Struct FlattenedSystem 

pub struct FlattenedSystem {

    pub independent_variables: Vec<String>,
    pub state_variables: IndexMap<String, ModelVariable>,
    pub parameters: IndexMap<String, ModelVariable>,
    pub observed_variables: IndexMap<String, ModelVariable>,
    pub algebraic_variables: IndexMap<String, ModelVariable>,
    pub brownian_parameters: IndexMap<String, ModelVariable>,
    pub discrete_parameters: IndexMap<String, ModelVariable>,
    pub field_ics: Vec<(String, Expr)>,
    pub equations: Vec<Equation>,
    pub equation_contributions: Vec<Vec<Contribution>>,
    pub equation_lifted: Vec<bool>,
    pub continuous_events: Vec<ContinuousEvent>,
    pub discrete_events: Vec<DiscreteEvent>,
    pub domain: Option<Domain>,
    pub index_sets: IndexMap<String, IndexSet>,
    pub function_tables: IndexMap<String, FunctionTable>,
    pub template_registry: IndexMap<String, Value>,
    pub loader_fields: Vec<LoaderField>,
    pub lifted_shapes: IndexMap<String, Vec<i64>>,
    pub metadata: FlattenMetadata,
}

Spec-compliant flattened coupled system (§4.7.5).

The shape matches the Julia and Python flattened systems: real Expr-tree equations (not strings), ordered variable maps for deterministic iteration, and full provenance metadata.

Fields

independent_variables: Vec<String>

Independent variables, derived per esm-libraries-spec §4.7.6 “Independent-variable computation”: ["t"] for a 0-D system or a DISCRETIZED one (whose spatial axes have been folded into faq dimensions and so name no axis any more), and ["t", <spatial axes>] for a system still carrying undiscretized spatial differentials.

This is what decides whether a downstream constructor builds an ODESystem or a PDESystem, so an undiscretized spatial operator must REACH this struct rather than be rejected before it. t comes first; the spatial axes follow in DOCUMENT ORDER — the order the equation scan first encounters them, which is the order the document names them and the order a downstream array layout follows.

state_variables: IndexMap<String, ModelVariable>

The SOLVED-FOR VECTOR, dot-namespaced and with full metadata: the differential unknowns, PLUS Self::algebraic_variables, PLUS any arrayed observed that materializes into a buffer (esm-libraries-spec §4.7.5 step 4).

parameters: IndexMap<String, ModelVariable>

Dot-namespaced parameters. variable_map with param_to_var or conversion_factor transform removes entries from this map.

observed_variables: IndexMap<String, ModelVariable>

The dot-namespaced unknowns an equation DEFINES, at either LHS spelling (esm-spec §6.3.1). NOT disjoint from Self::state_variables: a scalar observed is eliminated by substitution and is in this map alone, while an arrayed one materializes into a buffer and is in both.

algebraic_variables: IndexMap<String, ModelVariable>

Unknowns constrained ONLY by an expression-LHS equation (H*H*SO4 ~ Ksp, esm-spec §6.3.1). A SUBSET of Self::state_variables, not a sibling bucket: state_variables is the SOLVED-FOR VECTOR and a DAE solves for its algebraic unknowns, so removing them from that map would emit a u vector that silently omits them (esm-libraries-spec §4.7.5 step 4).

brownian_parameters: IndexMap<String, ModelVariable>

Dot-namespaced Brownian noise sources — parameters whose update.kind is "wiener". A SUBSET of Self::parameters: esm-spec §6.3.1 says the four parameter sets partition the parameters, so a wiener entry IS a parameter and also appears here. Excluding it from parameters would make the parameter vector’s LENGTH depend on whether the model happens to be stochastic, and leave the four sets partitioning nothing. Non-empty is exactly what §6.3.1’s system_kind derivation tests FIRST, so carrying this map is what keeps the flattened form able to report "sde".

discrete_parameters: IndexMap<String, ModelVariable>

Dot-namespaced DISCRETE parameters — any OTHER update, i.e. piecewise-constant between refreshes. Likewise a SUBSET of Self::parameters.

field_ics: Vec<(String, Expr)>

Deferred scoped-reference / array ic equations (esm-spec §11.4.1), classified out of equations by flatten. Each entry is (target_state, rhs) where target_state names the (post-lift, grid- shaped) state variable and rhs is the initial-field expression — a bare reference to a provider-served loaded field (e.g. InitialConditions.O3_init) or a broadcast constant. The array simulator folds these into u0 cell-by- cell at build time, reading the loaded field from the data-Provider seam (DESIGN pde_simulation_pipeline §2 R2). Empty for a system with no ic equations, so the ordinary ODE path is unaffected.

