Optimizations to Discontinuity Detection Scheme by Shreyas-Ekanathan · Pull Request #3720 · SciML/OrdinaryDiffEq.jl

Shreyas-Ekanathan · 2026-06-05T15:25:22Z

Checklist

Appropriate tests were added
Any code changes were done in a way that does not break public API
All documentation related to code changes were updated
The new code follows the
contributor guidelines, in particular the SciML Style Guide and
COLPRAC.
Any new documentation only uses public API

Additional context

Optimizations:

Add a tstop on the first identification of a discontinuity to help with step-resizing and prevent excessively large steps after finding a discontinuity. This should help us not take unreasonable steps, as Oscar suggested, and helps with error resetting after passing a discontinuity (since we are effectively in a new regime) to begin stepping anew.
Shrink the solve window for the interval nonlinear problem after finding a discontinuity
Move _ode_addsteps! out of the zero_func_struct call and only call it once per discontinuity detection run

oscardssmith · 2026-06-12T14:12:03Z

+    is_disco = integrator.is_disco_step
+    if is_disco
+        integrator.is_disco_step = false
+        cache.nconsteps = 0


what is this line doing?

because it's not a standard timestep BDF shouldn't really count this step towards its order selection logic right?

@ChrisRackauckas thoughts on this? I don't know how we want disco to interact with BDF well enough here.

oscardssmith · 2026-07-16T20:25:49Z

is this ready to merge?

Shreyas-Ekanathan · 2026-07-16T20:51:55Z

is this ready to merge?

yes should be

oscardssmith · 2026-07-21T16:35:48Z

any idea why so much CI is failing?

Shreyas-Ekanathan · 2026-07-21T17:55:32Z

any idea why so much CI is failing?

Honestly not sure, it seems pretty random. I pushed another small fix for what I could see that is disco's fault, the remainder appears unrelated

