Creating family of QDMI_query_gate_property_x queries

[echavarria-lrz]

We have

QDMI_query_qubit_property_exists QDMI_query_qubit_property_c QDMI_query_qubit_property_i QDMI_query_qubit_property_f QDMI_query_qubit_property_d

as well as

QDMI_query_device_property_exists QDMI_query_device_property_c QDMI_query_device_property_i QDMI_query_device_property_f QDMI_query_device_property_d

but only

QDMI_query_gate_name

Shouldn't we create the missing ones?

https://github.com/Munich-Quantum-Software-Stack/QDMI/blob/516dee09d99d3e380d026495dfa3c64d600683a5/src/qdmi_backend_ibm.c#L392C5-L392C25

[burgholzer]

👍🏻 that would most likely make sense. In that case one should probably remove the existing function for querying the name and replace that with a corresponding property.

Furthermore, it should be made pretty clear, which properties can be implemented for a device, a qubit and a gate.

Extra care should be taken, that there is only ever one way to retrieve a certain property, as everything else will create bloat and ambiguity.

[Gistbatch]

In our scheduler, we do a noise estimation (we have used mapomatic) and a runtime estimation + overhead (from the Azure resource estimator). We have used the following information:

• Current internal queue length of the device and it's remaining running time (estimated)
• Processing time of a circuit on a given device as an estimate:
  • Based on 2-qubit gate duration and maximal circuit depth
  • Resource overhead
  • What could be done: expected shot number given a desired result accuracy
• Set-up time between two jobs:
  • Compilation effort, e.g., parametric circuits or circuits from circuit cutting, could be faster
  • device-specific setup, e.g. recalibration
  • job-job-device specific setup, e.g., same trap layout
• Fidelities per gate/location

[kayaercument]

@burgholzer @echavarria-lrz @Gistbatch Does it solved with #4 ?

[burgholzer]

@burgholzer @echavarria-lrz @Gistbatch Does it solved with #4 ?

This issue is about gate properties, not qubit properties. So it is not yet solved.

[ystade]

Resolved by #61.