Edukaizen

Menu
  • Home
  • 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
  • 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
      • ai toymodel
  • Random Graph
    • 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 4: de 120-qubit quantumrun

Posted on July 2, 2026 by
Nederlands | English | Project page | Previous | Next

Nu komt de vraag waar dit project om draait: wat gebeurt er als we de Fermi-Hubbard simulatie echt op quantumhardware draaien?

De grote lokale run in deze projectlijn volgt het Q-CTRL/IBM scenario op een concrete schaal:

  • 60 Hubbard-sites;
  • 120 fermionische modes, dus 120 qubits;
  • U/t_h = -2;
  • 30 Trotter steps;
  • eindtijd t = 6;
  • IBM hardware via Fire Opal.

De tijdsrelatie is eenvoudig

\[t=n_{\mathrm{step}}\Delta t\qquad \Delta t=0.2,\quad n_{\mathrm{step}}=30,\quad t=6\]

Dit betekent dat elke Trotterstap een stukje digitale tijdsevolutie benadert. Hoe meer stappen, hoe dichter je de continue tijdsevolutie nadert, maar ook hoe dieper het circuit wordt.

Wat werd gemeten?

De hardware geeft bitstrings terug. Die bitstrings moeten worden vertaald naar lokale observables. Voor dit project zijn vooral occupation, charge, spin en double occupancy belangrijk.

\[n_\uparrow(i)=\langle n_{i,\uparrow}\rangle,\quad n_\downarrow(i)=\langle n_{i,\downarrow}\rangle\\ \mathrm{charge}(i)=n_\uparrow(i)+n_\downarrow(i)\\ \mathrm{spin}(i)=n_\uparrow(i)-n_\downarrow(i)\\ D(i)=\langle n_{i,\uparrow}n_{i,\downarrow}\rangle\]

Deze observables maken het mogelijk om de quantumrun als een soort materiaalbeeld te bekijken. De x-as is de sitepositie in de 1D keten. De y-as is Trotter step of modeltijd. De kleur is bijvoorbeeld charge of spin.

Het resultaat lijkt daardoor conceptueel op quantum-gas-microscope metingen aan 1D Fermi-Hubbard ketens. Het is niet hetzelfde experiment. Een cold-atom plot kan bijvoorbeeld een symmetrische lokale quench rond het centrum tonen, terwijl onze digitale run een globale evolutie op een 60-site keten laat zien. Maar de taal is vergelijkbaar: positie, tijd, charge en spin.

Timing

Voor de 120-qubit / 30-step Fire Opal run is de lokale geschatte main+readout circuit execution time ongeveer:

33.148928 seconden.

Dat is niet hetzelfde als volledige menselijke doorlooptijd. Het is ook niet hetzelfde als cloud wall time inclusief wachtrij en service overhead. Daarom is het belangrijk om drie tijden uit elkaar te houden:

  • quantum execution proxy: de geschatte hardware-circuituitvoering;
  • observed action wall time: de tijd die de cloudactie zichtbaar kostte;
  • end-to-end workflow time: alles inclusief voorbereiding, validatie, post-processing en menselijke keuzes.

Voor een eerlijke benchmark moet je zeggen welke tijd je bedoelt. De 33 seconden zijn vooral interessant als execution-time proxy voor de quantumroute.

Raw of readout-corrected?

Een onverwachte les uit de lokale vergelijking is dat readout-correctie niet automatisch alle observables beter maakt. Voor sommige globale grootheden, zoals totale charge, kan readout-correctie helpen. Voor lokale RMSE tegen een chi256 referentie kan raw soms beter scoren.

Dat is geen paradox. Error mitigation is geen magische stap. Zij verschuift fouten. Soms helpt ze een globale constraint, terwijl lokale observables juist wat slechter worden. Daarom is het belangrijk om meerdere metrics te tonen.

Vergelijking met chi256

De lokale chi256 MPS referentie had een wall time van 9033 seconden. Tegen die referentie was de hardware niet perfect. Maar zij gaf wel een bruikbare volledige-instantie schatting in zeer korte quantum execution time.

De ruwe hardware route had voor de lokale scoring een lagere overall score dan de readout-corrected route tegen chi256. Dat is een inhoudelijk punt: je moet de data meten, niet aannemen dat de meest gecorrigeerde variant altijd het beste is.

Wat mogen we claimen?

Een voorzichtige formulering is

De quantumrun geeft snel een bruikbare lokale observable voor een 120-qubit / 60-site Fermi-Hubbard instantie. Dit is geen bewijs dat klassieke methoden falen, maar wel een concrete time-to-answer benchmark.

Wat we niet moeten zeggen

  • niet dat dit alle klassieke computers verslaat;
  • niet dat de volledige wavefunction is gesimuleerd;
  • niet dat noise geen rol meer speelt;
  • niet dat de lokale run de volledige Q-CTRL paperclaim reproduceert.

Wat we wel kunnen zeggen

  • het circuit draait op echte hardware;
  • de observables zijn materiaalachtig interpreteerbaar;
  • de timing is interessant ten opzichte van lokale klassieke referenties;
  • de vergelijking wordt pas eerlijk als ook tensor-networks en Majorana propagation worden meegenomen.

Dit maakt de quantumrun geen eindpunt, maar het midden van het verhaal. De volgende vraag is: hoe hard kunnen klassieke methoden terugvechten?

Bronnen en projectlinks

  • Q-CTRL Fermi-Hubbard paper: https://arxiv.org/abs/2605.04025
  • Projectrepo: https://github.com/BramDo/fermi-hubbard-60q-tdvp
  • Fire Opal route in de repo: docs/fire_opal_route.md
Nederlands | English | Project page | Previous | Next

Recent Posts

  • Black Hole OLE, part 7: a local toy model with theory and user guide
  • Black Hole OLE, part 6: what the result proves and what comes next
  • Black Hole OLE, part 5: Hawking, black holes, and scrambling
  • Black Hole OLE, part 4: the tensor-network challenge
  • Black Hole OLE, part 3: Fire Opal on IBM Kingston

Recent Comments

No comments to show.

Archives

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

Categories

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