Wigner Time: from experimental intent to real-time laboratory control

AI summary

Overview

Research area: Quantum physics / atomic, molecular and optical (AMO) laboratory instrumentation — specifically the software layer that translates an experimental procedure into precisely timed, multi-device hardware signals.

Technical level: Intermediate. The physics content is light, but the paper assumes familiarity with cold-atom experiments, real-time I/O controllers, and Python data-handling idioms.

Scope: The paper presents Wigner Time, an open-source Python package that represents an experimental timing sequence as an inspectable data table rather than as a real-time program, and reports on its deployment across two cold-atom setups.

What This Paper Is About

Experiments in atomic, molecular and optical physics need many devices — lasers, shutters, acousto-optical modulators, electromagnets, motorized stages — to be switched and ramped at microsecond or sub-microsecond precision, which forces labs onto specialized real-time hardware with its own restrictive programming model. On such hardware the only notion of time is a global cycle counter, so every stage boundary must be written as a running sum of everything before it, and changing one stage silently shifts all later ones. The paper's goal is to move the experimental description off the real-time controller and into ordinary Python, where the procedure exists as a table of timed updates that can be read, reused, versioned, and only at the last step converted into hardware-ready arrays.

Key Contributions

1. A data-oriented representation of experiments. Wigner Time introduces the timeline: a pandas.DataFrame with at minimum four columns — variable, time, value, context — where each row is a single state change of a single variable at a single instant. Because it is a plain table, users can fall back on the pandas ecosystem directly, and timelines can be plotted, compared, stored and archived.

2. Relative, named reference points instead of absolute instants. An origin mechanism lets stages be written purely in terms of their own internal timing and composed afterwards. Every core function accepts an origin keyword; by default the reference is the most recent anchor (or most recent entry, or absolute zero at the start of an experiment), so a time argument is read as a Δt from the end of the preceding stage. Passing a context name instead — e.g. origin = "molasses" — attaches a diagnostic, imaging or trigger operation to a named point of an existing timeline without restructuring the surrounding stages.

3. Hardware detail isolated to one conversion step. Naming physical connections (connection table, the only ADwin-specific part) is kept separate from calibration and unit conversion (device table, holding linear factors, functions, or interpolation from a calibration file, plus permitted value ranges). Adapting to a different real-time controller requires only a new conversion function plus a controller program that consumes the resulting table. The paper notes that raw output can already be used with non-ADwin systems such as National Instruments, but that these are not yet explicitly supported or optimized.

4. A deliberately minimal real-time program. Because ramps are stored symbolically (start and end time-value pairs plus a function reference, defaulting to hyperbolic tangent) and only expanded — normally automatically before conversion — all logic can be removed from the event loop, whose job reduces to "at this cycle, write the values listed for it." Which values need writing at all, i.e. those differing from what an output already holds, is decided beforehand in Python.

Main Findings

• Five-fold improvement in temporal resolution. The ADbasic implementation that Wigner Time replaced evaluated ramp trajectories, including transcendental functions, inside its event loop alongside several dozen conditional tests, and ran at a cycle time of 5 µs; the present system runs the same experiments at 1 µs.
• Real deployment, not a prototype. The package has been in use for more than two years across two cold-atom setups at the Wigner Research Centre for Physics, Budapest, and is released as open source under the GNU General Public License v3.
• The speed gain is an exchange of computation for memory. Ramps expanded ahead of time occupy rows that were previously recomputed on every cycle; the authors describe this as a favourable trade by a wide margin on current hardware, not as a free gain.
• A concrete before/after comparison. Figure 1 shows one optical-pumping stage distributed across five locations in the old ADbasic code — an include file with hardware channels and shutter response times, a derived delay at file scope, running-sum boundaries in LOWINIT, equality tests against the global cycle counter in EVENT, and a coil-ramp interpolation in a separate block roughly 150 lines further down, reached through reserved global state set by a subroutine in a third file — versus a single Python function in Wigner Time.
• Enforced constraints catch categories of error. A ramp must end after it begins (zero or negative duration raises an error); ramping a variable that has not yet been set raises an error; starting a ramp of a variable while another ramp of it is in progress also raises an error, since the value it passes through at that instant is in no row of the timeline. A ramp whose value does not change is a hold, not an error. In the old code, a second concurrent coil ramp was a runtime error rather than a new operation.
• Self-documenting stage interfaces. Stages are ordinary functions, so the quantities expected to vary are their arguments — declared once, with defaults, alongside the code they govern — while rarely changing values sit in the body. A specification needed in more than one place, such as a safe default apparatus state, can be written once and reused.
• Not reported: the paper content provided does not give quantitative data on development-time savings, number of timeline rows, number of channels in the deployed setups, or any benchmark comparisons against other control software beyond the 5 µs to 1 µs cycle-time figure.

Methodology in Plain English

The authors reframed the problem: rather than treating an experiment as a program to be executed, they treat it as a value to be transformed. The description of an experiment lives in three layers. The operation layer is ordinary client Python in which the lab writes stage functions such as "optical pumping" or "take a fluorescence image". The physics layer, which is the package core, holds the timeline expressed entirely in real physical units (MHz, amperes, watts); building blocks — update for discrete state changes, ramp for smooth transitions, anchor for virtual reference rows — each return a stage, and stack composes stages in a causal chain, with to_timeline producing the actual table. The hardware layer is a single conversion function that reads the connection table (which module and channel a named device is wired to) and the device table (how a physical value maps to a voltage, and its permitted range), turning each row into a cycle count, a channel, and a digitized value suitable for upload to an ADwin controller via its API.

