QASM3 Import/Export: name '$3' is not defined in this scope

[ArfatSalman]

Environment

• Qiskit Terra version: {'qiskit-terra': '0.23.1', 'qiskit-aer': '0.11.2', 'qiskit-ignis': None, 'qiskit-ibmq-provider': '0.20.0', 'qiskit': '0.41.0', 'qiskit-nature': None, 'qiskit-finance': None, 'qiskit-optimization': None, 'qiskit-machine-learning': None}
• Python version: Python 3.9.12
• Operating system: MacOS Ventura 13.1

What is happening?

When a coupling map is provided, the QASM3 exporter add a $3

OPENQASM 3;
include "stdgates.inc";
bit[9] cr;
rz(6.163759533339787) $3; // <----- THIS

Without the coupling map (as in skipping it in the transpile step), there's no error:

OPENQASM 3;
include "stdgates.inc";
bit[9] cr;
qubit[9] _all_qubits;
let qr = _all_qubits[0:8];
rz(6.163759533339787) qr[3];

How can we reproduce the issue?

from qiskit import transpile
from qiskit import QuantumCircuit, ClassicalRegister, QuantumRegister
from qiskit.circuit.library.standard_gates import *


qr = QuantumRegister(9, name='qr')
cr = ClassicalRegister(9, name='cr')

qc = QuantumCircuit(qr, cr, name='qc')
qc.append(RZGate(6.163759533339787), qargs=[qr[3]], cargs=[])

coupling_map=[[0, 1], [0, 2], [0, 7], [0, 9], [1, 0], [1, 6], [1, 8], [1, 11], [2, 0], [2, 4], [3, 9], [4, 2], [4, 5], [5, 4], [6, 1], [7, 0], [8, 1], [9, 0], [9, 3], [9, 10], [10, 9], [11, 1]]


qc = transpile(qc, coupling_map=coupling_map)

from qiskit.qasm3 import loads, dumps
qc = loads(dumps(qc))

What should happen?

The QASM2 exporter/importer works. So I was expecting this to work as well.

Any suggestions?

No response

[jakelishman]

This is expected behaviour: physical qubits are not yet supported by the OpenQASM 3 importer, but we are in the process of adding them (Qiskit/qiskit-qasm3-import#2).

I should note that OpenQASM 3 support in Qiskit is for interoperability with other places; it is not expected to be a lossless way to write a circuit to disk and then load it back into Qiskit. For that, you should look at QPY (qiskit.qpy) or Python's builtin pickle module.

[ArfatSalman]

I'm reading the QASM3 docs and I am not able to find things that are not supported (for ex. with regards to QASM2). By any chance, is there any (public) list available?

Thanks for the quick reply! 😊

I'll take a look at QPY!

[jakelishman]

It's a bit of a funny situation, to be honest. OpenQASM 3 is still quite a new language, which brings a lot of new features for describing dynamic circuits. Qiskit has support for some of these features (but not too many yet - we're working on it!), and hardware has support for some as well, but often those two things don't quite line up.

In this case, the problem is that OpenQASM 3 as a language has a distinction between a "physical" qubit (one that corresponds exactly to a particular piece of hardware) and a "virtual" qubit (more like what we think of in the mathematics of quantum computing - these can freely be interacted with any other qubit in the circuit, and we don't worry about hardware). One of the principal jobs of Terra, via transpile, is to map a user's description of a "virtual" circuit to a "physical" circuit. OpenQASM 3 then gives us the language feature to describe that we've done this, as you've found: we swap from emitting instructions based on qubit identifiers to using the hardware-qubit literals $0 and so on.

That's quite easy to do when we're exporting, but historically, Qiskit has never been able to read in circuits that are already mapped to hardware. There is a hacky "convention" we use internally to ~kind of detect this sometimes with OQ2, but it's not good. The work in the PR I linked above is our effort to add the proper way of doing this to the import, but it goes hand-in-hand with other work also happening on Terra itself to stabilise the interfaces surrounding hardware-mapped circuits (e.g. #9486). That's why we didn't launch with this support in place yet; Terra hasn't fully stabilised its interface, so we'd be trying to hit a moving target.

The inability to import physical qubits back to Terra is the only place I know of where the OpenQASM 3 importer doesn't have support for something that Terra does support. It's possible there are more, but if so, I didn't think about them when I wrote the importer. Most of the things that we don't support from the OpenQASM 3 language specification are because Terra itself can't represent them.

[jlapeyre]

physical qubits are not yet supported by the OpenQASM 3 importer

reading the QASM3 docs and I am not able to find things that are not supported (for ex. with regards to QASM2)

Are we confusing two different things in the comments here? When @jakelishman first mentioned "unsupported", he did not mean than OpenQASM3 (OQ3) does not support some things. He meant that the Qiskit importer of OQ3 does not support some features in the spec for OQ3.

Differences between the specs for OQ2 and OQ3 is another matter. A list of difference would be a good idea. You might want to open an issue on the openqasm GH repo if you don't already find one. The paper, arxiv:2104.14722 goes into more detail, I think. But it is somewhat out of date.

[ArfatSalman]

Thank you for your detailed response @jakelishman and @jlapeyre.

He meant that the Qiskit importer of OQ3 does not support some features in the spec for OQ3.

I think I mis-wrote. I understand the distinction between Qasm3 (the spec) and Qasm3 (the importer). Sorry for that.

Is this issue (Qiskit/qiskit-qasm3-import#8) also an example of lack of support by the importer?

[jakelishman]

Your other linked issue is a lack of support by the importer yeah, with the added complication that Terra can represent a very limited subset of OQ3 subroutine definitions, but it's not a very clean mapping at all. For now, I think our priorities will probably not be to add support for that in the importer, because it'd end up quite messy since we'd need to disentangle a lot of stuff that Terra doesn't really support, and our larger goal is to have Terra's abilities drive the importer's, not try and shoe-horn partial stuff.

[jakelishman]

Support for hardware qubits in the base OQ3 exporter was released some time ago now, so I'll close this issue as completed.