De eerste twee delen gingen over fysica en circuitstructuur. Dit deel gaat over de praktische route: hoe kom je van een lokaal Fermi-Hubbard circuit naar een run op IBM hardware, eventueel via Q-CTRL Fire Opal?
De belangrijkste les is simpel: behandel de workflow als een experiment, niet als een losse notebook. Bouw het circuit, exporteer of submit het, haal de resultaten terug, en maak daarna reproduceerbare observables.
De drie lagen
In deze repo zijn er drie lagen
- circuitconstructie: bouw het native fSWAP/snake Fermi-Hubbard circuit;
- execution route: draai lokaal, exporteer QASM, of submit naar IBM Runtime / Fire Opal;
- post-processing: maak occupation, charge, spin, double occupancy, readout correctie en vergelijkingen.
Die scheiding is belangrijk. Als een resultaat tegenvalt, wil je weten of het probleem in de mapping, hardware, readout of analyse zit.
Qiskit omgeving
Op deze machine werd voor Fire Opal de bekende WSL Qiskit omgeving gebruikt
/home/bram/.venvs/qiskit/bin/python
Die omgeving bevatte Qiskit, qiskit-ibm-runtime en Fire Opal. Op een andere machine is het principe hetzelfde: gebruik een aparte virtual environment voor hardwarewerk en test eerst zonder echte submission.
Een veilige volgorde
- maak of activeer een Python environment;
- installeer de requirements;
- doe een dry run of QASM export;
- controleer de outputbestanden;
- submit pas daarna een kleine hardware smoke run.
De Fire Opal route
De Fire Opal route in deze repo werkt via QASM. De runner bouwt de circuits, exporteert OpenQASM en kan daarna groepen submitten.
De groepen zijn
- main: het echte Fermi-Hubbard circuit;
- readout: calibratiecircuits voor readout-correctie;
- echo: een final echo circuit voor decay/fidelity diagnostiek.
Die opsplitsing is nuttig. Je kunt een kleine smoke test doen met alleen main, en daarna pas readout en echo toevoegen.
Credentials
Credentials horen niet in de repo. De runner leest ze bij runtime. De veilige route is via environment variables of via de lokale Qiskit accountconfig. In deze workflow worden tokens niet naar artifacts geschreven.
Dat is niet alleen security. Het maakt de repo ook publiceerbaar. Iemand anders moet de code, QASM en resultaten kunnen lezen zonder persoonlijke API keys te zien.
Wat Fire Opal doet
Fire Opal is een performance-management laag van Q-CTRL. Het verandert de Hubbard Hamiltoniaan niet. Het probeert de uitvoering op noisy hardware beter te maken met hardware-aware keuzes, error suppression en post-processing.
Voor deze circuits is dat relevant. De circuits zijn groot genoeg om gevoelig te zijn voor noise, maar gestructureerd genoeg om van een goede hardware-aware pipeline te profiteren.
Van job naar observable
Een quantum job die "completed" is, is nog geen fysisch resultaat. Het resultaat wordt pas interessant wanneer de counts zijn omgezet naar observables:
\[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\]Daarna kun je vergelijken met klassieke referenties zoals MPS/TDVP of met een Majorana-propagation baseline.
De claimgrens
Een werkende Qiskit/Fire Opal route betekent
we kunnen het circuit submitten, terughalen en analyseren.
Het betekent nog niet
we hebben de volledige Fermi-Hubbard dynamica fysisch bewezen.
Voor harde claims blijven kleine exacte checks, klassieke referenties en convergence studies nodig. De setup is de machinekamer. De wetenschap zit in de vergelijking.
Bronnen en projectlinks
- Q-CTRL Fire Opal getting started: https://docs.q-ctrl.com/fire-opal/get-started
- IBM Quantum credentials guide: https://quantum.cloud.ibm.com/docs/guides/save-credentials
- IBM guide for Q-CTRL Fire Opal Performance Management: https://quantum.cloud.ibm.com/docs/guides/q-ctrl-performance-management
- Projectrepo: https://github.com/BramDo/fermi-hubbard-60q-tdvp