Skip to content

Documentation on the acquisition framework

Adriaan requested to merge acq_docs into main

Explanation of changes

Adds a new reference guide on the Acquisition framework. Most of this documentation is a direct copy from the agreed upon definitions of &5 .

There are a few things which are added that were not included in &5 . Based on @gdenes 's work in !900 (closed) , the concept of the AcquisitionChannel is fleshed out in more detail. Specifically, it became clear that every Acquisition associated with an AcquisitionChannel must have the same AcquisitionProtocol and BinMode. The concept of BinMode is also something we use, but that has never been defined. This is added in this MR as well.

By virtue of adding a lot of documentation, this closes #81 (closed) which is about documenting what an AcquisitionProtocol is and how it impacts data structures.

Motivation of changes

In order to progress with the acquisition framework, we need to document what we add. A framework and common context for this was missing.

The idea is that this serves as the starting point, and as we iterate on concepts and implementations this is expanded upon.

This MR should be uncontroversial as it only reflects previously agreed upon definitions of &5. The only exception is the definition of the BinMode which is not part of &5. Here I have only documented existing behavior.

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 merge main back in or update local packages (or N/A).
  • Tested on hardware (or N/A).
  • CHANGELOG.md and AUTHORS.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.

Edited by Viacheslav Ostroukh

Merge request reports