Identification of the available devices

[kayaercument]

Selectors and schedulers might use device-based models to optimize their performance. Therefore, both of them require a kind of identification. We can use BACKEND_NAME or create another attribute named BACKEND_ID, which would be an integer.

We need to consider the production phase as well. How can we define the IDs? They might be environment variables, and we can assign them to the .qdmi-config file.

[burgholzer]

Related to #17.

As stated over there, the best guess for an identifier is probably a device property BACKEND_NAME that can be queried via QDMI. As for storing a configuration: storing a list of names seems perfectly fine with me. That is also how Qiskit for example stores the available backends of a provider.

[kayaercument]

@burgholzer Thank you for your input.

@flowerthrower Please follow this issue and PR.

Please check #24. My idea is to query the BACKEND_NAME as follows:

char* backendName;
QDMI_query_device_property_c(device, BACKEND_NAME, backendName);

BACKEND_NAME is defined in the qdmi.h. The QDMI_Device_property was a struct, but I made it an integer as it used to be.

@echavarria-lrz @Durganshu

[burgholzer]

@burgholzer Thank you for your input.

@flowerthrower Please follow this issue and PR.

Please check #24. My idea is to query the BACKEND_NAME as follows:

char* backendName;
QDMI_query_device_property_c(device, BACKEND_NAME, backendName);

BACKEND_NAME is defined in the qdmi.h. The QDMI_Device_property was a struct, but I made it an integer as it used to be.

Could you please isolate this change in a separate PR? It is small and self-contained, so it should not be part of a huge cleanup PR that no one can follow and or review properly.

[Durganshu]

@burgholzer Thank you for your input.

@flowerthrower Please follow this issue and PR.

Please check #24. My idea is to query the BACKEND_NAME as follows:

char* backendName;
QDMI_query_device_property_c(device, BACKEND_NAME, backendName);

BACKEND_NAME is defined in the qdmi.h. The QDMI_Device_property was a struct, but I made it an integer as it used to be.

@echavarria-lrz @Durganshu

QDMI_Device_Property was changed to a struct to store all the information relevant to a Device property (name, type, or even timestamp to store when it was last updated). For example, the backend version could be one of the properties (let's take backend_version = 0.3). Some backend providers can store this as a string, and others may store it as a double. A struct with a type member will help the user identify the property type.

Do you suggest any other method/alternative for handling this information?

[kayaercument]

How do you suggest we create and assign values to QDMI_Device_Property? I believe we should not allow the user access directly.

[burgholzer]

QDMI_Device_Property was changed to a struct to store all the information relevant to a Device property (name, type, or even timestamp to store when it was last updated). For example, the backend version could be one of the properties (let's take backend_version = 0.3). Some backend providers can store this as a string, and others may store it as a double. A struct with a type member will help the user identify the property type.

Do you suggest any other method/alternative for handling this information?

Just a couple thoughts on this:

I am not sure that this kind of abstraction is necessary here. Why can't we simply prescribe which type we expect certain properties to be?

BACKEND_VERSION -> string
BACKEND_NAME -> string
NUM_QUBITS -> int
...

I think it is reasonable to assume that we can "force" every backend provider to report a given property with a pre-defined type.

A follow-up thought: Right now, the pattern to access a property via QDMI is to

• check whether the property exists
• if no error code is returned, query the property with the right function

In principle. This could be reduced further, by just having the query functions as part of the QDMI interface and handling the existence of the property via error codes. For example,

int QDMI_query_device_property_i(QDMI_Device dev, QDMI_Device_property prop, int *value);

could return

• QDMI_SUCCESS if successful
• QDMI_ERROR_PROPERTY_DOES_NOT_EXIST if the property does not exist
• QDMI_ERROR_PROPERTY_WRONG_TYPE if the property exists, but the type is wrong
• ...

reduces the interface even further.

One advantage of the QDMI_Property struct could be that it can be implemented as an opaque pointer and we could probably eliminate the different type overloads for the query functions completely, i.e., something like

int QDMI_query_device_property(QDMI_Device dev, QDMI_Device_property prop, QDMI_Property* value);

and some helper functions to get the proper value out of a QDMI_Property. Something like

int QDMI_query_property_i(QDMI_Property* property, int* value);
...

which, again, could return QDMI_ERROR_PROPERTY_WRONG_TYPE if the requested property is not matching the requested type. The good thing would be, that these queries on QDMI_Property* could have a default implementation as part of the QDMI internals/details as this is completely independent from the actual properties.

Combining the last two ideas could actually simplify the QDMI Query interface quite a bit.

Hope all of this remotely makes sense. While I first was opposed to the properties being a struct, this might actually be a nice idea that allows to hide some implementation details.