New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement automatic detector computation #199
Comments
Hi Adrien,
My proposal for partially solving the "automatic construction of detectors"
problem is as follows.
1) 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.
2) 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.
3) 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.
4) 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.
5) 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.
6) 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.
7) do the same thing with the beginning stabilizers, search for pairs that
can be combined to make new beginning stabilizers with only commuting
measurements.
8) 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
<#100 (comment)>
- 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
<#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. |
@inmzhang any update on that issue? |
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. |
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 inPlaquette
instances for the "default" situation, when that makes sense. But this way of adding detector is not optimal: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
or1
Moment (in thecirq
sense) of reset,k
Moments of computation with Clifford gates,0
or1
Moment of measurement.Additional context
The text was updated successfully, but these errors were encountered: