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...)Generic Usage Rules
Generic solver and extension code should dispatch on both the problem and algorithm interfaces and use capability traits for behavior that varies by algorithm. It must not inspect algorithm fields or assume that every algorithm supports every common keyword. In particular:
- algorithm-specific choices belong in the algorithm constructor and its documented fields;
- common solve controls belong in
solveorinitkeyword arguments; isadaptive,isdiscrete,allowscomplex,allows_arbitrary_number_types, andalg_orderdescribe execution behavior and should be queried before selecting a generic path;- capability traits such as
allowsbounds,requiresgradient, andallowscallbackmust be treated as contracts, not hints; remake(alg; kwargs...)is for preserving a concrete algorithm while replacing supported configuration fields, and callers must not assume that arbitrary fields are replaceable.
An algorithm author should test the trait values and the generic solve dispatch with a representative algorithm value. A downstream consumer should be able to make compatibility decisions without naming the concrete solver:
function supports_complex_adaptive(alg::SciMLBase.AbstractSciMLAlgorithm)
return SciMLBase.allowscomplex(alg) && SciMLBase.isadaptive(alg)
endAlgorithm-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 an algorithm-specific keyword argument handled via Rodas5(autodiff=true).
Remake
remake is applicable to AbstractSciMLAlgorithm values and lets solver packages replace constructor fields while preserving the concrete algorithm type. This is useful for internal transformations such as changing an automatic differentiation chunk size. User code should normally construct the desired algorithm directly because supported replacement fields are defined by each concrete algorithm.
Common Algorithm Keyword Arguments
An algorithm constructor stores choices that are specific to that numerical method, such as an automatic differentiation backend, linear solver, preconditioner, stage limiter, or method variant. Options shared across methods for a problem family belong to solve and init: saving, tolerances, step-size control, callbacks, progress, initialization, and RNG handling use the common keyword interface.
Concrete algorithms must document constructor fields, supported common keywords, and any keyword whose meaning or default differs from the family contract. Solver code should reject or diagnose unsupported common keywords rather than silently treating an allow-listed name as proof of capability.
Compatibility Diagnostics
SciMLBase.check_keywords — Function
check_keywords(alg, kwargs, warnlist) -> BoolWarn for each non-nothing keyword in kwargs whose name occurs in warnlist. The warning identifies alg as ignoring that keyword. Return true when at least one warning was emitted and false otherwise.
Solver packages can use this helper to diagnose common solve keywords that a specific algorithm does not implement. It does not remove keywords or validate keywords outside warnlist.
SciMLBase.warn_compat — Function
warn_compat()
Emit a warning with a link to the solver compatibility chart in the DifferentialEquations.jl documentation. This compatibility helper takes no arguments and always returns the result of @warn.
Traits
SciMLBase.isautodifferentiable — Function
isautodifferentiable(alg::AbstractDEAlgorithm)Trait declaring whether direct automatic differentiation through a solver is supported.
Return true only when the algorithm implementation is generic enough that AD systems such as ForwardDiff.jl, ReverseDiff.jl, or source-to-source AD can differentiate the solver itself. Wrapped foreign solvers and solvers that use non-differentiable mutation, callbacks, or external state should keep the default and instead rely on sensitivity algorithms or problem-level derivative interfaces.
The default is false.
SciMLBase.allows_arbitrary_number_types — Function
allows_arbitrary_number_types(alg::AbstractDEAlgorithm)Trait declaring whether an algorithm supports nonstandard numeric scalar types.
Algorithms that return true should be implemented generically enough to work with SciML-compatible state, parameter, and time number types beyond standard floating-point and complex floating-point types, subject to the additional rules in the SciML container and number interface. Wrapped C/Fortran solvers and algorithms that assume a concrete floating-point storage format usually cannot support this and should keep the default.
The default is false.
SciMLBase.allowscomplex — Function
allowscomplex(alg::AbstractDEAlgorithm)Trait declaring whether an algorithm supports complex-valued states.
Return true when the solver can accept complex entries in the problem state and all internal linear algebra, error estimates, caches, and callbacks used by the algorithm preserve complex values correctly. Algorithms that require real states should keep the default.
The default is false.
SciMLBase.isadaptive — Function
isadaptive(alg::AbstractDEAlgorithm)Trait declaring whether an algorithm uses adaptive stepping or adaptive work.
Return true when the algorithm may vary step sizes, iteration counts, or other internal work based on local error estimates or runtime convergence behavior. Return false for fixed-work algorithms with a quasi-static compute graph. Callers use this trait when deciding which keyword defaults and differentiable execution strategies are appropriate.
The default is true, which is conservative for differential equation solvers.
isadaptive(i::DEIntegrator)Checks if the integrator is adaptive
SciMLBase.isdiscrete — Function
isdiscrete(alg::AbstractDEAlgorithm)Trait declaring whether an algorithm supports discrete-valued states.
Return true when the solver can advance states whose entries are not elements of a continuous scalar field, such as integers or categorical encodings. Continuous numerical integrators should keep the default.
The default is false.
SciMLBase.forwarddiffs_model — Function
forwarddiffs_model(alg::AbstractDEAlgorithm)Trait declaring whether an algorithm calls the user model with ForwardDiff dual numbers in the state or parameter arguments.
Return true when the solver internally uses ForwardDiff.jl on the model function, for example to build Jacobians or local linearizations. Function wrapping and specialization code uses this information to prepare callable variants that accept dual-number inputs. Algorithms that never dualize the model through ForwardDiff should keep the default.
The default is false.
SciMLBase.forwarddiffs_model_time — Function
forwarddiffs_model_time(alg::AbstractDEAlgorithm)Trait declaring whether an algorithm applies ForwardDiff to the model time argument.
Return true when the solver may call the model as f(u, p, t) with t as a ForwardDiff dual number. This is separate from forwarddiffs_model because some methods differentiate only with respect to state or parameters, while methods such as Rosenbrock-family ODE solvers may also differentiate with respect to time.
The default is false.
SciMLBase.forwarddiff_chunksize — Function
forwarddiff_chunksize(alg::AbstractSciMLAlgorithm)Trait declaring the ForwardDiff chunk size used by the algorithm when calling the model 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 declaring whether an algorithm constructs solution interpolation lazily.
Return true when dense-output interpolation is computed on demand from saved solver data rather than fully materialized during the solve. Solution and save handling code can use this to avoid assuming that interpolation coefficients are eagerly available at solve completion.
The default is false.
SciMLBase.has_global_error — Function
has_global_error(alg::AbstractDEAlgorithm)Trait declaring whether an algorithm computes an estimate of the global (accumulated) error of the solution.
Return true when the solver or solver wrapper populates the global_error field of the solution with a per-time-point estimate of the global error (the difference between the numerical and true solutions), rather than only controlling the local error of each step. When true, the solution's global_error is an array matching u; when false (the default) it is nothing.
The default is false.
SciMLBase.allows_late_binding_tstops — Function
allows_late_binding_tstops(
alg::SciMLBase.AbstractODEAlgorithm
) -> Bool
Trait declaring whether an ODE algorithm supports late-bound tstops.
Return true when the solver can accept tstops as a function tstops(p, tspan) and evaluate it after problem initialization has finalized the parameters and time span. Algorithms that require concrete time-stop values before initialization should keep the default.
The default is false.
SciMLBase.supports_opt_cache_interface — Function
supports_opt_cache_interface(alg) -> Bool
Deprecated trait for whether an optimization algorithm supports the init interface.
Use has_init and has_step for new code. This compatibility trait remains for older optimization solver integrations that queried cache support through an optimization-specific name.
The default is false.
SciMLBase.has_init — Function
has_init(a) -> Bool
Trait declaring whether alg supports the caching/iterator interface through init(prob, alg; kwargs...).
Algorithms that return true should provide an init/__init path that constructs an object which can later be advanced or finished with solve!. Returning false means users should call solve directly, or that the package has not exposed a reusable cache for this algorithm. The default is false.
SciMLBase.has_step — Function
has_step(a) -> Bool
Trait declaring whether an initialized object for alg supports direct advancement through step!.
Algorithms that return true should have an init path whose returned iterator or integrator can be advanced by step!. This is stronger than supporting solve!: a cached solver may be finishable with solve! without exposing manual stepping. See the init/solve interface documentation for the solver-side contract. The default is false.
SciMLBase.supports_solve_rng — Function
supports_solve_rng(prob, alg) -> BoolReturn whether the selected problem/algorithm path accepts solve(prob, alg; rng) and uses that RNG to initialize its stochastic state.
Pass alg = nothing to query support for the default solver-selection path (i.e., solve(prob; rng)). The trait is defined on the pair because RNG support can depend on both the problem family and the concrete solver.
Ensemble solvers use a true result to pass an independently seeded RNG to each trajectory. A solver that returns true must consume the supplied RNG rather than silently falling back to global randomness. The conservative default is false.
SciMLBase.alg_order — Function
alg_order(alg)Return the theoretical convergence order of an ODE algorithm.
For fixed-order methods this is the method order. For variable-order or adaptive-order methods, return the maximum order the algorithm can use. Solver packages should override this trait for algorithms where the order is part of the public method contract.
SciMLBase.allowsbounds — Function
allowsbounds(opt)Trait declaring whether an optimization algorithm supports finite box bounds.
Return true when the solver can use the lb and ub fields of an OptimizationProblem. Return false when the solver does not accept bound constraints and callers should reject or ignore nontrivial bounds before dispatching to the solver. This trait describes support for variable bounds, not nonlinear constraints from OptimizationFunction.cons.
The default is false.
SciMLBase.requiresbounds — Function
requiresbounds(opt)Trait declaring whether an optimization algorithm requires box bounds.
Return true when the solver interface is only valid for problems that provide lb and ub bounds. Algorithms that merely support optional bounds should override allowsbounds and keep this trait false.
The default is false.
SciMLBase.allowsconstraints — Function
allowsconstraints(opt)Trait declaring whether an optimization algorithm supports nonlinear constraints.
Return true when the solver can use the cons callback stored in an OptimizationFunction together with lcons and ucons from the OptimizationProblem. This trait does not describe box-bound support; use allowsbounds for lb and ub.
The default is false.
SciMLBase.requiresconstraints — Function
requiresconstraints(opt)Trait declaring whether an optimization algorithm requires nonlinear constraints.
Return true when the solver interface is meaningful only for constrained problems with an OptimizationFunction.cons callback and matching constraint bounds. Algorithms that support both constrained and unconstrained problems should return false.
The default is false.
SciMLBase.requiresgradient — Function
requiresgradient(opt)Trait declaring whether an optimization algorithm requires objective gradients.
Return true when solver setup must obtain a gradient callback for the objective, either supplied manually on OptimizationFunction or generated by the selected AD backend during function instantiation. Algorithms that can run with objective values only should keep the default.
The default is false.
SciMLBase.allowsfg — Function
allowsfg(opt)Trait declaring whether an optimization algorithm can use combined objective and gradient evaluation.
Return true when the solver can consume a callback that computes the objective value and gradient in one evaluation. Function-instantiation code can use this to preserve or generate an efficient fg-style callback instead of separate objective and gradient calls.
The default is false.
SciMLBase.requireshessian — Function
requireshessian(opt)Trait declaring whether an optimization algorithm requires an objective Hessian.
Return true when solver setup must obtain a Hessian callback for the objective, either supplied manually on OptimizationFunction or generated by the selected AD backend. Algorithms that can run without second derivatives should keep the default.
The default is false.
SciMLBase.allowsfgh — Function
allowsfgh(opt)Trait declaring whether an optimization algorithm can use combined objective, gradient, and Hessian evaluation.
Return true when the solver can consume a callback that computes the objective value, gradient, and Hessian in one evaluation. Function-instantiation code can use this to preserve or generate an efficient fgh-style callback.
The default is false.
SciMLBase.requiresconsjac — Function
requiresconsjac(opt)Trait declaring whether an optimization algorithm requires a constraint Jacobian.
Return true when constrained solver setup must obtain cons_j, the Jacobian of OptimizationFunction.cons with respect to the optimization state. The callback may be supplied manually or generated by an AD backend during function instantiation.
The default is false.
SciMLBase.allowsconsjvp — Function
allowsconsjvp(opt)Trait declaring whether an optimization algorithm can use constraint Jacobian-vector products.
Return true when the solver can consume cons_jvp, a callback applying the constraint Jacobian to a vector without materializing the full Jacobian. Algorithms that require the full constraint Jacobian should use requiresconsjac instead.
The default is false.
SciMLBase.allowsconsvjp — Function
allowsconsvjp(opt)Trait declaring whether an optimization algorithm can use constraint vector-Jacobian products.
Return true when the solver can consume cons_vjp, a callback applying the adjoint action of the constraint Jacobian without materializing the full Jacobian.
The default is false.
SciMLBase.requiresconshess — Function
requiresconshess(opt)Trait declaring whether an optimization algorithm requires constraint Hessians.
Return true when constrained solver setup must obtain cons_h, the Hessian information for the nonlinear constraints in OptimizationFunction.cons. Algorithms that instead use the Hessian of the Lagrangian should override requireslagh.
The default is false.
SciMLBase.requireslagh — Function
requireslagh(opt)Trait declaring whether an optimization algorithm requires a Lagrangian Hessian.
Return true when solver setup must obtain lag_h, the Hessian of the Lagrangian combining the objective, constraint multipliers, and any solver scaling arguments expected by the backend. This is distinct from requiring separate objective and constraint Hessians.
The default is false.
SciMLBase.allowscallback — Function
allowscallback(opt)Trait declaring whether an optimization algorithm supports solve callbacks.
Return true when the solver can accept the callback keyword for an OptimizationProblem solve. Return false for solver backends where callbacks cannot be represented or would be silently ignored.
The default is true.
SciMLBase.allows_non_wiener_noise — Function
allows_non_wiener_noise(alg::AbstractSDEAlgorithm)Trait declaring whether an SDE algorithm supports non-Wiener noise processes.
Return true when the algorithm can use an AbstractNoiseProcess that is not a standard Wiener process. Algorithms that rely on Brownian increments, Levy area approximations, or adaptivity assumptions specific to Wiener noise should keep the default.
The default is false.
SciMLBase.requires_additive_noise — Function
requires_additive_noise(alg::AbstractSDEAlgorithm)Trait declaring whether an SDE algorithm requires additive noise.
Return true when the algorithm is valid only for noise functions that do not depend on the state u. Algorithms that support multiplicative noise should keep the default.
The default is false.
SciMLBase.AlgorithmInterpretation — Module
AlgorithmInterpretationStochastic integral interpretation implemented by an SDE algorithm.
The two values are AlgorithmInterpretation.Ito and AlgorithmInterpretation.Stratonovich. For multiplicative noise these interpretations generally define different solutions and different statistics; they coincide for additive noise because the diffusion does not depend on the state.
Concrete SDE algorithms report their interpretation through alg_interpretation. Problem transformations, sensitivity methods, and solver-selection code should query that trait instead of inferring the interpretation from an algorithm name.
SciMLBase.AlgorithmInterpretation.Ito — Constant
AlgorithmInterpretation.ItoItô interpretation, defined by non-anticipating stochastic sums whose diffusion coefficient is evaluated at the left endpoint of each interval.
Itô integrals are adapted to the information available before each noise increment. Nonlinear changes of variables follow Itô's formula and include the quadratic-variation correction term.
SciMLBase.AlgorithmInterpretation.Stratonovich — Constant
AlgorithmInterpretation.StratonovichStratonovich interpretation, defined by symmetric or midpoint stochastic sums.
Stratonovich integrals obey the ordinary chain rule. For multiplicative noise, converting an SDE between Stratonovich and Itô form requires a drift correction; changing only the algorithm interpretation without transforming the drift generally changes the mathematical problem.
SciMLBase.alg_interpretation — Function
alg_interpretation(alg)Return the AlgorithmInterpretation implemented by alg.
Concrete SDE algorithms must return either AlgorithmInterpretation.Ito or AlgorithmInterpretation.Stratonovich. Itô methods approximate non-anticipating left-endpoint stochastic sums, while Stratonovich methods approximate symmetric or midpoint sums. There is deliberately no default for arbitrary SciML algorithms: omitting the trait is an error because silently choosing an interpretation can change the mathematical solution.
Algorithms parameterized by an interpretation should return the selected marker; algorithms with a fixed interpretation should define a method for their concrete type. Downstream code uses this trait for solver selection, drift transformations, and stochastic sensitivity equations. The distinction affects multiplicative noise; additive-noise equations have the same solution under both interpretations.
Abstract SciML Algorithms
SciMLBase.AbstractSciMLAlgorithm — Type
abstract type AbstractSciMLAlgorithmBase interface for solver algorithm objects. A concrete AbstractSciMLAlgorithm selects the numerical method used by solve, init, or lower-level extension methods for an AbstractSciMLProblem.
Interface
Concrete algorithms should be lightweight configuration objects. Solver-specific options belong in the algorithm constructor, while options shared by a whole problem family stay as solve or init keyword arguments. Solver packages normally implement dispatches such as:
CommonSolve.solve(
prob::AbstractSciMLProblem, alg::AbstractSciMLAlgorithm;
kwargs...
)Algorithms should implement the relevant trait methods in alg_traits.jl when their behavior differs from the default, such as adaptivity, supported number types, automatic-differentiation behavior, solver order, stochastic integral interpretation, or support for the caching and stepping interfaces. remake can be used internally by solver packages to replace algorithm components such as automatic-differentiation chunk sizes, but it is not part of the public user API for choosing methods.
SciMLBase.AbstractDEAlgorithm — Type
abstract type AbstractDEAlgorithm <: SciMLBase.AbstractSciMLAlgorithmBase interface for differential equation solver algorithms. Concrete subtypes dispatch on differential equation problem types and should document the equation families, state types, callbacks, events, interpolation, and initialization features they support.
Differential equation algorithms participate in common traits such as isadaptive, isdiscrete, allowscomplex, alg_order, isautodifferentiable, forwarddiffs_model, and allows_late_binding_tstops. The default trait values are conservative, so solver packages should override them for concrete algorithms where appropriate.
SciMLBase.AbstractLinearAlgorithm — Type
abstract type AbstractLinearAlgorithm <: SciMLBase.AbstractSciMLAlgorithmBase interface for linear solve algorithms. Concrete subtypes select methods for AbstractLinearProblem instances, including direct factorizations, iterative methods, preconditioner choices, and matrix-free operator handling.
Algorithm-specific choices such as factorization strategy, Krylov options, or preconditioner configuration should be constructor fields on the concrete algorithm. Shared solve controls remain keyword arguments to the solve call.
SciMLBase.AbstractNonlinearAlgorithm — Type
abstract type AbstractNonlinearAlgorithm <: SciMLBase.AbstractSciMLAlgorithmBase interface for nonlinear solve algorithms. Concrete subtypes select methods for AbstractNonlinearProblem instances and should document their support for in-place residuals, Jacobian information, bounds, line searches, trust regions, termination controls, and reusable caches.
SciMLBase.AbstractIntervalNonlinearAlgorithm — Type
abstract type AbstractIntervalNonlinearAlgorithm <: SciMLBase.AbstractSciMLAlgorithmBase interface for interval nonlinear solve algorithms. Concrete subtypes solve AbstractIntervalNonlinearProblem instances by searching for zeros over a provided interval, commonly using bracketing or interval-based methods.
Concrete algorithms should document whether they require a sign change, how they handle array-valued residuals, and which termination tolerances or bracketing assumptions they use.
SciMLBase.AbstractIntegralAlgorithm — Type
abstract type AbstractIntegralAlgorithm <: SciMLBase.AbstractSciMLAlgorithmBase interface for integral and quadrature algorithms. Concrete subtypes solve AbstractIntegralProblem instances and should document their domain support, adaptive or fixed-sample behavior, batching semantics, random number usage, and whether in-place integrands are supported.
SciMLBase.AbstractOptimizationAlgorithm — Type
abstract type AbstractOptimizationAlgorithm <: SciMLBase.AbstractDEAlgorithmBase interface for optimization algorithms. Concrete subtypes solve AbstractOptimizationProblem instances and should document their support for bounds, nonlinear constraints, callbacks, gradients, Hessians, constraint Jacobians, and reusable caches.
Optimization solver packages should override the optimization capability traits in alg_traits.jl, such as allowsbounds, requiresgradient, allowsfg, allowsfgh, allowsconstraints, and allowscallback, when the defaults do not describe a concrete algorithm.
SciMLBase.AbstractSteadyStateAlgorithm — Type
abstract type AbstractSteadyStateAlgorithm <: SciMLBase.AbstractDEAlgorithmBase interface for steady-state algorithms. Concrete subtypes solve AbstractSteadyStateProblem instances, usually by reusing ODE time-stepping, nonlinear solve, or specialized fixed-point machinery to find du/dt = 0.
Concrete algorithms should document whether they expect an ODE-style inner algorithm, a nonlinear solver, or a direct steady-state method, and how common termination tolerances are interpreted.
SciMLBase.AbstractBVPAlgorithm — Type
abstract type AbstractBVPAlgorithm <: SciMLBase.AbstractDEAlgorithmBase interface for boundary value problem algorithms. Concrete subtypes solve AbstractBVProblem instances and should document their collocation, shooting, mesh-adaptation, nonlinear-solver, and boundary-residual layout assumptions.
SciMLBase.AbstractODEAlgorithm — Type
abstract type AbstractODEAlgorithm <: SciMLBase.AbstractDEAlgorithmBase interface for ordinary differential equation algorithms. Concrete subtypes solve AbstractODEProblem instances and should document their order, adaptivity, stiffness assumptions, dense-output support, callback/event support, and compatibility with mass matrices or split problem formulations.
SciMLBase.AbstractSecondOrderODEAlgorithm — Type
abstract type AbstractSecondOrderODEAlgorithm <: SciMLBase.AbstractDEAlgorithmBase interface for algorithms that preserve second-order ODE structure. Concrete subtypes should document whether they operate on a native second-order formulation or on a first-order transformed problem, and which callback, interpolation, and mass-matrix features remain available.
SciMLBase.AbstractRODEAlgorithm — Type
abstract type AbstractRODEAlgorithm <: SciMLBase.AbstractDEAlgorithmBase interface for random ordinary differential equation algorithms. Concrete subtypes solve AbstractRODEProblem instances and should document the noise process assumptions, interpolation behavior, and how random forcing is sampled or queried during a step.
SciMLBase.AbstractSDEAlgorithm — Type
abstract type AbstractSDEAlgorithm <: SciMLBase.AbstractDEAlgorithmBase interface for stochastic differential equation algorithms. Concrete subtypes solve AbstractSDEProblem instances and should document their stochastic integral interpretation, supported noise structures, adaptive behavior and any restrictions such as additive-noise or Wiener-only assumptions.
SDE algorithms should override alg_interpretation, and may need to override allows_non_wiener_noise or requires_additive_noise.
SciMLBase.AbstractDAEAlgorithm — Type
abstract type AbstractDAEAlgorithm <: SciMLBase.AbstractDEAlgorithmBase interface for differential-algebraic equation algorithms. Concrete subtypes solve AbstractDAEProblem instances and should document their DAE index assumptions, mass-matrix or residual form, consistent-initial-condition handling, and supported DAEInitializationAlgorithm choices.
SciMLBase.AbstractDDEAlgorithm — Type
abstract type AbstractDDEAlgorithm <: SciMLBase.AbstractDEAlgorithmBase interface for delay differential equation algorithms. Concrete subtypes solve AbstractDDEProblem instances and should document their lag support, history interpolation, discontinuity handling, and callback/event behavior.
SciMLBase.AbstractSDDEAlgorithm — Type
abstract type AbstractSDDEAlgorithm <: SciMLBase.AbstractDEAlgorithmBase interface for stochastic delay differential equation algorithms. Concrete subtypes combine the delay and stochastic algorithm contracts, including support for lag metadata, history interpolation, noise structures, stochastic integral interpretation, and discontinuity handling.
SciMLBase.EnsembleAlgorithm — Type
abstract type EnsembleAlgorithm <: SciMLBase.AbstractSciMLAlgorithmBase interface for ensemble execution algorithms. These algorithms choose how many related problem solves are scheduled for an AbstractEnsembleProblem; they do not choose the numerical method for an individual trajectory.
Concrete subtypes should document the execution backend, serialization requirements, random number behavior, task or process scheduling, and any limitations on callbacks, reductions, or output functions.
SciMLBase.DAEInitializationAlgorithm — Type
abstract type DAEInitializationAlgorithm <: SciMLBase.AbstractSciMLAlgorithmBase interface for DAE initialization algorithms selected by the initializealg keyword. Concrete subtypes control how solvers check, skip, or repair initial conditions before integration starts.
Solver packages implement initialization by passing these algorithms to get_initial_values. That hook returns (u0, p, success), where u0 and p are the state and parameter objects that should be used for the initialized problem. Concrete algorithms should document which problem metadata they require, whether they leave current values unchanged or solve an auxiliary problem, and which tolerances or inner nonlinear solvers they use.
SciMLBase.AbstractDiscretization — Type
abstract type AbstractDiscretization <: SciMLBase.AbstractSciMLAlgorithmOptional common base for discretization algorithms. Packages participate in the discretization interface by extending discretize and optionally symbolic_discretize for the high-level representation and algorithm types they support. A package may instead subtype a more specific public algorithm hierarchy that it owns; subtyping AbstractDiscretization is not required to extend those functions.
Concrete discretizations should document the input problem or system types they accept, the numerical discretization they apply, the generated problem type, and the metadata needed to map the numerical solution back to the original variables and domains.
SciMLBase.AbstractDiscretizationMetadata — Type
abstract type AbstractDiscretizationMetadata{hasTime}Base interface for metadata produced by a discretization. The hasTime type parameter records whether the wrapped solution has an independent time axis. Use Val(true) for time-dependent PDE solution wrappers and Val(false) for time-independent wrappers; this value parameter is what wrap_sol uses to choose between PDETimeSeriesSolution and PDENoTimeSolution.
Concrete metadata types should store enough information for PDE solution wrappers to recover the original variables, domains, dependent-variable layout, and the solver-ready problem or solution generated by the discretizer.
DAE Initialization Algorithms
SciMLBase.NoInit — Type
struct NoInit <: DAEInitializationAlgorithmAn initialization algorithm that skips consistency checks and auxiliary initialization solves.
get_initial_values(prob, value_provider, f, NoInit(), isinplace) returns (state_values(value_provider), parameter_values(value_provider), true). It does not inspect residuals, does not mutate u0, du0, or p, and does not require tolerances or nonlinear solver algorithms.
SciMLBase.CheckInit — Type
struct CheckInit <: DAEInitializationAlgorithmAn initialization algorithm that verifies the current values without attempting to repair them.
get_initial_values methods for CheckInit require the keyword abstol. For mass-matrix differential problems, only algebraic equations are checked. For DAE problems, the full DAE residual is checked. Residual norms use integrator.opts.internalnorm when available and LinearAlgebra.norm otherwise.
If the residual norm is at most abstol, the current state_values(integrator) and parameter_values(integrator) are returned with success == true. If the residual norm is larger than abstol, a CheckInitFailureError is thrown. CheckInit never changes the current state, derivative state, or parameters.
SciMLBase.OverrideInit — Type
struct OverrideInit <: DAEInitializationAlgorithmAn initialization algorithm that uses initialization metadata stored on a SciMLFunction to compute replacement state and parameter values.
When f has non-nothingOverrideInitData, get_initial_values updates the stored initialization problem from the current value provider, solves it when it is nontrivial, and maps the initialization result back to the original problem's u0 and p. If f has no initialization data, OverrideInit is a successful no-op and returns the current state and parameters.
Nontrivial initialization problems require abstol and reltol; values stored in the OverrideInit object take priority over keywords passed to get_initial_values. A nonlinear solver algorithm can be supplied either as OverrideInit(; nlsolve = alg) or as the nlsolve_alg keyword to get_initial_values, with the call keyword taking priority. Additional keywords are forwarded to the inner solve.
Trivial initialization problems are not solved and therefore do not require nlsolve_alg, abstol, or reltol; their mapping hooks are applied directly. For nonlinear least-squares initialization, success requires both a successful solver return code and a final residual norm no larger than abstol.
Fields
abstol: Default absolute tolerance for the initialization solver.reltol: Default relative tolerance for the initialization solver.nlsolve: Default nonlinear solver algorithm for initialization.