PaperlayerView exact revision on arXiv

Source-linked AI summary

Enabling Integrated AI Control on DIII-D: A Control System Design with State-of-the-art Experiments

Andrew Rothstein, Hiro Joseph Farre-Kaga, Jalal Butt, Ricardo Shousha, Keith Erickson, Takuma Wakatsuki, Azarakhsh Jalalvand, Peter Steiner, Sangkyeun Kim, Egemen Kolemen

arXiv:2511.08818v1physics.plasm-phcs.SYeess.SY

TL;DR

Most ML-based plasma controllers had been stand-alone demonstrations, leaving a common real-time framework for diverse applications largely undeveloped. PACMAN provides an end-to-end DIII-D framework, demonstrated across varied experiments and controller types.

  • Problem

    Most ML-based controllers had been stand-alone demonstrations, with little effort toward a common real-time framework for deployment across diverse control applications.

    Source: §I · p. 1

  • Method

    PACMAN links diagnostic inputs, model processing, controller logic, and actuator outputs in a modular framework that supports different model and controller types.

    Source: §I · p. 1, B. Model Block · p. 5, §IV · p. 10

  • Results

    PACMAN was demonstrated in five listed experiments and four additional experiments, spanning diverse model implementations, control types, and objectives.

    Source: §IV · p. 10

  • Takeaways & Limitations

    The demonstrated variability in models and controllers shows PACMAN can handle different control types and objectives using DIII-D diagnostics and actuators.

    Source: §IV · p. 10

    The three-level design principle is not enforced across DIII-D algorithms, and some edge cases span two levels.

    Source: §3 · p. 3

Abstract

from arXiv · show

We present the design and application of a general algorithm for Prediction And Control using MAchiNe learning (PACMAN) in DIII-D. Machine learing (ML)-based predictors and controllers have shown great promise in achieving regimes in which traditional controllers fail, such as tearing mode free scenarios, ELM-free scenarios and stable advanced tokamak conditions. The architecture presented here was deployed on DIII-D to facilitate the end-to-end implementation of advanced control experiments, from diagnostic processing to final actuation commands. This paper describes the detailed design of the algorithm and explains the motivation behind each design point. We also describe several successful ML control experiments in DIII-D using this algorithm, including a reinforcement learning controller targeting advanced non-inductive plasmas, a wide-pedestal quiescent H-mode ELM predictor, an Alfv\'en Eigenmode controller, a Model Predictive Control plasma profile controller and a state-machine Tearing Mode predictor-controller. There is also discussion on guiding principles for real-time machine learning controller design and implementation.

I. INTRODUCTION

Tokamak control requires real-time feedback across diverse timescales, while prior ML controllers were often stand-alone demonstrations. The paper introduces PACMAN, a DIII-D framework for deploying diverse ML models and controllers.

I. INTRODUCTION

  • Tokamak instabilities span timescales from milliseconds to over 100 ms, motivating real-time feedback and PCS architectures with multiple CPU cores and cycle times.Real-time equilibrium reconstruction supplies plasma shape and boundary information for fast position and shape control.Source: §I · p. 1
  • Prior ML plasma-control work includes surrogate models, instability prediction and avoidance, profile prediction and control, and reinforcement learning trained in offline simulators.Event predictors have typically been paired with thresholding or finite-state controllers.Source: §I · p. 1
  • PACMAN addresses the lack of a common real-time framework for deploying diverse ML control applications, which had remained mostly stand-alone demonstrations.The paper reports its first implementation on DIII-D and emphasizes modularity, fault-tolerance, and flexibility.Source: §I · p. 1
  • PACMAN expands a prior profile-control workflow to improve scalability, model-controller separation, diagnostic integration, and timebase management.Its principles are presented as generalizable beyond the demonstrated CPU-based environment.Source: §I · p. 1

II. ALGORITHM DESIGN

  • The algorithm is organized as an end-to-end sequence from diagnostic inputs through processing blocks to actuator commands.The paper introduces the four-block outline before detailing the architecture.Source: §II · p. 1

1. Diagnostic input pre-processing

PACMAN places high-level control objectives in a layered PCS architecture and separates processing into blocks with forward-only information flow. The design targets scalable, flexible deployment while keeping actuator commands within the hierarchy.

