SciMLProblems

abstract type AbstractSpecialization

Base interface for marker types that control how SciML function wrappers retain, erase, or type-restrict their callable fields.

Specialization markers are passed as types, not values, usually as the second explicit parameter after the in-place flag:

ODEFunction{iip, specialize}(f)
ODEProblem{iip, specialize}(f, u0, tspan, p)

Concrete SciML function types store the marker in their type parameters. Query it with specialization instead of relying on a particular parameter position. Problem construction and remake should preserve an explicitly chosen marker unless the caller requests a different function representation.

The built-in markers are AutoSpecialize, AutoDespecialize, AutoRespecialize, NoSpecialize, FunctionWrapperSpecialize, and FullSpecialize. Their behavior is implemented jointly by SciMLBase constructors and downstream solver packages: a marker alone does not automatically erase types or install callable wrappers. New AbstractSpecialization subtypes therefore require explicit support in every function constructor and solver path that is expected to honor them.

Solver and transformation code must not assume that a type-restricted wrapped callable accepts new state, time, parameter, or AD types. Use unwrapped_f before calling it with a signature outside the documented wrapper set, then reconstruct a suitable SciML function, commonly with FullSpecialize for AD transformations.

struct AutoSpecialize <: SciMLBase.AbstractSpecialization

The default specialization level for problem functions. AutoSpecialize asks the selected solver path to reuse compilation where it has a supported type-erasure or callable-wrapping strategy, while falling back to ordinary full specialization elsewhere.

For the common in-place ODE path, wrapping is applied shortly before solving so prob.f remains convenient to inspect and the solver can reuse precompiled code across compatible model functions. Other problem families may implement their own AutoSpecialize strategy; for example, nonlinear solvers can install wrappers suited to their residual signatures. The exact supported state, parameter, time, callback, and AD types are therefore part of the concrete solver's contract.

Note About Benchmarking and Runtime Optimality

It is recommended that AutoSpecialize is not used in benchmarking because callable wrapping can affect runtime. Its primary goal is lower latency for REPL and application workflows. Use FullSpecialize when measuring peak runtime or when repeatedly solving inside a long-running optimization loop.

Limitations of AutoSpecialize

Support is solver-specific, but common restrictions are:

• Only signatures precompiled or installed by the solver's wrapper path can reuse compilation. Unsupported problem forms fall back to full specialization.
• Type-restricted wrappers require concrete compatible state, parameter, time, and return types. Unitful or unusual array types may disable wrapping when the solver cannot construct matching signatures.
• Operators such as AbstractSciMLOperator are generally left unwrapped because they provide their own callable and update interfaces.
• AD paths must either install wrapper signatures for their dual types and chunk sizes or reconstruct the problem around unwrapped_f. Sensitivity packages commonly choose the latter for tracked, dual, or Enzyme values.
• Compilation reuse only exists for argument combinations that downstream solver packages precompile. Common defaults cover Vector{Float64} state, Float64 time, and Vector{Float64} or NullParameters parameters.

Cases where automatic wrapping is disabled are equivalent to FullSpecialize.

Example

f(du, u, p, t) = (du .= u)

# Note this is the same as ODEProblem(f, [1.0], (0.0,1.0))
# If no preferences are set
ODEProblem{true, SciMLBase.AutoSpecialize}(f, [1.0], (0.0, 1.0))

struct AutoDespecialize <: SciMLBase.AbstractSpecialization

AutoDespecialize asks supported solver paths to store p in a DespecializedParameters container. AutoSpecialize retains its existing function-specialization behavior and does not select this parameter container. The container has a stable outer type and stores the original parameter object in an Any field, so solver compilation can be reused across parameter-container types. Built-in SciML function containers cross a dynamic function barrier before calling model code, where the original concrete parameter object is recovered.

This policy accepts arbitrary parameter objects and does not impose the opaque-container constraints of AutoRespecialize. The tradeoff is dynamic dispatch at the model function barrier. Transformations such as parameter AD may call unwrap_parameters and reconstruct a concretely parameterized problem when needed. Symbolic and modeling packages must forward their parameter interfaces through DespecializedParameters for indexed access to remain available.

Support is solver-specific. A solver without an AutoDespecialize path may fall back to ordinary specialization without wrapping p.

Example

struct MyParameters
    rate::Float64
end
f(du, u, p, t) = (du .= -p.rate .* u)
ODEProblem{true, SciMLBase.AutoDespecialize}(
    f, [1.0], (0.0, 1.0), MyParameters(2.0)
)

struct AutoRespecialize <: SciMLBase.AbstractSpecialization

AutoRespecialize extends AutoSpecialize by additionally de-specializing the parameter object. Solver paths with a supported opaque-parameter strategy pack an isbits, non-NullParametersp into a fixed-type opaque container (e.g. RespecializeParams.OpaqueParams) and install callable wrappers whose signatures carry the opaque container type in the p slot instead of typeof(p). The concretized problem type — and with it the solver's compilation — then becomes independent of the user's parameter struct type, so a single compiled (and precompiled) solve is shared across all isbits parameter types. Inside the user's f, p is recovered at its original concrete type via a type-stable, allocation-free unpack, so the model function itself remains fully specialized.

AutoRespecialize is the recommended choice for latency-sensitive workflows that construct many problems with differently-typed parameter structs (parameter studies over configuration structs, package test suites, teaching setups).

Support is solver-specific, like all specialization levels. Where a solver path has no opaque-parameter strategy — or where p is not isbits or is NullParameters — behavior falls back to plain AutoSpecialize. Solvers that apply the packing keep the opaque container in the concretized problem (e.g. sol.prob.p), since installed wrappers may be re-invoked with it; consult the solver's documentation for how to recover the original value.

Example

struct MyParams
    k::Float64
end
f(du, u, p, t) = (du .= p.k .* u)
ODEProblem{true, SciMLBase.AutoRespecialize}(f, [1.0], (0.0, 1.0), MyParams(2.0))

AutoDePSpecialize

Deprecated name for AutoRespecialize. New code should use AutoRespecialize.

struct NoSpecialize <: SciMLBase.AbstractSpecialization

NoSpecialize forces SciMLFunctions to not specialize on the types of functions wrapped within it. This ultimately contributes to a form such that every prob.f type is the same, meaning compilation caches are fully reused, with the downside of losing runtime performance. NoSpecialize is the form that most fully trades off runtime for compile time. Unlike AutoSpecialize, NoSpecialize can be used with any SciMLFunction.

Example

f(du, u, p, t) = (du .= u)
ODEProblem{true, SciMLBase.NoSpecialize}(f, [1.0], (0.0, 1.0))

struct FunctionWrapperSpecialize <: SciMLBase.AbstractSpecialization

FunctionWrapperSpecialize is an eager wrapping choice which performs callable wrapping during problem construction. This performs the function wrapping at the earliest possible point, giving the best compile-time vs runtime performance, but with the difficulty that any usage of prob.f needs to account for the function wrapper's presence. While useful as a performance reference, this method has interoperability costs: nonstandard solvers and analyses must unwrap and reconstruct the callable when state, parameter, time, or AD types change. It is therefore not the default, and the usually small compile-time difference from AutoSpecialize rarely justifies the stricter callable contract in application code.

Limitations of FunctionWrapperSpecialize

FunctionWrapperSpecialize has the type-compatibility limitations of AutoSpecialize, plus the following stricter rules:

• prob.f is directly specialized to the types of (u,p,t), and any usage of prob.f on other types first requires using SciMLBase.unwrapped_f(prob.f) to remove the function wrapper.
• Prefer a problem constructor such as ODEProblem{iip, FunctionWrapperSpecialize}, because it has the representative u, p, and t values needed to define wrapper signatures.
• Constructing a SciML function directly with this marker requires an already wrapped callable. Solver-integration packages use wrapfun_iip or wrapfun_oop for this purpose; passing a bare callable when its input types are unavailable is an error.

Example

f(du, u, p, t) = (du .= u)
ODEProblem{true, SciMLBase.FunctionWrapperSpecialize}(f, [1.0], (0.0, 1.0))

struct FullSpecialize <: SciMLBase.AbstractSpecialization

FullSpecialize is an eager specialization choice which directly types the AbstractSciMLFunction struct to match the type of the model f. This forces recompilation of the solver on each new function type f, leading to the most compile times with the benefit of having the best runtime performance.

