Unresolved resonance ranges with LRF=1 are silently dropped (parse_mf2 dispatches on LRF where it means LRU)

[shimwell]

Summary

parse_mf2 (src/endf/mf2.py) selects the unresolved-resonance branch on LRF == 2, but the resolved/unresolved distinction is carried by LRU, not LRF.

https://github.com/shimwell/endf-python/blob/main/src/endf/mf2.py#L42-L53

            if LRF == 0:
                ...
            elif LRU in (0, 1):
                # resolved resonance region
                rrange.update(_FORMALISMS[LRF].dict_from_endf(file_obj, NRO))
            elif LRF == 2:
                # unresolved resonance region
                rrange.update(Unresolved.dict_from_endf(file_obj, LFW, LRF, NRO))

Per ENDF-102, LRU=1 is the resolved region and LRU=2 the unresolved one. Within LRU=2, LRF selects the representation: LRF=1 for the energy-independent cases (Case A, LFW=0; Case B, LFW=1) and LRF=2 for the fully energy-dependent one (Case C).

So a range with LRU=2, LRF=1 matches neither elif: not LRU in (0, 1), and not LRF == 2. It falls through with nothing read.

That Unresolved.dict_from_endf contains explicit LFW == 0 and LRF == 1 and LFW == 1 and LRF == 1 branches — code the current dispatch can never reach — is fairly strong evidence the condition was meant to be LRU == 2.

Reproduction

A minimal MF=2 section with LRU=2, LRF=1, LFW=0 (Case A):

import io
from endf.mf2 import parse_mf2

def f(v): return f"{v: .6E}".replace('E+0','+').replace('E-0','-').replace('E+','+').replace('E-','-').rjust(11)
def i(v): return str(int(v)).rjust(11)
def line(*x): return "".join(x).ljust(66) + "9999 2151\n"

text = (
    line(f(95244), f(241.968), i(0), i(0), i(1), i(0))       # HEAD, NIS=1
  + line(f(95244), f(1.0),     i(0), i(0), i(1), i(0))       # isotope, LFW=0, NER=1
  + line(f(100.0), f(1000.0),  i(2), i(1), i(0), i(1))       # range: LRU=2, LRF=1
  + line(f(2.5),   f(0.9),     i(0), i(0), i(1), i(0))       # SPI, AP, LSSF, NLS=1
  + line(f(241.968), f(0.0),   i(0), i(0), i(6), i(1))       # LIST header, NJS=1
  + line(f(10.0), f(3.0), f(1.0), f(0.5), f(0.04), f(0.0))   # D, AJ, AMUN, GNO, GG
)

r = parse_mf2(io.StringIO(text))['isotopes'][0]['ranges'][0]
print(sorted(r))

['EH', 'EL', 'LRF', 'LRU', 'NAPS', 'NRO']

Only the range header survives. SPI, AP, LSSF, NLS and the whole ranges list are gone.

Effect

• Every unresolved resonance range written with LRF=1 — Case A and Case B, which is how most actinide and many structural-material evaluations write their URR — returns no parameters at all. There is no error, so a consumer sees an evaluation that simply appears to have no URR data.
• Because the branch also never reads the records, the file position is left before them. Any subsequent range in the same section is then parsed starting from the wrong record, so the corruption is not confined to the range that was skipped.
• LRU=2, LRF=2 (Case C) happens to work, since LRF == 2 is true for it. That is why this is not immediately obvious.

Suggested fix

            elif LRU == 2:
                # unresolved resonance region
                rrange.update(Unresolved.dict_from_endf(file_obj, LFW, LRF, NRO))

Worth a test with an evaluation that has a Case A or Case B URR — U238 or Am241 from ENDF/B-VIII would do.

Notes

Found while porting the reader to Rust. The port reproduces the current dispatch deliberately, with a comment pointing here, so the two agree until this is settled; the Case A/B readers are implemented on the Rust side and switch on as soon as the condition is corrected.

[shimwell]

Cross-checked against other readers: confirmed, and it is a regression

Compared against OpenMC (openmc-dev/openmc @ 9a62e43), which this reader descends from.

OpenMC dispatches on LRU in both branches. openmc/data/resonance.py:

items = get_cont_record(file_obj)
resonance_flag = items[2]  # flag for resolved (1)/unresolved (2)
formalism = items[3]       # resonance formalism

if resonance_flag in (0, 1):
    # resolved resonance region
    erange = _FORMALISMS[formalism].from_endf(ev, file_obj, items)

elif resonance_flag == 2:
    # unresolved resonance region
    erange = Unresolved.from_endf(file_obj, items, fission_widths)

resonance_flag is items[2], i.e. LRU, and both branches test it. Here the second branch tests LRF instead:

elif LRU in (0, 1):
    rrange.update(_FORMALISMS[LRF].dict_from_endf(file_obj, NRO))
elif LRF == 2:                    # <- LRU is meant
    rrange.update(Unresolved.dict_from_endf(file_obj, LFW, LRF, NRO))

So this is not inherited behaviour that might have a reason behind it — it is a one-word divergence from the ancestor, and the ancestor is right. Case C (LRU=2, LRF=2) works only because the two values coincide there.

Verdict: real bug, introduced in this package. Of the issues raised while porting, this is the one I would fix first: Cases A and B are how most actinides write their unresolved region, and the failure is silent and leaves the file position wrong, so a later range in the same isotope is misparsed rather than merely missing.

_{Also checked ENDFtk (njoy/ENDFtk @ 6596073), which models LRU and LRF as separate discriminants throughout and never conflates them.}

---

Generated by Claude Code

[shimwell]

Fixed in ad0fca1

src/endf/mf2.py now dispatches on LRU, and so does crates/endf/src/mf/mf2.rs.

Proven before and after, with a built file

No fixture had a Case A range, so tools/make_urr_endf.py writes one:
tests/synthetic-urr-cases.endf.xz carries a Case A range (LFW=0), a Case B
range (LFW=1) and — the important part — a resolved Breit-Wigner range
immediately after Case A, because the alignment is the dangerous half.

Before the fix, on that file:

range 0: LRU=2 LRF=1 EL=1000  EH=30000  -> []
range 1: LRU=0 LRF=0 EL=0.5   EH=0.94   -> ['AP', 'NLS', 'SPI']

Range 0 lost everything: SPI, AP, LSSF, NLS and both L values. Range 1 is not
even the right record — EL=0.5 and EH=0.94 are range 0's SPI and AP,
read as a range header because range 0's records were never consumed.

After:

range 0: LRU=2 LRF=1 EL=1000  EH=30000  -> ['AP','LSSF','NLS','SPI','ranges']
range 1: LRU=1 LRF=2 EL=30000 EH=100000 -> ['AP','NLS','SPI','sections']

Tests

tests/test_parser_regressions.py — Case A read with both L values and their
differing J counts, Case B with its NE/ES energy grid and per-J fission widths,
the following range still aligned, and Case C (U235) unchanged.
crates/endf/src/mf/mf2.rs::an_unresolved_range_with_lrf_1_is_read does the
same on the Rust side, including the range behind it.

Thanks for pushing back on the reasoning — the argument here is not "OpenMC
does it differently" but that LRU is definitionally the resolved/unresolved
flag, and the file above shows the consequence directly.

---

Generated by Claude Code