Repository navigation
Euler-Lagrange integration accepts ~2.3x more ODE steps since #355 #379
Description
Activity
Cause: #350, not #355. Commit
5f32a39cereplaced the hard-coded pass-1mpsi = 128of the auto grid withPASS1_INTERVALS = 1024(GridRefinement.jl). The finer pass 1 measures more curvature, so the refined ψ grid grew from 196 to 573 knots. With the defaultabstol = 1e-6, the Euler-Lagrange integration takes about 8 steps per knot interval, whatever the interval's width, so the step count followed the knot count.DIIID-like_ideal_example, ForceFreeStates only,save_interval = 1, parallel integrator.PASS1_INTERVALSis the only change, on1d30dfba:PASS1_INTERVALSKnots Steps Δ′[1,1] Δ′[4,4] Pass-1 warning 128 (pre-#350 value) 205 1991 5.67 −2316 under-sampled 256 293 2539 9.21 −2277 under-sampled 512 381 3308 9.14 −2242 none 1024 (current) 573 4738 9.34 −2231 none - Reverting to 128 restores the pre-EQUIL - BUGFIX - Fix ideal Δ′ non-convergence on the auto psi-grid #350 step count (1991 vs 1910) but breaks Δ′. The extra knots are needed, even with EQUIL - BUGFIX - Fix ideal Δ′ non-convergence on the auto psi-grid #350's rational-surface bracketing in place.
- 512 gives Δ′ within the 256–1024 spread, with no warning and 33 % fewer knots. It's worth considering, but Δ′ across this ladder itself only agrees to about 2 %.
Fix: I tested this as part of verifying #480, which scales the ODE absolute tolerance to each solution column, as Fortran DCON does. On the same 573-knot grid, steps fall from 4738 to 1464, below the 1910 before #350. Energies and Δ′ are unchanged by the tolerance. Steps still grow with knots (about 2.6 per interval); see #376. So #480 does not fix the root cause of what is going on here (and I am not going to go any deeper since I didn't have any part in the
autogrid selection), but it at least counteracts it
Noticed while validating #365 (which is unaffected — its trajectory is bit-identical on both sides of this change).
Symptom
examples/DIIID-like_ideal_example, same deck, same environment, same machine:integration/nstep_total(accepted)integration/nstep(saved)5b6ba34a(pre-#355, matches all July-era runs)1d30dfbaand currentdevelopRoughly 2.3x the accepted steps, with the saved count following (bands + every
save_interval-th step). Since the EL integration dominates wall time, this is approximately a 2x runtime and solution-storage increase on every run.The trajectory is not wrong — at the saved nodes the solution is bit-identical across #365's merges at both densities, and the resonant quantities agree to ~1e-10. The step controller is simply accepting more, smaller steps.
Ruled out
save_intervaldefault, the save-band condition,near_q_frac, and the chunking code are textually unchanged across the range.[ForceFreeStates]settings are unchanged (comment drift only).psilim/qlimare identical in the runs (0.995 / 6.200), so the domain and the edge-scan band did not move.Bracket
5b6ba34a..1d30dfbacontains only #355 (ab329276), the #357 docs merge, and a benchmarks cleanup — #355 is the only src change. Plausible mechanism: a numerical change in how the EL matrices or their splines are built (the freeze-control/locstab refactor touchedSing.jl), slightly changing the RHS smoothness and making the Vern9 controller more conservative. Not yet bisected within #355.Reproduce