Closed jlapeyre closed 1 year ago
Copied over from the issue I was writing about this:
The Terra exporter can put out circuits that are fully mapped to hardware. In this form, the output program contains no qubit ...[];
declarations, and only uses OQ3's way of referring to hardware qubits, i.e. $0
, $1
, etc.
The importer could be extended to handle this, since trying to re-import circuits output by Qiskit's exporter is likely something people will quickly try to do.
The exporter puts out hardware qubits if the circuit has a _layout
attribute set. Note that this attribute is quite likely to become public in some form or another for Terra 0.24, and we'll need to handle both if/when it does. The principle is that we will have the importer build up an implied Layout
to apply to the circuit at the end of the root visit method.
We should be able to do this in the existing single pass: we track whether we're in "physical", "virtual" or "unknown" qubit-addressing modes throughout the execution, and raise on any attempt to mix (see "Limitiations" below). In "physical" mode, we can implicitly just add bits to the circuit as required when we see a new hardware identifier, and add a link between that bit instance to the hardware-qubit number in both the importer's symbol table and the tracked Layout
object.
This might need a little more thinking about inside the emission of nested control-flow blocks, since the importer uses the control-flow builder interface to handle those, but I think QuantumCircuit.add_bit
should still work on the outer circuit within those.
We shouldn't attempt to support programs that mix virtual and physical qubit uses. The semantics of such programs are not entirely clear in OQ3 as a language yet, and there's no need for us to start inventing things. If we see a mixture, we can just error out.
The code currently does not handle references to physical qubits in the OQ3 program.
I have not yet looked into this in detail, so I'm not sure if the following points are relevant.
We might need to allow specifying additional information, such as information for the
_layout
field of the circuit. But we have a very simple API at the moment and would like to keep it that way.Is there a problem with mixing physical and virtual qubits in the input OQ3?