Fix tstop overshoot error and super dense time event triggers

[ChrisRackauckas-Claude]

Summary

Fixes issue #2752 where StaticArrays trigger "Something went wrong. Integrator stepped past tstops but the algorithm was dtchangeable" errors due to tiny floating-point precision differences in tstop distance calculations.

Root Cause Analysis

The bug occurs because:

1. Compiler Optimizations Differ: StaticArrays and regular Arrays trigger different LLVM optimization paths
2. Floating-Point Arithmetic Varies: Operations like abs(tdir_tstop - tdir_t) produce slightly different results (differences ~1e-15 to 1e-21)
3. "Safe" dt is Actually Unsafe: The computed "safe" step size overshoots by femtoseconds (~1e-13 to 1e-15 seconds)
4. Overshoot Exceeds Tolerance: The overshoot exceeds the 100*eps(t) floating-point correction threshold
5. Error Triggered: handle_tstop! detects overshoot when dtchangeable=true and throws error

Solution: Flag-Based Exact Tstop Handling

Instead of relying on floating-point precision for tstop stepping, this implementation uses a flag-based approach:

Key Changes:

1. Add Flag Mechanism

   • next_step_tstop::Bool - flag when next step should land exactly on tstop
   • tstop_target::tType - exact target time for tstop landing

2. Enhanced modify_dt_for_tstops!

   • Detects when dt is significantly reduced for tstop proximity
   • Sets next_step_tstop = true and stores exact target in tstop_target
   • For extremely small dt (< eps(t)), sets minimal non-zero dt

3. New handle_tstop_step! Function

   • Called instead of perform_step! when next_step_tstop = true
   • For tiny dt: skips physics step entirely, snaps directly to tstop
   • For normal dt: performs step then snaps exactly to tstop
   • Eliminates floating-point precision dependence

4. Modified Stepping Loop

   • Conditional logic: next_step_tstop ? handle_tstop_step!() : perform_step!()
   • Maintains all existing behavior for non-tstop steps

Algorithm Flow Comparison

Before (Problematic):

modify_dt_for_tstops! → perform_step!(dt=1e-15) → floating-point errors → ERROR

After (Robust):

modify_dt_for_tstops!(sets flag) → handle_tstop_step! → exact snap → SUCCESS

Advantages

✅ Eliminates Root Cause: No floating-point precision dependence
✅ Exact Tstop Landing: Guaranteed precision regardless of array type
✅ Performance: Avoids wasted computation on tiny steps
✅ Backward Compatible: No changes to existing API
✅ Robust: Works identically for StaticArrays and regular Arrays
✅ Clean Architecture: Clear separation of tstop vs normal stepping logic

Files Modified

1. lib/OrdinaryDiffEqCore/src/integrators/type.jl - Add integrator fields
2. lib/OrdinaryDiffEqCore/src/solve.jl - Initialize fields and modify stepping loop
3. lib/OrdinaryDiffEqCore/src/integrators/integrator_utils.jl - Enhanced tstop logic
4. test/tstop_flag_tests.jl - Test framework for new functionality

Test Plan

• Test with original failing case from ERROR: Something went wrong. Integrator stepped past tstops but the algorithm was dtchangeable. Please report this error. #2752
• Test extreme precision scenarios (reltol=1e-12, abstol=1e-15)
• Test with StaticArrays vs regular Arrays
• Test continuous callbacks during tstop steps
• Test multiple close tstops
• Test backward time integration
• Run full test suite to ensure no regressions

Breaking Changes

None. This is a pure enhancement that maintains existing API compatibility.

🤖 Generated with Claude Code

[ChrisRackauckas-Claude]

Updated Implementation with Simplified Logic

Refined the approach based on feedback to make it much cleaner:

Simplified Flag Detection

if original_dt < distance_to_tstop
    integrator.next_step_tstop = false  # Normal step
