Implementation · GNU Octave

GNU Octave implementation

technical preview source 967e466af56c reviewed 2026-10-02
Engine
GNU Octave
Implementation status
active sibling / broad workflow coverage
Provenance and source references
Source revision
967e466af56ccc5fc41c939464096e5d72c19c37
Operator revision
not recorded
Curated authority records
4
Curated implementation records
8
Curated verification records
5
On this page
  1. 1. Role in the project
  2. 2. Canonical entry points
  3. 3. Solver registry
  4. 4. Solver adapters
  5. 5. Process orchestration
  6. 6. Spatial method packages
  7. 7. Shared numerical services
  8. 8. Physical and numerical ownership
  9. 9. Verification surfaces
  10. 10. Relationship to the C++ and Julia engines
  11. 11. Current limitations and publication boundary

GNU Octave implementation

GNU Octave is one of the active sibling calculation engines of the Multiphysics project. It currently has the broadest process-workflow coverage, but this does not make it the scientific reference or permanent primary engine. This page describes software architecture and execution flow; it does not redefine the FDM, FEM or FVM numerical formulations.

1. Role in the project

The Octave codebase is the original calculation environment and remains an active sibling of the C++ engine. Numerical method identity remains independent from engine identity: FDM, FEM and FVM are spatial methods, while GNU Octave is one implementation environment capable of hosting those methods.

Octave is retained deliberately because its MATLAB-compatible language and high-level matrix/vector operations make numerical prototyping, array-oriented data manipulation, diagnostics and comparison with MATLAB-oriented scientific workflows straightforward. These are engine-specific advantages, not grounds for treating Octave results as scientific truth.

The project remains in research-development. Octave currently has the broadest end-to-end process-workflow coverage, while the C++ sibling has a narrower resolved-case surface. Coverage and architectural status are separate: both engines are active. FDM and FEM are implemented. FVM is also implemented for the fixed-geometry/current-heating scope, and that target is implemented-and-verified under the R2 attestation. Broader geometry-changing welding stages remain unpromoted, so the package-level capability is still limited in scope; this is a capability boundary, not an unfinished fixed-geometry solver.

2. Canonical entry points

New solver execution is expected to enter through the method-neutral API:

ctx = multiphysics.api.create_context('fdm', case_id);
[T, T_sample, memory] = multiphysics.api.run_stage( ...
    ctx, 'current_heating', profile, 1, 1, stage_input, nsteps);

create_context() combines four things without collapsing their meanings:

  • a selected spatial method;
  • a physical/research case loaded from the project configuration layer;
  • a RunSpecification carrying numerical execution choices such as target

spacing and time step;

  • a solver factory obtained from the central solver registry.

The resulting context stores the method, resolved case, component metadata, run specification, solver adapter and the registry entry used to construct it.

3. Solver registry

+multiphysics/+api/solver_registry.m is the central registry for spatial solver plugins. A method-specific entry declares whether the solver is implemented, its factory, contract version and advertised capabilities.

The architectural intention is that adding a new spatial method requires its own solver package and registry entry, rather than adding method branches to the shared physics or process engine.

At the current reviewed revision, the registry exposes:

FDM  implemented   independent spatial solver
FEM  implemented   independent spatial solver
FVM  implemented   fixed geometry/current heating verified; geometry-changing unpromoted

The public website therefore describes FVM as implemented for a verified fixed-geometry scope while keeping geometry-changing welding capability explicitly unpromoted.

4. Solver adapters

Each active spatial method supplies a small adapter with a shared shape:

solver.id
solver.operator_id
solver.operator_revision
solver.case
solver.run_spec
solver.config
solver.step_fn

For example, the FDM adapter binds the current FDM runtime constants and fdm_core_step, while the FEM adapter binds its own runtime constants and fem_core_step. The shared process engine depends on the adapter contract, not on a hard-coded FDM or FEM implementation.

This is the key separation:

physical case + run specification
             |
             v
       create_context()
             |
             v
       solver registry
             |
       +-----+-----+
       |           |
      FDM         FEM        ...
       |           |
       +-----+-----+
             |
             v
      shared process engine

5. Process orchestration

multiphysics.api.run_stage() delegates to the solver-independent run_stage_engine(). The shared engine owns process chronology, state chaining, remapping/event handling, sampling and stage-handler dispatch. A spatial solver supplies the spatial step through solver.step_fn.

The process controller therefore does not duplicate a complete sequence for FDM and another for FEM. Stage bodies live under the shared process namespace, and stage dispatch is itself registry-based.

For schedule-oriented studies, run_process() reads the process schedule from the case and chains the stage outputs and private integrator memory through the selected solver.

6. Spatial method packages

Method-specific Octave code is organised under:

+multiphysics/+solvers/+fdm/
+multiphysics/+solvers/+fem/
+multiphysics/+solvers/+fvm/

FDM and FEM currently separate method-specific concerns into areas such as:

configuration/
numerics/
runtime/
stages/       historical compatibility surface
variants/     historical compatibility surface

The stages/, variants/ and main.m compatibility APIs are retained for transition/regression purposes. Current project documentation directs new code toward create_context() + run_stage() instead of those historical wrappers.

7. Shared numerical services

Not every numerical operation belongs inside a spatial-method tree. Shared services live under +multiphysics/+numerics/, including:

  • boundary/interface numerical support;
  • interpolation;
  • meshes;
  • remapping;
  • temporal integration.

The time integrator is intentionally method-neutral. After a spatial solver constructs a semi-discrete right-hand side, multiphysics.numerics.time.advance() selects the configured temporal algorithm. The current implementation supports primary Forward Euler and Adams--Bashforth 2 with its configured starter/restart policy.

Private integrator memory remains a numerical object distinct from the physical state and from the scientific process history.

8. Physical and numerical ownership

The Octave solver trees do not own the universal definitions of materials, physical interface laws or stage semantics. Those responsibilities are shared project-level concepts and are resolved upstream or through common modules.

Consequently, changing from FDM to FEM should not redefine:

  • the identity of R and S workpiece roles;
  • the physical thermal-contact law;
  • the physical distant-end condition;
  • the material dataset identity;
  • the process schedule itself.

Only the appropriate numerical representation changes.

9. Verification surfaces

The Octave implementation has separate verification surfaces for architecture and for individual spatial methods. Examples include solver-registry tests, canonical-API versus historical-wrapper equivalence, process-sequence tests, FDM conservation/refinement tests and FEM assembly/stability tests.

test_api_wrapper_equivalence.m specifically checks that direct use of the canonical context/stage API reproduces the historical wrapper outputs for the covered FDM and FEM calls, including the carried AB2 history objects.

These tests are implementation evidence. Their existence must not be interpreted as experimental validation of the underlying physical model.

10. Relationship to the C++ and Julia engines

GNU Octave and C++ are active sibling engines. The Octave implementation does not call the C++ engine, and the C++ engine does not call Octave. Cross-language comparison is intentionally performed above both engines through resolved-case fixtures and neutral comparison tooling.

This prevents one implementation from becoming an opaque backend of the other and makes cross-engine agreement useful as independent implementation evidence. Julia is planned as a third sibling rather than as a replacement. Its eventual role is to reproduce selected formulations independently and to investigate language/runtime trade-offs under equivalent numerical and benchmark contracts.

11. Current limitations and publication boundary

This page documents architecture visible in the reviewed private source revision. It does not expose private cases, unpublished datasets or restricted collaboration material. It also does not claim that every registered method has the same stage coverage or verification maturity.

The canonical private repository remains the implementation authority. MPX is a curated public technical view of that state rather than an independently edited copy of the solver code.