De recente Q-CTRL paper Fast, accurate, high-resolution simulation of large-scale Fermi-Hubbard models on a digital quantum processor is interessant omdat het geen losstaande demonstratie van een groot quantumcircuit is. De kracht zit juist in de vertaling van een fysisch probleem naar een circuit dat precies past bij de hardware.

Ik heb een kleinere, reproduceerbare versie van dat idee uitgewerkt in deze repo:

https://github.com/BramDo/fermi-hubbard-60q-tdvp

Die repo is geen volledige reproductie van de Q-CTRL claim. Het is een 60-qubit / 30-site / 8-Trotter-step snapshot, geen 120-qubit / 30-step experiment. Maar juist daardoor is het een nuttige “poor man’s” versie: klein genoeg om zelf te volgen, groot genoeg om te laten zien waarom de mapping, layout en fSWAP-constructie essentieel zijn.

Het model: een lijn van fermionen

Het 1D Fermi-Hubbard model beschrijft fermionen met spin die over een rooster kunnen hoppen en elkaar afstoten wanneer twee tegengestelde spins op dezelfde site zitten. In de notatie van de paper kun je de kern schrijven als:

\[H=-t_h\sum_{i,\sigma}\left(c^\dagger_{i,\sigma}c_{i+1,\sigma}+c^\dagger_{i+1,\sigma}c_{i,\sigma}\right)+U\sum_i n_{i,\uparrow}n_{i,\downarrow}-\mu\sum_{i,\sigma}n_{i,\sigma}\]

De eerste term is hopping: een fermion beweegt van site i naar site i+1. De tweede term is de onsite interactie: als er op dezelfde site een spin-up en spin-down fermion aanwezig zijn, kost dat energie U. De laatste term is de chemische potentiaal.

Voor een quantumcomputer is dit nog geen circuit. Fermionische operatoren moeten eerst worden vertaald naar qubits. Dat is subtiel, omdat fermionen antisymmetrisch zijn: wanneer je twee fermionische modes verwisselt, verschijnt er een minteken. Een gewone qubit-SWAP houdt die tekenstructuur niet automatisch bij.

Pair-interleaved Jordan-Wigner ordering

De Q-CTRL aanpak gebruikt een Jordan-Wigner mapping, maar met een slimme ordering van de fermionische modes. In plaats van alle spin-up modes en daarna alle spin-down modes te nemen, worden de modes per site geinterleaved:

\[\{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}\]

Het gevolg is dat de twee spinmodi van dezelfde Hubbard-site naast elkaar liggen op de qubitlijn. Dat maakt de onsite interactie lokaal. Hoppingtermen kunnen vervolgens worden georganiseerd in korte en lange hoppinglagen. De layout is dus niet een bijzaak achteraf, maar een onderdeel van de fysische vertaling.

In mijn 60-qubit run betekent dit: 30 Hubbard-sites worden vertaald naar 60 qubits. De circuitfamilie heet in de repo native-fswap-cz. De naam is belangrijk: de routing is niet opgebouwd uit gewone SWAPs, maar uit fermionische SWAPs.

Waarom fSWAP geen gewone SWAP is

Een fSWAP verwisselt twee fermionische modes en voegt precies het teken toe dat nodig is voor fermionische anticommutatie. De gebruikte vorm is:

\[\mathrm{fSWAP}=\mathrm{SWAP}\cdot\mathrm{CZ}\] \[\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 eerste drie basiscomponenten gedragen zich als een gewone SWAP. Het verschil zit in \(|11\rangle\): daar komt een minteken. Dat minteken is geen detail. Het is precies wat je nodig hebt wanneer twee bezette fermionische modes van plaats wisselen.

Hierdoor wordt routing zelf onderdeel van de fermionische simulatie. De fSWAP-laag verplaatst modes door de qubitlijn, maar doet dat algebraisch correct. Daardoor kun je hopping-interacties lokaal houden zonder de fermionische tekenboekhouding te verliezen.

De snake-layout: de fermionlijn op heavy-hex leggen

IBM processors hebben geen perfecte rechte lijn van qubits. Ze hebben een heavy-hex connectiviteit. De truc is om een effectieve 1D fermionlijn als een snake door die connectiviteit te leggen. De layout volgt dus het probleem: naburige fermionische modes moeten zoveel mogelijk ook fysiek naburige qubits zijn.

Dit is het punt waarop de Q-CTRL aanpak duidelijk geen generieke “druk op compile” workflow is. De goede layout komt uit co-design:

• de fysica bepaalt welke modes naast elkaar moeten liggen;
• de Jordan-Wigner ordering bepaalt waar de tekenstrings zitten;
• de fSWAP-lagen bepalen hoe modes door de lijn bewegen;
• de heavy-hex hardware bepaalt welke qubitparen goedkoop zijn;
• kalibratiegegevens bepalen welke fysieke qubits of koppelingen je liever vermijdt.

Dat is precies waarom deze klasse circuits zo interessant is. De quantumcomputer wint hier niet doordat een willekeurig circuit magisch snel wordt. De winst komt doordat het probleem zo wordt herschreven dat de hardware bijna de natuurlijke geometrie van het probleem uitvoert.

Waarom de diepte klein blijft

De paper geeft voor deze native constructie een opvallende resource-scaling:

\[D_{2Q}=5\,n_{\mathrm{step}}+2\] \[N_{2Q}=(5L-2)n_{\mathrm{step}}+2(L-1)-1\]

\(D_{2Q}\) is de twee-qubit diepte. Die hangt af van het aantal Trotter-stappen, maar niet van het aantal sites \(L\). \(N_{2Q}\), het aantal twee-qubit gates, groeit wel met \(L\), maar lineair. Dat is precies wat je wilt voor een grote 1D simulatie: meer sites kosten meer gates, maar niet automatisch meer seriele diepte.

Voor mijn kleinere run, met L = 30 sites en nstep = 8, geeft dat:

\[D_{2Q}=5\cdot 8+2=42\] \[N_{2Q}=(5\cdot 30-2)\cdot 8+2(30-1)-1=1241\]

Deze getallen staan ook zo in de lokale stage plan van de repo: native two-qubit depth 42 en native two-qubit gates 1241.

Wat er op hardware overblijft

Na transpilation naar de gebruikte IBM hardware wordt het circuit natuurlijk zwaarder. Voor de main hardware route in de repo is de summary:

• 60 qubits / 30 sites;
• 8 Trotter steps;
• dt = 0.2, dus totale tijd t = 1.6;
• circuit family: native-fswap-cz;
• main transpiled CZ / two-qubit-depth / total depth: 2368 / 80 / 353;
• selected CZ error mean / max: 0.0020063 / 0.0058129;
• selected readout error mean / max: 0.0162679 / 0.0925293.

De native structuur wordt dus niet perfect behouden, maar ook niet vernietigd. De main transpiled two-qubit depth is ongeveer een factor 1.9 boven de native target van 42. Dat is nog steeds compact voor een 60-qubit fermionisch circuit. De CZ-fouten zijn relatief gunstig; de readout heeft wel duidelijke outliers, waardoor readout correction geen cosmetische stap is maar een noodzakelijke correctie.

De kern: dit is geen generieke compilerwinst

De les van deel 1 is dat de interessante versnelling niet begint bij timing, maar bij structuur. Je krijgt dit circuit niet door een willekeurige Fermi-Hubbard Hamiltoniaan aan een generieke compiler te voeren en te hopen op het beste. Je hebt de combinatie nodig van:

• een fermion-to-qubit mapping die de juiste lokale structuur blootlegt;
• een fSWAP-netwerk dat fermionische anticommutatie bewaart;
• een snake-layout die past bij heavy-hex connectiviteit;
• layoutselectie op basis van kalibratie;
• en een native circuitfamilie die de twee-qubit diepte onder controle houdt.

Daarom is de Q-CTRL paper technisch sterk. Tegelijk maakt dit de interpretatie van “quantum advantage” subtieler. Als een groot deel van de prestatie komt uit physics-aware compilation en hardware-aware mitigation, dan moet je precies aangeven wat je meet: algoritmisch voordeel, QPU-executietijd, compiler-assisted voordeel, of volledig end-to-end applicatievoordeel.

In deel 2 kijk ik naar de runtimekant: de vergelijking met ITensorMPS TDVP, waarom mijn kleinere 60q/8 run al een duidelijke QPU-execution-time separation laat zien, en waarom ik dat bewust nog geen quantum advantage claim noem.