Integrate automatic detector computation into `tqec`

[nelimee]

Is your feature request related to a problem? Please describe. #249 aims at including in the code base a generic way to automatically compute detectors from a given quantum circuit checking some pre-conditions. The implementation in #249 is voluntarily disconnected from the main tqec library, to be able to extract it as an independent library if we think this might be useful to the QEC community. But this disconnection implies that, for the moment, automatic detector computation does not use the additional knowledge provided by the tqec library.

In particular, if #249 is merged without significant changes, the workflow that will need to be followed is the following:

1. Create the necessary plaquettes and templates.
2. Assemble the created plaquettes and templates into a structure representing the QEC computation.
3. For each code distance d and noise model e:
   1. Create the quantum circuit representing the QEC computation.
   2. Compute detectors over the whole quantum circuit and add the computed detectors to the circuit.

Even though detector computation is quite efficient most of the time, the computation might get very expensive on large code distance.

Describe the solution you'd like In practice, it might not be needed to perform detector computation at step 3.2. over the whole circuit. Using knowledge on the code locality (e.g., detectors can only include measurements that are within a ball of radius X in space around a central point, and maximum Y temporal steps before the current step), we might be able to extract from the representation obtained after step 2. a limited number of sub-circuits (subsets of templates with plaquettes) that:

1. are centered on a specific plaquette (i.e., one index particular location in a template that will be replaced with a plaquette),
2. for each sub-circuit, only include plaquettes that are at a distance X from the center plaquette,
3. cover each plaquette in the template.

Basically, finding local (both in time and in space) regions that should contain at least one detector involving a defined central measurement, computing the detector for each of these regions, and re-using the computation when the same local region is found multiple times in the QEC computation.

[afowler]

+1 for this approach. It should be possible to calculate detectors for scalable circuits, meaning at the template level, not for every different code distance and every round of the computation, since the circuits we construct ourselves have such a regular structure.

On Fri, Jun 28, 2024 at 2:10 AM Adrien Suau @.***> wrote:

Is your feature request related to a problem? Please describe. #249 https://github.com/QCHackers/tqec/pull/249 aims at including in the code base a generic way to automatically compute detectors from a given quantum circuit checking some pre-conditions. The implementation in #249 https://github.com/QCHackers/tqec/pull/249 is voluntarily disconnected from the main tqec library, to be able to extract it as an independent library if we think this might be useful to the QEC community. But this disconnection implies that, for the moment, automatic detector computation does not use the additional knowledge provided by the tqec library.

In particular, if #249 https://github.com/QCHackers/tqec/pull/249 is merged without significant changes, the workflow that will need to be followed is the following:

1. Create the necessary plaquettes and templates.
2. Assemble the created plaquettes and templates into a structure representing the QEC computation.
3. For each code distance d and noise model e:
   1. Create the quantum circuit representing the QEC computation.
   2. Compute detectors over the whole quantum circuit and add the computed detectors to the circuit.

Even though detector computation is quite efficient most of the time, the computation might get very expensive on large code distance.

Describe the solution you'd like In practice, it might not be needed to perform detector computation at step 3.2. over the whole circuit. Using knowledge on the code locality (e.g., detectors can only include measurements that are within a ball of radius X in space around a central point, and maximum Y temporal steps before the current step), we might be able to extract from the representation obtained after step 2. a limited number of sub-circuits (subsets of templates with plaquettes) that:

1. are centered on a specific plaquette (i.e., one index particular location in a template that will be replaced with a plaquette),
2. for each sub-circuit, only include plaquettes that are at a distance X from the center plaquette,
3. cover each plaquette in the template.

Basically, finding local (both in time and in space) regions that should contain at least one detector involving a defined central measurement, computing the detector for each of these regions, and re-using the computation when the same local region is found multiple times in the QEC computation.

— Reply to this email directly, view it on GitHub https://github.com/QCHackers/tqec/issues/259, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKAXTAHP5MZ4AGT73S47UDZJUSBPAVCNFSM6AAAAABKBO6L6CVHI2DSMVQWIX3LMV43ASLTON2WKOZSGM3TSOJWGE4DEMQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>