How can I decide ahead of time whether a Stim detector will be deterministic?

Question

I have a high-level description of a quantum stabiliser code and a small brain, and I'd like to write code to compile the former to a Stim circuit. The high-level description contains the stabiliser measurements to perform each round, and then generally detectors should be built by comparing measurements of the same stabiliser in consecutive rounds. Taking the rotated surface code as an example, the stabilisers (in the bulk) are XXXX and ZZZZ products.

In the first ever round of measurements, however, I can't compare to the previous measurement of a stabiliser, because it doesn't exist. I can still build detectors at the end of this round, but they depend on the initial states of the data qubits. e.g. If I initialise all the data qubits in |0>, then the first ZZZZ measurements should output +1 deterministically (using the convention that outcomes are +1 and -1), so I can build a 'one-measurement detector'. The XXXX measurements individually are random, however, so I can't turn them into detectors. Vice versa if I initialise all the data qubits in |+>.

I've read the paper that explains how Stim works, and I'm almost certain it's telling me I should be able to figure out which 'potential detectors' in the first round will be deterministic, using only Tableaus and PauliStrings - i.e. without dropping down to the circuit level. But my aforementioned small brain can't quite connect the dots. Is anyone able to help?

(Other info: I'm reluctant to swap to a design where the user specifies themself which detectors are/aren't deterministic in round 1. My current workaround, apart from being shamefully ugly, is too slow: it involves building a circuit representing the initialisation steps, then checking in turn whether each potential detector is deterministic by asking for the circuit's detector error model, then seeing if this throws an error saying there's non-deterministic detectors.)

Answer 1

Detectors correspond to measurements that can be predicted, because their result is determined by (as opposed to randomized by) the current state of the system.

One way to automatically identify such measurements is to run the circuit step by step using stim.TableauSimulator, but using introspection methods like simulator.peek_z or simulator.measure_kickback to identify determined measurements. peek_z will return a non-zero expectation if a Z basis measurement is going to be deterministic. measure_kickback returns a kickback of None for determined measurements.

So, for your specific case, I would recommend running the first round of the circuit using a stim.TableauSimulator. Before each measurement, peek at its expectation. The measurements with non-zero expectation (either +1 or -1) are the ones that are detectors.

---

A bit of pontificating on detector discovery in general...

In the general case it gets a bit more complicated. For example, beware that one of the determined measurements, usually one of the data measurements at the end, will be determined because of the deterministic logical observable rather than due to a detector.

Once you know which measurements are determined, you have to figure out how to predict them. Which specific other measurements are predicting the determined measurement? It could be a single other measurement, multiple other measurements, or the empty set (as occurs during initialization). Usually you'll have a pretty good idea of which measurements to use (e.g. the previous measurement of the same stabilizer). Sometimes you'll have to more carefully trace the observables measured by measurement backwards through the circuit, and find combinations that cancel out. Sometimes it's a giant pain to get all the details exactly right. For example, in this paper I struggled to find this detector:

It's possible to automatically discover measurements that predict the given measurement by using Gaussian elimination. Trace each measurement's observable back to the beginning of time, noting which resets each measurement anticommutes with, and then perform Gaussian elimination on the anticommutations to discover sets of measurements that commute with all resets. These sets form detectors... except they might be really bad detectors.

The tricky thing about solving for the other measurements to use is that the solution is ambiguous. There are often multiple possible solutions, and the goal is to pick the "right" one. For example, in the second round of stabilizer measurements after a Z basis initialization, you can either predict the Z stabilizers by comparing them to the previous round or by comparing them to the initialization start of time. You have to decide whether to decompose $a=b=+1$ into $a=+1, b=+1$ or into $a=+1, b=a$. Getting this choice wrong can make decoding break, e.g. because you broke the invariant that detection events should come in pairs. This "right choice" ambiguity is what makes it difficult to completely automate detector discovery.

There are similarities between "good detector discovery" and "minimum weight basis" problems. Given two detector measurement sets $A$ and $B$, their symmetric difference $A \oplus B$ is also a detector measurement set. So you can always XOR one detector into another, producing a slightly different potentially unnecessarily complicated but still valid choice of detectors. The goal is to find detectors that have good properties, like they are local or they are sensitive to fewer errors or they use fewer measurements or they evenly cover the circuit or etc or etc or etc.