Access
Why does high-fidelity simulation need a supercomputer?
Some of it is genuinely the physics. A surprising amount is the software: memory layouts carrying fields nobody uses, architectures that stop the compiler seeing across stage boundaries, and portability layers that reach hardware only through toolchains supporting current devices.
FigureSurface geometry as the solver receives it, rendered from the same triangulation the mesher consumes.
Why it is hard
A solver carrying several times more state per cell than it needs is bandwidth-bound, and a bandwidth-bound solver cannot afford the better numerics that would let it use a coarser mesh. The inefficiency compounds. Meanwhile every mainstream portability layer compiles through a vendor toolchain supporting current accelerators only — quietly excluding the hardware most researchers and smaller institutions actually own.
How we attack it
Treat the implementation as a scientific variable rather than an engineering afterthought: lay out state explicitly, compose the scheme at compile time so unused physics costs nothing, and fuse the passes that read the same data. That moves the solver off the bandwidth wall and leaves arithmetic headroom for richer numerics. Every parallel loop is standard C++ with no vendor kernel language, so one source is both the CPU correctness floor and the accelerator build.
What we have established
- 217 bytes per cell, audited line by line — four to six times lighter than mainstream reference codes at matched physics.
- A 2.29 M-cell airframe with live refinement runs on a single workstation inside 16 GB.
- The accelerator build is verified bit-identical to the CPU build, which is what makes performance work safe to do at all.