Algebraic Problem Types

Defines a linear system problem. Documentation Page: https://docs.sciml.ai/LinearSolve/stable/basics/LinearProblem/

Mathematical Specification of a Linear Problem

Concrete LinearProblem

To define a LinearProblem, you simply need to give the AbstractMatrix$A$ and an AbstractVector$b$ which defines the linear system:

\[Au = b\]

Matrix-Free LinearProblem

For matrix-free versions, the specification of the problem is given by an operator A(u,p,t) which computes A*u, or in-place as A(du,u,p,t). These are specified via the AbstractSciMLOperator interface. For more details, see the SciMLBase Documentation.

Note that matrix-free versions of LinearProblem definitions are not compatible with all solvers. To check a solver for compatibility, use the function needs_concrete_A(alg::AbstractLinearAlgorithm).

Problem Type

Constructors

Optionally, an initial guess $u₀$ can be supplied which is used for iterative methods.

LinearProblem{isinplace}(A, b, p = NullParameters(); u0 = nothing, kwargs...)
LinearProblem(f::AbstractSciMLOperator, b, p = NullParameters(); u0 = nothing, kwargs...)

isinplace optionally sets whether the function is in-place or not, i.e. whether the solvers are allowed to mutate. By default this is true for AbstractMatrix, and for AbstractSciMLOperators it matches the choice of the operator definition.

Parameters are optional, and if not given, then a NullParameters() singleton will be used, which will throw nice errors if you try to index non-existent parameters. Any extra keyword arguments are passed on to the solvers.

Fields

• A: The representation of the linear operator.
• b: The right-hand side of the linear system.
• p: The parameters for the problem. Defaults to NullParameters. Currently unused.
• u0: The initial condition used by iterative solvers.
• symbolic_interface: An instance of SymbolicLinearInterface if the problem was generated by a symbolic backend.
• kwargs: The keyword arguments passed on to the solvers.

Defines a standard or generalized eigenvalue problem.

Mathematical Specification of an Eigenvalue Problem

The standard problem finds pairs $(λ, v)$ satisfying

\[A v = λ v\]

If a second operator B is supplied, the generalized problem is solved instead:

\[A v = λ B v\]

Type Promotion Rules

• The eigenvector type follows u0 when it is supplied: typeof(v) == typeof(u0). Otherwise, eigenvectors are returned as the dense vector type corresponding to a row of A (e.g. sparse A still returns dense eigenvectors).
• The eigenvalue type follows eltype(A): typeof(lambda) == eltype(A) whenever the eigenvalues are real (e.g. A symmetric or Hermitian). For a general, non-symmetric real A, eigenvalues may be complex conjugate pairs, in which case typeof(lambda) == Complex{eltype(A)}.

Problem Type

Constructors

EigenvalueProblem(
    A, B = nothing, p = NullParameters();
    num_eigenpairs = nothing, eigentarget = EigenvalueTarget.LargestMagnitude,
    shift = nothing, u0 = nothing, kwargs...
)

Keyword Arguments

• num_eigenpairs: the number of eigenpairs (eigenvalues together with their eigenvectors) to compute. nothing (the default) requests every eigenpair for the dense solver, or a solver-chosen default for the iterative backends.
• eigentarget: which part of the spectrum to return, as an EigenvalueTarget. Defaults to the eigenvalues of largest magnitude.
• shift: if supplied, return the eigenvalues nearest this shift (shift-and-invert).
• u0: optional initial guess for the iterative backends.

Any extra keyword arguments are passed on to the solver.

Fields

• A: the operator whose eigenvalues are sought.
• B: the second operator for a generalized problem, or nothing for a standard one.
• num_eigenpairs: the requested number of eigenpairs.
• eigentarget: the EigenvalueTarget selecting the part of the spectrum.
• shift: the shift for shift-and-invert, or nothing.
• u0: the initial guess used by iterative solvers.
• p: the parameters for the problem. Defaults to NullParameters.
• kwargs: the keyword arguments passed on to the solvers.

EigenvalueTarget

Enum selecting which part of the spectrum is returned when only a subset of the eigenpairs is requested (via num_eigenpairs) in an EigenvalueProblem.

Eigenvalues of largest magnitude, abs(λ) largest.

