SciMLAlgorithms

Definition of the AbstractSciMLAlgorithm Interface

SciMLAlgorithms are defined as types which have dispatches to the function signature:

CommonSolve.solve(prob::AbstractSciMLProblem, alg::AbstractSciMLAlgorithm; kwargs...)

Algorithm-Specific Arguments

Note that because the keyword arguments of solve are designed to be common across the whole problem type, algorithms should have the algorithm-specific keyword arguments defined as part of the algorithm constructor. For example, Rodas5 has a choice of autodiff::Bool which is not common across all ODE solvers, and thus autodiff is a algorithm-specific keyword argument handled via Rodas5(autodiff=true).

Remake

Note that remake is applicable to AbstractSciMLAlgorithm types, but this is not used in the public API. It's used for solvers to swap out components like ForwardDiff chunk sizes.

Common Algorithm Keyword Arguments

Commonly used algorithm keyword arguments are:

Traits

SciMLBase.isautodifferentiableFunction
isautodifferentiable(alg::AbstractDEAlgorithm)

Trait declaration for whether an algorithm is compatible with direct automatic differentiation, i.e. can have algorithms like ForwardDiff or ReverseDiff attempt to differentiate directly through the solver.

Defaults to false as only pure-Julia algorithms can have this be true.

source
SciMLBase.allows_arbitrary_number_typesFunction
allows_arbitrary_number_types(alg::AbstractDEAlgorithm)

Trait declaration for whether an algorithm is compatible with direct automatic differentiation, i.e. can have algorithms like ForwardDiff or ReverseDiff attempt to differentiate directly through the solver.

Defaults to false as only pure-Julia algorithms can have this be true.

source
SciMLBase.allowscomplexFunction
allowscomplex(alg::AbstractDEAlgorithm)

Trait declaration for whether an algorithm is compatible with having complex numbers as the state variables.

Defaults to false.

source
SciMLBase.isadaptiveFunction
isadaptive(alg::AbstractDEAlgorithm)

Trait declaration for whether an algorithm uses adaptivity, i.e. has a non-quasi-static compute graph.

Defaults to true.

source
isadaptive(i::DEIntegrator)

Checks if the integrator is adaptive

source
SciMLBase.isdiscreteFunction
isdiscrete(alg::AbstractDEAlgorithm)

Trait declaration for whether an algorithm allows for discrete state values, such as integers.

Defaults to false.

source
SciMLBase.forwarddiffs_modelFunction
forwarddiffs_model(alg::AbstractDEAlgorithm)

Trait declaration for whether an algorithm uses ForwardDiff.jl on the model function is called with ForwardDiff.jl

Defaults to false as only pure-Julia algorithms can have this be true.

source
SciMLBase.forwarddiffs_model_timeFunction
forwarddiffs_model_time(alg::AbstractDEAlgorithm)

Trait declaration for whether an algorithm uses ForwardDiff.jl on the model f(u,p,t) function is called with ForwardDiff.jl on the t argument.

Defaults to false as only a few pure-Julia algorithms (Rosenbrock methods) have this as true

source
SciMLBase.forwarddiff_chunksizeFunction
forwarddiff_chunksize(alg::AbstractSciMLAlgorithm)

Trait declaration for the ForwardDiff chunk size used by the algorithm when calling the model function with ForwardDiff.Dual numbers.

Returns a Val{N}(): Val(0) means unspecified (the framework will choose a default, typically 1 for FunctionWrapper compatibility). Val(N) for any positive integer N means the algorithm will use chunk size N.

This is used by DiffEqBase to compile FunctionWrapper variants with matching Dual number chunk sizes, avoiding NoFunctionWrapperFoundError.

Defaults to Val(0) (unspecified).

source
SciMLBase.has_lazy_interpolationFunction
has_lazy_interpolation(alg::AbstractDEAlgorithm)

Trait declaration for whether an algorithm computes the solution interpolation lazily.

Defaults to false.

source
SciMLBase.allows_late_binding_tstopsFunction
allows_late_binding_tstops(
    alg::SciMLBase.AbstractODEAlgorithm
) -> Bool

