Developer Interface

The supported user workflow is deliberately small: construct a POD from state snapshots, then call reduce! with one of the built-in backends, SVD, TSVD, or RSVD. Continuous-time LTI systems can be reduced with baltrunc, and polynomial reduced models can be learned from snapshot/derivative data with opinf. The public API does not require users to interact with the abstract types described below.

POD reduction contract

POD accepts either an AbstractMatrix{T} whose columns are state snapshots or an AbstractVector{<:AbstractVector{T}} containing state snapshots, with T <: AbstractFloat. All snapshots must describe the same state dimension. The positional nmodes form fixes the retained rank. The keyword form selects the rank from min_renergy, min_nmodes, and max_nmodes.

The reduction contract is:

Construct pod = POD(snapshots, nmodes) or POD(snapshots; kwargs...).
Call reduce!(pod, SVD()), reduce!(pod, TSVD()), or reduce!(pod, RSVD()).
Read pod.rbasis, pod.spectrum, pod.nmodes, and pod.renergy after the call.

reduce! mutates pod and returns nothing. The three concrete backends are the supported choices; their keyword arguments are forwarded to their respective SVD implementations as described in the API reference.

julia> using ModelOrderReduction

julia> snapshots = [1.0 0.0; 0.0 1.0];

julia> pod = POD(snapshots, 1);

julia> reduce!(pod, SVD()); pod.nmodes
1

Reduction pipeline

deim and pod reduce a system in three internal steps. The source system is first brought into the explicit first-order form described by ModelOrderReduction.FullOrderModel, whose right-hand sides are split by ModelOrderReduction.separate_terms into a numeric linear part, forcing terms, and the state-dependent terms handled by interpolation or Galerkin projection. The POD state basis (and, for DEIM, the nonlinear basis) are then computed from the snapshot. Finally, the reduced system is assembled with one array differential equation for the reduced state and one reconstruction equation per ModelOrderReduction.SourceField.

pod applies plain Galerkin projection $V^T f(V\\hat y)$. When the source equations are written as array (or field) residuals, that projection is kept as array linear algebra so the generated graph does not grow with the grid. deim adds hyper-reduction of the nonlinear residual so the online cost stays independent of the full-order dimension as well. These types and functions are internal and may change without notice.

ModelOrderReduction.FullOrderModel — Type

struct FullOrderModel{S, T}

Explicit first-order form of a source system, prepared for projection.

Structural simplification eliminates the algebraic equations of the source system. The remaining differential unknowns are the dynamic unknowns, and their right-hand sides are split as linear * unknowns + forcing + nonlinear: linear holds the numeric linear coefficients, forcing holds the terms free of dynamic unknowns, and nonlinear holds every other state-dependent term, including linear terms with symbolic coefficients.

This type is internal and is not part of the public API.

Fields

system::Any: source system, before structural simplification
iv::Any: independent variable
source_unknowns::Vector{Any}: scalar unknowns of the source system, in snapshot row order
fields::Vector{ModelOrderReduction.SourceField}: source unknowns grouped by symbolic variable
unknowns::Vector{Any}: dynamic unknowns of the explicit first-order form
rows::Vector{Int64}: snapshot row of each dynamic unknown
linear::SparseArrays.SparseMatrixCSC{Float64, Int64}: numeric linear coefficients of the dynamic right-hand sides
forcing::Vector{Symbolics.Num}: state-independent terms of the dynamic right-hand sides
nonlinear::Vector{Symbolics.Num}: state-dependent terms of the dynamic right-hand sides handled by interpolation
parameters::Vector{Any}: model parameters of the explicit form
parameter_values::Dict{Any, Any}: numeric parameter values used for training and as reduced-model defaults
observed::Vector{Symbolics.Equation}: source observed equations that do not define a source unknown

source

ModelOrderReduction.SourceField — Type

struct SourceField

Scalar unknowns of a source system that belong to one symbolic variable.

Fields

variable::Any: the array variable, or the scalar unknown itself
rows::Vector{Int64}: snapshot rows of the elements, in column-major order for an array variable
shape::Tuple{Vararg{Int64}}: array shape, or () for a scalar unknown

source

ModelOrderReduction.separate_terms — Function

separate_terms(
    exprs::AbstractVector,
    vars::AbstractVector
) -> Tuple{SparseArrays.SparseMatrixCSC{Float64, Int64}, Any, Any}

Split each expression in exprs as linear * vars + forcing + nonlinear.

linear is a sparse matrix holding the numeric coefficients of terms that are linear in vars. forcing collects the additive terms that do not depend on vars. nonlinear collects every remaining term, so it also holds terms that are linear in vars with a symbolic coefficient.

Variables in vars must be unique.

source

Internal type hierarchy

The following abstract types are implementation details. They are documented so that contributors can understand the source hierarchy, but they are not exported and are not stable extension points:

ModelOrderReduction.AbstractReductionProblem — Type

AbstractReductionProblem

Internal common supertype for model-reduction problem types.

This type is not exported and is not a supported extension point. User code should construct one of the documented concrete problem types instead.

source

ModelOrderReduction.AbstractDRProblem — Type

AbstractDRProblem <: AbstractReductionProblem

Internal marker type for data-reduction problems such as POD.

This type is not exported and is not a supported extension point. Use the documented POD constructors and reduce! methods instead.

source

ModelOrderReduction.AbstractSVD — Type

AbstractSVD

Internal supertype for the built-in singular-value-decomposition backends.

This type is not exported and is not a supported extension point. The supported backends are SVD, TSVD, and RSVD; custom subtypes and additional reduce! dispatches are not part of the public API.

source

Do not subtype these types, dispatch on them from downstream packages, or add new reduce! methods for custom algorithm types. Such methods would depend on internal dispatch and field invariants that are not covered by the public API. If a supported extension point is needed, it should first be designed and documented as a separate interface with generic tests.