Fix _default_dt for DelayLtiSystem (closes #544)#1054
Merged
Conversation
The previous heuristic always returned `0.07` because the appended `0` in `minimum([abs.(real.(ps));0])` and `minimum([sys.Tau;0])` forced `r = 0`, which then fell back to `r = 1.0`. As a result `step(delay(0.01))` (issue #544) sampled at `dt = 0.07` and could not resolve the delay. Rewritten to mirror `_default_dt(::LTISystem)`: take the fastest pole of `sys.P.P` and the smallest positive delay, and pick the more demanding of `1/(12·ω_max)` and `τ_min/12`. Add a regression test for #544. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
This is an automated message.
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1054 +/- ##
==========================================
+ Coverage 91.54% 91.57% +0.02%
==========================================
Files 42 42
Lines 5609 5624 +15
==========================================
+ Hits 5135 5150 +15
Misses 474 474 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
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
_default_dt(::DelayLtiSystem)so the default time-vectordtactually adapts to the system's poles and delays. Previously the function always returned0.07because two[…; 0]constructs collapsedrto0, which then fell back tor = 1.0.step(delay(0.01))now usesdt ≈ 0.00083, ran past the delay, and producesy[end] ≈ 1.The new heuristic mirrors
_default_dt(::LTISystem): take the fastest pole magnitudeω_maxand the smallest positive delayτ_min, pick the more demanding of1/(12·ω_max)andτ_min/12.Context
Issue #544 was originally about
step(delay(0.01))failing withdt <= dtminand aBoundsError. The error itself was resolved in #690 (2022) viaforce_dtmin=true, but the root-cause heuristic was never fixed — sostep(delay(0.01))ran without erroring while sampling far too coarsely to resolve the delay. This PR fixes that.While verifying the fix I hit an apparently-unrelated upstream issue:
MethodOfSteps(Tsit5())+ neutral DDE +SavingCallbackerrors out specifically atdt = 0.014for the existing test system1/(0.85s+1)·exp(-0.14s), while neighbouringdtvalues succeed. Reported as SciML/OrdinaryDiffEq.jl#3636. The new heuristic uses/12(matching the LTI version) rather than/10, which happens to land on0.012instead of0.014and sidesteps the upstream bug for now.Test plan
delay_timeresptestset passes (33/33, including the new regression test)timeresptestset passes (no regressions)step(1/(0.85s+1)*exp(-0.14s), 5)test still passes (length 417, dt 0.012)step(delay(0.01))now returnsy[end] ≈ 1withdt ≈ 0.00083