DEV Community

Cover image for SCPN Fusion Core: A Control-First, Neuro-Symbolic Software Stack for Tokamak Plasma Control
Miroslav Šotek
Miroslav Šotek

Posted on

SCPN Fusion Core: A Control-First, Neuro-Symbolic Software Stack for Tokamak Plasma Control

SCPN-FUSION-CORE ON GITHUB

We built an open-source software laboratory that treats tokamak plasma control as a compiler problem. Control logic is expressed in formally verifiable Petri nets, compiled to spiking neural networks, and executed at sub-microsecond latencies against physics-informed plant models. It is not a replacement for billion-dollar physics solvers. It is a framework for building, validating, and hardening control algorithms before they touch billion-dollar hardware.

Why Fusion Control Needs a New Software Stack

Nuclear fusion is having a moment. SPARC is aiming for Q ≥ 10. ITER is commissioning its plasma control system. Dozens of private companies are racing toward net energy. But behind the headlines, a quieter crisis is unfolding: the software that controls these machines is not keeping up with the physics.

Tokamak control is a trilemma. You need:

  1. Physical realism — the controller must respect magnetohydrodynamics, transport, and stability limits.
  2. Real-time execution — plasma evolution happens in milliseconds; control loops must close in microseconds.
  3. Auditable safety — when a plasma disrupts, the cost is measured in millions of dollars and months of downtime. The control logic must be inspectable, reproducible, and bounded.

Most existing tools optimize one vertex of this triangle and leave the others informal. Physics codes like GENE, CGYRO, or TRANSP solve the first problem brilliantly, but they run for hours on supercomputers. Control systems like the ITER Plasma Control System (PCS) solve the second and third, but they are bespoke, proprietary, and hard to test against realistic physics outside of the machine itself.

We started SCPN Fusion Core with a simple inversion: make control the primary artifact, and treat physics as the plant model it operates against.

The SCPN Approach: Three Unusual Bets

Bet 1: Control-First Architecture

Instead of solving transport equations and then "bolting on" a controller, we designed the stack from the control loop outward. The central abstraction is a stochastic Petri net — a graph of places, transitions, and contracts that encodes control logic in a formally inspectable way. This net compiles to a spiking neural network (SNN) of leaky integrate-and-fire (LIF) neurons, which executes at hardware-compatible latencies.

The pipeline looks like this:

Petri Net (places + transitions + safety contracts)
    |
    v  compiler.py — structure-preserving mapping
Stochastic LIF Network (neurons + synapses + thresholds)
    |
    v  controller.py — closed-loop execution
Real-Time Plasma Control (sub-millisecond, deterministic replay)
    |
    v  artifact.py — versioned, signed compilation artifact
Deployment Package (JSON + schema + git SHA)
Enter fullscreen mode Exit fullscreen mode

This is not a metaphor. The compiler is implemented in Python, the real-time kernel is in Rust, and the compilation artifact is a signed, schema-versioned JSON bundle that can be audited before deployment.

Bet 2: Evidence-Bounded Claims

Fusion software has a credibility problem. It is easy to write a module called gyrokinetic_transport.py and imply that it replaces a $50M code. It is much harder to prove it.

We adopted a fail-closed validation philosophy. Every scientific claim in the repository is tracked in a machine-readable report with an explicit status:

  • Accepted: Same-case evidence exists, checksums match, thresholds pass.
  • Blocked: The claim is not yet supported by external reference data.

For example, our native nonlinear gyrokinetic solver has explicit invariant benchmarks and electromagnetic residual diagnostics, but its full-fidelity status is blocked until it produces same-case comparison artifacts against GENE, CGYRO, or GS2. The report is public, the debug traces are row-level, and the thresholds are declared in advance. We do not hide incomplete work in prose.

This makes the repository useful before plant deployment. It is a place to test controller architectures, benchmark kernel choices, and build the documentation discipline needed for later hardware-in-the-loop work.

Bet 3: Formal Verification in Lean 4

Real-time control of a burning plasma is a safety-critical problem. We believe that claims about safety properties should be machine-checkable, not just well-intentioned.

SCPN Fusion Core includes a committed Lean 4 proof surface. The first machine-checkable theorems prove that:

  • Invalid Grad-Shafranov case descriptions fail closed (validation errors propagate exactly).
  • PID saturation bounds are preserved under normalization and filtering.
  • Petri net reachability and token boundedness are preserved by the SNN compiler.

These are intentionally narrow boundaries — we are not claiming to have verified the full plasma solver. But they are a start, and no other open-source fusion project has them.


Architecture at a Glance

The repository is a polyglot workspace:

Layer Technology Role
Control Compiler Python Petri net → SNN compilation, contract checking, artifact packaging
Real-Time Kernels Rust (11 crates) PID, MPC, transport, ML inference, PyO3 bindings
Physics Models Python + JAX Grad-Shafranov, 1.5D transport, gyrokinetic operators, MHD stability
Validation Python + Rust Benchmark pipelines, reference data, report generation
Formal Proofs Lean 4 Safety theorems, CI-checked

Key Numbers

  • 0.52 µs — Rust PID kernel step latency (P50), measured via Criterion on an Intel i5-11600K.
  • 10.5 µs — Closed-loop hardware-in-the-loop step latency (P50).
  • 413 µs — Rust full-order Grad-Shafranov SOR solve (33×33).
  • ~24 ns — QLKNN-10D neural transport surrogate per-point inference.
  • 3,815 — Test functions (Hypothesis property-based tests in Python, proptest in Rust).
  • 74 — Validation scripts producing tracked reports.

The Three-Path Gyrokinetic Design

We expose three gyrokinetic transport lanes with explicit fidelity limits:

