Pass backend properties in a sane manner.

[nonhermitian]

What is the expected enhancement?

Currently the backend properties are a nightmare to parse through. Basically one has to go through nested lists of items to find what one is looking for. For example, finding the readout_error on all the qubits requires:

readout_errors = []
for qubit in backend.properties().qubits:
    for item in qubit:
        if item.name == 'readout_error':
            readout_errors.append(item.value)

This is not an ideal way to do things.

The interface should be changed so that it is easier to extract the data needed. For example it is easy to recast the above to look something like:

[qubit['readout_error'].value for qubit in backend.properties().qubits]

where qubit here is an object representing the qubit (As opposed to a list):

backend.properties().qubits[0]

Qubit 0 
    T1 60.507043 us 
    T2 119.551747 us 
    anharmonicity -0.318653 GHz 
    frequency 5.269249 GHz 
    prob_meas0_prep1 0.0124  
    prob_meas1_prep0 0.0044  
    readout_error 0.0084  
    readout_length 732.444444 ns 

with items accessible in a logic manner, e.g.

backend.properties().qubits[0].T1.calibration_time

datetime.datetime(2021, 9, 14, 9, 43, 12, tzinfo=tzlocal())

Because this is a new package we have the opportunity to do things better this time around.

[rathishcholarajan]

FYI, there are a couple of other easy ways to do this today, using the readout_error method in the BackendProperties class.

1. Using range and len

   props = backend.properties()
   readout_errors = [props.readout_error(i) for i in range(len(props.qubits))]
   readout_errors

2. Using enumerate

   props = backend.properties()
   readout_errors = [props.readout_error(i) for i, qubit in enumerate(props.qubits)]
   readout_errors

But I agree that this can be simplified as proposed in this issue.

[nonhermitian]

That is true because someone does the for-loop behind the scenes for you.

[rathishcholarajan]

BTW, qiskit_ibm uses the BackendProperties class from terra.

https://github.com/Qiskit-Partners/qiskit-ibm/blob/16d60753b00d9f1a82ed0c5f2f709f174b21caa7/qiskit_ibm/ibm_backend.py#L456

Is terra the right place to fix this then? @mtreinish @jyu00

[jyu00]

As someone who had to parse through the properties file, I agree it can use some improvement. But as @rathishcholarajan pointed out, the structure of the backend properties is defined by BackendProperties in qiskit-terra. So instead of making any extra convenience methods IBMQ only, I think it makes more sense for them to go into BackendProperties.

[mtreinish]

My goal is for backend properties and backend configuration to disappear from the user facing backend api. It shouldn't have ever been a user facing class, it started as just an marshmallow object model of the iqx wire protocol for the properties data and the API is basically a 1:1 mapping with the json format. I've proposed dropping it from BackendV2 (which is still wip here: https://github.com/Qiskit/qiskit-terra/pull/5885 ) although for backwards compat you'll probably need to keep it around for a while in qiskit-ibm.

[jyu00]

@mtreinish it's nice to decouple the user interface from the backend api! @nonhermitian I think we can close this issue since it makes more sense to add/make the user interface changes you want in BackendV2?

[nonhermitian]

Yeah I am good with that.