3. Controller block

  • The architecture’s end-to-end path starts with diagnostics and ends with actuator requests such as NBI power, ECH power, and gas.PACMAN selects actuators to accomplish user-defined targets.Source: Figure 2 · p. 2, Figure 1 · p. 2
  • The block design separates components and passes information forward, preventing models or controllers within a block from depending on one another.This avoids dependency collisions and leaves open parallel execution of models followed by controllers; centralized interface checks clarify fault handling.Source: §3 · p. 3
  • Level 1 algorithms process diagnostics or calculate hardware commands, Level 2 algorithms process diagnostics or translate high-level requests, and Level 3 algorithms pursue control objectives.Users typically interact least with Level 1 and most with Level 3.Source: §3 · p. 3
  • The design’s human-organization analogy maps engineers to Level 1, physics operators to Level 2, and experimentalists to Level 3.Level 2 may accept or reject requests such as total beam power based on configured limits.Source: §3 · p. 3
  • PACMAN is a Level 3 controller that takes user objectives and processed Level 2 data, then sends actuator commands to Level 2 algorithms.The three-level convention is a design principle rather than an enforced standard, and some DIII-D algorithms cross levels.Source: §3 · p. 3
  • The architecture targets concurrent models and controllers, model- and controller-type flexibility, flexible standard input processing, 5–50 ms cycle times, and actuator-command arbitration.The stated cycle-time goal applies even if components take performance hits.Source: §3 · p. 3

A. Input Gathering and Pre-processing

PACMAN gathers and standardizes real-time diagnostic inputs while delegating buffering to Level 2 providers and keeping model-specific processing flexible. It checks inputs for errors and exposes available inputs and actuator timescales.

A. Input Gathering and Pre-processing

  • PACMAN reads Level 2 buffers instead of managing high-volume diagnostic buffering itself, with diagnostic rates ranging from 1 MHz to 100 Hz.It retains the most recent cycle, typically 10 or 20 ms, rather than a longer history, while Level 2 providers buffer relevant data.Source: A. Input Gathering and Pre-processing · pp. 3–4
  • Input preprocessing is minimal: selected power and torque signals are low-pass filtered, while custom normalization is left to each model.This keeps models close to diagnostic data and lets them use normalization suited to their development.Source: A. Input Gathering and Pre-processing · p. 4
  • Input checks detect diagnostic errors such as failed EFIT convergence, nonpositive temperature profiles, or stale timestamps, and essential missing inputs prevent a model or controller from running for that timestep.Failures are also made visible to the control room for follow-up before the next shot.Source: A. Input Gathering and Pre-processing · pp. 4–5
  • Table I catalogs PACMAN model inputs and output actuators, distinguishing diagnostic-update times from actuator-effect times.For ECH, switching can occur in under 1 ms, but continuous modulated power requires closer to 10 ms for time averaging.Source: Table I · p. 5
  • The input block supplies error-checked real-time Level 2 data and prior-cycle data while keeping preprocessing minimal.The PCS hierarchy routes processed diagnostic information upward toward controllers.Source: Figure 3 · p. 4, A. Input Gathering and Pre-processing · p. 5

B. Model Block

PACMAN’s model block transforms input-block data into values usable by controllers or other PCS components, supporting ML and non-ML models. Models handle their own normalization and task-specific processing.

B. Model Block

  • The model block accepts ML or non-ML models that turn input-block data into values actionable by controllers or usable elsewhere in the PCS.Outputs can support external algorithms or feed PID control, thresholding, and finite-state machines.Source: B. Model Block · pp. 5–6
  • Model processing parses structured inputs, preprocesses them, runs the model, and post-processes its outputs for the controller block.Preprocessing can include filtering, smoothing, and normalization; post-processing can include filtering or thresholding.Source: B. Model Block · pp. 5–6
  • PACMAN supports varied model types and implementations, while each model handles its own normalization and model-specific input processing.Supported types include surrogates, event and profile predictors, observers, latent-space mappings, and RL models.Source: B. Model Block · p. 6
  • keras2c eases PCS implementation but uses substantial stack memory, scales poorly across concurrent functions, and limits a DIII-D function file to about 3 MB.It supports convolutional and LSTM layers, whereas heap-allocating alternatives such as PCAnet scale better but limit users to MLP architectures.Source: B. Model Block · p. 6
  • Independent models can run in series or parallel, enabling potential computation speedups but limiting direct model-to-model inputs.A hierarchical model can instead combine multiple keras2c-generated functions in one Model sub-block.Source: B. Model Block · p. 6

C. Controller Block

