There are many ways to build a fusion device: tokamaks, stellarators, Z-pinches, mirrors, laser and beam driven inertial fusion, magneto-inertial schemes, and more. Most open software picks one of them. We wanted something different: a catalogue where every concept is described in the same way, so they can be compared honestly.
So we split it up. Today there are 21 device-family repositories, one per concept, plus a shared kernel library and a general tokamak physics toolkit. All of them are open.
What one family repository contains
Take the Z-pinch repository as an example. It has five parts:
- a validated configuration model of the device;
- diagnostic and timing semantics, so a measurement plan is explicit;
- level-0 physics from the concept's own literature (for a Z-pinch: Bennett equilibrium, ideal-MHD/Kadomtsev stability limits, Shumlak–Hartman, Pease–Braginskii);
- a 3D mesh exported as STL and glTF;
- a B-rep CAD model exported as deterministic STEP.
The test suite runs with 100 % statement and branch coverage, and native Rust implementations are compared with the Python ones.
What "level-0" means here
This is the part I like most, because it says what the code does not do. In the project's own words, level-0 means "closed-form models from the device's own literature, evaluated on the validated configuration, without solving any equation". No equilibrium or stability equation is solved. Reactivity, yield, gain and breakeven are out of scope.
That sounds modest, and it is on purpose. It gives every concept the same honest baseline before anyone builds a solver on top of it.
Bit patterns, not tolerances
Where a kernel exists in both Python and Rust, parity tests compare float64 bit patterns, never tolerances. If the two implementations differ in the last bit, the test fails.
To keep that manageable, the numerical kernels live in exactly one place, a shared library, so no device repository carries a second copy. The README also says plainly that those kernels are not correctly rounded.
What we do not claim
The family READMEs state the same boundary, and I think it is the most useful sentence in the whole catalogue:
- the models are not machine-ready, not safety-certified and not reactor-ready;
- there is no solver, no controller, no experimental correlation and no dataset yet;
- no parameter set describes or validates any real machine.
The tokamak repository, for example, models the cylindrical periodic equivalent of a tokamak, not a specific device. The Z-pinch and tokamak repositories have no release or DOI yet.
What comes next
The same pattern is planned for 29 more families: fission (PWR, BWR, MSR, SFR, HTGR and others), chemical reactors (kinetics, catalytic beds, reformers, electrochemical, biochemical) and hybrids such as nuclear hydrogen production. The plans are written; the repositories do not exist yet. After that comes Reactor Studio, where a concept can be designed in 3D/CAD, simulated and compared side by side.
Try it
- Shared kernels: scpn-reactor-kernels
- Example families: scpn-z-pinch-core, scpn-tokamak-core
- Tokamak physics and control research: scpn-fusion-core
- The full list of families: github.com/anulum
If you work on any of these concepts, I would value a critical look at the level-0 models for "your" device: which closed-form limit would you check first?
We are a pre-seed lab and this work is funded through GitHub Sponsors. This article was drafted with help from AI agents from our own repository documentation; I reviewed and edited the text.
Top comments (2)
you scamming motherfuckers