Open SebastianM-C opened 4 years ago
And a simpler option would be to just use SecondOrderODEProblems for everything and remove the ODEProblem path.
That's probably the right thing to do. I think the benchmarks are demonstrating that it's pretty much always the case you want to do this. Unless you really really want to use a method for stiff ODEs, but we can make some SecondOrderODEProblem stiff ODE solvers (we should, there are plenty to implement), and the fallback should work anyways nowadays.
The current
run_simulation
interface is used to create and solve the appropriate ODE/SDE problem based on the thermostat algorithm. https://github.com/SciML/NBodySimulator.jl/blob/172b046d8f3cfd0737df294fb54481b0bc95e754/src/nbody_simulation_result.jl#L284-L290 It internally callscalculate_simulation
for ODEs, which uses dispatch on the algorithm type to choose between creating and solving anODEProblem
orSecondOrderODEProblem
. https://github.com/SciML/NBodySimulator.jl/blob/172b046d8f3cfd0737df294fb54481b0bc95e754/src/nbody_simulation_result.jl#L292-L302The current implementation thus only allows only some some dynamical ODE solvers to be used with
run_simulation
since any other would use theODEProblem
fallback and fail.One way to solve this would be via a trait, as indicated in the comment. An other option would be to select only some predefined well performing integrators in the union and indicate to users that they should manually construct and solve the problem for other algorithms. And a simpler option would be to just use
SecondOrderODEProblem
s for everything and remove theODEProblem
path.I can start a PR if we decide upon a solution.