`--enable-write-all-solutions` aborts when the physical timestep index reaches `Schedule::size()`

[7rbiX]

Description

With the packaged Flow 2026.04 release, --enable-write-all-solutions=true reproducibly aborts in the asynchronous output writer after a successful nonlinear solve when the physical timestep sequence reaches the number of schedule snapshots.

The reported exception is:

Simulation aborted as program threw an unexpected exception: Failure in the TaskletRunner while writing output.
ERROR: Uncaught std::exception when running tasklet: vector::_M_range_check: __n (which is 16) >= this->size() (which is 16).

I reproduced the failure twice with the same binary and deck. The combined stdout/stderr log was byte-identical in both runs, as was the unified restart output produced before the failure.

Environment

• Ubuntu 24.04 under WSL2
• Official OPM PPA package libopm-simulators-bin 2026.04-1~noble
• /usr/bin/flow, one thread

Reproduction

Start from spe1/SPE1CASE2_ACTNUM.DATA at opm-data commit eaa2261683a97027e057c2bc49612ad1c86390b3.

Apply these output-only changes:

@@ -67,6 +67,8 @@
 UNIFOUT
 
 GRID
+
+INIT
 -- -------------------------------------------------------------------------
 NOECHO
@@ -289,6 +291,9 @@
 8300 1.270
 8450 1.270 /
 
+RPTSOL
+  'RESTART=2' 'FIP' /
+
 SUMMARY
 -- -------------------------------------------------------------------------
@@ -382,7 +387,7 @@
 	'PRES' 'SGAS' 'RS' 'WELLS' /
 
 RPTRST
-	'BASIC=1' /
+	'BASIC=1' 'RPORV' 'SFIP' 'FLOWS' /

Then run:

OMP_NUM_THREADS=1 flow \
  --threads-per-process=1 \
  --enable-write-all-solutions=true \
  SPE1CASE2_ACTNUM.DATA

The run reaches report step 13/15 at day 304. The day 304 to 334 nonlinear solve completes, and then the output tasklet throws the exception above.

Expected behavior

Every accepted physical timestep should be written without indexing outside the schedule. In this case, Flow should complete the simulation rather than abort after the solve.

Likely cause

Source inspection suggests that the physical output sequence is being reused as a schedule/report-step index:

1. EclipseIO::reportIndex() maps a supplied zero-based physical timestep index to time_step + 1.
2. That value is passed to Summary::add_timestep().
3. The summary path later uses the sequence as a schedule index in sched_[last.seq], and Schedule::operator[] ultimately uses snapshots.at(index).

For the failing write, the zero-based physical timestep index is 15, so reportIndex() yields 16. The schedule has 16 snapshots, with valid indices 0 through 15. This matches the observed at(16)-on-size-16 exception exactly.

The behavior appears related to the every-timestep output work in opm-common#4104 and its companion opm-simulators#5426. The same indexing path is still present on current master at the immutable commit linked above.

A fix likely needs to keep the enclosing schedule/report-step index separate from the physical-output sequence number. I have not opened a patch because the intended restart and summary numbering semantics should be confirmed before changing that interface.