Add details of `prob_meas0_prep1, prob_meas1_prep0, readout_length`

[t-imamichi]

Qubit properties provided by IBM backends are: t1, t2, frequency, anharmonicity, readout_error, prob_meas0_prep1, prob_meas1_prep0, readout_length according to the comment https://github.com/Qiskit/qiskit/pull/5885#discussion_r747156388

We can get the information as follows.

In [23]: service = QiskitRuntimeService(...)

In [24]: backend = service.backend("ibm_fez")

In [25]: backend.qubit_properties(0)
Out[25]: QubitProperties(t1=6.322117837611346e-05, t2=5.209639963380763e-05, frequency=None)

In [26]: backend.properties().qubit_property(0)
Out[26]:
{'T1': (6.322117837611346e-05,
  datetime.datetime(2025, 4, 21, 8, 46, 23, tzinfo=tzlocal())),
 'T2': (5.209639963380763e-05,
  datetime.datetime(2025, 4, 21, 8, 46, 23, tzinfo=tzlocal())),
 'readout_error': (0.0087890625,
  datetime.datetime(2025, 4, 21, 10, 21, 58, tzinfo=tzlocal())),
 'prob_meas0_prep1': (0.01611328125,
  datetime.datetime(2025, 4, 21, 10, 21, 58, tzinfo=tzlocal())),
 'prob_meas1_prep0': (0.00146484375,
  datetime.datetime(2025, 4, 21, 10, 21, 58, tzinfo=tzlocal())),
 'readout_length': (1.56e-06,
  datetime.datetime(2025, 4, 21, 10, 21, 58, tzinfo=tzlocal()))}

But, the definitions of prob_meas0_prep1, prob_meas1_prep0 and readout_length don't exist in the documentation. Could you add the information in the following pages?

• https://github.com/Qiskit/documentation/blob/main/docs/guides/qpu-information.mdx
• https://github.com/Qiskit/documentation/blob/main/docs/guides/get-qpu-information.ipynb

[abbycross]

The Support Team passed along the following definitions:

• prob_meas0_prep1: This is the probability of getting a measurement result of 0 when the qubit was actually prepared in the |1⟩ state. Mathematically, this can be expressed as P(0 | 1).
• prob_meas1_prep0: Similarly, this is the probability of measuring 1 when the qubit was prepared in the |0⟩ state - P(1 | 0).

These values represent what are known as SPAM errors (State Preparation And Measurement), but in IBM Quantum systems, they mainly reflect measurement errors. This is because state preparation errors are typically negligible compared to readout errors in superconducting qubits.

• readout_error: This is the average probability of a readout error for a given qubit. It’s generally computed as the mean of prob_meas1_prep0 and prob_meas0_prep1.

Are these the proper definitions to use? Additionally, can you provide one for readout_length? @nathanearnestnoble @t-imamichi

[t-imamichi]

@abbycross We are not the team that defined these data. Could you reach out to the calibration team?

[abbycross]

I can do that @t-imamichi. Unfortunately I don't know who is on that team - do you?

[dtmcclure]

The Support Team passed along the following definitions:

• prob_meas0_prep1: This is the probability of getting a measurement result of 0 when the qubit was actually prepared in the |1⟩ state. Mathematically, this can be expressed as P(0 | 1).

I would say "intended to be prepared" rather than "actually prepared," since some fraction of the error could come from imperfect state preparation.

• prob_meas1_prep0: Similarly, this is the probability of measuring 1 when the qubit was prepared in the |0⟩ state - P(1 | 0).

Same comment as above

These values represent what are known as SPAM errors (State Preparation And Measurement), but in IBM Quantum systems, they mainly reflect measurement errors. This is because state preparation errors are typically negligible compared to readout errors in superconducting qubits.

Not necessarily: while single-qubit gate errors are quite low, initialization errors are not always negligible.

• readout_error: This is the average probability of a readout error for a given qubit. It’s generally computed as the mean of prob_meas1_prep0 and prob_meas0_prep1.

Yes though it seems a bit circular to use "readout error" in the definition of readout error...

Are these the proper definitions to use? Additionally, can you provide one for readout_length? @nathanearnestnoble @t-imamichi

readout_length is the total time allotted for a readout operation, starting from the time the measurement pulse starts to be emitted, and ending once the resulting signal has been digitized and the system is ready to perform another measurement.

[t-imamichi]

Thank you for the details!

[abbycross]

Many thanks @dtmcclure!

[shraddha-aangiras]

Hi! Can i be assigned to work on this under unitaryHACK?

[alapena]

Hi! I am interested in working on this issue for the unitaryHACK. Please kindly confirm that I can join.

[AprilSweettooth]

Hi, I am pretty familiar with this and would like to be assigned to the UnitaryHack, if it is still available. Thanks!

[kaelynj]

Hi @shraddha-aangiras , @alapena , @AprilSweettooth. Thanks for your interest in working on this! For the Unitary Hack we don't typically assign folks to an issue. Feel free to open a PR and the first one to pass review will complete it.

[1ucian0]

👋 This issue is part of UnitaryHack 2025. For the duration of the event, it follows a few special rules and considerations:

• No need to be assigned to start working on it, just go ahead! This holds until the end of UnitaryHack.
• If multiple PRs are submitted to close this issue, maintainers may select one at the end of the event and award the bounty accordingly.
• If more than one person works on a single PR, please note that the bounty cannot be split.
• In some cases, a not-fully-complete but close-enough PR might receive a partial bounty.
• If you have any questions or need clarification, feel free to ask in the comments here. Please note that while maintainers do their best to reply, responses might take longer than you expect.

Happy hacking! 🧑‍💻✨

[AsadullahGalib007]

This issue was addressed and resolved in PR #3205, which has now been merged. It can likely be closed.

[t-imamichi]

Thanks. I close this.