equations: Vec<Equation>

Flattened equations in processing order. Every variable reference is dot-namespaced.

equation_contributions: Vec<Vec<Contribution>>

Per-term provenance (esm-libraries-spec §4.7.5): one entry per entry of Self::equations, in the same order. Entry i lists the summands whose LEFT-FOLD sum is equations[i]’s right-hand side (or, for an equation the pointwise lift wrapped in a faq, that faq’s body), each with the component or coupling entry that authored it. flatten builds every right-hand side from this list. Empty only on a system assembled by hand rather than by flatten.

A public pass that rebuilds a right-hand side from this list first checks that the list still sums to it; a caller who edited rhs after flatten keeps the edit, and that equation’s list collapses to one contribution carrying every origin the list named.

equation_lifted: Vec<bool>

One entry per entry of Self::equations: true where the pointwise lift (esm-spec §10.5) wrapped the equation in an faq over the grid, so that Self::equation_contributions sums to the faq body rather than to the right-hand side. An authored faq right-hand side is false. Empty (and omitted when serialized) when nothing was lifted.

continuous_events: Vec<ContinuousEvent>

Continuous events from every component, LHS rewritten to namespaced form.

discrete_events: Vec<DiscreteEvent>

Discrete events from every component, LHS rewritten to namespaced form.

domain: Option<Domain>

The file’s single shared domain, passed through (v0.8.0).

index_sets: IndexMap<String, IndexSet>

The document-scoped index_sets registry (esm-spec v0.8.0), passed through verbatim from the source EsmFile. Carried so a coupled (multi-model) array system reaching the array runtime via crate::simulate_array::ArrayCompiled::from_flattened can resolve faq ranges { "from": <set> }, join.on gates, and derived-set references against it — exactly as the single-model from_file path resolves them against file.index_sets. Empty for a file that declares no index sets, so the ordinary ODE path is unaffected.

function_tables: IndexMap<String, FunctionTable>

The document-scoped function_tables registry (esm-spec §9.5), copied from the source EsmFile in document order. Carried so a surviving table_lookup node resolves without re-reading the source document (esm-libraries-spec §4.7.5 step 4).

template_registry: IndexMap<String, Value>

The MERGED expression-template registry (esm-spec §9.6.4 rule 7, §10.7; esm-libraries-spec §4.7.5 step 4): the union of the per-component registries with each model’s carried bodies component-SCOPED first, deep-equal same-name entries deduplicated at first occurrence, and a non-deep-equal same-name collision renamed to <ComponentPath>.<name> in every owning component with the rename propagated along the reference DAG. See [merged_template_registry].

loader_fields: Vec<LoaderField>

The provider-served loaded fields this system consumes (esm-spec §8.5): one descriptor per PARAMETER carrying a data-kind update, in the document order of Self::parameters.

lifted_shapes: IndexMap<String, Vec<i64>>

Concrete integer grid shapes assigned by the pointwise spatial lift (esm-spec §10.5) to each lifted state variable, e.g. {"Chemistry.O3": [4, 2]}. Empty when no lift ran.

metadata: FlattenMetadata

Provenance metadata.

Implementations

impl FlattenedSystem

pub fn system_kind(&self) -> SystemKind

The flattened system’s DERIVED kind (esm-spec §6.3.1) — "sde" / "pde" / "nonlinear" / "ode", tested in that order.

Available on the flattened form precisely because Self::brownian_parameters survives flattening: the derivation’s first row is “any parameter in brownian_parameters”, so a FlattenedSystem that dropped the bucket could not report "sde" and a consumer would integrate a stochastic system as a deterministic one (esm-libraries-spec §4.7.5 step 4).

Trait Implementations

impl Clone for FlattenedSystem

fn clone(&self) -> Self

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for FlattenedSystem

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl<'de> Deserialize<'de> for FlattenedSystem

fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error>

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl<'a> From<&'a FlattenedSystem> for ProblemInput<'a>

fn from(f: &'a FlattenedSystem) -> Self

Converts to this type from the input type.

impl Serialize for FlattenedSystem

fn serialize<__S>(&self, __serializer: __S) -> Result<__S::Ok, __S::Error>

where __S: Serializer,

Serialize this value into the given Serde serializer.