New Crowdin translations by GitHub Action (#593)
Co-authored-by: Crowdin Bot <support+bot@crowdin.com>
This commit is contained in:
github-actions[bot]
GitHub
parent
e6c7f8416d
commit
2a720097af
|
|
@ -86,9 +86,9 @@ Once you know which primitive you want to use, choose the primitive implementati
|
|||
- For running on quantum hardware choose from these options:
|
||||
|
||||
- Access services with native primitive implementations, such as the IBM Qiskit Runtime service by using [`qiskit_ibm_runtime.Sampler`](../qiskit-ibm-runtime/qiskit_ibm_runtime.Sampler) and [`qiskit_ibm_runtime.Estimator`.](../qiskit-ibm-runtime/qiskit_ibm_runtime.Estimator)
|
||||
- Wrap any backend with Backend primitives ([`qiskit.primitives.BackendSampler`](../qiskit/qiskit.primitives.BackendSampler) and [`qiskit.primitives.BackendEstimator`](../qiskit/qiskit.primitives.BackendEstimator)). These wrappers implement a primitive interface on top of a backend that only supports `backend.run()`.
|
||||
- Wrap any system with `Backend` primitives ([`qiskit.primitives.BackendSampler`](../qiskit/qiskit.primitives.BackendSampler) and [`qiskit.primitives.BackendEstimator`](../qiskit/qiskit.primitives.BackendEstimator)). These wrappers implement a primitive interface on top of a backend that only supports `backend.run()`.
|
||||
|
||||
For detailed information and examples, particularly on the use of the Backend primitives, refer to
|
||||
For detailed information and examples, particularly on the use of the `Backend` primitives, refer to
|
||||
the [QuantumInstance migration guide](./qiskit-quantum-instance).
|
||||
|
||||
This guide describes these common configurations for algorithms that determine which primitive import to use:
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ the [`qiskit.opflow`](../qiskit/0.44/opflow) module to the [`qiskit.primitives`]
|
|||
<Admonition type="note">
|
||||
Most references to the [`qiskit.primitives.Sampler`](../qiskit/qiskit.primitives.Sampler) or [`qiskit.primitives.Estimator`](../qiskit/qiskit.primitives.Estimator) in this guide
|
||||
can be replaced with instances of any primitive implementation. For example Aer primitives ([`qiskit_aer.primitives.Sampler`](https://qiskit.org/ecosystem/aer/stubs/qiskit_aer.primitives.Sampler.html)/[`qiskit_aer.primitives.Estimator`](https://qiskit.org/ecosystem/aer/stubs/qiskit_aer.primitives.Estimator.html)) or the IBM Qiskit Runtime primitives ([`qiskit_ibm_runtime.Sampler`](../qiskit-ibm-runtime/qiskit_ibm_runtime.Sampler)/[`qiskit_ibm_runtime.Estimator`](../qiskit-ibm-runtime/qiskit_ibm_runtime.Estimator)).
|
||||
Specific backends can be wrapped with ([`qiskit.primitives.BackendSampler`](../qiskit/qiskit.primitives.BackendSampler), [`qiskit.primitives.BackendEstimator`](../qiskit/qiskit.primitives.BackendEstimator)) to also present primitive-compatible interfaces.
|
||||
Specific systems can be wrapped with ([`qiskit.primitives.BackendSampler`](../qiskit/qiskit.primitives.BackendSampler), [`qiskit.primitives.BackendEstimator`](../qiskit/qiskit.primitives.BackendEstimator)) to also present primitive-compatible interfaces.
|
||||
|
||||
Certain classes, such as the
|
||||
[`qiskit.opflow.expectations.AerPauliExpectation`](../qiskit/0.44/qiskit.opflow.expectations.AerPauliExpectation), can only be replaced by a specific primitive instance
|
||||
|
|
@ -35,7 +35,7 @@ the [`qiskit.opflow`](../qiskit/0.44/opflow) module to the [`qiskit.primitives`]
|
|||
The [`qiskit.opflow`](../qiskit/0.44/opflow) module was originally introduced as a layer between circuits and algorithms, a series of building blocks
|
||||
for quantum algorithm research and development.
|
||||
|
||||
The release of the [`qiskit.primitives`](../qiskit/primitives) introduced a new paradigm for interacting with backends. Instead of
|
||||
The release of the [`qiskit.primitives`](../qiskit/primitives) introduced a new paradigm for interacting with systems. Instead of
|
||||
preparing a circuit to execute with a `backend.run()` type of method, algorithms can leverage the [`qiskit.primitives.Sampler`](../qiskit/qiskit.primitives.Sampler) and
|
||||
[`qiskit.primitives.Estimator`](../qiskit/qiskit.primitives.Estimator) primitives, send parametrized circuits and observables, and directly receive quasi-probability distributions or
|
||||
expectation values (respectively). This workflow simplifies the pre-processing and post-processing steps
|
||||
|
|
@ -591,7 +591,7 @@ See more examples in [Expectations](#expectations) and [Converters](#converters
|
|||
The role of the [`qiskit.opflow.converters`](../qiskit/0.44/qiskit.opflow.converters) submodule was to convert the operators into other opflow operator classes:
|
||||
([`qiskit.opflow.converters.TwoQubitReduction`](../qiskit/0.44/qiskit.opflow.converters.TwoQubitReduction), [`qiskit.opflow.converters.PauliBasisChange`](../qiskit/0.44/qiskit.opflow.converters.PauliBasisChange), and so on).
|
||||
The [`qiskit.opflow.converters.CircuitSampler`](../qiskit/0.44/qiskit.opflow.converters.CircuitSampler) traversed an operator and outputted
|
||||
approximations of its state functions using a quantum backend.
|
||||
approximations of its state functions using a quantum system.
|
||||
This functionality has been replaced by the [`qiskit.primitives`](../qiskit/primitives).
|
||||
|
||||
| Opflow | Alternative |
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ The remainder of this guide focused on the [`qiskit.utils.QuantumInstance.execut
|
|||
- _Reference primitives_ - [`qiskit.primitives.Sampler`](../qiskit/qiskit.primitives.Sampler) and [`qiskit.primitives.Estimator`](../qiskit/qiskit.primitives.Estimator) are reference implementations that come with Qiskit.
|
||||
- _Aer primitives_ - The [Aer](https://qiskit.org/ecosystem/aer) primitive implementations [`qiskit_aer.primitives.Sampler`](https://qiskit.org/ecosystem/aer/stubs/qiskit_aer.primitives.Sampler.html) and [`qiskit_aer.primitives.Estimator`](https://qiskit.org/ecosystem/aer/stubs/qiskit_aer.primitives.Estimator.html).
|
||||
- _Qiskit Runtime primitives_ - The IBM Qiskit Runtime primitive implementations [`qiskit_ibm_runtime.Sampler`](../qiskit-ibm-runtime/qiskit_ibm_runtime.Sampler) and [`qiskit_ibm_runtime.Estimator`](../qiskit-ibm-runtime/qiskit_ibm_runtime.Estimator).
|
||||
- _Backend primitives_ - Instances of [`qiskit.primitives.BackendSampler`](../qiskit/qiskit.primitives.BackendSampler) and [`qiskit.primitives.BackendEstimator`](../qiskit/qiskit.primitives.BackendEstimator). These allow any backend to implement primitive interfaces.
|
||||
- _`Backend` primitives_ - Instances of [`qiskit.primitives.BackendSampler`](../qiskit/qiskit.primitives.BackendSampler) and [`qiskit.primitives.BackendEstimator`](../qiskit/qiskit.primitives.BackendEstimator). These allow any system to implement primitive interfaces.
|
||||
|
||||
</Admonition>
|
||||
|
||||
|
|
@ -80,17 +80,17 @@ yourself two questions:
|
|||
2. How do you want to run your circuits?
|
||||
|
||||
This question is not new. In the legacy algorithm workflow, you would set up a
|
||||
[`qiskit.utils.QuantumInstance`](../qiskit/0.44/qiskit.utils.QuantumInstance) with either a real backend from a provider, or a simulator.
|
||||
For this migration, this "backend selection" process is translated to **where** do you import your primitives from:
|
||||
[`qiskit.utils.QuantumInstance`](../qiskit/0.44/qiskit.utils.QuantumInstance) with either a real system from a provider, or a simulator.
|
||||
For this migration, this "system selection" process is translated to **where** do you import your primitives from:
|
||||
|
||||
- Using **local** statevector simulators for quick prototyping: **Reference primitives**
|
||||
- Using **local** noisy simulations for finer algorithm tuning: **Aer primitives**
|
||||
- Accessing **runtime-enabled backends** (or cloud simulators): **Qiskit Runtime primitives**
|
||||
- Accessing **non runtime-enabled backends** : **Backend primitives**
|
||||
- Accessing **runtime-enabled systems** (or cloud simulators): **Qiskit Runtime primitives**
|
||||
- Accessing **non runtime-enabled systems** : **`Backend` primitives**
|
||||
|
||||
Arguably, the `Sampler` is the closest primitive to [`qiskit.utils.QuantumInstance`](../qiskit/0.44/qiskit.utils.QuantumInstance), as they
|
||||
both execute circuits and provide a result. However, with the [`qiskit.utils.QuantumInstance`](../qiskit/0.44/qiskit.utils.QuantumInstance),
|
||||
the result data was backend dependent (it could be a counts `dict`, a `numpy.array` for
|
||||
the result data was system-dependent (it could be a counts `dict`, a `numpy.array` for
|
||||
statevector simulations, and so on), while `Sampler` normalizes its `SamplerResult` to
|
||||
return a [`qiskit.result.QuasiDistribution`](../qiskit/qiskit.result.QuasiDistribution) object with the resulting quasi-probability distribution.
|
||||
|
||||
|
|
@ -111,7 +111,7 @@ primitives expose a similar setting through their interface:
|
|||
refer to the API reference or source code of the desired primitive implementation.
|
||||
</Admonition>
|
||||
|
||||
| QuantumInstance | Reference Primitives | Aer Primitives | Qiskit Runtime Primitives | Backend Primitives |
|
||||
| QuantumInstance | Reference Primitives | Aer Primitives | Qiskit Runtime Primitives | `Backend` Primitives |
|
||||
| ----------------------------------------------------------------------------------------------------- | -------------------- | -------------- | --------------------------------- | ------------------------------------- |
|
||||
| Select `backend` | No | No | Yes | Yes |
|
||||
| Set `shots` | Yes | Yes | Yes | Yes |
|
||||
|
|
@ -134,7 +134,7 @@ primitives expose a similar setting through their interface:
|
|||
|
||||
**QuantumInstance**
|
||||
|
||||
The only option for local simulations using the quantum instance was using an Aer simulator backend.
|
||||
The only option for local simulations using the quantum instance was using an Aer simulator.
|
||||
If no simulation method is specified, the Aer simulator defaults to an exact simulation
|
||||
(statevector/stabilizer), if shots are specified, it adds shot noise.
|
||||
Note that `QuantumInstance.execute()` returned the counts in hexadecimal format.
|
||||
|
|
@ -341,7 +341,7 @@ print(expectation_value)
|
|||
[-0.04101562]
|
||||
```
|
||||
|
||||
### Example 3: Circuit sampling on IBM backend with error mitigation
|
||||
### Example 3: Circuit sampling on IBM system with error mitigation
|
||||
|
||||
**QuantumInstance**
|
||||
|
||||
|
|
@ -429,7 +429,7 @@ QuantumInstance **did not** manage parameter bindings on parametrized quantum ci
|
|||
When using the primitives:
|
||||
|
||||
- You cannot explicitly access their transpilation routine.
|
||||
- The mechanism to apply custom transpilation passes to the Aer, Runtime, and Backend primitives is to pre-transpile
|
||||
- The mechanism to apply custom transpilation passes to the Aer, Runtime, and `Backend` primitives is to pre-transpile
|
||||
locally and set `skip_transpilation=True` in the corresponding primitive.
|
||||
- The only primitives that accept a custom **bound** transpiler pass manager are instances of [`qiskit.primitives.BackendSampler`](../qiskit/qiskit.primitives.BackendSampler) or [`qiskit.primitives.BackendEstimator`](../qiskit/qiskit.primitives.BackendEstimator).
|
||||
If a `bound_pass_manager` is defined, the `skip_transpilation=True` option does **not** skip this bound pass.
|
||||
|
|
@ -518,7 +518,7 @@ Quasi-dists: {'11': 0.443359375, '10': 0.21875, '01': 0.189453125, '00': 0.14843
|
|||
|
||||
**Primitives**
|
||||
|
||||
Let's see how the workflow changes with the Backend Sampler:
|
||||
Let's see how the workflow changes with the `Backend` Sampler:
|
||||
|
||||
```python
|
||||
from qiskit.circuit.library.standard_gates.equivalence_library import StandardEquivalenceLibrary as std_eqlib
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ This results in a considerable reduction of the code complexity and a
|
|||
more compact algorithm design.
|
||||
|
||||
<Admonition type="note">
|
||||
**Backend.run() model:** In this model, you accessed real backends and remote simulators using the `qiskit-ibmq-provider` module (now migrated to `qiskit-ibm-provider`). To run **local** simulations, you could import a specific backend from `qiskit-aer`. All of them followed the `backend.run()` interface.
|
||||
**Backend.run() model:** In this model, you accessed real systems and remote simulators using the `qiskit-ibmq-provider` module (now migrated to `qiskit-ibm-provider`). To run **local** simulations, you could import a specific simulator from `qiskit-aer`. All of them followed the `backend.run()` interface.
|
||||
|
||||
````
|
||||
<details>
|
||||
|
|
@ -57,7 +57,7 @@ result = backend.run(expectation_circuits)
|
|||
```
|
||||
</details>
|
||||
|
||||
**Primitives model:** Access real backends and remote simulators through the `qiskit-ibm-runtime` **primitives** (`Sampler` and `Estimator`). To run **local** simulations, you can import specific local primitives from `qiskit_aer.primitives` and `qiskit.primitives`. All of them follow the `BaseSampler` and `BaseEstimator` interfaces, but **only the Runtime primitives offer access to the Runtime service, sessions, and built-in error mitigation**.
|
||||
**Primitives model:** Access real systems and remote simulators through the `qiskit-ibm-runtime` **primitives** (`Sampler` and `Estimator`). To run **local** simulations, you can import specific local primitives from `qiskit_aer.primitives` and `qiskit.primitives`. All of them follow the `BaseSampler` and `BaseEstimator` interfaces, but **only the Runtime primitives offer access to the Runtime service, sessions, and built-in error mitigation**.
|
||||
|
||||
<details>
|
||||
<summary>Code example for Runtime Estimator</summary>
|
||||
|
|
@ -323,7 +323,7 @@ difference is the format of the output: `backend.run()` outputs
|
|||
**quasi-probability distribution** associated with them.
|
||||
|
||||
<Admonition type="note">
|
||||
**Backend.run() model:** In this model, you used the `qiskit-ibmq-provider` (now migrated to `qiskit-ibm-provider`) module to access real backends and remote simulators. To run **local** simulations, you could import a specific backend from `qiskit-aer`. All of them followed the `backend.run()` interface.
|
||||
**Backend.run() model:** In this model, you used the `qiskit-ibmq-provider` (now migrated to `qiskit-ibm-provider`) module to access real systems and remote simulators. To run **local** simulations, you could import a specific simulator from `qiskit-aer`. All of them followed the `backend.run()` interface.
|
||||
|
||||
````
|
||||
<details>
|
||||
|
|
@ -357,7 +357,7 @@ result = backend.run(circuits)
|
|||
```
|
||||
</details>
|
||||
|
||||
**Primitives model:** Access real backends and remote simulators through the `qiskit-ibm-runtime` Sampler and Estimator *primitives*. To run **local** simulations, import specific local primitives from `qiskit_aer.primitives` and `qiskit.primitives`. All of them follow the `BaseSampler` and `BaseEstimator` interfaces, but **only the Runtime primitives offer access to the Runtime service, sessions, and built-in error mitigation**.
|
||||
**Primitives model:** Access real systems and remote simulators through the `qiskit-ibm-runtime` Sampler and Estimator *primitives*. To run **local** simulations, import specific local primitives from `qiskit_aer.primitives` and `qiskit.primitives`. All of them follow the `BaseSampler` and `BaseEstimator` interfaces, but **only the Runtime primitives offer access to the Runtime service, sessions, and built-in error mitigation**.
|
||||
|
||||
<details>
|
||||
<summary><a>Code example for Runtime Sampler</a></summary>
|
||||
|
|
|
|||
|
|
@ -86,7 +86,7 @@ with Session(backend=backend) as session:
|
|||
print(job2.session_id) # is None
|
||||
```
|
||||
|
||||
**Example 4: Backend session containing Sampler:**
|
||||
**Example 4: `Backend` session containing Sampler:**
|
||||
|
||||
In this example, `backend` is run within a session, but `sampler` is run independently
|
||||
of the session.
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ your algorithm is based on:
|
|||
- If it uses a **probability distribution** (from sampling the device), you will need a `Sampler`.
|
||||
|
||||
After determining which primitive to use, identify where the algorithm
|
||||
accesses the backend. Look for the call to `backend.run()`. Next, you
|
||||
accesses the system. Look for the call to `backend.run()`. Next, you
|
||||
will replace this call with the respective primitive call, as shown in
|
||||
the following examples.
|
||||
|
||||
|
|
@ -272,9 +272,9 @@ the `hub`, `group`, and `project` are specified through the new
|
|||
service = QiskitRuntimeService(channel="ibm_quantum", instance="my_hub/my_group/my_project")
|
||||
```
|
||||
|
||||
### Get the backend
|
||||
### Get the system or simulator
|
||||
|
||||
Use the updated code to view backends.
|
||||
Use the updated code to view systems and simulators.
|
||||
|
||||
**Legacy**
|
||||
|
||||
|
|
|
|||
|
|
@ -61,7 +61,7 @@ Key:
|
|||
| `continue` | ❌ | |
|
||||
| `break` | ❌ | |
|
||||
| `return` | ❌ | |
|
||||
| `extern` | 🟡 | Only for certain extern subroutines exposed by backend devices. It is currently not possible for clients to submit these. |
|
||||
| `extern` | 🟡 | Only for certain extern subroutines exposed by systems. It is currently not possible for clients to submit these. |
|
||||
| `def` subroutines (classical) | ❌ | |
|
||||
| `def` subroutines (quantum) | ❌ | |
|
||||
| `input` | ❌ | |
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ qc.cx(0, 1)
|
|||
qc.measure(0, 0)
|
||||
qc.measure(1, 1)
|
||||
|
||||
# Run on the least-busy backend you have access to
|
||||
# Run on the least-busy system you have access to
|
||||
backend = service.least_busy(simulator=False,operational=True)
|
||||
|
||||
# Create a Sampler object
|
||||
|
|
|
|||
|
|
@ -14,8 +14,8 @@ In the run phase, you send your quantum program to be executed on a quantum syst
|
|||
The steps during the run phase are:
|
||||
|
||||
1. Using your account credentials, authenticate to the channel of your choice ([IBM Quantum Platform](../start/setup-channel#ibm-quantum-platform) or [IBM Cloud](../start/setup-channel#ibm-cloud)).
|
||||
2. Choose a backend.
|
||||
3. Send a job to a quantum system.
|
||||
2. Choose a system or simulator.
|
||||
3. Send a job to a system or simulator.
|
||||
4. View job results.
|
||||
|
||||
[^1]: Median 2Q gate errors measured over all accessible Eagle processors from July 20 to September 20, 2023.
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ Those using the Open plan instance have up to 10 minutes total of system executi
|
|||
<span id="connect-instance"></span>
|
||||
## Connect to an instance
|
||||
|
||||
You can specify an instance when initializing the service or provider, or when choosing a backend. You can copy the service-level code by clicking the three dots by the instance name on the Instances section of the [Account overview page](https://quantum.ibm.com/account).
|
||||
You can specify an instance when initializing the service or provider, or when choosing a system. You can copy the service-level code by clicking the three dots by the instance name on the Instances section of the [Account overview page](https://quantum.ibm.com/account).
|
||||
|
||||
### qiskit-ibm-runtime
|
||||
|
||||
|
|
@ -90,8 +90,8 @@ job2 = backend2.run(...) # this will use hub2/group2/project2
|
|||
If you do not specify an instance, the code will select one in the following order:
|
||||
|
||||
1. If your account only has access to one instance, it is selected by default.
|
||||
2. If your account has access to multiple instances but only one can access the requested backend, the instance with access is selected.
|
||||
3. In all other cases, the code selects the first instance other than `ibm-q/open/main` that has access to the backend.
|
||||
2. If your account has access to multiple instances but only one can access the requested system, the instance with access is selected.
|
||||
3. In all other cases, the code selects the first instance other than `ibm-q/open/main` that has access to the system.
|
||||
</Admonition>
|
||||
|
||||
## Leaving an instance
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: Maximum execution time for a Qiskit Runtime job or session
|
|||
description: Describes how long a Qiskit Runtime job or session can run.
|
||||
---
|
||||
|
||||
# Maximum execution time
|
||||
# Maximum execution time for a Qiskit Runtime job or session
|
||||
|
||||
To ensure fairness and help control costs, there is a maximum amount of time each Qiskit Runtime job and session can run. If a job exceeds this time limit, it is forcibly canceled and a `RuntimeJobMaxTimeoutError` exception is raised. If a session exceeds its limits, any queued jobs are canceled but any jobs that are already running are not.
|
||||
|
||||
|
|
@ -16,7 +16,7 @@ The maximum execution time for a job is the smaller of these values:
|
|||
- The system-determined job timeout value
|
||||
|
||||
<Admonition type="note">
|
||||
As of August 7, 2023, the `max_execution_time` value is based on _quantum time_ instead of wall clock time. Quantum time is the duration a quantum system is committed to fulfilling a user request..
|
||||
As of August 7, 2023, the `max_execution_time` value is based on _quantum time_ instead of wall clock time. Quantum time is the duration a quantum system is committed to fulfilling a user request.
|
||||
|
||||
Simulator jobs continue to use wall clock time because they do not have quantum time.
|
||||
</Admonition>
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ The steps in this topic describes how to set up primitives, explore the options
|
|||
|
||||
### 1. Initialize the account
|
||||
|
||||
Since Qiskit Runtime `Estimator` is a managed service, you will first need to initialize your account. You can then select the simulator or real backend you want to use to calculate the expectation value.
|
||||
Since Qiskit Runtime `Estimator` is a managed service, you will first need to initialize your account. You can then select the simulator or real system you want to use to calculate the expectation value.
|
||||
|
||||
Follow the steps in the [Install and set up topic](../start/install) if you don't already have an account.
|
||||
|
||||
|
|
@ -48,7 +48,7 @@ print(f">>> Observable: {observable.paulis}")
|
|||
|
||||
Here we are initializing an instance of `qiskit_ibm_runtime.Estimator` instead of `qiskit.primitives.Estimator` to use Qiskit Runtime's implementation of the `Estimator`.
|
||||
|
||||
When you initialize the `Estimator`, you'll need to pass in the backend you previously selected as the target device (or simulator). You could also do this within the `session` parameter.
|
||||
When you initialize the `Estimator`, you'll need to pass in the system or simulator you previously selected as the target device (or simulator). You could also do this within the `session` parameter.
|
||||
|
||||
```python
|
||||
from qiskit_ibm_runtime import Estimator
|
||||
|
|
@ -78,7 +78,7 @@ print(f" > Metadata: {result.metadata[0]}")
|
|||
|
||||
### 1. Initialize the account
|
||||
|
||||
Since Qiskit Runtime `Sampler` is a managed service, you will first need to initialize your account. You can then select the simulator or real backend you want to use to calculate the expectation value.
|
||||
Since Qiskit Runtime `Sampler` is a managed service, you will first need to initialize your account. You can then select the simulator or real system you want to use to calculate the expectation value.
|
||||
|
||||
Follow the steps in the [Install and set up topic](../start/install) if you don't already have an account set up.
|
||||
|
||||
|
|
@ -109,7 +109,7 @@ circuit.measure_all()
|
|||
|
||||
Here we are initializing an instance of `qiskit_ibm_runtime.Sampler` instead of `qiskit.primitives.Sampler` to use Qiskit Runtime's implementation of the `Sampler`.
|
||||
|
||||
When you initialize the `Sampler`, you'll need to pass in the backend you previously selected as the target device (or simulator). You could also do this within the `session` parameter.
|
||||
When you initialize the `Sampler`, you'll need to pass in the simulator or system you previously selected as the target device (or simulator). You could also do this within the `session` parameter.
|
||||
|
||||
```python
|
||||
from qiskit_ibm_runtime import Sampler
|
||||
|
|
|
|||
|
|
@ -31,12 +31,12 @@ you are trying to achieve.
|
|||
The Qiskit primitives are defined by open-source primitive base-classes, from
|
||||
which different providers can derive their own Sampler and Estimator implementations. Among the implementations
|
||||
using Qiskit, you can find reference primitive implementations for local simulation in the `qiskit.primitives` module.
|
||||
Providers like IBM’s Qiskit Runtime enable access to appropriate backends through native implementations of
|
||||
Providers like IBM’s Qiskit Runtime enable access to appropriate systems through native implementations of
|
||||
their own primitives.
|
||||
|
||||
## Benefits of Qiskit primitives
|
||||
|
||||
For Qiskit users, primitives allow you to write quantum code for a specific backend without having to explicitly
|
||||
For Qiskit users, primitives allow you to write quantum code for a specific system without having to explicitly
|
||||
manage every detail. In addition, because of the additional layer of abstraction, you may be able to more easily
|
||||
access advanced hardware capabilities of a given provider. For example, with Qiskit Runtime primitives,
|
||||
you can leverage the latest advancements in error mitigation and suppression by toggling options such as
|
||||
|
|
@ -64,7 +64,7 @@ probabilities, except they may include negative values, which can occur when usi
|
|||
## How to use Qiskit primitives
|
||||
|
||||
The `qiskit.primitives` module enables the development of primitive-style quantum programs and was specifically
|
||||
designed to simplify switching between different types of backends. The module provides three separate classes
|
||||
designed to simplify switching between different types of systems. The module provides three separate classes
|
||||
for each primitive type:
|
||||
|
||||
1. `Sampler` and `Estimator`
|
||||
|
|
@ -73,11 +73,11 @@ These classes are reference implementations of both primitives and use Qiskit’
|
|||
|
||||
2. `BaseSampler` and `BaseEstimator`
|
||||
|
||||
These are abstract base classes that define a common interface for implementing primitives. All other classes in the `qiskit.primitives` module inherit from these base classes, and developers should use these if they are interested in developing their own primitives-based execution model for a specific backend provider. These classes may also be useful for those who want to do highly customized processing and find the existing primitives implementations too simple for their needs.
|
||||
These are abstract base classes that define a common interface for implementing primitives. All other classes in the `qiskit.primitives` module inherit from these base classes, and developers should use these if they are interested in developing their own primitives-based execution model for a specific system provider. These classes may also be useful for those who want to do highly customized processing and find the existing primitives implementations too simple for their needs.
|
||||
|
||||
3. `BackendSampler` and `BackendEstimator`
|
||||
|
||||
If a provider does not support primitives natively, you can use these classes to “wrap” any backend into a primitive. Users can write primitive-style code for providers that don’t yet have a primitives-based interface. These classes can be used just like the regular Sampler and Estimator, except they should be initialized with an additional backend argument for selecting which backend to run on.
|
||||
If a provider does not support primitives natively, you can use these classes to “wrap” any system into a primitive. Users can write primitive-style code for providers that don’t yet have a primitives-based interface. These classes can be used just like the regular Sampler and Estimator, except they should be initialized with an additional `backend` argument for selecting which system to run on.
|
||||
|
||||
The Qiskit Runtime primitives provide a more sophisticated implementation (such as with error mitigation) as a cloud-based service.
|
||||
|
||||
|
|
|
|||
|
|
@ -110,13 +110,13 @@ Qiskit Runtime custom programs can be easily migrated to Quantum Serverless via
|
|||
|
||||
Premium Plan users have access to an alpha release of resource management functionality through Quantum Serverless. This enables automatic selection of quantum hardware for your workloads.
|
||||
|
||||
The example below demonstrates how to use `IBMQPUSelector` to automate the process of selecting which qubits will be used from a set of available backends. This illustrates how the selectors can be used within a four-step Qiskit Pattern.
|
||||
The example below demonstrates how to use `IBMQPUSelector` to automate the process of selecting which qubits will be used from a set of available systems. This illustrates how the selectors can be used within a four-step Qiskit Pattern.
|
||||
|
||||
Instead of manually selecting a backend, step 2 of the Qiskit Pattern optimizes the circuits for execution by using the QPU selectors from Quantum Serverless to automatically allocate a backend according to desired criteria. Here, `IBMLeastNoisyQPUSelector` finds the backend, among the ones available to you through your IBM Quantum account, that yields the least-noisy qubit subgraph for the input circuit. You can also use the `IBMLeastBusyQPUSelector` to find a backend that can support the circuit width but with the shortest queue.
|
||||
Instead of manually selecting a system, step 2 of the Qiskit Pattern optimizes the circuits for execution by using the QPU selectors from Quantum Serverless to automatically allocate a system according to desired criteria. Here, `IBMLeastNoisyQPUSelector` finds the system, among the ones available to you through your IBM Quantum account, that yields the least-noisy qubit subgraph for the input circuit. You can also use the `IBMLeastBusyQPUSelector` to find a system that can support the circuit width but with the shortest queue.
|
||||
|
||||
For each `IBMQPUSelector`, the context is set in the constructor. All `IBMQPUSelectors` require Qiskit Runtime credentials. The `IBMLeastNoisyQPUSelector` requires a circuit and transpile options specifying how the circuit should be optimized for each backend when determining the most optimal QPU and qubit layout. All `IBMQPUSelector`s implement a `get_backend` method, which retrieves the optimal backend with respect to the given context. The `get_backend` method also allows for additional filtering of the backends. It is implemented using the same interface as the [QiskitRuntimeService.backends method](/api/qiskit-ibm-runtime/qiskit_ibm_runtime.QiskitRuntimeService#backends).
|
||||
For each `IBMQPUSelector`, the context is set in the constructor. All `IBMQPUSelectors` require Qiskit Runtime credentials. The `IBMLeastNoisyQPUSelector` requires a circuit and transpile options specifying how the circuit should be optimized for each system when determining the most optimal QPU and qubit layout. All `IBMQPUSelector`s implement a `get_backend` method, which retrieves the optimal system with respect to the given context. The `get_backend` method also allows for additional filtering of the systems. It is implemented using the same interface as the [QiskitRuntimeService.backends method](/api/qiskit-ibm-runtime/qiskit_ibm_runtime.QiskitRuntimeService#backends).
|
||||
|
||||
Then, in step 3 of the pattern, you execute the target circuit on the backend chosen by the selector. Since you optimized your circuit for the backend in step 2, you can skip transpilation in the primitives by setting `skip_transpilation=True`.
|
||||
Then, in step 3 of the pattern, you execute the target circuit on the system chosen by the selector. Since you optimized your circuit for the system in step 2, you can skip transpilation in the primitives by setting `skip_transpilation=True`.
|
||||
|
||||
```python
|
||||
# source_files/my_qiskit_pattern_resource_management.py
|
||||
|
|
@ -132,14 +132,14 @@ abstract_circuit = random_circuit(
|
|||
num_qubits=5, depth=4, measure=True, seed=1234
|
||||
)
|
||||
|
||||
# Step 2: Optimize the circuit for quantum execution with automatically selected backend
|
||||
# Step 2: Optimize the circuit for quantum execution with automatically selected system
|
||||
selector = IBMLeastNoisyQPUSelector(
|
||||
service, circuit=abstract_circuit, transpile_options={"optimization_level": 3}
|
||||
)
|
||||
backend = selector.get_backend(min_num_qubits=127)
|
||||
target_circuit = selector.optimized_circuit
|
||||
|
||||
## Alternatively, one can automatically select a backend according to most available:
|
||||
## Alternatively, one can automatically select a system according to most available:
|
||||
# from qiskit.transpiler.preset_passmanagers import generate_preset_pass_manager
|
||||
# from quantum_serverless_tools.selectors import IBMLeastBusyQPUSelector
|
||||
#
|
||||
|
|
|
|||
|
|
@ -46,9 +46,9 @@ with Session(service=service, backend="ibmq_qasm_simulator"):
|
|||
sampler = Sampler()
|
||||
```
|
||||
|
||||
When you start a session, you must specify a backend. This can be done by specifying its name or by passing a backend object.
|
||||
When you start a session, you must specify a system or simulator. This can be done by specifying its name or by passing a `backend` object.
|
||||
|
||||
**Specify a backend by name**
|
||||
**Specify a system or simulator by name**
|
||||
|
||||
```python
|
||||
service = QiskitRuntimeService()
|
||||
|
|
@ -56,7 +56,7 @@ with Session(service=service, backend="ibmq_qasm_simulator"):
|
|||
...
|
||||
```
|
||||
|
||||
**Pass a backend object**
|
||||
**Pass a `backend` object**
|
||||
|
||||
```python
|
||||
backend = service.get_backend("ibmq_qasm_simulator")
|
||||
|
|
|
|||
|
|
@ -38,13 +38,13 @@ The revision version number will increment for fixes that do not break the exist
|
|||
- Small electronics changes that don’t affect operation.
|
||||
- System software updates.
|
||||
|
||||
## Backend configuration values
|
||||
## System configuration values
|
||||
|
||||
The following is a subset of backend configuration values available in IBM Quantum and from [Qiskit](/api/qiskit/qiskit.providers.models.BackendConfiguration).
|
||||
The following is a subset of system configuration values available in IBM Quantum and from [Qiskit](/api/qiskit/qiskit.providers.models.BackendConfiguration).
|
||||
|
||||
These values are shown on both the Systems and Simulators tabs of the [Compute resources page](https://quantum.ibm.com/services/resources?services=systems) and the details page for each system.
|
||||
|
||||
- **Name** - The unique name assigned to a specific quantum system or simulator. Backends hosted on IBM Cloud® have names that begin with `ibmq_*` (older systems) or `ibm_*` (newer systems). All quantum systems are given a city name, e.g., `ibmq_johannesburg`. This name does not indicate where the actual quantum system is hosted. They are named after IBM locations around the world.
|
||||
- **Name** - The unique name assigned to a specific quantum system or simulator. Systems hosted on IBM Cloud® have names that begin with `ibmq_*` (older systems) or `ibm_*` (newer systems). All quantum systems are given a city name, e.g., `ibmq_johannesburg`. This name does not indicate where the actual quantum system is hosted. They are named after IBM locations around the world.
|
||||
- **Qubits** - The number of qubits in a system. For physical quantum systems, this is the number of physical qubits in the device. For simulators, this number need not be uniquely defined, and instead can depend on the simulation method and/or the amount of memory available.
|
||||
- **EPLG** - Error per layered gate in a chain of 100 qubits. Error per layered gate measures the average gate process error in a layered chain of $N$ qubits ($N$=100 here). It is derived from a similar quantity known as the layer fidelity (LF) where EPLG$\_{100}$ = 1-LF$^{\\frac{1}{99}}$ and layer fidelity is the process fidelity of the layered chain of $N$ qubits. For details, see the paper [Benchmarking quantum processor performance at scale](https://arxiv.org/abs/2311.05933).
|
||||
- **CLOPS** - Circuit layer operations per second, and also known as CLOPS_v, is a measure of how many layers of a Quantum volume circuit (virtual circuit) a QPU (quantum processing unit) can execute per unit of time. Find more information about this metric in the paper [Quality, Speed, and Scale: three key attributes to measure the performance of near-term quantum computers](https://arxiv.org/abs/2110.14108).
|
||||
|
|
@ -92,8 +92,8 @@ The Graph view tab.
|
|||
|
||||
The Table view tab.
|
||||
|
||||
## Find backend information from other channels
|
||||
## Find system information from other channels
|
||||
|
||||
To find your available systems and simulators on **IBM Cloud**, view the [IBM Cloud Compute resources page.](https://cloud.ibm.com/quantum/resources/your-resources) You must be logged in to see your available compute resources. You are shown a snapshot of each backend. To see full details, click the backend name. You can also search for backends from this page.
|
||||
To find your available systems and simulators on **IBM Cloud**, view the [IBM Cloud Compute resources page.](https://cloud.ibm.com/quantum/resources/your-resources) You must be logged in to see your available compute resources. You are shown a snapshot of each system. To see full details, click the system name. You can also search for systems from this page.
|
||||
|
||||
To find your available systems and simulators on **IBM Quantum Platform**, view the [Platform Compute resources page.](https://quantum.ibm.com/services/resources) You are shown a snapshot of each backend. To see full details, click the backend name. You can also sort, filter, and search from this page.
|
||||
To find your available systems and simulators on **IBM Quantum Platform**, view the [Platform Compute resources page.](https://quantum.ibm.com/services/resources) You are shown a snapshot of each system. To see full details, click the system name. You can also sort, filter, and search from this page.
|
||||
|
|
|
|||
|
|
@ -28,10 +28,10 @@ By default, this file is in `~/.qiskit/settings.conf` but the path can be overri
|
|||
|
||||
## Available options
|
||||
|
||||
- `circuit_drawer`: Changes the default backend for the circuit drawer. It can be set to `latex`, `mpl`, `text`, or `latex_source`. When the output kwarg is not explicitly set, this drawer backend is used.
|
||||
- `circuit_mpl_style`: The default style sheet used for the mpl output backend for the circuit drawer. Valid values are `default` or `bw`.
|
||||
- `circuit_drawer`: Changes the default system for the circuit drawer. It can be set to `latex`, `mpl`, `text`, or `latex_source`. When the output kwarg is not explicitly set, this drawer system is used.
|
||||
- `circuit_mpl_style`: The default style sheet used for the mpl output system for the circuit drawer. Valid values are `default` or `bw`.
|
||||
- `circuit_mpl_style_path`: The paths to have the circuit drawer use to look for JSON style sheets when using the mpl output mode.
|
||||
- `state_drawer`: This is used to change the default backend for the state visualization draw methods. Valid values are `repr`, `text`, `latex`, `latex_source`, `qsphere`, `hinton`, or `bloch`. When the output kwarg is not explicitly set on the [qiskit.quantum_info.DensityMatrix.draw](../api/qiskit/qiskit.quantum_info.DensityMatrix#densitymatrix) method, the specified output method is used.
|
||||
- `state_drawer`: This is used to change the default system for the state visualization draw methods. Valid values are `repr`, `text`, `latex`, `latex_source`, `qsphere`, `hinton`, or `bloch`. When the output kwarg is not explicitly set on the [qiskit.quantum_info.DensityMatrix.draw](../api/qiskit/qiskit.quantum_info.DensityMatrix#densitymatrix) method, the specified output method is used.
|
||||
- \`transpile_optimization_level: Change the default optimization level for [qiskit.compiler.transpile](../api/qiskit/compiler#circuit-and-pulse-compilation-functions) and [qiskit.execute.execute](../api/qiskit/execute#executing-experiments). Specify an integer 0-3.
|
||||
- `parallel`: Whether Python multiprocessing is enabled for operations that support running in parallel. For example, transpilation of multiple [qiskit.circuit.QuantumCircuit](../api/qiskit/qiskit.circuit.QuantumCircuit#quantumcircuit) objects. This setting can be overridden by the QISKIT_PARALLEL environment variable. Specify a boolean value.
|
||||
- `num_processes`: The maximum number of parallel processes to launch for parallel operations if parallel execution is enabled. This setting can be overridden by the QISKIT_NUM_PROCS environment variable. Specify an integer greater than 0.
|
||||
|
|
|
|||
|
|
@ -3,18 +3,59 @@ title: Install Qiskit from source
|
|||
description: Learn how to install the development version of Qiskit.
|
||||
---
|
||||
|
||||
# Install Qiskit from source
|
||||
# Install Qiskit and Qiskit Runtime from source
|
||||
|
||||
Installing Qiskit from source allows you to access the current development version, instead of using the version in the Python Package Index (PyPI) repository. This lets you inspect and extend the latest version of the Qiskit code more efficiently.
|
||||
|
||||
## Create and activate a new virtual environment
|
||||
|
||||
First, create a new virtual environment for Qiskit.
|
||||
1. Create a minimal environment with only Python installed in it.
|
||||
|
||||
```python
|
||||
python3 -m venv QiskitDevenv
|
||||
source QiskitDevenv/bin/activate
|
||||
```
|
||||
````
|
||||
<OperatingSystemTabs>
|
||||
<TabItem value="mac" label="macOS">
|
||||
```shell
|
||||
python3 -m venv /path/to/virtual/environment
|
||||
```
|
||||
</TabItem>
|
||||
|
||||
<TabItem value="linux" label="Linux">
|
||||
```shell
|
||||
python3 -m venv /path/to/virtual/environment
|
||||
```
|
||||
</TabItem>
|
||||
|
||||
<TabItem value="win" label="Windows">
|
||||
```text
|
||||
python3 -m venv c:\path\to\virtual\environment
|
||||
```
|
||||
</TabItem>
|
||||
</OperatingSystemTabs>
|
||||
````
|
||||
|
||||
2. Activate your new environment.
|
||||
|
||||
````
|
||||
<OperatingSystemTabs>
|
||||
<TabItem value="mac" label="macOS">
|
||||
```shell
|
||||
source /path/to/virtual/environment/bin/activate
|
||||
```
|
||||
</TabItem>
|
||||
|
||||
<TabItem value="linux" label="Linux">
|
||||
```shell
|
||||
source /path/to/virtual/environment/bin/activate
|
||||
```
|
||||
</TabItem>
|
||||
|
||||
<TabItem value="win" label="Windows">
|
||||
```text
|
||||
c:\path\to\virtual\environment\Scripts\Activate.ps1
|
||||
```
|
||||
</TabItem>
|
||||
</OperatingSystemTabs>
|
||||
````
|
||||
|
||||
## Install the Rust compiler
|
||||
|
||||
|
|
@ -26,39 +67,39 @@ Follow these steps to install Qiskit:
|
|||
|
||||
1. Clone the Qiskit repository.
|
||||
|
||||
```python
|
||||
git clone https://github.com/Qiskit/qiskit.git
|
||||
```bash
|
||||
git clone https://github.com/Qiskit/qiskit.git
|
||||
```
|
||||
|
||||
2. Change to the `qiskit` directory.
|
||||
|
||||
```python
|
||||
cd qiskit
|
||||
```bash
|
||||
cd qiskit
|
||||
```
|
||||
|
||||
3. (Optional) If you want to run tests or linting checks, install the developer requirements.
|
||||
|
||||
```python
|
||||
pip install -r requirements-dev.txt
|
||||
```bash
|
||||
pip install -r requirements-dev.txt
|
||||
```
|
||||
|
||||
4. Install `qiskit`.
|
||||
|
||||
- **Standard install**:
|
||||
|
||||
```python
|
||||
```bash
|
||||
pip install .
|
||||
```
|
||||
|
||||
- **Editable mode**: In this mode, you don't need to reinstall Qiskit when there are code changes to the project.
|
||||
|
||||
```python
|
||||
```bash
|
||||
pip install -e .
|
||||
```
|
||||
|
||||
In editable mode, the compiled extensions are built in _debug mode_ without optimizations. This affects the runtime performance of the compiled code. To build the compiled extensions with optimizations enabled, run the following command to rebuild the binary in _release mode_:
|
||||
|
||||
```python
|
||||
```bash
|
||||
python setup.py build_rust --release --inplace
|
||||
```
|
||||
|
||||
|
|
@ -66,6 +107,44 @@ Follow these steps to install Qiskit:
|
|||
If you are working on Rust code in Qiskit, you need to rebuild the extension code every time you make a local change. In editable mode, the Rust extension is only built when the install command is run, so local changes you make to the Rust code are not reflected in the installed package unless you rebuild the extension by rerunning `build_rust` (with or without `--release`, depending on whether you want to build in release or debug mode).
|
||||
</Admonition>
|
||||
|
||||
## Install Qiskit Runtime
|
||||
|
||||
Follow these steps if you want to install Qiskit Runtime:
|
||||
|
||||
1. Clone the Qiskit Runtime repository.
|
||||
|
||||
```bash
|
||||
git clone https://github.com/Qiskit/qiskit-ibm-runtime.git
|
||||
```
|
||||
|
||||
2. Change to the `qiskit_ibm_runtime` directory.
|
||||
|
||||
```bash
|
||||
cd qiskit_ibm_runtime
|
||||
```
|
||||
|
||||
3. (Optional) If you want to run tests or linting checks, install the developer requirements. We recommend using a [virtual environment](https://docs.python.org/3/library/venv.html) to avoid polluting your global Python installation.
|
||||
|
||||
```bash
|
||||
pip install -r requirements-dev.txt
|
||||
```
|
||||
|
||||
4. Install `qiskit-runtime`. We recommend using a [virtual environment](https://docs.python.org/3/library/venv.html) to avoid polluting your global Python installation.
|
||||
|
||||
- **Standard install**:
|
||||
|
||||
```bash
|
||||
pip install .
|
||||
```
|
||||
|
||||
- **Editable mode**: In this mode, you don't need to reinstall Qiskit when there are code changes to the project.
|
||||
|
||||
```bash
|
||||
pip install -e .
|
||||
```
|
||||
|
||||
In editable mode, the compiled extensions are built in _debug mode_ without optimizations.
|
||||
|
||||
## Next steps
|
||||
|
||||
<Admonition type="tip" title="Recommendations">
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ description: Install and set up Qiskit and Qiskit Runtime on various operating s
|
|||
<span id="qiskit-install"></span>
|
||||
# Install and set up Qiskit
|
||||
|
||||
Whether you will work locally or in a cloud environment, the first step for all users is to install Qiskit. For those wanting to run on a real backend, your next step is to choose one of two channels in order to access IBM Quantum systems: IBM Quantum Platform or IBM Cloud.
|
||||
Whether you will work locally or in a cloud environment, the first step for all users is to install Qiskit. For those wanting to run on a real system, your next step is to choose one of two channels in order to access IBM Quantum systems: IBM Quantum Platform or IBM Cloud.
|
||||
|
||||
<span id="local"></span>
|
||||
## Install and set up Qiskit with the Qiskit Runtime Client
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ description: Installation and setup instructions for IBM Quantum Platform or IBM
|
|||
|
||||
# Select and set up an IBM Quantum channel
|
||||
|
||||
You can access IBM Quantum systems by using the IBM Quantum Platform or IBM Cloud channel.
|
||||
You can access IBM Quantum systems by using the IBM Quantum Platform or IBM Cloud _channel_. _Channel_ is the term used to describe the method you use to access IBM Quantum services.
|
||||
|
||||
### IBM Quantum Platform
|
||||
|
||||
|
|
|
|||
|
|
@ -68,6 +68,17 @@ An example of citing an IBM Quantum program:
|
|||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>
|
||||
How do I cite IBM Quantum Composer in my research?
|
||||
</summary>
|
||||
|
||||
An example of citing IBM Quantum Composer:
|
||||
|
||||
> IBM Quantum Composer. 2023. url: https://<span>quantum.ibm.com/composer</span>
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary>
|
||||
Why do I receive the error message `AttributeError: QuantumCircuit object has no attribute 'save_state'` when using `save_*`method on a circuit?
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ circuit = EfficientSU2(120, entanglement="circular", reps=1).decompose()
|
|||
transpiled_circuit = ai_passmanager.run(circuit)
|
||||
```
|
||||
|
||||
Here, the `target` determines which backend to route for, the `optimization_level` (1, 2, or 3) determines the computational effort to spend in the process (higher usually gives better results but takes longer), and the `layout_mode` specifies how to handle the layout selection.
|
||||
Here, the `target` determines which system to route for, the `optimization_level` (1, 2, or 3) determines the computational effort to spend in the process (higher usually gives better results but takes longer), and the `layout_mode` specifies how to handle the layout selection.
|
||||
The `layout_mode` includes the following options:
|
||||
|
||||
- `keep`: This respects the layout set by the previous transpiler passes (or uses the trivial layout if not set). It is typically only used when the circuit must be run on specific qubits of the device. It often produces worse results because it has less room for optimization.
|
||||
|
|
|
|||
|
|
@ -6,19 +6,26 @@
|
|||
"source": [
|
||||
"# Write a custom transpiler pass\n",
|
||||
"\n",
|
||||
"Qiskit lets you create custom transpilation passes and run them in the `PassManager` object or add them to a `StagedPassMager`. Here we will demonstrate how to write a transpiler pass, focusing on building a pass that performs [Pauli twirling](https://arxiv.org/abs/quant-ph/0606161) on the noisy quantum gates in a quantum circuit. This example uses the DAG, which is the object manipulated by the `TransformationPass` type of pass.\n"
|
||||
"Qiskit lets you create custom transpilation passes and run them in the `PassManager` object or add them to a `StagedPassManager`. Here we will demonstrate how to write a transpiler pass, focusing on building a pass that performs [Pauli twirling](https://arxiv.org/abs/quant-ph/0606161) on the noisy quantum gates in a quantum circuit. This example uses the DAG, which is the object manipulated by the `TransformationPass` type of pass.\n"
|
||||
]
|
||||
},
|
||||
{
|
||||
"cell_type": "code",
|
||||
"execution_count": null,
|
||||
"metadata": {},
|
||||
"outputs": [],
|
||||
"source": []
|
||||
},
|
||||
{
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"<details>\n",
|
||||
" <summary>\n",
|
||||
" Background: DAG Representation\n",
|
||||
" Background: DAG representation\n",
|
||||
" </summary>\n",
|
||||
"\n",
|
||||
"Before building a pass it is important to introduce the internal representation of quantum circuits in Qiskit, the [directed acyclic graph (DAG)](../api/qiskit/qiskit.dagcircuit.DAGCircuit) (see [this tutorial](https://qiskit.org/ecosystem/rustworkx/tutorial/dags.html) for an overview). To follow these steps, install the `graphivz` library for the DAG plotting functions. Use a python package manager (such as `pip` or `conda`) to install `pydot` and your system's native package manager (for example, `apt`, `brew`, `yum`, or `dnf`) for `graphivz`.\n",
|
||||
"Before building a pass it is important to introduce the internal representation of quantum circuits in Qiskit, the [directed acyclic graph (DAG)](../api/qiskit/qiskit.dagcircuit.DAGCircuit) (see [this tutorial](https://qiskit.org/ecosystem/rustworkx/tutorial/dags.html) for an overview). To follow these steps, install the `graphivz` library for the DAG plotting functions. Use a Python package manager (such as `pip` or `conda`) to install `pydot` and your system's native package manager (for example, `apt`, `brew`, `yum`, or `dnf`) for `graphivz`.\n",
|
||||
"\n",
|
||||
"In Qiskit, within the transpilation stages, circuits are represented using a DAG. In general, a DAG is composed of *vertices* (also known as \"nodes\") and directed *edges* that connect pairs of vertices in a particular orientation. This representation is stored using `qiskit.dagcircuit.DAGCircuit` objects that are composed of invididual `DagNode` objects. The advantage of this representation over a pure list of gates (that is, a *netlist*) is that the flow of information between operations is explicit, making it easier to make transformation decisions. \n",
|
||||
"\n",
|
||||
|
|
@ -58,7 +65,7 @@
|
|||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"## Transpiler Passes\n",
|
||||
"## Transpiler passes\n",
|
||||
"\n",
|
||||
"Transpiler passes are classified as analysis or transformation passes. Passes in general work with the [DAG](../api/qiskit/qiskit.dagcircuit.DAGCircuit) and the `property_set`, a dictionary-like object for storing properties determined by analysis passes. Analysis passes work with the DAG but cannot modify it. This contrasts with transformation passes, which do modify the DAG, and can read (but not write to) `property_set`. "
|
||||
]
|
||||
|
|
@ -71,7 +78,7 @@
|
|||
"\n",
|
||||
"The following example constructs a transpiler pass that adds Pauli twirls. [Pauli twirling](https://arxiv.org/abs/quant-ph/0606161) is an error suppression strategy that randomizes how qubits experience noisy channels, which we assume to be two-qubit gates in this example (because they are much more error-prone than single-qubit gates). The Pauli twirls do not affect the two-qubit gates' operation. They are chosen such that those applied *before* the two-qubit gate (to the left) are countered by those applied *after* the two-qubit gate (to the right). In this sense, the two-qubit operations are identical, but the way they are performed is different. One benefit of Pauli twirling is that it turns coherent errors into stochastic errors, which can be improved by averaging more.\n",
|
||||
"\n",
|
||||
"Transpiler passes act on the [DAG](../api/qiskit/qiskit.dagcircuit.DAGCircuit), so the important method to override is `.run()`, which takes the DAG as input. Initializing pairs Paulis as shown preserves the operation of each two-qubit gate. This is done with the helper method `build_twirl_set`, which goes through each two-qubit Pauli (as obtained from `pauli_basis(2)`) and finds the other Pauli that preserves the operation. \n",
|
||||
"Transpiler passes act on the [DAG](../api/qiskit/qiskit.dagcircuit.DAGCircuit), so the important method to override is `.run()`, which takes the DAG as input. Initializing pairs of Paulis as shown preserves the operation of each two-qubit gate. This is done with the helper method `build_twirl_set`, which goes through each two-qubit Pauli (as obtained from `pauli_basis(2)`) and finds the other Pauli that preserves the operation. \n",
|
||||
"\n",
|
||||
"From the DAG, use the `op_nodes()` method to return all of its nodes. The DAG can also be used to collect runs, which are sequences of nodes that run uninterrupted on a qubit. These can be collected as single-qubit runs with `collect_1q_runs`, two-qubit runs with `collect_2q_runs`, and runs of nodes where the instruction names are in a namelist with `collect_runs`. The `DAGCircuit` has many methods for searching and traversing a graph. One commonly used method is `topological_op_nodes`, which provides the nodes in a dependency ordering. Other methods such as `bfs_successors` are used primarily to determine how nodes interact with subsequent operations on a DAG. \n",
|
||||
"\n",
|
||||
|
|
|
|||
|
|
@ -5,13 +5,13 @@ description: Default settings and configuration options
|
|||
|
||||
# Transpilation default settings and configuration options
|
||||
|
||||
Abstract circuits need to be transpiled because backends have a limited set of basis gates and cannot execute arbitrary operations. The transpiler's function is to change arbitrary circuits so that they can run on a specified backend. This is done by translating the circuits to the supported basis gates, and by introducing SWAP gates as needed, so that the circuit's connectivity matches that of the backend.
|
||||
Abstract circuits need to be transpiled because systems have a limited set of basis gates and cannot execute arbitrary operations. The transpiler's function is to change arbitrary circuits so that they can run on a specified system. This is done by translating the circuits to the supported basis gates, and by introducing SWAP gates as needed, so that the circuit's connectivity matches that of the system.
|
||||
|
||||
You can pass circuits and a backend to the `transpile()` function and use all default settings, or you can use parameters to fine tune the transpilation.
|
||||
You can pass circuits and a system to the `transpile()` function and use all default settings, or you can use parameters to fine tune the transpilation.
|
||||
|
||||
## Basic usage without parameters
|
||||
|
||||
In this example, we pass a circuit and target backend to the transpiler without specifying any further parameters.
|
||||
In this example, we pass a circuit and target system to the transpiler without specifying any further parameters.
|
||||
|
||||
Create a circuit and view the result:
|
||||
|
||||
|
|
@ -40,7 +40,7 @@ qc.draw(output='mpl')
|
|||
Transpile the circuit and view the result:
|
||||
|
||||
```python
|
||||
# Specify the backend to target
|
||||
# Specify the system to target
|
||||
backend = FakeSherbrooke()
|
||||
|
||||
# Transpile the circuit
|
||||
|
|
@ -62,24 +62,24 @@ All parameters except `circuits` are optional. For full details, see the [Trans
|
|||
|
||||
### Parameters used to describe the compilation target:
|
||||
|
||||
These arguments describe the system that the input circuit will be run on. For example, they may be used to ensure that the returned circuit can be run on the specified backend, where the transpiler maps the circuit's virtual qubits to the physical qubits which may have limited connectivity as specified in the `coupling_map`, `basis_gates` that specify which single- and two-qubit gates are calibrated for the backend, and possibly their error rates.
|
||||
These arguments describe the system that the input circuit will be run on. For example, they may be used to ensure that the returned circuit can be run on the specified system, where the transpiler maps the circuit's virtual qubits to the physical qubits which may have limited connectivity as specified in the `coupling_map`, `basis_gates` that specify which single- and two-qubit gates are calibrated for the system, and possibly their error rates.
|
||||
|
||||
Many of these parameters are described in detail in [Commonly used parameters for transpilation](common-parameters).
|
||||
|
||||
<details>
|
||||
<summary>
|
||||
**Backend parameters**
|
||||
**System (`Backend`) parameters**
|
||||
</summary>
|
||||
|
||||
**Backend parameters** - If you specify `backend`, you don't need to specify `target` or any other backend options. Likewise, if you specify `target`, you don't need to specify `backend` or any other backend options.
|
||||
|
||||
- `backend` (Backend) - If this is set, the transpiler compiles the input circuit to this device. If any other option is set that impacts these settings, such as `coupling_map`, it overrides the settings from `backend`.
|
||||
- `target` (Target) - A backend transpiler target. Normally this is specified as part of the backend argument, but if you manually constructed a Target object, you can specify it here. This overrides the target from `backend`.
|
||||
- `backend_properties` (BackendProperties) - Properties returned by a backend, including information on gate errors, readout errors, qubit coherence times, and so on. Find a backend that provides this information by running `backend.properties()`.
|
||||
- `backend_properties` (BackendProperties) - Properties returned by a system, including information on gate errors, readout errors, qubit coherence times, and so on. Find a system that provides this information by running `backend.properties()`.
|
||||
- `dt` (float | None) - Backend sample time (resolution) in seconds. If `None` is specified (default), `backend.configuration().dt` is used.
|
||||
- `ignore_backend_supplied_default_methods` (bool) - If set to `True`, any default methods specified by a backend are ignored. Some backends specify alternative default methods to support custom compilation target-specific passes / plugins that support backend-specific compilation techniques. If you prefer that these defaults are not used, this option disables those backend-specific defaults.
|
||||
- `instruction_durations` (List\[Tuple\[str, Iterable[int], float, Iterable[float], str]] | List\[Tuple\[str, Iterable[int], float, Iterable[float]]] | List\[Tuple\[str, Iterable[int], float, str]] | List\[Tuple\[str, Iterable[int], float]] | InstructionDurations) - Durations of instructions. Applicable only if `scheduling_method` is specified. The gate lengths defined in `backend.properties` are used by default. They are overwritten if `instruction_durations` is specified. The `instruction_durations` format must be as follows. The instruction_durations must be given as a list of tuples [(instruction_name, qubits, duration, unit), …]. | \[(`cx`, [0, 1], 12.3, `ns`), (`u3`, [0], 4.56, `ns`)] | \[(`cx`, [0, 1], 1000), (`u3`, [0], 300)] If `unit` is omitted, the default is `dt`, which is a sample time depending on backend. If the time unit is `dt`, the duration must be an integer.
|
||||
- `timing_constraints` (Dict[str, int] | None) - An optional control hardware restriction on instruction time resolution. This information is provided by the backend configuration. If the backend doesn’t have any restriction on the instruction time allocation, `timing_constraints` is `None` and no adjustment is performed. A quantum computer backend might report a set of restrictions, namely:
|
||||
- `ignore_backend_supplied_default_methods` (bool) - If set to `True`, any default methods specified by a system are ignored. Some systems specify alternative default methods to support custom compilation target-specific passes / plugins that support system-specific compilation techniques. If you prefer that these defaults are not used, this option disables those system-specific defaults.
|
||||
- `instruction_durations` (List\[Tuple\[str, Iterable[int], float, Iterable[float], str]] | List\[Tuple\[str, Iterable[int], float, Iterable[float]]] | List\[Tuple\[str, Iterable[int], float, str]] | List\[Tuple\[str, Iterable[int], float]] | InstructionDurations) - Durations of instructions. Applicable only if `scheduling_method` is specified. The gate lengths defined in `backend.properties` are used by default. They are overwritten if `instruction_durations` is specified. The `instruction_durations` format must be as follows. The instruction_durations must be given as a list of tuples [(instruction_name, qubits, duration, unit), …]. | \[(`cx`, [0, 1], 12.3, `ns`), (`u3`, [0], 4.56, `ns`)] | \[(`cx`, [0, 1], 1000), (`u3`, [0], 300)] If `unit` is omitted, the default is `dt`, which is a sample time depending on system. If the time unit is `dt`, the duration must be an integer.
|
||||
- `timing_constraints` (Dict[str, int] | None) - An optional control hardware restriction on instruction time resolution. This information is provided by the system configuration. If the system doesn’t have any restriction on the instruction time allocation, `timing_constraints` is `None` and no adjustment is performed. A system might report a set of restrictions, namely:
|
||||
\- `granularity`: An integer value representing the minimum pulse gate resolution in units of dt. A user-defined pulse gate should have duration that is a multiple of this granularity value.
|
||||
\- `min_length`: An integer value representing the minimum pulse gate length in units of dt. A user-defined pulse gate should be longer than this length.
|
||||
\- `pulse_alignment`: An integer value representing a time resolution of gate instruction starting time. Gate instructions should start at time that is a multiple of this value.
|
||||
|
|
@ -94,8 +94,8 @@ Many of these parameters are described in detail in [Commonly used parameters fo
|
|||
- `basis_gates` (List[str] | None) - List of basis gate names to unroll to. For example ['u1', 'u2', 'u3', 'cx']. If `None`, do not unroll.
|
||||
- `coupling_map` (CouplingMap | List\[List[int]]) - Directed coupling map (possibly custom) to target in mapping. If the coupling map is symmetric, both directions need to be specified. These formats are supported:
|
||||
- CouplingMap instance
|
||||
- List, must be given as an adjacency matrix, where each entry specifies all directed two-qubit interactions supported by backend. For example:\[[0, 1], [0, 3], [1, 2], [1, 5], [2, 5], [4, 1], [5, 3]]
|
||||
- `inst_map` (List[InstructionScheduleMap] | None) - Mapping of circuit operations to pulse schedules. If `None`, the backend’s `instruction_schedule_map` is used.
|
||||
- List, must be given as an adjacency matrix, where each entry specifies all directed two-qubit interactions supported by the system. For example:\[[0, 1], [0, 3], [1, 2], [1, 5], [2, 5], [4, 1], [5, 3]]
|
||||
- `inst_map` (List[InstructionScheduleMap] | None) - Mapping of circuit operations to pulse schedules. If `None`, the system’s `instruction_schedule_map` is used.
|
||||
</details>
|
||||
|
||||
### Parameters used to influence how the transpiler works:
|
||||
|
|
|
|||
|
|
@ -19,10 +19,10 @@ Find more information about the pass manager stages in the [Transpiler stages](t
|
|||
|
||||
Qiskit's prebuilt transpiler pipeline consists of six fundamental stages:
|
||||
|
||||
1. `init` - This pass runs any initial passes that are required before we start embedding the circuit to the backend. This typically involves unrolling custom instructions and converting the circuit to all single- and two-qubit gates. (By default this will just validate the circuit instructions and translate multi-qubit gates into single- and two-qubit gates.)
|
||||
2. `layout` - This pass applies a _layout_, mapping/assigning the virtual qubits in your circuit to the physical qubits of a backend.
|
||||
3. `routing` - This pass runs after a layout has been applied and will inject gates (i.e., SWAPs) in the original circuit in order to make it compatible with the backend's connectivity/coupling map.
|
||||
4. `translation` - This pass translates the gates in the circuit to the backend's basis set of instructions.
|
||||
1. `init` - This pass runs any initial passes that are required before we start embedding the circuit to the system. This typically involves unrolling custom instructions and converting the circuit to all single- and two-qubit gates. (By default this will just validate the circuit instructions and translate multi-qubit gates into single- and two-qubit gates.)
|
||||
2. `layout` - This pass applies a _layout_, mapping/assigning the virtual qubits in your circuit to the physical qubits of a system.
|
||||
3. `routing` - This pass runs after a layout has been applied and will inject gates (i.e., SWAPs) in the original circuit in order to make it compatible with the system's connectivity/coupling map.
|
||||
4. `translation` - This pass translates the gates in the circuit to the system's basis set of instructions.
|
||||
5. `optimization` - This pass runs an optimization loop to find more efficient decompositions of your quantum circuit until a condition is met (such as a fixed depth).
|
||||
6. `scheduling` - This stage is for any hardware-aware scheduling passes. If the user specifies a scheduling method, this stage accounts for all idle time in the circuit.
|
||||
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ By default, the package tries to authenticate to IBM Quantum services with the d
|
|||
|
||||
## qiskit-transpiler-service transpile options
|
||||
|
||||
- `target` (optional, str) - A backend name as it would be expected by QiskitRuntimeService (for example, `ibm_sherbrooke`). If this is set, the transpile method uses the layout from the specified backend for the transpilation operation. If any other option is set that impacts these settings, such as `coupling_map`, the `target` settings are overridden.
|
||||
- `target` (optional, str) - A system name as it would be expected by QiskitRuntimeService (for example, `ibm_sherbrooke`). If this is set, the transpile method uses the layout from the specified system for the transpilation operation. If any other option is set that impacts these settings, such as `coupling_map`, the `target` settings are overridden.
|
||||
- `coupling_map` (optional, List\[List[int]]) - A valid coupling map list (for example, \[[0,1],[1,2]]). If this is set, the transpile method uses this coupling map for the transpilation operation. If defined, it overrides any value specified for `target`.
|
||||
- `optimization_level` (int) - The potential optimization level to apply during the transpilation process. Valid values are [1,2,3], where 1 is the least optimization (and fastest), and 3 the most optimization (and most time-intensive).
|
||||
- `ai` (bool) - Whether to use AI capabilities during transpilation. The AI capabilities available can be for `AIRouting` transpiling passes or other AI synthesis methods. If this value is `True`, the service applies different AI-powered transpiling passes depending on the `optimization_level` requested.
|
||||
|
|
@ -55,7 +55,6 @@ The following examples demonstrate how to transpile circuits using the Qiskit tr
|
|||
|
||||
2. Produce a similar random circuit and transpile it, requesting AI transpiling capabilities by setting the flag `ai` to `True`:
|
||||
|
||||
````
|
||||
```python
|
||||
from qiskit.circuit.random import random_circuit
|
||||
from qiskit_transpiler_service.transpiler_service import TranspilerService
|
||||
|
|
@ -69,9 +68,8 @@ The following examples demonstrate how to transpile circuits using the Qiskit tr
|
|||
)
|
||||
transpiled_circuit = cloud_transpiler_service.run(random_circ)
|
||||
```
|
||||
````
|
||||
|
||||
## Next steps
|
||||
## Next steps
|
||||
|
||||
<Admonition type="tip" title="Recommendations">
|
||||
- Learn how to create [AI transpiler passes.](ai-transpiler-passes)
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
---
|
||||
title: Representing quantum computers
|
||||
description: Learn about coupling maps, basis gates and backend errors for transpiling
|
||||
description: Learn about coupling maps, basis gates and system errors for transpiling
|
||||
---
|
||||
|
||||
# Represent quantum computers
|
||||
|
||||
To construct an equivalent circuit that can run on a specific backend, the transpiler needs certain details about the backend. Typically, this information is found in the `backend` or `target = backend.target` class, so you don't need to pass anything further to the transpiler. However, if more infomation is provided, the transpiler can use it to try to produce the best circuit to run on that hardware.
|
||||
To construct an equivalent circuit that can run on a specific system, the transpiler needs certain details about the system. Typically, this information is found in the `backend` or `target = backend.target` class, so you don't need to pass anything further to the transpiler. However, if more infomation is provided, the transpiler can use it to try to produce the best circuit to run on that hardware.
|
||||
|
||||
<Admonition type="note">
|
||||
Because many of the underlying transpilation algorithms are stochastic, there is no guarantee that a better circuit will be found.
|
||||
|
|
@ -14,9 +14,9 @@ Because many of the underlying transpilation algorithms are stochastic, there is
|
|||
<span id="default-config"></span>
|
||||
## Default configuration
|
||||
|
||||
The simplest use of the transpiler is to provide all the backend information by providing the `backend` or `target`. To better understand how the transpiler works, construct a circuit and transpile it with different information:
|
||||
The simplest use of the transpiler is to provide all the system information by providing the `backend` or `target`. To better understand how the transpiler works, construct a circuit and transpile it with different information:
|
||||
|
||||
Import the necessary libraries and instantiate the backend:
|
||||
Import the necessary libraries and instantiate the system or simulator:
|
||||
|
||||
```python
|
||||
from qiskit import transpile
|
||||
|
|
@ -36,9 +36,9 @@ qc.decompose(reps=1).draw('mpl', style='iqp')
|
|||
|
||||
|
||||
|
||||
### Transpile the circuit to backend target
|
||||
### Transpile the circuit to `backend` target
|
||||
|
||||
This example uses the default `optimization_level=1` to transpile to the `backend` `target`, which providers all the information to the transpiler that is necessary to convert circuit to one that will run on the backend.
|
||||
This example uses the default `optimization_level=1` to transpile to the `backend` `target`, which providers all the information to the transpiler that is necessary to convert circuit to one that will run on the system.
|
||||
|
||||
```python
|
||||
qc_t_target = transpile(qc, target=target, seed_transpiler=12345)
|
||||
|
|
@ -47,9 +47,9 @@ qc_t_target.draw('mpl', style='iqp', idle_wires=False)
|
|||
|
||||
|
||||
|
||||
This example is used in later sections of this topic to illustrate that the coupling map and basis gates are the essential pieces of information to pass to the transpiler for optimal circuit construction. The backend can usually select default settings for other information that is not passed in, such as timing and scheduling.
|
||||
This example is used in later sections of this topic to illustrate that the coupling map and basis gates are the essential pieces of information to pass to the transpiler for optimal circuit construction. The system can usually select default settings for other information that is not passed in, such as timing and scheduling.
|
||||
|
||||
Providing the backend properties, including the gates' error rates, allows the transpiler to select the best set of qubits on the backend.
|
||||
Providing the `backend` properties, including the gates' error rates, allows the transpiler to select the best set of qubits on the system.
|
||||
|
||||
## Coupling map
|
||||
|
||||
|
|
@ -105,7 +105,7 @@ Now the layout is in a ring. Because this layout respects the circuit's connect
|
|||
|
||||
## Basis gates
|
||||
|
||||
Every quantum backend supports a limited instruction set, called its _basis gates_. Every gate in the circuit must be translated to the elements of this set. This set should consist of single- and two-qubit gates that provide a universal gates set, meaning that any quantum operation can be decomposed into those gates. This is done by the [BasisTranslator](../api/qiskit/qiskit.transpiler.passes.BasisTranslator), and the basis gates can be specified as a keyword argument to the transpiler to provide this information.
|
||||
Every quantum system supports a limited instruction set, called its _basis gates_. Every gate in the circuit must be translated to the elements of this set. This set should consist of single- and two-qubit gates that provide a universal gates set, meaning that any quantum operation can be decomposed into those gates. This is done by the [BasisTranslator](../api/qiskit/qiskit.transpiler.passes.BasisTranslator), and the basis gates can be specified as a keyword argument to the transpiler to provide this information.
|
||||
|
||||
```python
|
||||
basis_gates = list(target.operation_names)
|
||||
|
|
@ -116,10 +116,10 @@ print(basis_gates)
|
|||
['rz', 'sx', 'x', 'ecr', 'measure', 'delay']
|
||||
```
|
||||
|
||||
The default single-qubit gates on _ibm_sherbrooke_ are `rz`, `x`, and `sx`, and the default two-qubit gate is `ecr` which stands for echoed cross resonance. CX gates are constructed from `ecr` gates, so on some backends `ecr` is specified as the two-qubit basis gate while on others `cx` is default. The `ecr` gates is the _entangling_ part of the `cx` gate. If one desires to use a gate that is not in the basis gate set, instructions for custom gates can be provided using [pulse gates](https://docs.quantum.ibm.com/api/qiskit/qiskit.transpiler.passes.PulseGates#pulsegates). In addition to the control gates, there are also `delay` and `measurement` instructions.
|
||||
The default single-qubit gates on _ibm_sherbrooke_ are `rz`, `x`, and `sx`, and the default two-qubit gate is `ecr` which stands for echoed cross resonance. CX gates are constructed from `ecr` gates, so on some systems `ecr` is specified as the two-qubit basis gate while on others `cx` is default. The `ecr` gates is the _entangling_ part of the `cx` gate. If one desires to use a gate that is not in the basis gate set, instructions for custom gates can be provided using [pulse gates](https://docs.quantum.ibm.com/api/qiskit/qiskit.transpiler.passes.PulseGates#pulsegates). In addition to the control gates, there are also `delay` and `measurement` instructions.
|
||||
|
||||
<Admonition>
|
||||
Backends have default basis gates, but you can choose whatever gates you want, as long as you provide the instruction or add pulse gates (See [Create transpiler passes.](custom-transpiler-pass)) The default basis gates are those that calibrations have been done for on the backend, so no further instruction/pulse gate needs to be provided. For example, on some backends `cx` is the default two-qubit gates and `ecr` on others.
|
||||
Systems have default basis gates, but you can choose whatever gates you want, as long as you provide the instruction or add pulse gates (See [Create transpiler passes.](custom-transpiler-pass)) The default basis gates are those that calibrations have been done for on the system, so no further instruction/pulse gate needs to be provided. For example, on some systems `cx` is the default two-qubit gates and `ecr` on others.
|
||||
</Admonition>
|
||||
|
||||
```python
|
||||
|
|
@ -131,11 +131,11 @@ qc_t_cm_bg.draw('mpl', style='iqp', fold=-1, idle_wires=False)
|
|||
|
||||
Note that the `CXGate`s have been decomposed to `ecr` gates and single-qubit basis gates.
|
||||
|
||||
## Including backend errors
|
||||
## Including system errors
|
||||
|
||||
Constructing a `target` object lets you consider the qubits' error rates in addition to the `coupling_map` and `basis_gates`. The `target` object contains everything needed to target a backend, but here we build one that contains a limited amount of information.
|
||||
Constructing a `target` object lets you consider the qubits' error rates in addition to the `coupling_map` and `basis_gates`. The `target` object contains everything needed to target a system, but here we build one that contains a limited amount of information.
|
||||
|
||||
We retrieved the `target` from `backend.target` previously. This contains a lot of backend information, including error rates. For example, the instruction properties of the echoed cross resonance gate between qubit 0 and 1 (not that `ecr` is directional) is retrieved by running the following command:
|
||||
We retrieved the `target` from `backend.target` previously. This contains a lot of system information, including error rates. For example, the instruction properties of the echoed cross resonance gate between qubit 0 and 1 (not that `ecr` is directional) is retrieved by running the following command:
|
||||
|
||||
```python
|
||||
target['ecr'][(1, 0)]
|
||||
|
|
|
|||
|
|
@ -7,11 +7,11 @@ description: Learn how to set the optimization level
|
|||
|
||||
Decomposing quantum circuits into the basis gate set of the target device and the addition of SWAP gates needed to match hardware topology causes an increase in the depth and gate count of quantum circuits. To mitigate this increased complexity, you can set the `optimization_level`. Setting this value calls an optimization routine that optimizes the transpilation process by combining or eliminating gates and by optionally using algorithms to find an optimal layout (depending on the level chosen).
|
||||
|
||||
In some cases these methods are so effective the output circuits have lower depth than the inputs. In other cases, not much can be done, and the computation may be difficult to perform on noisy devices. Choosing the best optimization level might take trial and error, as it depends heavily on the circuit being transpiled and the backend being targeted.
|
||||
In some cases these methods are so effective the output circuits have lower depth than the inputs. In other cases, not much can be done, and the computation may be difficult to perform on noisy devices. Choosing the best optimization level might take trial and error, as it depends heavily on the circuit being transpiled and the system being targeted.
|
||||
|
||||
Higher optimization levels generate more optimized circuits at the expense of longer compile times. By default, `optimization_level=1` is used.
|
||||
|
||||
- `optimization_level=0`: Trivial optimization, which maps the circuit to the backend with no explicit optimization.
|
||||
- `optimization_level=0`: Trivial optimization, which maps the circuit to the system with no explicit optimization.
|
||||
- `optimization_level=1-3`: Increasingly complex optimization, with heuristic algorithms that are used to find a layout and insert SWAP gates, with the goal of improving the overall performance of the circuit. The number of iterations that these algorithms run increases with higher optimization levels.
|
||||
|
||||
Because finding the best layout is an NP-hard problem, it is the most time-consuming part of the transpilation process. However, Qiskit uses stochastic algorithms that have been refactored into Rust, resulting in significant speedup. Therefore, optimization levels 1-3 all use the same layout algorithms. There are some slight differences in how the circuits are translated into basis gates, as described in the following table:
|
||||
|
|
@ -94,7 +94,7 @@ qc.draw('mpl')
|
|||
|
||||
|
||||
|
||||
We use `FakeTokyo` as the backend and transpile using `optimization_level=1` (the default). To avoid considering the effect of idle qubits, We override the backend's coupling map so that the transpiled circuit returns to a two-qubit circuit.
|
||||
We use `FakeTokyo` as the system and transpile using `optimization_level=1` (the default). To avoid considering the effect of idle qubits, We override the system's coupling map so that the transpiled circuit returns to a two-qubit circuit.
|
||||
|
||||
```python
|
||||
backend = FakeTokyo()
|
||||
|
|
|
|||
Loading…
Reference in New Issue