QuantumOp#

class iqm.pulse.quantum_ops.QuantumOp(name, arity=1, params=<factory>, optional_params=<factory>, implementations=<factory>, symmetric=False, factorizable=False, defaults_for_locus=<factory>, unitary=None)#

Bases: object

Describes a native quantum operation type.

Quantum operations (or “ops” in short), are simple, abstract, self-contained actions one can execute on a station as parts of a quantum circuit. They include quantum gates, measurements, and resets. They must have an unambiguous definition in terms of their intended effect on the computational subspace of the quantum subsystems (qubits, qudits, qumodes…) they act on. They are implemented on the hardware using instruction schedules.

A QuantumOp can also be a metaoperation, which (in an idealized picture) has no effect on the quantum state, but affects the scheduling of the other ops. Execution barriers are an example of a metaoperation.

The ops can have any number of named parameters. For example, PRX is a two-parameter quantum gate family, whereas CZ is a single gate with no parameters.

A locus (plural: loci) is a tuple[str, ...] (an ordered sequence) of CHAD component names an instance of a quantum operation acts on. The locus consists of those QPU components that store the quantum information the operation acts on. For example, a CZ gate implemented using a flux pulse on the coupler connecting the qubits does not include the coupler in its locus, since the coupler is simply an implementation detail.

In a quantum circuit each operation type normally has several different loci. For example, you could have a PRX gate being used on qubits {('QB1',), ('QB2',), ('QB5',)}, or a CZ gate used on qubit pairs {('QB1', 'QB3'), ('QB3', 'QB5',), ('QB1', 'QB5',)}.

Each quantum operation can have any number of named implementations, each represented by a GateImplementation subclass. For example, we may have two implementations of the CZ gate, one with just a single flux pulse applied to the coupler, and another one with additional flux pulses applied to the qubits as well.

operation defines the abstract intention (what)
implementation defines the concrete method (how)
locus defines the target of the operation (where)

The quantum operations are typically calibrated using specific calibration experiments that output the required calibration data. Each implementation of each operation can require its own, independent set of calibration data for each locus.

Module: iqm.pulse.quantum_ops

Attributes

`arity`	Number of locus components the operation acts on.
`default_implementation`	Name of the default implementation (the global default).
`factorizable`	True iff the operation is always factorizable to independent single-subsystem operations, which is also how it is implemented, for example parallel single-qubit measurements.
`symmetric`	True iff the effect of operation is symmetric in the quantum subsystems it acts on.
`unitary`	Unitary matrix that represents the effect of this quantum operation in the computational basis, or `None` if the quantum operation is not unitary or the exact unitary is not known.
`name`	Unique name of the operation.
`params`	Maps names of required operation parameters to their allowed types.
`optional_params`	Maps names of optional operation parameters to their allowed types.
`implementations`	Maps implementation names to `GateImplementation` classes that provide them.
`defaults_for_locus`	Optionally define the implementation default individually per each locus.

Methods

`copy`	Make a copy of `self` with the given changes applied to the contents.
`get_default_implementation_for_locus`	Get the default (highest priority) implementation for the given locus.
`set_default_implementation`	Sets the given implementation as the default.
`set_default_implementation_for_locus`	Set the locus-specific default implementation.

Parameters:

name (str)
arity (int)
params (dict[str, tuple[type, ...]])
optional_params (dict[str, tuple[type, ...]])
implementations (dict[str, type[GateImplementation]])
symmetric (bool)
factorizable (bool)
defaults_for_locus (dict[Locus, str])
unitary (Callable[..., np.ndarray] | None)

name: str#: Unique name of the operation.

arity: int = 1#: Number of locus components the operation acts on. Each locus component corresponds to a quantum subsystem in the definition of the operation. The computational subspace always consists of the lowest two levels of the subsystem. Zero means the operation can be applied on any number of locus components.

params: dict[str, tuple[type, ...]]#: Maps names of required operation parameters to their allowed types.

optional_params: dict[str, tuple[type, ...]]#: Maps names of optional operation parameters to their allowed types.

implementations: dict[str, type[GateImplementation]]#: Maps implementation names to GateImplementation classes that provide them. Each such class should describe the implementation in detail in its docstring. The implementations are in the dict in priority order, highest-priority (default) first. This global priority order can be overridden per locus by the attribute defaults_for_locus.

symmetric: bool = False#: True iff the effect of operation is symmetric in the quantum subsystems it acts on. Only meaningful if self.arity != 1.

factorizable: bool = False#: True iff the operation is always factorizable to independent single-subsystem operations, which is also how it is implemented, for example parallel single-qubit measurements. In this case the operation calibration data is for individual subsystems as well.

defaults_for_locus: dict[Locus, str]#: Optionally define the implementation default individually per each locus. Maps the locus to the default gate implementation name. If a locus is not found in this dict (by default, the dict is empty), falls back to the global order defined in implementations. The implementations must be first registered in implementations.

unitary: Callable[..., np.ndarray] | None = None#: Unitary matrix that represents the effect of this quantum operation in the computational basis, or None if the quantum operation is not unitary or the exact unitary is not known. The Callable needs to take exactly the arguments given in params, for example if params={'angle': (float,), 'phase': (float,)}, the function must have signature f(angle: float, phase: float) -> np.ndarray. For operations acting on more than 1 qubit, unitary should be given in the big-endian order, i.e. in the basis np.kron(first_qubit_basis_ket, second_qubit_basis_ket).

copy(**changes)#

Make a copy of self with the given changes applied to the contents.

Return type:: QuantumOp

property default_implementation: str#: Name of the default implementation (the global default).

set_default_implementation(default)#

Sets the given implementation as the default.

Parameters:: default (str) – name of the new default implementation
Raises:: ValueError – default is unknown or is a special implementation.
Return type:: None

get_default_implementation_for_locus(locus)#

Get the default (highest priority) implementation for the given locus.

If no locus-specific priority is defined, returns the global default.

Parameters:: locus (Iterable[str]) – tuple of component names defining the locus.
Returns:: The default implementation name.
Return type:: str

set_default_implementation_for_locus(default, locus)#

Set the locus-specific default implementation.

Parameters:

default (str) – name of the new default implementation for locus.
locus (Iterable[str]) – tuple of component names defining the locus.

Raises:

ValueError – if there is no implementation defined with the name default or default is a special implementation.

Return type:

None

QuantumOp

Contents

QuantumOp#