Repository navigation
parse_mf7_mt4 reads LI from each temperature record and then discards it #16
Description
Summary
In parse_mf7_mt4 (src/endf/mf7.py), the loop over additional temperatures unpacks LI from the record and then stores the outer LT under the key 'LT', so LI is never recorded.
https://github.com/shimwell/endf-python/blob/main/src/endf/mf7.py#L96-L104
for i in range(NB):
params, S = get_tab1_record(file_obj)
T, beta, LT, *_ = params
temp_data = [{'T': T, 'beta': beta, 'LT': LT, 'S': S}]
for _ in range(LT):
params, S = get_list_record(file_obj)
T, beta, LI, *_ = params
temp_data.append({'T': T, 'beta': beta, 'LT': LT, 'S': S})
# ^^^^^^^^ LI is droppedCompare parse_mf7_mt2, which does the same walk correctly:
for _ in range(LT):
params, S = get_list_record(file_obj)
T, _, LI, *_ = params
temp_data.append({'T': T, 'LI': LI, 'S': S})Effect
LI is the interpolation scheme to use between this temperature and the previous one (ENDF-102 section 7.4). Dropping it means a consumer reconstructing S(alpha, beta, T) has no way to know how to interpolate in temperature and has to assume a scheme.
The stored 'LT' is also misleading: every entry in temp_data reports the same outer LT, which is the count of additional temperatures, not a property of the entry.
LI is genuinely unused today (nothing downstream reads it), so this is data loss rather than a wrong answer — but it is lost at parse time, which is the one place it cannot be recovered later.
Suggested fix
Match MT=2:
temp_data.append({'T': T, 'beta': beta, 'LI': LI, 'S': S})Note this changes a key name in the returned dict for entries after the first, so it is a small API change worth a changelog line.
Notes
Found while porting the reader to Rust. The port reproduces the current behaviour — the subsequent-temperature struct carries the outer lt and no li — with a comment pointing here, so the two agree until this is settled.
Activity
Port MF7, MF8, MF9 and MF10
Port MF7, MF8, MF9 and MF10
Project MF 1 MT458, 6, 7 and 26 through section_data
shimwell commentedon Aug 9, 2026
Cross-checked against other readers: confirmed, LI is real data
Compared against ENDFtk (
njoy/ENDFtk@6596073) and OpenMC (openmc-dev/openmc@9a62e43).ENDFtk keeps LI, one per additional temperature.
section/7/4/TabulatedFunctions/ScatteringFunction.hpp:temperatures_is thestd::vector<ListRecord>of the additional temperatures, soLI()yields one flag per record — exactly the values this reader reads and drops. ENDFtk treats them as part of the section's meaning, not as padding.So the flags are not redundant with the outer LT: LT says how many extra temperatures follow, LI says how to interpolate between each and the one before it. Overwriting the second with the first, as
parse_mf7_mt4does:loses the interpolation scheme and reports a value that has nothing to do with the record it is attached to.
Verdict: real bug.
Provenance
Not inherited in a form worth comparing. OpenMC's
openmc/data/thermal.pyreads the additional temperatures withget_list_recordand takes onlyparams[0](the temperature), buildingkTsand the S arrays rather than a dict of record fields. So OpenMC drops LI too — but it never claims to have it, whereas this reader exposes anLTkey per temperature and fills it with the wrong variable. The mislabelling is specific to this package.Generated by Claude Code