QuantumOp#

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

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

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.

params

Names of required operation parameters, if any.

symmetric

True iff the effect of operation is symmetric in the quantum subsystems it acts on.

name

Unique name of the operation.

arity

Number of locus components the operation acts on.

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#

Unique name of the operation.

arity: int#

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: tuple[str, ...] = ()#

Names of required operation parameters, if any.

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[tuple[str, ...], 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.

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:

ValueErrordefault 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