See the above issue for a more detailed description, but this PR fixes a bug in which DynamicsBackend was using the wrong integration interval in schedule simulations: the times were passed as sample times, rather than as sample times * dt (the sample width).
Details and comments
The private function dynamics_backend._get_acquire_data has been updated to return a list of only acquire times for each schedule (as opposed to something with the shape of t_span that should be passed to solve). The documentation of this function has also been updated to clearly state this is what it is doing. After _get_acquire_data is called within DynamicsBackend.run, this is translated to the t_span argument by constructing the integration intervals with the correct samples times multiplied by dt.
At the moment, the PR does not directly test this change, as it occurs within inaccessible code. One option is to modify the _get_acquire_data function to return the constructed t_span value, and then we could add tests for that function, however since this function works only with schedules, it feels more natural for it to work purely with sample times.
This PR does however add tests for diagonally-specified rotating frames for the _get_dressed_state_decomposition utility function. While this turned out to be unrelated to this issue, I noticed this case was being missed in these tests.
Summary
Closes #185
See the above issue for a more detailed description, but this PR fixes a bug in which
DynamicsBackendwas using the wrong integration interval inschedulesimulations: the times were passed as sample times, rather than as sample times* dt(the sample width).Details and comments
The private function
dynamics_backend._get_acquire_datahas been updated to return a list of only acquire times for each schedule (as opposed to something with the shape oft_spanthat should be passed tosolve). The documentation of this function has also been updated to clearly state this is what it is doing. After_get_acquire_datais called withinDynamicsBackend.run, this is translated to thet_spanargument by constructing the integration intervals with the correct samples times multiplied bydt.At the moment, the PR does not directly test this change, as it occurs within inaccessible code. One option is to modify the
_get_acquire_datafunction to return the constructedt_spanvalue, and then we could add tests for that function, however since this function works only with schedules, it feels more natural for it to work purely with sample times.This PR does however add tests for diagonally-specified rotating frames for the
_get_dressed_state_decompositionutility function. While this turned out to be unrelated to this issue, I noticed this case was being missed in these tests.