Edukaizen

Menu
  • News
  • Hubbard
    • 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: Reading heatmaps
      • Part 9: Digital vs cold-atom labs
      • Part 10: 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
    • 2D Local Quantum Advantage
      • Deel 1: Doel en budget
      • Deel 2: Fermionmodel
      • Deel 3: Mapping en diepte
      • Deel 4: Pilots en shots
      • Deel 5: Foutmitigatie
      • Deel 6: 6×6-resultaten
      • Deel 7: Circa 20x
      • Deel 8: Google en Bonsai
      • Deel 9: Volgende stap
  • Hadron
    • Part 1: Hadron on a quantum processor
    • Part 2: Quarks and confinement
    • Part 3: SU(2) and LSH
    • Part 4: Hamiltonian and circuit
    • Part 5: Fire Opal
    • Part 6: Classical simulations
    • Part 7: Quantum advantage
  • 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
    • Tutorial: UMI counts to a four-qubit circuit
    • Part 1: The QML task
    • Part 2: QOS theory
    • Part 3: Gene expression to 40 qubits
    • Part 4: JAX to hardware
    • Part 5: Readout and classifier
    • Part 6: 40-qubit result
    • Part 7: Route to quantum advantage
    • Part 8: 60-qubit result
  • Floquet-Ising
    • Part 1: Floquet physics
    • Part 2: Ising cycle
    • Part 3: Two-qubit toy model
    • Part 4: Oscillation and entanglement
    • Part 5: Noise and error mitigation
    • Part 6: Toward 51 qubits
  • Work
    • Quantum Gold
      • Part 1: Why gold is a relativistic quantum problem
      • Part 2: Why the 2025 gold VQE study stalled
      • Part 3: From QE and spin–orbit coupling to Qiskit
      • Part 4: Twelve gold spinor modes on four qubits
      • Part 5: The 24-qubit route: an active window for transport
      • Part 6: 24 qubits on IBM and with Fire Opal
      • Part 7: The road to quantum advantage for gold
      • Part 8: 24 gold spinor modes on IBM with ZNE-PEA
      • Part 9: Forced gold colour on 56 qubits
    • HaPPY Gravity
      • Part 1: Gravity as a phase gate
      • Part 2: Bosons and convergence
      • Part 3: The dynamic HaPPY benchmark
      • Part 4: The N=145 classical audit
      • Part 5: MPS and Majorana baselines
      • Part 6: PEA/ZNE and the decisive test
    • Fibonacci Anyons
      • Part 1: Fusion and braiding
      • Part 2: The 3/5/9-qubit ladder
      • Part 3: Why nine qubits were too deep
      • Part 4: Structure-aware simplification
      • Part 5: IBM hardware diagnostic
      • Part 6: Results and open questions
  • Advantage List
Menu

Part 1: A laptop as our benchmark: the Nighthawk project

NederlandsEnglish
2D Local Quantum Advantage | Previous | Next

Our goal does not start with beating every supercomputer. It starts with a much more personal question: can we, as a student/hobby project, have a quantum computer perform an interesting calculation using less recorded computation time than our own classical computer needs?

That limited goal is the common thread of this third Hubbard series. In the first series we explored the one-dimensional model. In the second we moved to two dimensions. We now focus on IBM Nighthawk, more physically faithful fermion circuits and a measurable local timing comparison.

The first milestone: approximately twenty times

For our archived 6×6 instance, the classical chi64 calculation took 150.819 seconds in its kernel. A Nighthawk job recorded 8 seconds of QPU usage; a later paired original/compact job recorded 7 seconds. The ratios are approximately 18.85 and 21.55. We summarise this as approximately 20x.

That ratio genuinely follows from the saved timing records. But it answers a specific question. QPU usage is not the same as the time between clicking ‘start’ and reading a validated answer. Queueing, preparation, network communication and local analysis are not all included on that QPU clock. Moreover, our classical reference has not been shown to be converged: chi64 is a calculation setting, not a guarantee of correctness.

Our claim is therefore that the quantum job used approximately twenty times less registered QPU time than the kernel of our current local classical baseline. We do not yet claim a twentyfold reduction in total elapsed time at demonstrably matched accuracy.

What does the quantum computer actually calculate?

We simulate a simplified model of moving, mutually repelling electrons: the two-dimensional Fermi-Hubbard model. The lattice has 36 sites. With two spin modes per site, that gives 72 fermion modes represented on 72 qubits. The state contains 32 particles, not 72.

We do not read out the complete quantum state. We ask for local charge, spin and double occupancy. These observables describe where the particles are and how the chosen initial state evolves. A useful quantum run must be judged on those requested quantities.

Working within a limited budget

The hardware experiments grew from small pilots to 6×6. We worked with 512 shots per setting and explicit QPU time limits, eventually a maximum of 15 seconds for an authorised job. More settings, extra mitigation circuits and additional shots all consume budget. Maximum depth, many time points and perfect statistics cannot be combined for free.

That makes this project educational. We had to decide which check would provide the most information, when a circuit becomes too deep, and when an attractive corrected value mainly tells us something about the correction method.

The new repository therefore contains more than appealing final tables. Source code, raw data, unsuccessful pilots and theory are preserved as well. While the repository is private, access is restricted to authorised readers.

Sources: our job records under hardware_tflo_dd6_2026-09-06_v1 and hardware_compact_tflo_2026-09-07_v1, the chi64 baseline, and IBM’s explanation of workload usage.

Recent Posts

  • Quantum computing-nieuws — 4 september 2026
  • Quantum computing-nieuws — 28 augustus 2026
  • Quantum computing-nieuws — 27 augustus 2026
  • Quantum computing-nieuws — 26 augustus 2026
  • Quantum computing-nieuws — 25 augustus 2026

Recent Comments

No comments to show.

Archives

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

Categories

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