fix sub_dims bug in _get_iq_data

[rupeshknn]

Summary

Backends instantiated using DynamicsBackend.from_backend do not work with meas_level arg in DynamicsBackend.run

Details and comments

from qiskit import pulse
from qiskit import QuantumCircuit
from qiskit.qobj.utils import MeasLevel
from qiskit_ibm_provider import ibm_provider
from qiskit_dynamics import DynamicsBackend

provider = ibm_provider.IBMProvider()
kyoto = provider.get_backend('ibm_kyoto')
sim_backend = DynamicsBackend.from_backend(kyoto,subsystem_list=[0]) #single qubit backend


qc = QuantumCircuit(1,1)
qc.h(0)
qc.measure([0],[0])

with pulse.build() as h_q0:
    pulse.play(
        pulse.library.Gaussian(duration=256, amp=0.2, sigma=50, name="custom"),
        pulse.DriveChannel(0)
    )
qc.add_calibration("h", qubits=[0], schedule=h_q0)


result = sim_backend.run(qc, meas_level=MeasLevel.KERNELED)

# ValueError: maximum supported dimension for an ndarray is 32, found 127

which is raised by qiskit_dynamics/backend/backend_utils.py:239 --> probabilities_tensor = probabilities.reshape(list(reversed(subsystem_dims)))

This PR solves this error by removing all 1d (trivial) systems from the subsystem dims within the _get_iq_data function.

More generally, however, DynamicsBackend.from_backend must assign a Target object with the correct number of qubits to the backend and have the subsystem_dims of only the required length.

[rupeshknn]

I just realized, the problem isn't just with meas_level=MeasLevel.KERNELED. Even doing result = sim_backend.run(qc) doesn't work as similar logic is evoked in Qiskit quantum-info. The 127 qubit open-access backends have made it infeasible to use DynamicsBackend.from_backend in the way it currently works.

[DanPuzzuoli]

Thanks @rupeshknn

That's a funny issue... seems kind of like a fundamental problem that's going to need a deeper solution. I guess normally we won't work with so many dimensions, and the only reason we're encountering it here is because these dimensions have length 1 (i.e. are "trivial").

[DanPuzzuoli]

Thank you. The only other thing I'd request is if you can add a test case to test.dynamics.backend.test_dynamics_backend.TestDynamicsBackend_from_backend that would have caught this. I guess there aren't any test cases that actually compute outcomes. You could add one that integrates over a very short time interval (to avoid costly simulation) and computes the results. Thoughts?

[rupeshknn]

Hey Dan, for this PR, the bug isn't from DynamicsBackend.from_backend. It has to do with how IQ data is computed. I've already added a test that ensures trivial sub-systems are not measured for IQ data-related means options. This works irrespective of whether the trivial subsystems were provided by the user or via from_backend.

So, I don't see the need for another test. if you disagree, could you point out what exactly would this test be checking for?

[DanPuzzuoli]

Hey Dan, for this PR, the bug isn't from DynamicsBackend.from_backend. It has to do with how IQ data is computed. I've already added a test that ensures trivial sub-systems are not measured for IQ data-related means options. This works irrespective of whether the trivial subsystems were provided by the user or via from_backend.

So, I don't see the need for another test. if you disagree, could you point out what exactly would this test be checking for?

Ah I see - yes you're right. Apologies, I rushed through looking at this in a scramble to reply to a bunch of things after getting back from holidays.