Redesign default ODE solver to be type-grounded and lazy #2184
Conversation
oscardssmith
force-pushed
the
os/default_solver-v2
branch
3 times, most recently
from
929f41d to
817d250
Compare
|
Seems like there was a rebase issue in the cache builds |
|
I believe the rebase is now actually correct. Rebasing across the formatting changes is really annoying. |
|
@ChrisRackauckas I think your merge was wrong. I'll fix it. |
This accomplishes a few things: * Faster precompile times by precompiling less * Full inference of results when using the automatic algorithm * Hopefully faster load times by also precompiling less This is done the same way as * linearsolve SciML/LinearSolve.jl#307 * nonlinearsolve SciML/NonlinearSolve.jl#238 and is thus the more modern SciML way of doing it. It avoids dispatch by having a single algorithm that always generates the full cache and instead of dispatching between algorithms always branches for the choice. It turns out, the mechanism already existed for this in OrdinaryDiffEq... it's CompositeAlgorithm, the same bones as AutoSwitch! As such, this reuses quite a bit of code from the auto-switch algorithms but instead of just having two choices it (currently) has 6 that it chooses between. This means that it has stiffness detection and switching behavior, but also in a size-dependent way. There are still some optimizations to do though. Like LinearSolve.jl, it would be more efficient to have a way to initialize the caches to size zero and then have a way to re-initialize them to the correct size. Right now, it'll generate the same Jacobian N times and it shouldn't need to do that. fix typo / test fix precompilation choices Update src/composite_algs.jl Co-authored-by: Nathanael Bosch <nathanael.bosch@uni-tuebingen.de> Update src/composite_algs.jl switch CompositeCache away from tuple so it can start undef Default Cache fix precompile remove fallbacks remove fallbacks
oscardssmith
force-pushed
the
os/default_solver-v2
branch
from
e080f75 to
5f19a80
Compare
|
Awesome, looks like tests pass sans codecov nonsense. Can you prepare the two big downstream changes as well, the fix to DelayDiffEq and also a change to DifferentialEquations.jl which uses this as the default? |
|
I think I can make this work without requiring a DelayDiffEq fix ( |
|
Yes 1 PR, I'm a bit confused which one is the one to look at. |
|
Can you port something similar to https://github.com/SciML/DifferentialEquations.jl/blob/master/test/default_ode_alg_test.jl over to here so it's tested? Big feature to not have a test for 😅 |
|
Unfortunately the fully grounded approach makes this type of test impossible. I think the only thing we can test is that the number of steps and f evals roughly match what we would expect. These tests have now been added. |
|
You can check the |
|
I believe this is now ready to merge. |
|
Test fails |
|
Before merging this, I think the issues linked to #2103 should be checked and specify if this PR can resolve them. |
|
This I believe does all the things that PR requires. Specifically, it is type stable, and roughly the same for precompile. I'm not sure either version actually makes a significant precompile difference, since they both take us from precompiling 6 solvers to a single solver that calls all the functions that those 6 solvers would have called. |
|
What's the test failure from? |
|
The test failure was from me being wrong about which algorithm would be used for exrober at the last timestep. (I think due to the same issue that causes #2198). The test has been adjusted. |
This is the version of #2103 that doesn't end up initializing the integrator caches that are unused. The code is fairly janky, but it all works and is type stable.