Case Study 2: The Optimization That Did Nothing, Twice

The setup

Dynamical decoupling is the cheapest technique in the chapter. No extra circuits, no extra shots, no post-processing — it fills idle time with pulses that echo away dephasing, and the runtime exposes it as a single boolean:

estimator.options.dynamical_decoupling.enable = True

One line, free, and it protects the qubits that Chapter 11 §11.7 showed the computational basis cannot even see decohering. It should be the easiest recommendation in the book.

The circuit built to demonstrate it: two qubits hold a Bell state while two others churn through 30 layers of gates. The Bell pair idles for a long time doing nothing — precisely the situation DD exists for.

qc = QuantumCircuit(4, 2)
qc.h(0); qc.cx(0, 1)              # entangle, then idle
for _ in range(30):
    qc.cx(2, 3); qc.cx(3, 2)      # the other pair churns
qc.barrier()
qc.measure([0, 1], [0, 1])

Transpiled depth: 213. Plenty of idle time to protect.

Failure 1: the pass ran and nothing happened

dd = PassManager([
    ALAPScheduleAnalysis(durations),
    PadDynamicalDecoupling(durations, dd_sequence=[XGate(), XGate()]),
])
isa_dd = dd.run(isa)

  variant                            X added   delays   correct     delta
  (no DD)                                  0        0    0.9801       --
  ALAP, skip_reset=True (default)          4      132    0.9801   +0.0000

The result did not change. At all. Not to four decimal places.

Everything about the run looked like success. The pass executed without error. It inserted 132 delay instructions — clear evidence it had analyzed the schedule and found idle time. It added four X gates. The circuit got two layers deeper. A reasonable person checking "did DD run?" would have answered yes and moved on.

Four X gates across a 213-deep circuit is not dynamical decoupling. It is four X gates.

Why

Two defaults interacting.

PadDynamicalDecoupling defaults to skip_reset_qubits=True, which declines to insert DD on qubits that have not yet been operated on — sensible, since a qubit still in $|0\rangle$ has no coherence to protect.

ALAPScheduleAnalysis schedules as late as possible. So the Bell pair's h and cx get pushed to the end of the circuit, right before the measurement, and the long idle stretch ends up at the beginning — while those qubits are still in their reset state.

DD looked at the idle period, saw untouched qubits, and skipped all of it. Both defaults behaved exactly as documented. Their combination made the optimization a no-op.

The general shape of this failure: a technique that is enabled but never reaches the case it is meant to handle. It reports success, consumes no obvious resources, and silently contributes nothing.

This is Chapter 11's testing trap in a new costume. There, RemoveDiagonalGatesBeforeMeasure deleted the $T$ gates before the stabilizer simulator could fail on them, so a test that should have failed passed. Here, the scheduler moved the idle time out from under the pass that was supposed to protect it.

In both cases the tooling was correct, the configuration was defensible, and the result was meaningless.

The check

added = isa_dd.count_ops().get("x", 0) - isa.count_ops().get("x", 0)
print(f"DD inserted {added} X gates into a depth-{isa.depth()} circuit")

Expect hundreds. A handful means it is not engaging. And note that if the pass is doing nothing, changing sequence_type will not help — the problem is placement, not sequence. That is a distinction worth ten minutes of not guessing.

Failure 2: when it engaged, it made things worse

Turn off skip_reset_qubits and DD engages properly:

  variant                            X added   delays   correct     delta
  (no DD)                                  0        0    0.9801       --
  ALAP, skip_reset=True (default)          4      132    0.9801   +0.0000
  ALAP, skip_reset=False                 254      382    0.9178   -0.0623
  ASAP, skip_reset=False                 254      382    0.8796   -0.1005

254 X gates, unambiguously engaged, and correctness fell by 6 points under ALAP and 10 points under ASAP.

The obvious readings are both wrong. It is not a bug in the pass, and it is not evidence that DD is useless. It is evidence that this simulation cannot answer the question.

Why the simulator cannot answer it

Dynamical decoupling works against correlated, slowly-varying noise. A pulse echo reverses a dephasing that is still there — the same, unchanged — when the echo arrives. Low-frequency drift, quasi-static field offsets, $1/f$ noise: DD flips the qubit so that the phase accumulated in the second half cancels the phase accumulated in the first.

Chapter 11 §11.6 recorded what NoiseModel.from_backend actually contains: independent, memoryless (Markovian) errors, with no correlations, no drift, and no non-Markovian structure. The model was honest about this; §11.6 listed it as a limitation and moved on.

In a memoryless model, there is nothing for an echo to reverse. Each moment's noise is freshly sampled and uncorrelated with the last, so flipping the qubit halfway through cancels nothing. The X pulses contribute their own gate error and nothing else.

$$\text{DD benefit} \;=\; \underbrace{\text{correlated dephasing removed}}_{\;=\;0\text{ in a Markovian model}} \;-\; \underbrace{\text{error of the inserted pulses}}_{254 \text{ gates}}$$

−0.0623 is the correct output of that equation. The simulation is right. It is answering a different question than the one asked.

🔬 The honest position. The fake-backend path has been right about everything in this book — Chapter 4's dead qubit, Chapter 10's routing blowup, Chapter 11's noise signatures, Chapter 12's layout swing, this chapter's readout mitigation and ZNE. All of it verified locally, no credentials, no queue.

And it is structurally incapable of evaluating dynamical decoupling. Not inaccurate — incapable. The physics DD addresses is absent from the model by construction.

Evaluate DD on hardware, against a control, or not at all.

The scoreboard

Two different failures, and neither is "DD doesn't work." On real hardware DD is frequently a genuine, cheap win. What this case study establishes is that you cannot tell that from here, and that a config which appears to enable it may not.

The lessons

Verify that an optimization is doing something before evaluating whether it helps. Count what it inserted. "Enabled" and "engaged" are different states, and only one of them shows up in a config file.

Know which questions your instrument cannot answer. Chapter 12 §12.7 step 2 asks whether a failure survives the removal of noise; the same reasoning applied to a simulator asks which physics the model contains. A Markovian noise model cannot speak to a technique that targets non-Markovian noise, and running the experiment anyway produces a confident, precise, meaningless number.

A negative result from an inadequate instrument is not a negative result. −0.0623 is real, it is reproducible, and it says nothing whatsoever about DD on hardware. Reporting it as "DD hurt performance" would be a straightforward misreading of one's own experiment.

Defaults are chosen for the common case and compose unpredictably. skip_reset_qubits=True is right on its own. ALAP is right on its own. Together they silently disabled the feature. This is the fourth time in the book that a defensible default produced a wrong outcome — Chapter 8's parameter sort order, Chapter 10's optimization level, Chapter 11's diagonal-gate removal, now this.

Reproduce it: code/example-04-dynamical-decoupling.py runs all three configurations and counts the inserted pulses.