Two design decisions do most of the work. First, everything is relative: stages never contain absolute times, so inserting or lengthening a stage displaces everything after it automatically instead of invalidating hand-computed sums. Second, hardware specifics are deferred: module numbers, channel assignments and DAC digitization appear only at conversion, leaving the timeline human-readable and back-end agnostic up to that point. Ramps are kept symbolic until an expand call, which samples at the controller's cycle period unless the ramp fixes its own resolution — for example, time_resolution = 1e-4 samples every 0.1 ms, keeping a long ramp from occupying every cycle it spans. Initial and final device states, which belong to no instant, are placed at −∞ and +∞. The authors situate the work against two existing families of solutions — hardware co-designed with its own software (Meyrath and Schreck's system, Sinara/ARTIQ) and software over commercial off-the-shelf hardware (Cicero/Atticus, labscript, Entangleware Sequencer) — noting that in all of them the description is a program, whereas here it is data. They frame the advantages using Hickey's distinction between easy and simple: easy because it uses a popular general-purpose language and the pandas ecosystem; simple because physical calibration, wiring, timeline design and hardware conversion are each kept in their own place.

Why This Matters

Impact on research. Timing code is where a lot of AMO experimental time quietly disappears. Moving the logic out of the real-time loop buys resolution (5 µs to 1 µs here) and, more importantly, makes the experimental procedure an artifact that can be read by a newcomer, diffed between campaigns, and archived alongside the data it produced. Because a complete experiment is ordinary versionable source, the difference between two campaigns becomes a diff — a meaningful step toward reproducibility in a field where procedures are often private, lab-specific programs of which, as the authors note, little is ever published.

Real-world applications (as motivated or illustrated in the paper):

• Cold-atom experiments — magneto-optical trapping, optical pumping, molasses cooling, transport, imaging and finalization sequences.
• Neutral-atom arrays and other precisely controlled quantum platforms, cited as the most precisely controllable systems produced.
• Any multi-device timing problem in AMO labs, including laser frequency control, shutter sequencing, AOM amplitude control, electromagnet ramps, and optomechanical stage motion.
• The authors state the design applies to any domain requiring precise multi-device timing, not only quantum physics.

Industry relevance. Commercial timing hardware (ADwin, National Instruments cards) and open-hardware ecosystems (Sinara/ARTIQ) currently bind labs to vendor- or platform-specific description languages. A back-end-agnostic, table-based intermediate lowers switching costs, and the deliberate exchange of computation for memory is a familiar and favourable trade on commodity hardware. The pandas foundation means the core rests on well-tested, widely used technology rather than bespoke infrastructure, and a single Jupyter notebook can carry a workflow from batches of experimental runs through data collection and analysis to publication-quality figures.

Future Directions

• Broader back-end support. The conversion step is currently ADwin-specific (only the connection table is), and non-ADwin targets such as National Instruments are described as usable in raw form but not yet explicitly supported or optimized. A clean abstraction over several real-time controllers is the obvious next step, with the caveat that for some systems it may require a more substantial controller-side program than the few lines used for ADwin.
• Richer interweaving and scheduling. The origin-by-context mechanism already allows attaching operations to named points; extending this to more complex overlapping, conditional or triggered sequences is a natural elaboration.
• Tooling around the table. Since timelines are data, plotting, comparison, interrogation and archival tooling can grow independently; the paper mentions basic display conveniences are included but does not describe a full visualization or analysis suite.
• Open questions left unaddressed in the provided content. The paper does not report quantitative development-time savings, scaling limits on timeline size or memory when ramps are fully expanded, or a formal comparison against ARTIQ, labscript or Cicero on a common experiment. Whether the approach generalizes beyond cold atoms remains an assertion rather than a demonstration in what is presented here.

Target Audience

Experimental AMO and quantum-optics groups who build and maintain their own timing sequences; lab software engineers and instrument-control developers supporting such labs; and research-software maintainers interested in data-oriented design applied to real-time instrumentation. Readers from other precision-timing fields — synchrotron beamlines, pump-probe spectroscopy, quantum-computing control stacks — will find the architectural argument transferable even though the examples are cold-atom specific. The paper is less suited to readers seeking new physics results; it is a software and methodology contribution.

Authors’ abstract

Precisely timed, multi-device control in atomic, molecular and optical physics is provided by specialized real-time systems, which impose their own terms on the description of the experiment: a program over a global clock, in which every stage boundary is an absolute time computed from everything preceding it. Such descriptions are tightly coupled -- changing one stage affects all later ones -- and are correspondingly hard to reuse, inspect, or move elsewhere. We introduce Wigner Time, a Python package in which the experimental procedure is instead represented as data: a table of timed updates, assembled by composing functions and referred to named points in the experiment rather than to absolute instants. Hardware enters only at a final conversion step, leaving the description readable and back-end agnostic. Wigner Time has run two cold-atom setups for more than two years, where taking the computation out of the real-time program improved the achievable temporal resolution five-fold; the design applies to any domain requiring precise multi-device timing.