ideal
and noisy
simulations, allowing you to choose to see both the complete range of outcomes in the ideal case, or an example of how a circuit would run on physical hardware with a limited number of shots.
Noise models are provided for IonQ’s currently available QPUs (Aria 1, Aria 2, Forte 1 and Forte Enterprise 1), as well as our retired Harmony QPU. Like our ideal cloud-based simulators, they are free for all users with direct IonQ access, including through Google Cloud Marketplace or simulator-only accounts. Noise model simulations can be submitted through our API, Qiskit, and Cirq.
Noise model simulation uses an approximation of system performance, and is meant to help users understand the impact of noise on quantum algorithms. IonQ offers no specific guarantees of accuracy, and these models should not be used to predict if a specific IonQ system will or won’t be able to successfully execute a specific circuit.
Our noise model
We perform a detailed gate-level characterization of the noise sources on our systems, and then approximate the noise model with a depolarization error channel where the noise strength is determined from the gate-level characterization of the noises. The Kraus operators for one-qubit depolarization error channels are given by: , where are Pauli matrices and is an identity. Similarly, two-qubit Kraus operators are: , where are Pauli matrices and is an identity. The one- and two-qubit depolarization channels are applied after each corresponding ideal one- and two-qubit gate in the circuit. For our currently available Aria and Forte systems, the error rate parameters used for one- and two-qubit gates in this model are:System | ||
---|---|---|
Aria 1 | 0.0005 | 0.0133 |
Aria 2 | 0.0006573333333333332 | 0.01856 |
Forte 1 | 0.0002666666666666667 | 0.004949333333333333 |
Harmony (retired in September 2024) has a noise model available in our cloud simulator, but it uses a different formula and parameters than those described above.
We continually improve our understanding of noise sources in our systems and develop new strategies for error suppression and mitigation, which may be reflected in changes or updates to our noise models over time.
Example results
Here’s an example of ideal simulation, noisy simulation, and QPU execution for a nine-qubit GHZ state. This circuit creates the maximally-entangled state that is the equal superposition of and .harmony
noise model and 1000 shots, and our Harmony QPU (which has since been retired) with 1000 shots. Here’s the output probabilities graphed together for comparison:


Using the noisy simulator
Noisy simulation jobs are submitted in the same fashion as anideal
simulation, but specifying a named noise model instead: aria-1
, aria-2
, forte-1
, or harmony
. (The forte-enterprise-1
noise model will be available in the future.)
You can also specify "ideal"
whenever you are setting the noise model. This will use the ideal simulator, which is also the default if no noise model is specified.
For our smaller systems, each noise model simulation can use as many qubits as its corresponding QPU has (25 qubits for Aria 1 or Aria 2, 11 qubits for Harmony). For our Forte 1 system (which has 36 qubits) as well as our ideal simulator, each simulation can currently use up to 29 qubits. Simulation capabilities for larger circuits will be available in the future.
Unlike ideal simulation, which runs a single calculation to generate probabilities, noise model simulation is shot-aware: it will run one simulation for each shot you request. This means that the number of counts in your output histogram will match the number of shots you submitted. Another implication of this: the more shots you use, the longer your simulation will take to finish - though this generally isn’t very noticeable unless you are simulating circuits with many qubits and a very large number of shots.
The noise model takes an optional parameter called seed
. This allows you to specify a specific seed for the pseudo-random noise generation and shot sampling that occurs during noise model simulation, allowing for reproducible “noisy” results. If you don’t provide a seed, one will be chosen at random and then provided as part of the simulation output (viewable in an API job result or the job detail page in the IonQ Cloud Console). The seed can be any integer between 1 and .
Jobs submitted to a noisy simulator follow the same compilation and optimization process as jobs submitted to a QPU. If the circuit is written in abstract gates, it will be compiled to IonQ’s native gates and optimized before simulation. If the circuit is written in our native gates, it will not be optimized or modified before simulation.
Noisy simulation currently doesn’t include debiasing, our default error mitigation strategy. Future versions of our simulator may implement this feature.
API example
When submitting a job via the API, use"target": "simulator"
and add "noise": {"model": "aria-1"}
(or specify a different QPU noise model) to the job body.
To specify a random seed, use "noise": {"model": "aria-1", "seed": 481516}
.
Qiskit examples
When using an IonQ backend with Qiskit, the noise model can be specified either when setting up a backend or when submitting a job.For a backend
To set the noise model for a simulator backend, which will be the default noise model for all jobs run on that backend, usebackend.set_options(noise_model="aria-1")
.
To also specify the simulation’s random seed, use backend.set_options(noise_model="aria-1", sampler_seed=8151623)
.
For a job
To set the noise model for an individual job run on a simulator backend, use thenoise_model
keyword argument when calling backend.run()
.
Cirq example
When using an IonQ service with Cirq, useextra_query_params={"noise": {"model": "aria-1"}}
(or specify another noise model) when running a job. You can also use extra_query_params
to add other parameters, using the same format as an API job.
To specify the simulation’s random seed, use extra_query_params={"noise": {"model": "aria-1", "seed": 15162342}}
.
Noise model do’s and don’t’s
Do:- Run noisy simulations before submitting jobs to a QPU. This is a great way to test your code and workflows!
- Explore the directional effect of noise while varying circuit depth, complexity, and number of shots, as well as testing noise models for different QPUs. For example, comparing an ideal and noisy simulation can help you isolate and understand the effects of noise from statistical sampling vs errors from running the circuit.
- Reconsider your approach if you get completely unusable results from a noisy simulation. If your circuit is clearly well beyond the limits of the noisy simulator performance, it’s unlikely to perform better on today’s QPUs. You may need to consider shallower circuits, additional optimization, or other approaches.
- Expect QPU results to quantitatively match noisy simulation results. These noise models are simplified approximations of what would happen on actual hardware, provided for developer convenience and efficiency, and should not be considered a replacement for running circuits on real hardware.
- Use noise model results to precisely predict what a given IonQ system will or won’t be able to execute. If you need help in understanding if your algorithm will successfully run on a specific generation of IonQ hardware, please reach out to [email protected] for guidance.
- Rely on noise model results when investigating specific error channels or benchmarking methods. For these specialized circuits that are sensitive to particular sources of noise, this general model likely won’t work well.