Phases and Chunking

Very fast experiments with a high repetition rate (>1 Hertz) are challenging. A particular problem are the time it takes the core device to switch from one run/kernel to the next. Atomiq tries to reduce this overhead by grouping together different runs in so-called chunks. Runs within a chuck are packed into the same ARTIQ kernel and are thus executed back-to-back (even without breaking real-time if you like) without the timing overhead of starting a new kernel. In principle one would like to pack all runs into a single kernel, but memory on the core device is limited, and thus we have to compromise and find a reasonable AtomiqExperiment.CHUNKSIZE that can be overwritten as a class-level attribute for your experiment class

Atomiq implements several phases during the original ARTIQ run phase to optimally embed chunking and provide a fast, yet flexible interface. Each of these phases can be used in a user experiment by implementing a method of the corresponding name. An overview of the available phases and their order and timings is shown in the following visualization.

The color of each phase indicates if they are realtime phases on the ARTIQ hardware (green) or non-realtime phases on the host machine running the ARTIQ master (blue).

If an exception occurs anywhere during the run phase, the postfail phases are executed to allow the user to shut down or reset critical components, like for example magnetic field coils.

If an RTIO underflow (or a kernel error) occurs during a chunk, the prerun phase is called again before continuing with the next chunk. Note, that only the prerun method is called and individual prerun methods of included blocks are ignored.

Warning

Atomiq uses the build and prepare phases for internal preparation. If you want to use these phases for your own code, make sure to call the atomiq code by running super().prepare() or super().build() in your methods.