Developer API

Developer API, not user API

The contracts on this page are versioned for SciML solver, symbolic-system, and numeric-wrapper packages. Application code should use solve, remake, solution interpolation, and return-code interfaces instead of calling or extending these hooks.

Interpolation Hooks

SciMLBase.strip_interpolationFunction
strip_interpolation(id::AbstractDiffEqInterpolation)

Return an interpolation suitable for serialization or a solution detached from solver working state.

Solver packages may specialize this hook for interpolation types that retain a model function, AD configuration, or other non-serializable working state. The returned object must preserve evaluation from the saved solution data while discarding only data that cannot be retained. The default leaves an interpolation unchanged.

Developer API, not user API

Solution and solver implementations may extend this hook. Application code should serialize solutions through its normal serialization mechanism.

Example

SciMLBase.strip_interpolation(interp::MyInterpolation) =
    MyInterpolation(interp.t, interp.u, nothing)
source

Symbolic Initialization And Remake Hooks

SciMLBase.get_root_indpFunction
get_root_indp(x)

Return the innermost symbolic index provider associated with x, or nothing when no provider is available.

Solver and symbolic-problem wrappers use this query before dispatching symbolic remake and initialization behavior. A wrapper that introduces a symbolic container may specialize it to forward to the underlying problem or function. The fallback returns x, which lets an explicit index provider participate directly.

Developer API, not user API

This is a versioned hook for solver and symbolic-wrapper packages.

Example

SciMLBase.get_root_indp(wrapper::MyProblemWrapper) =
    SciMLBase.get_root_indp(wrapper.prob)
source
SciMLBase.has_initializeprobFunction
has_initializeprob(f::AbstractSciMLFunction) -> Bool

Return whether f supplies an initialization problem through its initialization metadata.

Solver packages use this trait before selecting a DAE or nonlinear initialization path. Function-container implementations that follow the AbstractSciMLFunction initialization-data layout inherit the default method; custom function containers may specialize it only when they provide an equivalent initialization-problem contract.

Developer API, not user API

Application code should select initialization through problem and solver keywords rather than query this trait.

Example

if SciMLBase.has_initializeprob(prob.f)
    initialize_with_problem!(integrator)
end
source
SciMLBase.RemakeInitializationDataContextType
RemakeInitializationDataContext()

Context passed to remake_initialization_data.

The context currently has no fields. It reserves a positional extension point so future context can be added without changing the symbolic-remake dispatch shape. Extensions must accept the context argument and must not dispatch on undocumented implementation details.

source
SciMLBase.remake_initialization_dataFunction
remake_initialization_data(
        sys, scimlfn, u0, t0, p, newu0, newp,
        ctx = RemakeInitializationDataContext()
    ) -> initialization_data

Recreate a SciML function's initialization data after symbolic remake changes state or parameters.

Arguments

  • sys: The symbolic system associated with scimlfn; this is the primary extension dispatch argument.
  • scimlfn: The SciML function whose initialization data is being reconstructed.
  • u0, p: Values supplied to remake; either may be missing when not overridden.
  • t0: The new initial independent-variable value.
  • newu0, newp: Concrete state and parameter values already resolved by remake.
  • ctx: A RemakeInitializationDataContext.

Returns

  • Reconstructed initialization data, or nothing when scimlfn has none. The generic method preserves the existing initialization callbacks and maps.

Extension Rules

Symbolic-system packages may specialize on sys and function types they own. A method must accept the context argument, must handle missing user overrides, and must return data accepted by the target SciML function constructor. It must not mutate u0, p, newu0, or newp unless those objects' public contracts explicitly permit mutation.

Example

struct MyInitializationSystem end

function SciMLBase.remake_initialization_data(
        ::MyInitializationSystem, scimlfn, u0, t0, p, newu0, newp, ctx
    )
    return (; previous = scimlfn.initialization_data, newu0, newp)
end
source
SciMLBase.late_binding_update_u0_pFunction
late_binding_update_u0_p(prob, root_indp, u0, p, t0, newu0, newp, ctx) -> (u0, p)

Customize the state and parameter values produced by symbolic remake.

Symbolic-system packages may specialize this hook for their problem and root index-provider types. newu0 and newp have already been assembled from the requested symbolic map; return their replacement pair after applying any late-bound defaults or consistency rules. The generic method returns them unchanged. root_indp is supplied for dispatch and is obtained by get_root_indp.

