You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, we maintain a rather proprietary interface for devices in MQT Bench.
QDMI, which is available at https://github.com/Munich-Quantum-Software-Stack/QDMI, provides a standardised interface for querying and controlling quantum devices.
It forms a central part of the Munich Quantum Software Stack (MQSS).
Adopting QDMI allows us to directly connect device implementations created as part of the MQSS (and beyond) to mqt-bench and use them for creating benchmarks for these systems.
It also gets rid of our own device representation code and, hopefully, leads to more unification of these concepts across the MQT and the MQSS.
Describe the solution you'd like
The existing device class should be replaced by QDMI.
This sounds simpler as it is in practice, as there are several open questions left to address. QDMI is a C interface, with implementations in C or C++. As of the time creating this issue, there are no Python bindings for QDMI. In addition, it is not 100% clear, how the concept of a QDMI driver that provides access to the available shared libraries translates to Python.
In a best-case scenario, we can use the Device class interface from mqt-bench and simply swap it out for Python bindings of QDMI without disrupting most of mqt-bench.
I have a feeling that it might not be that easy though.
QDMI support within the MQT is tracked in mqt-core as part of cda-tum/mqt-core#772
The text was updated successfully, but these errors were encountered:
What's the problem this feature will solve?
Right now, we maintain a rather proprietary interface for devices in MQT Bench.
QDMI, which is available at https://github.com/Munich-Quantum-Software-Stack/QDMI, provides a standardised interface for querying and controlling quantum devices.
It forms a central part of the Munich Quantum Software Stack (MQSS).
Adopting QDMI allows us to directly connect device implementations created as part of the MQSS (and beyond) to mqt-bench and use them for creating benchmarks for these systems.
It also gets rid of our own device representation code and, hopefully, leads to more unification of these concepts across the MQT and the MQSS.
Describe the solution you'd like
The existing device class should be replaced by QDMI.
This sounds simpler as it is in practice, as there are several open questions left to address. QDMI is a C interface, with implementations in C or C++. As of the time creating this issue, there are no Python bindings for QDMI. In addition, it is not 100% clear, how the concept of a QDMI driver that provides access to the available shared libraries translates to Python.
In a best-case scenario, we can use the
Device
class interface from mqt-bench and simply swap it out for Python bindings of QDMI without disrupting most of mqt-bench.I have a feeling that it might not be that easy though.
QDMI support within the MQT is tracked in mqt-core as part of cda-tum/mqt-core#772
The text was updated successfully, but these errors were encountered: