parse_mf7_mt4 reads LI from each temperature record and then discards it

[shimwell]

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 dropped

Compare 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.

[shimwell]

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:

/**
 *  @brief Return the temperature interpolation flags (LT values will be ...
 */
auto LI() const {
  return this->temperatures_ | std20::views::transform( ... );
}

temperatures_ is the std::vector<ListRecord> of the additional temperatures, so LI() 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_mt4 does:

for _ in range(LT):
    params, S = get_list_record(file_obj)
    T, beta, LI, *_ = params          # LI read
    temp_data.append({'T': T, 'beta': beta, 'LT': LT, 'S': S})   # and discarded

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.py reads the additional temperatures with get_list_record and takes only params[0] (the temperature), building kTs and 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 an LT key per temperature and fills it with the wrong variable. The mislabelling is specific to this package.

---

Generated by Claude Code