The SciML init and solve Functions

__init(prob, alg, args...; kwargs...)

The low-level entry point that CommonSolve.init forwards to after performing the common pre-init handling (such as argument checking and high-level error messages). Solver packages add methods to SciMLBase.__init dispatched on their problem and algorithm types, returning the iterator/integrator object used by solve!; this is the documented extension hook for implementing a solver. Defining __init rather than init directly allows SciMLBase.init to keep a common implementation across all solvers.

Implementations should construct and return the mutable cache, iterator, or integrator object associated with the solver. That object should support solve! and, when the corresponding algorithm trait returns true, direct stepping through step!. Solver packages should keep __init keyword handling consistent with __solve so that solve(prob, alg; kwargs...) and solve!(init(prob, alg; kwargs...)) agree when both paths are supported.

See also __solve, which implements the direct solve path.

__solve(prob, alg, args...; kwargs...)

The low-level entry point that CommonSolve.solve forwards to after performing the common pre-solve handling (such as argument checking and high-level error messages). Solver packages add methods to SciMLBase.__solve dispatched on their problem and algorithm types; this is the documented extension hook for implementing a solver. Defining __solve rather than solve directly allows SciMLBase.solve to keep a common implementation across all solvers.

Implementations should accept the same positional and keyword arguments that the public solve method for the package accepts after prob and alg. They should return the package's solution object and are responsible for honoring common SciML keywords that apply to the problem family. Solver packages should dispatch on concrete problem and algorithm types that they own, or on documented abstract interfaces when that is the intended solver extension point, to avoid method ambiguity with other packages.

See also __init, which implements the reusable cache/iterator path.

abstract type DEIntegrator{Alg, IIP, U, T}

Base interface for differential equation integrators returned by init. Integrators are mutable iterator-like solver states that can be advanced by step!, finished by solve!, inspected or modified by callbacks, and reinitialized when the concrete solver supports it.

The type parameters record the algorithm type Alg, the in-place/out-of-place function convention IIP, the state type U, and the independent-variable type T. Concrete integrators commonly expose fields such as u, t, p, f, alg, opts, and sol, and should implement the relevant methods from the integrator interface: stepping, cache access, state/time mutation, saving, symbolic indexing, error checking, and optional RNG/reinitialization support.

abstract type AbstractSteadyStateIntegrator{Alg, IIP, U} <: SciMLBase.DEIntegrator{Alg, IIP, U, Nothing}

Base interface for steady-state integrators. These are returned by steady-state init methods when the solver supports an iterator or cache interface for finding an equilibrium.

Concrete subtypes follow the DEIntegrator conventions, but their independent variable type is Nothing because the solve target is a terminal steady state rather than a time series.

abstract type AbstractODEIntegrator{Alg, IIP, U, T} <: SciMLBase.DEIntegrator{Alg, IIP, U, T}

Base interface for ODE integrators. Concrete subtypes advance an AbstractODEProblem with an AbstractODEAlgorithm and should implement the standard differential equation integrator operations for stepping, interpolation, callback handling, saving, and cache access.

abstract type AbstractSecondOrderODEIntegrator{Alg, IIP, U, T} <: SciMLBase.DEIntegrator{Alg, IIP, U, T}

Base interface for second-order ODE integrators. Concrete subtypes preserve, or wrap, second-order problem structure while following the standard DEIntegrator stepping, callback, saving, and cache contracts.

abstract type AbstractSDEIntegrator{Alg, IIP, U, T} <: SciMLBase.DEIntegrator{Alg, IIP, U, T}

Base interface for SDE integrators. Concrete subtypes advance stochastic differential equation problems and should implement the standard integrator operations plus any RNG, noise-cache, stochastic-interpolation, and noise-process access required by the solver.

abstract type AbstractRODEIntegrator{Alg, IIP, U, T} <: SciMLBase.DEIntegrator{Alg, IIP, U, T}

Base interface for RODE integrators. Concrete subtypes advance random ordinary differential equation problems and should document how they expose or update the noise process during stepping and interpolation.

