Restart fails with `bad optional access` when UNRST contains group slots with blank names

[rhart2121]

Summary

OPM's restart reader iterates all NGMAXZ group slots in a unified restart file (UNRST), processing each as a real group even when the slot's ZGRP entry holds only blanks and its IGRP/SGRP/XGRP records are all-zero. A downstream std::optional<Group> dereference then fails with bad optional access, aborting initialization.

OPM's UNRST writer produces files in this exact state under conditions we have not fully characterized (the writer reserves NGMAXZ slot blocks beyond the actual group count). When such a UNRST is fed back to the OPM reader as a restart source, the reader cannot handle the blank slots its sibling writer produced.

Bug is reproduced using a byte-level mutation of SPE1CASE2.UNRST (OPM's own demo deck). Confirmed on OPM Flow 2025.10 and 2026.04.

Possibly related to #5485 (open issue listing several RESTART bugs), though the failure mode and reproducer here are distinct and minimal.

Reproducer

Environment

• Host OS: macOS Sequoia 15.7.4 (Apple Silicon, M4 Max)
• Container runtime: Docker Desktop with linux/amd64 emulation (Rosetta 2)
• OPM image (prebuilt, not built from source): openporousmedia/opmreleases:2025.10 and openporousmedia/opmreleases:latest (the :latest tag currently resolves to 2026.04)
• Compiler: whichever the official OPM Docker image is built with — not building from source
• Python: with resdata 6.2.9 for the UNRST mutation step

Note: same crash signature on both 2025.10 and 2026.04 images, so the bug is not specific to a single build.

Steps

1. Run SPE1CASE2.DATA (from opm-tests repository) to completion, producing SPE1CASE2.UNRST. Confirm a clean restart works using the standard SPE1CASE2_RESTART.DATA (RESTART SPE1CASE2 60 /).

2. Mutate the UNRST: replace the last INTEHEAD block's corresponding ZGRP/IGRP/SGRP/XGRP records with blank/zero values for slot index 0, leaving slot index 1 (FIELD) intact:

• ZGRP positions [0..4] → 8-char blank strings
• IGRP record 0 (stride = len(IGRP) // NGMAXZ = 99 in SPE1) → all zeros
• SGRP record 0 (stride 112) → all 0.0
• XGRP record 0 (stride 181) → all 0.0
• INTEHEAD NGMAXZ unchanged (already 2)

Python script mutate_spe1_orphans.py (attached) uses resdata's FortIO.WRITE_MODE to write the mutated UNRST while preserving FORTRAN record markers.

3. Build a restart deck pointing at the mutated UNRST and restarting at the last report step:

RESTART
SPE1CASE2_MUTATED 120 /

(where 120 = step index of the last INTEHEAD block in the SPE1CASE2.UNRST 120-step run)

4. Run with flow SPE1CASE2_MUTATED_RESTART.DATA.

Expected vs observed

Expected: restart proceeds. Either the blank slot is skipped (analogous to how blank ZGRP positions within a slot are tolerated), or a clear error message identifies the malformed UNRST.

Observed: OPM prints

Adding group  from restart file       <-- double space; blank name being processed as a group
Adding group FIELD from restart file
[...]
Simulation aborted as program threw an unexpected exception:
Could not initialize the problem: bad optional access

The "Adding group from restart file" line (with a literal blank name) confirms the reader is iterating all NGMAXZ slot blocks rather than only the populated ones. The blank result is then used downstream where a std::optional<Group> is dereferenced.

Cross-version confirmation

Identical output, character-for-character, on both:

• openporousmedia/opmreleases:2025.10
• openporousmedia/opmreleases:latest (which is 2026.04 at filing time)

Root cause hypothesis

The crash occurs in Schedule::load_rst() or one of its callees in opm-common. The reader appears to:

1. Read NGMAXZ from INTEHEAD
2. Iterate for i in 0..NGMAXZ, reading ZGRP[i*stride] as the group name
3. Either pass the blank name forward, or look it up in a map of valid groups
4. Eventually, an std::optional<Group> populated from the blank slot is .value()-ed without checking .has_value()

The "Adding group from restart file" message is printed before the abort, confirming the reader treated the blank slot as a real group rather than skipping it.

Suggested fix

In whichever loop in Schedule::load_rst() reads ZGRP entries, add an early-continue for blank names:

for (int i = 0; i < ngmaxz; ++i) {
    const std::string group_name = trim(zgrp_entry(i));
    if (group_name.empty()) {
        continue;   // skip reserved/orphan slots
    }
    // ... existing handling
}

This matches what the writer presumably already does (it knows which slots have real groups). Symmetrizing reader and writer fixes the bug.

Why this matters

This is not a corner case from invalid UNRST input. OPM produces UNRSTs in this state itself, then cannot read them back. We discovered this while investigating a restart failure on a black-oil simulation; the SPE1 mutation in this issue is a synthetic minimal reproducer of the same failure pattern.

We have not pinpointed which conditions during a simulation cause OPM's writer to produce NGMAXZ greater than the actual group count. In our case, the deck has a single FIELD group, no GRUPTREE, and NGMAXZ=3 with 2 orphan slots. We are happy to share additional UNRST probes if useful for tracking the writer-side question, though the reader-side fix above stands independently.

Attachments

• mutate_spe1_orphans.py — Python script using resdata to mutate SPE1CASE2.UNRST as described in step 2.
• SPE1CASE2_MUTATED_RESTART.DATA (uploaded as SPE1CASE2_MUTATED_RESTART.DATA.txt due to GitHub extension restrictions — rename back to .DATA to use) — modified SPE1CASE2_RESTART.DATA with the RESTART line updated
• probe_spe1_groups.py, probe_sgrp_xgrp.py — diagnostic scripts that produced the byte-level layout summary below.

Diagnostic artifacts

SPE1 byte-level layout, last UNRST block

INTEHEAD[18] (NGRP)   = 0
INTEHEAD[19] (NWGMAX) = 2
INTEHEAD[20] (NGMAXZ) = 2

ZGRP length = 10 (stride 5)
  [0] 'G1      '   <-- group slot 0 name
  [1..4] blank     <-- padding within slot 0
  [5] 'FIELD   '   <-- group slot 1 name
  [6..9] blank     <-- padding within slot 1

IGRP length = 198 (stride 99)
  Record 0: populated (G1)
  Record 1: populated (FIELD)

SGRP length = 224 (stride 112)
XGRP length = 362 (stride 181)
  Both records populated in both arrays

After mutation (slot 0 cleared):

ZGRP[0..4] = blanks (slot 0 name removed)
IGRP record 0 = all zeros
SGRP record 0 = all 0.0
XGRP record 0 = all 0.0
Slot 1 (FIELD) intact across all four arrays.
NGMAXZ unchanged at 2.

This is structurally identical to what we observed in our production UNRST, which has NGMAXZ=3 with 2 leading orphan slots (records 0 and 1 all-zero, record 2 = FIELD) — i.e., the writer produced 2 orphans instead of our deliberately-injected 1.

SPE1CASE2_MUTATED_RESTART.DATA.txt
mutate_spe1_orphans.py
probe_sgrp_xgrp.py
probe_spe1_groups.py

[bska]

Thank you for the report. I think I may be able to help here.

We have not pinpointed which conditions during a simulation cause OPM's writer to produce NGMAXZ greater than the actual group count.

That's intentional. The *GRP restart arrays are always sized according to NGMAXZ (WELLDIMS(3)).

In our case, the deck has a single FIELD group, no GRUPTREE, and NGMAXZ=3 with 2 orphan slots. We are happy to share additional UNRST probes if useful for tracking the writer-side question, though the reader-side fix above stands independently.

If you don't have any named groups besides FIELD then the .UNRST file structure you're describing is the expected state. Tangentially, do you have any wells? If so, I assume they're parented directly to FIELD. In any case, we should obviously detect this situation at restart time and never blindly extract a value from an optional.

[rhart2121]

Thanks Bård, this matches what we found on our side exactly, and confirming the `*GRP` arrays are sized to NGMAXZ (WELLDIMS(3)) closes the loop on the root cause. To your question: yes, we have wells -- about 25 -- and they are all parented directly to FIELD. The deck has no GRUPTREE, no GCONPROD/GCONINJE, no group structure beyond the single FIELD group. WELLDIMS(3) = NGMAXZ is set higher than 1 (we carry a small margin there), so the writer emits the extra blank group slots, and the reader hits the empty optional during schedule reconstruction. So your "single FIELD group, NGMAXZ > actual, orphan slots" description is precisely our configuration. If a deck with only FIELD and a margin on WELLDIMS(3) is a reliable reproducer of the writer-side behavior, that may be the trigger you haven't pinned down -- happy to share UNRST probes or a stripped deck if useful. In the meantime, for anyone else who lands here blocked: there is a clean workaround that sidesteps the crashing path entirely, because it never asks OPM to reconstruct well/group state from the restart file. Instead of the RESTART keyword, use enumerated (explicit) array initialization in the continuation deck: 1. Read PRESSURE, SWAT, SGAS, and RS for the branch report step out of the source UNRST (resdata works fine). Note these come out active-cell length; scatter them into full-grid length per ACTNUM for the SOLUTION section. 2. Write those four arrays into the new deck's SOLUTION section as plain keyword arrays. No EQUIL, no RESTART. 3. Re-declare the wells from scratch (WELSPECS / COMPDAT / WCONPROD / WCONINJE) with start dates at the branch date. OPM treats the new deck as day zero; the reservoir state already reflects the prior run via the input arrays. Because no well or group state is read from the UNRST, the orphan-slot optional in this issue is never reached. The per-cell thermodynamic state is fully pinned by (SGAS, RS) -- saturated where SGAS > 0, otherwise RS fixes the bubble point through the saturated PVTO branch -- so PBUB is not needed and was not even written under RPTRST BASIC=2 ALLPROPS. We validated this two ways. A minimal black-oil case (run a primary, capture step-N arrays, rebuild with enumerated SOLUTION + fresh wells, run forward over the same dates) reproduced the original trajectory to solver noise: PRESSURE diff ~3e-3 psia, saturations/RS ~1e-7 to 1e-8, with gas breaking out at the correct pressure and time -- confirming the bubble point survived the RS-only handoff. We then applied the same recipe to a full field model (~526k active cells, ~25 wells all under FIELD) and it initialized and ran cleanly from the depleted state with no RESTART keyword involved. Not a substitute for the reader-side fix you described -- just a way to keep working in the meantime. Tested on OPM Flow 2025.10 and 2026.04, prebuilt Docker image (openporousmedia/opmreleases), linux/amd64. I’m a semi-retired petroleum engineer and a friend challenged me with a field he had to simulate. A year and a half later we have a great working sim on the primary. We've been playing with a sandbox version of it to setup the secondary side. This part we worked out for the hot start instead of re-start is working well too. Thank you so much for the simulator, have had a great time working with it! Rick Hart

On May 29, 2026, at 6:54 AM, Bård Skaflestad ***@***.***> wrote: bska left a comment (OPM/opm-simulators#7101) <#7101 (comment)> Thank you for the report. I think I may be able to help here. We have not pinpointed which conditions during a simulation cause OPM's writer to produce NGMAXZ greater than the actual group count. That's intentional. The *GRP restart arrays are always sized according to NGMAXZ (WELLDIMS(3)). In our case, the deck has a single FIELD group, no GRUPTREE, and NGMAXZ=3 with 2 orphan slots. We are happy to share additional UNRST probes if useful for tracking the writer-side question, though the reader-side fix above stands independently. If you don't have any named groups besides FIELD then the .UNRST file structure you're describing is the expected state. Tangentially, do you have any wells? If so, I assume they're parented directly to FIELD. In any case, we should obviously detect this situation at restart time and never blindly extract a value from an optional. — Reply to this email directly, view it on GitHub <#7101?email_source=notifications&email_token=CE4HXCPNU6XKBY63KNLLUM345F267A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINJXGQ3DINJTGYYKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4574645360>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CE4HXCOER5RYTNOWCZEOIKD45F267AVCNFSM6AAAAACZSKF7NCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DKNZUGY2DKMZWGA>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CE4HXCMOFBI26GEKAQA5QPT45F267A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINJXGQ3DINJTGYYKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/CE4HXCJB45EVPFWKLISUKTL45F267A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINJXGQ3DINJTGYYKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.

Richard Hart jr ***@***.***

[bska]

Thanks Bård, this matches what we found on our side exactly, and confirming the *GRP arrays are sized to NGMAXZ (WELLDIMS(3)) closes the loop on the root cause.

To your question: yes, we have wells -- about 25 -- and they are all parented directly to FIELD. The deck has no GRUPTREE, no GCONPROD/GCONINJE, no group structure beyond the single FIELD group. WELLDIMS(3) = NGMAXZ is set higher than 1 (we carry a small margin there), so the writer emits the extra blank group slots, and the reader hits the empty optional during schedule reconstruction. So your "single FIELD group, NGMAXZ > actual, orphan slots" description is precisely our configuration. If a deck with only FIELD and a margin on WELLDIMS(3) is a reliable reproducer of the writer-side behavior, that may be the trigger you haven't pinned down -- happy to share UNRST probes or a stripped deck if useful.

Okay, thanks a lot for providing the additional detail. I'll try to reproduce the symptoms on my end with that extra knowledge. If unable, I may ask for some stripped-down .DATA files at a later time, but I already have some idea of what the root cause may be. I'll pick this up in the AM (CEST) on Monday, but I have to leave work now.

Since you're using Docker images, I assume you're not building the simulator from source yourself. If that's the case, and it is of course a completely supported way of working, that may mean that getting the fix will be a bit delayed for you. Our regular release schedule stipulates that the next public simulator release will be in late October/early November 2026 which is of course quite a while away.