Skip to content

Fix ExplicitTaylor fsallast aliasing to state buffer - #3975

Open
singhharsh1708 wants to merge 1 commit into
SciML:masterfrom
singhharsh1708:fix-explicittaylor-fsallast-aliasing
Open

Fix ExplicitTaylor fsallast aliasing to state buffer#3975
singhharsh1708 wants to merge 1 commit into
SciML:masterfrom
singhharsh1708:fix-explicittaylor-fsallast-aliasing

Conversation

@singhharsh1708

@singhharsh1708 singhharsh1708 commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

Summary

get_fsalfirstlast for ExplicitTaylorCache and ExplicitTaylorAdaptiveOrderCache returned (cache.u, cache.u), aliasing the FSAL buffer to the state buffer itself.

The generic auto-dt heuristic (ode_determine_initdt in OrdinaryDiffEqCore) writes an extra f evaluation into whichever buffer fsallast points to. With this aliasing, that call effectively becomes f(u, u, p, t), which corrupts u mid-evaluation for any RHS that reads from u after writing to du (a normal, valid in-place pattern).

On the Pleiades N-body problem (ODEProblemLibrary.prob_ode_pleiades), several bodies share identical initial velocity components, so the corruption produces coincident positions and a 0/0 division in the pairwise inverse-cube force term. Default-adaptive ExplicitTaylor(order=Val(6)) returns retcode=DtNaN after exactly one step; supplying a starting dt was previously the only workaround.

Fix: give both caches an independent scratch buffer instead of aliasing cache.u, matching ExplicitTaylor2Cache's existing (cache.k1, cache.k1) pattern for the same "FSAL not really used" situation.

Verification

  • ExplicitTaylor(order=Val(6)) on Pleiades under fully default settings (no dt override): retcode=Success, 587 steps, matches the previous dt-workaround result to 4-5 significant figures.
  • Full existing OrdinaryDiffEqTaylorSeries Core test group passes unchanged.
  • New regression test added covering the crash.

Known follow-up (not fixed here)

ExplicitTaylorAdaptiveOrder() had the identical aliasing bug and no longer crashes with DtNaN after this fix, but separately has its own pre-existing error-estimation bug that this fix exposes (previously masked by the crash). Filed as #3976 rather than fixed here. Marked @test_broken in the added test.

Test plan

  • ExplicitTaylor(order=Val(6)) solves Pleiades under default adaptive settings without a dt override
  • Existing Core test suite for OrdinaryDiffEqTaylorSeries passes with no regressions
  • New regression test added and passing

get_fsalfirstlast for ExplicitTaylorCache and
ExplicitTaylorAdaptiveOrderCache returned (cache.u, cache.u),
aliasing the FSAL buffer to the state itself. The generic
auto-dt heuristic writes an extra f evaluation into fsallast,
so this made that call f(u, u, p, t), corrupting u mid-evaluation
for RHS functions that read from u after writing to du.

On the Pleiades N-body problem several bodies share identical
initial velocity components, so the corruption produces
coincident positions and a 0/0 division in the pairwise force
term - default-adaptive ExplicitTaylor(order=Val(6)) returns
retcode=DtNaN after one step. Give both caches an independent
scratch buffer instead, matching ExplicitTaylor2Cache's existing
pattern.
@singhharsh1708
singhharsh1708 force-pushed the fix-explicittaylor-fsallast-aliasing branch from 7db67ee to 72e7246 Compare July 31, 2026 20:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant