Alternative structure hardware options

Explanation of changes

Current implementation: CompilationConfig.hardware_options: Optional[HardwareOptions], where the HardwareOptions datastructure contains sub-datastructures for (e.g.) the DistortionCorrections and LatencyCorrections

Proposed alternative 1: CompilationConfig.hardware_options: Optional[HardwareOptions], where the HardwareOptions datastructure contains fields for (e.g.) the distortion_corrections: Dict[str, DistortionCorrection] and latency_corrections: Dict[str, LatencyCorrection], where str is a port-clock combination, a DistortionCorrection is a datastructure, and LatencyCorrection is a float.

• Also enables some ruff checks on the backends.graph_compilation module and improves its (documentation) formatting.

Motivation of changes

• Removes the need for an extra field name in the specific hardware options datastrucutres, e.g. LatencyCorrections.corrections
• Makes it easier to add structure to the specific hardware options datastrucutres. For example, look at the diff for DistortionCorrection datastructure; it now contains fields for the parameters instead of having DistortionCorrections.corrections: Dict[str,Dict] (where we would probably have to create another datastructure/class to do validation on the last Dict anyways).

See also &1 (closed)

Alternative solution

I also tried a different solution:

Proposed alternative 2 (old): CompilationConfig.hardware_options: Optional[Dict[str, list[HardwareOption]]], where the str represents a port-clock combination and HardwareOption datastructure is a base class for e.g. LatencyCorrection and DistortionCorrection, which are datastructures for the corrections on a single port-clock combination

However, this alternative has the following issues:

1. Since the port-clock combinations keys of the hardware_options are stored at the very top of the structure, different hardware options on the same port-clock combination have to be stored in a list, which makes it hard to extract a specific HardwareOption on a specific port-clock combination (e.g., extract the latency correction on "q0:res-q0.ro"). One would need to loop over the elements in CompilationConfig.hardware_options[port_clock]: list to find it.
2. This structure enforces all HardwareOptions have to be stored on a port-clock basis, which might be too stringent for future use cases.

---

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 (or N/A).
• Tested on hardware (or N/A).
• CHANGELOG.md and AUTHORS.md have been updated (or N/A).
• Windows tests in CI pipeline pass (manually triggered by maintainers before merging).

---

For reference, the issues workflow is described in the contribution guidelines.