No backends use fixed rate (#3057)

closes #3005

---------

Co-authored-by: Frank Harkins <[email protected]>

Author: beckykd

docs/guides/_toc.json

@@ -584,7 +584,7 @@
               "url": "/docs/guides/native-gates"
             },
             {
-              "title": "Fixed and dynamic repetition rate execution",
+              "title": "Dynamic repetition rate execution",
               "url": "/docs/guides/repetition-rate-execution"
             },
             {

docs/guides/dynamic-circuits-considerations.ipynb

@@ -65,7 +65,7 @@
     "  - **Insert `qc.delay()` after measurements:** Add a delay instruction between measurements within a circuit to give the system time to stream results and prevent the buffer from filling.\n",
     "  **Note:** this approach increases the circuit duration, which might reduce shot quality due to qubit decoherence.\n",
     "\n",
-    "  For more information, see the [Fixed and dynamic repetition rate execution](/docs/guides/repetition-rate-execution) guide, which explains dynamic repetition rate execution and how to set `rep_delay`."
+    "  For more information, see the [Dynamic repetition rate execution](/docs/guides/repetition-rate-execution) guide."
    ]
   }
  ],

docs/guides/execute-on-hardware.mdx

@@ -74,7 +74,7 @@ expectation values of observables corresponding to physical quantities or cost f
 * [Calibration jobs](./calibration-jobs)
 * [Get QPU information with Qiskit](./get-qpu-information)
 * [Native gates and operations](./native-gates)
-* [Fixed and dynamic repetition rate execution](./repetition-rate-execution)
+* [Dynamic repetition rate execution](./repetition-rate-execution)
 * [Retired QPUs](./retired-qpus)
 * [Hardware considerations and limitations for classical feedforward and control flow](./dynamic-circuits-considerations)
 * [Instances](./instances)
@@ -88,7 +88,7 @@ expectation values of observables corresponding to physical quantities or cost f
 * [QPU information](./qpu-information)
 * [Get QPU information with Qiskit](./get-qpu-information)
 * [Native gates and operations](./native-gates)
-* [Fixed and dynamic repetition rate execution](./repetition-rate-execution)
+* [Dynamic repetition rate execution](./repetition-rate-execution)
 * [Retired QPUs](./retired-qpus)
 * [Hardware considerations and limitations for classical feedforward and control flow](./dynamic-circuits-considerations)
 * [Instances](./instances)

docs/guides/repetition-rate-execution.mdx

@@ -1,32 +1,24 @@
 ---
-title: Fixed and dynamic repetition rate execution
-description: Explanatory content on fixed and dynamic repetition rate execution
+title: Dynamic repetition rate execution
+description: Explanatory content about dynamic repetition rate execution
 
 ---
 
-# Fixed and dynamic repetition rate execution
+# Dynamic repetition rate execution
 
-## Fixed 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`.
 
-Most IBM® quantum processing units (QPUs) execute circuits at a fixed rate. Although this *repetition rate* varies by QPU, the underlying execution model is the same, and is described here. First, consider three circuits sent to a QPU using separate jobs, one for each circuit. The example below shows what happens for jobs of varying lengths. Because of the fixed repetition rate, there is a variable amount of *idle time* that occurs before the start of a circuit in order to make the entire duration match that given by the QPU repetition rate.
-
-![With fixed-rate execution, shorter jobs result in longer idle time.](/docs/images/guides/repetition-rate-execution/fixed_single_circuit1.avif "Idle time versus job length")
-
-The situation changes somewhat when the same circuits are batched into a single job. In this case the circuits included in the job are executed by iterating over the circuits for each shot requested; the execution is column-wise over a matrix of circuits and shots (see below).
+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. ](/docs/images/guides/repetition-rate-execution/circuits_shots_matrix1.avif "Column-wise execution matrix")
 
-Matrix of four circuits in a job showing the execution pattern over the circuits.
-
-When submitting batches of circuits to QPUs, the circuits are executed differently than they would be if executed separately. Namely, the initialization of the circuit, that is, prepare the ground state, and measurements (if any) are aligned over all circuits.
 
-![The image shows three circuits.  Although they are different lengths, they take the same amount of time to complete because they were submitted in a batch.](/docs/images/guides/repetition-rate-execution/fixed_batch_circuit1.avif)
+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:
 
-Therefore, each circuit is equal in duration to the longest circuit in the batch, and there is a common idle time that is placed in front of all circuits to match the repetition rate.
+![This image shows that as the `rep_delay` value is lowered, the state preparation error rate increases.](/docs/images/guides/repetition-rate-execution/rep_delay.avif "Repetition delay versus error rate")
 
-## Dynamic repetition rate execution
 
-Some IBM QPUs allow for dynamic repetition rate execution. These QPUs are identified in Qiskit using `backend.configuration().dynamic_reprate_enabled`, and return a value of `True`. On these QPUs, it is possible to manually set the above idle time by setting the `rep_delay` of the submitted job. One can see from the above figures that by reducing the idle time one can potentially see a greater throughput of circuits on the QPUs that support dynamic repetition rates.
+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