Eigenvalues of smallest magnitude, abs(λ) smallest.

Eigenvalues with the largest (most positive) real part.

Eigenvalues with the smallest (most negative) real part.

Eigenvalues with the largest (most positive) imaginary part.

Eigenvalues with the smallest (most negative) imaginary part.

Defines a nonlinear system problem. Documentation Page: https://docs.sciml.ai/NonlinearSolve/stable/basics/nonlinear_problem/

Mathematical Specification of a Nonlinear Problem

To define a Nonlinear Problem, you simply need to give the function $f$ which defines the nonlinear system:

\[f(u,p) = 0\]

and an initial guess $u₀$ of where f(u, p) = 0. f should be specified as f(u, p) (or in-place as f(du, u, p)), and u₀ should be an AbstractArray (or number) whose geometry matches the desired geometry of u. Note that we are not limited to numbers or vectors for u₀; one is allowed to provide u₀ as arbitrary matrices / higher-dimension tensors as well.

Problem Type

Constructors

NonlinearProblem(f::NonlinearFunction, u0, p = NullParameters(); kwargs...)
NonlinearProblem{isinplace}(f, u0, p = NullParameters(); kwargs...)

isinplace optionally sets whether the function is in-place or not. This is determined automatically, but not inferred.

Parameters are optional, and if not given, then a NullParameters() singleton will be used, which will throw nice errors if you try to index non-existent parameters. Any extra keyword arguments are passed on to the solvers. For example, if you set a callback in the problem, then that callback will be added in every solve call.

For specifying Jacobians and mass matrices, see the nonlinear function types page of the SciMLBase interface documentation.

Fields

• f: The function in the problem.
• u0: The initial guess for the root.
• p: The parameters for the problem. Defaults to NullParameters.
• lb: Lower bounds for the solution. Defaults to nothing.
• ub: Upper bounds for the solution. Defaults to nothing.
• kwargs: The keyword arguments passed on to the solvers.

struct ImmutableNonlinearProblem{uType, iip, P, F, K, PT} <: SciMLBase.AbstractNonlinearProblem{uType, iip}

An immutable counterpart to NonlinearProblem that carries the same f, u0, p, problem_type, and kwargs data.

Because the struct and its fields are immutable, an ImmutableNonlinearProblem built from isbits components is itself isbits. That makes it usable from contexts which cannot allocate or mutate — most importantly inside GPU kernels, where solver packages construct one per thread and hand it to a non-allocating nonlinear solver. Use NonlinearProblem for ordinary host-side solves; reach for this type when the problem must cross into a kernel or otherwise stay allocation-free.

Constructors mirror NonlinearProblem, and remake is supported.

struct StandardNonlinearProblem

Marker for standard nonlinear problem layouts.

StandardNonlinearProblem() is the default problem_type metadata for nonlinear problems represented directly by a residual function and either an initial guess or an interval. Solver code may inspect this marker through problem_type when it needs to distinguish the standard residual layout from specialized nonlinear problem encodings, while generic nonlinear code should rely on the AbstractNonlinearProblem fields and traits instead.

Defines an interval nonlinear system problem. Documentation Page: https://docs.sciml.ai/NonlinearSolve/stable/basics/nonlinear_problem/

Mathematical Specification of an Interval Nonlinear Problem

To define a Nonlinear Problem, you simply need to give the function $f$ which defines the nonlinear system:

\[f(t,p) = u = 0\]

along with an interval tspan, $t ∈ [t_0,t_f]$, within which the root should be found. f should be specified as f(t,p) (or in-place as f(u,t,p)), and tspan should be a Tuple{T,T} where T <: Number.

Problem Type

Constructors

IntervalNonlinearProblem(f::NonlinearFunction, tspan, p = NullParameters(); kwargs...)
IntervalNonlinearProblem{isinplace}(f, tspan, p = NullParameters(); kwargs...)

isinplace optionally sets whether the function is in-place or not. This is determined automatically, but not inferred.

Parameters are optional, and if not given, then a NullParameters() singleton will be used, which will throw nice errors if you try to index non-existent parameters. Any extra keyword arguments are passed on to the solvers. For example, if you set a callback in the problem, then that callback will be added in every solve call.

Fields

• f: The function in the problem.
• tspan: The interval in which the root is to be found.
• p: The parameters for the problem. Defaults to NullParameters.
• kwargs: The keyword arguments passed on to the solvers.

Defines a nonlinear least squares problem.

Mathematical Specification of a Nonlinear Least Squares Problem

To define a Nonlinear Problem, you simply need to give the function $f$ which defines the nonlinear system:

\[\min_x ‖ f(x, p) ‖\]

and an initial guess $u_0$ for the minimization problem. $f$ should be specified as $f(u, p)$ (or in-place as $f(du, u, p)$), and $u_0$ should be an AbstractArray (or number) whose geometry matches the desired geometry of $u$. Note that we are not limited to numbers or vectors for $u_0$; one is allowed to provide $u_0$ as arbitrary matrices / higher-dimension tensors as well.

Problem Type

Constructors

NonlinearLeastSquaresProblem(f::NonlinearFunction, u0, p = NullParameters(); kwargs...)
NonlinearLeastSquaresProblem{isinplace}(f, u0, p = NullParameters(); kwargs...)

isinplace optionally sets whether the function is in-place or not. This is determined automatically, but not inferred.

Parameters are optional, and if not given, then a NullParameters() singleton will be used, which will throw nice errors if you try to index non-existent parameters.

For specifying Jacobians and mass matrices, see the nonlinear function types page of the SciMLBase interface documentation.

Fields

• f: The function in the problem.
• u0: The initial guess for the solution.
• p: The parameters for the problem. Defaults to NullParameters.
• lb: Lower bounds for the solution. Defaults to nothing.
• ub: Upper bounds for the solution. Defaults to nothing.
• kwargs: The keyword arguments passed on to the solvers.

SCCNonlinearProblem(probs, explicitfuns!)

Defines an SCC-split nonlinear system to be solved iteratively.

Mathematical Specification of an SCC-Split Nonlinear Problem

An SCC-Split Nonlinear Problem is a system of nonlinear equations

\[f(u,p) = 0\]

with the special property that its Jacobian is in block-lower-triangular form. In this form, the nonlinear problem can be decomposed into a system of nonlinear systems.

\[\begin{align*} f_1(u_1,p) &= 0 \\ f_2(u_2,u_1,p) &= 0 \\ f_3(u_3,u_2,u_1,p) &= 0 \\ & ⋮ \\ f_n(u_n,…,u_3,u_2,u_1,p) &= 0 \end{align*}\]

Splitting the system in this form can have multiple advantages, including:

• Improved numerical stability and robustness of the solving process
• Improved performance due to using smaller Jacobians

The SCC-Split Nonlinear Problem is the ordered collection of nonlinear systems to solve in order solve the system in the optimized split form.

Representation

The representation of the SCCNonlinearProblem is via an ordered collection of NonlinearProblems, probs, with an attached explicit function for pre-processing a cache. This can be interpreted as follows:

\[\begin{align*} p_1 &= g_1(u,p) & f_1(u_1,p_1) &= 0 \\ p_2 &= g_2(u,p) & f_2(u_2,u_1,p_2) &= 0 \\ p_3 &= g_3(u,p) & f_3(u_3,u_2,u_1,p_3) &= 0 \\ & ⋮ \\ p_n &= g_n(u,p) & f_n(u_n,…,u_3,u_2,u_1,p_n) &= 0 \\ \end{align*}\]

where $g_i$ is explicitfuns![i]. In a computational sense, explictfuns! is instead a mutating function explictfuns![i](prob.probs[i],sols) which updates the values of prob.probs[i] using the previous solutions sols[i-1] and below.

Example

For the following nonlinear problem:

function f(du, u, p)
    du[1] = cos(u[2]) - u[1]
    du[2] = sin(u[1] + u[2]) + u[2]
    du[3] = 2u[4] + u[3] + 1.0
    du[4] = u[5]^2 + u[4]
    du[5] = u[3]^2 + u[5]
    du[6] = u[1] + u[2] + u[3] + u[4] + u[5] + 2.0u[6] + 2.5u[7] + 1.5u[8]
    du[7] = u[1] + u[2] + u[3] + 2.0u[4] + u[5] + 4.0u[6] - 1.5u[7] + 1.5u[8]
    du[8] = u[1] + 2.0u[2] + 3.0u[3] + 5.0u[4] + 6.0u[5] + u[6] - u[7] - u[8]
    return
