qasm3 returns wrong results with pauli evolution gate

[LenaPer]

When trying to turn this circuit into a qasm3 :

from qiskit.circuit import QuantumCircuit, ParameterVector
from qiskit.circuit.library import PauliEvolutionGate
from qiskit.quantum_info import SparsePauliOp
from qiskit.qasm3 import dumps, loads, dump, load

t = ParameterVector("t", 3)
X, Y, Z = SparsePauliOp("X"), SparsePauliOp("Y"), SparsePauliOp("Z")
op1, op2, op3 = (X^X), (Y^Y), (Z^Z)
evo1 = PauliEvolutionGate(op1, time=t[0])
evo2 = PauliEvolutionGate(op2, time=t[1])
evo3 = PauliEvolutionGate(op3, time=t[2])
 
dec0 = QuantumCircuit(2)
dec0.append(evo1, range(2))
dec0.append(evo2, range(2))
dec0.append(evo3, range(2))
dec0.count_ops() #returns OrderedDict([('PauliEvolution', 3)])

after dumping into a qasm3, we would expect the qasm to have 3 different gates for the XX, YY, ZZ but it only looks into the first Pauli evolution gate and repeats it 3 times :

q0 = dumps(dec0)
print(q0)
#returns 
OPENQASM 3.0;
include "stdgates.inc";
input float[64] _t_0_;
input float[64] _t_1_;
input float[64] _t_2_;
gate rxx_4948547280(_t_0_) _gate_q_0, _gate_q_1 {
  h _gate_q_0;
  h _gate_q_1;
  cx _gate_q_0, _gate_q_1;
  rz(2.0*_t_0_) _gate_q_1;
  cx _gate_q_0, _gate_q_1;
  h _gate_q_1;
  h _gate_q_0;
}
gate PauliEvolution(_t_0_) _gate_q_0, _gate_q_1 {
  rxx_4948547280(2.0*_t_0_) _gate_q_0, _gate_q_1;
}
qubit[2] q;
PauliEvolution(_t_0_) q[0], q[1];
PauliEvolution(_t_1_) q[0], q[1];
PauliEvolution(_t_2_) q[0], q[1];

[LenaPer]

It looks like the same problem as in #7335 but the workaround doesn't work for this specific example. It might be because the op doesn't appear in the name or in the parameters and fall through the cracks of the fix.

print(evo1.params, evo1.name)
# returns [ParameterVectorElement(t[0])] PauliEvolution

[jakelishman]

Thanks for the report. It looks like the OpenQASM 3 exporter still maintains a lot of the same problems that the OpenQASM 2 exporter used to have until we fixed a whole load of them in #9953 - this kind of duplicate definition / bad definition reuse / whatever used to be rife in the old one as well. I'm not sure of a timespan for when we'll get this entirely fixed, but I think such a fix will tie into the implementation of #10737, since to handle exporting against multiple possible library files, we'll need to rethink how we do the definition decomposition quite heavily.

[jakelishman]

This should be fixed by #12776 for PauliEvolutionGate.