FullSpecialize should be used in all cases where top runtime performance is required, such as in long-running simulations and benchmarking.

Example

f(du, u, p, t) = (du .= u)
ODEProblem{true, SciMLBase.FullSpecialize}(f, [1.0], (0.0, 1.0))

struct DespecializedParameters

Store a parameter object behind the stable field type Any. This prevents callers such as solver internals from specializing on the concrete parameter-container layout. Use invoke_with_despecialized_parameters to cross a dynamic function barrier before calling code that needs the original concrete parameter type.

This strategy accepts arbitrary parameter objects and forwards the common Base, SciMLStructures, SymbolicIndexingInterface, ArrayInterface, and Adapt interfaces to the wrapped value. The dynamic dispatch isolates inference loss at the function barrier, but adds runtime overhead. Use unwrap_parameters in transformations such as AD that need to reconstruct a problem with concrete parameters. Use FullSpecialize when runtime performance takes priority over compilation reuse. Supported solvers select this container with AutoDespecialize.

DespecializedParameters is distinct from AutoRespecialize: the latter lets a supporting solver recover a concrete parameter type without dynamic dispatch, but imposes solver-specific restrictions on symbolic indexing and parameter differentiation.

The wrapped object is available through the params field. Other properties and collection operations are forwarded to it.

Fields

• params::Any

unwrap_parameters(params)

Return the parameter object stored in DespecializedParameters. The fallback is the identity, so downstream transformations can call this function without first testing whether parameters were despecialized.

invoke_with_despecialized_parameters(f, args; kwargs...)
invoke_with_despecialized_parameters(
    f, args, params, ::Val{parameter_index}; kwargs...
)

Call f(args...; kwargs...) after replacing a DespecializedParameters argument with its wrapped object. The two-argument form locates the wrapper in args; the explicit form accepts its statically known position. The call crosses a non-inlined dynamic-dispatch barrier: code above the barrier sees the stable outer parameter type, while f compiles for the concrete wrapped parameter type.

This is a developer interface used by all built-in AbstractSciMLFunction containers. args may contain at most one despecialized parameter object. In the explicit form, args[parameter_index] must be the same wrapper passed as params.

specialization(f::AbstractSciMLFunction) -> Type{<:AbstractSpecialization}
specialization(::Type{<:AbstractSciMLFunction}) -> Type{<:AbstractSpecialization}

Return the specialization marker carried by a SciML function wrapper.

Known concrete SciML function types return their stored specialization type, such as AutoSpecialize or FullSpecialize. The fallback for a custom AbstractSciMLFunction is FullSpecialize, meaning generic code must assume ordinary Julia specialization unless the type explicitly participates in the marker interface.

Use this query instead of inspecting concrete type-parameter positions. The result is a marker type, not an instance, and can be compared with ===.

isfunctionwrapper(x) -> Bool

Return whether x is a low-level type-restricting callable wrapper used by a SciML specialization path.

Wrapper-provider packages should extend this predicate for their concrete wrapper types. The default is false. Most model transformations should use unwrapped_f, which recursively handles supported wrapper layers, instead of branching on this predicate directly.

wrapfun_oop(f, inputs)

Wrap an out-of-place callable f for the concrete argument values in inputs.

This is an extension hook for packages that provide the callable-wrapper backend used by AutoSpecialize or FunctionWrapperSpecialize. inputs contains representative values in the same order as a call to f; the returned callable must accept that concrete signature and return the same type as f(inputs...). Implementations may support additional precompiled signatures.

The original callable must remain recoverable through unwrapped_f. Calling this hook without loading a package that implements the requested wrapper path is unsupported.

wrapfun_iip(f, inputs)
wrapfun_iip(f, inputs, ::Val{chunksize})

Wrap an in-place callable f for the concrete argument values in inputs.

This is an extension hook for packages that provide the callable-wrapper backend used by AutoSpecialize or FunctionWrapperSpecialize. inputs contains representative values in the same order as a call to f, such as (du, u, p, t) for an ODE right-hand side. The returned callable must support that signature and preserve the in-place convention that its return value is ignored.

The optional Val{chunksize} form lets AD-aware implementations install matching dual-number signatures. Implementations may support additional precompiled signatures, and the original callable must remain recoverable through unwrapped_f. Calling this hook without loading a package that implements the requested wrapper path is unsupported.

unwrap_fw(wrapper)

Return the callable stored directly inside one low-level function wrapper.

Wrapper-provider packages implement this hook for their raw wrapper types. It removes one wrapper layer and is mainly useful while implementing specialization backends. General solver and analysis code should prefer unwrapped_f, which recursively removes the wrapper forms known to SciMLBase.

struct NullParameters

A singleton type used as the default value of the parameter argument p in AbstractSciMLProblem constructors (for example ODEProblem(f, u0, tspan) with no p supplied). It marks the absence of parameters.

NullParameters is deliberately not indexable or broadcastable: any attempt to index into it (such as p[1] or x .+ p inside a problem's function) throws an error with a message explaining that no parameters were passed to the problem. This turns the common mistake of forgetting to supply p (or using the wrong function signature) into an informative error rather than a confusing downstream failure.

Model functions must still accept their documented p argument even when the problem stores NullParameters().

Example

prob = ODEProblem(f, u0, tspan)      # prob.p === NullParameters()
prob = ODEProblem(f, u0, tspan, p)   # prob.p === p

remake(thing; <keyword arguments>)

Re-construct thing with new field values specified by the keyword arguments.

remake(
    prob::AbstractSciMLProblem; u0 = missing, p = missing,
    interpret_symbolicmap = true, use_defaults = false, kwargs...
)

Construct a problem of the same family as prob, replacing the supplied fields and preserving all other problem data. Extra keyword arguments are forwarded to the problem-family-specific remake implementation.

When u0 or p is a symbolic map and prob has an associated symbolic system, explicit entries take precedence. Missing entries with symbolic-expression defaults use those expressions so dependent values remain consistent. Other missing entries retain their values from prob unless use_defaults = true, in which case available numeric system defaults are preferred. use_defaults is meaningful only when an explicit symbolic map is supplied for a problem with an associated system.

Set interpret_symbolicmap = false to use a pair-valued p directly instead of interpreting it as a symbolic parameter map. Pair-valued u0 is still interpreted as a symbolic state map. Non-symbolic u0 and p values are used directly.

remake(func::AbstractSciMLFunction; f = missing, g = missing, f2 = missing, kwargs...)

remake the given func. Return an AbstractSciMLFunction of the same kind, isinplace and specialization as func. Retain the properties of func, except those that are overridden by keyword arguments. For stochastic functions (e.g. SDEFunction) the g keyword argument is used to override func.g. For split functions (e.g. SplitFunction) the f2 keyword argument is used to override func.f2, and f is used for func.f1. If f isa AbstractSciMLFunction and func is not a split function, properties of f will override those of func (but not ones provided via keyword arguments). Properties of f that are nothing will fall back to those in func (unless provided via keyword arguments). If f is a different type of AbstractSciMLFunction from func, the returned function will be of the kind of f unless func is a split function. If func is a split function, f and f2 will be wrapped in the appropriate AbstractSciMLFunction type with the same isinplace and specialization as func.

remake(
    prob::ODEProblem; f = missing, u0 = missing, tspan = missing,
    p = missing, kwargs = missing, _kwargs...
)

Remake the given ODEProblem. If u0 or p are given as symbolic maps ModelingToolkit.jl has to be loaded.

remake(
    prob::DynamicalODEProblem; f = missing, v0 = missing, u0 = missing,
    tspan = missing, p = missing, kwargs = missing, _kwargs...
)

Remake the given DynamicalODEProblem. u0 = ArrayPartition(v0, u0) remains supported as a full-state replacement when v0 is omitted. Pair-valued symbolic state maps are forwarded to the standard ODEProblem remake machinery; component overrides must otherwise be concrete values.

remake(
    prob::SecondOrderODEProblem; f = missing, du0 = missing, u0 = missing,
    tspan = missing, p = missing, kwargs = missing, _kwargs...
)

Remake the given SecondOrderODEProblem. u0 = ArrayPartition(du0, u0) remains supported as a full-state replacement when du0 is omitted. Pair-valued symbolic state maps are forwarded to the standard ODEProblem remake machinery; component overrides must otherwise be concrete values.

remake(
    prob::BVProblem; f = missing, u0 = missing, tspan = missing,
    p = missing, kwargs = missing, problem_type = missing, _kwargs...
)

Remake the given BVProblem.

remake(
    prob::SDEProblem; f = missing, g = missing, u0 = missing, tspan = missing,
    p = missing, noise = missing, noise_rate_prototype = missing,
    seed = missing, kwargs = missing, _kwargs...
)

Remake the given SDEProblem.

remake(
    prob::DAEProblem; f = missing, du0 = missing, u0 = missing, tspan = missing,
    p = missing, differential_vars = missing, kwargs = missing, _kwargs...
)

Remake the given DAEProblem. If u0 or p are given as symbolic maps ModelingToolkit.jl has to be loaded.

remake(
    prob::OptimizationProblem; f = missing, u0 = missing, p = missing,
    lb = missing, ub = missing, int = missing, lcons = missing, ucons = missing,
    sense = missing, problem_type = missing, kwargs = missing, _kwargs...
)

Remake the given OptimizationProblem. If u0 or p are given as symbolic maps ModelingToolkit.jl has to be loaded.

remake(
    prob::NonlinearProblem; f = missing, u0 = missing, p = missing,
    problem_type = missing, kwargs = missing, _kwargs...
)

Remake the given NonlinearProblem. If u0 or p are given as symbolic maps ModelingToolkit.jl has to be loaded.

remake(
    prob::NonlinearLeastSquaresProblem; f = missing, u0 = missing, p = missing,
    kwargs = missing, _kwargs...
)

Remake the given NonlinearLeastSquaresProblem.

remake(
    prob::SCCNonlinearProblem; u0 = missing, p = missing, probs = missing,
    parameters_alias = prob.parameters_alias, sys = missing, explicitfuns! = missing
)

Remake the given SCCNonlinearProblem. u0 is the state vector for the entire problem, which will be chunked appropriately and used to remake the individual subproblems. p is the parameter object for prob. If parameters_alias, the same parameter object will be used to remake the individual subproblems. Otherwise if p !== missing, this function will error and require that probs be specified. probs is the collection of subproblems. Even if probs is explicitly specified, the value of u0 provided to remake will be used to override the values in probs. sys is the index provider for the full system.

updated_u0_p(
    prob, u0, p, t0 = nothing; interpret_symbolicmap = true,
    use_defaults = false
)

Resolve replacement initial conditions and parameters for a SciML problem.

Package authors implementing a remake method for a wrapper problem can use this to preserve the symbolic-map and default-value behavior of remake.

parameterless_type(x)

Return the parameterless type constructor associated with x or a concrete type.

This is intended for package authors implementing remake-style reconstruction of parametric SciML objects.

abstract type AbstractSciMLProblem

Base abstract type for all SciML problem definitions. A concrete AbstractSciMLProblem encodes the mathematical data that a solver consumes via solve, init, or lower-level extension methods.

Interface

Concrete problem types should document the mathematical problem they encode, the accepted constructor forms, and the fields that solvers may use. Common fields are:

• f: the function, operator, or symbolic interface defining the equations.
• u0: the initial state, initial guess, or state-like data when one exists.
• tspan: the independent-variable interval for time-dependent problems.
• p: parameters, defaulting to NullParameters when omitted.
• kwargs: keyword arguments stored on the problem and forwarded to solves.
• construction-layout metadata available through problem_type when several constructors share one concrete representation.

Subtypes that expose state and parameters through symbolic indexing should implement or delegate the SymbolicIndexingInterface methods. By default, prob[sym] indexes state variables, prob.ps[sym] indexes parameters, and current_time(prob) is prob.tspan[1] for time-dependent problems. Parameter indexing through prob[sym] is reserved for state variables and errors so that parameter access remains explicit through prob.ps.

Problem types with an in-place/out-of-place function distinction should encode that choice in their type parameters and support isinplace. Problem types that allow solver aliasing should define a matching AbstractAliasSpecifier subtype and document which stored arrays may be aliased by solvers.

abstract type AbstractDEProblem <: SciMLBase.AbstractSciMLProblem

Base type for differential equation problems. Concrete subtypes encode equations whose state is advanced, constrained, or sampled over an independent-variable domain.

Interface

Differential equation problems generally provide f, u0, tspan, p, and kwargs fields, and follow the AbstractSciMLProblem symbolic indexing rules. The problem's function is usually a subtype of AbstractDiffEqFunction, or is converted to one by the concrete constructor, and its in-place choice is returned by isinplace.

Subtypes should document the mathematical form of their equation, the expected call signatures of their functions, and any additional data such as mass matrices, delays, noise processes, jumps, callbacks, or boundary conditions.

abstract type AbstractLinearProblem{bType, isinplace} <: SciMLBase.AbstractSciMLProblem

Base interface for linear system problems.

Concrete subtypes define systems such as A * u = b, optionally with an initial guess for iterative solvers. The bType parameter records the right-hand side type, and isinplace records whether the linear operator may mutate supplied storage.

Interface

Linear problems should provide A, b, u0, p, and kwargs fields. Matrix and operator-backed definitions should use public matrix/operator interfaces such as AbstractMatrix or AbstractSciMLOperator. Symbolic linear problems can provide a symbolic container through an f or symbolic_interface field so that state, parameter, and observed-value indexing delegates through SymbolicIndexingInterface.

abstract type AbstractEigenvalueProblem <: SciMLBase.AbstractSciMLProblem

Base interface for eigenvalue problems.

Concrete subtypes define standard eigenvalue problems A * v = lambda * v or generalized problems A * v = lambda * B * v.

Interface

Eigenvalue problems should provide the operator A, an optional generalized operator B, parameter storage p, optional initial guess u0, solver selection metadata such as num_eigenpairs, eigentarget, and shift, plus stored solver kwargs. Extra keyword arguments are forwarded to solvers.

abstract type AbstractNonlinearProblem{uType, isinplace} <: SciMLBase.AbstractSciMLProblem

Base interface for nonlinear solve problems f(u, p) = 0.

The uType parameter records the initial guess type, and isinplace records whether the nonlinear function writes residuals into supplied storage.

Interface

Concrete subtypes should provide f, u0, p, and kwargs fields, plus any solver-relevant bounds or problem metadata. State symbolic indexing reads and writes u0; parameter indexing is exposed through prob.ps. Constructors should wrap bare callables in an AbstractNonlinearFunction subtype when needed.

abstract type AbstractIntervalNonlinearProblem{uType, isinplace} <: SciMLBase.AbstractNonlinearProblem{uType, isinplace}

Base interface for interval nonlinear problems. These problems search for a zero of f(t, p) over an interval tspan rather than for a root near an initial state u0.

Concrete subtypes should provide f, tspan, p, and kwargs fields. The isinplace parameter records whether the function writes its value into supplied storage, and the uType parameter is available for array-valued interval residuals.

abstract type AbstractIntegralProblem{isinplace} <: SciMLBase.AbstractSciMLProblem

Base interface for integral and quadrature problems.

The isinplace parameter records whether the integrand writes into supplied storage. Concrete subtypes should document the integration domain, measure, batch or sampled semantics, and whether the integrand has the call signature f(x, p) or an in-place equivalent.

Integral problems commonly provide f, a domain or bounds field, p, and stored solver kwargs, and use NullParameters when parameters are omitted.

abstract type AbstractOptimizationProblem{isinplace} <: SciMLBase.AbstractSciMLProblem

Base interface for optimization problems.

The isinplace parameter records whether the objective or derivative callbacks write into supplied storage. Concrete subtypes encode an objective function, an initial optimizer, optional parameters, constraints, bounds, and solver keyword arguments.

Optimization problems should provide symbolic indexing metadata through their optimization function or cache when constructed from a symbolic system. Solvers that support reusable caches should use AbstractOptimizationCache.

abstract type AbstractNoiseProblem <: SciMLBase.AbstractDEProblem

Base interface for problems that directly solve or sample an AbstractNoiseProcess. Concrete noise problems should provide a noise field, a tspan, and solver keyword arguments. Their in-place behavior delegates to the stored noise process through isinplace.

abstract type AbstractODEProblem{uType, tType, isinplace} <: SciMLBase.AbstractDEProblem

Base interface for ordinary differential equation problems.

Concrete ODE problems encode equations of the form du/dt = f(u, p, t), or a mass-matrix variant represented by the function object. The uType, tType, and isinplace parameters record the initial state, promoted time span, and function mutation convention.

Interface

ODE problems should provide f, u0, tspan, p, and kwargs. A problem that preserves an alternate construction layout should extend problem_type. The function should support either f(u, p, t) or f(du, u, p, t) according to isinplace. Stored keyword arguments such as callbacks or tolerances are forwarded to solvers.

abstract type AbstractDynamicalODEProblem

Marker supertype for structured ODE problem layouts.

Subtypes identify ODE problems that are constructed from partitioned or second-order dynamics and then stored in the common ODEProblem representation. The concrete marker is available through problem_type so solvers can preserve structure when they support specialized methods.

abstract type AbstractDynamicOptProblem{uType, tType, isinplace} <: SciMLBase.AbstractODEProblem{uType, tType, isinplace}

Base interface for dynamical optimization problems represented through the ODE problem hierarchy. Concrete subtypes follow the AbstractODEProblem contract and add optimization-specific objective, control, or constraint metadata in their concrete fields.

abstract type AbstractDiscreteProblem{uType, tType, isinplace} <: SciMLBase.AbstractODEProblem{uType, tType, isinplace}

Base interface for discrete-time recurrence problems. Concrete subtypes follow the AbstractODEProblem field conventions but interpret tspan as the iteration or discrete independent-variable span and f as the state update map.

abstract type AbstractAnalyticalProblem{uType, tType, isinplace} <: SciMLBase.AbstractODEProblem{uType, tType, isinplace}

Base interface for analytical problems. Analytical problems follow the AbstractODEProblem contract while indicating that the solution is defined directly from an analytical function rather than numerical time stepping.

abstract type AbstractRODEProblem{uType, tType, isinplace, ND} <: SciMLBase.AbstractDEProblem

Base interface for random ordinary differential equation problems.

RODE problems follow the differential equation problem conventions and add a noise process that is available to the dynamics, typically through a function signature involving W(t). The ND parameter records the noise-rate prototype or dimensionality metadata used to determine diagonal versus non-diagonal noise.

abstract type AbstractSDEProblem{uType, tType, isinplace, ND} <: SciMLBase.AbstractRODEProblem{uType, tType, isinplace, ND}

Base interface for stochastic differential equation problems.

SDE problems provide a drift function, a noise function, an initial state, parameters, a time span, and noise-process metadata. Concrete subtypes commonly store the drift/noise pair as f and g, plus noise, noise_rate_prototype, seed, and kwargs.

The ND parameter records the noise-rate prototype. When it is Nothing, the problem is treated as diagonal noise by is_diagonal_noise; otherwise the prototype describes the shape of the noise-rate output.

abstract type AbstractDAEProblem{uType, duType, tType, isinplace} <: SciMLBase.AbstractDEProblem

Base interface for differential-algebraic equation problems.

Concrete DAE problems encode residual equations involving both u and du, with initial guesses for each. The uType, duType, tType, and isinplace parameters record the state, derivative state, time span, and residual mutation convention.

DAE problem subtypes should document their residual signature, usually f(resid, du, u, p, t) for in-place functions or f(du, u, p, t) for out-of-place functions, and any initialization data used to make initial conditions consistent.

abstract type AbstractDDEProblem{uType, tType, lType, isinplace} <: SciMLBase.AbstractDEProblem

Base interface for delay differential equation problems.

Concrete DDE problems follow the differential equation problem conventions and add history data plus lag metadata. The lType parameter records the lag specification type, and the function should document how it queries the history function, commonly through h(p, t) or a solver-provided history interface.

abstract type AbstractConstantLagDDEProblem{uType, tType, lType, isinplace} <: SciMLBase.AbstractDDEProblem{uType, tType, lType, isinplace}

Base interface for DDE problems whose delays are constant over the solve. Concrete subtypes follow the AbstractDDEProblem contract and should provide the constant lag collection used by discontinuity handling and method selection.

abstract type AbstractSecondOrderODEProblem{uType, tType, isinplace} <: SciMLBase.AbstractODEProblem{uType, tType, isinplace}

Base interface for second-order ODE problems. These problems are represented in the ODE hierarchy for solver interoperability, but their constructors preserve second-order structure through concrete fields or problem_type metadata.

abstract type AbstractBVProblem{uType, tType, isinplace, nlls} <: SciMLBase.AbstractODEProblem{uType, tType, isinplace}

Base interface for boundary value problems.

Concrete BVP problems follow the ODE problem conventions and add boundary condition functions and boundary data. The nlls parameter records whether the boundary conditions are interpreted in a nonlinear least-squares form.

Subtypes should document their differential equation function, boundary condition signature, initial mesh or guess, parameter storage, and how boundary residuals are laid out.

abstract type AbstractJumpProblem{P, J} <: SciMLBase.AbstractDEProblem

Base interface for jump process problems.

Jump problems wrap an inner SciML problem and a jump collection. Symbolic indexing, parameter access, state access, and current time delegate to the inner problem. Concrete subtypes should provide the wrapped problem, jump definitions, aggregation metadata, RNG/seed handling, and solver keyword arguments.

abstract type AbstractSDDEProblem{uType, tType, lType, isinplace, ND} <: SciMLBase.AbstractDEProblem

Base interface for stochastic delay differential equation problems.

SDDE problems combine the SDE and DDE contracts: they provide drift and noise functions, history data, lag metadata, noise-process metadata, parameters, and a time span. The ND parameter records noise-rate prototype metadata and the lType parameter records delay metadata.

abstract type AbstractConstantLagSDDEProblem{uType, tType, lType, isinplace, ND} <: SciMLBase.AbstractSDDEProblem{uType, tType, lType, isinplace, ND}

Base interface for SDDE problems whose delays are constant over the solve. Concrete subtypes follow the AbstractSDDEProblem contract and should provide the constant lag collection used by discontinuity handling and method selection.

abstract type AbstractPDEProblem <: SciMLBase.AbstractDEProblem

Base interface for partial differential equation problems.

SciMLBase only defines the high-level PDE problem interface. Concrete PDE problem types or discretization packages should document the symbolic or discrete PDE representation, independent/dependent variables, domains, parameters, boundary/initial conditions, and the discretization metadata needed to transform the PDE into solver-ready SciML problems.

abstract type AbstractNonlinearProblem{uType, isinplace} <: SciMLBase.AbstractSciMLProblem

Base for types which define steady-state problems, i.e. finding the u for which du/dt = f(u, p, t) = 0. This is a type alias for AbstractNonlinearProblem, since a steady state is the solution of the nonlinear system defined by the right-hand side of the differential equation.

Steady-state problem types therefore follow the nonlinear problem interface: they provide f, u0, p, and kwargs, encode the in-place convention in the isinplace parameter, and expose state and parameter data through the same symbolic indexing rules. They do not have a finite independent-variable value; SymbolicIndexingInterface.current_time(prob) returns Inf.

abstract type AbstractOptimizationCache

Base interface for reusable optimization solver caches.

Concrete caches must at least hold the optimization function, typically f <: OptimizationFunction, and parameter values p. Caches that support reinitialization may additionally provide a reinit_cache with replacement u0 and p values; reinit! and symbolic parameter access delegate through those fields when present.

mutable struct DefaultOptimizationCache{F<:OptimizationFunction, P} <: SciMLBase.AbstractOptimizationCache

Representation the default cache for an optimization problem defined by an OptimizationProblem.

promote_tspan(tspan)

Normalize a differential equation time span into the representation stored on a problem.

For a two-element tuple, promote_tspan returns promote(t1, t2) so both endpoints have a common type. A scalar tspan is interpreted as (zero(tspan), tspan). A two-element array is accepted and converted through the same tuple path, while arrays of any other length throw an error because saved output times belong in saveat, not in tspan. nothing and function-valued time spans are returned unchanged.

This function normalizes the stored value; it does not decide whether a solver supports the resulting time type. Adaptive solvers generally require a floating point independent variable, while non-adaptive solvers may support exact or custom time types when the chosen algorithm also supports them.