PACMAN’s controller block converts model outputs and input data into actuator commands. Independent controllers support parallel execution, while separation can constrain integrated control and is intended to avoid conflicting commands.

C. Controller Block

  • Each controller receives needed model outputs and input data, then computes actuator commands for the output block.Controllers can implement finite-state machines, thresholding, PID, MPC, or other algorithms.Source: C. Controller Block · p. 6
  • Controllers cannot communicate within the block, allowing independent execution and potential parallelization but potentially limiting integrated controllers.The authors judge this restriction worthwhile for the safety of avoiding conflicting actuator commands.Source: C. Controller Block · p. 6
  • If a controller’s input has an error from the input or model block, it issues no actuator command.The paper notes that inaction can sometimes be more dangerous than a bad action; designated ramp-down actions are proposed as a possible future alternative.Source: C. Controller Block · p. 6

D. Actuator Output and Post-Processing

The output block checks controller commands for conflicts, applies final safety clamps, and sends commands to Level 2 algorithms. Its update rate limits how quickly PACMAN can issue actuation.

D. Actuator Output and Post-Processing

  • PACMAN cannot issue commands faster than its millisecond evaluation cycle, making it inappropriate for sub-millisecond events such as VDEs.The paper says this timescale is sufficient for most plasma instabilities of interest.Source: D. Actuator Output and Post-Processing · p. 7
  • Conflicting actuator commands result in no actuation, preserving machine safety while operators are informed of the conflict.The authors describe this handling as naive, while noting the output block can support future improvements.Source: D. Actuator Output and Post-Processing · p. 7
  • Before sending commands to Level 2 algorithms, the output block applies final minimum and maximum limits to actuator requests.Clamps cover gas valve voltages, NBI and ECH power, ECH mirror angles, and 3D coil currents.Source: D. Actuator Output and Post-Processing · pp. 6–7

III. EXPERIMENTAL APPLICATIONS

The DIII-D applications illustrate PACMAN’s use across different model and controller types and control objectives. The reinforcement-learning example uses model outputs to determine actuator commands subject to hard-coded safety limits.

III. EXPERIMENTAL APPLICATIONS

  • The applications illustrate PACMAN’s flexibility across model and controller types and diverse real-time plasma-control objectives.The section presents successful examples and notes that additional algorithms have also been deployed on the DIII-D PCS using PACMAN.Source: §III · p. 7

A. Reinforcement Learning Controller

  • The RL βN and ITB controller demonstrates full ML control: its outputs determine actuator commands subject to hard-coded machine-safety limits.It targets a βN trajectory and ITB excitation during flattop in a high-qmin advanced-tokamak scenario.Source: A. Reinforcement Learning Controller · p. 7
  • The RL model takes q and Te profiles plus actuator information and outputs on-axis and off-axis NBI power requests and ECH power.PACMAN ran this controller at a 50 ms cycle time; its hierarchical design selects among three model functions using an ITB-observer index.Source: A. Reinforcement Learning Controller · p. 7
  • A controller block converts the RL model’s on-axis and off-axis NBI requests into individual NBI powers accepted by the DIII-D PCS algorithm.The model functions were generated with keras2c, and the controller block converts their outputs into Level 2 commands.Source: A. Reinforcement Learning Controller · p. 7

B. TM control with ECCD

The TM predictor-controller was tested in the elevated qmin advanced tokamak scenario, using predicted TM probability to steer ECH mirror tasks for suppression. Its threshold-based controller smooths predictions and changes gyrotron tasks as probability rises.

B. TM control with ECCD

  • The predictor-controller was tested experimentally in the elevated qmin advanced tokamak scenario, using an Auton Survival Model predictor to steer the ECH mirror and preemptively suppress TMs.The predictor uses RTCAKENN profiles, PNBI, PECH, and scalar rt-EFIT parameters; the controller targets either a broad off-axis current-drive aim or the q = 2 rational surface.Source: B. TM control with ECCD · p. 7
  • The model outputs TM probability over a configurable time horizon, and its target inference time was under 10 ms.Real-time TORBEAM and ECH mirror steering use the selected objective to find the optimal mirror angle.Source: B. TM control with ECCD · pp. 7, 9
  • Above 10% TM probability, the first gyrotron switches to q = 2 surface tracking; above 20%, the second switches tasks.A low-pass filter smooths the probability to avoid changing the actuator based on a single potentially poor CPU-cycle datum.Source: B. TM control with ECCD · p. 9

C. ELM Prediction

For wide-pedestal quiescent H-mode, PACMAN processed diagnostic data for an ELM predictor connected to an external avoidance controller. The applications also include an Alfvén Eigenmode detector combined with proportional NBI control.

C. ELM Prediction

  • PACMAN’s non-command output path supplied real-time diagnostic processing to an already developed external controller for WPQH pedestal control.The model and controller were deployed and tested experimentally.Source: C. ELM Prediction · p. 9
  • Sporadic breakthrough ELMs in intrinsically ELM-free plasmas lack a simple predictive model, so the WPQH predictor uses a broad set of diagnostics and actuator measurements.Inputs include BES turbulence, CO2-interferometry density, ECE temperature gradients, Dα emission, and neutral-beam, ECH, and gas actuator information.Source: C. ELM Prediction · p. 9
  • The deep survival model outputs 1-survivability as the likelihood of ELM-free termination over a user-configurable horizon, and feeds the ELM-free PCS avoidance algorithm.Its median prediction time is about 100 ms, while execution takes about 200 µs; the selected CPU cycle time was 2 ms.Source: C. ELM Prediction · p. 9

D. Alfén Eigenmode Controller

  • An ECE-based RCN model classified Alfvén Eigenmodes and was combined with proportional control of PNBI during a DIII-D ramp-up shot.The controller used TAE and RSAE amplitudes, with low-pass filtering and user-selected feedback amplitude; NBI power changes were bounded by minimum, maximum, and rate-of-change limits.Source: D. Alfén Eigenmode Controller · p. 9
  • The RCN model detected five AE types, but only TAE and RSAE signals were passed to the controller.Its weights could be changed during an experiment, while intra-shot retraining remained future work.Source: D. Alfén Eigenmode Controller · p. 9

E. MPC Profile Control

PACMAN was demonstrated across diverse control applications, including AI-based model predictive control of plasma profiles. The profile controller produced accurate 33-point rotation and density profile control, while future work targets faster computation and new hardware integration.

E. MPC Profile Control

  • The AI-based MPC controller produced accurate rotation and density 33-point full-profile control experimentally on DIII-D.It performs multi-input, multi-actuator profile control; its QP optimization uses measured and target latent spaces, plasma current and magnetic field, actuator limits, and solver parameters to calculate NBI, ECH, and gas commands.Source: E. MPC Profile Control · p. 10

IV. CONCLUSION

  • PACMAN separates input processing, ML models, controllers, and actuator-output handling, with the output block resolving conflicting requests and enforcing actuator constraints.The separated blocks ease user design and could be parallelized in the future.Source: §IV · p. 10
  • 5 listed experiments and 4 additional experiments demonstrated PACMAN across multiple model and controller types and control objectives.The examples include survival models, nonlinear encoders, and RCN event predictors, with RL, finite-state, PID-based, and MPC control.Source: §IV · p. 10
  • Full-algorithm multithreading is a future goal for speeding computation, and future work may explore GPU or FPGA hardware.The input and output blocks are also expected to be adjusted as new diagnostics and actuators come online.Source: §IV · p. 10

DISCLAIMER

The report disclaims warranties and liability regarding the information and its use, and states that references to commercial products do not imply government endorsement.

DISCLAIMER

  • The report disclaims warranties and liability for disclosed information, products, or processes and does not imply government endorsement of referenced commercial products or services.Source: DISCLAIMER · p. 11

V. APPENDIX

PACMAN planning should begin before model training and account for the objective, timescales, actuators, inputs, and control scheme. Its millisecond-or-longer timing range covers most relevant timescales but not every plasma-control application.

A. ML Controller Planning

  • Real-time implementation decisions should be made before training, since otherwise the model may need retraining or the control scheme significant changes.Source: A. ML Controller Planning · p. 14
  • Planning should match the control objective and actuator response times to the timescales the control task requires.Source: A. ML Controller Planning · p. 14
  • Input planning should address the sim-to-real gap and how quickly the model must run to meet the control objective.Source: A. ML Controller Planning · p. 14
  • The control scheme should account for actuator limits and possible actuator failures.Source: A. ML Controller Planning · p. 14
  • PACMAN imposes millisecond-or-longer control and objective timescales, covering most relevant timescales but not all plasma-control applications.The framework is described as enabling easier deployment for a significant number of ML models and controllers.Source: A. ML Controller Planning · p. 15
Loading 2511.08818v1…