Quantum Hardware Execution

11.1 Execution Setup

We take the Bell circuit, which we have tested locally. A local simulation and a hardware run of it make different claims: the first predicts what an ideal model does, while the second reports what a particular device did at a particular time. Before any submission we must decide which device to use, how to prove we may use it, and what form of circuit it accepts. We take the device and the account first, then the circuit.

11.1.1 Backend selection and credentials

Which backend can run our circuit? It needs at least as many qubits as the circuit, and it must support the circuit’s instructions and any classical control the circuit uses. Using it also requires an account, identified by a secret token. Where should that token live? Never in a source file, since source files are shared and stored in version histories. Qiskit Runtime saves the account separately on our computer, and QiskitRuntimeService() reads it from there.

A harder question is how to make spending execution time impossible by accident. A script that submitted a job whenever it ran would do so every time someone ran the course checks. So the companion compiles locally by default, and it submits only when the user types two options on the command line: python chapter_11.py --submit --backend NAME.

Python’s standard module argparse reads such options. Each add_argument line declares one. action="store_true" makes --submit a switch, true when present and false otherwise. parse_args() reads what the user typed, and parser.error stops the program with a message if --submit comes without a backend name.

One more guard matters. Another program may import this file to reuse its build function. Python sets the variable __name__ to "__main__" only when a file is run directly, so the block under if __name__ == "__main__": never runs on import. Importing the file therefore never submits, and neither does importing the Runtime package.

11.1.2 Executable circuits and mapped observables

What form must the circuit take before the backend accepts it? IBM’s devices accept only circuits already written in the backend’s native instructions, on its physical qubits, respecting its connections. Such a circuit is called an ISA circuit, after the backend’s instruction set architecture, its list of native instructions. Producing one is what our pass manager did for the toy line. Here generate_preset_pass_manager(backend=backend, …) reads the native gates and connections from the backend’s own target.

For local runs, the companion uses GenericBackendV2(2, seed=3), an invented two-qubit backend with realistic native gates, rz, sx, x and cx. Compiling for it turns H into Z rotations and a \(\sqrt X\), as before, and the measured Bell circuit needs one CNOT.

Compilation also moves qubits, and that affects observables. Suppose we use an Estimator to ask for \(\langle ZZ\rangle\) on logical qubits 0 and 1, and the layout places them on physical qubits 5 and 6 of a large device. The observable must then act on 5 and 6. observable.apply_layout(compiled.layout) rewrites it accordingly. A Sampler needs no such step, because the measurements are part of the compiled circuit and still write to the bits we chose.

11.2 Runtime Workloads

With an ISA circuit and a backend, the next step uses real execution time. What happens when we submit, how do we find our job again, and how do we keep the cost under control? We follow a single submission first, then consider how groups of jobs are organized and paid for.

11.2.1 Submitting and retrieving jobs

What does a submission look like in code? SamplerV2 from Runtime is the remote counterpart of the local sampler we already know. Its input mode=backend says where its jobs run. Calling run sends the PUBs and returns a job at once, while the work may still wait in a queue. job.job_id() is a string that identifies the job. We print or save it immediately, so that a later program can retrieve the result even if this one stops. job.result() waits for the result, and we read the counts exactly as before.

This branch uses a separately configured account. It was checked against the Runtime documentation but not run on hardware for this course.

11.2.2 Execution modes and budgets

Suppose a program sends many related jobs, as an optimization loop does. Must each one wait in the queue separately? The mode decides. In job mode, which our companion uses, each job is queued on its own. A session reserves a window on one device, so the jobs of an iterative program run one after another without queuing again. A batch submits a group of independent jobs together, so the service can schedule them efficiently. Which modes are available, and how they are charged, depends on the service and the account.

What will a submission cost? We estimate it before submitting, from the number of circuits, the shots, and the expected time on the device. No fixed free allowance should be assumed. A one-line statement can launch a large amount of work, so the explicit submission boundary stays visible in any code we share.

11.3 Result Analysis

When counts come back from hardware, what can we claim from them? Two things limit the claim. We can compare a run only with what we recorded about it, and we can compare it with our prediction only after separating sampling fluctuation from device error. We take the record first, then the comparison.

11.3.1 Metadata and provenance

Suppose we rerun the job a month later and the counts differ. Is that a bug, or the device? Without a record we cannot tell. Devices are recalibrated often, and their errors drift, so the same source circuit can give different results at different times.

So we save the history of the result, its provenance: the backend name, the time of execution, the package versions, the compiled circuit and its layout, the shots, the options, and the metadata the service returns. The compiled circuit matters most, because it is what actually ran. A table of counts without these facts cannot be compared reliably with another run.

11.3.2 Simulation, hardware, and uncertainty

How should hardware counts be compared with our prediction? The ideal Bell state gives 00 and 11 with probability one half each, and never 01 or 10. Sampling alone moves the frequency of 00 by a standard error of \(\sqrt{0.25/1024}=1/64\approx0.016\) at 1024 shots. But sampling can never produce 01 or 10 from the ideal state. So if those strings appear, the cause is the device, not the finite number of shots. Telling apart the kinds of device error is a question we take up with noise.

The companion’s local path compiles for the invented backend and prints the compiled gate counts: two Z rotations, one \(\sqrt X\), one CNOT, the two measurements and a barrier. The remote path compiles for the chosen backend, submits 1024 shots, prints the job identifier and then the counts. Only the local path runs in the automated checks.

"""Runnable companion for Quantum Programming, Chapter 11."""
import argparse
from qiskit import QuantumCircuit
from qiskit.transpiler import generate_preset_pass_manager
from qiskit.providers.fake_provider import GenericBackendV2
from qiskit_ibm_runtime import QiskitRuntimeService, SamplerV2

def build(backend):
    circuit = QuantumCircuit(2)
    circuit.h(0); circuit.cx(0, 1); circuit.measure_all()
    return generate_preset_pass_manager(backend=backend, optimization_level=1,
                                        seed_transpiler=17).run(circuit)

if __name__ == "__main__":
    parser = argparse.ArgumentParser()
    parser.add_argument("--submit", action="store_true", help="Explicitly submit a paid/allocated hardware job")
    parser.add_argument("--backend", help="Exact accessible hardware backend name")
    args = parser.parse_args()
    if not args.submit:
        compiled = build(GenericBackendV2(2, seed=3))
        print("Local compilation only; no account accessed and no job submitted.")
        print(compiled.count_ops())
    else:
        if not args.backend:
            parser.error("--backend is required with --submit")
        service = QiskitRuntimeService()  # Uses a separately configured account.
        backend = service.backend(args.backend)
        compiled = build(backend)
        job = SamplerV2(mode=backend).run([compiled], shots=1024)
        print("Submitted job:", job.job_id())
        print(job.result()[0].data.meas.get_counts())

Companion script: chapter_11.py.

All our circuits so far measured only at the end. Some hardware can measure a qubit partway through a circuit and act on the result before the circuit finishes. How can a measurement change the remaining computation?

Sources and further study: IBM, Runtime SamplerV2.