# Does Runge Kutta methods run well with variable $h$?

When using Runge Kutta methods for real time simulations there is a problem with the constant step length $$h$$ since the operating systems often interrupt the simulation and the main loop therefore has a variable length.

Is it relevant to use a slightly variable $$h$$ being the real time for the calculation in the loop? Are there other methods better suited for real time simulations?

No, the great thing about Runge-Kutta is that even though it appears to be a third-order method, by a "miracle" of the algebra it is correct to fourth order.

If you let $$h$$ vary and use naively use the same formulas, the algorithm gets errors on order of $$h^2$$ and so you might as well be using the basic Euler method. If instead you properly correct for the varying $$h$$ you can restore it to third order but the fortuitous cancellation that gives you one free order will never recur.

• How about using an estimated constant $h$ for shorter intervalls, say about $10-100$ steps, and change the the step length when OS (ubuntu) start to interfere? – Lehs Oct 8 '18 at 7:57
• Could you please explain your mysterious statement "appears to be a third-order method"? It appears to be the generalization of the Simpson quadrature to ODE integration, and Simpsons method has error order 4. Are we talking about classical RK4? Where does the order reduction in a one-step method come from? Your last remark might apply to multi-step methods, but those are not called "Runge-Kutta". – LutzL Oct 8 '18 at 12:41
• @LutzL: Yes, Simpson's rule integration is 4th order -- but if you were to naively try for a balanced-step-size 3rd order integration method, you would get Simpson's rule. The same sort of "lucky" break happens with Runge-Kutta. In fact, I think if you apply RK4 to merely integrate a given function, it will exactly replicate Simpson's rule. – Mark Fischler Oct 16 '18 at 2:18

Operating system interrupting execution should be irrelevant if you use a real-time operating system, right?

There are methods of varying $$h$$ in Runge-Kutta but they are for estimating the error term for adaptive step-size control, such as RKF45 or DOPRI methods. They solve a different problem.

• I guess you can't run Google Earth parallell with the simulation on RTOS? Which is nice when simulating an orbiter. – Lehs Oct 8 '18 at 8:01

You need to do full steps of the one-step method with a fixed $$h$$. However, between the steps the value of $$h$$ can vary. If you can guarantee that in every step $$h<\bar h$$ with some constant $$\bar h$$ then the error will still be bounded by $$O(\bar h^4)$$. So if in the real-time simulation there is a sleep time of $$\underline{h}$$ then other processes may cause the actual time that the evaluation resumes is larger. You compute $$h$$ using the actual time elapsed since the last step. Assuming that this delay is a bounded quantity, this gives the mentioned $$\bar h$$ so that $$\underline{h}\le h\le \bar h$$.

The advanced way to solve this problem is to compute the next ODE integration step with an $$h$$ that guarantees the needed accuracy of the simulation, where one can also use an adaptive step size strategy, Richardson extrapolation or embedded methods are often used. For the real time display you then interpolate the values for the time of the frame that is displayed, in the most simple case use linear interpolation. Then compute the next integration step when it becomes necessary. As you can use larger step sizes in the numerical ODE integration, the evaluation of the simulation dynamic has to occur less often, which takes less computational effort and may make the animation smoother.

• A good idea to use a greater but accurate $h$. That seems to solve my problem. – Lehs Oct 8 '18 at 17:42