QASM3 dumps / loads rzz issue

[barakatzir]

Environment

• Qiskit version: qiskit v1.2.4, qiskit-qasm3-import v0.5.0, openqasm3 v0.5.0, antlr4-python3-runtime v4.13.2
• Python version: 3.12.4
• Operating system: Ubuntu 24.0

What is happening?

Dumping loading and dumping again yields a different QASM3, with the wrong rzz custom gate definition (with fixed angle). While the circuit is technically correct this makes reasoning about the result of dumping and loading qasm3 files harder.

How can we reproduce the issue?

from qiskit import QuantumCircuit
from qiskit.qasm3 import loads, dumps
import math

circ = QuantumCircuit(4)
circ.rx(0.3, range(4))
for i in (0, 2, 1):
    circ.rzz(math.pi/6, i, i+1)

circ_qasm = dumps(circ)
print(dumps(loads(circ_qasm)))

new_rzz_instruction = loads(dumps(loads(circ_qasm)))[4]
assert new_rzz_instruction.name == 'rzz'
print(f"{new_rzz_instruction.is_standard_gate() = }")

output

OPENQASM 3.0;
include "stdgates.inc";
gate rzz(_gate_p_0) _gate_q_0, _gate_q_1 {
  cx _gate_q_0, _gate_q_1;
  rz(pi/6) _gate_q_1;
  cx _gate_q_0, _gate_q_1;
}
qubit[4] q;
rx(0.3) q[0];
rx(0.3) q[1];
rx(0.3) q[2];
rx(0.3) q[3];
rzz(pi/6) q[0], q[1];
rzz(pi/6) q[2], q[3];
rzz(pi/6) q[1], q[2];

new_rzz_instruction.is_standard_gate() = False

note that the custom rzz gate has a fixed angle

What should happen?

The gate in QASM3 should be defined as

gate rzz(p0) _gate_q_0, _gate_q_1 {
  cx _gate_q_0, _gate_q_1;
  rz(p0) _gate_q_1;
  cx _gate_q_0, _gate_q_1;
}

Any suggestions?

No response

[jakelishman]

This is unfortunately a bit of a problem in the Qiskit data model around parametric gates - we can't, generally, tell from a given QuantumCircuit how to get its definition in terms of arbitrary parameters if we only see it called with a fixed parameter, and we can't in general be certain that any given parametric gate statement defines a gate that's properly consistent with a Qiskit standard-library gate. rzz isn't in stdgates.inc, so we have to define the gate in the file, but on reload, we can't tell that it's a standard-library gate (as opposed to some other gate that the user just called rzz), which means we don't risk doing the wrong thing by silently switching to our version of RZZGate.

The underlying issue is the same data-model thing alluded to in #9428. We have some plans to improve the situation for Qiskit built-in gates that aren't in the OpenQASM standard libraries in #10737, but we've not had chance to implement that yet. The OpenQASM 3 importer also hasn't been prioritised for a long time, so it sadly doesn't have much of the work-around functionality that the OpenQASM 2 importer has for dealing with these situations better - we also want to improve that, it'll just take time.

Fwiw, OpenQASM 3 is always going to be a lossy serialisation format for QuantumCircuit - we try what we can to represent a circuit in valid OpenQASM 3, and to map valid OpenQASM 3 back to Qiskit concepts, but the mappings are very much not 1:1, so things always get changed between the export and the import.