C++ calculation engine

The C++ engine is an active sibling calculation engine of GNU Octave. It currently has narrower process-workflow coverage, centred on independent resolved-case implementations, cross-engine verification and compiled-engine studies. Narrower coverage does not make its architectural role secondary.

1. Purpose and maturity

The C++ engine provides an independent active implementation of selected Multiphysics formulations. Its scientific purpose includes cross-language redundancy: the same resolved physical/numerical problem can be executed independently in GNU Octave and C++ and the resulting histories can then be compared above both engines.

Its current coverage is best described as:

architectural role: active sibling engine
resolved-case FDM/FEM/FVM paths: implemented
full process-workflow coverage: narrower than GNU Octave

The project also values C++ as an explicit compiled-language implementation surface that is well suited to LLM-assisted code generation, review and cross-checking. That is a development rationale, not evidence that C++ is scientifically superior to another engine.

Implementation coverage, deployment maturity, numerical verification and experimental validation are separate concepts.

2. Compatibility target

The current engine targets C++17 and the C++ standard library. Its foundation requires CMake 3.16 or newer and deliberately avoids mandatory HPC-specific libraries.

The present base implementation does not require Eigen, BLAS, OpenMP, CUDA or a vendor numerical library. Future acceleration may be added, but project policy requires such paths to carry their own reproducibility record rather than being introduced only to produce favourable timing numbers.

3. Engine structure

The public/private implementation boundary is organised around headers under engines/cpp/include/multiphysics_cpp/ and source files under engines/cpp/src/:

types.hpp          shared data structures
engine.hpp/cpp     common engine contracts and orchestration
physics.hpp/cpp    shared physical/numerical closures
fdm.hpp/cpp        finite-difference implementation
fem.hpp/cpp        finite-element implementation
fvm.hpp/cpp        finite-volume implementation path
time.hpp/cpp       temporal integration
io.hpp/cpp         resolved-case input and history output

This mirrors project concepts without requiring the C++ directory layout to be a textual copy of the Octave package tree.

4. Method and engine remain separate

FDM, FEM and FVM are numerical methods. C++ is an implementation environment. The engine currently contains resolved-case paths for all three methods, while their overall project maturity differs.

At the reviewed revision:

Method   GNU Octave                          C++
FDM      active / broad workflow coverage   active / resolved-case path
FEM      active / broad workflow coverage   active / resolved-case path
FVM      active / fixed-geometry scope      active / resolved-case path

This matrix describes implementation availability and coverage only. It is not a ranking of engines or methods, and it does not imply equal workflow coverage or equal verification depth.

5. Solver-ready input contract

Cross-engine work uses the text contract multiphysics.resolved-thermal-case.v1. The fixture is deliberately already resolved: it carries numerical geometry, time settings, boundary data, electrical input, initial state, source fields and resolved material-property laws.

It intentionally does not carry high-level identifiers such as material IDs, dataset/profile IDs, publication configuration or plotting controls. Those belong upstream from a solver-ready numerical contract.

The C++ engine therefore consumes resolved material-property functions rather than owning the project Material Library taxonomy.

6. Independent temporal integration

Implementation-specific temporal memory is not exchanged between Octave and C++. The v1 resolved-case contract requires the imported history to be invalid, so each engine initialises the configured temporal method independently.

The C++ time layer currently provides a method-neutral advance_time() path with explicit integrator configuration and method-owned memory. Forward Euler and Adams--Bashforth 2 are implemented, with AB2 using its configured starter and restart behaviour.

This matches the project-level rule that temporal integration is independent of the selected spatial method.

7. FDM path

The C++ FDM implementation is an independent transcription of the active cell-centred conservative flux-form formulation. The current engine documentation identifies the promoted positive-log(kappa) FDM path and checks it against a frozen GNU Octave reference bundle for development qualification.

The implementation remains separate source code: the C++ solver does not call Octave to obtain spatial derivatives or time steps.

8. FEM path

The C++ FEM path independently implements the current linear P1 Galerkin formulation with two-point Gauss quadrature, row-sum lumped mass and the cell-centred half-cell capacity/source completion used by the active model.

Shared physical closures such as distant-end exchange and welding-interface thermal/electrical coupling are represented according to the same model contracts, while their code is native to the C++ engine.

9. FVM path

A C++ FVM resolved-case path is implemented with a two-point cell-centred control-volume operator. This does not mean that FVM has the same overall project stage coverage as FDM/FEM. The public project status therefore keeps FVM in the partial / under-development category until its broader method-level scope and verification are closed.

10. Output contract

Resolved-case runs write multiphysics.temperature-history.v1 CSV output. The history contains the states from step zero to the final step, local R/S distance from the interface, and the reconstructed interface temperature.

The verification-export metadata currently includes:

classification=development-cross-verification
timing_authoritative=false

This classification belongs to the exported verification artifact and its benchmark maturity, not to the C++ engine. C++ remains an active calculation engine. The metadata prevents resolved-case parity files from being mistaken for a formal performance benchmark campaign.

11. Cross-engine comparison

Cross-engine tooling sits outside both implementations:

resolved case
    |--------------------|
    v                    v
 GNU Octave             C++
    |                    |
    v                    v
 temperature history   temperature history
    |____________________|
              |
              v
       neutral comparison

Same-method/different-engine comparison is the primary parity question. A cross-method comparison such as FDM versus FEM is possible but is explicitly a different verification question and therefore requires an opt-in mismatch flag in the comparison tool.

The current default tolerances are development gates, not frozen publication or formal benchmark tolerances.

12. Tests and build surface

The C++ engine uses CMake/CTest and has unit/smoke coverage for common engine operations, FDM, FEM, FVM, physics, I/O and temporal integration. Resolved-case integration fixtures exercise the solver-ready path.

A typical development build is:

cmake -S engines/cpp -B build/cpp-engine -DCMAKE_BUILD_TYPE=Release
cmake --build build/cpp-engine --parallel
ctest --test-dir build/cpp-engine --output-on-failure

Performance numbers are intentionally excluded from the public technical claim set until the project freezes equivalent inputs, tolerances and a benchmark protocol including compiler, CPU, OS, warm-up/iteration rules and timing scope.

13. Relationship to GNU Octave and Julia

GNU Octave and C++ are active sibling engines; neither is implemented as a backend of the other. This is essential to the verification strategy: agreement between independently maintained implementations can expose transcription defects, while shared disagreement can still reveal a problem in the common model or formulation.

Julia is planned as a third sibling engine. It is being considered both to add another independent implementation path and to investigate whether its numerical language/runtime model offers useful execution-efficiency or expressiveness advantages on selected workloads. No Julia performance advantage is claimed before equivalent cases and a reproducible benchmark protocol exist.

Cross-engine agreement therefore remains implementation-verification evidence, not proof that the physical model has been experimentally validated.

14. Current limitations and publication boundary

The C++ engine is active, but its current process-workflow coverage remains narrower than GNU Octave's. Its resolved-case paths should therefore not be presented as complete workflow parity. This coverage distinction does not turn C++ into a secondary or disposable verification-only engine.

MPX documents only the public technical architecture and maturity state. Private case material, restricted datasets and unpublished collaboration information remain outside the generated website.