Skip to content

Theory notes

The mechanics inside the solver — element formulations, sign conventions, numerical assumptions and their limits.

Theory notes 1 min read

These notes describe what the solver actually does, so you can check the tool instead of trusting it. An element whose formulation is not written down cannot be defended in a review.

In this section

The solver in one paragraph

Elementarium assembles a global stiffness matrix from element contributions, applies boundary conditions, and solves — by default with a preconditioned conjugate-gradient iteration, or with a sparse direct factorisation if you choose one (see Choosing a linear solver). The core is C++ compiled to WebAssembly, threaded across your cores where the browser grants cross-origin isolation and single-threaded where it does not.

Solution procedure

  1. Element stiffness matrices are formed in local coordinates and transformed to global.
  2. Contributions are assembled into a sparse global matrix.
  3. Constraints (supports, releases, rigid links) are applied.
  4. Every load case is solved, all of them in one pass. A linear combination is then the factored sum of the load-case results; nothing is solved again.
  5. Element results are recovered from the displacement field.

Step 4 is why fifty combinations cost little more than one, and why superposition is available at all. The direct stiffness method walks through each step.

Numerical assumptions

AssumptionConsequence
Linear elastic materialNo yielding, cracking or creep
Small displacementsEquilibrium on the undeformed geometry
Static loadingNo inertia except in modal analysis
Perfect nodal connectivityMembers meeting at a node share degrees of freedom unless released
Consistent units throughoutEnforced by the model, not by convention

Verification

Every element type is exercised against closed-form solutions before anything merges: cantilever and simply supported beams, plate bending benchmarks, buckling of standard columns, and frequencies with analytical answers. A benchmark that disagrees with theory by more than the discretisation error allows is a bug, and we would rather hear about it from you than not at all.

That is our floor, not your evidence. Verifying the solver lists the same cases with their formulas so that you can run them yourself.

Something wrong or unclear on this page? Tell us, and it gets corrected.