Multiple users (myself included) have run into issues where a solver steps over a pulse. While this can be easily solved by setting the max step size of the solver to be no larger than the sample size dt (or perhaps 0.5 * dt is safer?), this is usually initially difficult to diagnose, and can be very confusing.
Potential solutions:
Based on user support, @wshanks has suggested adding a max step size to the solver arguments in the DynamicsBackend tutorial, to indicate to new users that this is a thing they can, and probably should do.
Have DynamicsBackend automatically set the max step size. This will likely be slightly annoying/messy, as each underlying solver has it's own way of doing this, and there will need to be some form of validation/checking if the user has specified it themselves or not.
The first option is much easier, though for usability it may make sense to implement the second option. It may actually make more sense to put this automatic choosing into the Solver object itself, rather than DynamicsBackend.
Multiple users (myself included) have run into issues where a solver steps over a pulse. While this can be easily solved by setting the max step size of the solver to be no larger than the sample size
dt(or perhaps0.5 * dtis safer?), this is usually initially difficult to diagnose, and can be very confusing.Potential solutions:
DynamicsBackendtutorial, to indicate to new users that this is a thing they can, and probably should do.DynamicsBackendautomatically set the max step size. This will likely be slightly annoying/messy, as each underlying solver has it's own way of doing this, and there will need to be some form of validation/checking if the user has specified it themselves or not.The first option is much easier, though for usability it may make sense to implement the second option. It may actually make more sense to put this automatic choosing into the
Solverobject itself, rather thanDynamicsBackend.