Deel 5 van de reeks Van quarks tot quantumvoordeel

Het circuit uit deel 4 is nog een ideale unitaire bewerking. Een echte quantumsimulatie vraagt meer: een fysieke qubitketen kiezen, het circuit naar native gates compileren, veel shots verzamelen, meetfouten karakteriseren en de bits terugvertalen naar LSH-observabelen. Juist in die laatste stap kan een ogenschijnlijk klein conventieverschil het hele ruimtelijke profiel omkeren.

Dit deel behandelt twee uitvoeringslagen. Eerst reconstrueren we de route van de paper op IBM Boston met 10.000 shots per tijdpunt. Daarna bekijken we onze lokale reproductieroute via de zelfstandige Fire Opal-API op ibm_fez, met 512 shots voor Trotterstappen 5, 10, 15 en 20.

De tweede route is bewust een smoke test. Zij bewijst dat de gedownloade 120-qubitcircuits kunnen worden voorbereid, uitgevoerd, opgehaald en gedecodeerd. Zij heeft nog niet dezelfde statistiek of exact dezelfde observable-normalisatie als de paper.

Eén tijdstip is één nieuw circuit

De paper gebruikt digitale Trotterisatie. Voor tijdstap (t) wordt een circuit met (t) herhaalde Trotterblokken voorbereid. Een meting vernietigt de quantumtoestand, zodat het volgende tijdstip niet simpelweg verder kan gaan met de reeds gemeten toestand. Voor ieder gewenst tijdpunt wordt een nieuw circuit vanaf de initial state uitgevoerd.

Bovendien zijn er twee initial states:

• het strong-coupling vacuum, SCV;
• hetzelfde vacuüm met een centraal meson.

Voor één datapunt \(\Delta n_f(r,t)\) zijn dus minstens twee circuitfamilies nodig. Beide worden op alle 120 qubits in de Z-basis gemeten. Met 10.000 shots per circuitdiepte bouwt de paper voor iedere qubit een schatting van

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

Die bezettingskans wordt vervolgens geïnterpreteerd als \(n_i(r)\) of \(n_o(r)\), afhankelijk van de logische mapping.

Van 120 bits naar een lokaal profiel

De gedeclareerde eindmapping is

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

Voor even sites is \(n_f=n_i+n_o\); voor oneven sites is \(n_f=2-(n_i+n_o)\). Daarna worden de globale controles berekend:

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

Voor de bedoelde sector zijn \(Q=60\) en \(q=0\). Deze twee getallen zijn ongevoelig voor veel details van de ruimtelijke sitekoppeling. Dat maakt ze geschikt als eerste controle van bitvolgorde en symmetriebehoud, maar niet als vervanging voor het lokale mesonsignaal.

De laatste stap is de vacuümaftrekking:

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

De paper maakt van deze siteafhankelijke waarden een ruimtetijdheatmap en leidt er ook globale of centraal gewogen scalars uit af. De precieze som, middeling, sitekeuze en staggered tekens moeten gelijk zijn voordat twee gereduceerde scalars numeriek kunnen worden vergeleken.

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

De paperroute op IBM Boston

IBM Boston is een 156-qubit Heron r3-processor. Het algoritme gebruikt daarvan een verbonden keten van 120 fysieke qubits. De logische circuitgraaf is zelf lineair, zodat de transpiler volgens de paper geen extra routerings-SWAPs hoeft toe te voegen. Hij selecteert een relatief ruisarme keten en ontbindt de logische gates naar de native hardwaregates.

De paper gebruikt een vaste 10.000-shotbudget per geëvalueerde Trotterdiepte en een readout-error-mitigationmethode. Bij stap 20 is de tweequbitdiepte 259. De tracker rapporteert voor dat punt een globale QPU-lading van 59,99402699 in de bedoelde \(Q=60\)-sector. De absolute afwijking is ongeveer 0,00597.

Het hadronsignaal is niet dat ene ladingsgetal. De tracker geeft daarnaast \(n_f(20)=-0,07723426024\), terwijl de paper de volledige ruimtelijke \(\Delta n_f(r,t)\)-structuur en de breathing frequency bespreekt. De globale lading controleert vooral of de uitgelezen evolutie de juiste sector benadert.

Onze zelfstandige Fire Opal-route

In dit project gebruiken we Fire Opal als losse API en niet als een Qiskit Function. De runner leest de oorspronkelijke QASM, laat die bronbestanden ongemoeid en schrijft uitvoeringskopieën met een klassiek register en meting van alle 120 qubits.

De run bestaat uit twee groepen:

1. main: SCV- en mesoncircuits voor de gekozen Trotterstappen;
2. readout: een volledig nul- en volledig één-circuit voor lokale meetkalibratie.

Fire Opal verzorgt de service- en backendroute. De eenvoudige readoutcorrectie die in onze tabellen staat, wordt daarna lokaal door hadron_observable_analyzer.py uitgevoerd. Dat onderscheid voorkomt dat we een lokaal correctiemodel ten onrechte als eigenschap van de Fire Opal-service presenteren.

Alle vier main-circuitsmokes zijn succesvol afgerond op ibm_fez. De belangrijkste samenvatting is:

stap	bron	ruwe lokale Delta n_f-scalar	readout-gecorrigeerd	hardwaretijd main	diepte
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

