Een Fermi-Hubbard Hamiltoniaan is nog geen quantumcircuit. Eerst moeten de fermionische modes naar qubits worden vertaald. Daarna moet het circuit op een echte chip worden gelegd. Bij fermionische simulatie is die layout geen detail. Zij is onderdeel van het algoritme.
De reden is het fermionische teken. Als twee bezette fermionische modes worden verwisseld, verschijnt er een minteken. Een gewone qubit-SWAP houdt daar geen rekening mee. Daarom gebruiken we een fermionische swap: de fSWAP.
Van sites naar qubits
Elke Hubbard-site heeft twee spinmodi: spin-up en spin-down. Een keten met 60 sites heeft dus 120 fermionische modes. In een Jordan-Wigner achtige mapping leg je die modes op een lijn en koppel je ze aan qubits.
Een handige ordering houdt de twee spinmodi van dezelfde site dicht bij elkaar
\[\{c_{0,\downarrow},c_{0,\uparrow},c_{1,\uparrow},c_{1,\downarrow},c_{2,\downarrow},c_{2,\uparrow},c_{3,\uparrow},c_{3,\downarrow},\ldots\}\rightarrow q_0,q_1,\ldots,q_{2L-1}\]Dit is belangrijk omdat de onsite interactie lokaal is. Als spin-up en spin-down van dezelfde site ver uit elkaar liggen in de qubitlijn, betaal je met extra routing en langere strings.
De fSWAP gate
De fSWAP verwisselt twee fermionische modes en voegt het juiste teken toe
\[\mathrm{fSWAP}=\mathrm{SWAP}\cdot\mathrm{CZ}\]Als matrix
\[\mathrm{fSWAP}=\left(\begin{array}{rrrr}1&0&0&0\\0&0&1&0\\0&1&0&0\\0&0&0&-1\end{array}\right)\]De toestand |01> wordt |10>, en |10> wordt |01>, net als bij een gewone SWAP. Het verschil zit in |11>. Als beide modes bezet zijn, verschijnt een minteken. Dat minteken is precies de fermionische anticommutatie.
Routing wordt fysica
Bij veel quantumalgoritmen voelt routing als een compilerprobleem achteraf. Bij fermionische simulatie is dat te simpel. Een fSWAP-laag doet twee dingen tegelijk:
- zij verplaatst modes zodat de volgende interactie lokaal wordt;
- zij houdt de fermionische tekenstructuur correct.
Daarom kun je niet zomaar zeggen: laat de compiler swaps toevoegen. De swaps zijn hier niet alleen transport. Zij zijn onderdeel van de gesimuleerde fermionische algebra.
De snake door de chip
IBM processors hebben geen perfecte rechte lijn van 120 qubits. De connectiviteit is beperkt. De truc is om de effectieve fermionische lijn als een snake door de hardware te leggen.
Een goede snake layout probeert drie dingen tegelijk te doen
- vaak gekoppelde modes fysiek dicht bij elkaar houden;
- lange routing vermijden;
- slechte qubits of slechte koppelingen vermijden wanneer kalibratiegegevens dat nodig maken.
Dit is waarom de Q-CTRL aanpak niet voelt als een generieke "druk op compile" workflow. De fysica, de mapping, de fSWAP-lagen, de hardwareconnectiviteit en de error suppression zijn samen ontworpen.
Waarom de diepte laag blijft
De resource-scaling uit de paper laat zien waarom deze constructie aantrekkelijk is:
\[D_{2Q}=5\,n_{\mathrm{step}}+2\qquad N_{2Q}=(5L-2)n_{\mathrm{step}}+2(L-1)-1\]Voor de kleinere 60-qubit / 30-site / 8-step versie geeft dat
\[D_{2Q}=5\cdot 8+2=42\qquad N_{2Q}=(5\cdot 30-2)\cdot 8+2(30-1)-1=1241\]De twee-qubit diepte groeit met het aantal Trotterstappen, maar niet direct met het aantal sites. Het aantal twee-qubit gates groeit wel met de ketenlengte, maar lineair. Dat is precies wat je wilt voor een grote 1D simulatie.
De kernles
De quantumcomputer wint hier niet door een willekeurig circuit sneller uit te voeren. De winst komt doordat de Fermi-Hubbard structuur zo wordt vertaald dat de hardware bijna de natuurlijke geometrie van het probleem uitvoert.
Dat maakt de benchmark subtieler, maar ook interessanter. Het voordeel zit in de combinatie van fysica, mapping, layout en hardware-uitvoering.
Bronnen en projectlinks
- Q-CTRL Fermi-Hubbard paper: https://arxiv.org/abs/2605.04025
- Projectrepo: https://github.com/BramDo/fermi-hubbard-60q-tdvp