Case Study 1: The Circuit That Was Wrong for the Machine

The situation

A team has a twelve-qubit algorithm whose structure is a hub: one register qubit interacts with every other qubit in turn. This shape is common — it appears in phase estimation, in some oracle constructions, and in any algorithm with a control register that conditions operations on a work register.

It runs on a 127-qubit superconducting device. The results are poor: correct-fraction well below what the error budget predicts, and it gets worse as they add qubits.

They do everything Part II taught, and all of it helps a little.

Chapter 12's layout scoring: they enumerate candidate placements and pick the best-scoring one. Some improvement.

Chapter 12's preflight check: no dead qubits in the layout. Clean.

Chapter 13's readout mitigation: 60%-ish of the readout error removed, as advertised.

Chapter 13's ZNE on top: further improvement, at 12× the gate cost.

Chapter 10's optimization level 3: already on.

They have applied every technique in this book and the circuit is still not good enough. The natural conclusion is that twelve qubits is simply beyond current hardware.

The measurement they did not take

    n   logical 2q   Sherbrooke ECR   depth   overhead
    4            3                3      18      1.00x
    6            5                7      36      1.40x
    8            7               15      63      2.14x
   10            9               27     115      3.00x
   12           11               35     136      3.18x

The algorithm asks for 11 two-qubit gates. The device executes 35.

Twenty-four of those gates are SWAPs — pure overhead, existing only to move quantum information to places where the lattice permits it to interact. They contribute error and contribute nothing else.

And the depth is 136 layers for an eleven-gate algorithm. Since Chapter 11 §11.7 established that decoherence scales with duration, that is the number doing the damage.

Every mitigation they applied was fighting the symptom. Readout mitigation removes readout error; ZNE removes scalable gate error; layout scoring picks better qubits to run 35 gates on. None of them addresses the fact that 24 of the 35 gates should not exist.

Why the overhead grows

The circuit's interaction graph is a star: qubit 0 must interact with eleven distinct partners.

$$\text{max interaction degree} = 11$$

A heavy-hex lattice gives each physical qubit two or three neighbours. There is no qubit anywhere on a 127-qubit heavy-hex chip that is adjacent to eleven others — not because the chip is small, but because that is what a degree-3 lattice is.

So the compiler does the only thing available: it routes. Qubit 0's state gets SWAPped around the lattice to meet each partner in turn, and the number of SWAPs required grows with the number of partners.

The overhead is not a compiler limitation. Chapter 10 §10.6 measured optimization level 3 doing substantially better than level 1; it is doing well here too. It is a graph-embedding fact: a degree-11 vertex cannot be embedded in a degree-3 graph without paths, and paths cost gates.

The control case makes this unambiguous. The same GHZ state built as a chain instead of a star — same qubit count, same entanglement, same final state:

    n = 4, 6, 8, 10, 12   ->   overhead 1.00x at every size

Free. At every size. The chain has max interaction degree 2, which any lattice provides.

Same algorithm, same output state, and a 3.18× difference in cost — decided entirely by which qubit-pair structure the programmer happened to write.

The two real options

Option 1: change the circuit. A GHZ state can be built as a star or a chain, and the chain is free. More generally, many hub-shaped circuits have equivalent formulations with bounded interaction degree — this is what "hardware-efficient ansatz" means in Chapter 16, and why those ansätze look the way they do.

Option 2: change the machine. On trapped ions the overhead is 1.00× regardless of shape, because the Mølmer–Sørensen gate couples any two ions through a shared vibrational mode.

Which is better is a calculation, not a preference:

$$\varepsilon_{\text{ion}} = 1 - (1 - \varepsilon_{\text{sc}})^{r}$$

    n   overhead r   break-even error for an all-to-all device
    4        1.00x                                     0.0075
    8        2.14x                                     0.0160
   12        3.18x                                     0.0237

At twelve qubits, an all-to-all device wins if its two-qubit gate error is below about 2.4% — a bar current trapped-ion hardware clears. And the bar gets easier as the circuit grows, because the overhead grows.

The counter-consideration is speed. Ion gates are roughly 100× slower. If this were a variational workload running thousands of circuits — Chapter 16 §16.4's $2n+1$ executions per gradient, per iteration — the wall-clock cost could easily outweigh the fidelity gain. For a single twelve-qubit circuit run a few thousand times, it does not.

What went wrong in the process

Not the techniques. Every one of them worked as documented and measured.

The failure was one of ordering. Chapter 13 §13.9 laid out a mitigation procedure that begins "diagnose first — know which channel dominates." The team's dominant error source was neither readout nor gate noise in the usual sense; it was the 24 gates that the algorithm never asked for. No amount of channel-specific mitigation reaches that.

And there is a step even earlier than diagnosis, which this chapter adds:

Before asking "how do I run this circuit well on this machine," ask "is this machine the right shape for this circuit."

That question costs one transpilation against an all-to-all coupling map and a division. It would have been the first thing to try and was never tried, because Parts I and II had established superconducting hardware as the setting rather than as a choice.

The lessons

Connectivity is a first-order cost, not a detail. A 3.18× two-qubit gate multiplier exceeds anything Chapter 13's mitigation stack recovers, and it compounds with size while mitigation does not.

Measure the overhead before optimizing within it. One transpilation against CouplingMap.from_full gives you the number. If it is near 1.0, connectivity is not your problem and you should carry on with Chapter 13. If it is 3×, you are optimizing the wrong thing.

The interaction graph is the property that matters. Max interaction degree 2 maps onto anything; max degree 11 maps onto nothing with degree 3. You can read this off the circuit without transpiling at all.

The same algorithm can have very different shapes. Star-GHZ and chain-GHZ produce the identical state and differ by 3.18× in cost. Circuit structure is a hardware decision in disguise, and Chapter 16's "hardware-efficient ansatz" is the name for taking it seriously.

And the framing error is the expensive one. Parts I and II taught superconducting hardware thoroughly enough that its constraints became invisible — background facts rather than choices. The techniques were all correct; the setting was never questioned. That is exactly Chapter 14 §14.1's argument for learning a second framework, arriving now at the level of hardware rather than software.

Reproduce it: code/example-02-connectivity-cost.py produces every table in this case study, and recommend_modality in code/project-checkpoint.py makes the call with its evidence attached.