Fix reset and measurement gates being wrongly applied when moving

[nelimee]

The initial comments on #100 raised a few very valid points that are not fixed yet. This issue document one of them.

Relevant part of the original comment:

• The glue between different layers remains a cumbersome aspect. Maybe we can use some strategy pattern to specify how to merge /rewrite operations at the temporal boundaries when integrating different layers. For example, we can define a strategy to eliminate the reset operations for the already-in-use qubits when stacking an initialization layer onto a memory layer.

Originally posted by @inmzhang in https://github.com/QCHackers/tqec/pull/100#pullrequestreview-1887608426

Is your feature request related to a problem? Please describe. Moving a logical qubit requires a few manipulation on Plaquette instances. Let's take the example below

Going from 1 to 2 has no issue. Plaquette instances that are used in 2 automatically reset their syndrome qubit by default https://github.com/QCHackers/tqec/blob/47cb5e9712ab02959df9e2ce552cf8c663a2b110/src/tqec/plaquette/library/utils/pauli.py#L10-L56 but this reset gate can be tagged to be merged automatically afterwards like https://github.com/QCHackers/tqec/blob/47cb5e9712ab02959df9e2ce552cf8c663a2b110/src/tqec/plaquette/library/measurement.py#L29

[!NOTE]
Turns out the reset is not tagged, a follow-up issue will be opened to address that.

Changing 2 into 3 is a little bit more challenging, because we need to apply initialisation plaquettes to the qubits to the right (in the example above), but we also need to avoid resetting the data qubits highlighted in blue.

Finally, changing 3 into 4 has the same issue, but with measurements: we need to apply the measurement plaquettes but also need to make sure that the data qubits highlighted in blue are not measured, as they are still used.

Describe the solution you'd like I have no preference, as long as we are able to make that work, if possible elegantly, I am fine with the solution.

Describe alternatives you've considered None of the following alternatives have been tested yet:

1. As noted in the comment cited at the beginning of this issue, maybe find a clever way to remove reset and measurement gates in some conditions. My main concern here is that I think this will be tricky to get predictable, easy to explain to a potential user, and right in all cases.
2. We may also try to make the initialisation and measurement plaquettes aware of that kind of situations (e.g., adding a PlaquetteSide argument somewhere that would be either the side of the plaquette that should be kept or the one that should be reset/measured).

[nelimee]

Note that potential solution number 2 above is not enough: we do not want to have to re-define specific Template instances to be able to apply different plaquettes as this is the main pain point found by implementing the qubit movement in #81 and #100.

This additional restriction leaves us with very little freedom to implement something, and I can only see option 1 (automatically removing the operations in some way) if we want to avoid creating a (or several) new Template and Plaquette instances.

[smburdick]

I'd like to help out with the backend some more, so I can look into this.

[nelimee]

One more piece that might be important for this one: we can consider logical qubits to have assigned positions on the physical qubit grid. In the grid above, Template instances are drawn in blue, and it is reasonable to limit ourselves to logical qubits that can only be within a red square. In other words, logical qubits are arranged on a grid.

Feel free to discuss what you plan to do here, both @inmzhang and myself have implemented the qubit movement and so we might be able to see if there is any shortcoming early.

[nelimee]

@smburdick any update on that issue?

[afowler]

Sam is out this week, can anyone else help?

On Tue, May 7, 2024 at 12:31 AM Adrien Suau @.***> wrote:

@smburdick https://github.com/smburdick any update on that issue?

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

[nelimee]

Sam is out this week, can anyone else help?

Let's wait for Sam on that. I can start hacking, but I do not want to re-do things that Sam already did on his side without pushing online, and as he assigned to this issue he should have the priority.

[nelimee]

@smburdick have you started to look at that issue on your side?

If not, I am thinking about coming back to it and try to find a reasonable solution to this long-standing issue that is currently blocking most of the interesting developments.

If you did think about it / write code to solve it, could you share your work?

[smburdick]

@nelimee I haven't had time recently due to my personal life, and being more focused on the frontend. I don't know if I'll have time to in the next couple of weeks.

[nelimee]

@nelimee I haven't had time recently due to my personal life, and being more focused on the frontend. I don't know if I'll have time to in the next couple of weeks.

If this is fine for you, I will assign myself to that issue then. Thanks for answering :)

[nelimee]

Closing this issue as we are changing the way we think about movement. Rather than a movement, it is a merge of 2 logical patches.