Projective Measurement of entangled qubit in Clifford representation

[timneumann1]

I am trying to implement a networking simulation to generate a certain stabiliser state in the Clifford formalism. As part of the simulation, I need to perform a CNOT gate with the target qubit being part of a Bell pair, as in

apply!((network[ri,q1], network[ri,1]), QuantumSavory.QuantumClifford.sCNOT) ,

where network was set up in the Clifford representation, network[rj,1] is entangled with network[ri,1], and network[ri,q1] is supposed to be the control. This yields the following error:

LoadError: An attempt was made to measure a projection observable while using Clifford representation for the qubits. However, the qubits that are being observed are entangled with other qubits. Currently this is not supported. Consider tracing out the extra qubits or using Pauli observables that do not suffer from this embedding limitation. Message us on the issue tracker if you want this functionality implemented.

I am unsure if there is an obvious fix, but since the error message explicitly suggests to mention this feature request here, I was wondering whether an implementation of entangled qubit measurements in the Clifford regime would be possible. If there is a simpler fix that I haven't considered, I would be happy to hear about it!

For context, the code I am working with the following code setup:

@resumable function bell_pair(sim, network, ri, rj)
    eprot = EntanglerProt(sim, network, ri, rj; pairstate=noisy_pair, chooseslotA=1, chooseslotB=1, rounds=1, success_prob=1.)
    @process eprot()
end

@resumable function apply_remote_CNOT(sim, network, ri, rj, q1, q2)
    [...]
    # Create Bell Pair between first qubits of registers i and j
    @process bell_pair(sim, network, ri, rj)
    [...]

    # Perform CNOT telegate between qubits q1 and q2
    apply!((network[ri,q1], network[ri,1]), QuantumSavory.QuantumClifford.sCNOT) 
    @yield timeout(sim, two_qubit_gate_execution_time)
    m1 = project_traceout!(network[ri,1], Z)
    @yield timeout(sim, projective_measurement_time)
    if m1 == 2
        apply!(network[rj,1], X)
        @yield timeout(sim, single_qubit_gate_execution_time)
    end
    # Teleported CNOT Gate
    [...]
end

@resumable function circuit(sim, network)
    initialize!(...)
    apply!(...)
    [...]
    **@yield @process apply_remote_CNOT(sim, network, 1, 2, 5, 2)**
    [...]
end

sim, network = simulation_setup(sizes, T2; representation = CliffordRepr)  
@process circuit(sim, network)

For some time, I thought the error came from the project_traceout! call, but it seems that the CNOT apply! call is the root.

Thank you!

[Krastanov]

Thanks for the report! There are a couple of quick workarounds and it seems like a good time to upstream these workarounds. I should have time later today to implement this and send you a few examples

[Krastanov]

Pardon the slow response. Again, thanks for the report -- such reports are very helpful as we are trying to push out a first non-alpha version in the next couple of months.

I moved this issue to the QuantumSavory repository, as it is more about how QuantumSavory wraps around a backend, not about the particular backend.

A couple of points that can generally help diagnose things faster:

1. Do not elide pieces of the example code, just post the entirety of the code. Of course, it is nice if important points are highlighted
2. Post the stack trace. Especially when the code that triggers the error is not shared, it becomes quite difficult to help without a stack trace.
3. Share the versions of julia and of the library that you are using. E.g. versioninfo() and Pkg.status().

A minor note on QuantumSavory idioms:

1. I see you are using QuantumClifford.sCNOT. QuantumSavory on purpose does not export this symbol. Backends are meant to be something the user does not need to worry about. Just using CNOT which is exported from QuantumSavory by default (and implemented in QuantumSymbolics) should be enough. The conversion is handled automatically behind the scenes. That also permits your code to work with any other backend without having to change it, e.g. if you want to model slighly-nonclifford dynamics. We permit using the backends directly in case someone needs to hack together something unsupported and for general flexibility, but we should probably set up a warning when a user does that.

Getting to the actual issue, my guess it is two unrelated things:

• You are using observable somewhere in your code, which does not have full functionality under the Clifford backend.
• The @resumable macro has mangled the line numbers and the error caused by observable is printed with an incorrect line number, making it look like another line caused the error. This is a known debugging issue with ResumableFunctions.jl (and generally with complicated macros). It seems plausible that the debugging issue will be fixed in an upcoming julia version in the next year.

Could you confirm whether you call the function observable directly yourself? If not, then the problem might be different, but I would need the example code and a stack trace to continue debugging. If you are worried about showing current research projects publicly, you can also send it over email.

If you are using observable, the error probably comes from observable(some_register_slots, projector(StabilizerState(...))) where you have an entangled state bigger than the state you are projecting on. This is generally a rather complicated operation to compute, and also a relatively inefficient one. We have some of the fast cases implemented, but never bothered with the general case. I have a PR for the general case almost ready, I will post it here when it is done.

In the meantime, a very quick and mathematically equivalent way to get around this is to not use projector as your observable, but rather use a Pauli operator. For instance, if you want to study entangled Bell pairs, have one observable(..., X⊗X) and one observable(..., Z⊗Z). Besides much easier to compute, we can also pretend that it is anyway a better idea to do that, because it gives you more information about the type of infidelity you have.