DiffEqBase API

AutoDespecialize

Use a stable dynamic parameter container so compiled solver code can be shared across different concrete parameter layouts. The original parameter is recovered at the SciML function call barrier.

AutoRespecialize

Use the constrained non-dynamic parameter policy, which recovers the original concrete parameter type from an opaque container on supported solver paths.

AutoDePSpecialize

Deprecated alias for AutoRespecialize.

AutoDePSpecialize

Deprecated name for AutoRespecialize. New code should use AutoRespecialize.

struct AutoRespecialize <: SciMLBase.AbstractSpecialization

AutoRespecialize extends AutoSpecialize by additionally de-specializing the parameter object. Solver paths with a supported opaque-parameter strategy pack an isbits, non-NullParametersp into a fixed-type opaque container (e.g. RespecializeParams.OpaqueParams) and install callable wrappers whose signatures carry the opaque container type in the p slot instead of typeof(p). The concretized problem type — and with it the solver's compilation — then becomes independent of the user's parameter struct type, so a single compiled (and precompiled) solve is shared across all isbits parameter types. Inside the user's f, p is recovered at its original concrete type via a type-stable, allocation-free unpack, so the model function itself remains fully specialized.

AutoRespecialize is the recommended choice for latency-sensitive workflows that construct many problems with differently-typed parameter structs (parameter studies over configuration structs, package test suites, teaching setups).

Support is solver-specific, like all specialization levels. Where a solver path has no opaque-parameter strategy — or where p is not isbits or is NullParameters — behavior falls back to plain AutoSpecialize. Solvers that apply the packing keep the opaque container in the concretized problem (e.g. sol.prob.p), since installed wrappers may be re-invoked with it; consult the solver's documentation for how to recover the original value.

Example

struct MyParams
    k::Float64
end
f(du, u, p, t) = (du .= p.k .* u)
ODEProblem{true, SciMLBase.AutoRespecialize}(f, [1.0], (0.0, 1.0), MyParams(2.0))

ODE_DEFAULT_ISOUTOFDOMAIN(u, p, t)

The default isoutofdomain predicate used by the integrators. It always returns false, i.e. no state is considered out of the problem's domain. Pass a custom predicate via the isoutofdomain solver keyword to reject steps whose proposed state leaves a valid domain.

ODE_DEFAULT_NORM(u, t)
ODE_DEFAULT_NORM(f, u, t)

The default internal norm used by the integrators for error estimation and step-size control. It is the (optionally f-weighted) RMS norm: roughly sqrt(sum(abs2, u) / length(u)), which scales with the magnitude of the state but not its dimensionality, with specialized methods for scalars, Arrays, static arrays, and nested array types. Pass a custom callable via the internalnorm solver keyword to override it.

ODE_DEFAULT_PROG_MESSAGE(dt, u, p, t)

The default progress-bar message builder used by the integrators when progress = true. It returns a short multi-line string reporting the current dt, t, and the largest-magnitude component of the state u. Pass a custom callable via the progress_message solver keyword to override it.

ODE_DEFAULT_UNSTABLE_CHECK(dt, u, p, t) -> Bool

Return whether the default ODE instability check considers the current state unstable.

The generic fallback returns false. Numeric scalars, arrays, and ArrayPartitions return true when any state entry is infinite or non-finite. This is the default used by OrdinaryDiffEq solvers when no unstable_check callback is supplied.

Arguments

• dt: Current step size.
• u: Current state.
• p: Problem parameters.
• t: Current time.

Returns

• Bool: true when the state should be treated as unstable.

NAN_CHECK(x)

Recursively test whether x holds a NaN. The integrators use this to detect a step that produced NaN and reject it.

Methods are provided for numbers, AbstractArrays, RecursiveArrayTools.AbstractVectorOfArrays and RecursiveArrayTools.ArrayPartitions; nested containers are descended into, so a state made of arrays of arrays reports true if any leaf is NaN. Enum values always report false, which keeps discrete components of a mixed state vector from being sent through isnan. Add a method to make the check reach the elements of a custom state type:

DiffEqBase.NAN_CHECK(x::MyStateType) = any(DiffEqBase.NAN_CHECK, x.parts)

NaN is only one of the ways a step can go bad; Inf and overflow are handled separately by ODE_DEFAULT_UNSTABLE_CHECK.

abstract type Tableau

abstract type ODERKTableau <: DiffEqBase.Tableau

mutable struct ExplicitRKTableau{MType<:(AbstractMatrix), VType<:(AbstractVector), CType<:(AbstractVector), S, IType} <: DiffEqBase.ODERKTableau

Holds a tableau which defines an explicit Runge-Kutta method.

mutable struct ImplicitRKTableau{MType<:(AbstractMatrix), VType<:(AbstractVector), CType<:(AbstractVector)} <: DiffEqBase.ODERKTableau

Holds a tableau which defines an implicit Runge-Kutta method.

struct ConvergenceSetup{P, C}

abstract type DECostFunction

struct DefaultInit <: DAEInitializationAlgorithm

The default initialization algorithm for DAEs. This will use heuristics to determine the most appropriate initialization based on the problem type.

For Sundials, this will use:

• OverrideInit if the problem has initialization_data (typically from ModelingToolkit)
• CheckInit otherwise

struct BrownFullBasicInit{T, F} <: DAEInitializationAlgorithm

The Brown full basic initialization algorithm for DAEs. This implementation is based on the algorithm described in:

Peter N. Brown, Alan C. Hindmarsh, and Linda R. Petzold, "Consistent Initial Condition Calculation for Differential-Algebraic Systems", SIAM Journal on Scientific Computing, Vol. 19, No. 5, pp. 1495-1512, 1998. DOI: https://doi.org/10.1137/S1064827595289996

This method modifies the algebraic variables and their derivatives to be consistent with the DAE constraints, while keeping the differential variables fixed. It uses Newton's method to solve for consistent initial values.

This is the default initialization for many DAE solvers when differential_vars is provided, allowing the solver to distinguish between differential and algebraic variables.

Parameters

• abstol: Absolute tolerance for the nonlinear solver (default: 1e-10)
• nlsolve: Custom nonlinear solver to use (optional)

struct ShampineCollocationInit{T, F} <: DAEInitializationAlgorithm

The Shampine collocation initialization algorithm for DAEs. This implementation is based on the algorithm described in:

Lawrence F. Shampine, "Consistent Initial Condition for Differential-Algebraic Systems", SIAM Journal on Scientific Computing, Vol. 22, No. 6, pp. 2007-2026, 2001. DOI: https://doi.org/10.1137/S1064827599355049

This method uses collocation on the first two steps to find consistent initial conditions. It modifies both the differential and algebraic variables to satisfy the DAE constraints. This is more general than BrownBasicInit but may be more expensive computationally.

This method is useful when you need to modify all variables (both differential and algebraic) to achieve consistency, rather than just the algebraic ones.

Parameters

• initdt: Initial time step to use in the collocation method (optional)
• nlsolve: Custom nonlinear solver to use (optional)

Ignores all adjoint definitions (i.e. sensealg) and proceeds to do standard AD through the solve functions. Generally only used internally for implementing discrete sensitivity algorithms.