The disco-optimizations merge (SciML#3720) landed three files that Runic rejects, so format-check has been failing on master for every PR since. Whitespace and line wrapping only; `runic --check .` is clean across the repo afterwards. Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DKB6v14nZHZPYtKiLsPLDT

Six floors on master permit dependency versions that lack symbols the code references. AutoMerge has been rejecting the OrdinaryDiffEqBDF 2.4.1 and OrdinaryDiffEqSDIRK 2.8.2 registrations since 2026-07-29 for two of them. DiffEqBase floors (Core, Differentiation, NonlinearSolve) All three require SciMLBase = "3.40", but the first DiffEqBase permitting SciMLBase 3.40 is 7.10.0. With a DiffEqBase floor of "7"/"7.8" the resolver has no solution at all — `Pkg.instantiate()` on any of the three fails with an unsatisfiable DiffEqBase. Raised to "7.10". OrdinaryDiffEqBDF and OrdinaryDiffEqFIRK -> OrdinaryDiffEqCore "4.12" Both read integrator.is_disco_step and integrator.disco_checkpoint. Those ODEIntegrator fields arrived with the DISCO work merged 2026-07-29 (SciML#3720) and are not in any released Core; the first to carry them is 4.12.0. Against Core 4.11.0 BDF fails to load with FieldError: type OrdinaryDiffEqCore.ODEIntegrator has no field `is_disco_step` FIRK's master tree already diverges from the registered 2.5.0 (which predates the field use), so it is bumped to 2.5.1 to make the corrected floor releasable. OrdinaryDiffEqSDIRK -> OrdinaryDiffEqNonlinearSolve "2.6" Imports can_smooth_est, added in SciML#3823. The version carrying it was never registered (ONLS goes 2.5.0 -> master 2.6.0), so against any released ONLS SDIRK fails to load with UndefVarError: `can_smooth_est` not defined in `OrdinaryDiffEqSDIRK` Audit method, since this class keeps recurring (SciML#2600, SciML#4078, SciML#4079) Diffed the ODEIntegrator struct between the registered Core 4.11.0 tree and master for added fields, then grepped every sublibrary for accesses to them; and cross-referenced every qualified access and explicit import name against the registered OrdinaryDiffEqCore 4.11.0 and OrdinaryDiffEqNonlinearSolve 2.5.0 trees. No sublibrary references a Core *name* absent at 4.11.0 — the only Core gaps are the two struct fields — and can_smooth_est is the only NonlinearSolve gap. Verified locally: SDIRK loads against the in-tree ONLS, and BDF loads and solves (FBDF on a scalar decay problem returns 0.36790983175798864). Metadata-only apart from the FIRK version bump. Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017ZqxphdTA1MydR1WXye9Jc

…es (#4084) * Correct dependency floors blocking the pending base and solver releases Six floors on master permit dependency versions that lack symbols the code references. AutoMerge has been rejecting the OrdinaryDiffEqBDF 2.4.1 and OrdinaryDiffEqSDIRK 2.8.2 registrations since 2026-07-29 for two of them. DiffEqBase floors (Core, Differentiation, NonlinearSolve) All three require SciMLBase = "3.40", but the first DiffEqBase permitting SciMLBase 3.40 is 7.10.0. With a DiffEqBase floor of "7"/"7.8" the resolver has no solution at all — `Pkg.instantiate()` on any of the three fails with an unsatisfiable DiffEqBase. Raised to "7.10". OrdinaryDiffEqBDF and OrdinaryDiffEqFIRK -> OrdinaryDiffEqCore "4.12" Both read integrator.is_disco_step and integrator.disco_checkpoint. Those ODEIntegrator fields arrived with the DISCO work merged 2026-07-29 (#3720) and are not in any released Core; the first to carry them is 4.12.0. Against Core 4.11.0 BDF fails to load with FieldError: type OrdinaryDiffEqCore.ODEIntegrator has no field `is_disco_step` FIRK's master tree already diverges from the registered 2.5.0 (which predates the field use), so it is bumped to 2.5.1 to make the corrected floor releasable. OrdinaryDiffEqSDIRK -> OrdinaryDiffEqNonlinearSolve "2.6" Imports can_smooth_est, added in #3823. The version carrying it was never registered (ONLS goes 2.5.0 -> master 2.6.0), so against any released ONLS SDIRK fails to load with UndefVarError: `can_smooth_est` not defined in `OrdinaryDiffEqSDIRK` Audit method, since this class keeps recurring (#2600, #4078, #4079) Diffed the ODEIntegrator struct between the registered Core 4.11.0 tree and master for added fields, then grepped every sublibrary for accesses to them; and cross-referenced every qualified access and explicit import name against the registered OrdinaryDiffEqCore 4.11.0 and OrdinaryDiffEqNonlinearSolve 2.5.0 trees. No sublibrary references a Core *name* absent at 4.11.0 — the only Core gaps are the two struct fields — and can_smooth_est is the only NonlinearSolve gap. Verified locally: SDIRK loads against the in-tree ONLS, and BDF loads and solves (FBDF on a scalar decay problem returns 0.36790983175798864). Metadata-only apart from the FIRK version bump. Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017ZqxphdTA1MydR1WXye9Jc * Also floor Differentiation and NonlinearSolve on Core 4.12 / Differentiation 3.6 Same rule as the DiffEqBase floors in the previous commit, applied to the sibling dependencies rather than DiffEqBase: a package requiring SciMLBase = "3.40" cannot resolve against any sibling version whose own compat caps SciMLBase below 3.40. OrdinaryDiffEqDifferentiation -> OrdinaryDiffEqCore "4.12" OrdinaryDiffEqNonlinearSolve -> OrdinaryDiffEqCore "4.12" OrdinaryDiffEqNonlinearSolve -> OrdinaryDiffEqDifferentiation "3.6" The released Core tops out at 4.11.0, which declares SciMLBase = "3.39", and the released Differentiation at 3.5.0. With the old "4" / "4.6" / "3" floors both packages are unresolvable: Unsatisfiable requirements detected for package OrdinaryDiffEqCore: restricted to versions 4 by OrdinaryDiffEqDifferentiation, leaving 4.0.0 - 4.11.0 restricted by compatibility requirements with SciMLBase to versions: uninstalled Exactly four packages on master require SciMLBase 3.40 — DiffEqBase, OrdinaryDiffEqCore, OrdinaryDiffEqDifferentiation, OrdinaryDiffEqNonlinearSolve — so only their sibling floors need this treatment. Packages that still allow SciMLBase 3.39 resolve fine against the older siblings and are left alone. This fixes the release order: DiffEqBase 7.10.0 (registered), then OrdinaryDiffEqCore 4.12.0, then OrdinaryDiffEqDifferentiation 3.6.0, then OrdinaryDiffEqNonlinearSolve 2.6.0, then the blocked BDF and SDIRK. Verified locally: Core 4.12.0 with [sources] stripped resolves against registry-only dependencies (picking DiffEqBase 7.10.0) and loads; ONLS and Differentiation instantiate and load in-tree. Their registry-only check has to wait until Core 4.12.0 is actually registered. Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: ChrisRackauckas-Claude <accounts@chrisrackauckas.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

The disco-optimizations merge (#3720) landed three files that Runic rejects, so format-check has been failing on master for every PR since. Whitespace and line wrapping only; `runic --check .` is clean across the repo afterwards. Claude-Session: https://claude.ai/code/session_01DKB6v14nZHZPYtKiLsPLDT Co-authored-by: ChrisRackauckas-Claude <accounts@chrisrackauckas.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

oscardssmith reviewed Jun 8, 2026

View reviewed changes

Comment thread lib/OrdinaryDiffEqBDF/src/controllers.jl Outdated

oscardssmith reviewed Jun 8, 2026

View reviewed changes

Comment thread lib/OrdinaryDiffEqCore/src/integrators/controllers.jl

Shreyas-Ekanathan force-pushed the disco-optimizations branch from 931262d to c11227a Compare June 8, 2026 18:10

oscardssmith reviewed Jun 12, 2026

View reviewed changes

Comment thread lib/OrdinaryDiffEqCore/src/integrators/type.jl

oscardssmith reviewed Jun 12, 2026

View reviewed changes

Comment thread lib/OrdinaryDiffEqCore/src/disco.jl Outdated

oscardssmith reviewed Jun 12, 2026

View reviewed changes

Comment thread lib/OrdinaryDiffEqCore/src/disco.jl Outdated

oscardssmith reviewed Jun 12, 2026

View reviewed changes

Shreyas-Ekanathan added 6 commits June 15, 2026 14:37

disco optimizations

408a7a3

addsteps optimization

268bbb0

Update disco_tests.jl

690e356

refactor controller disco logic

a95e473

add biasing

9607466

Update disco.jl

31da61e

Shreyas-Ekanathan force-pushed the disco-optimizations branch from ee7c874 to 31da61e Compare June 15, 2026 18:45

oscardssmith reviewed Jun 15, 2026

View reviewed changes

Comment thread lib/OrdinaryDiffEqBDF/src/controllers.jl Outdated

oscardssmith reviewed Jun 15, 2026

View reviewed changes

Comment thread lib/OrdinaryDiffEqCore/src/integrators/controllers.jl Outdated

Shreyas-Ekanathan and others added 6 commits June 16, 2026 13:06

code cleanup

80d7e74

cache reused vals

c2af3bc

Merge branch 'master' into disco-optimizations

f6f255a

Update OrdinaryDiffEqCore.jl

cba7495

Merge branch 'master' into disco-optimizations

3e53ad1

small bug fix

b033a02

bug fix

e075fe3

another small bug fix

8c1d36e

Shreyas-Ekanathan added 2 commits July 22, 2026 11:09

calling bug

92ec4de

fix test failure

f324536

bdf fix

da80135

oscardssmith approved these changes Jul 29, 2026

View reviewed changes

oscardssmith merged commit fd3f95b into SciML:master Jul 29, 2026
217 of 256 checks passed

ChrisRackauckas-Claude mentioned this pull request Jul 29, 2026

Run Runic on the disco-optimizations files #4064

Merged

4 tasks

ChrisRackauckas-Claude mentioned this pull request Jul 30, 2026

Correct dependency floors blocking the pending base and solver releases #4084

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

Optimizations to Discontinuity Detection Scheme - #3720

Optimizations to Discontinuity Detection Scheme#3720
oscardssmith merged 17 commits into
SciML:masterfrom
Shreyas-Ekanathan:disco-optimizations

Shreyas-Ekanathan commented Jun 5, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

oscardssmith Jun 12, 2026

Uh oh!

Shreyas-Ekanathan Jun 12, 2026

Uh oh!

oscardssmith Jun 12, 2026

Uh oh!

Uh oh!

Uh oh!

oscardssmith commented Jul 16, 2026

Uh oh!

Shreyas-Ekanathan commented Jul 16, 2026

Uh oh!

oscardssmith commented Jul 21, 2026

Uh oh!

Shreyas-Ekanathan commented Jul 21, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Uh oh!

Conversation

Shreyas-Ekanathan commented Jun 5, 2026

Checklist

Additional context

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

oscardssmith Jun 12, 2026

Choose a reason for hiding this comment

Uh oh!

Shreyas-Ekanathan Jun 12, 2026

Choose a reason for hiding this comment

Uh oh!

oscardssmith Jun 12, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

oscardssmith commented Jul 16, 2026

Uh oh!

Shreyas-Ekanathan commented Jul 16, 2026

Uh oh!

oscardssmith commented Jul 21, 2026

Uh oh!

Shreyas-Ekanathan commented Jul 21, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants