-
-
Notifications
You must be signed in to change notification settings - Fork 116
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ensure initial tstops are unique #777
Comments
Or alternatively to give a useful error about double including |
Shouldn't these cases be handled by the algorithm that pops tstops? Even if the initial tstops are unique callbacks might add tstops that introduce non-uniqueness later during the integration process (this is done eg by the callbacks in DelayDiffEq). It seems safer to ensure that all tstops of (approximately) the same value are removed if a tstop is hit. |
Is there a use case for having non-unique initial |
I'd be willing to put a warning on this. My guess is that there is no valid use case. If there is, we can create an opt-out, but I think there's a 99% chance that any time this happens it's a user setup error. |
As shown in SciML/JumpProcesses.jl#239, a user might accidentally double include some
tstops
when using callbacks. Maybe it would make sense forDiffEqBase.initialize!
to callunique!
on thetstops
?The text was updated successfully, but these errors were encountered: