Initial DynamicsBackend class

[DanPuzzuoli]

Summary

Closes #74 Closes #75

This PR implements an initial version of the PulseSimulator class, with a very minimal feature set. The main goal is to establish the structure of the class with a minimal level of usability, an then features can be iteratively added.

Currently a WIP, the minimal functionality goal is to allow a user to instantiate an instance with a custom model (defined in terms of a Dynamics Solver), and to submit schedules to PulseSimulator.run and get results objects back containing counts. The current functionality is shown in the file PulseSimulator_custom_demo.ipynb in the root folder (to be deleted prior to merge).

Details and comments

Establishes the PulseSimulator class, which is instantiate with:

• A qiskit Dynamics Solver instance configured to simulate pulse schedules.
• A list of integers specifying the subsystem structure of the model in Solver.

The class assumes that, regardless of the rotating frame the Solver is configured in, the non-rotating frame version of the static Hamiltonian defines the dressed state structure (i.e. the lab frame static Hamiltonian). At instantiation, the lab frame static Hamiltonian is diagonalized, and eigenvalues/eigenvectors are sorted according to dressed-state ordering.

Calling run will:

• Validate the input is a list of schedules with one measurement in each schedule.
• Default to simulating the ground state.
• Simulate the schedules.
• Normalize the output states and sample (normalization is necessary to ensure proper sampling regardless of tolerances used).
• Return a DynamicsJob object containing results.

For now, the DynamicsJob object is an _async=False subclass of Job.

I think the main things to discuss are:

• The constructor interface.
• Options handling - I think we should just use the Aer simulators as an example here, but want to discuss first.