iqm-client 32.0.0__tar.gz → 33.0.0__tar.gz

{iqm_client-32.0.0 → iqm_client-33.0.0}/CHANGELOG.rst

@@ -1,6 +1,59 @@
-=========
-Changelog
-=========
+Version 33.0.0 (2025-11-19)
+===========================
+
+Breaking changes
+----------------
+
+- :class:`.IQMClient` now connects to IQM Server instead of directly to Station Control service.
+  - The ``url`` init parameter for :class:`.IQMClient` is replaced by ``iqm_server_url``.
+    In addition the class can take the ``quantum_computer`` parameter to connect to a specific
+    quantum computer on a server with several. If your IQM Server instance only has one quantum computer,
+    you can leave this parameter to its default value.
+  - The ``timeout_secs`` parameter is removed for all :class:`.IQMClient` methods, value from the
+    :envvar:`IQM_CLIENT_REQUESTS_TIMEOUT` environment variable is used instead (default 120 seconds).
+  - :meth:`IQMClient.get_quality_metric_set` and :meth:`IQMClient.get_calibration_set` now return
+    slightly different data models with more complete observation data.
+  - Circuit and job related models have been moved to :mod:`iqm.station_control.interface.models`
+    from IQM client models, to avoid code duplication and use the same models in all SW
+    components. Imports have to be updated.
+  - :meth:`IQMClient.submit_circuits` no longer has the parameter ``custom_settings``. Use Pulla if
+    you need this functionalty.
+  - :meth:`IQMClient.submit_circuits` and :meth:`IQMClient.submit_run_request` now return a
+    :class:`.CircuitJob` object instead of the plain job ID.  The job object contains the job ID,
+    and provides methods for monitoring the job's state and retrieving its results.
+  - :meth:`IQMClient.get_run` is replaced by :meth:`IQMClient.get_job`, which returns a
+    :class:`.CircuitJob` object. The job results can be queried using :class:`CircuitJob.result`.
+  - :meth:`IQMClient.get_run_status` is removed, you can check the job object for its status using
+    :class:`CircuitJob.update`.
+  - :meth:`IQMClient.wait_for_compilation` and :meth:`IQMClient.wait_for_results` are removed,
+    use :class:`CircuitJob.wait_for_completion` instead.
+  - :meth:`IQMClient.get_run_counts` is replaced by :meth:`IQMClient.get_job_measurement_counts`.
+  - :meth:`IQMClient.abort_job` is replaced by :meth:`IQMClient.cancel_job`.
+- The :mod:`iqm.iqm_server_client.authentication` module including :class:`TokenManager` has been moved to
+  :mod:`iqm.station_control.client.authentication`, and its API has slightly changed.
+
+Features
+--------
+
+- ``iqm-client`` integration guide updated.
+- :meth:`IQMClient.submit_circuits` and :meth:`IQMClient.submit_run_request` have a new parameter,
+  ``use_timeslot``, which indicates if the job should be submitted to a timeslot queue or the
+  shared on-demand queue.
+- Minimal changes to support Qiskit v2.0 and v2.1 :issue:`SW-1735`.
+- Deprecation warning for Qiskit versions < 2.0.
+- Bugfix in the transpile example to select qubits from the largest connected subgraph of the backend so that the code works when running against a disconnected graph.
+- Identified potential bug with semantic equivalence of transpiled circuits when using the IQMNaiveMovePass. Tests are temporarily marked as expected to fail. :issue:`SW-1999`.
+
+Version 32.1.0 (2025-10-13)
+===========================
+
+Features
+--------
+
+- Add support for the ``with circuit.if_test()`` construction for classical control in Qiskit :issue:`SW-1724`.
+- Deprecate the ``c_if`` method in favor of the new ``if_test`` method for classical control in Qiskit :issue:`SW-1724`.
+- Bugfix: Fixed the transpiler bug causing classical conditionals to be ignored in certain cases :issue:`SW-1856`.
+- Using one of our transpiler plugins that do not apply MoveGate routing, no longer raises an error when the target backend is not set in the transpiler. e.g. ``transpile(circuit, scheduling_method="only_rz_optimization", basis_gates=['r','cz', 'if_else'])``.
 
 Version 32.0.0 (2025-10-09)
 ===========================
