Case Study 2: The Ansatz That Could Not Be Optimized

Six months of the wrong lever

A team has been running a variational algorithm on hardware for two quarters. The results are poor and they know it — roughly 75% fidelity against the noiseless distribution, which is not enough to trust an energy estimate.

Their engineering effort has gone, sensibly, into everything Chapters 12, 13 and 28 recommend:

   * error-aware layout selection             (Chapter 12)
   * readout mitigation, then ZNE, in order   (Chapter 13, -79% combined)
   * optimization level 3 everywhere          (Chapter 28)
   * a custom PassManager with extra
     CommutativeCancellation iterations       (Chapter 28 Sec 28.5)

Each of these is correct and each helped. The last one — the custom pass manager — took three weeks and bought a 2% reduction in two-qubit gates.

Their ansatz is EfficientSU2 with entanglement="full", which is the library default in several tutorials and the natural choice if you are thinking about expressibility rather than hardware.

The one line

ansatz = efficient_su2(6, reps=3, entanglement="linear")   # was "full"

   entanglement   logical 2q   hardware ecr (L1)   overhead
   full                   45                 147       3.3x
   linear                 15                  15       1.0x

Their circuit had 45 logical two-qubit gates and was executing 147. A hundred and two of those gates — 69% of everything running on the device — were SWAPs the transpiler inserted to connect qubits the chip keeps apart.

Six months of optimization work had been spent making those 102 gates cheaper. None of it had asked whether they needed to exist.

What the change was worth

   configuration                                 ecr  depth   1-TVD
   full entanglement,   level 1, auto layout     147    396  0.7458
   full entanglement,   level 3, auto layout     118    334  0.7720
   linear entanglement, level 1, auto layout      15     41  0.9116
   linear entanglement, level 3, auto layout      15     54  0.9310

Isolating the two variables:

   optimization level, shape held fixed  (naive L1 -> naive L3):  +0.0262
   circuit shape, level held fixed       (naive L1 -> aware L1):  +0.1658

Circuit shape was worth six times the optimization level, and the hardware-aware circuit at level 1 beat the naive circuit at level 3 by $+0.1397$.

⚛️ Routing overhead is a property of your circuit, not of the transpiler.

The transpiler realizes the interaction graph you asked for on the interaction graph the chip provides. If the graphs match, the job is free. If they do not, the cost is set by how badly they mismatch, and optimization only finds a cheaper route through the same mismatch.

A team optimizing routing overhead is working on a number they chose, and could unchoose.

The question nobody asked

Not "how do we make this circuit cheaper?" — which they asked constantly and answered well — but:

"Why does this circuit need those connections at all?"

EfficientSU2 with entanglement="full" entangles every pair. That is a decision about the ansatz's expressibility: an all-to-all pattern generates a larger family of states than a linear one.

It is a real consideration and §29.6 takes it seriously. But it had never been examined against its cost, because the cost was invisible — it appeared as "the transpiler produces a lot of gates," which reads as a transpiler problem.

The interaction pattern was chosen by a default in a tutorial and then defended by six months of engineering effort spent downstream of it.

The honest counter-argument

Linear entanglement is less expressive. The comparison is not "same ansatz, cheaper" but:

   full entanglement:   more expressive, 0.7458 -> 0.7720 fidelity
   linear entanglement: less expressive, 0.9116 -> 0.9310 fidelity

So the right question is whether the extra expressibility reaches states the problem needs.

For Chapter 24's H₂ ansatz the answer was emphatic: a four-parameter, problem-informed circuit reached the exact ground state to $8.88 \times 10^{-16}$. Expressibility was nowhere near the binding constraint — the shot budget was.

For a harder molecule it might bind. That is an empirical question, and it can be answered on a simulator in an afternoon: run the optimization with both ansätze, noiselessly, and see whether the linear one reaches the answer at all. If it does, the expressibility argument is settled and the fidelity argument decides.

The team had never run that comparison, because the ansatz was not the thing they thought they were choosing.

A more expressive circuit you cannot execute is not more expressive.

And two other chapters point the same way. Chapter 16 §16.6 found that problem-informed ansätze are the main defence against barren plateaus. Chapter 24 §24.4 noted that QAOA gets a problem-informed structure for free. The ansatz that runs is often also the ansatz that trains, which makes this a less painful trade than it first appears.

What they should have done first

   1. COUNT THE ROUTING OVERHEAD before optimizing anything.
      hardware_2q / logical_2q. One line. 3.3x is a design problem,
      not a transpiler problem.

   2. ASK WHICH CONNECTIONS THE ALGORITHM NEEDS, as opposed to which
      the library's default provides.

   3. CHECK THE EXPRESSIBILITY COST on a simulator, noiselessly. Does the
      cheaper ansatz still reach the answer?

   4. THEN optimize. The transpiler works within your constraints; set
      them first.

Step 1 is the diagnostic, and it takes a minute. An overhead of 1.0 means routing is free and optimization is the only lever left. An overhead of 3.3 means most of your circuit is not your algorithm.

The lessons

Measure routing overhead before optimizing. It distinguishes a transpiler problem from a design problem, and they call for completely different work.

A library default is a decision you have made. entanglement="full" was never evaluated; it was inherited, and then protected by everything built on top of it.

Effort spent downstream of a bad constraint compounds the constraint. The custom pass manager was good work, took three weeks, and made 102 unnecessary gates 2% cheaper.

Ask what a cost is for, not just how to reduce it. Chapter 25's team optimized syndrome extraction without asking whether the code helped at their error rate. Chapter 28's team reduced gate count without asking whether it changed the answer. The recurring failure is optimizing a quantity without checking that it is the right quantity — and this is now the fourth chapter in which that is the finding.

And check what you gave up. Less entanglement is less expressibility. It was almost certainly the right trade here, and "almost certainly" should be replaced by a simulator run.

Reproduce it: code/example-01-the-chip-is-not-a-complete-graph.py prints the overhead table; routing_overhead in code/vqelab/hardware.py reduces the diagnostic to one call, and test_linear_entanglement_has_ZERO_routing_overhead asserts the 1.0.