end
prob = NonlinearProblem(f, zeros(8))
sol = solve(prob)

The split SCC form is:

cache = zeros(3)

function f1(du, u, cache)
    du[1] = cos(u[2]) - u[1]
    du[2] = sin(u[1] + u[2]) + u[2]
    return
end
explicitfun1(cache, sols) = nothing
prob1 = NonlinearProblem(NonlinearFunction{true, SciMLBase.NoSpecialize}(f1), zeros(2), cache)
sol1 = solve(prob1, NewtonRaphson())

function f2(du, u, cache)
    du[1] = 2u[2] + u[1] + 1.0
    du[2] = u[3]^2 + u[2]
    du[3] = u[1]^2 + u[3]
    return
end
explicitfun2(cache, sols) = nothing
prob2 = NonlinearProblem(NonlinearFunction{true, SciMLBase.NoSpecialize}(f2), zeros(3), cache)
sol2 = solve(prob2, NewtonRaphson())

function f3(du, u, cache)
    du[1] = cache[1] + 2.0u[1] + 2.5u[2] + 1.5u[3]
    du[2] = cache[2] + 4.0u[1] - 1.5u[2] + 1.5u[3]
    du[3] = cache[3] + + u[1] - u[2] - u[3]
    return
end
prob3 = NonlinearProblem(NonlinearFunction{true, SciMLBase.NoSpecialize}(f3), zeros(3), cache)
function explicitfun3(cache, sols)
    cache[1] = sols[1][1] + sols[1][2] + sols[2][1] + sols[2][2] + sols[2][3]
    cache[2] = sols[1][1] + sols[1][2] + sols[2][1] + 2.0sols[2][2] + sols[2][3]
    cache[3] = sols[1][1] + 2.0sols[1][2] + 3.0sols[2][1] + 5.0sols[2][2] + 6.0sols[2][3]
    return
end
explicitfun3(cache, [sol1, sol2])
sol3 = solve(prob3, NewtonRaphson())
manualscc = [sol1; sol2; sol3]

sccprob = SciMLBase.SCCNonlinearProblem(
    [prob1, prob2, prob3],
    SciMLBase.Void{Any}.([explicitfun1, explicitfun2, explicitfun3])
)

Note that this example aliases the parameters together for a memory-reduced representation.

Problem Type

Constructors

Fields

• probs: the collection of problems to solve
• explictfuns!: the explicit functions for mutating the parameter set

Defines a one-parameter homotopy nonlinear problem. This is the embedding / natural-parameter continuation problem type. It is unrelated to HomotopyNonlinearFunction, which supports polynomial homotopy continuation (e.g. via HomotopyContinuation.jl).

Mathematical Specification of a Homotopy Problem

To define a Homotopy Problem, you give the residual function $f$

\[0 = f(u, p, λ)\]

where $λ ∈ \texttt{λspan}$ is the scalar continuation parameter, passed to f as a separate trailing argument after the parameters p. A continuation solver sweeps $λ$ from λspan[1] to λspan[2], warm-starting each step from the previous solution; the target system is the one at λspan[2].

Problem Type

Constructors

HomotopyProblem(f::NonlinearFunction, u0, p = NullParameters(); λspan = (0.0, 1.0), kwargs...)
HomotopyProblem{isinplace}(f, u0, p = NullParameters(); λspan = (0.0, 1.0), kwargs...)

isinplace optionally sets whether the function is in-place or not. This is determined automatically, but not inferred. The residual follows the time-dependent argument convention with $λ$ in place of t:

• out-of-place: f(u, p, λ)
• in-place: f(du, u, p, λ)

Fields

• f: The residual function, called as f(u, p, λ) (or f(du, u, p, λ) in-place). Optional derivative fields of the wrapped NonlinearFunction (jac, jac_prototype, sparsity, colorvec, ...), if provided, must follow the same λ-extended argument convention, e.g. jac(u, p, λ) (or jac(J, u, p, λ) in-place); they are consumed by NonlinearSolve.jl's continuation solvers. Pass lambda_extended = true to the NonlinearFunction constructor so that jac, jvp, and vjp are validated against the λ-extended arities instead of the standard nonlinear ones.
• u0: The initial guess (a solution of the simplified system at λspan[1]).
• p: The parameters, passed through to f unchanged; $λ$ is not part of p.
• λspan: the (start, stop) continuation interval; the target system is at stop.
• kwargs: The keyword arguments passed on to the solvers.

