Skip to content

Fix propagation of digitization_thresholds to the compiled settings

Thomas Middelburgrequested to merge
fix_seq_settings_in_compiler into main

Explanation of changes

The digitization_thresholds hardware option was not added to the _SequencerCompilationConfig, and therefore did not end up in TimetagSequencerSettings.

In addition I created a separate test file for hardware config validation tests, in an effort to reduce the number of lines in test_qblox_backend.py.

Motivation of changes

I went for a very basic fix, but I noticed quite a few things "wrong" with the hardware configuration still. These should be refactored. I spotted these issues (captured in a jira ticket already):

  • These _extract... methods (in _ClusterCompilationConfig, etc.) are not great if you, e.g., want to have different config types for different module types (not open-closed).
    • However, given the structure of QbloxHardwareCompilaitonConfig, it is quite expensive to generate each cluster config or each module config one-by-one.
  • _SequencerCompilationConfig is confusing because some fields are inside SequencerOptions and others aren't, for seemingly no reason.
  • And you have this extra conversion to TimetagSequencerSettings, AnalogSequencerSettings, RFModuleSettings, TimetagModuleSettings, etc. Why not generate these immediately from the base hardware config?

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 for breaking changes and AUTHORS.md have been updated (or N/A).
  • Update Hardware backends documentation if backend interface change or N/A
  • Check whether performance is significantly affected by looking at the Performance metrics results.
  • 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 Thomas Middelburg

Merge request reports