Benchmarking PINNs Against Finite-Element Solvers
Kronos validates every physics PINN against reference finite-element and finite-difference solvers before it is trusted in the twin.
Why benchmark at all
A PINN is a surrogate for a PDE solution, and surrogates can be confidently wrong. Before any PINN enters KRONOS-CTRL, Kronos benchmarks it against established mesh solvers, finite-element Grad-Shafranov codes for equilibrium, eigenvalue MHD codes for stability, on a battery of cases spanning the operating space and, deliberately, its edges.
- Accuracy: flux-map L2 error and boundary-shape error vs FEM reference
- Derived quantities: q-profile, delta, kappa, X-point position agreement
- Stability: growth-rate and marginal-boundary agreement vs eigenvalue code
- Extrapolation: behavior just outside the training envelope (must degrade gracefully)
The trade the benchmark quantifies
FEM is the accuracy reference but is too slow for the 50-100 ms shadow; the PINN is fast but approximate. The benchmark quantifies exactly how much accuracy is traded for speed and where. Kronos accepts a PINN only if its error is bounded below the tolerance the consuming controller needs, for shape control that is a boundary-position tolerance, for disruption avoidance a growth-rate tolerance.
Guarding extrapolation
The most important benchmark is out-of-distribution behavior. A PINN asked about an equilibrium outside its training envelope must not return a confident wrong answer. Kronos pairs each PINN with an in-distribution detector; queries that fall outside trigger a confidence drop and, if needed, a fallback to a slower on-demand FEM solve at L0 rather than trusting the network. The FEM reference thus remains available as an offline oracle even after the PINN is deployed.
This benchmark is re-run whenever the design changes (still frequent pre-FOAK) or whenever plant synchronization reveals model drift, keeping the twin's physics honest against first-principles solvers throughout the machine's life.