Multimode Experiment Code

Installation

Install pixi on your machine and pixi install to set up the environment. Then pixi run jupyter lab or set up a Jupyter kernel to allow VS Code to execute notebooks using the default pixi environmnet (LLMs can tell you how).

Running

On Pippin:

• Just double click start_all.bat and follow the instructions to start the Pyro nameserver, the job server and the worker.
• Or go inside job_server and double click the .sh executables to start server/worker individually.

On Pippin or your own machine:

• pixi run [nameserver|server|worker] to start each of them individually.
• pixi run monitor to live-monitor the job queue (-n 20 for more entries, -u alice to filter by user).

You can pass the --mock option to the worker to use mock mode (use mock QICK and Yoko instead of real hardware and gitignored local folders instead of real D drive locations on BF5).

Code organization

Pending major refactoring, slab code that is actively used in this repo is now vendored inside slab as a module.

pyproject.toml takes care of making sure the python modules inside this repo can be correctly imported without hacking path variables: If you add "abc" to the "include" list under [tool.setuptools.packages.find], the folder abc will become an importable module (such that you can import abc in your code anywhere). No import multimode_expts or import .anything or sys.path hacking!

TODO

• Experiment should initialize using station.im if available instead of constructing its own im every time (saves time and allows skipping the dependency injection in runners for mock instruments)
• Switch jobs.db file read/write to interacting with the job server
• Close mpl figures more proactively
• Make a web interface for viewing and operating on queued and running jobs
• Delete the binary files that don't belong in git. hdf5 data, images etc. Move them to the data/log folder accompanying each experiment.
• The few slab files are simply vendored in their original cursed state. If we straighten up the Experiment class and allow say proper file-reading functionalities, we can actually easily use the analyze functions in each child class to do the analysis instead of collecting everything in fitting_display_classes or such.
• Deal with accumulated log files and old jobs.db entries
• Migrate to tProcv2 at some point
• Consider using pydantic for complex config dictionaries.
• Mock QICK
• Sequencer