MIT Plasma Science and Fusion Center

The framework grew up MDSplus-centric. MAST's data lives in Zarr stores on an S3-compatible object store with no MDSplus at all, and the first MAST integration bolted an Xarray connection on with duck typing and a type cast repeated in every MAST physics method. The fix was to separate two concerns the code had been mixing: per-shot data access and per-process connection lifecycle.

I introduced DataConnection and ProcessConnection abstract base classes, implemented them for MDSplus and for Xarray/Zarr, and rewired the retrieval manager, settings, and the machine modules on top of them. Path formats deliberately stay backend-specific, because normalising them would have meant rewriting every physics method for no user-visible gain. The design went through five design documents and one rejected abstraction that turned out to be indirection for its own sake.

Before merging I verified the output was bit-identical to the reference dataset on a set of C-Mod shots, serial versus parallel, and that known-corrupt shots produced the same errors as before. Later work on the error hierarchy and on data-access forwarders built on the new interfaces.

The workflow fans shots out to a multiprocessing pool. On Linux the pool forks, so workers inherit everything the main process set up. On macOS the default is spawn, and Python 3.14 moved Linux to forkserver, and in both cases workers start from a fresh interpreter. Anything registered only in the main process is simply gone. The first symptom was that every MAST physics method failed inside workers with a missing custom log level, so zero of thirty-three parameters had data. A pytest hang and an xarray merge error on concatenation turned out to be the same problem wearing different clothes.

The fixes moved all logger state to import time, gave the pool an initializer that resets handlers, made the affected test spawn-safe so the macOS CI matrix could land, and stamped workflow metadata in the main process instead of in each worker.

Defaults were scattered through the codebase as hardcoded literals. I scoped the migration into tiers, from trivial scalars through small design calls to architectural registries, and posted the analysis on the tracking issue before writing code. The first slice moved logging defaults into layered configuration via Dynaconf with an explicit precedence: explicit argument, then environment variable, then the user's TOML, then the repository TOML. The effective settings are written back into the configuration inside the main entry point, so the per-run config dump records what actually ran, for API callers as well as the CLI.

The same PR fixed a log-file corruption that had been present since the spawn work: the main process opened the file in write mode and its offset overwrote lines the workers had appended. I reproduced it byte for byte in a standalone script and replaced it with truncate-once-then-append.

Most derived quantities come from EFIT, an equilibrium-reconstruction code, and a shot can have several EFIT runs at different time resolutions. Selecting one used to go through an implicit SQL-backed fallback. I replaced it with an explicit, user-specified cascade of tree names that falls through on missing trees and logs each step, backed by twenty-eight unit tests against a fake connection and a regression test on real C-Mod shots. Approved, pending merge.

Worker processes also printed over the main process's tqdm progress bar, and lost their console output entirely when stdout was not a terminal. I compared candidate fixes empirically by capturing runs through a pseudo-terminal, traced the non-terminal loss to the logger's queue not being drained at worker exit, and shipped a queue-based console relay plus two spawn-safe tests. In review.

Poster: Maintainable and Extensible Software Architecture for Multi-Machine Disruption Studies with DisruptionPy. First author, with the MIT PSFC Disruption Studies Group. 68th Annual Meeting of the APS Division of Plasma Physics, Chicago, 2 to 6 November 2026.