Path Fidelity Speed Module
A: External GK Reference (when installed) Minutes to CPU-hours GENE, CGYRO, GS2, TGLF, QUALIKIZ adapters
B: Native GK Linear + nonlinear 5D operator contracts ~0.3 s/surface linear gk_eigenvalue, gk_quasilinear, gk_nonlinear
C: Hybrid Surrogate+GK Adaptive ~24 ns/point QLKNN + OOD detector + online corrector

The hybrid layer validates neural surrogates against GK spot-checks in real time. External adapters carry explicit metadata distinguishing linear from nonlinear electrostatic/electromagnetic models. We do not bundle or replace those solvers; we validate against them.


What We Built vs. What We Blocked

Honesty is cheaper than hype. Here is the current capability matrix with explicit blockers:

Built and validated (local contracts):

  • Neuro-symbolic SNN compiler with deterministic replay
  • Rust real-time PID/MPC kernels
  • 1.5D coupled transport solver (JAX-differentiable)
  • QLKNN-10D and FNO neural surrogates
  • Native linear gyrokinetic eigenvalue solver
  • 7-criterion MHD stability suite
  • Disruption chain (thermal quench → current quench → runaway → halo)
  • Lean 4 safety proofs for validation error propagation and PID boundedness

Blocked (waiting for same-case external parity):

  • Full nonlinear 5D gyrokinetic turbulence parity vs. GENE/CGYRO/GS2
  • Full kinetic runaway-electron distribution parity vs. DREAM
  • Charge-state-resolved impurity transport parity vs. Aurora/STRAHL
  • EFIT-grade free-boundary equilibrium reconstruction
  • Production-scale MPI/multi-GPU scaling evidence

The blocked items are not hidden. They are tracked in validation/reports/ with row-level debug traces, explicit threshold declarations, and deterministic CI behavior.


How It Compares

Capability SCPN TORAX FUSE FreeGSNKE DREAM
Control-first architecture Yes No No No No
Neuro-symbolic SNN compiler Yes No No No No
Real-time kernel <1 µs 0.52 µs No No No No
Formal verification Lean 4 No No No No
JAX autodiff transport Yes Yes No No No
1.5D coupled transport Yes Yes Yes No No
Neural transport surrogate QLKNN-10D QLKNN-7/10D No No No
Full GK turbulence Blocked TGLF only TGLF only No No
Full kinetic runaway Blocked No No No Yes
Free-boundary GS Partial No No Yes No

The positioning: TORAX is a physics-first transport simulator with excellent JAX autodiff. FUSE is a reactor design framework with OpenMC neutronics. FreeGSNKE is an equilibrium reconstruction tool. DREAM is the runaway-electron gold standard. SCPN is the control layer that can interface with all of them. We are not trying to replace them. We are trying to make it possible to test control algorithms against them without a tokamak.


Who This Is For

  • Fusion control researchers who need a fast, differentiable plant model to prototype controllers.
  • Validation engineers who need reproducible benchmark pipelines with explicit fidelity gates.
  • Accelerator/GPU teams who need deterministic decomposition contracts for production scaling.
  • Formal methods contributors who want to extend machine-checkable safety proofs to physical systems.
  • Investors evaluating whether a fusion team's control software is reproducible before the team has a machine.

Try It

# Install (Python only, Rust optional)
pip install -e .

# Run a Grad-Shafranov equilibrium
scpn-fusion kernel

# Run the tokamak flight simulator
scpn-fusion flight

# Run the validation suite
pytest tests/ -x -q

# Run the Golden Base notebook
jupyter notebook examples/neuro_symbolic_control_demo_v2.ipynb

# Or spin up the Streamlit dashboard
docker compose up --build  # localhost:8501
Enter fullscreen mode Exit fullscreen mode

The Rust backend is optional but recommended for real-time work:

cd scpn-fusion-rs
cargo build --release && cargo test
cargo bench  # Criterion benchmarks
Enter fullscreen mode Exit fullscreen mode

The Road Ahead

The next milestones are narrow and specific:

  1. One accepted full-fidelity artifact. We are working to produce a same-case nonlinear gyrokinetic comparison against GENE. One accepted row changes the narrative from "blocked" to "validated."
  2. Hardware validation. We are seeking partnerships with university tokamaks to validate the SNN controller on real hardware. Even a single shot with a compiled Petri-net controller would be a landmark.
  3. Extended formal proofs. The Lean surface will expand to cover SNN deterministic replay over seeded stochastic traces, and matrix-level incidence preservation against the Python compiler artifact.
  4. Security hardening. We are adding a formal threat model, input fuzzing for GEQDSK/IMAS parsers, and a safety certification roadmap for industrial adoption.

License & Commercial Use

SCPN Fusion Core is released under AGPL-3.0. This keeps the open-source stack free and inspectable. For commercial use in proprietary plant software, a separate commercial license is available: protoscience@anulum.li.


Citation

@software{scpn_fusion_core,
  title   = {SCPN Fusion Core: Neuro-Symbolic Tokamak Control Suite},
  author  = {Sotek, Miroslav},
  year    = {2026},
  url     = {https://github.com/anulum/scpn-fusion-core},
  version = {3.9.9}
}
Enter fullscreen mode Exit fullscreen mode

Join Us

We are looking for contributors in Rust real-time systems, JAX differentiable physics, formal verification, and tokamak experimental physics. If you believe that control software for fusion should be open, inspectable, and evidence-bounded, we would like to hear from you.


The project is currently at version 3.9.9. It is not viral. It is not a startup. It is a software laboratory. We are building it because someone has to. We appreciate sharing, Likes, Contributions, Sponsoring / Donations to keep us going, we are open for collaboration.

Kindest Regards, Miroslav Šotek, lead researcher.



Enter fullscreen mode Exit fullscreen mode

Top comments (0)