abstract type AbstractDDEIntegrator{Alg, IIP, U, T} <: SciMLBase.DEIntegrator{Alg, IIP, U, T}

Base interface for DDE integrators. Concrete subtypes advance delay differential equation problems and should document their history interpolation, lag handling, discontinuity tracking, callback behavior, and cache access.

abstract type AbstractDAEIntegrator{Alg, IIP, U, T} <: SciMLBase.DEIntegrator{Alg, IIP, U, T}

Base interface for DAE integrators. Concrete subtypes advance differential- algebraic equation problems and should document their residual form, derivative state handling, initialization behavior, algebraic consistency checks, and callback reinitialization support.

abstract type AbstractSDDEIntegrator{Alg, IIP, U, T} <: SciMLBase.DEIntegrator{Alg, IIP, U, T}

Base interface for SDDE integrators. Concrete subtypes combine the stochastic and delay integrator contracts, including RNG/noise handling, history interpolation, lag metadata, discontinuity tracking, and callback behavior.

abstract type DECache

Base interface for solver caches used by differential equation integrators. Concrete caches hold reusable arrays, factorizations, random increments, temporary workspaces, or other mutable state needed across steps.

Solver packages should keep cache fields internal to the concrete integrator and expose only the public cache accessors that are safe for users or callbacks, such as get_tmp_cache, user_cache, full_cache, and the state-specific cache helpers.

step!(integ::DEIntegrator [, dt [, stop_at_tdt]])

Advance a differential equation integrator.

With one argument, perform one accepted solver step according to the concrete algorithm. With dt, repeatedly step until the signed time displacement from the starting time is at least dt. When stop_at_tdt is true, the generic fallback adds a temporary tstop so the integrator lands exactly at t + dt. Negative stepping relative to integ.tdir is rejected by the fallback.

symbolic_interpolation(integrator::DEIntegrator, t, idxs, deriv = Val{0})

Evaluate idxs on the interpolant of integrator's current step at time(s) t.

idxs is resolved through SymbolicIndexingInterface, so observed equations and other symbolic expressions give the same values here that they do when indexing a solution with sol(t; idxs). t may be a number or a collection of numbers; a collection returns a DiffEqArray over those times.

Solver packages should route integrator(t; idxs) here when idxs is symbolic. Raw dense-output interpolants only accept integer component indices, so they cannot resolve quantities that are not stored in the state vector.

has_symbolic_idxs(idxs)

Return whether idxs names quantities symbolically rather than by position in the state vector.

Solver packages use this to decide whether integrator(t; idxs) has to go through symbolic_interpolation. A raw dense-output interpolant only accepts integer component indices, so it cannot resolve a symbolic index, which may name an observed equation that is not stored in the state vector at all.

resize!(integrator::DEIntegrator, k::Int)

Resize the state dimension of an integrator to length k.

Concrete integrators that support dynamic state sizes should resize u, saved state caches, user-facing caches, and any algorithm-specific non-user caches so future steps see a consistent state layout. Shrinking removes trailing state entries; growing appends solver-defined blank/default values.

deleteat!(integrator::DEIntegrator, idxs)

Delete state components from a dynamic-size integrator.

Implementations should remove the selected entries from integrator.u, saved state caches, and any dependent non-user caches. Symbolic indexing metadata is assumed to remain valid only when the concrete solver documents support for dynamic state selection.

addat!(integrator::DEIntegrator, idxs, val)

Insert state components into a dynamic-size integrator.

idxs must describe contiguous positions. Implementations should insert val or solver-defined defaults into integrator.u, saved state caches, and any dependent non-user caches so subsequent stepping uses the new state dimension.

get_tmp_cache(i::DEIntegrator)

Return temporary work arrays owned by the integrator.

The returned tuple is intended for callbacks and integrator-interface code that needs non-allocating scratch storage. Callers may mutate these arrays during the current operation, but must not store them for later use or assume a fixed tuple length across algorithms.

