Commit afa4ad3
committed
test/minibatch: use Float64 for time, state, and parameters
The minibatch test was using `Float32` for `u0`, `tspan`, and the
network parameters (via the default `Lux.setup` eltype). It is a test
of the minibatching loop, not of Float32 throughput, and the Float32
choice exposes a fragile codepath in `SciMLSensitivity`'s
`InterpolatingAdjoint` checkpoint re-solve:
1. The sub-checkpoint forward re-solve seeds its initial `dt` with
`abs(cpsol_t[end] - cpsol_t[end - 1])` from the previous
re-solve.
2. With `Float32` time, an adaptive Tsit5 step that lands one ulp
past `interval[2]` is followed by a tiny "correction" step back
to `interval[2]`, leaving the last two `cpsol_t` entries 1 ulp
apart (~1.2e-7).
3. That ulp value becomes the `dt` for the next re-solve over an
interval ~0.052 wide. The Tsit5 controller, given that
microscopic seed, ends up emitting a `cpsol` whose time vector
has only the start point.
4. On the iteration after that, `cpsol_t[end - 1]` becomes
`cpsol_t[0]` and the test errors out with
`BoundsError: attempt to access 1-element Vector at index [0]`.
`Float64` has ~1e-16 epsilon, so the same ulp-collision pattern
produces a `dt` far below any abstol/reltol the controller cares
about and the feedback loop never amplifies into a 1-point cpsol.
The test passes against the unmodified, registered SciMLSensitivity
v7.103.0 with the Float64 change alone, no upstream patch needed.
Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>1 parent c5a4c13 commit afa4ad3
1 file changed
Lines changed: 3 additions & 3 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
24 | 24 | | |
25 | 25 | | |
26 | 26 | | |
27 | | - | |
| 27 | + | |
28 | 28 | | |
29 | | - | |
| 29 | + | |
30 | 30 | | |
31 | 31 | | |
32 | 32 | | |
33 | 33 | | |
34 | 34 | | |
35 | 35 | | |
36 | 36 | | |
37 | | - | |
| 37 | + | |
38 | 38 | | |
39 | 39 | | |
40 | 40 | | |
| |||
0 commit comments