Developer 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_interpolation — Function
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.
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)Symbolic Initialization And Remake Hooks
SciMLBase.get_root_indp — Function
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.
Example
SciMLBase.get_root_indp(wrapper::MyProblemWrapper) =
SciMLBase.get_root_indp(wrapper.prob)SciMLBase.has_initializeprob — Function
has_initializeprob(f::AbstractSciMLFunction) -> BoolReturn 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.
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)
endSciMLBase.RemakeInitializationDataContext — Type
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.
SciMLBase.remake_initialization_data — Function
remake_initialization_data(
sys, scimlfn, u0, t0, p, newu0, newp,
ctx = RemakeInitializationDataContext()
) -> initialization_dataRecreate a SciML function's initialization data after symbolic remake changes state or parameters.
Arguments
sys: The symbolic system associated withscimlfn; this is the primary extension dispatch argument.scimlfn: The SciML function whose initialization data is being reconstructed.u0,p: Values supplied toremake; either may bemissingwhen not overridden.t0: The new initial independent-variable value.newu0,newp: Concrete state and parameter values already resolved byremake.ctx: ARemakeInitializationDataContext.
Returns
- Reconstructed initialization data, or
nothingwhenscimlfnhas 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)
endSciMLBase.LateBindingUpdateU0PContext — Type
LateBindingUpdateU0PContext()Context passed to late_binding_update_u0_p.
The context currently has no fields. It reserves a positional extension point for symbolic-system packages. Extensions must accept it and must not assume that it remains fieldless in later minor releases.
SciMLBase.late_binding_update_u0_p — Function
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.
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)
endlate_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.
SciMLBase.detect_cycles — Function
detect_cycles(indp, varmap, syms) -> BoolReturn 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 returnsfalsewhen 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)SciMLBase.get_updated_symbolic_problem — Function
get_updated_symbolic_problem(indp, prob; kwargs...) -> updated_probReturn the problem that a solver should use after applying symbolic solve-time updates.
Arguments
indp: The root index provider returned byget_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:probor a replacement problem ready forinit/solve. When the result is not=== prob, it must already contain the effectiveu0andpvalues.
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)
endSymbolic Linear Problem Hooks
SciMLBase.SymbolicLinearInterface — Type
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 mutableAandbasupdate_Ab(A, b, p)or returns replacements asupdate_Ab(p) -> (A, b).sys: The symbolic container used bySymbolicIndexingInterfaceand byget_new_A_bdispatch.observed: A callable that builds observed-value functions, ornothingto delegate tosys.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 takesA,band the parameter objectpand updates bothAandbin-place. For immutableAorb, this should only takepand return the new(A, b). Previously, this API usedupdate_A!andupdate_b!as separate functions with a similar contract. Supplying these individually is supported, but deprecated.sys::Any: The symbolic backend for theLinearProblem.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'sffield.
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
)SciMLBase.get_new_A_b — Function
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 followingSymbolicIndexingInterface.symbolic_container; this is the primary extension dispatch argument.f: The problem'sSymbolicLinearInterface.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 returnAandb, 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
endFunction Preparation Hooks
SciMLBase.prepare_initial_state — Function
prepare_initial_state(u0) -> prepared_u0Convert 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 returnsu0unchanged.
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.valuesSee also prepare_function.
SciMLBase.prepare_function — Function
prepare_function(f) -> prepared_fConvert 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 asf. The generic method returnsfunchanged.
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.fSee also prepare_initial_state.
SciMLBase.widen_bounded_type_params — Function
widen_bounded_type_params(f::AbstractSciMLFunction) -> AbstractSciMLFunctionWiden 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
fwith 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)Numeric Wrapper Hooks
SciMLBase.value — Function
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.
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.primalSciMLBase.unitfulvalue — Function
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.
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.primalSolver Code-Generation Utilities
These utilities support solver implementation code and are not application-facing API.
SciMLBase.@def — Macro
@def name definitionDefine 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) # 5SciMLBase._unwrap_val — Function
_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: AValinstance 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) # :runtimeSolution 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_solution — Function
build_linear_solution(
alg, u, resid, cache; retcode = ReturnCode.Default, iters = 0,
stats = nothing
) -> LinearSolutionConstruct the LinearSolution returned by a solver for a linear system.
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, ornothingwhen it is unavailable.cache: The cache associated with this solve, ornothingwhen 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, ornothingwhen none are available.
Returns
LinearSolution: A no-time solution whoseu,resid,alg,retcode,iters,cache, andstatsfields are the corresponding supplied values.
Example
julia> alg = :direct;
julia> build_linear_solution(
alg, [2.0], nothing, nothing;
retcode = ReturnCode.Success
)
retcode: SuccessSciMLBase.build_eigenvalue_solution — Function
build_eigenvalue_solution(
prob, alg, values, vectors; retcode = ReturnCode.Success,
resid = nothing, stats = nothing
) -> EigenvalueSolutionConstruct the EigenvalueSolution returned by a solver for an eigenvalue problem.
Solver packages use this versioned construction hook after computing eigenpairs. Application code should obtain solutions through solve rather than call it directly.
Arguments
prob: TheEigenvalueProblemthat was solved.alg: The eigenvalue algorithm that produced the result.values: Computed eigenvalues. They are retained without copying as the solution'sufield.vectors: Eigenvectors corresponding tovalues, 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, ornothingwhen none are available.
Returns
EigenvalueSolution: A no-time solution whoseu,vectors,prob,alg,retcode,resid, andstatsfields 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
SuccessIntegrator Hook
SciMLBase.last_step_failed — Function
last_step_failed(integrator) -> BoolReturn 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.
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_failedSciMLBase.AbstractDEOptions — Type
abstract type AbstractDEOptionsDeveloper 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
endSciMLBase.ODENLStepData — Type
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 structuredAbstractNonlinearProblemtemplate 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 theouter_tmpvector in the nonlinear stage equation.
set_inner_tmp::Any: Callable used by the ODE algorithm to update theinner_tmpvector in the nonlinear stage equation.
nlprobmap::Any: Callable that maps the solution ofnlprobback 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.
SciMLBase.JacobianWrapper — Type
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-placef(residual, u, p)or out-of-placef(u, p)function.p: The fixed parameter value.iip: Whetherffollows the in-place convention. The unparameterized constructor infers this fromf.
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.
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_p — Function
get_concrete_p(prob, kwargs)Return the parameter value a solver should use for a single solve call.
Arguments
prob: A SciML problem with apfield.kwargs: Keyword arguments from the solve call, represented by aNamedTupleor 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.
SciMLBase.get_concrete_u0 — Function
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 au0field.isadapt: Whether the solver will adapt its time step or mesh. Integer initial states are converted to floating-point values when this istrue.t0: The initial independent-variable value.kwargs: Keyword arguments from the solve call. Au0entry overridesprob.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.
SciMLBase.isconcreteu0 — Function
isconcreteu0(prob, t0, kwargs) -> BoolReturn whether prob.u0 is already a concrete initial state that can be reused without evaluation.
Arguments
prob: A SciML problem with au0field.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.
SciMLBase.promote_u0 — Function
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.
SciMLBase.get_concrete_problem — Function
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 tosolveorinit.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 possibleu0,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.
SciMLBase.check_prob_alg_pairing — Function
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.
SciMLBase.KeywordArgError — Type
KeywordArgError
KeywordArgWarn
KeywordArgSilentControls how a solver handles keyword arguments outside its supported keyword set.
Values
KeywordArgError: throwCommonKwargErrorfor 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.
SciMLBase.keyword_arg_silent — Constant
keyword_arg_silentThe 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.
SciMLBase.@add_kwonly — Macro
@add_kwonly function_definitionDefine keyword-only version of the function_definition.
@add_kwonly function f(x; y = 1)
...
endexpands to:
function f(x; y = 1)
...
end
function f(; x = error("No argument x"), y = 1)
...
end