Make PresetTimeCallback robust to tstop roundoff#305
Closed
AshtonSBradley wants to merge 1 commit into
Closed
Conversation
Member
|
Why not just use the values from Julia's range? |
3684dbb to
8ef936f
Compare
8ef936f to
de2a691
Compare
Member
|
Seems like this was AI slip, not the real issue. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
PresetTimeCallbackmatching when an integrator reaches a preset floating-point time within roundoff instead of at the exact storedtstop.insortedpath, then checks the nearest sorted preset time with a small floating-point tolerance after promoting the solver time and preset time together.9.0preset time reached as8.999999999999996, covering integer vector, Julia range, and floating vector schedules; this is the callback-side behavior behind PresetTimeCallback skipped for certain constant lags in DDEs DifferentialEquations.jl#1124.Explanation
PresetTimeCallbackcurrently checks preset times with exact sorted membership. That can skip the callback when upstream time stepping lands on the intended stop with a representational roundoff, which showed up in the downstream DDE reproducer from SciML/DifferentialEquations.jl#1124.This makes the callback predicate robust to that case by preserving the exact membership check first, then comparing only the nearest candidate
tstops from the sorted preset-time vector. The comparison promotestand the candidatetstoptogether, so schedules like[2, 9]and2:7:9are handled the same way as[2.0, 9.0]when the solver time is floating-point. Non-floating comparisons and exact matches keep the existing behavior.Tests
julia --project=. -e 'using Pkg; Pkg.test()'DiffEqCallbacks | 373 pass / 373 total.julia -e 'using Pkg; Pkg.activate(; temp=true); Pkg.develop(path="/private/tmp/DiffEqCallbacks-1124"); Pkg.add("OrdinaryDiffEqTsit5"); include("/private/tmp/DiffEqCallbacks-1124/test/preset_time.jl")'DiffEqCallbacksand explicitMethodOfSteps(Tsit5()).(:up, 9.0)andsol.retcode = SciMLBase.ReturnCode.Success.julia --project=@runic -e 'using Runic; exit(Runic.main(["--check", "src/preset_time.jl", "test/preset_time.jl"]))'git diff --check