Defines an integral problem. Documentation Page: https://docs.sciml.ai/Integrals/stable/

Mathematical Specification of an Integral Problem

Integral problems are multi-dimensional integrals defined as:

\[∫_{lb}^{ub} f(u,p) du\]

where p are parameters. u is a Number or AbstractVector whose geometry matches the space being integrated. This space is bounded by the lower bound lb and upper bound ub, which are Numbers or AbstractVectors with the same geometry as u.

Problem Type

Constructors

IntegralProblem(f::AbstractIntegralFunction, domain, p = NullParameters(); kwargs...)
IntegralProblem(f::AbstractIntegralFunction, lb, ub, p = NullParameters(); kwargs...)
IntegralProblem(f, domain, p = NullParameters(); nout = nothing, batch = nothing, kwargs...)
IntegralProblem(f, lb, ub, p = NullParameters(); nout = nothing, batch = nothing, kwargs...)

• f: the integrand, callable function y = f(u,p) for out-of-place (default) or an IntegralFunction or BatchIntegralFunction for inplace and batching optimizations.
• domain: an object representing an integration domain, i.e. the tuple (lb, ub).
• lb: DEPRECATED: Either a number or vector of lower bounds.
• ub: DEPRECATED: Either a number or vector of upper bounds.
• p: The parameters associated with the problem.
• nout: DEPRECATED (see IntegralFunction): length of the vector output of the integrand (by default the integrand is assumed to be scalar)
• batch: DEPRECATED (see BatchIntegralFunction): number of points the integrand can evaluate simultaneously (by default there is no batching)
• kwargs: Keyword arguments copied to the solvers.

Additionally, we can supply iip like IntegralProblem{iip}(...) as true or false to declare at compile time whether the integrator function is in-place.

Fields

The fields match the names of the constructor arguments.

Defines a integral problem over pre-sampled data. Documentation Page: https://docs.sciml.ai/Integrals/stable/

Mathematical Specification of a data Integral Problem

Sampled integral problems are defined as:

\[∑_i w_i y_i\]

where y_i are sampled values of the integrand, and w_i are weights assigned by a quadrature rule, which depend on sampling points x.

Problem Type

Constructors

SampledIntegralProblem(y::AbstractArray, x::AbstractVector; dim = ndims(y), kwargs...)

• y: The sampled integrand, must be a subtype of AbstractArray. It is assumed that the values of y along dimension dim correspond to the integrand evaluated at sampling points x
• x: Sampling points, must be a subtype of AbstractVector.
• dim: Dimension along which to integrate. Defaults to the last dimension of y.
• kwargs: Keyword arguments copied to the solvers.

Fields

The fields match the names of the constructor arguments.

Defines an optimization problem. Documentation Page: https://docs.sciml.ai/Optimization/stable/API/optimization_problem/

Mathematical Specification of an Optimization Problem

To define an optimization problem, you need the objective function $f$ which is minimized over the domain of $u$, the collection of optimization variables:

\[\min_u f(u,p)\]

$u₀$ is an initial guess for the minimizer. f should be specified as f(u,p) and u₀ should be an AbstractArray whose geometry matches the desired geometry of u. Note that we are not limited to vectors for u₀; one is allowed to provide u₀ as arbitrary matrices / higher-dimension tensors as well.

Problem Type

Constructors

OptimizationProblem{isinplace}(
    f, u0, p = SciMLBase.NullParameters();
    lb = nothing,
    ub = nothing,
    lcons = nothing,
    ucons = nothing,
    sense = nothing,
    problem_type = nothing,
    kwargs...
)

isinplace optionally sets whether the function is in-place or not. This is determined automatically, but not inferred. Note that for OptimizationProblem, in-place refers to the objective's derivative functions, the constraint function and its derivatives. OptimizationProblem currently only supports in-place.

