Edukaizen

Menu
  • Nieuws
  • Hubbard 1D
    • Part 1: 1D Hubbard model
    • Part 2: Snake layout and fSWAP
    • Part 3: Qiskit and Fire Opal
    • Part 4: 120-qubit run
    • Part 5: Time-to-answer
    • Part 6: Tensor networks
    • Part 7: Majorana propagation
    • Part 8: Heatmaps
    • Part 9: 2D Hubbard outlook
    • Part 10: Quantum computer as a lab
    • Part 11: Official Monoprop benchmark
  • Hubbard 2D
    • Part 1: 1D to 2D
    • Part 2: Cuprates
    • Part 3: 3×3
    • Part 4: Time
    • Part 5: 4×4
    • Part 6: 6×6 Fez
  • Hadron
    • Deel 1: Hadron op quantumprocessor
    • Deel 2: Quarks en confinement
    • Deel 3: SU(2) en LSH
    • Deel 4: Hamiltoniaan en circuit
    • Deel 5: Fire Opal
    • Deel 6: Klassieke simulaties
    • Deel 7: Quantumvoordeel
  • Black Hole OLE
    • Part 1: What we ran
    • Part 2: How OLE works
    • Part 3: Fire Opal and Kingston
    • Part 4: The tensor-network challenge
    • Part 5: Hawking and scrambling
    • Part 6: What the result proves
    • Part 7: Local toy model
    • Part 8: QGSS26 compatibility
  • Random Graph
    • Start here
    • Part 1: Theory
    • Part 2: Circuit
    • Part 3: Qiskit
    • Part 4: Complexity
    • Part 5: Verification
    • Part 6: Workflow
    • Part 7: Conclusion
  • QOS QML
    • Nederlands
    • English
    • Beginnershandleiding 4q
  • Advantage List
Menu

Fermi-Hubbard op een quantumcomputer, deel 11: de officiële Monoprop-benchmark

Posted on August 1, 2026August 1, 2026 by admin
Nederlands | English | Projectpagina | Vorige

Een upstream-implementatie verandert de klassieke vergelijking

Deel 7 van deze serie introduceerde Majorana propagation als klassieke concurrent voor een gate-based Fermi-Hubbardsimulatie. Die eerste vergelijking gebruikte onze eigen EduKaizen-implementatie. We kunnen de berekening nu herhalen met Monoprop, Algorithmiqs officiële high-performance implementatie van Majorana- en Pauli-propagatie.

Dat onderscheid is belangrijk. Twee programma’s kunnen allebei het label “Majorana propagation” gebruiken en toch andere coëfficiëntdrempels, termlimieten, operatorrepresentaties en uitvoeringsstrategieën toepassen. Een runtime van één implementatie is niet automatisch een benchmark van de hele methode.

Dezelfde observable

De eerdere snelle Monoprop-tutorial propageerde één lokale occupation-operator. Dat duurde ongeveer één seconde, maar was niet vergelijkbaar met de EduKaizen-benchmark. EduKaizen berekende de gemiddelde dubbele bezetting over alle 60 sites:

\[D=\frac{1}{60}\sum_{i=1}^{60}\left\langle n_{i,\uparrow}n_{i,\downarrow}\right\rangle.\]

Deze observable bevat 60 lokale quartische termen. We bouwden hem daarom als één Monoprop-FermiOperator en propageerden hem door hetzelfde circuit met 60 sites, 120 modes en 30 stappen als in de bestaande vergelijking. De parameters waren U=-2, dt=0.2 en eindtijd t=6. De run gebruikte Monoprop 0.8.0 onder Python 3.12 in WSL2. Het was de standaard single-process Python-wheel, geen MPI-build.

Voor de volledige run is de constructie op vier sites zonder truncatie gecontroleerd. Eén gecombineerde gemiddelde operator en het gemiddelde van vier afzonderlijk gepropageerde lokale operatoren kwamen overeen tot op 2,78e-17.

Het resultaat

Methode Gemiddelde dubbele bezetting Gemeten tijd Absolute afwijking van MPS chi256
Lokale Fire Opal, readout-corrected 0,2306772151 33,15 s uitvoeringsproxy 0,0215794919
Monoprop 0.8.0, cutoff 4, lower_atol=1e-8 0,1976589194 234,03 s 0,0114388037
EduKaizen Majorana, cutoff 4 0,2086139231 1.153,51 s 0,0004838001
MPS chi256 0,2090977231 9.033 s referentie

De officiële Monoprop-run is ongeveer 4,93x sneller dan EduKaizen cutoff 4 en 38,60x sneller dan de geregistreerde MPS chi256-run. Hij is ook 7,06x trager dan de lokale Fire Opal-uitvoeringsproxy met 4.096 shots.

De tijdsvolgorde is voor deze runs dus duidelijk: eerst de lokale quantumuitvoering, daarna Monoprop, vervolgens EduKaizen Majorana propagation en tot slot MPS chi256. De nauwkeurigheidsvolgorde ten opzichte van chi256 is anders. EduKaizen ligt het dichtst bij de referentie, Monoprop volgt en de lokale readout-corrected hardwarewaarde wijkt het meest af.

Waarom de snelste Monoprop-instelling niet voldoende is

Met de tutorialdrempel lower_atol=1e-4 voltooide Monoprop dezelfde observable in slechts 2,40 s. De uitkomst was echter 0,2502868623, met een absolute afwijking van ongeveer 0,04119 van chi256. Bij aanscherping naar 1e-8 groeide de gepropageerde operator tot 11.443.150 actieve termen en steeg de rekentijd naar 234 seconden.

De waarden bij lower_atol=1e-6 en 1e-8 verschillen slechts 3,86e-5. De coëfficiëntdrempel is over dat interval dus bijna stabiel. De resterende afwijking van chi256 verdwijnt niet door alleen deze drempel aan te scherpen; ook de lengtecutoff en implementatiedetails blijven relevant.

De eerdere EduKaizen-code gebruikte eveneens cutoff 4, maar behield daarnaast maximaal 5.000 termen. Officiële Monoprop behield iedere term boven de coëfficiëntdrempel. Hetzelfde cutofflabel definieert dus niet dezelfde benadering. De kleine afwijking tussen EduKaizen en chi256 is op zichzelf geen onafhankelijk bewijs dat cutoff 4 geconvergeerd is.

Welke quantumtijd vergelijken we?

De lokale 33,15 s is een uitvoeringsschatting voor één hoofdcircuit met 4.096 shots plus readoutcircuits. De Q-CTRL-studie gebruikte 20.000 shots. Voor het experiment met 60 sites en 30 stappen rapporteert zij 166 s hoofd-QPU-tijd en 265 s inclusief karakterisatie voor readout error mitigation en decay recovery.

Bij het shotbudget uit de paper ligt de Monoprop-run van 234 seconden tussen beide quantumtijden: trager dan alleen het hoofdcircuit, maar sneller dan de QPU-tijd inclusief karakterisatie. QPU-gebruik sluit bovendien wachtrij en de omringende cloudworkflow uit, terwijl de klassieke getallen lokale wall-clockmetingen zijn. Het zijn nuttige technische metingen, maar geen volledig identieke definities van time-to-answer.

Wat deze benchmark aantoont

Officiële Monoprop is een veel sterkere klassieke baseline dan de eerdere demonstratie van één lokale occupation-operator. Voor dezelfde gemiddelde dubbele bezetting van 60 sites levert Monoprop in enkele minuten een antwoord, tegenover 19 minuten voor de EduKaizen-implementatie en 2,5 uur voor MPS chi256.

Deze benchmark toont op de lokale uitvoeringsmaat wel degelijk een quantum-runtimevoordeel. De hardwareproxy van 33,15 s is 234,03/33,15 = 7,06x sneller dan de strikte officiële Monoprop-run. De quantumuitvoering gebruikt in deze geregistreerde vergelijking ongeveer 14,2 procent van de Monoprop-tijd.

De reikwijdte van dat voordeel blijft specifiek. De hardwarewaarde wijkt sterker af van chi256 dan Monoprop, de QPU-tijd is een uitvoeringsproxy en geen volledige cloud-time-to-answer, en chi256 bereikte zelf de ingestelde bondlimiet. Deze kanttekeningen verhinderen een algemene end-to-end quantumvoordeelclaim bij gelijkgeschakelde nauwkeurigheid, maar nemen het gemeten quantum-runtimevoordeel van 7,06x tegenover officiële Monoprop niet weg.

De conclusie is daarom een tijd-nauwkeurigheidsfront met een duidelijke winnaar op runtime: hardware is op de lokale uitvoeringsmaat 7,06x sneller dan officiële Monoprop, Monoprop ligt dichter bij de huidige MPS-referentie dan de hardware-uitkomst, de EduKaizen-truncatie ligt toevallig het dichtst bij die referentie en MPS blijft in deze vergelijking de duurste berekening.

Bronnen en reproduceerbaarheid

  • Algorithmiq, officiële Monoprop-repository en documentatie.
  • A. Miller et al., Simulation of Fermionic Circuits Using Majorana Propagation.
  • Q-CTRL Fermi-Hubbard-studie, arXiv:2605.04025.
  • EduKaizen-projectcode en benchmarkbestanden, fermi-hubbard-60q-tdvp.
Nederlands | English | Projectpagina | Vorige

Leave a Reply Cancel reply

You must be logged in to post a comment.

Recent Posts

  • Fermi-Hubbard op een quantumcomputer, deel 11: de officiële Monoprop-benchmark
  • Fermi-Hubbard on a quantum computer, part 11: the official Monoprop benchmark
  • Quantum computing-nieuws — 1 augustus 2026
  • Quantum computing-nieuws — 31 juli 2026
  • Fermi-Hubbard op een quantumcomputer, deel 10: kan een quantumcomputer een quantumlab vervangen?

Recent Comments

No comments to show.

Archives

  • August 2026
  • July 2026
  • May 2026
  • March 2026
  • February 2026
  • September 2024

Categories

  • 10
  • Quantum Computing
  • Uncategorized
©2026 Edukaizen | Theme by SuperbThemes