get_tab2_record uses int() where the rest of the reader uses int_endf()

[shimwell]

Summary

get_tab2_record (src/endf/records.py) reads its interpolation pairs with the built-in int(), while the otherwise identical loop in get_tab1_record uses int_endf().

https://github.com/shimwell/endf-python/blob/main/src/endf/records.py#L222-L229

    for _ in range((n_regions - 1)//3 + 1):
        line = file_obj.readline()
        to_read = min(3, n_regions - m)
        for _ in range(to_read):
            breakpoints[m] = int(line[0:11])        # <-- int
            interpolation[m] = int(line[11:22])     # <-- int
            line = line[22:]
            m += 1

against get_tab1_record:

            breakpoints[m] = int_endf(line[0:11])
            interpolation[m] = int_endf(line[11:22])

Effect

int_endf exists because the format permits an integer to be written as an all-blank field, meaning zero:

def int_endf(s: str) -> int:
    return 0 if s.isspace() else int(s)

So a TAB2 record with a blank NBT or INT field raises ValueError: invalid literal for int() with base 10 where the equivalent TAB1 record reads it as 0. TAB2 records appear in MF4, MF5 and MF6, so this is reachable from ordinary evaluations — it just depends on an evaluator leaving a field blank rather than writing an explicit zero.

Suggested fix

Use int_endf in both places, matching get_tab1_record.

Notes

The to_read inner loop also rebinds line = line[22:] rather than indexing at an offset, which is fine but makes the two functions harder to compare; using the same offset arithmetic as get_tab1_record would make the divergence above obvious.

Found while porting the reader to Rust. The port uses the lenient reading in both records, since that is what the format specifies and what TAB1 already does — this is the one place the port deliberately differs from current behaviour, and it only differs on input that currently raises.

[shimwell]

Cross-checked against other readers: inherited, and still worth fixing

Compared against OpenMC (openmc-dev/openmc @ 9a62e43).

Inherited. OpenMC's own get_tab2_record, before it switched to depending on this package (8053111~1, openmc/data/endf.py), is identical:

for j in range(to_read):
    breakpoints[m] = int(line[0:11])
    interpolation[m] = int(line[11:22])
    line = line[22:]
    m += 1

So the bare int() is not a porting mistake.

It is still inconsistent. get_tab1_record in this package reads the same NBT/INT pairs with int_endf, so the two records disagree about how to read the same field. int_endf returns 0 for an all-blank field where int() raises ValueError, which is the whole reason int_endf exists.

Severity: low, and I have no failing file. In every fixture I have, NBT and INT are plain right-justified integers that int() handles. A TAB2 whose interpolation range is written with a blank field would break, and evaluations do write blanks where a zero is meant, but I have not found one that does it here — so treat this as tidiness rather than a defect, unless someone turns up a file.

Since OpenMC now imports get_tab2_record from this package (from endf.records import (..., get_tab2_record)), a fix here would reach OpenMC too.

_{ENDFtk and endf-parserpy both parse these fields through their general integer readers, which tolerate blanks — so both behave like int_endf rather than like int().}

---

Generated by Claude Code