tqec
tqec copied to clipboard
QCHackers
Implement automatic detector computation
Is your feature request related to a problem? Please describe.
Currently, the tqec library requires users to explicitly implement the detectors. To ease that process, detectors are automatically included in Plaquette instances for the "default" situation, when that makes sense. But this way of adding detector is not optimal:
- the "default" detectors have been chosen arbitrarily, and are not a good fit for all possible codes,
- requiring users to explicitly annotate detectors should remain a possibility, but is a tedious and error-prone process,
- there are ways to find detectors automatically.
Describe the solution you'd like We need to provide a way for users to automatically add detectors. This should be opt-in, as the automatic computation of detectors will likely, at least in the beginning, be driven by heuristics (i.e., not always correct/exhaustive), and because we want the library to provide the most control possible to the users that require it.
Describe alternatives you've considered For the moment, I am not sure how this should be implemented. I have a theoretical reformulation that works generally, but that is not convenient to compute and may be made more efficient. We also have very localised information: propagated Paulis are, in the current setup in which we only consider surface codes, very much local and cannot spread globally (in the spatial dimension). There might be a way to use that feature by considering the QEC at the plaquette level, before generating the actual circuit.
Finally, we will likely require another abstraction: "layer". It seems reasonable, at the moment and (again) in the setup we are considering, that a QEC is composed of a sequence of layers, each following the scheme:
0or1Moment (in thecirqsense) of reset,kMoments of computation with Clifford gates,0or1Moment of measurement.
Additional context
Hi Adrien,
My proposal for partially solving the "automatic construction of detectors" problem is as follows.
-
restrict yourself to error detection circuits with the property that any error in a given round is detected no later than the end of the next round, meaning detectors only consist of measurements chosen from at most 2 consecutive rounds. This means using reset gates after measurement gates, and assuming all stabilizers are measured once per round, but I can certainly live with those 2 restrictions.
-
in each round of error detection, start with each reset gate, insert a Z operator after it, and propagate it forward to the end of the round. Mark any measurements that have a Z right before them as commuting measurements. Mark any measurements that have an X or Y before them as anti-commuting measurements. Save the list of data qubits with nontrivial propagated operators on them. Call this object an end stabilizer.
-
in each round of error detection, start with each measurement gate, insert a Z operator before it, and propagate it backward to the beginning of the round. Mark any resets that have a Z right after them as commuting resets. Mark any resets that have an X or Y right after them as anti-commuting resets. Save the list of data qubits with nontrivial propagated operators on them. Call this object a beginning stabilizer.
-
initially focus on end and beginning stabilizers with no anti-commuting measurements. Try to find end stabilizers in one round that match beginning stabilizers in the next round. The associated commuting measurements form detectors. Remove these end and beginning stabilizers from the pool to be considered.
-
in the pool of remaining end and beginning stabilizers, search for sets of end stabilizers that disjointly cover a beginning stabilizer, and sets of beginning stabilizers that disjoint cover an end stabilizer. This is common at the end of the memory experiment when you measure all of the data qubits directly. The individual beginning stabilizer data qubit measurements will disjoint cover an end stabilizer from the previous round.
-
in most situations, your work will be done, but let's continue to discuss some rarer cases. It is possible that you are left with end stabilizers that have anti-commuting measurements. Search for pairs of these that when combined form an end stabilizer with only commuting measurements. If the pairing is unique, form this new combined end stabilizer and remove the pieces that made it from consideration. If there are any left, search for groups of three end stabilizers, and so on. Throw an error if things get too expensive.
-
do the same thing with the beginning stabilizers, search for pairs that can be combined to make new beginning stabilizers with only commuting measurements.
-
repeat steps 4) and 5) with these new assembled beginning and end stabilizers. Removing pieces that lead to detection events.
Some additional considerations. Some codes make use of gauge operators that are not stabilizers and need to be assembled in groups. For the moment let's not deal with this, but you can in principle study these operators and the nearby operators that they anti-commute with, and form a graph, and look for cycles in the graph, and find the sets of gauge operators that form stabilizers.
Please let me know if there are any questions about the above.
Regards, Austin.
On Fri, Mar 22, 2024 at 1:09 AM Adrien Suau @.***> wrote:
Is your feature request related to a problem? Please describe. Currently, the tqec library requires users to explicitly implement the detectors. To ease that process, detectors are automatically included in Plaquette instances for the "default" situation, when that makes sense. But this way of adding detector is not optimal:
- the "default" detectors have been chosen arbitrarily, and are not a good fit for all possible codes,
- requiring users to explicitly annotate detectors should remain a possibility, but is a tedious and error-prone process,
- there are ways to find detectors automatically.
Describe the solution you'd like We need to provide a way for users to automatically add detectors. This should be opt-in, as the automatic computation of detectors will likely, at least in the beginning, be driven by heuristics (i.e., not always correct/exhaustive), and because we want the library to provide the most control possible to the users that require it.
Describe alternatives you've considered For the moment, I am not sure how this should be implemented. I have a theoretical reformulation that works generally, but that is not convenient to compute and may be made more efficient. We also have very localised information: propagated Paulis are, in the current setup in which we only consider surface codes, very much local and cannot spread globally (in the spatial dimension). There might be a way to use that feature by considering the QEC at the plaquette level, before generating the actual circuit.
Finally, we will likely require another abstraction: "layer". It seems reasonable, at the moment and (again) in the setup we are considering, that a QEC is composed of a sequence of layers, each following the scheme:
- 0 or 1 Moment (in the cirq sense) of reset,
- k Moments of computation with Clifford gates,
- 0 or 1 Moment of measurement.
Additional context
- @inmzhang answer in a PR https://github.com/QCHackers/tqec/pull/100#issuecomment-1952002691
- Inplace Access to the Surface Code Y Basis (Appendix C) https://arxiv.org/abs/2302.07395
— Reply to this email directly, view it on GitHub https://github.com/QCHackers/tqec/issues/199, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKAXTCSQSUGNX6WVCGOQILYZPRKXAVCNFSM6AAAAABFC3U2WWVHI2DSMVQWIX3LMV43ASLTON2WKOZSGIYDCOJSGYYTEOA . You are receiving this because you are subscribed to this thread.Message ID: @.***>
I'll start working on this when I have time. As a starting point, I will try to implement exactly what Austin proposed, which I think should be sufficient for the near-term goal.
Sorry for taking such a long time. I have done most of the work except for the anticommute grouping and several edge cases. Hopefully I'll complete the remaining stuff and start iterating on the design in this week.