Repeat until success¶

Circuit definition¶

For this tutorial, we will build an abstract circuit that uses the non-parametrized gate set to construct a heralded gate on a target qubit, where satisfies . This example is modified slightly from Nielsen and Chuang, Quantum Computation and Quantum Information, 10^th anniversary edition, exercise 4.41. Each iteration of the circuit only has a finite chance of success, but successes are heralded, so we will use our dynamic-circuit capabilities to repeat the setup until it succeeds.

Note: for real-world usage, it is better to insert the gates you want onto the circuit directly, and let Qiskit’s transpile function automatically synthesize them into a suitable basis for the target hardware. We are using this purely as an educational example.

We first initialize our circuit in Qiskit. We will create the probabalistic gate on one qubit, using two auxiliary controlling qubits, which we will measure throughout the execution of the circuit. We begin by creating separate quantum and classical registers for these components.

from qiskit import QuantumCircuit, QuantumRegister, ClassicalRegister

max_trials = 2

controls = QuantumRegister(2, name="control")
target = QuantumRegister(1, name="target")

mid_measure = ClassicalRegister(2, name="mid")
final_measure = ClassicalRegister(1, name="final")

base = QuantumCircuit(controls, target, mid_measure, final_measure)

A single trial of the probabalistic gate has the following form:

def trial(circuit, target, controls, measures):
    """Probabilistically perform an Rx gate for an
    angle that is an irrational multiple of pi."""
    circuit.h(target)
    circuit.h(controls)
    circuit.ccx(*controls, target)
    circuit.s(target)
    circuit.ccx(*controls, target)
    circuit.h(controls)
    circuit.h(target)
    circuit.measure(controls, measures)


example = base.copy_empty_like()
trial(example, target, controls, mid_measure)
example.draw("mpl", cregbundle=False)

If both measurements of the control bits return , the applied gate is with . If any of the measurements are , then the applied gate is simply , which is a failure. This is our heralding; we can tell from the measurement whether we applied the correct gate, without disturbing the coherence of the target qubit. Without fully reproducing the mathematics, the success probability of this gate is: $$

If there is a failure, we should reset the dirty state, and start again. Since we know what is applied in the case of a failure, we can use this knowledge to perform the reset efficiently, without using a general hardware reset. For the two auxiliary qubits, this is just an gate conditioned on its respective measurement being . IBM hardware has a special fast-path for when qubits are conditioned on the result of their own measurement, so this is more efficient than most control flow.

We can do this conditional measurement in Qiskit either with the older circuit.x(0).c_if(<condition>) form, or the newer with circuit.if_test(<condition>) form. For single operations like these, either will work for now, but it is beneficial to start adopting the new form, since the old form will eventually be deprecated, and the new one offers far more power when dealing with multiple operations, as we will see later. For now, the reset of the controls looks like this:

def reset_controls(circuit, controls, measures):
    """Reset the controlling qubits if they are in |1>."""
    with circuit.if_test((measures[0], True)):
        circuit.x(controls[0])
    with circuit.if_test((measures[1], True)):
        circuit.x(controls[1])


reset_controls(example, controls, mid_measure)
example.draw("mpl", cregbundle=False)

So far, we have drawn a dummy circuit, to show the intermediate steps. Let us now construct the whole circuit in one cell.

We now see the full power of the new-style with circuit.if_test blocks compared to the old c_if form. Not only can you include multiple operations in the same single-condition check, but you can also use the else branch. Right now, Qiskit can only represent very basic equality conditions. The backend is capable of significantly more than this, which you can test out by using the OpenQASM 3 string input forms discussed in the Dynamic circuits basics with OpenQASM 3 notebook.

Of note is that Qiskit cannot directly represent an inequality condition, which is what we require; we only need to do the repeat if the mid-circuit measurement result was not the bitstring "00". Instead, we can create an if statement with the condition mid_measure == "00", pass an empty block, and then use the else branch to perform the logic we want.

# Create a clean circuit with the same structure (bits, registers, etc)
# as the initial base we set up.
circuit = base.copy_empty_like()

# The first trial does not need to reset its inputs, since the controls
# are guaranteed to start in the |0> state.
trial(circuit, target, controls, mid_measure)

# Manually add the rest of the trials.  In the future, we will be
# able to use a dynamic `while` loop to do this, but for now, we
# statically add each loop iteration with a manual condition check
# on each one.  This involves more classical synchronizations than
# the while loop, but will suffice for now.
for _ in range(max_trials - 1):
    reset_controls(circuit, controls, mid_measure)
    with circuit.if_test((mid_measure, 0b00)) as else_:
        # This is the success path, but Qiskit can't directly
        # represent a negative condition yet, so we have an
        # empty `true` block in order to use the `else` branch.
        pass
    with else_:
        # First reset the target.
        circuit.x(target)
        # Then repeat the trial.
        trial(circuit, target, controls, mid_measure)

# We need to measure the control qubits again to ensure we
# get their final results; this is a hardware limitation.
circuit.measure(controls, mid_measure)

# Finally, let's measure our target, to check that we're
# getting the rotation we desired.
circuit.measure(target, final_measure)

circuit.draw("mpl", cregbundle=False)

Run on hardware¶

We have defined a relatively complicated circuit now, and one that contains three-qubit gates. This cannot run directly on our hardware; it must be “transpiled” by Qiskit into a form that only uses the basis gates of the underlying hardware and respects its connectivity.

First, we do the standard setup to retrieve a backend to run on.

from qiskit_ibm_provider import IBMProvider, least_busy

provider = IBMProvider()

hub = "<hub>"
group = "<group>"
project = "<project>"
hgp = f"{hub}/{group}/{project}"
backend_name = "<backend name>"

backend = provider.get_backend(backend_name, instance=hgp)
print(f"Using {backend.name}")

To prepare the circuit to run on real hardware, we use Qiskit’s transpile function. The defaults are all sensible, so it simply requires the input circuit and the target backend. All of Qiskit’s normal transpilation stages should work with the dynamic circuit: a suitable subset of the available qubits will be chosen; the input gates will all be translated into a basis that the hardware can actually run; the resulting two-qubit gates will be swap-mapped (routed) so that only physically linked qubits are interacted; and the resulting output undergoes some quantum optimizations to remove unnecessary gates and optimize the remaining ones.

By not specifying an optimization_level argument to transpile, we implicitly use level 1, which has light quantum optimization. For now, levels 2 and 3 do not support the dynamic circuits path; some of the optimizations used at those levels are not fully control-flow-aware. For our circuit, the difference is not especially large.

from qiskit import transpile

built = transpile(circuit, backend)
built.draw("mpl", cregbundle=False, idle_wires=False)

Now that we have built the circuit, we execute it on hardware by giving it to the backend’s run method. This returns a handle to an asynchronous job object. Calling its result method will block until the result is available, and then return it.

First, though, we can confirm, using Qiskit Aer, that we’re producing the results we expect to see. The preparation has a success probability of , and we repeat it up to max_trials times, so the probability of a successful result at the end is

1 - (1 - 5 / 8) ** max_trials

0.859375

Aer provides its own backend, which is capable of simulating the available basis gates in all active IBM devices, and can handle complex control flow. We build the simulator backend using AerSimulator, and then use the standard run method, which behaves the same as the real hardware. For demonstration purposes here, we do not load a noise model into the simulator, but use idealized operations.

from qiskit_aer import AerSimulator

sim = AerSimulator(method="statevector")
simulator_result = sim.run(built, shots=3000).result()
simulator_counts = simulator_result.get_counts()
simulator_counts

{'1 11': 141, '1 00': 505, '1 01': 154, '1 10': 136, '0 00': 2064}

A successful result is one in which the measurements on the two controls end in the 00 state. Let’s filter those out, and see how many successes will result. This is a type of post-selection. In the complete repeat-until-success circuit, with a dynamic while loop, we would not need this, as we would be guaranteed a success. However, in the interim, we can use the probabilities to examine the quality of the output, and verify that the probabilities are what we expect.

import collections


def marginalize_successes(counts):
    """Split the full output `counts` dictionary
    into two separate dictionaries, marginalizing
    the results to leave only the target qubit's
    state."""
    successes = collections.defaultdict(int)
    failures = collections.defaultdict(int)

    for key, value in counts.items():
        if key.endswith("00"):
            successes[key[0]] += value
        else:
            failures[key[0]] += value

    return successes, failures


sim_successes, sim_failures = marginalize_successes(simulator_counts)

# What percentage of the results were successful?
sum(sim_successes.values()) / sum(simulator_counts.values())

0.8563333333333333

This is consistent with what we expected to see, up to the statistical noise of the measurements. We can also verify the statistics of the target qubit state, post-selected for only the cases that have a heralded success.

The successful gate performs the operation

For an initial state of , the probability of measuring after the successful operation is

We can extract this directly from our marginalized counts.

sim_successes["1"] / sum(sim_successes.values())

0.19657454262358895

Again, up to statistical noise, this looks correct. Our circuit seems to be working, so let’s run it on actual hardware.

We already prepared our backend at the beginning of this section, in order to do the transpilation of circuit into built. All that is left is to run, using the familiar backend.run. When using dynamic-circuits capabilities, the keyword argument dynamic=True should be given, to exercise the correct paths.

# Recall that `built = transpile(circuit, backend)`.
job = backend.run(built, dynamic=True)
job.job_id()

'cggtvbg51vfr6fth4h5g'

hardware_counts = job.result().get_counts()
hardware_counts

{'0 00': 2225,
 '0 01': 169,
 '0 10': 239,
 '0 11': 138,
 '1 00': 635,
 '1 01': 168,
 '1 10': 288,
 '1 11': 138}

We can perform the same marginalization as before to check what percentage of shots resulted in a successful gate creation.

hw_successes, hw_failures = marginalize_successes(hardware_counts)

expected_successes = 1 - (1 - 5 / 8) ** max_trials
actual_successes = sum(hw_successes.values()) / sum(hardware_counts.values())
print(
    f"Expected success rate {expected_successes:5.3f}.  Actual rate {actual_successes:5.3f}."
)

Expected success rate 0.859.  Actual rate 0.715.

There is more noise than with Aer’s ideal simulator, but it’s still a good result, especially considering all the mid-circuit measurements and conditionals that we have applied in our circuit.

We can also test the post-selected output state:

actual_probability = hw_successes["1"] / sum(hw_successes.values())
print(f"Expected |1> probability: 0.2.  Actual probability {actual_probability:5.3f}.")

Expected |1> probability: 0.2.  Actual probability 0.222.

Final remarks¶

Our final circuit used mid-circuit measurements to do conditional resets and to repeat a trial setup several times, until it either succeeded or the maximum number of trials were exceeded. This involved several complex dynamic-circuit capabilities:

• Mid-circuit measurements

• Blocks of quantum operations conditioned on mid-circuit measurements

• Conditional measurements

• Simulation of all of the above

In the end, we were able to use the standard Qiskit workflow - transpile and backend.run - to prepare, compile, and execute a complex dynamic circuit on real hardware. We verified it with a simulation, and saw results that compare very favorably with what we expected!

Of course, this was a somewhat artificial example. Qiskit’s transpiler would have been able to exactly synthesize the one-qubit operation we were approximating if we had simply applied it and used the regular path. However, this is not always the case with more complex algorithms.

We also encountered a few limitations of the current stack, which we worked around:

• while loops are not fully supported in hardware (but will be soon!), so we hard-coded a finite number of repeats ourselves.

• Conditional measurement results can be used in execution, but are not reported back to the caller, so we had to add extra measurements to ensure we retrieved the results.

• Qiskit was unable to represent a negative condition directly, so we had to use an empty if block with a populated else block.

The IBM Quantum and Qiskit teams are currently working on solutions to these limitations.

import qiskit.tools.jupyter

%qiskit_version_table