Developer API, not user API

This is a versioned symbolic-remake extension hook. Application code should call remake, not this function.

Example

function SciMLBase.late_binding_update_u0_p(
        prob::MyProblem, root::MySystem, u0, p, t0, newu0, newp, ctx
    )
    return fill_missing_defaults(root, newu0, newp)
end
source
late_binding_update_u0_p(prob, u0, p, t0, newu0, newp, ctx) -> (u0, p)

Call the symbolic-remake extension hook after deriving the root index provider with get_root_indp. Solver code that does not already hold a root provider should use this form.

source
SciMLBase.detect_cyclesFunction
detect_cycles(indp, varmap, syms) -> Bool

Return whether symbolic substitutions in varmap contain a cycle involving syms.

Arguments

  • indp: An index provider used for extension dispatch.
  • varmap: A symbolic assignment map.
  • syms: Symbols whose dependencies should be checked.

Returns

  • Bool: The result from the innermost symbolic container. The generic fallback returns false when no more specific container method exists.

Extension Rules

Symbolic-system packages may specialize this function for index-provider types they own. A method must return true only for a dependency cycle that prevents deterministic symbolic replacement; it must not mutate varmap or syms.

Example

struct MyCycleCheckedSystem end
SciMLBase.detect_cycles(::MyCycleCheckedSystem, varmap, syms) =
    any(sym -> get(varmap, sym, nothing) === sym, syms)
source
SciMLBase.get_updated_symbolic_problemFunction
get_updated_symbolic_problem(indp, prob; kwargs...) -> updated_prob

Return the problem that a solver should use after applying symbolic solve-time updates.

Arguments

  • indp: The root index provider returned by get_root_indp; this is the primary extension dispatch argument.
  • prob: The type-promoted SciML problem about to be solved.

Keywords

  • u0: A solve-time state override, defaulting to the problem's state values.
  • p: A solve-time parameter override, defaulting to the problem's parameter values.
  • kwargs...: Additional solve keywords. Implementations must accept arbitrary keywords.

Returns

  • updated_prob: prob or a replacement problem ready for init/solve. When the result is not === prob, it must already contain the effective u0 and p values.

Extension Rules

Symbolic-system packages may specialize on indp and problem types they own. This hook is called after type promotion and before solver initialization. Implementations must preserve the problem family and all solve-relevant fields not explicitly replaced.

Example

struct MySolveSystem end
struct MySymbolicProblem
    u0
    p
end

function SciMLBase.get_updated_symbolic_problem(
        ::MySolveSystem, prob::MySymbolicProblem; u0 = prob.u0, p = prob.p, kwargs...
    )
    return MySymbolicProblem(u0, p)
end
source

Symbolic Linear Problem Hooks

SciMLBase.SymbolicLinearInterfaceType
SymbolicLinearInterface(; update_Ab, sys, observed, metadata)
SymbolicLinearInterface(update_A!, update_b!, sys, observed, metadata)

Attach symbolic indexing and parameter-dependent matrix reconstruction to a LinearProblem.

Arguments

  • update_Ab: A callable that updates mutable A and b as update_Ab(A, b, p) or returns replacements as update_Ab(p) -> (A, b).
  • sys: The symbolic container used by SymbolicIndexingInterface and by get_new_A_b dispatch.
  • observed: A callable that builds observed-value functions, or nothing to delegate to sys.
  • metadata: Symbolic-backend metadata not interpreted by SciMLBase.
  • update_A!, update_b!: Legacy separate matrix and right-hand-side update callables.

Fields

  • update_Ab::Any: A function which takes A, b and the parameter object p and updates both A and b in-place. For immutable A or b, this should only take p and return the new (A, b). Previously, this API used update_A! and update_b! as separate functions with a similar contract. Supplying these individually is supported, but deprecated.

  • sys::Any: The symbolic backend for the LinearProblem.

  • observed::Any: A function which when given a symbolic expression returns a function (u, p) that computes the expression.

  • metadata::Any: Arbitrary metadata useful for the symbolic backend.

Returns

  • SymbolicLinearInterface: Metadata stored in a linear problem's f field.

Extension Rules

