I think the confusion here is what exactly is a "tableau method" since it's used in our docs in a very specific way. A "tableau method" in DifferentialEquations.jl parlance is a method which is implemented by explicitly building the arrays for the tableaus and performing loops on said arrays. The tableaus are stored in DiffEqDevTools.jl in the highest precision published and transform at compile-time to the right precision before solving. Here is Tsitouras' 5th order method:
https://github.com/JuliaDiffEq/DiffEqDevTools.jl/blob/master/src/ode_tableaus.jl#L866-L920
You can directly use these with the ExplicitRK method. Here is its internal perform_step
function:
https://github.com/JuliaDiffEq/OrdinaryDiffEq.jl/blob/master/src/perform_step/explicit_rk_perform_step.jl#L72-L119
However, as another post mentioned, when we first did this we did a literature review of all of the tableaus we could find, implemented them, tested them, looked at stability, etc. (that 8000 line page of tableaus :) ) and then specialized some of the algorithms. For example, for Tsitoras' method we pulled it apart into a stack-allocated tableau
https://github.com/JuliaDiffEq/OrdinaryDiffEq.jl/blob/master/src/tableaus/low_order_rk_tableaus.jl#L497-L601
specialized the equations on the form of the constants
https://github.com/JuliaDiffEq/OrdinaryDiffEq.jl/blob/master/src/perform_step/low_order_rk_perform_step.jl#L609-L656
added a special interpolant to it, modified some default magic numbers for adaptivity, etc. to specifically optimize this algorithm. We also have a trait system which for example hard codes specific constants about the stability region necessary for performing stiffness detection and automatic switching to implicit methods. And we did that for a few other RK methods. A lot of these optimizations only truly matter if f
is inexpensive, but since that shows up in a lot of cases (parameter estimation and searches, analysis of chaotic systems) we took the time to do this, tested it, and performance-wise would recommend these implementations over the pure tableau-based form. Note that it is mathematically the same method, but this formulation does not require loops over constants and instead is in a form that LLVM optimizes very well. When the equation is small, Julia will in fact in line the user's f
derivative function and the solver will construct something entirely different and efficient.
But that's just optimizations and just a DifferentialEquations.jl thing. Explicit RK methods, implicit RK methods, Rosenbrock methods, etc. can all be discussed as methods in a tableau form, and these are all quite good methods. The Tsitorious method which was shown above is actually one of the core defaults of the ecosystem, and a similar method is the Dormand-Prince method which you might know of as ode45
. These are still quite state-of-the-art (at least for non-stiff equations, and when paired with PI-adaptivity and their special interpolants). These are the methods you see recommended everywhere, along with a few non-tableau methods like multistep Adams and BDF. Due to the benchmarks we have we recommend the hand-tuned versions, but it's stepping behavior are mathematically the same as if you looped through arrays of constants (sans the specializations on constants and interpolations).
For your aside, our test showed that not every tableau is worth it. Some just aren't efficient. Over time, people have gotten better at choosing coefficients which reduce the leading truncation error term while keeping the stability region the same size. The older methods then take similar steps but result in a solution with more error. We keep them there for research purposes, and also it's a nice archive of the literature since some of those are hard to find.