Missing readout frequency in IBMQubitProperty

[nkanazawa1989]

What is the expected enhancement?

IBMQubitProperty has "t1", "t2", "frequency", "anharmonicity". These are sufficient properties to describe your qubit. However, when we want to readout quantum state from this qubit, we need to know the frequency of stimulus pulse, which is usually the frequency of readout cavity capacitively coupled to the qubit. Previously, this information is provided through backend.defaults() which is dropped in the V2 backend. The missing readout frequency causes some problem in qiskit-community/qiskit-experiments#900.

From software viewpoint, adding extra information about the readout frequency to IBMQubitProperty might be the simplest solution, e.g. IBMQubitProperty.readout_frequency. Luckily, readout cavity and qubit are 1:1 mapping in IBM architecture and this doesn't cause any side effect in practice.

From hardware viewpoint, strictly speaking the readout cavity is not a part of "qubit". So above data structure may confuse the device engineer or physicist who may use the data for daily calibration or QED simulation. They may want to check IBMBackend.readout_properties(self, cavity: Union[int, List[int]]), which doesn't exist today. I prefer this pattern and in principle provider can add whatever properties they want -- but I'm not sure if this is technically possible. I'd like to hear comments form others.

[wshanks]

For the benefit of people not interested in qiskit-community/qiskit-experiments#900, I will repeat some of my comments from there here.

One point is that this information is still provided by backend.defaults():

qiskit-ibm-provider/qiskit_ibm_provider/ibm_backend.py

Lines 714 to 719 in 06490ab

	def defaults(self, refresh: bool = False) -> Optional[PulseDefaults]:
	"""Return the pulse defaults for the backend.
	The schema for default pulse configuration can be found in
	`Qiskit/ibm-quantum-schemas
	<https://github.com/Qiskit/ibm-quantum-schemas/blob/main/schemas/default_pulse_configuration_schema.json>`_.

The thing that changed with defaults() between V1 and V2 is that the V1 fake backends in terra implement defaults() while the V2 fake backends do not. Neither BackendV1 nor BackendV2 implements defaults() in terra but the V1 and V2 subclasses in qiskit-ibmq-provider and here both implement it.

This is a little pedantic but I think the frequencies should live in two places. One place (like backend.properties()) can hold resonant frequencies of the device and the other (like backend.defaults() or maybe backend.target in the future) can hold frequencies used by the control electronics. For IBM superconducting transmon qubits, readout is done by coupling to a resonator whose frequency changes (by 2 chi) depending on the state of the qubit. Typically readout is done by driving half-way in between these two frequencies. There is less distinction for qubits but even there for finite ZZ one needs to decide to drive at the frequency of the qubit with its neighbors in 0 or with them in 0+1.

[nkanazawa1989]

Good point. This makes me think IBM backend may need to report other properties like chi, kappa for the readout resonator, and thus having dedicated IBMBackend.readout_properties(self, cavity: Union[int, List[int]]) entry would make more sense. Anyways having one for physical properties in property and another one for control parameter in Target sounds like a good idea.