Munich-Quantum-Software-Stack / QDMI

Quantum Device Management Interface (QDMI)
https://munich-quantum-software-stack.github.io/QDMI/
Apache License 2.0
27 stars 0 forks source link

Querying available devices #17

Closed kayaercument closed 1 month ago

kayaercument commented 6 months ago

Previously, @echavarria-lrz created two functions to query available devices, as you can see here. Since we're working on cleaning this repo, those functions need to move to qdmi.h or qdmi_backend.h.

However, we can use two functions named QDMI_core_device_count and QDMI_core_open_device to query devices. We can get the number of available devices using QDMI_core_device_count and QDMI_core_open_device to return the device with index idx.

What are your options?

burgholzer commented 6 months ago

Hey @kayaercument 👋🏼

I think QDMI_core_device_count should be the first function to call, to get a first overview of how many backends there are. Given that the index alone might not really be sufficient for selecting a backend in general, it would be nice, if the name of the backend was query-able as well. If it isn't already, that should be part of the Query component of QDMI though, given that the backend name is something the backend provider will implement as part of their QDMI backend. To me, it feels like QDMI_core_* should really be separated from the rest of the QDMI components as it contains functions that will typically not be implemented by the backend provider and rather by the system managing the backends.

I believe QDMI_core_open_device should still just take an index and there should not be an alternative that takes a string. Any logic for selecting backends by name can then be implemented on top of QDMI without further bloating the interface.

kayaercument commented 6 months ago

Hey @burgholzer 👋🏼,

Thank you very much for your input. Here you can see my first attempt to implement those functions and here how to use it.

I also think that we should not be rely on strings. However, we might need to change the function signature. Besides that @flowerthrower mentioned me earlier that he needs an identifier to run his models.

burgholzer commented 6 months ago

Hey @burgholzer 👋🏼,

Thank you very much for your input. Here you can see my first attempt to implement those functions and here how to use it.

That already looks quite good. Would you mind simply creating a PR for that particular part? That makes it way easier to comment on specific lines/parts of the code. For example, I think the range check in the device getter is not yet quite correct and should also error if idx==count given that the index is zero-based.

A general thing I was wondering about: Wouldn't it be easier to do the implementation of, e.g., QDMI_core_* in C++? that would simplify some of the constructs in the code.

I also think that we should not be rely on strings. However, we might need to change the function signature. Besides that @flowerthrower mentioned me earlier that he needs an identifier to run his models.

An integer is a perfectly fine identifier ;-) Furthermore, a subsequent QDMI_query_device_property call can be used to retrieve the name of a device if that is more desirable as an identifier.

flowerthrower commented 6 months ago

Please let me know once there is a branch with (any kind of) identifier.

ystade commented 1 month ago

In #61 the device is identified by an opqaue pointer that is implemented by the driver. The driver also provides functions to retrieve the list of available devices.

ystade commented 1 month ago

I close that issue for now as I think it is resolved. However, if you think it is not feel free to comment/re-open the issue.