Closed jyu00 closed 6 months ago
This affects API-only users sending qasm to our (Runtime) APIs. The cloud transpilation service is also affected, and returns non-ISA circuits for some circuits & users. Please do assign priority to this issue in users' interest.
I'll look into this. We will most likely have to add an extra keyword argument to the importer functions, because OpenQASM 3 itself simply doesn't have enough information to fully represent things - say, in the example program at the top, the circuit uses only as high as $14
, but the hardware has an actual number of qubits it wants to be present in the circuit more like 127.
New keyword arguments (to make the full-width circuit) are new features, and they should wait until Qiskit 1.1 (May), but what we can do in the interim is fix the bug where the importer isn't making the output circuit at least as wide as the highest physical qubit used, and then it should be an easy change for IBM primitives to add on extra dummy qubits to make it full width (if they need circuits to contain them).
I think that's probably the least risky path forwards here, for the timescales.
Qiskit Runtime primitives now requires ISA circuits. But running an OpenQASM3 circuit fails due to the importer not setting the qubit mapping correctly.
Code to recreate:
shows the
ecr
gate was applied to the physical qubits:But if I re-import that,
circuit.data
uses qubits 0-5:shows