3
$\begingroup$

In the Wikipedia article on Runge-Kutta methods, there is a notation explained using a Butcher table with a $c_{i}$ vector (nodes), a $b_{i}$ vector (weights) and a runge-kutta matrix $a_{ij}$.

My question is : does every runge-kutta-something method is entirely summed up by this Butcher table, or is there some subtleties ?

For example, if we take the Feagin RK12 and RK14 methods explained here :

and with the coefficients :

do the coefficients completely constrain the numerical scheme or is there additional details to put in the integrator ?

For example when we say RK14(12) which is a "14th order method with an embedded 12th order method", can I simply put the Butcher table in a generic RK integrator which takes $c_{i}$, $b_{i}$ and $a_{ij}$ as arguments, or is there some additional details to know ?

$\endgroup$
5
$\begingroup$

Yes, the coefficients completely define a Runge-Kutta scheme. If you put a tableau into a generic integrator, it will work...

But there are caveats. Will the methods achieve the correct order? Yes. Will they be efficient? No, for many reasons. For one, many of the tableaus try to "maximize zeros". This reduces the number of calculations you have to do. But if it's an array-based implementation, it will still do 0*k[i] + ... so there will be an unnecessary array-dereference, multiplication, and addition for every single zero in the tableau. Also, it won't take into account things like FSAL which is "first same as last", meaning schemes setup such that the first function evaluation is the same as the last evaluation from the previous timestep, so you can actually "get rid" of 1 function evaluation per timestep. Also, some methods like Symplectic Runge-Kutta methods may be shown as tableaus but lose extra properties like their conservation if not treated properly.

So yes, it will work if you throw that tableau into some program. But don't expect it to be very efficient. In fact, the Feagin methods have lots of zeros and require a lot of unnecessary allocations if used in a vectorized manner. Thus I noticed when implementing them in DifferentialEquations.jl that you can make them a lot more efficient by unraveling the matrices (to make the constants stack allocate) and de-vectorizing all of the updates (to get rid of all temporaries). The resulting algorithm is quite a mess (you can find it here if you want to take a look), but this specialized implementation is much faster than the general implementation.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.