Trait declaration for whether an algorithm supports specifying tstops as a function tstops(p, tspan) to be called after initialization.

Defaults to false.

source
SciMLBase.has_initFunction
has_init(a) -> Bool

Trait for specifying whether the passed algorithm supports init. Any inited object can solve!.

source
SciMLBase.has_stepFunction
has_step(a) -> Bool

Trait for specifying whether the passed algorithm supports step!, specifying a more direct control over the internal solver process. See https://docs.sciml.ai/SciMLBase/stable/interfaces/Init_Solve/#init-and-the-Iterator-Interface for more details.

source
SciMLBase.alg_orderFunction
alg_order(alg)

The theoretic convergence order of the algorithm. If the method is adaptive order, this is treated as the maximum order of the algorithm.

source
SciMLBase.allowsboundsFunction
allowsbounds(opt)

Trait declaration for whether an solver allows for box constraints passed with lb and ub in problems.

Defaults to false.

source
SciMLBase.allowsconstraintsFunction
allowsconstraints(opt)

Trait declaration for whether an optimizer allows non-linear constraints specified in cons in OptimizationFunction.

Defaults to false.

source
SciMLBase.alg_interpretationFunction
alg_interpretation(alg)

Integral interpolation for the SDE solver algorithm. SDEs solutions depend on the chosen definition of the stochastic integral. In the Ito calculus, the left-hand rule is taken, while Stratonovich calculus uses the right-hand rule. Unlike in standard Riemannian integration, these integral rules do not converge to the same answer. In the context of a stochastic differential equation, the underlying solution (and its mean, variance, etc.) is dependent on the integral rule that is chosen. This trait describes which interpretation the solver algorithm subscribes to, and thus whether the solution should be interpreted as the solution to the SDE under the Ito or Stratonovich interpretation.

For more information, see https://oatml.cs.ox.ac.uk/blog/2022/03/22/ito-strat.html as a good high-level explanation.

Note

The expected solution statistics are dependent on this output. Solutions from solvers with different interpretations are expected to have different answers on almost all SDEs without additive noise.

source

SciMLBase.AlgorithmInterpretation is the public enum namespace for stochastic integral interpretations used by SciMLBase.alg_interpretation.

Abstract SciML Algorithms

Missing docstring.

Missing docstring for SciMLBase.AbstractQuadratureAlgorithm. Check Documenter's build log for details.

DAE Initialization Algorithms

SciMLBase.NoInitType
struct NoInit <: DAEInitializationAlgorithm

An initialization algorithm that completely skips the initialization phase. The solver will use the provided initial conditions directly without any consistency checks or modifications.

Warning

Using NoInit() with inconsistent initial conditions will likely cause solver failures or incorrect results. Only use this when you are absolutely certain your initial conditions satisfy all DAE constraints.

This is useful when:

  • You know your initial conditions are already perfectly consistent
  • You want to avoid the computational cost of initialization
  • You are debugging solver issues and want to isolate initialization from integration

Example

prob = DAEProblem(f, du0_consistent, u0_consistent, tspan)
sol = solve(prob, IDA(), initializealg = NoInit())
source
SciMLBase.OverrideInitType
struct OverrideInit <: DAEInitializationAlgorithm

An initialization algorithm that uses a separate initialization problem to find consistent initial conditions. This is typically used with ModelingToolkit.jl which can generate specialized initialization problems based on the model structure.

When using OverrideInit, the problem must have initialization_data that contains an initializeprob field with the initialization problem to solve.

This algorithm is particularly useful for:

  • High-index DAEs that have been index-reduced
  • Systems with complex initialization requirements
  • ModelingToolkit models with custom initialization equations

Fields

  • abstol: Absolute tolerance for the initialization solver
  • reltol: Relative tolerance for the initialization solver
  • nlsolve: Nonlinear solver to use for initialization

Example

# Typically used automatically with ModelingToolkit
@named sys = ODESystem(eqs, t, vars, params)
sys = structural_simplify(sys)
prob = DAEProblem(sys, [], (0.0, 1.0), [])
# Will automatically use OverrideInit if initialization_data exists
sol = solve(prob, IDA())
source