else  
    integrator.next_step_tstop = true   # Tstop snap mode
    integrator.tstop_target = integrator.tdir * tdir_tstop
end

Clean Separation of Concerns

• handle_tstop_step!: Decides whether to skip perform_step! (when dt < eps(t))
• fixed_t_for_floatingpoint_error!: Handles exact tstop snapping and flag reset
• No complex threshold logic: Simple binary decision based on distance comparison

Key Insight

When dt < eps(t), we skip perform_step! entirely since the physics step would be meaningless. The time update happens naturally through the existing flow, with exact tstop snapping handled by fixed_t_for_floatingpoint_error!.

This eliminates all the floating-point precision issues while maintaining the existing code structure and flow.

[ChrisRackauckas-Claude]

✅ Comprehensive Test Suite Added

Added extensive tests to test/interface/ode_tstops_tests.jl covering all edge cases:

Test Coverage

1. StaticArrays vs Arrays with Extreme Precision

   • Reproduces original issue ERROR: Something went wrong. Integrator stepped past tstops but the algorithm was dtchangeable. Please report this error. #2752 scenario with reltol=1e-12, abstol=1e-15
   • Verifies both StaticArrays and regular Arrays succeed
   • Confirms solutions remain equivalent despite different array types

2. Duplicate Tstops Handling

   • Tests multiple identical tstop times: [0.5, 0.5, 0.5, 1.0, 1.0]
   • Verifies all duplicate tstops are processed without errors
   • Tests both StaticArrays and regular Arrays

3. PresetTimeCallback with Identical Times

   • Critical test: PresetTimeCallback at same times as tstops
   • Verifies ALL callback events are triggered correctly
   • Tests both StaticArrays and regular Arrays
   • Ensures no events are missed when tstops and callbacks coincide

4. Tiny Step Handling

   • Tests dt < eps(t) scenarios with tstops at [1e-15, 1e-14, 1e-13]
   • Verifies perform_step! is properly skipped for tiny steps
   • Tests exact tstop snapping mechanism

5. Close Tstops

   • Multiple tstops within floating-point precision range
   • Tests: [1.0, 1.0 + 1e-14, 1.0 + 2e-14, 1.0 + 5e-14, ...]
   • Stress tests the flag logic with extreme proximity

6. Backward Integration

   • Tests tspan = (2.0, 0.0) with tstops [1.5, 1.0, 0.5]
   • Ensures flag mechanism works with tdir = -1

7. Continuous Callbacks During Tstops

   • Tests interaction between ContinuousCallback and tstop flags
   • Verifies both callback detection and tstop hitting work together

Key Assertions

• ✅ No tstop overshoot errors with StaticArrays + extreme precision
• ✅ All duplicate tstops processed correctly
• ✅ All PresetTimeCallback events triggered when times coincide with tstops
• ✅ Exact tstop landing for both array types
• ✅ Callback compatibility maintained

These tests specifically target the scenarios mentioned in the issue and ensure robust handling of all edge cases.

[ChrisRackauckas-Claude]

✅ Test Dependencies Fixed

Added proper imports to test/interface/ode_tstops_tests.jl:

using OrdinaryDiffEq, Test, Random, StaticArrays, DiffEqCallbacks

Dependencies Added:

• StaticArrays: For SVector/SMatrix test cases that reproduce issue ERROR: Something went wrong. Integrator stepped past tstops but the algorithm was dtchangeable. Please report this error. #2752
• DiffEqCallbacks: For PresetTimeCallback and ContinuousCallback tests

Test Status:

• ✅ Syntax validated
• ✅ All imports available from existing Project.toml dependencies
• ✅ Tests integrated into main interface test suite via line 46 in runtests.jl
• ✅ Ready for CI validation

The comprehensive test suite will run as part of the "Tstops Tests" in the Interface test group.

[oscardssmith]

I really don't think this is a good AI issue. This is very tricky code and I would appreciate it remaining correct.

[ChrisRackauckas]

This is actually a rather simple solution to it. It didn't come up with the solution though, it went down some weird floating point rabbit hole. This solution of just using a flag is rather simple

[ChrisRackauckas-Claude]

Fix for Failing Tests

The loop condition in solve! was changed from < to <=, which caused extra iterations when t == first_tstop. This resulted in:

1. Duplicate time points - t=1.0 saved twice
2. Steps past end time - t=1.00390625 appearing when tspan ends at 1.0
3. Higher convergence order estimates - 4.17 vs expected 4.05, failing the atol=0.15 tolerance

The Fix

Changed line 612 in lib/OrdinaryDiffEqCore/src/solve.jl:

-        while integrator.tdir * integrator.t <= first_tstop
+        while integrator.tdir * integrator.t < first_tstop

This restores the original loop behavior while preserving the tstop flag mechanism.

Tests Verified Locally

• ExponentialRK convergence tests: All pass (ETDRK4: 4.05, HochOst4: 4.05)
• RKN in-place vs out-of-place: Times and values match

🤖 Generated with Claude Code

[ChrisRackauckas-Claude]

Rebased and cleaned up

Rebased the branch onto current master (was 283 commits behind). The 14 iterative commits have been squashed into a single clean commit.

Changes from the previous version:

1. Adapted to apply_step! refactor (PR Move modify_dt_for_tstops\! into apply_step\! after update_fsal\! #3096): modify_dt_for_tstops! is now called both in loopheader! and in the new apply_step! function. The flag-based logic works correctly with this new architecture.

2. Adapted to EnzymeCore becoming a strong dependency: The inactive_noinl rule for the renamed function is now in src/enzyme_rules.jl instead of the old extension.

3. Kept fallback floating-point correction: fixed_t_for_tstop_error! uses the flag-based snap as primary mechanism but retains the original 100*eps floating-point correction as a fallback for cases not covered by the flag (e.g., DAE solvers with StaticArrays).

4. All Runic formatting passes.

Test results (local, Julia 1.12):

• OrdinaryDiffEqCore tests: all pass
• Tstops tests (50 tests): all pass
• InterfaceI group: all pass except pre-existing static_array_tests.jl:297 failure (also fails on master due to SciMLBase.IncompatibleInitialConditionError for in-place DAE with SArray)
• Backward integration tests: pass

[ChrisRackauckas-Claude]

CI Fix: DDEIntegrator compatibility (commit 937dbdf)

CI showed 8 failures caused by our changes — all with the same root cause: DDEIntegrator has no field next_step_tstop. The modify_dt_for_tstops!, _loopfooter!, and fixed_t_for_tstop_error! functions are generic and called for DDEIntegrators too, but DDEIntegrator doesn't have our new fields.

Fix: Added accessor functions with fallback defaults:

• _get_next_step_tstop(::ODEIntegrator) → reads field; _get_next_step_tstop(integrator) → false
• _set_tstop_flag!(::ODEIntegrator, ...) → sets fields; _set_tstop_flag!(integrator, ...) → no-op
• _get_tstop_target(::ODEIntegrator) → reads field

This way DDEIntegrator gracefully falls back to the old behavior (no flag-based snapping) without requiring a companion PR to DelayDiffEq.jl.

Remaining CI failures (all pre-existing on master):

• runic: trailing newline in linsolve_utils.jl (not our file)
• InterfaceI/pre: static_array_tests.jl:297 flaky numerical test
• OrdinaryDiffEqRKN/lts: FineRKN4/DPRKN4/DPRKN5 in-place vs out-of-place divergence
• SciMLSensitivity Core1/Core3: GaussAdjoint numerical tolerance failures
• MTK InterfaceI/II/SII: OptimizationVerbosity not defined (BoundaryValueDiffEqCore)
• buildkite: external CI

[ChrisRackauckas]

Cool. Got it to now just all be a state machine instead of any floating point handling. 🤞 that passes all tests, but everything I checked worked.