Symbolic-system packages construct this type and specialize get_new_A_b on the type of sys. Consumers must use the documented fields and SymbolicIndexingInterface operations; they must not depend on the concrete type parameters. New code should use the unified update_Ab keyword constructor.

Example

update_Ab = (A, b, p) -> (A .= p[1]; b .= p[2]; (A, b))
interface = SciMLBase.SymbolicLinearInterface(;
    update_Ab, sys = :my_system, observed = nothing, metadata = nothing
)
source
SciMLBase.get_new_A_bFunction
get_new_A_b(root_indp, f, p, A, b; kwargs...) -> (new_A, new_b)

Return the matrix and right-hand side for a symbolic LinearProblem after remake.

Arguments

  • root_indp: The innermost index provider obtained by recursively following SymbolicIndexingInterface.symbolic_container; this is the primary extension dispatch argument.
  • f: The problem's SymbolicLinearInterface.
  • p: The remade parameter object.
  • A, b: Copies of the previous matrix and right-hand side.

Keywords

Implementations must accept and forward arbitrary keyword arguments for compatibility with future symbolic remake options.

Returns

  • (new_A, new_b): Updated linear-system data. Implementations may mutate and return A and b, or return replacement objects.

Extension Rules

Symbolic-system packages may specialize on root_indp and interface types they own. The returned objects must define the same linear problem represented by f and p, and must remain valid inputs to the original LinearProblem constructor.

Example

struct MyLinearSystem end

function SciMLBase.get_new_A_b(::MyLinearSystem, f, p, A, b; kwargs...)
    f.update_Ab(A, b, p)
    return A, b
end
source

Function Preparation Hooks

SciMLBase.prepare_initial_stateFunction
prepare_initial_state(u0) -> prepared_u0

Convert an object supplied as a SciML initial state into its solver-facing form.

Arguments

  • u0: An initial-state value supplied to a problem or ensemble constructor.

Returns

  • prepared_u0: The state stored by the constructor. The generic method returns u0 unchanged.

Extension Rules

Wrapper and language-bridge packages may specialize this function for input types they own. A method must preserve the mathematical state values and shape expected by the model, must not evaluate the model, and must return an object accepted by SciML problem constructors. Do not specialize on broad types owned by another package.

Example

struct ExternalState{T}
    values::T
end

SciMLBase.prepare_initial_state(state::ExternalState) = state.values

See also prepare_function.

source
SciMLBase.prepare_functionFunction
prepare_function(f) -> prepared_f

Convert an object supplied as a SciML model or callback into a Julia-callable form.

Arguments

  • f: A function or foreign-language callable supplied to a SciML constructor.

Returns

  • prepared_f: A callable implementing the same argument and mutation convention as f. The generic method returns f unchanged.

Extension Rules

Wrapper and language-bridge packages may specialize this function for callable types they own. prepare_function may run before or after numargs, so both the original object and prepared callable must expose compatible arity. In-place callables must retain nothing return semantics, and implementations must not invoke f during preparation.

Example

struct ExternalCallable{F}
    f::F
end

SciMLBase.prepare_function(f::ExternalCallable) = f.f

See also prepare_initial_state.

source
SciMLBase.widen_bounded_type_paramsFunction
widen_bounded_type_params(f::AbstractSciMLFunction) -> AbstractSciMLFunction

Widen all bounded type parameters of an AbstractSciMLFunction to their upper bounds.

For example, an ODEFunction has ID <: Union{Nothing, OverrideInitData} and NLP <: Union{Nothing, ODENLStepData}. This function replaces the concrete types of those parameters with Union{Nothing, OverrideInitData} and Union{Nothing, ODENLStepData} respectively, while leaving all unbounded (<: Any) type parameters concrete.

This ensures that all AutoSpecialize instances of a function type share the same type regardless of model-specific details (e.g. initialization functions), preventing recompilation of promote_f and solver code for each model.

Arguments

  • f: A concrete SciML function wrapper.

Returns

  • A reconstruction of f with the same field values and with bounded type parameters replaced by their declared upper bounds. Unbounded parameters remain concrete.

Developer Interface

Symbolic-system packages may call this after attaching model-specific initialization or nonlinear-stage metadata to a function that uses AutoSpecialize. Callers must treat the returned wrapper as immutable metadata reconstruction and must not depend on its exact concrete type parameters.

Example

f = ODEFunction{false, AutoSpecialize}((u, p, t) -> u)
widened = SciMLBase.widen_bounded_type_params(f)
SciMLBase.isinplace(widened)
source

Numeric Wrapper Hooks

SciMLBase.valueFunction
value(x)

Return the plain scalar or type representation underlying x.

Numeric-wrapper integrations may specialize this hook to remove AD, uncertainty, or unit wrappers when a solver needs an ordinary numeric value for control flow or type selection. The default returns x unchanged.

Developer API, not user API

Solver and numeric-wrapper packages may extend this hook. Application code should preserve its numeric wrappers instead of stripping them manually.

Example

SciMLBase.value(x::MyTrackedNumber) = x.primal
source
SciMLBase.unitfulvalueFunction
unitfulvalue(x)

Return the numeric value of x while retaining its physical units.

Numeric-wrapper integrations may specialize this hook to remove AD or uncertainty wrappers without discarding a unit carried by the primal value. The default returns x unchanged. Use value when the solver instead needs a fully unwrapped scalar or type.

Developer API, not user API

Solver and numeric-wrapper packages may extend this hook. Application code should use its quantity package's operations directly.

Example

SciMLBase.unitfulvalue(x::MyDualQuantity) = x.primal
source

Solver Code-Generation Utilities

These utilities support solver implementation code and are not application-facing API.

SciMLBase.@defMacro
@def name definition

Define a zero-argument macro named @name whose expansion is definition.

Solver packages use @def to define repeated preambles that must expand in the generated macro's invocation scope.

Arguments

  • name: The name of the macro to define, without the leading @.
  • definition: The expression returned when the generated macro is expanded.

Returns

An expression that defines @name in the module where @def is invoked.

Extension Rules

Invoke @def at module scope and invoke the generated macro without arguments. Names in definition resolve in the generated macro's invocation scope, so each invocation must provide every referenced local. Do not extend @def or use it to define user-facing API.

Examples

module ExampleSolver
    using SciMLBase: @def

    @def affine_preamble begin
        shifted = x + offset
    end

    function evaluate(x, offset)
        @affine_preamble
        return shifted
    end
end

ExampleSolver.evaluate(2, 3) # 5
source
SciMLBase._unwrap_valFunction
_unwrap_val(::Val{B}) where {B}
_unwrap_val(x)

Return the value encoded by a Val, or return any other input unchanged.

Solver constructors use _unwrap_val for options that accept either a compile-time Val marker or an ordinary runtime value.

Arguments

  • x: A Val instance or a value that should pass through unchanged.

Returns

The type parameter B for Val{B}(); otherwise x itself, preserving its type and identity.

Extension Rules

Call _unwrap_val only when both Val and runtime-value forms are part of the option's documented contract. Downstream packages should not add methods; support for another wrapper type must be implemented in SciMLBase.

Examples

using SciMLBase: _unwrap_val

_unwrap_val(Val(true)) # true
_unwrap_val(:runtime) # :runtime
source

Solution Construction Hooks

Solver packages use these hooks after finishing a linear or eigenvalue solve. They preserve the common no-time-solution representation without making application code depend on a concrete solution constructor.

SciMLBase.build_linear_solutionFunction
build_linear_solution(
        alg, u, resid, cache; retcode = ReturnCode.Default, iters = 0,
        stats = nothing
    ) -> LinearSolution

Construct the LinearSolution returned by a solver for a linear system.

Developer API, not user API

Solver packages use this versioned construction hook after implementing a linear solve. Application code should obtain solutions through solve or solve! rather than call it directly.

Arguments

  • alg: The linear algorithm that produced the result.
  • u: The computed solution state. It is retained without copying.
  • resid: The residual reported by the algorithm, or nothing when it is unavailable.
  • cache: The cache associated with this solve, or nothing when no cache should be exposed.

Keywords

  • retcode::ReturnCode.T = ReturnCode.Default: The completion status of the solve.
  • iters::Integer = 0: Number of iterations performed by an iterative method.
  • stats = nothing: Solver-specific statistics, or nothing when none are available.

Returns

  • LinearSolution: A no-time solution whose u, resid, alg, retcode, iters, cache, and stats fields are the corresponding supplied values.

Example

julia> alg = :direct;

julia> build_linear_solution(
           alg, [2.0], nothing, nothing;
           retcode = ReturnCode.Success
       )
retcode: Success
source
SciMLBase.build_eigenvalue_solutionFunction
build_eigenvalue_solution(
        prob, alg, values, vectors; retcode = ReturnCode.Success,
        resid = nothing, stats = nothing
    ) -> EigenvalueSolution

Construct the EigenvalueSolution returned by a solver for an eigenvalue problem.

Developer API, not user API

Solver packages use this versioned construction hook after computing eigenpairs. Application code should obtain solutions through solve rather than call it directly.

Arguments

  • prob: The EigenvalueProblem that was solved.
  • alg: The eigenvalue algorithm that produced the result.
  • values: Computed eigenvalues. They are retained without copying as the solution's u field.
  • vectors: Eigenvectors corresponding to values, conventionally stored column-wise.

Keywords

  • retcode::ReturnCode.T = ReturnCode.Success: The completion status of the solve.
  • resid = nothing: Residual information for the computed eigenpairs, when available.
  • stats = nothing: Solver-specific statistics, or nothing when none are available.

Returns

  • EigenvalueSolution: A no-time solution whose u, vectors, prob, alg, retcode, resid, and stats fields are the corresponding supplied values.

Example

julia> prob = EigenvalueProblem([2.0 0.0; 0.0 3.0]);

julia> build_eigenvalue_solution(prob, :dense, [2.0, 3.0], [1.0 0.0; 0.0 1.0]).retcode
Success
source

Integrator Hook

SciMLBase.last_step_failedFunction
last_step_failed(integrator) -> Bool

Return whether the preceding attempted solver step failed to converge.

Concrete differential-equation integrators may specialize this hook when their step controller tracks a recoverable failed attempt. check_error uses it to convert a non-adaptive repeated failure into ReturnCode.ConvergenceFailure. The default is false.

Developer API, not user API

This is a versioned integrator implementation hook. Application code should inspect a solve result's return code instead.

Example

SciMLBase.last_step_failed(integrator::MyIntegrator) = integrator.last_step_failed
source
SciMLBase.AbstractDEOptionsType
abstract type AbstractDEOptions

Developer interface for differential-equation solver option containers.

SciMLBase currently stores most common solve options as keyword arguments rather than through concrete AbstractDEOptions subtypes. The abstract type remains as a compatibility hook for solver packages that need to share option-container types without introducing a dependency cycle.

Extension Rules

Solver packages may subtype AbstractDEOptions for a concrete options container. The subtype owns its fields and constructors; SciMLBase does not require a field layout. User-facing options must still be accepted through the documented solve and init keywords, and a solver must not require applications to inspect the container directly.

Example

struct MySolverOptions{T} <: SciMLBase.AbstractDEOptions
    abstol::T
end
source
SciMLBase.ODENLStepDataType
ODENLStepData(nlprob, u0perm, set_gamma_c, set_outer_tmp, set_inner_tmp, nlprobmap)

A collection of hooks for custom nonlinear stage solves in implicit ODE and DAE algorithms.

ODENLStepData lets an ODEFunction, SplitFunction or DAEFunction provide a structured AbstractNonlinearProblem template for solver packages that form implicit stage equations. Before each nonlinear solve, the algorithm updates the stage guess, scaling factors, time information, and temporary vectors through the stored setter callables. After the nonlinear solve, nlprobmap converts the nonlinear unknown back to the state vector used by the original problem.

Mass-matrix form

