Can we apply generalized pauli channel in parallel?

[ZhideLu]

If we want to model crosstalk in a QEC circuit using the leaky simulator and need to apply a generalized Pauli channel (GPC) to pairs of neighboring qubits. The idea would be to bind the channel to a two-qubit identity gate, for example:

"""
s = leaky.Simulator(4)
channel_2q = leaky.LeakyPauliChannel(is_single_qubit_channel=False)
channel_2q.add_transition(0x00, 0x10, 0, 1.0)

s.bind_leaky_channel(leaky.Instruction("I2", [0,1]), channel_2q)
s.do(leaky.Instruction("I2", [0, 1]))
"""

However, Stim does not recognize the "I2" instruction (two-qubit identity) and throws an error.
My Questions:

1. Is there a natural way to define a two-qubit identity gate in Stim that would serve as a dummy operation to attach the GPC?

2. Alternatively, we could directly apply " s.apply_2q_leaky_pauli_channel([0, 1], channel_2q)". But this doesn't support parallel application of channels on disjoint qubit pairs, which limits running speed in larger circuits. How to solve this problem ?

[inmzhang]

Hi, thanks for the issue!

Is there a natural way to define a two-qubit identity gate in Stim that would serve as a dummy operation to attach the GPC?

There is a two-qubit identity gate in Stim named II.

Alternatively, we could directly apply " s.apply_2q_leaky_pauli_channel([0, 1], channel_2q)". But this doesn't support parallel application of channels on disjoint qubit pairs, which limits running speed in larger circuits. How to solve this problem ?

Sorry but currently I do not have a good idea for this.

[ZhideLu]

Hi, yiming, thanks for your response.
Indeed, there is a two-qubit identity gate in Stim named "II". But I can't bind a 2-qubit GPC to this "II" gate. Maybe this is a bug that needs to be restored.

[inmzhang]

It's a new feature added in v1.15 of stim. I've updated the cpp/python dependency version of stim, hopefully it should work now. Need to wait for CI to finish and publish to pypi.

[ZhideLu]

Hi, yiming, thanks for your response.

Currently, leakysim only supports decomposing one- or two-qubit unitaries into generalized Pauli channels (GPCs).

Is it possible to extend this functionality to support decomposition of a four-qubit unitary into a GPC?

This would be particularly useful when modeling crosstalk between two simultaneous CZ gates, where four qubits are involved. Is there a recommended way to handle this scenario within the current framework?

[inmzhang]

Hi zhide, the feature you mentioned is indeed very important. I can take a further look and see whether I can quickly add the feature in the next few days.

[ZhideLu]

Hi, yiming, thanks so much for your help and quick response.

[ZhideLu]

hi, yiming, with a four-qubit GPC, is there a way to bind it to a gate in Stim? I understand that Stim only includes native gates for up to two qubits, so I’m unsure how to proceed.

[inmzhang]

Hi zhide, what I have in mind is that we can use a specialized stim gate with "tag" feature introduced in stim v1.15 to represent arbitrary GPCs. That will enable us decoupling the GPC from the other stim instructions. For example, we can use I[leaky<0>] 0 1 2 3 4 5 6 7 to denote that the 0th GPC channel should be acted on qubits 0..=7, if we initialize that channel with specified number of qubits as 4, then we can group the targets as 0 1 2 3 and 4 5 6 7 to do two independent 4-qubit GPC.

With that implemented, the simulator will take a vector of GPC to initialize without specifying the targets of the GPC. Every time we come across a I[leaky<n>] ... gate, we lookup the GPC from the initialization GPC vector and apply it to the targets in the instruction. We need to extend the apply_leaky_pauli_channel to arbitrary channel dimensions, which should be easy to do.

I've implemented most of the code mentioned above but there are still some bugs. I'm taking a vacation and will travel for a week starting from tomorrow. So there will be some time to finish this... By the way, when reviewing the code, I find the function to decompose the GPC is extremely messy and I'm quite unconfident about the correctness of it. Do you by any chance have written some code for that, if so, a PR to improve it is quite welcome.

[ZhideLu]

hi, yiming, I have reviewed your function for decomposing Kraus operators (one- or two-qubit) into GPCs, and overall it looks solid — there doesn’t seem to be any major issue. That said, I did notice a few areas where it could be improved or made more robust.

I’d be happy to open a pull request to contribute those changes, if that works for you!

[inmzhang]

Hi zhide, the code under dev branch seem to work for the method I mentioned above. I did not have time to fix some data structure/typing issues in GPC decomposition module therefore I temporarily removed it from that branch. Feel free to test on that branch, I think it can work for multiple-qubit channels (plz refer to the updated README under dev branch). There are definitely things can be improved considering some API designs, which I might work on when I come back from travel.

I’d be happy to open a pull request to contribute those changes, if that works for you!

That would be great, thanks!

[ZhideLu]

Hi, yiming, is there currently a function in leakysim to query the leakage status of specific qubits without performing measurements? For example, something like:

simulator.get_leakage_status([a1, a2])

to return whether qubits a1 and a2 are in the leaked state?

[inmzhang]

Hi zhide, I just pushed v0.4.0 of leaky, it should support the multi-qubit GPC though with potential bugs due to the lack of tests. And there is a property Simulator.leakage_status to get the current leakage status of the qubits. I'm sorry that there are many breaking changes in the apis. You can refer to https://github.com/inmzhang/leaky/blob/master/src/leaky/__init__.pyi for all the public apis.