Parameters p are optional, and if not given, then a NullParameters() singleton will be used, which will throw nice errors if you try to index non-existent parameters.

lb and ub are the upper and lower bounds for box constraints on the optimization variables. They should be an AbstractArray matching the geometry of u, where (lb[i],ub[i]) is the box constraint (lower and upper bounds) for u[i].

lcons and ucons are the upper and lower bounds in case of inequality constraints on the optimization and if they are set to be equal then it represents an equality constraint. They should be an AbstractArray, where (lcons[i],ucons[i]) are the lower and upper bounds for cons[i].

The f in the OptimizationProblem should typically be an instance of OptimizationFunction to specify the objective function and its derivatives either by passing predefined functions for them or automatically generated using the ADType.

If f is a standard Julia function, it is automatically transformed into an OptimizationFunction with NoAD(), meaning the derivative functions are not automatically generated.

Any extra keyword arguments are captured to be sent to the optimizers.

Fields

• f: the function in the problem.
• u0: the initial guess for the optimization variables.
• p: Either the constant parameters or fixed data (full batch) used in the objective or a MLUtilsDataLoader for minibatching with stochastic optimization solvers. Defaults to NullParameters.
• lb: the lower bounds for the optimization variables u.
• ub: the upper bounds for the optimization variables u.
• int: integrality indicator for u. If int[i] == true, then u[i] is an integer variable. Defaults to nothing, implying no integrality constraints.
• lcons: the vector of lower bounds for the constraints passed to OptimizationFunction. Defaults to nothing, implying no lower bounds for the constraints (i.e. the constraint bound is -Inf)
• ucons: the vector of upper bounds for the constraints passed to OptimizationFunction. Defaults to nothing, implying no upper bounds for the constraints (i.e. the constraint bound is Inf)
• sense: the objective sense, can take MaxSense or MinSense from Optimization.jl.
• problem_type: an optional tag describing the origin of the problem, returned by problem_type. PDE discretizations store their AbstractDiscretizationMetadata here so that wrap_sol can wrap the optimization solution into a PDENoTimeSolution.
• kwargs: the keyword arguments passed on to the solvers.

Inequality and Equality Constraints

Both inequality and equality constraints are defined by the f.cons function in the OptimizationFunction description of the problem structure. This f.cons is given as a function f.cons(u,p) which computes the value of the constraints at u. For example, take f.cons(u,p) = u[1] - u[2]. With these definitions, lcons and ucons define the bounds on the constraint that the solvers try to satisfy. If lcons and ucons are nothing, then there are no constraints bounds, meaning that the constraint is satisfied when -Inf < f.cons < Inf (which of course is always!). If lcons[i] = ucons[i] = 0, then the constraint is satisfied when f.cons(u,p)[i] = 0, and so this implies the equality constraint u[1] = u[2]. If lcons[i] = ucons[i] = a, then $u[1] - u[2] = a$ is the equality constraint.

Inequality constraints are then given by making lcons[i] != ucons[i]. For example, lcons[i] = -Inf and ucons[i] = 0 would imply the inequality constraint u[1] <= u[2] since any f.cons[i] <= 0 satisfies the constraint. Similarly, lcons[i] = -1 and ucons[i] = 1 would imply that -1 <= f.cons[i] <= 1 is required or -1 <= u[1] - u[2] <= 1.

Note that these vectors must be sized to match the number of constraints, with one set of conditions for each constraint.

Data handling

As described above the second argument of the objective definition can take a full batch or a DataLoader object for mini-batching which is useful for stochastic optimization solvers. Thus the data either as an Array or a DataLoader object should be passed as the third argument of the OptimizationProblem constructor. For an example of how to use this data handling, see the Sophia example in the Optimization.jl documentation or the mini-batching tutorial.

ConvexOptimizationProblem{iip}(
    f, u0, p = NullParameters();
    constraints = nothing, lb = nothing, ub = nothing, int = nothing,
    sense = MinSense, kwargs...
)

Experimental. A disciplined-convex-programming problem: minimize (or maximize) a convex objective subject to convex cone constraints. Unlike a general OptimizationProblem — where the objective is an arbitrary nonlinear function solved to a local optimum — the objective and constraints of a ConvexOptimizationProblem are certified convex, so a conic backend (for example ConvexOptimization.jl, lowering each atom to a MathOptInterface cone and calling a solver such as Clarabel) can return a global optimum together with dual multipliers — the dual field of the returned OptimizationSolution, which convex solves populate by default (see default_calculate_dual).

