Introduce backend independent acquisition mappings (SE-386)
Explanation of changes
Overview
This change is part of acquisition redesign (&5), and is intended to partially replace the current acquisition metadata. This change only introduces some new acquisition mappings, but ultimately does not use it anywhere to make the MR relatively short. (In a subsequent MR we will use it.)
The change is the following.
- It introduces two acquisition mappings, both of them are backend independent mappings.
-
AcquisitionChannelData
, which contains the following for each acquisition channel.- acquisition protocol,
- bin mode,
- coords.
-
SchedulableLabelToAcquisitionIndex
, which is a mapping for each schedulable to acquisition index.
-
Replaces the operation's internal structure a little bit, theacq_index
is stored under thecoords
now.
This MR only implements the introduction of the backend-independent acquisition mappings (1st step) in 5. Implementation for quantify-scheduler!
Motivation of changes
Please first take a look at the agreed interface design to understand the motivation: Implementation plan for Quantify-scheduler.
New acquisition mappings
First, read 5. Implementation for quantify-scheduler.
This MR only implements the introduction of the backend-independent acquisition mappings (1st step)!
coords
vs acq_index
coords
vs acq_index
The reason we would introduce coords
, and store acq_index
in coords["index"]
is that with the new mapping, the acq_index
will have a different meaning: it is not something the user sets, but rather, this is a compiler generated value. In the examples, this is for example the values of acq_index_ch_0
. But in the meantime (while acquisition redesign is not completely ready) we can't change the interface, because we don't want to implement all the changes in one MR (would be too big). So, we need to store the user defined acq_index
somewhere, and coords
is a fitting place, because that's exactly what it is: it's a user appended value to the acquisition.
Throughout the codebase, we will use the coords["index"]
to store the user defined acq_index
.
This is confusing, but only a temporary solution, until we don't implement the coords
to the interface.
Merge checklist
See also merge request guidelines
-
Merge request has been reviewed (in-depth by a knowledgeable contributor), and is approved by a project maintainer. -
New code is covered by unit tests (or N/A). -
New code is documented and docstrings use numpydoc format (or N/A). -
New functionality: considered making private instead of extending public API (or N/A). -
Public API changed: added @deprecated
and entry in deprecated code suggestions (or N/A). -
Newly added/adjusted documentation and docstrings render properly (or N/A). -
Pipeline fix or dependency update: post in #software-for-developers
channel to mergemain
back in or update local packages (or N/A). -
Tested on hardware (or N/A). -
CHANGELOG.md
andAUTHORS.md
have been updated (or N/A). -
Performance tests: if changes can affect performance, trigger CI manually and evaluate results (or N/A). -
Windows tests in CI pipeline pass (manually triggered by maintainers before merging). - Maintainers do not hit Auto-merge, we need to actively check as manual tests do not block pipeline
For reference, the issues workflow is described in the contribution guidelines.