Platform
A solver where performance and rigour are the same decision, a way to run it on any hardware without rewriting it, and a build that makes a result reproducible.
Architecture
Most solvers are assembled at runtime: a dictionary selects a model, a virtual call dispatches it, and that flexibility is paid for on every cell of every timestep — while stopping the compiler seeing across stage boundaries.
Here the equations, flux, reconstruction, gradients, closure, chemistry and integrator are all template parameters, composed at compile time into one fused update. Comparing two schemes means changing one token, with a guarantee nothing else moved.
That guarantee is not an aesthetic preference. It is what makes the attribution experiments behind our open questionsmean anything.
Compile-time policies
Fig. 01From case to hardware. The parallelism contract in the middle is the whole portability argument: everything above it is standard C++, everything below it is interchangeable.
Component 01
Compressible and reactive finite-volume solver with GPU-native adaptive refinement
Profiling a 2.29 M-cell airframe sweep put the flux kernel at a third of the cost, gradients at a fifth, the viscous face sweep at a seventh — all three re-streaming the same data from memory. Because every stage is a compile-time policy rather than a virtual call, they fuse into one pass over the faces. A runtime-dispatched architecture cannot express that.
Fields are structures of arrays from a pooled allocator, and a closure you did not select contributes no branch, no field, no byte per cell. Hence 217 B/cell, audited line by line. Halo exchange is a few per cent of step time, so the solver is limited by arithmetic — the resource that keeps getting cheaper.
The adapt chain
Every stage is a data-parallel pass. The host never sees the tree.
Fig. 02Seven stages, no serial tree walk and no host-side regridding step. Cells are addressed by integer-lattice Morton keys, so refine, balance and remap reduce to sort, scan and scatter — the primitives a GPU is built for.
Fig. 03Levels flagged by a solution sensor around a curved front, two-to-one balanced.
Fig. 04In-house generation: background mesh, castellation and carving against the surface, then snapping — all under a single outward-winding face invariant.
Component 02
Standard C++ parallel algorithms, offloaded to any vendor's GPU
Every mainstream GPU portability layer — Kokkos, RAJA, SYCL, OpenMP target offload, ISO C++ parallel algorithms — eventually compiles through a vendor compiler supporting a narrow and shrinking set of current accelerators. The effect is to abandon the one- and two-generation-old hardware most researchers and smaller institutions own.
Vulkan with SPIR-V has genuine all-vendor breadth down to old silicon, and is used almost exclusively for machine-learning inference — essentially never for PDE solvers.
Parallax lowers standard C++ parallel algorithms to SPIR-V and dispatches them through Vulkan compute. No annotations, no custom allocators, no second code path: the translation unit that builds for CPU threads builds for the GPU. A 2014-era mobile part sustained 744 M elements/s on it.
That turns leanness into access: a solver that fits a consumer GPU, plus a runtime that reaches one of any brand and vintage.
Component 03
Hermetic, content-addressed build and package toolchain
A result is only reproducible if a third party can regenerate it. In practice that is defeated long before the numerics — by a compiler minor version, a library resolved differently, a timestamp baked into an object file.
Existing tools each solve a fragment: packaging, or determinism, or HPC combinatorics. None is light enough for one scientist. Rivet is built for that case — declare dependencies, commit the lockfile, and the same binary comes out on another machine. We wrote it because byte-identical results across refactors are unenforceable if the toolchain underneath drifts.
Next
The open questions this machinery exists to answer.