For M * du/dt = f(u, p, t) the nonlinear problem should represent a stage equation of the form M * z = outer_tmp + gamma1 * f(gamma2 * z + inner_tmp, p, t_c), equivalently g(z, p') = gamma1 * f(gamma2 * z + inner_tmp, p, t_c) + outer_tmp - M * z. Here z is the nonlinear stage unknown, p is the ODE parameter object, t_c is the stage evaluation time, and gamma1, gamma2, outer_tmp, and inner_tmp are supplied by the ODE algorithm.

Fully implicit form

For 0 = F(du, u, p, t) (a DAEFunction) the stage equation has the same shape, with both arguments of F affine in the stage unknown: g(z, p') = F(gamma1 * z + outer_tmp, gamma2 * z + inner_tmp, p, t_c). gamma2 and inner_tmp build the state argument from the stage unknown exactly as in the mass-matrix form, while gamma1 and outer_tmp build the derivative argument. Taking the stage unknown to be the stage state (gamma2 = 1, inner_tmp = 0), a BDF-type step with du ≈ (u - tmp) / (γ * dt) gives gamma1 = inv(γ * dt) and outer_tmp = -tmp / (γ * dt). With that convention gamma1 is the gamma of the DAEFunction Jacobian signature jac(J, du, u, p, gamma, t): the Jacobian of the stage residual with respect to z is gamma1 * dF/d(du) + dF/du.

Fields

  • nlprob::Any: The structured AbstractNonlinearProblem template solved for each implicit ODE stage.
  • u0perm::Any: Callable used by the ODE algorithm to update the nonlinear problem's initial guess from the current stage data.
  • set_γ_c::Any: Callable used by the ODE algorithm to update the stage scaling factors and stage time/abscissa data used by the nonlinear problem.
  • set_outer_tmp::Any: Callable used by the ODE algorithm to update the outer_tmp vector in the nonlinear stage equation.
  • set_inner_tmp::Any: Callable used by the ODE algorithm to update the inner_tmp vector in the nonlinear stage equation.
  • nlprobmap::Any: Callable that maps the solution of nlprob back to the state vector or stage vector of the original ODE problem.

Extension Rules

Symbolic-system packages construct this value and store it as the nlstep_data of an ODEFunction, SplitFunction or DAEFunction. Solver packages may consume the six fields through their callable contracts, but must not assume concrete callable types or mutate the container. Each setter must update the object it closes over consistently with nlprob, and nlprobmap must map a completed nonlinear solution back to the stage representation of the original problem.

source
SciMLBase.JacobianWrapperType
JacobianWrapper(f, p)
JacobianWrapper{iip}(f, p)

Fix the parameter argument of a residual function and expose the state as its free argument.

Arguments

  • f: An in-place f(residual, u, p) or out-of-place f(u, p) function.
  • p: The fixed parameter value.
  • iip: Whether f follows the in-place convention. The unparameterized constructor infers this from f.

Fields

  • f: The wrapped residual function.
  • p: The fixed parameter value.

Type Parameters

  • iip: Whether the wrapped function is in-place.
  • fType: Type of the wrapped function.
  • pType: Type of the fixed parameter value.

Returns

Calling an out-of-place wrapper as wrapper(u) returns f(u, p). Calling either convention as wrapper(residual, u) fills residual; the in-place form returns the return value of f, while the out-of-place form returns the broadcast assignment.

Example

wrapper = JacobianWrapper((u, p) -> u .- p, [1.0, 2.0])
wrapper([3.0, 5.0])

Developer Interface

Nonlinear solver and differentiation packages may construct this wrapper when they need a one-argument residual with fixed parameters. Use its callable interface rather than depending on the mutable field layout.

source

Solver Preparation Hooks

Solver packages use these hooks to derive the effective problem data for an individual solve call and to reject unsupported problem-algorithm pairings. They are not an application-facing replacement for solve, init, or remake.

SciMLBase.get_concrete_pFunction
get_concrete_p(prob, kwargs)

Return the parameter value a solver should use for a single solve call.

Arguments

  • prob: A SciML problem with a p field.
  • kwargs: Keyword arguments from the solve call, represented by a NamedTuple or another key-addressable keyword container.

Returns

The p keyword override when present; otherwise prob.p.

Developer Interface

Solver packages call this before constructing their cache or concretizing a problem so that solve(prob; p = new_p) and solve(remake(prob; p = new_p)) use the same parameter value. Extensions should preserve that override rule and must not mutate prob or the supplied keyword container.

source
SciMLBase.get_concrete_u0Function
get_concrete_u0(prob, isadapt, t0, kwargs)

Return the initial state a solver should use for a single solve call.

Arguments

  • prob: A SciML problem with a u0 field.
  • isadapt: Whether the solver will adapt its time step or mesh. Integer initial states are converted to floating-point values when this is true.
  • t0: The initial independent-variable value.
  • kwargs: Keyword arguments from the solve call. A u0 entry overrides prob.u0.

Returns

The effective initial state after applying the u0 override, evaluating supported problem-specific initial-state representations, and enforcing the common in-place and tuple-state constraints.

Developer Interface

Solver packages use this hook while concretizing a problem. Extensions must honor the u0 keyword override, return a state compatible with the problem's in-place trait, and throw the appropriate SciMLBase initial-condition error instead of silently changing an invalid state representation.

source
SciMLBase.isconcreteu0Function
isconcreteu0(prob, t0, kwargs) -> Bool

Return whether prob.u0 is already a concrete initial state that can be reused without evaluation.

Arguments

  • prob: A SciML problem with a u0 field.
  • t0: The initial independent-variable value for the proposed solve.
  • kwargs: Keyword arguments for the proposed solve.

Returns

true when the problem's stored u0 is neither deferred nor distribution-valued, and false otherwise.

Developer Interface

get_concrete_problem implementations use this predicate to decide whether they may return the original problem object. Extensions must return false whenever evaluating or replacing u0 is required, including for solve-call overrides.

source
SciMLBase.promote_u0Function
promote_u0(u0, p, t0)

Promote an initial state to preserve automatic-differentiation element types carried by parameters or the initial independent variable.

Arguments

  • u0: Initial state to prepare for a solve.
  • p: Effective parameter value for the solve.
  • t0: Effective initial independent-variable value.

Returns

u0 unchanged when no dual element type is present; otherwise a state with the common dual-compatible element type.

Developer Interface

Solver packages call this after get_concrete_u0 and before constructing caches or testing whether a problem can be reused. Extensions must retain the value semantics of u0 and only change its element type when promotion is required by p or t0.

source
SciMLBase.get_concrete_problemFunction
get_concrete_problem(prob, isadapt; alg = nothing, kwargs...)

Return the problem object a solver should use for a specific solve call.

Arguments

  • prob: The problem supplied to solve or init.
  • isadapt: Whether the selected algorithm adapts time steps or a mesh.
  • alg: Selected algorithm, when algorithm-dependent promotion or function specialization is required.
  • kwargs: Solve-call keyword arguments, including possible u0, p, and time-span overrides.

Returns

Either prob when its stored data already matches the requested solve, or a replacement problem carrying the effective values for that solve.

Developer Interface

Solver packages extend this hook for problem families that require solver-time concretization. Implementations should use get_concrete_p, get_concrete_u0, promote_u0, and remake as appropriate; they must not mutate prob, must preserve the problem family and user-visible metadata, and may return prob only when the effective values and their relevant types are unchanged.

source
SciMLBase.check_prob_alg_pairingFunction
check_prob_alg_pairing(prob, alg)

Validate that alg is applicable to prob before a solver allocates its cache.

Arguments

  • prob: Problem selected for the solve.
  • alg: Algorithm selected for the solve.

Returns

nothing when the pairing is supported.

Developer Interface

Solver packages extend this hook for problem families with algorithm restrictions. Implementations should throw a descriptive SciMLBase error for unsupported pairings and must not mutate prob or alg. A no-op method is appropriate when every algorithm in the package's documented algorithm family supports the problem type.

source
SciMLBase.KeywordArgErrorType
KeywordArgError
KeywordArgWarn
KeywordArgSilent

Controls how a solver handles keyword arguments outside its supported keyword set.

Values

  • KeywordArgError: throw CommonKwargError for unsupported keywords.
  • KeywordArgWarn: emit a warning and continue.
  • KeywordArgSilent: accept unsupported keywords without a warning.

Solver packages can use these values as the kwargshandle passed to their keyword validation path. Application code should prefer solver-specific documented keywords instead of suppressing validation with KeywordArgSilent.

source
SciMLBase.keyword_arg_silentConstant
keyword_arg_silent

The documented solver-author value for accepting unsupported keyword arguments without emitting a warning. Pass it as kwargshandle to a keyword-validation path when the caller has intentionally delegated keyword handling to another layer.

Application code should not use this value to suppress unsupported solver keywords; use the solver's documented keyword interface instead.

source
SciMLBase.@add_kwonlyMacro
@add_kwonly function_definition

Define keyword-only version of the function_definition.

@add_kwonly function f(x; y = 1)
    ...
end

expands to:

function f(x; y = 1)
    ...
end
function f(; x = error("No argument x"), y = 1)
    ...
end
source