Why turbulence tracking is the bottleneck in fusion performance
Fusion devices can reach the right temperatures and densities, yet still underperform because heat leaks out faster than planned. The main culprit is turbulence: small, fast-moving eddies in the plasma that mix hot core material with cooler outer regions, like stirring a pot you’re trying to keep layered. Even modest changes in turbulent transport can swing confinement enough to determine whether a plasma stays in a high-performance regime or slips back.
Tracking turbulence is a bottleneck because it evolves on timescales that are too quick for many control decisions and too complex for simplified models to capture reliably. High-fidelity simulations exist, but they can be too slow and expensive to run in the moment, and diagnostics only observe slices of the full 3D behavior. That gap—between what you can measure, what you can compute, and what you need to know in time—is where machine learning is being aimed.
What data you actually get from a tokamak or stellarator
In practice, you never “see” turbulence directly across the whole plasma. You get a patchwork of measurements: magnetic coils around the vessel capturing rapid changes in the boundary fields; microwave reflectometry or interferometry estimating density fluctuations along a line of sight; Thomson scattering providing snapshots of temperature and density profiles at discrete times; soft X-ray or bolometry giving emissivity patterns; and fast cameras viewing visible light from the edge. Many of these signals arrive as time series at kilohertz to megahertz rates, while others are sparse, delayed, or only available on some shots.
Two constraints shape what ML can do. First, sensors measure projections—lines, chords, or surfaces—so “ground truth” turbulence structure is usually inferred, not labeled. Second, devices change configuration: heating power, plasma shape, wall conditions, and even diagnostic calibrations drift. The data is rich but inconsistent, and a model that works on one campaign can degrade when hardware or operating regimes shift.
Defining the tracking task: detection, localization, or prediction
A familiar frustration in fusion papers is that “turbulence tracking” can mean three different jobs, with three different bars for success. Detection asks a yes/no question: are turbulent fluctuations rising into a transport-relevant state right now? That can be useful as an alarm or regime classifier, but it does not tell operators what to change. Localization goes a step further by estimating where the activity sits—core versus edge, on a particular flux surface, or near a rational surface—often by fusing multiple imperfect views into a best-guess map or index.
Prediction is the most operationally meaningful and the hardest: forecasting a near-future increase in turbulent transport early enough to adjust heating, fueling, or shaping. The “future” depends on actuator latency and diagnostic cadence; a 1–10 millisecond horizon might help real-time control, while longer horizons matter for scenario planning. In all three cases, the task definition has to match the data you truly have, and the cost of being wrong—missed events versus false alarms—because both can waste scarce plasma time and risk destabilizing the discharge.
Model options: from boosted trees to physics-informed deep nets
A common starting point is a supervised model that treats “turbulence level” as a label and the diagnostics as engineered features: spectral power in certain bands, cross-correlations between coils, gradients from profile fits, or simple stability proxies. Boosted trees and regularized linear models often work surprisingly well here because they handle messy inputs, missing channels, and mixed units without much tuning. They also give quick sanity checks: which signals matter, how performance changes across operating regimes, and whether the model is just learning trivial confounders like heating power.
Deep learning becomes attractive when you want to reduce hand-crafted features and exploit structure in the raw data. Convolutional nets can digest time–frequency “images” of fluctuations; sequence models can learn dynamics from multi-rate time series; graph models can represent coil layouts and diagnostic geometry. The cost is practical: more data hunger, more hyperparameter sensitivity, and a higher chance of learning device-specific quirks that don’t transfer to the next campaign.
Physics-informed approaches sit between. They constrain outputs to respect symmetries, conservation-like relationships, or simplified transport models, or they use a fast physics simulator to generate training targets. That can improve extrapolation, but it also bakes in assumptions that may be wrong precisely where turbulence surprises you.
How to train with scarce labels and noisy ground truth
The typical fusion ML project runs into a basic problem: you have plenty of sensor data, but very few moments you can confidently tag as “turbulence increased here, then it caused transport.” Labels often come indirectly from proxies like stored energy drops, confinement time estimates, or bursts in fluctuation power—each with timing uncertainty and contamination from other effects (MHD activity, ELMs, diagnostic artifacts). A practical response is to treat labels as probabilistic and time-fuzzy, training on windows rather than single timestamps and penalizing overconfident predictions when the target itself is ambiguous.
To stretch limited labeled shots, teams lean on self-supervised and weakly supervised tricks: pretraining on raw time series to learn representations, then fine-tuning on a small labeled subset; pairing “similar” operating points across shots; or using multiple diagnostics to vote on events. Domain shift is the ongoing tax: a model trained on one campaign can fail after a hardware change, so retraining budgets, calibration tracking, and simple baselines remain part of the workflow, not an afterthought.
Proving it works: metrics, baselines, and failure modes
A turbulence-tracking model “works” only if it beats simple yardsticks on the same shots. The first yardstick is a no-ML baseline: thresholding fluctuation power in one diagnostic band, or a hand-tuned rule based on gradients and heating power. Another is persistence: assume the turbulence level in the next few milliseconds matches the last few. If ML cannot outperform these, it is likely repackaging an existing heuristic.
Metrics should match the operational cost of mistakes. For detection, precision/recall and false-alarm rate per second matter more than overall accuracy, because turbulent bursts are rare. For localization, error bars and calibration (how often “80% confident” is right) can matter as much as mean error. For prediction, lead time at a fixed false-alarm budget is the headline number, along with performance across regimes, not just an average.
Common failure modes are mundane: the model keys off confounders like auxiliary heating settings; it learns diagnostic quirks that change after maintenance; or it silently fails when channels drop out. Robustness tests—sensor ablations, campaign-to-campaign splits, and stress cases with MHD or ELM activity—are usually where demos turn into evidence.
From offline insight to real-time turbulence-aware operation
The jump from an offline turbulence “score” to real-time operation is mostly an engineering timing problem. Control systems need decisions on millisecond scales, with bounded latency and predictable compute, while diagnostics can be multi-rate, intermittently missing, or delayed by reconstruction. That pushes models toward streaming features, small networks, or distilled versions of larger models that run reliably on the control hardware.
Operationally, the safest use is not “let ML steer the plasma,” but to gate existing actuators: raise confidence that transport is rising, then adjust heating, fueling, or rotation within pre-set limits. You need evidence across campaigns that the model still behaves under sensor drift, new wall conditions, and rare events. Without that, it stays a useful analysis tool rather than a step toward turbulence-aware control.
