Implement DynamicsBackend.from_backend

[DanPuzzuoli]

Summary

Closes #53.

This PR is a resubmission of the out-of-date #71 . Its scope is also slightly being expanded to implement the DynamicsBackend.from_backend method, for constructing a DynamicsBackend instance from an existing backend.

Note: this is a duplication of #154 - I seem to have messed up my branches badly and had to restart it.

Details and comments

This PR is composed of:

• The main bulk (in terms of lines of code) is bringing over the hamiltonian string parser from the Aer PulseSimulator. A single function which wraps this code is introduced in this PR - I'm leaning towards making this an exposed function so that people can potentially use it outside of the from_backend method, though it won't be heavily advertised or developed beyond its existing form.
• The DynamicsBackend.from_backend method, which parses the hamiltonian string of an existing backend, and also imports other backend properties into a DynamicsBackend instance.
• configuration and defaults methods have been added for backwards compatibility. A user can set whatever these methods are supposed to return through the options setting infrastructure.

Note the explicit choice in this PR to only extract minimal required information from the backend, and to set up as little as possible in the constructed DynamicsBackend. I.e. no configuration or defaults are constructed, and a minimal target (only containing the dt value) is constructed. This is for two reasons:

• Gates calibrated on the real backend won't work on the simulator due to model inaccuracies. This is explained in the method doc string in a warning block.
• The configuration/defaults have a lot of information in them, some of which are duplicated from the target. Rather than try to copy the relevant information and make it all consistent, since they are not required elements of the BackendV2 interface, we leave it up to the user to set them up and add them if necessary for their use case.

[chriseclectic]

This looks like it only works with legacy V1 backends from IBMQ Provider since it uses configuration and defaults rather than the new target for V2 backends from the IBM provider. It might be worth discussing with @mtreinish the best way to support both V1 and V2, with focus on V2 going forwards.

[DanPuzzuoli]

This looks like it only works with legacy V1 backends from IBMQ Provider since it uses configuration and defaults rather than the new target for V2 backends from the IBM provider. It might be worth discussing with @mtreinish the best way to support both V1 and V2, with focus on V2 going forwards.

We can go through the specific fields on a case by case basis, but @mtreinish and I discussed this, and the gist of it is that we are essentially stuck with only supporting V1 in this method for now (and whatever V2 backends have configuration/defaults for backwards compatibility). The main issue is that the Hamiltonian specification currently has no place in V2 backends, it can only be found in configuration. You're right though that I could be pulling more information from the target, which I can change. Once I saw that there was no way of avoiding configuration I just reverted to grabbing everything from it/defaults. It may be possible to avoid using the defaults, as I'm assuming whatever is in config.qubit_freq_est is consistent with the frequency listed in target.qubit_properties.

I added the configuration/defaults methods with the corresponding options to enable backwards compatibility. This was motivated by Matt telling me that this is done on a lot of V2s anyway since people are used to using this. It isn't actually necessary though, I guess a user could just directly set these methods as attributes to the backend instance of their choice if they really wanted to. Shall I remove them?

[mtreinish]

Right, BackendV2 makes a hard separation between the required fields, the optional fields, and the custom fields for a backend's properties. We started a bit more conservatively with what was required and optional as those basically had dependency inside qiskit-terra and were parts of what we considered the standard interface at the time. Anything outside of that was considered custom and particular implementations of a backend are encouraged to add any extra details they provide and if there is a need for a common interface we can evolve the backend/target to include extra data as it becomes widely used/needed. This was a key part of the design because the ibm payload formats contain a lot of superfluous (especially when coming from a more common circuit only usage patter) and duplicated information and other providers don't give nearly the same level of detail so we wanted the new version to be very clear about the intent behind each field a backend provides. On the IBM provider's backends the configuration(), properties(), and defaults() methods are still present both for backwards compatibility and also because they're the only backends that those methods really mean anything (because it's the payload format for the IBM api). So for dynamics it's ok to rely on those if we're ok saying that we're restricting this API to only backends from the IBM provider.

As for the gaps in BackendV2, for the case of dynamics I think the big thing as @DanPuzzuoli said is that we're missing hamiltonian definition. The intent at the time of Qiskit/qiskit#5885 was to follow-up after the PR with an object model representation of the hamiltonian and add that as an optional field on the backend (see @nkanazawa1989's comments here: Qiskit/qiskit#5885 (review) ). We have yet to actually start working on that if you had any input on this or an idea of how we should model this object in terra I'd be very keen to try and get this into 0.24.0. Thinking forward though it might be better to try and access the v2 attributes directly if there is equivalent information available outside of configuration() just so that when we have a native optional hamiltonian object exposed on BackendV2 the amount of work to enable general BackendV2 instances is less.

[DanPuzzuoli]

Thanks for the explanation @mtreinish . Based on these comments I've modified the following:

• from_backend has been modified to extract what it can from the target, if one is present. It now no longer strictly requires defaults, which now serves as a fallback if there is no target to extract qubit frequencies from, or if measurement channels are explicitly part of the model (as far as I can tell there is no equivalent for meas_freq_est in target).
  • While making these changes I looked more closely at the APIs for the configuration/defaults and changed how some of the code works. Very minor, but I used to check if configuration/defaults had certain attributes before retrieving them, but I now know that they always have these attributes, it's just a matter of if they're populated.
• Related to the above, I've had to update testing of these parts of the code.
• I've also updated the method doc string to reflect this. The main change is a new table listing which information is required in the original backend, and where it comes from (with a primary and secondary sources).

[chriseclectic]

LGTM