DynamicsBackend.form_backend fails using backendV2

[to24toro]

Informations

• Qiskit Dynamics version: 0.4.0
• Python version: 3.10.10
• Operating system: M1 MacOS

What is the current behavior?

There is a bug we need to fix as soon as possible. When we execute the below code, we encounter

QiskitError: 'DynamicsBackend.from_backend requires that the backend argument has a configuration method.'

This is because backendV2, unlike backendV1, doesn't support a configuration method.

Steps to reproduce the problem

from qiskit_dynamics import DynamicsBackend
from qiskit.providers.fake_provider import FakeKolkataV2
from qiskit_dynamics.backend import DynamicsBackend

backend= DynamicsBackend.from_backend(FakeKolkataV2(), subsystem_list=[0])

What is the expected behavior?

We would like to create the dynamics backend from FakeKolkataV2, retrieving its information.

Suggested solutions

• need to modify https://github.com/Qiskit-Extensions/qiskit-dynamics/blob/37d12ac33fffd57daea3c9d5f9cda3f00acc37ea/qiskit_dynamics/backend/dynamics_backend.py#L642 .
• Add from_backend test about using backendV2.

[DanPuzzuoli]

There is no way around this - the Hamiltonian is stored in the configuration(), so we cannot use DynamicsBackend.from_backend without this. Removing this constraint will require changing BackendV2 itself in terra to add the Hamiltonian somewhere. (There may also be other things in the configuration that we need to find a proper place for in BackendV2, but can't recall - the Hamiltonian is the big one.)

I'm going to close this for now since there's nothing that can be done in Dynamics about this without changes to terra.

[nkanazawa1989]

I think we don't get any conclusion for this. I don't think it's worth adding BackendV2.hamiltonian because this is only used by the simulator and future IBM backends (with large qubits) may drop this information. The V2 backend has the options field to define arbitrary system configuration, so system Hamiltonian could be a part of this. DynamicsBackend can override _default_options to provide system Hamiltonian. This doesn't mean we can avoid missing configuration field problem though.

Because we cannot assume the backend always provides Hamiltonian, it might be reasonable to write

DynamicsBackend.from_backend(backend, hamiltonian: Optional = None)

and let this factory method check the getattr(backend, "configuration") when hamiltonian is empty. If the backend neither provide Hamiltonian nor configuration, user can still write own Hamiltonian by themself.

(edit)

Probably you may want to implement system Hamiltonian factory. Since IBMBackend and FakeBackend provide qubit properties (frequency and anharmonicity are available) you can still create realistic Hamiltonian by assuming some random Rabi rate and J coupling constant.

[DanPuzzuoli]

Do we expect that systems for which the hamiltonian is not provided will even have pulse access at all? If not then the rest of the information extracted by from_backend won't be present anyway (e.g. channel frequencies), in which case from_backend will fail even if a hamiltonian is provided.

[DanPuzzuoli]

With regards to having a Hamiltonian factory: it may not be a bad idea to have a function that generates DynamicsBackend instances with CR Hamiltonians given a description of the qubits. Something like this was done here for the PulseSimulator. The function could have a similar argument list, but return a DynamicsBackend.

[nkanazawa1989]

I am not sure about what values will be reported. So far IBM devices report all qubit properties as an IBMQubitProperties. Since these values are acquired through the device calibration, I think the availability of them in the non-pulse devices is just a matter of high-level decision and limit of communication bandwidth.

[to24toro]

Looking at this issue from short, medium, long term perspectives.

Short term

• When the backend we use is backendV2, the hamiltonian used for the simulation is retrived from the configuration of backendV1. This is easier to implement than any other way and can be used for backends with configuration.hamiltonian. (In the future, if backends would not provide the hamiltonian information, dynamcisbackend cannot use the new backend.)

Medium term

• We can construct a hamiltonian from the provided qubit parameters. As long as there are some parameters obtained by the qubit calibration, the hamiltonian of IBM backends can be prepared.

Long term

• If you are considering to provide dynamicsbackend to other than IBM backend near future, there is no guarantee that we can utilize qubit properties or parameters of the backends, so users have to write their own hamiltonian. We can help some tools for it.

Anyway we have to change the type hint of an attribute backend of from_backend as soon as possible.