user_cache(integrator::DEIntegrator)

Return user-accessible cache components from the integrator.

These arrays are documented by the concrete solver as safe for user or callback mutation. They are distinct from temporary caches whose contents may be overwritten by the next integrator operation.

u_cache(integrator::DEIntegrator)

Return state-like cache arrays used by the integrator.

Concrete solvers use these arrays for stage values, interpolation data, or other intermediate state storage. Generic resizing and callback code may use this interface when it needs to keep state-shaped caches consistent with u.

du_cache(integrator::DEIntegrator)

Return derivative-like cache arrays used by the integrator.

These arrays store intermediate derivatives, residuals, or rate values whose shape follows the state. Concrete solvers should document whether users may mutate them directly or should treat them as internal storage.

ratenoise_cache(integrator::DEIntegrator)

Return an iterable of state-shaped rate-noise caches owned by a stochastic integrator.

Generic resizing operations use this collection to keep noise-rate workspaces aligned with integrator.u. The returned arrays are solver-owned mutable scratch storage; users should not retain or modify them independently of the integrator. Deterministic integrators and stochastic methods without such caches use the default empty tuple.

rand_cache(integrator::DEIntegrator)

Return an iterable of state-shaped random-increment caches owned by a stochastic integrator.

Generic resizing operations use this collection when random workspaces follow the state shape, notably for diagonal-noise methods. The returned arrays are solver-owned mutable scratch storage; they are not random-number generators and should not be retained or modified independently of the integrator. Integrators without such caches use the default empty tuple.

full_cache(i::DEIntegrator)

Return an iterator over all state-sized cache arrays managed by the method.

full_cache is the broad cache interface used by generic resizing, adaptation, and callback utilities that need to keep every state-shaped cache synchronized. Concrete solvers should include user and non-user caches whose leading state dimension must track integrator.u.

resize_non_user_cache!(integrator::DEIntegrator, k::Int)

Resizes the non-user facing caches to be compatible with a DE of size k. This includes resizing Jacobian caches.

deleteat_non_user_cache!(integrator::DEIntegrator, idxs)

deleteat!s the non-user facing caches at indices idxs. This includes resizing Jacobian caches.

addat_non_user_cache!(i::DEIntegrator, idxs)

addat!s the non-user facing caches at indices idxs. This includes resizing Jacobian caches.

terminate!(i::DEIntegrator[, retcode = :Terminated])

Terminates the integrator by emptying tstops. This can be used in events and callbacks to immediately end the solution process. Optionally, retcode may be specified (see: Return Codes (RetCodes)).

add_tstop!(i::DEIntegrator, t)

Schedule a future stopping time at the physical time t.

An integrator must not accept a stop behind its current time in the direction of integration. A tstop constrains stepping so the integrator reaches t exactly when the method supports step-size changes or interpolation. It does not by itself request that the solution be saved there; use add_saveat! or the solver's saving options for output.

Implementations commonly store tstops as direction-normalized priority keys integrator.tdir * t. The companion queue accessors expose those keys so generic stepping code can compare them with integrator.tdir * integrator.t in both forward and reverse integration.

has_tstop(i::DEIntegrator)

Return whether the integrator has any pending stopping times.

This query must be consistent with first_tstop and pop_tstop!: when it returns false, neither queue accessor may be called until another stop is added.

first_tstop(i::DEIntegrator)

Return the next pending stopping-time key without removing it.

Stopping times are ordered in the direction of integration. The returned value is direction-normalized as integrator.tdir * tstop, matching the queue key used by generic solver and callback code. Recover the physical time as integrator.tdir * first_tstop(integrator) when integrator.tdir is 1 or -1. Calling this on an empty queue is invalid; check has_tstop first.

pop_tstop!(i::DEIntegrator)

Remove and return the next pending stopping-time key.

The value and ordering follow first_tstop: this removes the earliest stop in the direction of integration, not the most recently inserted stop, and returns its direction-normalized queue key. Calling this on an empty queue is invalid; check has_tstop first.

