Our great sponsors
-
SciMLBenchmarks.jl
Scientific machine learning (SciML) benchmarks, AI for science, and (differential) equation solvers. Covers Julia, Python (PyTorch, Jax), MATLAB, R
-
SimpleDiffEq.jl
Simple differential equation solvers in native Julia for scientific machine learning (SciML)
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
DiffEqDevTools.jl
Benchmarking, testing, and development tools for differential equations and scientific machine learning (SciML)
But even that makes an assumption that some terms are zero to make the proof easier, so in 2011 someone used numerical optimizers to find the coefficients without the row simplifying assumptions. From doing that the principle truncation error norm is 1.38e-4 instead of Dormand-Prince's 3.99e-4, which suggests some potential performance advantages. While that doesn't necessarily equate to a ~3x speedup because of other factors (stability, error estimators, etc.), it does suggest it's usually more efficient, and the SciMLBenchmarks demonstrate this does tend to be true on a wide enough margin of problems. Thus while everyone else is using ode45 (Dormand-Prince), dopri (name is obvious), etc., it's the default of SciPy and everything because the dopri Fortran code was written back in the 90's, we default to Tsit5() all of the time and take our performance advantage at not just the language level but also at an algorithmic level.
There you go, that's one step of it, taken from SimpleDiffEq.jl. But that's a really bad method and should almost never be used in practice.
And that's why you use a library. Not even most library writers follow this stuff closely enough to be updating for minute improvements to scalar coefficients in tableaus of numbers. But in Julia we validated 8,000 lines of code describing these coefficients in higher precision accuracy and did the tests to choose the most effective methods out of that list. RK4 is almost never efficient. And even non-stiff ODE solvers are getting algorithmic improvements in the 2000's.
Related posts
- How much useful are Runge-Kutta methods of order 9 and higher within double-precision arithmetic/floating point accuracy?
- Interpolant Coefficients for the BS5 Runge-Kutta method
- Why Fortran is a scientific powerhouse
- How Julia ODE Solve Compile Time Was Reduced From 30 Seconds to 0.1
- Simulating a simple circuit with the ModelingToolkit