Skip to content

InnerLayer.SLAYER - BUGFIX - Make the AMR dispersion root search reproducible across threaded runs #420

Description

@d-burg

The SLAYER dispersion root search is not reproducible run to run: on the same commit, same deck, same pinned environment, fresh runs return growth rates that differ by ~0.1 Hz (0.01 %) at individual rational surfaces, in discrete steps rather than continuous noise.

Measurement

diiid_slayer_n1 (examples/DIIID-like_SLAYER_example, -t auto), two fresh --force harness runs of the same commit, γ in Hz per surface:

commit surface run 1 run 2 step
baf674659 3/1 −251.47513 −251.32989 0.1452
5fe6b4275 2/1 207.11628 206.99457 0.1217
both 4/1 −1118.9185 −1118.8422 0.0763

Every layer input feeding the root (rs, shear, S, D_norm, P_perp, tauk, iota_e) was bit-identical across all four runs, and Q_root / ω moved by ≤ 1e-5, so this is the root search itself, not its inputs. The steps recur at fixed sizes — the same 0.1452 Hz at surface 3/1 appeared in three unrelated comparisons today — which points to the search landing in one of two nearby states per surface rather than to floating-point scatter. The obvious candidate is the threaded AMR/contour search: a different thread interleaving changes which candidate is refined first.

Why it matters

  1. It defeats the regression harness for this quantity. Two samples that land in the same state agree to 1e-5 and look like a tight ceiling; two that don't differ by 0.15 Hz and get flagged CHANGED. Today that produced one false "ceiling" claim and two false CHANGED flags across two PRs before the same-source comparison above exposed it.
  2. A real 0.01–0.02 % effect on γ cannot be attributed to a source change by measurement, because it is the same size as the floor. One such attribution on a merged PR has already been downgraded to "plausible, not resolved."
  3. The diiid_slayer_n1 γ threshold has been raised from 1e-1 to 2.5e-1 as a stopgap so the harness stops flagging null changes. That is a loosened regression bound and should come back down once this is fixed.

Fix

Make the search deterministic: either run the candidate-ordering step serially (the root solve per candidate can stay threaded), or seed/sort candidates so the refinement order does not depend on thread scheduling. A one-line reproducibility test — run the dispersion search twice in-process and assert bit-identical γ — would keep it fixed.

Related: #418 (harness caching made this harder to see).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions