MF=1 MT=458 reports ZA as a float where every other section reports an int

[shimwell]

Summary

parse_mf1_mt458 (src/endf/mf1.py) reads its opening record with get_cont_record rather than get_head_record:

https://github.com/shimwell/endf-python/blob/main/src/endf/mf1.py#L171

    ZA, AWR, _, LFC, _, NFC = get_cont_record(file_obj)

The two differ in exactly this: get_head_record converts the first field to an integer, get_cont_record leaves it a float.

def get_head_record(file_obj):
    line = file_obj.readline()
    ZA = int(float_endf(line[:11]))   # <-- int
    ...

def get_cont_record(file_obj, skip_c=False):
    ...
    C1 = float_endf(line[:11])        # <-- float

Effect

>>> m = endf.Material('n-095_Am_244.endf')
>>> type(m[1, 451]['ZA']), type(m[1, 458]['ZA'])
(<class 'int'>, <class 'float'>)

So material[1, 458]['ZA'] is 95244.0 while every other section reports 95244. Anything that uses ZA as a dict key, compares it across sections, or formats it for a filename gets a surprise in this one place.

MT=458's record is a HEAD record per ENDF-102 — it has ZA and AWR in the first two fields like the rest — so this looks like an oversight rather than a deliberate choice.

Suggested fix

    ZA, AWR, _, LFC, _, NFC = get_head_record(file_obj)

This changes the type of a value that is currently exposed, so it is worth a line in the changelog even though the numeric value is unchanged.

Notes

Found while porting the reader to Rust. The port reproduces the current behaviour — Mf1Mt458::za is an f64 where every other section's is an i64 — with a comment pointing here, so the two agree until this is settled.

[shimwell]

Cross-checked against other readers: inherited from OpenMC, but ENDFtk disagrees

Compared against OpenMC (openmc-dev/openmc @ 9a62e43) and ENDFtk (njoy/ENDFtk @ 6596073).

OpenMC reads MT=458 the same way. openmc/data/fission_energy.py:

file_obj = StringIO(ev.section[1, 458])

# Read first record and check whether any components appear as
# tabulated functions
items = get_cont_record(file_obj)

A CONT record leaves C1 as the raw float, where get_head_record would convert it to int. So the float ZA is inherited, not introduced here.

ENDFtk types ZA as an integer for every section. section/BaseWithoutMT.hpp:

int ZA_;
...
constexpr int ZA() const { return this->ZA_; }

Every section derives from this, MF=1 MT=458 included, so there is no section where ENDFtk reports ZA as anything but an int. The ENDF-6 convention is that ZA is an integer written into a float field, and the first record of a section is a HEAD record regardless of which file it belongs to.

Verdict: real inconsistency, low severity. Nothing is misparsed — 92235.0 and 92235 are the same number — but material[1, 458]['ZA'] is the only ZA in the package that is not an int, so anything that formats or dict-keys on it has to special-case one section. Reading MT=458 with get_head_record like every other section would settle it.

The Rust port reproduces the float deliberately, with this issue linked at the site (crates/endf/src/mf/mf1.rs), so the parity harness stays green either way; flipping it here is a one-line change on both sides.

---

Generated by Claude Code