qBraid SDK and OQC Cat compiler connection

[rryoung98]

Summarize your feature/enhancement

The qBraid SDK allows for transpilation of virtual circuits between the following frameworks:

>>> from qbraid import QPROGRAM_LIBS
>>> QPROGRAM_LIBS
['braket', 'cirq', 'qiskit', 'pyquil', 'pytket', 'qasm2', 'qasm3']

and we are actively investigating and developing a transpiration for QIR as well.

The feature request: Allow for the high degree of transpiration of the qBraid-SDK to work seamlessly with the OQC Cat compiler using the QASM V2 support currently available on QAT to allow users of qBraid to access OQC hardware.

Specific details of what you would like to see

How this would be implemented:

Given QAT is still under development, im going off the functions written in the tests folder as well as qat/qasm.py and QatBackend

SAMPLE MVP CODE:

Ref:

""" 
Use the qBraid SDK to transpile a virtual circuit 
and use the get_qasm_parser method.
"""

from qbraid import circuit_wrapper, QPROGRAM_TYPES

class QatBackend(QasmSimulatorPy):
    """
    Basic qiskit backend built to run QASM on our own backends.

    TODO: Expand this to become a proper back-end, as I don't believe we need to inherit
        off the QASM simulator as it stands.
    """

    def __init__(self, hardware=None, comp_config=None, **fields):
        super().__init__(**fields)
        self.hardware = hardware
        self.comp_config = comp_config

    def run(self, qobj, **backend_options):
        if not isinstance(qobj, List):
            qobj = [qobj]

        """" NEW CODE SUGGESTION HERE""""
        if not all(type(val) in QPROGRAM_TYPES for val in qobj):
          raise ValueError(
                f"Experiment list contains non {QPROGRAM_TYPES} objects which we can't "
                f"process at this time."
            )
        # All virtual circuits are transpilable with the qBraid SDK, user can now write circuits in qiskit, cirq, pytket, qasm2, qasm3 etc and submit jobs
        qobj = [ circuit_wrapper(val).transpile('qiskit') for val in qobj ]
        """" NEW CODE SUGGESTION HERE""""

        options_keys = set(dir(self.options))
        assembled_data = assemble(
            qobj,
            self,
            **{key: val for key, val in backend_options.items() if key in options_keys}
        )
      ........
      ........
      ........

a more robust transpiler can include compilation passes from qiskit, pytket and cirq for improved results.

[chemix-lunacy]

Hi @rryoung98!

QAT is our backend compiler/runtime you access from our cloud system, not how you send requests to us. That Qiskit backend is purely for us to run a few circuit generation methods for testing, not actually a way for people to execute things. Considering any user already importing your library can just use a one-liner to transpile things it makes sense for them to do it on their end really. This includes using QAT directly, as all you'd need is something vaguely like this:

execute_qasm(qbraid_circ.transpile('qasm'), ...)

What would you be using this for exactly? If it's a closer integration it's likely way easier if we just help you build whatever you want in your own system.

With that said there are two things which are interesting here:

1. QASM v2/v3 to QIR transpilation would be useful if it's accurate, robust and efficenct.
2. If we can use qBraid to perform circuit synthesis that spans the libraries you mentioned through one consolidated API that'd also likely be useful for testing.

Can you give some timelines on 1 and what the capabilities of qBraid is for 2? I'd love if I could combine the various circuit synthesis/algorithm helpers across those libraries. Less interested in optimization or compilation passes, we already deal with those.