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.isautodifferentiable — Function
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.
SciMLBase.allows_arbitrary_number_types — Function
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.
SciMLBase.allowscomplex — Function
allowscomplex(alg::AbstractDEAlgorithm)Trait declaration for whether an algorithm is compatible with having complex numbers as the state variables.
Defaults to false.
SciMLBase.isadaptive — Function
isadaptive(alg::AbstractDEAlgorithm)Trait declaration for whether an algorithm uses adaptivity, i.e. has a non-quasi-static compute graph.
Defaults to true.
isadaptive(i::DEIntegrator)Checks if the integrator is adaptive
SciMLBase.isdiscrete — Function
isdiscrete(alg::AbstractDEAlgorithm)Trait declaration for whether an algorithm allows for discrete state values, such as integers.
Defaults to false.
SciMLBase.forwarddiffs_model — Function
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.
SciMLBase.forwarddiffs_model_time — Function
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
SciMLBase.forwarddiff_chunksize — Function
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).
SciMLBase.has_lazy_interpolation — Function
has_lazy_interpolation(alg::AbstractDEAlgorithm)Trait declaration for whether an algorithm computes the solution interpolation lazily.
Defaults to false.
SciMLBase.allows_late_binding_tstops — Function
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.
SciMLBase.has_init — Function
has_init(a) -> Bool
Trait for specifying whether the passed algorithm supports init. Any inited object can solve!.
SciMLBase.has_step — Function
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.
SciMLBase.alg_order — Function
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.
SciMLBase.allowsbounds — Function
allowsbounds(opt)Trait declaration for whether an solver allows for box constraints passed with lb and ub in problems.
Defaults to false.
SciMLBase.allowsconstraints — Function
allowsconstraints(opt)Trait declaration for whether an optimizer allows non-linear constraints specified in cons in OptimizationFunction.
Defaults to false.
SciMLBase.alg_interpretation — Function
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.
SciMLBase.AlgorithmInterpretation is the public enum namespace for stochastic integral interpretations used by SciMLBase.alg_interpretation.
Abstract SciML Algorithms
SciMLBase.AbstractSciMLAlgorithm — Type
abstract type AbstractSciMLAlgorithmSciMLBase.AbstractDEAlgorithm — Type
abstract type AbstractDEAlgorithm <: SciMLBase.AbstractSciMLAlgorithmSciMLBase.AbstractLinearAlgorithm — Type
abstract type AbstractLinearAlgorithm <: SciMLBase.AbstractSciMLAlgorithmSciMLBase.AbstractNonlinearAlgorithm — Type
abstract type AbstractNonlinearAlgorithm <: SciMLBase.AbstractSciMLAlgorithmSciMLBase.AbstractIntervalNonlinearAlgorithm — Type
abstract type AbstractIntervalNonlinearAlgorithm <: SciMLBase.AbstractSciMLAlgorithmSciMLBase.AbstractIntegralAlgorithm — Type
abstract type AbstractIntegralAlgorithm <: SciMLBase.AbstractSciMLAlgorithmMissing docstring for SciMLBase.AbstractQuadratureAlgorithm. Check Documenter's build log for details.
SciMLBase.AbstractOptimizationAlgorithm — Type
abstract type AbstractOptimizationAlgorithm <: SciMLBase.AbstractDEAlgorithmSciMLBase.AbstractSteadyStateAlgorithm — Type
abstract type AbstractSteadyStateAlgorithm <: SciMLBase.AbstractDEAlgorithmSciMLBase.AbstractODEAlgorithm — Type
abstract type AbstractODEAlgorithm <: SciMLBase.AbstractDEAlgorithmSciMLBase.AbstractSecondOrderODEAlgorithm — Type
abstract type AbstractSecondOrderODEAlgorithm <: SciMLBase.AbstractDEAlgorithmSciMLBase.AbstractRODEAlgorithm — Type
abstract type AbstractRODEAlgorithm <: SciMLBase.AbstractDEAlgorithmSciMLBase.AbstractSDEAlgorithm — Type
abstract type AbstractSDEAlgorithm <: SciMLBase.AbstractDEAlgorithmSciMLBase.AbstractDAEAlgorithm — Type
abstract type AbstractDAEAlgorithm <: SciMLBase.AbstractDEAlgorithmSciMLBase.AbstractDDEAlgorithm — Type
abstract type AbstractDDEAlgorithm <: SciMLBase.AbstractDEAlgorithmSciMLBase.AbstractSDDEAlgorithm — Type
abstract type AbstractSDDEAlgorithm <: SciMLBase.AbstractDEAlgorithmSciMLBase.DAEInitializationAlgorithm — Type
abstract type DAEInitializationAlgorithm <: SciMLBase.AbstractSciMLAlgorithmSciMLBase.AbstractDiscretization — Type
abstract type AbstractDiscretization <: SciMLBase.AbstractSciMLAlgorithmDAE Initialization Algorithms
SciMLBase.NoInit — Type
struct NoInit <: DAEInitializationAlgorithmAn initialization algorithm that completely skips the initialization phase. The solver will use the provided initial conditions directly without any consistency checks or modifications.
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())SciMLBase.OverrideInit — Type
struct OverrideInit <: DAEInitializationAlgorithmAn 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 solverreltol: Relative tolerance for the initialization solvernlsolve: 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())