SciML / NBodySimulator.jl

A differentiable simulator for scientific machine learning (SciML) with N-body problems, including astrophysical and molecular dynamics
https://docs.sciml.ai/NBodySimulator/stable/
Other
130 stars 20 forks source link

run_simulation integrator support #26

Open SebastianM-C opened 4 years ago

SebastianM-C commented 4 years ago

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 calls calculate_simulation for ODEs, which uses dispatch on the algorithm type to choose between creating and solving an ODEProblem or SecondOrderODEProblem. https://github.com/SciML/NBodySimulator.jl/blob/172b046d8f3cfd0737df294fb54481b0bc95e754/src/nbody_simulation_result.jl#L292-L302

The current implementation thus only allows only some some dynamical ODE solvers to be used with run_simulation since any other would use the ODEProblem 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 SecondOrderODEProblems for everything and remove the ODEProblem path.

I can start a PR if we decide upon a solution.

ChrisRackauckas commented 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.