Use Runge-Kutta integration in trajectory sim

[7deeptide]

@IanZabel We can improve the accuracy of the trajectory simulation if we move towards a 4th-order Runge-Kutta instead of the forward-difference Euler method we're currently using. I suggest we use the built in “dopri5” method in scipy.integrate.ode to do this. Thoughts?

[natronics]

It almost certainly doesn't make any difference. I suspect the numerical integrator errors are smaller that the uncertainty in the inputs (i.e., the unknowns of what a real flight vehicle mass/aero/etc. are bigger than whatever small integration error there might be).

That said, algorithms like dopri5 (Dormand–Prince) are very clever in that they can get an estimate of the real integrator error as they run, and adjust the time-step as they go holding onto a lower-bound error. That means you can run it and explicitly say "integrate this with no more than 10e-5 of error in each step" which is pretty neat. It also means they tend to run significantly faster than fixed-timestep integrator because they always take the largest possible timestep.

So go ahead and use dopri5 if you like, it will probably make the sim run (possibility much) faster. But I wouldn't expect it to change the actual outcome of the simulation, it's not the integrator that's the problem, it's knowing the real world conditions if the first place.

[IanZabel]

I read through the Dormand-Prince page and did some searching. I found the cash-karp method which, according to people on the Internet, performs almost identical to Dormand-Prince (since they are essentially the same thing) but can be sometimes slightly faster. Not much of a change, but easily tested.

I also found this page which provides a new package of a bunch of options. I'm still sorting through the page, haven't quite pulled anything useful from it yet.

[natronics]

I think Cash-Karp is more popular. Note that for this application the speedups we're talking about are likely in the thousandths of seconds. I don't think it matters if the sim takes 3.017 seconds or 3.023 seconds here.

The reason there is so much work devoted to this area is for super computing, when simulations can take on the order of years on large compute clusters unless careful attention to optimization is applied.

For us it literally does not matter. Just pick any of the adaptive-timestep RK based ones (it's the Swiss Army knife of integrators) and go with it.

[7deeptide]

@natronics @IanZabel Given the size of our timestep relative to the characteristic times (displacements and velocities at each timestep) for some of the flight dynamics I'd assume the error is quite large. But you're quite correct that we have other potentially larger sources of error elsewhere. Should we close this issue?

[natronics]

To clarify, I do think it's a good idea to use Cash-Karp, or Dormand-Prince, or similar because they handle setting the timestep for you in a safe way, with lower-bounded errors. That's a good thing! (though unless you were running the current Euler method with a huge timestep I wouldn't expect much of a different result)

I just want to be clear it doesn't make any difference which method in particular you use, and it certainly doesn't make any sense using anything more "sophisticated" like Adams Bash Moulton, or Filtered Leapfrog or whatever.

[7deeptide]

The timesteps are large (dt = 1 s).

[PandnotPthereforeQ]

I've implemented a 4th order Runge-Kutta with fixed timestep (dt = 0.25 s).