common#
Common python dataclasses for multiple backends.
Module Contents#
Classes#
Software distortion correction information for a port-clock combination. |
|
Software distortion correction information for a port-clock combination. |
|
Parent class for hardware distortion correction. |
|
Modulation frequencies for a port-clock combination. |
|
Mixer corrections for a port-clock combination. |
|
Datastructure containing the hardware options for each port-clock combination. |
|
Information needed to specify a Local Oscillator in the |
|
Information needed to specify an IQ Mixer in the |
|
Information needed to specify an optical modulator in the |
|
Specifies a piece of hardware and its instrument-specific settings. |
|
Connectivity between ports on the quantum device and control hardware inputs/outputs. |
|
Information required to compile a schedule to the control-hardware layer. |
|
Metadata specifically for the ThresholdedTriggerCount acquisition. |
Attributes#
Latency correction in seconds for a port-clock combination. |
- LatencyCorrection[source]#
Latency correction in seconds for a port-clock combination.
Positive values delay the operations on the corresponding port-clock combination, while negative values shift the operation backwards in time with respect to other operations in the schedule.
Note
If the port-clock combination of a signal is not specified in the corrections, it is set to zero in compilation. The minimum correction over all port-clock combinations is then subtracted to allow for negative latency corrections and to ensure minimal wait time (see
determine_relative_latency_corrections()).Example
Let’s say we have specified two latency corrections in the CompilationConfig:
compilation_config.hardware_options.latency_corrections = { "q0:res-q0.ro": LatencyCorrection(-20e-9), "q0:mw-q0.01": LatencyCorrection(120e9), }
In this case, all operations on port
"q0:mw"and clock"q0.01"will be delayed by 140 ns with respect to operations on port"q0:res"and clock"q0.ro".
- class SoftwareDistortionCorrection(/, **data: Any)[source]#
Bases:
quantify_scheduler.structure.model.DataStructureSoftware distortion correction information for a port-clock combination.
Example
from quantify_scheduler.backends.types.common import ( SoftwareDistortionCorrection ) distortion_corrections = { "q0:fl-cl0.baseband": SoftwareDistortionCorrection( filter_func="scipy.signal.lfilter", input_var_name="x", kwargs={ "b": [0, 0.25, 0.5], "a": [1] }, clipping_values=[-2.5, 2.5] ) }
- kwargs: dict[str, list | quantify_scheduler.structure.types.NDArray][source]#
The keyword arguments that are passed to the filter_func.
- clipping_values: list | None = None[source]#
The optional boundaries to which the corrected pulses will be clipped, upon exceeding.
- classmethod _only_two_clipping_values(clipping_values) list | None | ValueError[source]#
- class DistortionCorrection(**data)[source]#
Bases:
quantify_scheduler.structure.model.DataStructureSoftware distortion correction information for a port-clock combination.
Note: deprecated and to be removed after 0.23.0. Please use
SoftwareDistortionCorrectioninstead.Example
from quantify_scheduler.backends.types.common import ( SoftwareDistortionCorrection ) distortion_corrections = { "q0:fl-cl0.baseband": SoftwareDistortionCorrection( filter_func="scipy.signal.lfilter", input_var_name="x", kwargs={ "b": [0, 0.25, 0.5], "a": [1] }, clipping_values=[-2.5, 2.5] ) }
- kwargs: dict[str, list | quantify_scheduler.structure.types.NDArray][source]#
The keyword arguments that are passed to the filter_func.
- class HardwareDistortionCorrection(/, **data: Any)[source]#
Bases:
quantify_scheduler.structure.model.DataStructureParent class for hardware distortion correction.
- class ModulationFrequencies(/, **data: Any)[source]#
Bases:
quantify_scheduler.structure.model.DataStructureModulation frequencies for a port-clock combination.
Example
from quantify_scheduler.backends.types.common import ( ModulationFrequencies ) modulation_frequencies = { "q0:res-q0.ro": ModulationFrequencies( interm_freq=None, lo_freq=6e9, ) }
- class MixerCorrections(/, **data: Any)[source]#
Bases:
quantify_scheduler.structure.model.DataStructureMixer corrections for a port-clock combination.
Example
from quantify_scheduler.backends.types.common import ( MixerCorrections ) mixer_corrections = { "q0:mw-q0.01": MixerCorrections( dc_offset_i = -0.0542, dc_offset_q = -0.0328, amp_ratio = 0.95, phase_error= 0.07, ) }
- dc_offset_i: float = 0.0[source]#
The DC offset on the I channel used for this port-clock combination.
- class HardwareOptions(/, **data: Any)[source]#
Bases:
quantify_scheduler.structure.model.DataStructureDatastructure containing the hardware options for each port-clock combination.
This datastructure contains the HardwareOptions that are currently shared among the existing backends. Subclassing is required to add backend-specific options, see e.g.,
QbloxHardwareOptions,ZIHardwareOptions.- crosstalk: dict[str, dict[str, float | complex]] | None = None[source]#
Dictionary containing the crosstalk values between ports on the quantum device. The crosstalk values are given as a dictionary of dictionaries, where the outer dictionary keys are the source ports and the inner dictionary keys are the target ports.
- latency_corrections: dict[str, LatencyCorrection] | None = None[source]#
Dictionary containing the latency corrections (values) that should be applied to operations on a certain port-clock combination (keys).
- distortion_corrections: dict[str, SoftwareDistortionCorrection] | None = None[source]#
Dictionary containing the distortion corrections (values) that should be applied to waveforms on a certain port-clock combination (keys).
- modulation_frequencies: dict[str, ModulationFrequencies] | None = None[source]#
Dictionary containing the modulation frequencies (values) that should be used for signals on a certain port-clock combination (keys).
- class LocalOscillatorDescription(/, **data: Any)[source]#
Bases:
quantify_scheduler.structure.model.DataStructureInformation needed to specify a Local Oscillator in the
CompilationConfig.- instrument_type: Literal['LocalOscillator'][source]#
The field discriminator for this HardwareDescription datastructure.
- instrument_name: str | None = None[source]#
The QCoDeS instrument name corresponding to this Local Oscillator.
- generic_icc_name: str | None = None[source]#
The name of the
GenericInstrumentCoordinatorComponentcorresponding to this Local Oscillator.
- class IQMixerDescription(/, **data: Any)[source]#
Bases:
quantify_scheduler.structure.model.DataStructureInformation needed to specify an IQ Mixer in the
CompilationConfig.
- class OpticalModulatorDescription(/, **data: Any)[source]#
Bases:
quantify_scheduler.structure.model.DataStructureInformation needed to specify an optical modulator in the
CompilationConfig.
- class HardwareDescription(/, **data: Any)[source]#
Bases:
quantify_scheduler.structure.model.DataStructureSpecifies a piece of hardware and its instrument-specific settings.
Each supported instrument type should have its own datastructure that inherits from this class. For examples, see
ClusterDescription,ZIHDAWG4Description,LocalOscillatorDescription.This datastructure is used to specify the control-hardware ports that are included in the
Connectivitygraph.
- class Connectivity(/, **data: Any)[source]#
Bases:
quantify_scheduler.structure.model.DataStructureConnectivity between ports on the quantum device and control hardware inputs/outputs.
The connectivity graph can be parsed from a list of edges, which are given by a set of two strings that each correspond to an input/output on an instrument or a port on the quantum device.
Note
To specify connections between more than one pair of ports at once, one can also specify a list of ports within the edge input (see example below, and also see Connectivity examples).
The connectivity graph can be drawn using
draw(), which groups the nodes according to the instrument name (specified by the string before the first"."in the node name; the name is omitted for the quantum device).Example
from quantify_scheduler.backends.types.common import ( Connectivity ) connectivity_dict = { "graph": [ ("awg0.channel_0", "q0:mw"), ("awg0.channel_1", "q1:mw"), ("rom0.channel_0", ["q0:res", "q1:res"]), ] } connectivity = Connectivity.model_validate(connectivity_dict) connectivity.draw()
<Axes: >
- graph: quantify_scheduler.structure.types.Graph[source]#
The connectivity graph consisting of i/o ports (nodes) on the quantum device and on the control hardware, and their connections (edges).
- serialize_graph(graph: quantify_scheduler.structure.types.Graph) list[tuple[Any, Any]][source]#
Serialize the graph as a list of edges.
- draw(ax: matplotlib.axes.Axes | None = None, figsize: tuple[float, float] = (20, 10), **options) matplotlib.axes.Axes[source]#
Draw the connectivity graph using matplotlib.
The nodes are positioned using a multipartite layout, where the nodes are grouped by instrument (identified by the first part of the node name).
- Parameters:
ax – Matplotlib axis to plot the figure on.
figsize – Optional figure size, defaults to something slightly larger that fits the size of the nodes.
options – optional keyword arguments that are passed to
networkx.draw_networkx.
- Returns:
: Matplotlib axis on which the figure is plotted.
- class HardwareCompilationConfig(/, **data: Any)[source]#
Bases:
quantify_scheduler.structure.model.DataStructureInformation required to compile a schedule to the control-hardware layer.
From a point of view of Compilation this information is needed to convert a schedule defined on a quantum-device layer to compiled instructions that can be executed on the control hardware.
This datastructure defines the overall structure of a
HardwareCompilationConfig. Specific hardware backends should customize fields within this structure by inheriting from this class and specifying their own “config_type”, see e.g.,QbloxHardwareCompilationConfig,ZIHardwareCompilationConfig.- config_type: type[HardwareCompilationConfig] = None[source]#
A reference to the
HardwareCompilationConfigDataStructure for the backend that is used.
- hardware_description: dict[str, HardwareDescription][source]#
Datastructure describing the control hardware instruments in the setup and their high-level settings.
- hardware_options: HardwareOptions[source]#
The
HardwareOptionsused in the compilation from the quantum-device layer to the control-hardware layer.
- connectivity: Connectivity | dict[source]#
Datastructure representing how ports on the quantum device are connected to ports on the control hardware.
- compilation_passes: list[quantify_scheduler.backends.graph_compilation.SimpleNodeConfig] = None[source]#
The list of compilation nodes that should be called in succession to compile a schedule to instructions for the control hardware.
- classmethod _import_config_type_if_str(config_type: type[HardwareCompilationConfig]) type[HardwareCompilationConfig][source]#
- class ThresholdedTriggerCountMetadata[source]#
Metadata specifically for the ThresholdedTriggerCount acquisition.
- condition: quantify_scheduler.enums.TriggerCondition[source]#
The comparison condition (greater-equal, less-than) for the ThresholdedTriggerCount acquisition.