iqm.qiskit_iqm.iqm_provider.IQMBackend#

class iqm.qiskit_iqm.iqm_provider.IQMBackend(client: IQMClient, **kwargs)#

Bases: IQMBackendBase

Backend for executing quantum circuits on IQM quantum computers.

Parameters:
  • client (IQMClient) – client instance for communicating with an IQM server

  • **kwargs – optional arguments to be passed to the parent Backend initializer

Attributes

max_circuits

Maximum number of circuits that should be run in a single batch.

architecture

name

Name of the backend.

description

Optional human-readable description.

online_date

Date that the backend came online.

backend_version

Version of the backend being provided.

Methods

_default_options()

Return the default options

close_client()

Close IQMClient's session with the authentication server.

create_run_request(run_input, **options)

Creates a run request without submitting it for execution.

retrieve_job(job_id)

Create and return an IQMJob instance associated with this backend with given job id.

run(run_input, *[, timeout_seconds])

Run a quantum circuit or a list of quantum circuits on the IQM quantum computer represented by this backend.

serialize_circuit(circuit)

Serialize a quantum circuit into the IQM data transfer format.

property max_circuits: int | None#

Maximum number of circuits that should be run in a single batch.

Currently there is no hard limit on the number of circuits that can be executed in a single batch/job. However, some libraries like Qiskit Experiments use this property to split multi-circuit computational tasks into multiple baches/jobs.

The default value is None, meaning there is no limit. You can set it to a specific integer value to force these libraries to run at most that many circuits in a single batch.

run(run_input: QuantumCircuit | list[QuantumCircuit], *, timeout_seconds: float | None = None, **options) IQMJob#

Run a quantum circuit or a list of quantum circuits on the IQM quantum computer represented by this backend.

Parameters:
Returns:

Job object from which the results can be obtained once the execution has finished.

Return type:

IQMJob

create_run_request(run_input: QuantumCircuit | list[QuantumCircuit], **options) RunRequest#

Creates a run request without submitting it for execution.

This can be used to check what would be submitted for execution by an equivalent call to run().

Parameters:

run_input (QuantumCircuit | list[QuantumCircuit]) – Same as in run().

Keyword Arguments:
  • shots (int) – Number of repetitions of each circuit, for sampling. Default is 1024.

  • calibration_set_id (Union[str, UUID, None]) – ID of the calibration set to use for the run. Default is None, which means the IQM server will use the current default calibration set.

  • circuit_compilation_options (iqm.iqm_client.models.CircuitCompilationOptions) – Compilation options for the circuits, passed on to iqm-client.

  • circuit_callback (collections.abc.Callable[[list[QuantumCircuit]], Any]) – Callback function that, if provided, will be called for the circuits before sending them to the device. This may be useful in situations when you do not have explicit control over transpilation, but need some information on how it was done. This can happen, for example, when you use pre-implemented algorithms and experiments in Qiskit, where the implementation of the said algorithm or experiment takes care of delivering correctly transpiled circuits to the backend. This callback method gives you a chance to look into those transpiled circuits, and extract any info you need. As a side effect, you can also use this callback to modify the transpiled circuits in-place, just before execution; however, we do not recommend to use it for this purpose.

Returns:

created run request object

Return type:

RunRequest

retrieve_job(job_id: str) IQMJob#

Create and return an IQMJob instance associated with this backend with given job id.

Parameters:

job_id (str) –

Return type:

IQMJob

close_client() None#

Close IQMClient’s session with the authentication server.

Return type:

None

serialize_circuit(circuit: QuantumCircuit) Circuit#

Serialize a quantum circuit into the IQM data transfer format.

Serializing is not strictly bound to the native gateset, i.e. some gates that are not explicitly mentioned in the native gateset of the backend can still be serialized. For example, the native single qubit gate for IQM backend is the ‘r’ gate, however ‘x’, ‘rx’, ‘y’ and ‘ry’ gates can also be serialized since they are just particular cases of the ‘r’ gate. If the circuit was transpiled against a backend using Qiskit’s transpiler machinery, these gates are not supposed to be present. However, when constructing circuits manually and submitting directly to the backend, it is sometimes more explicit and understandable to use these concrete gates rather than ‘r’. Serializing them explicitly makes it possible for the backend to accept such circuits.

Qiskit uses one measurement instruction per qubit (i.e. there is no measurement grouping concept). While serializing we do not group any measurements together but rather associate a unique measurement key with each measurement instruction, so that the results can later be reconstructed correctly (see MeasurementKey documentation for more details).

Parameters:

circuit (QuantumCircuit) – quantum circuit to serialize

Returns:

data transfer object representing the circuit

Raises:

ValueError – circuit contains an unsupported instruction or is not transpiled in general

Return type:

Circuit