# when calculating code thresholds, why do we need to take a number of rounds that scales with the code distance?

In stim's error corretion example here, and in pymatching's toric code example here, the threshold calculation involves taking a number of rounds that scales as the code distance. Why is that the right way to do it?

To test what's going on if I try to do it some other way, calculated the threshold with a fixed number of rounds, yet much larger than the distance, and I get something that behaves reasonably until some "pseudo threshold" value, and then the errors seem to more or less track each other. How can we explain this behavior?

Here's an example of a surface code with rounds = 3 * distance as in the stim example:

and here's one with rounds=20:

The x axis are physical (2 qubit gate) error rates, and the y axis is logical error rate

BTW, I have a vague feeling that this is somehow related to this question.

(Note: you should take more data so those curves have less noise. You might also want to plot standard deviations of some sort so you can see the noise. The Stim example keeps to really low rep rates so it finishes in under a minute, not because that's recommended.)

The reason you want more and more rounds is because of boundary effects. Near boundaries, whether they be spatial boundaries or temporal boundaries (data initialization and measurement), the number of possible error chains is lower than in the bulk. Because errors that would have careened around without a care in the world instead slam into a wall. As the code distance gets bigger, the relevant error chains get longer, so the boundaries need to be further and further away. The threshold people are usually interested in is the threshold of the bulk, with boundaries nowhere nearby, and these can be different values.

You can very clearly see the problem at low round numbers. The threshold for 2-round memory experiments is higher than for 5-round memory experiments which is higher than for 10-round memory experiments. Here's data I took which agrees with your data. Note how the three curve groups have their respective crossings at different horizontal locations:

Incidentally, this is one of the reasons error correction experiments that do repetitive measurement instead of a single-shot thing are much more impressive. Single-shot experiments are like setting the number of rounds to 1, and have a much easier threshold.

• Thanks. Totally - my initial assumption was that you put 3 * distance because you want to look at bulk behavior and don't want the bulk to be needlessly large. However, I chose rounds= 3 * max(d) because I want to calculate $\Lambda$, as defined here: nature.com/articles/s41586-021-03588-y . The bunching behavior we see above the threshold seems to be at odds with this model, at least for $\Lambda < 1$. Like, how did they get $1/\Lambda = 1.3$ in fig. 4b? We see here that error rate is indpendent of code distance above the threshold.
– Lior
Feb 11 at 21:22
• BTW, about the noise - indeed, thanks for pointing this out. The plots look noisy because I'm modeling the behavior of the code when using a real time feedback correction model on the ancillas, and in order to do it I need to use the TableauSimulator. Still, it's order of magnitudes faster than quantumsim, which is what I was using previously, so thank you for that!
– Lior
Feb 11 at 21:25
• @Lior Hahaha that's quite funny to me because I think of the tableau simulator as 1000x slower than the frame simulator. Anyways, you have to look very carefully at how lambda is defined. In that experiment I believe we were fitting the exponential decay constant as the number of rounds was increased, and treating that as the logical error rate per round. So it's not from any one specific number of rounds. And then lambda was the factor that this decay constant changed by as you changed the code distance by 2; which was also fit as an exponential decay I bet. Fitting on fitting. Feb 11 at 22:26
• thanks @craigGidney. I realize now this question did not clearly demonstrate the issue - I posted a new question which hopefully clarifies things: quantumcomputing.stackexchange.com/questions/24063/…
– Lior
Feb 12 at 15:45