Quantum simulation and Fire Opal

Part 5 of the series From quarks to quantum advantage

The circuit from part 4 is another ideal unitary operation. A real quantum simulation requires more: choosing a physical qubit chain, compiling the circuit to native gates, collecting many shots, characterizing measurement errors and translating the bits back to LSH observables. It is precisely in that last step that a seemingly small convention difference can reverse the entire spatial profile.

This section covers two layers of implementation. First, we reconstruct the paper's route on IBM Boston with 10,000 shots per time point. We then look at our local reproduction route via the standalone Fire Opal API at ibm_fez, with 512 shots for Trotter steps 5, 10, 15 and 20.

The second route is deliberately a smoke test. It proves that the downloaded 120-qubit circuits can be prepared, executed, retrieved and decoded. It does not yet have the same statistics or exactly the same observable normalization as the paper.

One point in time is one new circuit

The paper uses digital Trotterization. For time step (t), a circuit with (t) repeated Trotter blocks is prepared. A measurement destroys the quantum state, so that the next time point cannot simply continue with the state already measured. For each desired time point, a new circuit is executed from the initial state.

In addition, there are two initial states:

• the strong-coupling vacuum, SCV;
• the same vacuum with a central meson.

Therefore, at least two circuit families are required for one data point \(\Delta n_f(r,t)\). Both are measured on all 120 qubits in the Z-base. With 10,000 shots per circuit depth, the paper builds an estimate of for each qubit

\[
P(1)=\frac{1-\langle Z\rangle}{2}.
\]

That occupancy probability is then interpreted as \(n_i(r)\) or \(n_o(r)\), depending on the logical mapping.

From 120 bits to a local profile

The declared final mapping is

q[2*r]   = n_i(r)
q[2*r+1] = n_o(r)

For even sites, \(n_f=n_i+n_o\); for odd sites is \(n_f=2-(n_i+n_o)\). Then the global checks are calculated:

\[
Q=\sum_r[n_i(r)+n_o(r)],
\qquad
q=\sum_r[n_o(r)-n_i(r)].
\]

For the targeted sector are \(Q=60\) and \(q=0\). These two numbers are insensitive to many details of the spatial site association. This makes them suitable as a first check of bit order and symmetry maintenance, but not as a replacement for the local meson signal.

The last step is the vacuum subtraction:

\[
\Delta n_f(r,t)=n_f^{\mathrm{meson}}(r,t)
-n_f^{\mathrm{SCV}}(r,t).
\]

The paper creates a spacetime heatmap from these site-dependent values ​​and also derives global or centrally weighted scalars from them. The precise sum, averaging, site selection, and staggered signs must be equal before two reduced scalars can be numerically compared.

flowchart LR
    A["SCV-QASM"] --> C["Fire Opal / IBM backend"]
    B["meson-QASM"] --> C
    R["all-0 and all-1 calibration"] --> C
    C --> D["counts per circuit"]
    D --> E["Z values and occupation probabilities"]
    E --> F["n_i, n_o, n_f, Q and q"]
    F --> G["meson minus SCV"]

The paper route at IBM Boston

IBM Boston is a 156-qubit Heron r3 processor. The algorithm uses a connected chain of 120 physical qubits. The logic circuit graph itself is linear, so the transpiler does not need to add additional routing SWAPs, according to the paper. It selects a relatively low-noise chain and decomposes the logic gates to the native hardware gates.

The paper uses a fixed 10,000-shot budget per evaluated Trotter depth and a readout error mitigation method. At step 20, the two-qubit depth is 259. The tracker reports a global QPU charge of 59.99402699 in the targeted \(Q=60\) sector for that point. The absolute deviation is approximately 0.00597.

The hadron signal is not that one charge. The tracker also provides \(n_f(20)=-0,07723426024\), while the paper discusses the full spatial \(\Delta n_f(r,t)\) structure and the breathing frequency. The global load mainly checks whether the selected evolution approaches the correct sector.

Our independent Fire Opal route

In this project we use Fire Opal as a separate API and not as a Qiskit Function. The runner reads the original QASM, leaves those source files intact, and writes execution copies with a classical register and measurement of all 120 qubits.

The run consists of two groups:

1. main: SCV and meson circuits for the chosen Trotter steps;
2. readout: A full zero and full one circuit for local measurement calibration.

Fire Opal takes care of the service and backend route. The simple readout correction shown in our tables is then performed locally by hadron_observable_analyzer.py. This distinction prevents us from incorrectly presenting a local correction model as a feature of the Fire Opal service.

All four main circuit smokes completed successfully at ibm_fez. The main summary is:

step	source	raw local Delta n_f scalar	readout-corrected	hardware time main	depth
5	LSH-IBM	-0.751953	-0.764251	0.987136 s	66
10	LSH-IBM	0.324219	0.334835	1.581056 s	125
15	LSH-IBM	-0.068359	-0.054407	2.174976 s	177
20	tracker-QASM	-0.386719	-0.389997	2.768896 s	237

The depths are the values ​​from the local preparation metadata. They may differ from the paper depth 259 because source QASM, optimization and reported depth definition are not necessarily identical.

What the local readout correction does

The all-0 circuit estimates per qubit the probability \(p_{01}\) that a prepared zero is read as one. The all-1 circuit estimates \(p_{10}\), the probability that a one is read as zero. Under an independent, stationary bit flip model,

\[
Z_{\mathrm{true}}
=\frac{Z_{\mathrm{obs}}-(p_{10}-p_{01})}
{1-p_{01}-p_{10}}.
\]

This inverse corrects a systematic readout bias, but also increases noise when the denominator is small or the calibration estimate is uncertain. It does not model correlated readout errors, gate errors, decoherence or drift between calibration and main circuits.

Our 512-shot results show exactly why corrected doesn't automatically mean better. The maximum raw deviation of the global charge over SCV and meson is approximately 0.41, 0.63, 0.39 and 0.71 per step. After the local correction the maximums become approximately 0.69, 1.10, 0.82 and 1.16. On these small shot budgets, the correction therefore increases the charge drift.

This may be due to statistical uncertainty, an independent readout model that is too simple or calibration drift. It is not evidence that readout mitigation is generally harmful. It does say that the raw data for this smoke currently provides the better symmetry sanity check.

512 shots are not 10,000 shots

For a simple Bernoulli observable, the statistical standard error falls approximately as \(1/\sqrt{M}\), with \(M\) the number of shots. The paper uses 19.53125 times as many shots per time point as our smoke. The expected statistical noise is therefore rough

\[
\sqrt{10000/512}\approx4.42
\]

times smaller, as long as correlations and system errors are not taken into account.

To a first approximation, the execution time scales linearly with the number of shots. Our 2.768896 hardware seconds for step 20 would then become approximately 54.08 seconds for 10,000 shots. That's an extrapolation, not an executed 10,000-shot run.

Hardware time is not the waiting time

The local hardware time is calculated as Fire Opals estimated_duration per shot times the shot count. The unit microseconds per shot in this project is derived from the readout duration and must remain visible as an assumption.

This time excludes queuing, uploading, compilation, service processing, fetching and local decoding. For the step-5 run, the main action wall time was 133 seconds and the readout action was 95 seconds. The combined main action for steps 10, 15 and 20 lasted 304 seconds; the readout action 176 seconds. These wall times belong to groups of circuits and cannot be assigned one-to-one to a single time point.

For physical throughput, hardware-only can be a useful quantity. For what a user actually experiences, end-to-end time is more relevant. Part 7 will keep both perspectives separate.

Why our scalar cannot yet be compared directly with the tracker

The signs and values in the local table seem inviting to place right next to the tracker string. That would be methodologically wrong. Our scalar is a local, staggered SCV versus meson difference that is summed from the measured QASM by the analyzer. The tracker value \(n_f(t)\) uses the paper definition and normalization.

Without exactly the same site weighting, averaging and background convention, the difference between, for example, -0.3867 and -0.0772 is not a physical error measure. The global charge can already be compared, because its definition is explicit and mapping robust. The local scalar only becomes a strict reproduction test after the paper normalization is implemented in the analyzer.

What has been demonstrated here?

The public 120-qubit circuits can be run via the standalone Fire Opal route on ibm_fez and fully decoded. The action states are successful, the hardware time grows with the circuit depth and the raw global charge remains recognizable around the intended sector on 512 shots.

What has not yet been proven?

The local smoke does not yet reproduce the paper curve or breathing frequency with the same statistics. The corrected data is not demonstrably better than the raw data, the hardware time is not end-to-end time and the local scalar is not the paper-normalized \(n_f(t)\).

In part 6, the question shifts from hardware to classical simulation. We look at which route simulates the full Hamiltonian, which just follows the circuit, and why no classical time without that task definition is meaningful.

Sources

1. Fran Ilčić et al., paper v3, main text and Methods.
2. Fire Opal Route and Output Boundaries.
3. Fire Opal Step Summary.
4. Local Observable Analyzer.
5. E. van den Berg, Z. K. Minev and K. Temme, Model-free readout-error mitigation for quantum expectation values.
6. Hadron repository and reproducibility notes.