Skip to main content

FEM Solver Pipeline

FEM Solver Pipeline​

This page describes how a structure moves from editable model state to solved results.

Two Representations, Different Jobs

The system intentionally maintains two distinct forms of structural state, as forcing them into a single shape compromises both:

  • Editor/Runtime Representation: Optimized for interaction, selection, commands, and visual presentation.

  • Core StructuralModel: Optimized for validation, matrix assembly, solving, and design evaluation.

Preparing the Core Model

Analysis runs strictly on Core data, not raw UI state. Before solving, the current state is translated into a StructuralModel containing:

  • Nodes (with model IDs) and members (with materials, sections, and releases).

  • Supports, load cases, nodal/distributed loads, and load combinations.

The Solve Flow

Once the StructuralModel is explicitly prepared, the SamLabs.Armatura.Core.Analysis pipeline executes the following sequence:

  1. Validation / scenario preparation.

  2. Element generation from members.

  3. Local stiffness computation.

  4. Transformation to global coordinates.

  5. Global stiffness assembly.

  6. Boundary-condition application.

  7. Solving $K \cdot u = F$ (utilizing MathNet Numerics).

  8. Reaction and member-force recovery.

  9. Result-set construction / evaluation (handled separately from the raw solve).

Cases, Combinations, and Results

  • Combinations: The model solves user-defined load cases directly. Load combinations can either be explicitly stored on the model or generated dynamically (e.g., standard Eurocode combinations) via linear superposition when the evaluation workflow requires them.

  • Immutable Attachment: After analysis, the model receives a new, immutable AnalysisResultSet. The architecture relies on replacement, not mutation; when the model changes, the old result set is invalidated and replaced.

Architectural Boundaries: Why the Solver Stays Stateless

The numerical solve path is designed to be a pure computation over the prepared model state. Solving directly from editor components would blur the lines between interactive, engineering, and numerical states.

Maintaining this explicit boundary provides three major benefits:

  • Testability: Tests can build, solve, and assert on a model without needing hidden editor state.

  • Simplicity: Repeated analyses don't require nursing a long-lived solver session back into consistency, and background concurrency is safer without mutable cross-run state.

  • Future-Proofing: The editor can evolve without turning the solver into an accidental extension of the viewport.