Skip to content

exec runner: carry live dumps across segment boundaries in append mode - #273

Merged
srmnitc merged 1 commit into
mainfrom
fix/exec-runner-live-dump-append
Jul 31, 2026
Merged

exec runner: carry live dumps across segment boundaries in append mode#273
srmnitc merged 1 commit into
mainfrom
fix/exec-runner-live-dump-append

Conversation

@srmnitc

@srmnitc srmnitc commented Jul 31, 2026

Copy link
Copy Markdown
Member

n_print_steps_equilibration (#272) only works under the library runner. Under the executable runner every mode=fe run dies.

n_print_steps_equilibration (#272) only works under the library runner.
Under the executable runner every mode=fe run dies at the first segment
boundary with

    RunnerStateError: dump(s) ['deq'] are live at a segment boundary;
    calphy must undump before a read

The `deq` dump has to stay open across run_pressure_convergence and
run_spring_constant_convergence, and both of those sync(), so the feature
can never complete on that backend.

check_replayable() refused this for a real reason: a replayed `dump`
reopens its file in truncate mode, so every frame written before the
boundary would be silently lost. Rather than forbid the crossing, make it
faithful -- build_replay_header() now re-emits each live dump followed by
`dump_modify <id> append yes`, so frames accumulate across segments
instead of being truncated.

- SessionState.dumps: id -> {"command", "dump_modify"}, mirroring how
  fixes already track fix_modify, so a dump_modify also survives a
  boundary
- dump_modify added to STICKY_TOKENS (it was absent from the vocabulary
  entirely, so emitting one was rejected as an unknown command) with an
  unknown-id guard
- check_replayable(): a live dump is no longer fatal

The library runner is untouched -- its sync() is a no-op, which is why
the feature already worked there. With n_print_steps_equilibration = 0
(the default) no dump is created and neither backend changes behaviour.

test_live_dump_at_sync_raises encoded the old contract and is replaced by
tests for the new one: append-on-replay with correct ordering, no append
in seg 0 (the segment that creates the file), a user dump_modify
replaying ahead of the append directive, unknown-id rejection, and
undump still dropping the dump entirely.

Verified on GPU with pair_style grace: 3 segments / 163 frames /
timestep 26000, against a hard stop at 101 frames / step 20000 before.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@srmnitc
srmnitc merged commit 0e596f8 into main Jul 31, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant