Cross-compatibility with other libraries

[scarrazza]

It is not the first time we discuss about this topic. At the moment any circuit-based model implemented in other libraries, most likely qiskit and cirq, can be integrated in qibo and qibolab via openqasm. However, for general users this feature is not properly documented nor tested at the level of qibolab. I believe we could put some effort and design a function def convert_to_qibo(external_circuit) -> qibo.Circuit and therefore provide a simple mechanism to execute more models @qiboteam/coredevs, any thoughts?

[MatteoRobbiati]

I agree with this idea.
In addition, I would suggest to make this simmetric. It can also be useful to have the same tool to convert Qibo's to qiskit and cirq, above all for calculating benchmarks.

[alecandido]

I would avoid the N x M problem, if possible (in our case N x 1, since we do not have to make converters for pairs in which Qibo is not involved). This is solved by some kind of intermediate protocol (like in the case of LSP for IDEs).

Before, I considered leveraging QASM for the purpose (upgrading support to the not-so-recent QASM 3.0), and maybe it's still the best option. However, if QIR is something concrete, and going to be widespread adopted, maybe there is no need to do anything, other than supporting QIR ourselves (at that point, you should be able to run routines generated by everyone).

[scarrazza]

This is a good point, however we need a solution as soon as possible without relying on projects that might or not takeoff.

[alecandido]

I agree that QASM might be our best choice, at least for the time being (I declared it above).

[scarrazza]

Yes, but my point is to create a set of high-level functions to avoid asking the user to export and import qasm.

[alecandido]

In principle it's feasible, but dumping to QASM it should be a matter of calling a single function.

Since it should be simple enough, I'd rather avoid to make Qibo depending on all the other libraries, and instead spell out the instructions in the docs. In this way, at the price of one extra call on the user side, the dependency will be in the user code only, and Qibo will support at the same level each library capable of dumping to QASM.

[stavros11]

One limitation of QASM may be that some gates are supported by Qibo and the other target library but not QASM (I am not sure but maybe one example is the arbitrary Unitary gate?). This may be more relevant for simulation than hardware execution.

Other than that, I agree that expanding and documenting our QASM parsers is a good first step to solve this issue. I would also focus on that at first, instead of trying to do a direct converter from/to qiskit, cirq, etc. Other than documentation, we should also consider supporting the newest stable versions of QASM and try to include all its functionalities (gates, etc.) so that we are mainly limited by QASM features and not our parser.

[andrea-pasquale]

I believe we could put some effort and design a function def convert_to_qibo(external_circuit) -> qibo.Circuit and therefore provide a simple mechanism to execute more models @qiboteam/coredevs, any thoughts?

For sure this is a useful feature. I think that a first prototype using QASM should be quite straightforward to do.
As a starting point we could also have a look at what we did in https://github.com/qiboteam/qibojit-benchmarks.
Moreover, I've heard in past that Qilimanjaro should have already done something similar.

[yjmaxpayne]

Agree. It is a timely discussion. We (IHPC) are planning a research collaboration effort with AWS to look into Qibo-Braket integration. Having a unified way to do the interfacing will be great. Also wish to point the team to this blog article where AWS specifically mentioned QIBO: https://aws.amazon.com/blogs/quantum-computing/new-open-source-tool-expands-access-to-lab-based-quantum-prototypes-cloud-queue-for-quantum-devices/