Skip to main contentIBM Quantum Documentation
Important

IBM Quantum Platform is moving and this version will be sunset on July 1. To get started on the new platform, read the migration guide.

Dynamic repetition rate execution

When a circuit is executed on an IBM® quantum processing unit (QPU), an implicit reset is typically inserted at the beginning of the circuit to ensure the qubits are initialized to zero. However, the reset process is not perfect, leading to state preparation errors. To alleviate the error, the system also inserts repetition delay time (or rep_delay) between circuits. Each backend has a different default rep_delay, but it's usually longer than T1 to allow the environment to reset the qubits. The default rep_delay can be queried by running backend.default_rep_delay.

All IBM QPUs use dynamic repetition rate execution, which allows you to change the rep_delay for each job. Circuits you submit in a primitive job are batched together for execution on the QPU. These circuits are executed by iterating over the circuits for each shot requested; the execution is column-wise over a matrix of circuits and shots, as illustrated in the following figure.

The first column represents shot 0.  The circuits are run in order from 0 through 3.  The second column represents shot 1.  The circuits are run in order from 0 through 3.  The remaining columns follow the same pattern.
Column-wise execution matrix

Because rep_delay is inserted between circuits, each shot of the execution encounters this delay. Therefore, lowering the rep_delay decreases the total QPU execution time, but at the expense of increased state preparation error rate, as can be seen in the following image:

This image shows that as the rep_delay value is lowered, the state preparation error rate increases.
Repetition delay versus error rate

Note that while circuits in a primitive job are batched together for QPU execution, there is no guarantee on the order the circuits from PUBs are executed. Thus, even though you submit pubs=[pub1, pub2], there is no guarantee the circuits from pub1 will run before those from pub2. There is also no guarantee that circuits from the same job would run as a single batch on the QPU.


Specify rep_delay for a primitive job

from qiskit_ibm_runtime import QiskitRuntimeService, SamplerV2 as Sampler
 
service = QiskitRuntimeService()
 
# Make sure your backend supports it
backend = service.least_busy(operational=True, min_num_qubits=100, dynamic_reprate_enabled=True)
 
# Determine the allowable range
backend.rep_delay_range
sampler = Sampler(mode=backend)
 
#Specify a value in the supported range
sampler.options.execution.rep_delay = 0.0005

Next steps

Recommendations
Was this page helpful?
Report a bug or request content on GitHub.