Technical · implementations

Calculation environments

Calculation engines are independent implementations of numerical methods. They are not the numerical methods themselves.

active sibling

GNU Octave

An active sibling engine with the broadest current workflow coverage. Its MATLAB-compatible, matrix-oriented environment supports rapid numerical development and scientific inspection.

active sibling

An active C++17 sibling engine with independent FDM/FEM/FVM resolved-case paths. It supports cross-engine verification, compiled implementation studies and LLM-assisted development; current workflow coverage remains narrower than Octave.

planned sibling

Julia

A planned third sibling engine for independent implementation and verification, with future experiments focused on numerical expressiveness and execution efficiency under equivalent, reproducible workloads.

Computational contract

How a resolved case reaches a history

Method identity, physical case, temporal configuration and engine identity remain separate. GNU Octave and C++ are active sibling implementations; Julia is the planned third sibling. Their coverage may differ, but none is designated as the scientific truth or permanent backend of another.

The multi-engine strategy serves two purposes: independent implementation verification and deliberate exploration of language/runtime trade-offs. Engine-specific strengths can be retained where they are useful as the project matures, provided equivalent numerical contracts and reproducible evidence are preserved.

Resolve the physical caseGeometry, material laws, sources, boundaries, interface data and process schedule become solver-ready inputs.
Select method and engineFDM, FEM or the restricted FVM path is selected independently from an available engine. GNU Octave and C++ are active today; Julia is planned.
Build the spatial right-hand sideFluxes, assembly, boundary closures, interface exchange and source terms are evaluated by the method adapter.
Advance the stateThe shared temporal service applies Forward Euler or AB2 according to the run specification and history policy.
Write evidence-bearing outputsTemperature histories, diagnostics and comparison metadata remain distinct from claims of physical validation.

Neutral exchange shape

resolved physical case
 spatial method
 run specification
        ↓
 solver adapter
        ↓
 semi-discrete RHS
        ↓
 FE / AB2 advance
        ↓
 history + diagnostics

Scientific tooling

Why Python is used

Python is an active supporting language in Multiphysics, but it is not currently one of the calculation engines that implements the FDM/FEM/FVM solution path. Instead, it provides scientific infrastructure around the engines and the project evidence.

Current Python tooling covers configuration and governance validation, material-data preparation and review, package/export isolation, provenance and freeze checks, semantic/naming validation, diagnostics and reference calculations, and cross-engine output comparison.

Python is useful in this role because these tasks depend heavily on automation, file and structured-data processing, schema/metadata checks and reproducible command-line workflows. Keeping them outside the calculation engines also helps the verification layer remain neutral: for example, Python compares GNU Octave and C++ histories above both engines rather than making either implementation the reference backend.

The role is therefore complementary. GNU Octave, C++ and the planned Julia implementation address independent numerical execution; Python helps prepare inputs, audit contracts, compare evidence and preserve reproducibility around those executions.

Python output is not treated as automatically authoritative merely because it is independent. Its scripts remain subject to the same provenance, review and evidence boundaries as the rest of the research software.