You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Let convergence studies drop the trajectories they are not measuring
`test_convergence` retains one full solution object per trajectory per step
size. A `RODESolution` carries the solver cache, the noise process, the problem
and its interpolation, none of which a convergence study needs — it wants the
per-trajectory errors and the endpoints the weak error is formed from. At the
trajectory counts the weak-convergence tests use, that gap is the difference
between passing and being OOM-killed: `SROCKC2WeakConvergence`,
`IIPWeakConvergence` and `OOPWeakConvergence` all die at 15.6 GiB in a 16 GiB
cgroup, with no test output, which is the "runner lost communication with the
server" signature reported in #4036.
Add a `save_solutions` keyword, default `true` so existing behaviour is
unchanged. With `false`, build the `EnsembleProblem` with an `output_func` that
reduces each trajectory to a `ConvergenceTrajectory` as it is solved, so the
full solutions never coexist and the peak is bounded rather than only the
retention. `ConvergenceTrajectory` stores one-tuples and a `NamedTuple` rather
than one-element `Vector`s and the solver's error `Dict`; indexing and key
lookup are unchanged, but the `Dict` alone dominated everything else retained
once a study runs to millions of trajectories.
Reject the combinations that cannot work with an explicit `ArgumentError`:
`weak_timeseries_errors` and `weak_dense_errors` need the full timeseries,
`expected_value` averages the trajectory values themselves, and an
`EnsembleProblem` supplied by the caller has its own `output_func` to set.
Drop `uEltype` from the `ConvergenceSimulation` constructor — it was assigned
and never used, and was the only thing requiring `solutions[i].u[j]` to be a
full solution.
Measured on the four weak files, 16 GiB cgroup, JULIA_NUM_THREADS=2:
weak_srockc2.jl OOM 15.61 GiB @3m29s -> exit 0, 24m31s, 4.69 GiB
oop_weak.jl OOM 15.62 GiB @23m50s -> exit 0, 12m48s, 1.58 GiB
additive_weak.jl (same group) -> exit 0, 3m10s, 1.03 GiB
iip_weak.jl OOM 15.61 GiB @21m24s -> runs fully, 10m13s, 2.22 GiB
Order estimates are bit-identical with and without the reduction.
With no group needing more than 4.69 GiB, remove the `high-memory` runner pin
from all eight groups that carried it. The five StochasticDiffEqWeak groups
needed no code change — they already reduce through their own `output_func` and
peak at 0.71-2.09 GiB, so the label was simply wrong for them.
Fixes#4037
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_01UwLXp5WY1uiqPun7qhwxeU
0 commit comments