I did some poking around – I think this is just a particular implementation of runga-kutta 4(5). Is this correct?
Yes, see the (brief) docs. According to the underlying paper and Chris’s benchmarks, it hits a sweet spot in precision and speed for many non-stiff problems using RK4(5).
It’s a newer tableau of coefficients for Runge–Kutta by Tsitouras (2011) that is more efficient than older versions like Dormand–Prince, as reviewed here by @ChrisRackauckas.
9 Likes
I just wanted to note that one of the nice things about Tsit5 over Dormand-Prince is that it gives you a fourth-order interpolant for free in case you need dense output! This can be a huge boost to performance if you want to specify the output times of the integration procedure.
6 Likes
(I probably shouldn’t dig up an old post, but my question is related)
I wanted to implement the method myself (or any other RK with a tableau) as an exercise. However, I struggled a bit with this one.
There are two possibilities to build the approximation, either with order p using the factors b_i or p-1 using the factors \hat{b}_i. However, when I extract the second factors from the paper
bhat = Float64[0.001780011052226, 0.000816434459657, -0.007880878010262, 0.144711007173263, -0.582357165452555, 0.458082105929187, 1.0/66.0]
I see that the sum is not equal to 1 but rather 2/66; hence it cannot be used to build y_{n+1}.
Is there somewhere a trick that I missed? This is kind of weird, as in the algorithm they describe to find those coefficients, there is the unity constraint.
I think that bhat is used to calculate the difference between the two orders.
The sum of bhat should be null and the last coefficient is -1.0/66.0
You can see the coefficients used in OrdinaryDiffEq.jl here
1 Like