Add explicit interface to DynamicsBackend for just returning results of ODE simulation

[DanPuzzuoli]

Currently DynamicsBackend.run, is the only method of DynamicsBackend for running simulations. In accordance with the standard backend interfaces, it performs a state simulation and returns a probability dict.

It would be good to have a public interface just for ODE simulation with arbitrary "states" (including unitary simulation) - basically the equivalent of Solver.solve, but in which a user can take advantage of circuit transpilation. I think it probably makes sense to add a new DynamicsBackend.solve method for this. (The other option would be to add options to DynamicsBackend.run, but this would completely change the output type, and therefore complicate the interface, and also take it out of line with general backend.run.)

[donsano33]

Hello Daniel, I would take a look at it and give it a shot. I agree, it like the choice to leave the DynamicsBackend.run method as is and add a new DynamicsBackend.solve which corresponds to the Solver.solve method. Can you assign the ticket to me? Thanks!

[donsano33]

When calling DynamicsBackend.solve(...), shall we

• wrap the call to solver.solve into a DynamicsJob similar to the DynamicsBackend.run function, leading to placing the OdeResults into a Result or
• match the solver.solve interface and just return the Union[OdeResult, List[OdeResult]]?

I actually think I prefer option two, as it gives more direct access to the results of interest avoiding the detour to Job.result.results(). What we loose with this additional datastructure from Result, for example saving the metadatafrom the schedules, etc.

What do you think?

[DanPuzzuoli]

I agree. The job interface in Dynamics serves no purpose other than to imitate the container objects returned by a real backend. The solve method doesn't fit into the backend framework, so there's really no reason to use DynamicsJob.