burgholzer
commented
7 months ago Just my two cents here:
Adding these probably makes sense. Coherence times and readout error/length are all metrics that should be relevant for practically any device that I could think of. So it shouldn't be too hard to make these accessible.
At least on the query side of the interface, these are partially defined as properties here: https://github.com/Munich-Quantum-Software-Stack/QDMI/blob/9baf644040ae782f33e2d5f1b2dc71ea121ed76a/include/qdmi.h#L57 And I guess this is still the preferred way to query them, i.e., first querying whether the property is present, then getting the property. Would be nice to have some kind of feature parity between the properties that are represented internally and the properties that are queryable.
Durganshu
kayaercument
Currently, there are no struct members to store qubit properties (like decoherence times - T1 & T2, readout error, etc.) https://github.com/Munich-Quantum-Software-Stack/QDMI/blob/ee8495ee56fed1c5d26b6197ca58da3e5e158631/include/qdmi_internal.h#L137-L142
T1, T2, readout error, and readout length could be essential qubit properties for all backends (at least superconducting ones).
I suggest adding members to store these properties. I'll also add a reference implementation of querying these properties in the Qiskit backend.
If the backend doesn't provide these properties, these values may be set to pre-defined error values (maybe some negative values).