Fields / keyword arguments

• f: an OptimizationFunction or a callable f(u, p) giving the convex objective. A symbolic objective lets the backend certify curvature and reformulate each atom into a cone.
• u0: the decision variables / initial point.
• p: parameters, treated as first-class affine data. A problem that is affine in p can be re-solved cheaply (and differentiated) by updating p through remake without re-running canonicalization.
• constraints: the convex constraints as cone memberships (equalities, inequalities, second-order / positive-semidefinite / exponential / power cones). The concrete representation is defined by the solving backend; nothing denotes an unconstrained (or bound-only) problem.
• lb, ub: elementwise lower/upper bounds on u0. If either is supplied, both must be.
• int: boolean mask marking integer-valued decision variables (mixed-integer convex programming).
• sense: MinSense (default) or MaxSense.

Defines a steady state ODE problem. Documentation Page: https://docs.sciml.ai/DiffEqDocs/stable/types/steady_state_types/

Mathematical Specification of a Steady State Problem

To define a Steady State Problem, you simply need to give the function $f$ which defines the ODE:

\[\frac{du}{dt} = f(u, p, t)\]

and an initial guess $u_0$ of where f(u, p, t) = 0. f should be specified as f(u, p, t) (or in-place as f(du, u, p, t)), and u₀ should be an AbstractArray (or number) whose geometry matches the desired geometry of u. Note that we are not limited to numbers or vectors for u₀; one is allowed to provide u₀ as arbitrary matrices / higher dimension tensors as well.

Note that for the steady-state to be defined, we must have that f is autonomous, that is f is independent of t. But the form which matches the standard ODE solver should still be used. The steady state solvers interpret the f by fixing $t = ∞$.

Problem Type

Constructors

SteadyStateProblem(f::ODEFunction, u0, p = NullParameters(); kwargs...)
SteadyStateProblem{isinplace, specialize}(f, u0, p = NullParameters(); kwargs...)

isinplace optionally sets whether the function is inplace or not. This is determined automatically, but not inferred. specialize optionally controls the specialization level. See Specialization Levels for more details. The default is AutoSpecialize.

Parameters are optional, and if not given, a NullParameters() singleton will be used, which will throw nice errors if you try to index non-existent parameters. Any extra keyword arguments are passed on to the solvers. For example, if you set a callback in the problem, then that callback will be added in every solve call.

Additionally, the constructor from ODEProblems is provided:

SteadyStateProblem(prob::ODEProblem)

Parameters are optional, and if not given, a NullParameters() singleton will be used, which will throw nice errors if you try to index non-existent parameters. Any extra keyword arguments are passed on to the solvers. For example, if you set a callback in the problem, then that callback will be added in every solve call.

For specifying Jacobians and mass matrices, see the DiffEqFunctions page.

Fields

• f: The function in the ODE.
• u0: The initial guess for the steady state.
• p: The parameters for the problem. Defaults to NullParameters
• lowered_problem: An optional non-transient problem that this steady-state problem lowers to, used by NonlinearProblem conversions in place of wrapping f directly. May be an AbstractSciMLProblem (used verbatim) or a callable prob -> problem evaluated on the current problem, so that symbolic frontends can defer the lowering until it is needed while still reflecting remaked u0/p values. Defaults to nothing.
• kwargs: The keyword arguments passed onto the solves.

Special Solution Fields

The SteadyStateSolution type is different from the other DiffEq solutions because it does not have temporal information.

struct AnalyticalProblem{uType, tType, isinplace, P, F, K} <: AbstractAnalyticalProblem{uType, tType, isinplace}

Problem wrapper for systems solved by an analytical function.

AnalyticalProblem stores the analytical function, initial state, time span, parameters, and solver keyword arguments. The function follows the same in-place or out-of-place convention as differential-equation functions, while the concrete analytical solver decides how to evaluate it across tspan.

Fields

• f::Any

• u0::Any

• tspan::Any

• p::Any

• kwargs::Any