Solvers Overview
Comparison of the numerical integration routines available.
The solvers module provides the numerical integrators necessary to step differential equations forward in time. Because fractional-order derivatives are non-local (they depend on the history of the trajectory), their numerical integration is significantly more complex and computationally demanding than classical integer-order ODEs.
Available Solvers
| Solver | Type | Order | Speed | Memory Scaling | Best For |
|---|---|---|---|---|---|
EFORKSolver | Explicit | Fractional () | Very Fast | Primary fractional sweeps | |
ABMSolver | Predictor-Corrector | Fractional () | Slower | High-accuracy verification | |
RK4Solver | Explicit | Integer () | Fastest | Classical analysis |
(Note: is the memory window length).
When to use which?
- Massive sweeps (High-throughput): If you are evaluating 10,000 initial conditions across a grid to map a basin of attraction in a fractional system, use
EFORKSolver. It provides a good balance of speed and stability. - Publishing a figure (High-accuracy): If you have found a single, fragile hidden attractor and want to generate a rigorous, high-quality rendering of its trajectory for a paper, switch to
ABMSolver. It prevents drift over very long integration times. - Integer-order benchmarks: Use
RK4Solverfor new lightweight ODE studies. To reproduce the documented Chua integer reference case, preserve its numerical contract: EFORK-3 evaluated at with the native hiddenness, basin, and Lyapunov stages.
The Memory Window ()
Fractional solvers approximate the Caputo derivative using a sliding memory window.
- Short memory (e.g., 50-100): Very fast, but behaves more like an integer-order system with heavy damping. Inaccurate for true fractional dynamics.
- Long memory (e.g., 500-2000): Accurate fractional behavior, but requires caching and convolving the last points at every integration step. Computation time scales linearly with memory length.
C Backend Fallbacks
The library attempts to compile a native C extension via ctypes on the first run of any solver. If a C compiler is not found, the library will print a warning and fall back to a pure Python/NumPy implementation.
The Python implementations are mathematically identical but can be 10x to 50x slower, especially for fractional solvers with large memory windows. See Native Backends for compilation details.