De dieptes zijn de waarden uit de lokale voorbereidingsmetadata. Zij kunnen afwijken van de paperdiepte 259, omdat bron-QASM, optimalisatie en gerapporteerde dieptedefinitie niet noodzakelijk identiek zijn.

Wat de lokale readoutcorrectie doet

Het all-0-circuit schat per qubit de kans \(p_{01}\) dat een voorbereide nul als één wordt gelezen. Het all-1-circuit schat \(p_{10}\), de kans dat een één als nul wordt gelezen. Onder een onafhankelijk, stationair bitflipmodel geldt

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

Die inverse corrigeert een systematische readoutbias, maar vergroot ook ruis wanneer de noemer klein of de calibratieschatting onzeker is. Zij modelleert geen gecorreleerde readoutfouten, gatefouten, decoherentie of drift tussen calibratie en main-circuits.

Onze 512-shotresultaten laten precies zien waarom gecorrigeerd niet automatisch beter betekent. De maximale ruwe afwijking van de globale lading over SCV en meson bedraagt per stap ongeveer 0,41, 0,63, 0,39 en 0,71. Na de lokale correctie worden de maxima ongeveer 0,69, 1,10, 0,82 en 1,16. Op deze kleine shotbudgetten versterkt de correctie dus de ladingsdrift.

Dat kan komen door statistische onzekerheid, een te eenvoudig onafhankelijk readoutmodel of calibratiedrift. Het is geen bewijs dat readoutmitigatie in het algemeen schadelijk is. Het zegt wel dat de ruwe data voor deze smoke momenteel de betere symmetriesanitycheck vormen.

512 shots zijn geen 10.000 shots

Voor een eenvoudige Bernoulli-observabele daalt de statistische standaardfout ongeveer als \(1/\sqrt{M}\), met \(M\) het aantal shots. De paper gebruikt per tijdpunt 19,53125 keer zoveel shots als onze smoke. De verwachte statistische ruis is daardoor ruwweg

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

keer kleiner, zolang correlaties en systeemfouten buiten beschouwing blijven.

De uitvoertijd schaalt in eerste benadering lineair met het aantal shots. Onze 2,768896 hardwareseconden voor stap 20 zouden dan ongeveer 54,08 seconden bij 10.000 shots worden. Dat is een extrapolatie, geen uitgevoerde 10.000-shotrun.

Hardwaretijd is niet de wachttijd

De lokale hardwaretijd is berekend als Fire Opals estimated_duration per shot maal het shotcount. De eenheid microseconden per shot is in dit project afgeleid uit de readoutduur en moet als aanname zichtbaar blijven.

Deze tijd sluit queueing, upload, compilatie, serviceverwerking, ophalen en lokale decoding uit. Voor de stap-5-run was de main action wall time 133 seconden en de readout action 95 seconden. De gecombineerde main action voor stappen 10, 15 en 20 duurde 304 seconden; de readout action 176 seconden. Die wall times horen bij groepen circuits en zijn niet één-op-één aan een enkel tijdpunt toe te wijzen.

Voor fysische throughput kan hardware-only een nuttige grootheid zijn. Voor wat een gebruiker werkelijk ervaart, is end-to-end tijd relevanter. Deel 7 zal beide perspectieven gescheiden houden.

Waarom onze scalar nog niet over de tracker mag

De tekens en getallen in de lokale tabel lijken uitnodigend om direct naast de trackerreeks te zetten. Dat zou methodologisch fout zijn. Onze scalar is een lokale, staggered SCV-versus-mesondifferentie die door de analyzer uit het gemeten QASM wordt gesommeerd. De trackerwaarde \(n_f(t)\) gebruikt de paperdefinitie en normalisatie.

Zonder exact dezelfde siteweging, middeling en achtergrondconventie is het verschil tussen bijvoorbeeld -0,3867 en -0,0772 geen fysische foutmaat. De globale lading kan al wel worden vergeleken, omdat haar definitie expliciet en mappingrobuust is. De lokale scalar wordt pas een strikte reproductietest nadat de paper-normalisatie in de analyzer is geïmplementeerd.

Wat is hier aangetoond?

De publieke 120-qubitcircuits kunnen via de zelfstandige Fire Opal-route op ibm_fez worden uitgevoerd en volledig worden gedecodeerd. De actionstatussen zijn succesvol, de hardwaretijd groeit met de circuitdiepte en de ruwe globale lading blijft op 512 shots herkenbaar rond de bedoelde sector.

Wat is nog niet aangetoond?

De lokale smoke reproduceert nog niet de papercurve of breathing frequency met gelijke statistiek. De gecorrigeerde data zijn niet aantoonbaar beter dan de ruwe data, de hardwaretijd is geen end-to-end tijd en de lokale scalar is niet de paper-genormaliseerde \(n_f(t)\).

In deel 6 verschuift de vraag van hardware naar klassieke simulatie. We bekijken welke route de volledige Hamiltoniaan simuleert, welke alleen het circuit volgt en waarom geen enkele klassieke tijd zonder die taakdefinitie betekenis heeft.

Bronnen

1. Fran Ilčić et al., paper v3, hoofdtekst en Methods.
2. Fire Opal-route en uitvoergrenzen.
3. Fire Opal-stappensamenvatting.
4. Lokale observable-analyzer.
5. E. van den Berg, Z. K. Minev en K. Temme, Model-free readout-error mitigation for quantum expectation values.
6. Bronnen- en notatiedossier.