single_qubit_state_tomography issues with multiple key measurements

[kygnz]

Issue:

When trying to run single_qubit_state_tomography on a CircuitOperation object that contains measurements, my group and I run into the error "cannot extract 2D measurements for repeated keys". Upon observing the file qubit_characterizations.py, we found the issue lies in the function definition of single_qubit_state_tomography, with rho_11, rho_01_im, and rho_01_re initialized using results.measurements. Changing the lines to results.records eliminates the error. Is this an unintended bug in the tomography function?

How to recreate the issue:

import cirq
import cirq.experiments
import sympy

qubits = cirq.LineQubit.range(3)
circuit = cirq.Circuit()

circuit.append(
    [
        cirq.X(qubits[0]),
        cirq.X(qubits[1]),
        cirq.X(qubits[2]),
    ]
)


circuit.append(
    [
        cirq.measure(qubits[0], key="a"),
        cirq.measure(qubits[1], key="b"),
        cirq.measure(qubits[2], key="c"),
    ]
)

a, b, c = sympy.symbols("a,b,c")
sympy_cond = cirq.SympyCondition(sympy.Eq(a + b + c, 0))


print(circuit)
sim = cirq.Simulator()

circuitBuilt = cirq.Circuit(
    cirq.CircuitOperation(
        circuit=circuit.freeze(),
        repeat_until=sympy_cond,
        use_repetition_ids=False,
    )
)

print("\n------------------- single qubit state tomography -------------------")
# Without updating qubit_characterizations.py, tomography_result produces an error
tomography_result = cirq.experiments.single_qubit_state_tomography(
    sim, qubits[0], circuitBuilt, 1000
)

print(tomography_result.data)

Cirq Version:

1.5.0

[dstrain115]

Discussion from cirq cync. This issue is asking for the single qubit tomography experiment to support circuits where there are intermediate measurements. This seems like it would be a reasonable request, but we should clarify in the documentation how this works, and what it is doing on the tomography on in this case where there are repeated measurements.

[mhucka]

@kygnz Can you confirm that Doug's explanation is your intention?

We'd also appreciate any other elaboration and details you can provide about what you're trying to do and how you ran into this.

[daxfohl]

Historical context: single_qubit_state_tomography was written years before Result.record field was created to support subcircuits with loops (or more specifically, circuits with multiple measurements to the same key). I'm not familiar with tomography, but from a quick look at the function, it only reads the z key, which it manually appends to the circuit so there will only be one measurement to that key, so it seems like changing measurements to records there would be the correct fix: it doesn't matter that other keys are repeated; all it cares about is the final z. (Though it should also probably handle the case where the circuit already defines a z key).

Until then as workaround, I see your circuit sets use_repetition_ids=False. I believe if you set use_repetition_ids=True, that will cause each measurement of the loop to go to a separate key, which I'm pretty sure won't fail when single_qubit_state_tomography calls result.measurements under the hood.

Update on workaround: oh wait, does repeat_until require use_repetition_ids=False? IIRC it might. If so, maybe that's something that could be improved. The subcircuit should be able to inject the current repetition id when it's testing the repeat_until condition (if it doesn't already; can't remember).

[kygnz]

@mhucka Yes, Doug's explanation captures the core of the problem! A bit of context, my team and I are implementing the purification algorithm for distilling |M〉as found here
and we want to use tomography on our resulting state to confirm we are implementing it correctly (the example snippet I provided is a simple recreation of the issue, not our full code)

[kygnz]

@daxfohl Thanks for the context! Yes, for our circuit when I don't set the repetition ids parameter to False I get the error: ValueError: Cannot unroll circuit due to nondeterministic repetitions

I don't mind making the fix if no one has claimed/been assigned to it yet!

[mhucka]

@kygnz Thank you for your interest and willingness to take this on. I've assigned the issue to you.