Wrong outcome using c_if on simulator

[fvarchon]

Informations

• Qiskit Aer version: 0.12.0 (local) & 0.12.1 (Quantum Lab)
• Python version: 3.10.4 (local)
• Operating system: Win11

What is the current behavior?

Wrong outcome using c_if instead of if_test + reset on simulators. Correct outcome on real systems

Steps to reproduce the problem

Executing this circuit :

qr = QuantumRegister(2,'q')
q0_value = ClassicalRegister(1,"q0_value")
q1_value = ClassicalRegister(1,"q1_value")
qc = QuantumCircuit(qr,q0_value,q1_value)

qc.h(0)
qc.cx(0,1)
qc.measure(1,q1_value)
qc.barrier()
qc.reset(0).c_if(q1_value,0)
#with qc.if_test((q1_value,0)):
#    qc.reset(0)
qc.barrier()
qc.measure(0,q0_value)

leads to a wrong outcome (for example {'0 0': 1015, '1 0': 1016})

What is the expected behavior?

Results should be like {'0 0': 1015, '1 1': 1016}.

The correct answer is obtained if one use if_test + reset (see code in comments above)
The correct answer is obtained using c_if or if_test + reset on real systems

[hhorii]

Originally (until 0.11.*), Aer did not support c_if for reset operation in qobj (error: Failed to load qobj: Invalid instruction: "reset" cannot be conditional.). Now we do not use qobj and AerCompiler generates AER::circuit directly and ignore c_if for reset while converting reset of Qiskit to of AER::circuit. We should raise exception when c_if comes for reset in AerCompiler or add support c_if for reset.

@jakelishman Is there specification about coverage of c_if in terra? I think that simulator can support c_if for reset (but hardware may not). If so, I would like to add support of c_if otherwise raise an exception as previous Aer did.

[jakelishman]

There's no reason in Terra that reset can't have a condition, so it's up to hardware vendors to support it or not. Aer should feel free to support it. For what it's worth, IBM dynamic-circuits hardware tends to implement "mid-circuit reset" as a measurement followed by a conditional (c_if-like) X.