♻️ Merging QuantumComputation and NAComputation`

[burgholzer]

We started the discussion on whether it makes sense to merge NAComputation into the existing QuantumComputation. As it stands right now, I would still argue that it makes sense to keep the concepts separate even though I see the duplication of code here. There are a few fundamental differences, that I want to list in the following. Most of the points are a consequence of that the QuantumComputation was primarily designed with SC and qiskit in mind.

• SC does not have the concept of zoned (global) operations. Hence, they are missing in the QuantumComputation. Even though this is not a deal breaker to add those, it may add additional checks to existing tools, whether a given QuantumComputation can be processed or not.
• The same holds for all shuttling operations. Again, even though it is not a deal breaker to add those to the QuantumComputation (which actually exist somewhere already created by Ludwig), this causes some changes in the infrastructure. For example, the standard output format of a QuantumComputation is QASM. However, QASM does not support shuttling operations. Me personally, I would be quite hesitant to add some custom syntax to QASM for shuttling operations as seems not the right way to be to augment something that is tailored to SC for NA. This is mainly related to the next point.
• As a consequence of the above, atoms (qubits) do not have a fixed position. Even though it is still possible to index the existing atoms from 0 to n as one does for SC, at least some operations need coordinates as input. I have the feeling that this does not fit very well into the QASM format. One reason for this might be, that we definitely want to move multiple atoms at the same time. QASM does not offer a good way to express the scheduling of operations, e.g., to express that a group of operations is executed simultaneously.
• The main purpose of 🎨 Refactor NAComputation with concrete base classes for every operation and ouput new .naviz format #846 was to make NAComputation output the new format that mqt-naviz understands. I would very much like to keep this feature. This means when merging both representations, QuantumComputation requires a new output method for the .naviz format.

Overall, I think everything is possible and there is no fundamental obstacle of merging both representations. It just generates some work to merge the different concepts. Additionally, one must accept that one merges the concepts of computations meant for SC and for NA.

Originally posted by @ystade in #862 (comment)

[burgholzer]

Hey @ystade 👋🏼

Here comes the longer and bigger discussion. 🙃

I agree with a lot of what you stated above. In general, I believe there is a purpose for multiple circuit representations (as also proven by our ongoing discussions with regard to MLIR).
In my mind, there is some kind of hardware-agnostic level to describe quantum programs (circuits), which is well covered by the existing QuantumComputation class.
At some point, a program is mapped (=>"QMAP") to a certain hardware technology.
The capabilities and constraints of the actual hardware might necessitate a different kind of program representation.
While this is not really the case for superconducting systems, where the only difference is a switch from virtual qubits to hardware qubits, it is very much a factor for neutral atom or trapped ion systems.
Thus, I believe having multiple different program representations is warranted.

In the same spirit, multiple output formats are warranted. Deeper down the software stack, different kinds of information are needed that might not all be expressible in a single format.
(Although OpenQASM 3 has the concept of boxed operations and timings 😉 https://openqasm.com/versions/3.0/language/delays.html#boxed-expressions)

At the same time, there is lots of duplication and little connection between the representation we currently use. The NAComputation is completely decoupled from the existing QuantumComputation.
Then again, the QuantumComputation duplicates the concept of Move and AOD operations.
I would propose to separate these concerns and clearly delineate, which concepts belongs to which level of abstraction.
To me, this means removing the NA-specific operations from the QuantumComputation hierarchy and, if one views all of our NA compilation activities as a whole, the corresponding compiler should map (QuantumComputation, NAArchitecture) -> NAComputation.

While there are certain fundamental differences between the different levels of abstraction (for example, qubits being indexed via 1D or 2D coordinates), I would really strive for a solution that does not duplicate every single concept between the hierarchies, but rather unifies them as much as possible.
For that, I think a discussion is to be had about the fundamental differences and similarities between the different concepts. Just to list a few keywords

• modifiers (control, inverse, power,...)
• locality (local, global, zoned,...)
• targets (single-target, two-target, ...)
• parameters (0, 1, 2, 3, ... parameter operations)
• addressing (linear 1D index, 2D integer grid, 2D floating point plane)
• ... (please add to this list if you have further ideas)