@@ -462,7 +515,7 @@ Version 23.1.0 (2025-04-07)
 Features
 --------
 
-- Fix package version in published docs footers, :issue:`SW-1392`. 
+- Fix package version in published docs footers, :issue:`SW-1392`.
 
 Version 23.0.0 (2025-04-04)
 ===========================

iqm_client-33.0.0/INTEGRATION_GUIDE.rst

@@ -0,0 +1,228 @@
+=================
+Integration Guide
+=================
+
+``iqm-client`` is the Python client for connecting to IQM's quantum computers, for application-level
+quantum computing frameworks.  For examples of integrations maintained by IQM, please refer to the
+:ref:`Qiskit <User guide Qiskit>` and :ref:`Cirq <User guide Cirq>` packages.
+
+IQM client offers the functionality to submit quantum circuit execution jobs to the quantum computer,
+track the statuses of jobs, and query various properties of the quantum computer.
+
+The following sections illustrate how to integrate IQM quantum computers into your quantum computing
+framework.
+
+
+Authentication
+--------------
+
+IQM uses bearer token authentication to manage access to quantum computers.
+Get your personal API token from the IQM Server web dashboard. The generated token can be provided to
+IQM client via an environment variable :envvar:`IQM_TOKEN`.
+Alternatively, the token can be provided as the ``token`` argument to :class:`.IQMClient` constructor.
+
+
+Code example
+------------
+
+The connection to an IQM Server instance is managed by an :class:`.IQMClient` instance.
+Initialization is simple, and in case you perform the authentication
+using the :envvar:`IQM_TOKEN` environment variable, it only requires the URL of IQM Server:
+
+.. code-block:: python
+
+    from iqm.iqm_client import IQMClient
+
+    server_url = "https://<IQM_SERVER_URL>"
+    iqm_client = IQMClient(server_url)
+
+To submit a quantum circuit for execution, it has to be specified using the
+:class:`iqm.pulse.Circuit` class. The available native instructions are documented in
+:mod:`iqm.iqm_client.models` and in :class:`iqm.pulse.CircuitOperation`.
+
+.. code-block:: python
+
+    from math import pi
+
+    from iqm.pulse.builder import CircuitOperation
+    from iqm.pulse.circuit_operations import Circuit
+
+    instructions = (
+        CircuitOperation(
+            name="prx", locus=("QB1",), args={"phase": 1.4 * pi, "angle": 0.5 * pi}
+        ),
+        CircuitOperation(name="cz", locus=("QB1", "QB2"), args={}),
+        CircuitOperation(name="measure", locus=("QB2",), args={"key": "Qubit 2"}),
+    )
+
+    circuit = Circuit(name="quantum_circuit", instructions=instructions)
+
+Then the circuit(s) can be submitted to the server using :meth:`.IQMClient.submit_circuits`.
+Upon successful submission the method returns a :class:`.CircuitJob` object that can be used
+to track the progress of the job. This is a convenience, the only thing that is really needed
+to access the job on IQM Server is the unique job ID in :attr:`.CircuitJob.job_id`.
+You can pass the job ID to :meth:`.IQMClient.get_job` to get a new :class:`.CircuitJob` object for the job.
+
+To query the status of the job, use :meth:`.CircuitJob.update`. It will update the job object and
+return its current status. The different job statuses are documented in :class:`.JobStatus`.
+
+.. code-block:: python
+
+    job = iqm_client.submit_circuits([circuit], shots=1000)
+    print(job.job_id)
+
+    job_status = job.update()
+    print(job_status)
+
+
+Eventually the job will end up in one of the terminal statuses:
+``"completed"``, ``"failed"``, or ``"cancelled"``.
+You can either periodically query the status, or use :meth:`.CircuitJob.wait_for_completion`
+which will block and poll the job status until it hits a terminal status, which is then returned.
+
+When the status is ``"completed"``, you can use :meth:`.CircuitJob.result` to get the job results:
+
+.. code-block:: python
+
+    job_status = job.wait_for_completion()
+    print(job_status)
+    job_result = job.result()
+
+A job can be cancelled by calling :meth:`.CircuitJob.cancel`.
+
+
+Job payload
+-----------
+
+A ``dict[str, Any]`` containing arbitrary metadata can be attached to :class:`iqm.pulse.Circuit`
+before submitting it for execution.
+The attached metadata should consist only of values of JSON serializable datatypes.
+A utility function :func:`~.iqm_client.util.to_json_dict` can be used to convert supported datatypes,
+e.g. :class:`numpy.ndarray`, to equivalent JSON serializable types.
+
+The server stores the job payload (including the metadata), and it can be queried using
+:meth:`.CircuitJob.payload`, which returns the submitted circuits (with their metadata), and
+the various job parameters used.
+
+
+Job metadata and errors
+-----------------------
+
+The server attaches its own metadata to the job, including details related to the compilation
+and execution of the job. Important metadata items include
+
+* :attr:`.CircuitJob.data.errors`: list of errors for a ``"failed"`` job
+* :attr:`.CircuitJob.data.messages`: list of informational messages
+* :attr:`.CircuitJob.data.timeline`: list of execution steps reached with their timestamps
+* :attr:`.CircuitJob.data.compilation.calibration_set_id`: ID of the calibration set used in the execution
+
+
+Job timeline
+~~~~~~~~~~~~
+
+Each item in :attr:`.CircuitJob.data.timeline` is a :class:`.TimelineEntry`,
+containing an execution step reached, a timestamp, and the source of the entry.
+The steps in the timeline are more detailed than the job statuses.
+For example, when the job is accepted, IQM Server adds a timestamp with the status ``"created"``.
+
+The timeline entries also contain information about the lower-level job processing steps by
+Station Control. For example, before the circuits can be executed they are compiled into instruction
+schedules, indicated by the ``"compilation_started"`` and ``"compilation_ended"`` timestamps.
+The actual execution of the job on the quantum hardware is indicated by the
+``"execution_started"`` and ``"execution_ended"`` timestamps.
+
+
+Circuit transpilation
+---------------------
+
+IQM does not provide an open source circuit transpilation library, so this will have to be supplied
+by the quantum computing framework or a third party library.  To obtain the necessary information
+for circuit transpilation, :meth:`.IQMClient.get_dynamic_quantum_architecture` returns the names of the
+QPU components (qubits and computational resonators), and the native operations available
+in the given calibration set. This information should enable circuit transpilation for the
+IQM Crystal quantum architectures.
+
+The notable exception is the transpilation for the IQM Star quantum architectures, which have
+computational resonators in addition to qubits. Some specialized transpilation logic involving
+the MOVE gates specific to these architectures is provided, in the form of the functions
+:func:`.transpile_insert_moves` and :func:`.transpile_remove_moves`.
+See :mod:`iqm.iqm_client.transpile` for the details.
+
+A typical Star architecture use case would look something like this:
+
+.. code-block:: python
+
+    from iqm.iqm_client import IQMClient, simplify_architecture, transpile_insert_moves, transpile_remove_moves
+    from iqm.pulse.circuit_operations import Circuit
+
+    client = IQMClient(URL_TO_STAR_SERVER)
+    dqa = client.get_dynamic_quantum_architecture()
+    simplified_dqa = simplify_architecture(dqa)
+
+    # circuit valid for simplified_dqa
+    circuit = Circuit(name="quantum_circuit", instructions=[...])
+
+    # intended use
+    circuit_with_moves = transpile_insert_moves(circuit, dqa)
+    job = client.submit_circuits([circuit_with_moves])
+
+    # back to simplified dqa
+    circuit_without_moves = transpile_remove_moves(circuit_with_moves)
+    # circuit_without_moves is equivalent to circuit
+
+
+Note on qubit mapping
+---------------------
+
+We encourage to transpile circuits to use the physical IQM qubit names before submitting them to IQM
+quantum computers.  In case the quantum computing framework does not allow for this, providing a
+qubit mapping can do the translation from the framework qubit names to IQM qubit names.  Note that
+qubit mapping is not supposed to be associated with individual circuits, but rather with the entire
+job request to IQM Server.  Typically, you would have some local representation of the QPU and
+transpile the circuits against that representation, then use qubit mapping along with the generated
+circuits to map from the local representation to the IQM representation of qubit names.
+We discourage exposing this feature to end users of the quantum computing framework.
+
+Note on circuit duration check
+------------------------------
+
+Before performing circuit execution, IQM Server checks how long it would take to run each circuit.
+If any circuit in a job would take too long to execute compared to the T2 time of the qubits,
+the server will disqualify the job, not execute any circuits, and return a detailed error message.
+In some special cases, it makes sense to adjust or disable this check using
+the :attr:`max_circuit_duration_over_t2` attribute of :class:`.CircuitCompilationOptions`,
+and then passing the options to :meth:`.IQMClient.submit_circuits`.
+
+Note on environment variables
+-----------------------------
+
+Set :envvar:`IQM_CLIENT_REQUESTS_TIMEOUT` environment variable to override the network request
+default timeout value (in seconds) for :class:`.IQMClient` methods.  The default value is 120
+seconds and might not be sufficient e.g.  when fetching the results of a larger circuit job through
+a slow network connection.
+
+On Linux:
+
+.. code-block:: bash
+
+  $ export IQM_CLIENT_REQUESTS_TIMEOUT=300
+
+On Windows:
+
+.. code-block:: batch
+
+  set IQM_CLIENT_REQUESTS_TIMEOUT=300
+
+Set :envvar:`IQM_CLIENT_SECONDS_BETWEEN_CALLS` to control the polling interval (in seconds) when
+waiting for a job to complete with :meth:`.CircuitJob.wait_for_completion`.
+The default value is 1 second.
+
+Set :envvar:`IQM_CLIENT_DEBUG=1` to print the run request when it is submitted for execution in
+:meth:`.IQMClient.submit_circuits` or :meth:`.IQMClient.submit_run_request`. To inspect the run
+request without sending it for execution, use :meth:`.IQMClient.create_run_request`.
+
+Integration testing
+-------------------
+
+IQM provides a demo environment to test the integration against a mock quantum computer. If you'd
+like to request access to that environment, please contact `IQM <info@meetiqm.com>`_.

iqm_client-33.0.0/MANIFEST.in

@@ -0,0 +1,4 @@
+include version.txt
+include LICENSE.txt
+prune tests/*
+exclude .gitlab-ci.yml

{iqm_client-32.0.0/src/iqm_client.egg-info → iqm_client-33.0.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.1
 Name: iqm-client
-Version: 32.0.0
+Version: 33.0.0
 Summary: Client library for accessing an IQM quantum computer
 Author-email: IQM Finland Oy <developers@meetiqm.com>
 License:                                  Apache License
@@ -216,35 +216,25 @@ Requires-Python: <3.13,>=3.10
 Description-Content-Type: text/x-rst
 License-File: LICENSE.txt
 License-File: AUTHORS.rst
-Requires-Dist: iqm-station-control-client<12,>=11
-Requires-Dist: iqm-exa-common<28,>=27
-Requires-Dist: iqm-pulse<13,>=12
 Requires-Dist: numpy<3.0,>=1.26.4
 Requires-Dist: packaging==24.1
 Requires-Dist: pydantic<3.0,>=2.9.2
 Requires-Dist: requests==2.32.3
+Requires-Dist: iqm-pulse
+Requires-Dist: iqm-station-control-client
 Provides-Extra: cirq
-Requires-Dist: iqm-station-control-client<12,>=11; extra == "cirq"
-Requires-Dist: iqm-exa-common<28,>=27; extra == "cirq"
-Requires-Dist: iqm-pulse<13,>=12; extra == "cirq"
 Requires-Dist: cirq-core[contrib]~=1.2; extra == "cirq"
 Requires-Dist: ply==3.11; extra == "cirq"
 Requires-Dist: llvmlite>=0.44.0; extra == "cirq"
 Requires-Dist: numba>=0.61.0; extra == "cirq"
 Provides-Extra: cli
-Requires-Dist: iqm-station-control-client<12,>=11; extra == "cli"
-Requires-Dist: iqm-exa-common<28,>=27; extra == "cli"
-Requires-Dist: iqm-pulse<13,>=12; extra == "cli"
 Requires-Dist: click<9,>=8.1.6; extra == "cli"
 Requires-Dist: jsonschema>=4.6.0; extra == "cli"
 Requires-Dist: psutil>=5.9.2; extra == "cli"
 Requires-Dist: types-psutil; extra == "cli"
 Requires-Dist: python-daemon>=2.3.0; extra == "cli"
 Provides-Extra: qiskit
-Requires-Dist: iqm-station-control-client<12,>=11; extra == "qiskit"
-Requires-Dist: iqm-exa-common<28,>=27; extra == "qiskit"
-Requires-Dist: iqm-pulse<13,>=12; extra == "qiskit"
-Requires-Dist: qiskit<=1.4.2,>=1.0; extra == "qiskit"
+Requires-Dist: qiskit<2.2,>=1.0; extra == "qiskit"
 Requires-Dist: qiskit-aer<0.18,>=0.13.1; extra == "qiskit"
 
 IQM Client

iqm_client-33.0.0/docs/changelog.rst

@@ -0,0 +1,8 @@
+.. _changelog:
+
+=========
+CHANGELOG
+=========
+
+.. include:: ../CHANGELOG.rst
+   :literal:

{iqm_client-32.0.0 → iqm_client-33.0.0}/docs/index.rst

@@ -21,14 +21,13 @@ Contents
    integration_guide
    user_guide_qiskit
    user_guide_cirq
+   changelog
    license
    authors
 
 .. toctree::
    :maxdepth: 1
 
-   changelog
-
 
 Indices and tables
 ==================

{iqm_client-32.0.0 → iqm_client-33.0.0}/docs/user_guide_cirq.rst

@@ -349,7 +349,7 @@ In this subsection we demonstrate how to run them on an IQM quantum computer.
 
 Cirq on IQM provides :class:`.IQMSampler`, a subclass of :class:`cirq.work.Sampler`, which is used
 to execute quantum circuits and decompose/route them for the architecture of the quantum computer.
-Once you have access to an IQM server you can create an :class:`.IQMSampler` instance and use its
+Once you have access to an IQM Server you can create an :class:`.IQMSampler` instance and use its
 :meth:`~.IQMSampler.run` method to send a circuit for execution and retrieve the results:
 
 .. code-block:: python
@@ -358,7 +358,7 @@ Once you have access to an IQM server you can create an :class:`.IQMSampler` ins
 
    # circuit = ...
 
-   sampler = IQMSampler(iqm_server_url)
+   sampler = IQMSampler(iqm_server_url, quantum_computer=quantum_computer)
    routed_circuit, _, _ = sampler.device.route_circuit(circuit)
    decomposed_circuit = sampler.device.decompose_circuit(routed_circuit)
    result = sampler.run(decomposed_circuit, repetitions=10)
@@ -366,7 +366,9 @@ Once you have access to an IQM server you can create an :class:`.IQMSampler` ins
 
 
 Note that the code snippet above assumes that you have set the variable ``iqm_server_url`` to the URL
-of the IQM server. Additionally, you can pass IQM backend specific options to the :class:`.IQMSampler` class.
+of the IQM Server, and ``quantum_computer`` to the name of the quantum computer to use, if the IQM Server
+has several. Leave it to ``None`` to use the default (or only) quantum computer of the server.
+Additionally, you can pass IQM backend specific options to the :class:`.IQMSampler` class.
 The below table summarises the currently available options:
 
 
@@ -381,7 +383,7 @@ The below table summarises the currently available options:
    * - :attr:`calibration_set_id`
      - :class:`uuid.UUID`
      - "f7d9642e-b0ca-4f2d-af2a-30195bd7a76d"
-     - Indicates the calibration set to use. Defaults to ``None``, which means the IQM server will use the
+     - Indicates the calibration set to use. Defaults to ``None``, which means the IQM Server will use the
        current default calibration set automatically.
    * - :attr:`compiler_options`
      - :class:`~iqm.iqm_client.models.CircuitCompilationOptions`

{iqm_client-32.0.0 → iqm_client-33.0.0}/docs/user_guide_qiskit.rst

@@ -31,7 +31,7 @@ things are set up correctly.
    (Save Page As...)
 5. Install Qiskit on IQM as instructed below.
 6. Run the Jupyter notebook (or run
-   ``python bell_measure.py --url https://<IQM server URL>``
+   ``python bell_measure.py --url https://<IQM Server URL>``
    if you decided to go for the Python script).
 7. If you're connecting to a real quantum computer, the output should show almost half of the
    measurements resulting in '00000' and almost half in '11111' - if this is the case, things are
@@ -115,7 +115,8 @@ Let's consider the following quantum circuit which prepares and measures a GHZ s
 
 
 To run this circuit on an IQM quantum computer you need to initialize an :class:`.IQMProvider`
-instance with the IQM server URL, use it to retrieve an :class:`.IQMBackend` instance representing
+instance with the IQM Server URL (and possibly a quantum computer name, if there are several),
+use it to retrieve an :class:`.IQMBackend` instance representing
 the quantum computer, and use Qiskit's :func:`~qiskit.compiler.transpile` function
 followed by :meth:`.IQMBackend.run` as usual.  ``shots`` denotes the number of times the quantum
 circuit(s) are sampled:
@@ -126,7 +127,8 @@ circuit(s) are sampled:
     from iqm.qiskit_iqm import IQMProvider
 
     iqm_server_url = "https://<IQM SERVER>"  # Replace this with the correct URL
-    provider = IQMProvider(iqm_server_url)
+    quantum_computer = "<NAME>"
+    provider = IQMProvider(iqm_server_url, quantum_computer=quantum_computer)
     backend = provider.get_backend()
 
     transpiled_circuit = transpile(circuit, backend=backend)
@@ -151,8 +153,7 @@ circuit(s) are sampled:
     As of ``iqm-client >= 30.1.0``, structured quality metrics and calibration data are available to
     ``IQMTarget`` for improved transpilation. To import the latest valid quality metric data corresponding
     to the default calibration set into ``IQMTarget``, set ``use_metrics`` to ``True`` when initializing the
-    class. For Resonance users, this data is not yet available via the Resonance API, so use the default setting
-    of ``use_metrics`` of ``False``.
+    class.
 
 You can optionally provide IQMBackend specific options as additional keyword arguments to
 :meth:`.IQMBackend.run`, documented at :meth:`.IQMBackend.create_run_request`.
@@ -189,48 +190,42 @@ The results of a job that was executed on the IQM quantum computer, represented
     print(result.get_counts())
     print(result.get_memory())
 
-The result comes with some metadata, such as the :class:`~iqm.iqm_client.models.RunRequest` that
-produced it in ``result.request``. The request contains e.g. the qubit mapping and the ID of the
-calibration set that were used in the execution:
+The result comes with some metadata, such as the contents of the request that
+produced it. The executed circuit batch (in the native IQM format) can be found in ``result.circuits``,
+and various execution parameters can be found in ``result.parameters``:
 
 .. code-block:: python
 
-    print(result.request.qubit_mapping)
-    print(result.request.calibration_set_id)
+    print(result.parameters.shots)
+    print(result.parameters.calibration_set_id)
 
 ::
 
-    [
-      SingleQubitMapping(logical_name='0', physical_name='QB1'),
-      SingleQubitMapping(logical_name='1', physical_name='QB2'),
-      SingleQubitMapping(logical_name='2', physical_name='QB3')
-    ]
+    1000
     1320eae6-f4e2-424d-b299-ef82d556d2c3
 
 Another piece of useful metadata are the timestamps of the various steps of processing the job. The
-timestamps are stored in the dict ``result.timestamps``. The job processing has three steps,
+timestamps are stored in the list ``result.timeline``. The actual job processing has three main steps,
 
-* ``compile`` where the circuits are converted to instruction schedules,
-* ``submit`` where the instruction schedules are submitted for execution, and
-* ``execution`` where the instruction schedules are executed and the measurement results are returned.
+* ``compilation`` where the circuits are converted to instruction schedules,
+* ``execution`` where the instruction schedules are executed and the measurement results are returned, and
+* ``post_processing`` where the results are converted to the format expected by the client.
 
-The dict contains a timestamp for the start and end of each step.
-For example, the timestamp of starting the circuit compilation is stored with key ``compile_start``.
-In the same way the other steps have their own timestamps with keys consisting of the step name and a ``_start`` or
-``_end`` suffix. In addition to processing step timestamps, there are also timestamps for the job itself,
-``job_start`` for when the job request was received by the server and ``job_end`` for when the job processing
+The list contains a timestamp for the start and end of each step.
+For example, the timestamp of starting the circuit compilation is stored with the status ``compilation_started``.
+In the same way the other steps have their own timestamps with statuses consisting of the step name and a ``_started``
+or ``_ended`` suffix. In addition to processing step timestamps, there are also timestamps for the job itself,
+``created`` for when the job request was accepted by the server and ``completed`` for when the job processing
 was finished.
 
 If the processing of the job is terminated before it is complete, for example due to an error, the timestamps of
-processing steps that were not taken are not present in the dict.
+processing steps that were not taken are not present.
 
 For example:
 
 .. code-block:: python
 
-    print(result.timestamps['job_start'])
-    print(result.timestamps['compile_start'])
-    print(result.timestamps['execution_end'])
+    print(result.timeline)
 
 
 Backend properties
@@ -279,11 +274,11 @@ support currently has several limitations:
   apply the gate if the bit is 1, and apply an identity gate if the bit is 0.
 * The availability of the controlled gates depends on the instrumentation of the quantum computer.
 
-The classical control can be applied on a circuit instruction using :meth:`~qiskit.circuit.Instruction.c_if`:
+The classical control can be applied on a circuit instruction using :meth:`~qiskit.circuit.QuantumCircuit.if_test`:
 
 .. code-block:: python
 
-    from qiskit import QuantumCircuit
+    from qiskit import QuantumCircuit, QuantumRegister, ClassicalRegister
 
     qr = QuantumRegister(2, 'q')
     cr = ClassicalRegister(1, 'c')
@@ -291,26 +286,27 @@ The classical control can be applied on a circuit instruction using :meth:`~qisk
 
     circuit.h(0)
     circuit.measure(0, cr[0])
-    circuit.x(1).c_if(cr, 1)
+    with circuit.if_test((cr[0], 1)):
+        circuit.x(1)  # apply X gate on qubit 1 if cr[0] is 1
     circuit.measure_all()
 
     print(circuit.draw(output='text'))
 
 ::
 
-            ┌───┐┌─┐        ░ ┌─┐
-       q_0: ┤ H ├┤M├────────░─┤M├───
-            └───┘└╥┘ ┌───┐  ░ └╥┘┌─┐
-       q_1: ──────╫──┤ X ├──░──╫─┤M├
-                  ║  └─╥─┘  ░  ║ └╥┘
-                  ║ ┌──╨──┐    ║  ║
-       c: 1/══════╩═╡ 0x1 ╞════╬══╬═
-                  0 └─────┘    ║  ║
-    meas: 2/═══════════════════╩══╩═
-                               0  1
+            ┌───┐┌─┐                           ░ ┌─┐   
+       q_0: ┤ H ├┤M├───────────────────────────░─┤M├───
+            └───┘└╥┘  ┌──────  ┌───┐ ───────┐  ░ └╥┘┌─┐
+       q_1: ──────╫───┤ If-0  ─┤ X ├  End-0 ├──░──╫─┤M├
+                  ║   └──╥───  └───┘ ───────┘  ░  ║ └╥┘
+                  ║ ┌────╨────┐                   ║  ║ 
+       c: 1/══════╩═╡ c_0=0x1 ╞═══════════════════╬══╬═
+                  0 └─────────┘                   ║  ║ 
+    meas: 2/══════════════════════════════════════╩══╩═
+                                                  0  1 
 
 
-The first measurement operation stores its result in the 1-bit classical register ``c``. If the
+The first measurement operation stores its result in the classical register ``c``. If the
 result is 1, the ``X`` gate will be applied. If it is zero, an identity gate of corresponding
 duration is applied instead.
 
@@ -319,9 +315,7 @@ between the '00 0' and '11 1' bins of the histogram (even though the state itsel
 
 .. note::
 
-   Because the gates can only take feedback from one classical bit you must place the measurement result
-   in a 1-bit classical register, ``c`` in the above example.
-
+   ``if_test`` blocks cannot be nested.
 
 Resetting qubits
 ~~~~~~~~~~~~~~~~
@@ -454,7 +448,7 @@ Starting from the :ref:`GHZ circuit <GHZ_circuit>` we created above:
     from qiskit.compiler import transpile
     from iqm.qiskit_iqm import IQMProvider
 
-    resonator_backend = IQMProvider("https://cocos.resonance.meetiqm.com/deneb").get_backend()
+    resonator_backend = IQMProvider("https://resonance.meetiqm.com", quantum_computer="sirius").get_backend()
     transpiled_circuit = transpile(circuit, resonator_backend)
 
     print(transpiled_circuit.draw(output='text', idle_wires=False))
@@ -706,17 +700,16 @@ a copy of the IQMFakeBackend instance with an updated error profile:
 Running a quantum circuit on a facade backend
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Circuits can be executed against a *mock environment*: an IQM server that has no real quantum computer hardware.
+Circuits can be executed against a *mock environment*: an IQM Server that has no real quantum computer hardware.
 Results from such executions are just random bits. This may be useful when developing and testing software integrations.
 
 .. note::
 
    IQM Resonance typically provides a mock environment for each real quantum computer it has.
-   For example, the URL
-   https://cocos.resonance.meetiqm.com/garnet refers to a real quantum computer named Garnet,
-   whereas https://cocos.resonance.meetiqm.com/garnet:mock refers to the corresponding mock environment.
+   For example, the name ``"garnet"`` refers to a real quantum computer named Garnet, whereas
+   ``"garnet:mock"`` refers to the corresponding mock environment.
 
-   On-premises users should ask their admin whether a mock environment is available, and which IQM server
+   On-premises users should ask their admin whether a mock environment is available, and which IQM Server
    URL to use.
 
 Qiskit on IQM contains :class:`.IQMFacadeBackend`, which allows to combine a mock remote execution with a local
@@ -734,7 +727,7 @@ static quantum architecture (i.e. names of qubits, their connectivity, and the n
 
 .. important::
 
-   When using a facade backend, the IQM server URL of :class:`IQMProvider` should always point to a mock environment
+   When using a facade backend, the IQM Server URL of :class:`IQMProvider` should always point to a mock environment
    rather than a real quantum computer, as the execution results from the server will be discarded and replaced by
    a locally simulated result generated by Qiskit Aer. If you use a real quantum computer with a facade backend,
    you will just waste your credits and/or computation time.
@@ -750,8 +743,9 @@ static quantum architecture (i.e. names of qubits, their connectivity, and the n
     circuit.cx(0, 1)
     circuit.measure_all()
 
-    iqm_server_url = "https://cocos.resonance.meetiqm.com/garnet:mock"  # Replace this with the correct mock env URL
-    provider = IQMProvider(iqm_server_url)
+    iqm_server_url = "https://resonance.meetiqm.com"
+    quantum_computer = "garnet:mock"  # Replace this with the correct mock env name
+    provider = IQMProvider(iqm_server_url, quantum_computer=quantum_computer)
     backend = provider.get_backend('facade_garnet')
     transpiled_circuit = transpile(circuit, backend=backend)
     job = backend.run(transpiled_circuit, shots=1000)
@@ -760,7 +754,7 @@ static quantum architecture (i.e. names of qubits, their connectivity, and the n
 .. note::
 
    When a classical register is added to the circuit, Qiskit fills it with classical bits of value 0 by default. If the
-   register is not used later, and the circuit is submitted to the IQM server, the results will not contain those
-   0-filled bits. To make sure the facade backend returns results in the same format as a real IQM server,
+   register is not used later, and the circuit is submitted to the IQM Server, the results will not contain those
+   0-filled bits. To make sure the facade backend returns results in the same format as a real IQM Server,
    :meth:`.IQMFacadeBackend.run` checks for the presence of unused classical registers, and fails with an error if there
    are any.