Skip to content

Silent trajectory corruption under symplectic-recovery storms (timestep starvation) #508

Description

@krystophny

Summary

When the fixed-step symplectic integrator is starved of timestep resolution in a chart whose coordinate surfaces are far from flux surfaces, the recovery path degrades trajectories silently: markers accumulate thousands of recovery events per marker and produce physically wrong (excess) losses, while almost no retry_exhausted events are reported and the run exits cleanly.

Observed case

  • SIMPLE 69fe8c364d55452ee203bbf06836510caafa7540, libneo e2b281b1bc9f9f48f9526622445e0b2c0f8a4984.
  • Proxima 5C (QI, 4 field periods) map2disc chartmap (non-flux-aligned harmonic-extension chart), 3.5 MeV alphas from s=0.2, 500 ms traces, implicit midpoint, npoiper2 = 256.
  • Result: 740 of 8192 markers lost, versus 424–429 for three other charts of the same wall/ensemble (verified marker-matched: on identical markers the corrected run agrees with an independent loss-detection method to a median loss-time difference of 79 µs).
  • Diagnostics on 33 inspected corrupted markers: all 33 showed corrupted trajectories with roughly 7600 symplectic recovery events per marker, but only 6 retry_exhausted events total were surfaced. No warning or error otherwise.
  • With npoiper2 = 512 (only changed parameter) recoveries drop to about 28 per marker and the excess loss disappears (424/8192).

Problem

A recovery mechanism that fires thousands of times per marker is no longer recovering — it is integrating a different, wrong trajectory. The user gets no signal: exit codes, logs, and retry_exhausted counts all look nominal.

Suggested robustness improvements

  1. Count recovery events per marker and flag markers whose count exceeds a threshold (e.g. mark them with a distinct exit code such as recovery_storm instead of a physical loss/confined status).
  2. Emit a run-level warning when the ensemble-mean recovery rate per timestep exceeds a sane bound, suggesting a smaller timestep.
  3. Consider making repeated recovery within a short window escalate to retry_exhausted rather than resetting the retry budget.

Full investigation record (private project, available on request): runs/simple-production/map2disc-leak-investigation.md in the JNME-D-26-00030 revision repository.

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