add_saveat!(i::DEIntegrator, t)

Schedule solution output at the future physical time t.

An integrator must not accept a save point behind its current time in the direction of integration. saveat normally uses interpolation when t lies inside a step and therefore does not force the integrator to step exactly to t. Add a matching add_tstop! when an exact step endpoint is also required. Saving still follows the solver's save_on, save_idxs, and related output options.

get_du(i::DEIntegrator)

Return the derivative represented by the integrator at its current (u, p, t).

An implementation may return an internal derivative cache or evaluate the problem function when no valid cache exists. Treat the returned value as read-only because mutating an aliased cache can corrupt later steps. Use get_du! when caller-owned output storage is required.

This operation is optional when a derivative is not meaningful or available. For example, discrete steppers have no continuous derivative, and some DAE integrators cannot provide one before their first initialized step. Direct changes to u, p, or t must be reported through the integrator mutation interface so a cached derivative is refreshed before it is queried.

get_du!(out, i::DEIntegrator)

Write the derivative represented by the integrator at its current (u, p, t) into caller-owned out.

out must have a shape and element type compatible with the derivative. An implementation may copy a valid internal cache or evaluate the problem function directly. Use the contents of out after the call; concrete methods are not required to return out. The same derivative-availability restrictions as get_du apply.

get_dt(i::DEIntegrator)

Return the integrator's active step-size increment.

This is the signed increment associated with the current or most recently attempted step, according to the concrete solver. It can differ from get_proposed_dt, which reports the controller's proposal for the next step. Concrete integrators that do not expose an active step size may leave this optional hook unimplemented.

get_proposed_dt(i::DEIntegrator)

Return the signed step-size increment currently proposed for the next step.

For adaptive methods this is the controller proposal. For fixed-step methods it is normally the configured step size. The actual next step may be shortened to land on a tstop, rejected and retried, or otherwise adjusted by the solver, so this value is a proposal rather than a promise about the next accepted time.

set_proposed_dt!(i::DEIntegrator, dt)
set_proposed_dt!(i::DEIntegrator, i2::DEIntegrator)

Set the signed step-size proposal used for the next step.

The scalar form updates every step-size field that the concrete solver requires to honor a new proposal. It does not bypass error control, rejection, or tstop handling, and therefore does not guarantee that the next accepted step has exactly that size.

The two-integrator form synchronizes the first integrator's time-stepping state with the second. Adaptive implementations should copy the controller history or other state needed to reproduce the proposal, rather than only copying one dt field. This form is optional for integrators that cannot share compatible controller state.

set_abstol!(i::DEIntegrator, abstol)

Update the absolute error tolerance used by subsequent adaptive steps.

Concrete implementations must refresh any controller or scaling state derived from the old tolerance. The accepted scalar or array tolerance shapes follow the solver's abstol option. Integrators that do not support changing tolerances at runtime may leave this optional hook unimplemented.

set_reltol!(i::DEIntegrator, reltol)

Update the relative error tolerance used by subsequent adaptive steps.

Concrete implementations must refresh any controller or scaling state derived from the old tolerance. The accepted scalar or array tolerance shapes follow the solver's reltol option. Integrators that do not support changing tolerances at runtime may leave this optional hook unimplemented.

derivative_discontinuity!(i::DEIntegrator, bool)

Record whether a callback or direct integrator mutation introduced a derivative discontinuity.

The flag describes whether f(u, p, t) may have changed discontinuously because u, p, t, or the definition of f changed. Solvers use this to decide whether to recompute derivatives, interpolation data, FSAL caches, or Jacobians before the next step. Callback code should leave the default discontinuity behavior in place after state-changing effects, and may call derivative_discontinuity!(integrator, false) only when it did not change the state, parameters, time, or dynamics.

u_modified!(integrator, modified)

Deprecated alias for derivative_discontinuity!. Replace calls with derivative_discontinuity!(integrator, modified); this alias is retained only for migration of older callback and integrator code.

savevalues!(
        integrator::DEIntegrator,
        force_save = false
    ) -> Tuple{Bool, Bool}

Try to save the state and time variables at the current time point, or the saveat point by using interpolation when appropriate. It returns a tuple that is (saved, savedexactly). If savevalues! saved value, then saved is true, and if savevalues! saved at the current time point, then savedexactly is true.

The saving priority/order is as follows:

• save_on

  • saveat
  • force_save
  • save_everystep

reinit!(integrator::DEIntegrator, args...; kwargs...)

The reinit function lets you restart the integration at a new value.

Arguments

• u0: Value of u to start at. Default value is integrator.sol.prob.u0

Keyword Arguments

• t0: Starting timepoint. Default value is integrator.sol.prob.tspan[1]
• tf: Ending timepoint. Default value is integrator.sol.prob.tspan[2]
• erase_sol=true: Whether to start with no other values in the solution, or keep the previous solution.
• tstops, d_discontinuities, & saveat: Cache where these are stored. Default is the original cache.
• reset_dt: Set whether to reset the current value of dt using the automatic dt determination algorithm. Default is (integrator.dtcache == zero(integrator.dt)) && integrator.opts.adaptive
• reinit_callbacks: Set whether to run the callback initializations again (and initialize_save is for that). Default is true.
• reinit_cache: Set whether to re-run the cache initialization function (i.e. resetting FSAL, not allocating vectors) which should usually be true for correctness. Default is true.

Additionally, once can access auto_dt_reset! which will run the auto dt initialization algorithm.

auto_dt_reset!(integrator::DEIntegrator)

Recompute the integrator's initial step size from its current state.

Concrete solvers should apply the same automatic step-size selection used during init, including the current state, time, parameters, tolerances, integration direction, and method-specific limits. They must update the active step size and any proposal state needed by the next step. This operation may evaluate the problem function and increment solver statistics. Its return value is not part of the interface.

change_t_via_interpolation!(
    integrator::DEIntegrator, t,
    modify_save_endpoint = Val{false}, reinitialize_alg = nothing
)

Move the integrator to time t using the method's local interpolation.

Concrete solvers should update integrator.t, integrator.u, interpolation state, and any dependent caches consistently. If the current endpoint has already been saved, modify_save_endpoint controls whether the saved endpoint in integrator.sol is rewritten as well. reinitialize_alg is available for methods that must rerun initialization after the time/state change.

addsteps!(integrator::DEIntegrator, args...)

Materialize any lazy stage or derivative data required to interpolate the integrator's current step.

Interpolation and callback code calls this hook before requesting off-grid values. Concrete solvers with lazy dense output should populate their interpolation caches idempotently; solvers whose interpolation needs no extra data use the default no-op. The optional arguments are solver-specific controls for cache construction and are not a portable user interface.

reeval_internals_due_to_modification!(
    integrator::DEIntegrator, continuous_modification::Bool = true;
    callback_initializealg = nothing
)

Update an integrator after callback-driven mutation.

For DAEs, callback effects may require re-solving algebraic variables to restore consistency. If continuous_modification is true, solvers should also refresh interpolation data because the mutation can affect the current continuous segment. For discrete-only modifications, solvers may skip interpolation recalculation when their method permits it.

Arguments

• continuous_modification: determines whether the modification is due to a continuous change (continuous callback) or a discrete callback. For a continuous change, this can include a change to time which requires a re-evaluation of the interpolations.
• callback_initializealg: the initialization algorithm provided by the callback. For DAEs, this is the choice for the initialization that is done post callback. The default value of nothing means that the initialization choice used for the DAE should be performed post-callback.

set_t!(integrator::DEIntegrator, t)

Set the current time of integrator to t.

set_t! is the direct time-mutation hook used by callbacks and generic integrator utilities. It changes the independent variable without implying that the state should be interpolated to the new time.

Interface rules

• Implementations must keep integrator.t, method-specific time caches, and any time-dependent controller state consistent with the new time.
• set_t! should not change integrator.u except for solver-specific bookkeeping required to keep an already-mutated state valid.
• Use change_t_via_interpolation! when moving to t should also recompute u from the method's interpolation.
• If changing time invalidates interpolation, error estimates, or dense output caches, the implementation must refresh them or require callers to follow with reeval_internals_due_to_modification!.

set_u!(integrator::DEIntegrator, u)
set_u!(integrator::DEIntegrator, sym, val)

Set the current state of integrator.

The two-argument form replaces the full state and must be implemented by concrete integrators that support direct state mutation. The three-argument form is the generic symbolic-state update path: it verifies that sym is a state variable, writes val into integrator.u, and marks a derivative discontinuity. Parameter updates should use integrator.ps[sym] or SymbolicIndexingInterface parameter setters instead of set_u!.

Interface rules

• Full-state updates must keep integrator.u and any solver-owned state caches that mirror u consistent.
• Symbolic updates are only for state variables. They must reject parameters and unknown symbols rather than silently adding new state.
• State mutation is treated as a derivative discontinuity because cached derivatives, interpolation data, and step controllers may no longer describe the current state.
• Solvers that need additional work after a state change should implement reeval_internals_due_to_modification! and document when callbacks or generic code must call it.

set_ut!(integrator::DEIntegrator, u, t)

Set the current state and time of integrator.

The fallback calls set_u! and then set_t!, so concrete integrators can specialize either lower-level mutation hook or overload set_ut! directly when state/time changes must be applied atomically.

Interface rules

• set_ut! is the preferred hook when a callback or initialization routine changes state and time together.
• The default ordering is state first, then time. Integrators whose caches require a different ordering must overload set_ut!.
• After returning, state_values(integrator) and current_time(integrator) should observe the updated u and t.

get_sol(integrator::DEIntegrator)

Return the solution object contained in integrator.

This is the public accessor for solver and generic-interface code that needs the live solution accumulator during integration. For example, delayed symbolic states may evaluate the current history through get_sol(integrator) instead of reaching into integrator.sol directly.

Interface rules

• The returned object is the integrator's current solution storage, not a defensive copy.
• Solver implementations may update this object as stepping, saving, and callback handling proceed.
• Code that only needs the final solve result should use solve/solve! rather than relying on get_sol during integration.

check_error(integrator)

Inspect integrator and return the ReturnCode that describes whether integration may continue.

The common implementation preserves an existing terminal return code and checks for a NaN step size, iteration limits, a step size at or below dtmin, a user-supplied instability predicate, and failed nonlinear steps. It does not mutate integrator.sol.retcode; use check_error! when the solution must be updated. Concrete integrators may specialize the checks while preserving the return-code contract.

Diagnostics for detected failures are emitted through report_integrator_failure, which the solver stack implements; this function only performs detection.

check_error!(integrator)

Run check_error, store the resulting code in integrator.sol.retcode, and return that code.

When the code is not ReturnCode.Success, the common implementation also calls the solver's postamble! hook so pending bookkeeping and finalization are performed before the solve exits. A successful check updates the return code but does not finalize the integrator.

report_integrator_failure(integrator, ::Val{reason})

Report a failure mode detected,called immediately before the corresponding return code is returned. reason is one of :dt_NaN, :max_iters, :dt_min_unstable, :dt_epsilon, :instability or :newton_convergence.

check_error only detects failures; describing them belongs to the solver stack, which owns both the wording and the verbosity settings that gate it. DiffEqBase.jl implements this for DEIntegrators. The default is a no-op, so a stack that does not implement it still gets correct return codes, just no diagnostics.

Implementations must not affect control flow and their return value is ignored. A reason configured at SciMLLogging.ErrorLevel throws instead of returning, which is the intended behaviour of that level.

initialize_dae!(integrator::DEIntegrator, initializealg = integrator.initializealg)

Runs the DAE initialization to find a consistent state vector. The optional argument initializealg can be used to specify a different initialization algorithm to use.

has_reinit(i::DEIntegrator)

Return whether i supports reinitialization through reinit!.

Generic code should query this trait before attempting to reuse an initialized solver object. A true result guarantees support for restarting from a new initial state and integration interval through the concrete integrator's documented reinit! method. Supported optional keywords can still vary by problem family. The default is false.

has_rng(integrator::DEIntegrator) -> Bool

Return whether integrator supports the live RNG interface formed by get_rng and set_rng!.

An integrator that returns true must carry a valid AbstractRNG for its whole lifetime, using Random.default_rng() when the solver supports the interface but the caller supplied no RNG. Generic code must query this trait before accessing or replacing the RNG. The default is false.

get_rng(integrator::DEIntegrator) -> AbstractRNG

Return the live random number generator used for future stochastic work by the integrator.

The returned object is not a copy: advancing or reseeding it changes the random stream used by subsequent steps. Call has_rng first in generic code. The fallback throws when the concrete integrator does not support RNG access.

set_rng!(integrator::DEIntegrator, rng) -> nothing

Replace the random number generator used for future stochastic work by the integrator.

Concrete integrators commonly require rng to have the same concrete type as the existing generator because that type is part of the integrator or noise process representation. Implementations must update every live reference used by the integrator and its noise process. Call has_rng first in generic code; the fallback throws for unsupported integrators.

This is needed for RNG types that don't support Random.seed!, such as counter-based RNGs (Random123.jl's Philox, Threefry) which are configured via (key, counter) pairs rather than a single seed. For these types, reseeding requires constructing a new instance and swapping it in.

For RNGs that support Random.seed!, reseeding the object returned by get_rng is usually sufficient. set_rng! is needed when reseeding requires constructing a replacement instance.

done(integrator) -> Bool

Return whether a differential-equation integrator has finished iteration. Solver packages may specialize this hook for their DEIntegrator subtype when their termination protocol differs from the common return-code and time-stop logic. A specialization must ensure postamble! has finalized the integrator before it reports a completed solve.

Example

function SciMLBase.done(integrator::MyIntegrator)
    integrator.finished || return false
    SciMLBase.postamble!(integrator)
    return true
end

postamble!(integrator)

Finalize a differential-equation integrator after its solve loop terminates. Solver packages specialize this hook to perform final bookkeeping that must run on normal completion and on an error return. The default generic function has no method; an integrator implementation that requires finalization must provide one.

Example

function SciMLBase.postamble!(integrator::MyIntegrator)
    flush_pending_save!(integrator)
    return nothing
end

struct OverrideInitData{IProb, UIProb, IProbMap, IProbPmap, M, OOP<:Union{Val{true}, Val{false}}}

Solver-author metadata for override-based initialization.

OverrideInitData is stored on SciMLFunction wrappers in the initialization_data field. When get_initial_values is called with OverrideInit, SciMLBase optionally updates initializeprob from the current value provider, solves that initialization problem, then maps the initialization solution back to the original problem's state and parameter objects.

The initialization problem must be a nonlinear-style SciML problem accepted by the constructor below, such as NonlinearProblem, NonlinearLeastSquaresProblem, SCCNonlinearProblem, ImmutableNonlinearProblem, or HomotopyProblem. If the initialization problem is trivial, for example a nonlinear problem with no initial unknowns, no nonlinear solver algorithm or tolerances are required and the mapping hooks are applied directly.

Fields

• initializeprob::Any: Nonlinear-style SciML problem solved, or directly evaluated for trivial initialization, to produce initialization values.

• update_initializeprob!::Any: Optional callable that synchronizes initializeprob with the current value provider before solving. It is called as update_initializeprob!(initializeprob, value_provider).

  If is_update_oop === Val(false), the callable is expected to mutate initializeprob. If is_update_oop === Val(true), it must return the updated initialization problem. If this field is nothing, the stored initializeprob is used as-is.

• initializeprobmap::Any: Optional callable that maps the solution of initializeprob to the state object of the original problem. It is called as initializeprobmap(nlsol). If this field is nothing, the existing state from the value provider is retained.

• initializeprobpmap::Any: Optional callable that maps the solution of initializeprob to the parameter object of the original problem. It is called as initializeprobpmap(value_provider, nlsol). If this field is nothing, the existing parameter object from the value provider is retained.

• metadata::Any: Additional metadata owned by the package that created the initialization problem.

• is_update_oop::Union{Val{true}, Val{false}}: Flag declaring whether update_initializeprob! mutates initializeprob or returns an updated problem. Use Val(false) for in-place updates and Val(true) for out-of-place updates.

get_initial_values(prob, valp, f, alg, isinplace; kwargs...)

Return (u0, p, success) for the requested initialization algorithm.

Solver packages call this hook when an initialized problem or integrator needs consistent initial state and parameter values before stepping or solving. prob is used for dispatch and problem-family-specific checks. valp is the current non-timeseries value provider, usually a problem or integrator, from which state_values, parameter_values, and current_time can be read. f is the SciMLFunction associated with prob, alg is the initialization algorithm, and isinplace is Val(true) when the value provider and SciMLFunction follow the in-place convention.

Methods must return the initialized state object, the initialized parameter object, and a boolean indicating whether initialization succeeded. Keyword arguments are algorithm-specific: CheckInit requires an abstol for residual checks, while OverrideInit can require a NonlinearSolve algorithm and tolerances unless the stored OverrideInitData represents a trivial initialization problem.

is_overdetermined_initialization(prob) -> Bool

Return whether prob carries an initialization problem with more residual equations than unknown initial values.

Arguments

• prob: A SciML problem whose function may carry initialization metadata.

Returns

true when the initialization problem is overdetermined, and false when it is fully determined, underdetermined, or absent.

Developer Interface

Solver and sensitivity packages use this predicate to select initialization behavior without depending on SciMLBase's internal status enum. Implementations must query the problem's initialization metadata rather than caching the result across remake or parameter updates.

numargs(f)

Return the number of positional arguments accepted by each method of f.

The returned collection is used by SciML constructors to validate model-function signatures and to infer in-place versus out-of-place conventions. The callable object itself is not counted, so a method f(du, u, p, t) contributes 4. The order follows Julia's method table and should not be treated as sorted; use queries such as any, minimum, or maximum when testing for supported arities.

Specialized callables such as RuntimeGeneratedFunction, ComposedFunction, and supported foreign-function wrappers provide their underlying arity through specialized methods. Constructors use these arities only for signature validation; they do not call f during this check.

FunctionArgumentsError

Exception thrown when a model function's methods do not match the accepted SciML problem interface signatures.

This is the mixed-arity validation failure: the callable has methods, but the method set is neither uniformly too short nor uniformly too long, and no method matches an accepted in-place or out-of-place signature. It commonly indicates that a function defines several dispatches, none of which match the selected problem or SciMLFunction interface.

Fields

• fname: Display name used in the error message, such as "f" or "jac".
• f: The offending callable; showerror prints its method table.

TooFewArgumentsError

Exception thrown when a model function defines methods with fewer arguments than the SciML problem interface requires.

SciML constructors raise this when the offending callable has methods, but all candidate arities are shorter than the interface requires. For optimization objectives, the specialized message explains the required f(u, p) signature; for differential equations, the message explains the required state, parameter, and time arguments.

Fields

• fname: Display name used in the error message, such as "f" or "jac".
• f: The offending callable; showerror prints its method table.
• isoptimization: Whether to use the optimization-specific explanation.

TooManyArgumentsError

Exception thrown when a model function defines methods with more arguments than the SciML problem interface accepts.

SciML constructors raise this when every visible method of the offending callable has arity greater than the expected in-place signature. For example, an ODE right-hand side must be callable as f(u, p, t) or f(du, u, p, t), not as f(du, u, p1, p2, t).

Fields

• fname: Display name used in the error message, such as "f" or "jac".
• f: The offending callable; showerror prints its method table.