get_intg_record writes every element of a row to the same column

[shimwell]

Summary

In get_intg_record (src/endf/records.py), the inner loop reads successive matrix elements across a row but assigns all of them to the same column jj, instead of advancing to jj + j.

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

for j in range(nrow):
    if jj+j >= ii:
        break
    element = int_endf(line[11+(ndigit+1)*j:11+(ndigit+1)*(j+1)])
    if element > 0:
        corr[ii, jj] = (element+0.5)/factor    # <-- jj, not jj + j
    elif element < 0:
        corr[ii, jj] = (element-0.5)/factor    # <-- same

The field offset 11+(ndigit+1)*j advances with j, and the loop guard is if jj+j >= ii: break — both of which say the column being filled is jj + j. Only the assignment does not follow.

Effect

For an INTG line covering more than one column, every element is written on top of the previous one at column jj. The result is that:

• only the last in-range element of each line survives, and it lands in the wrong column;
• every other column the line was meant to fill stays at its initialised value (0, or 1 on the diagonal).

The correlation matrix returned for LCOMP=2 compact covariances is therefore wrong wherever a line carries more than one element. Since the guard jj+j >= ii stops at the diagonal, single-element lines (jj == ii-1) happen to come out right, which is probably why this has gone unnoticed.

Suggested fix

        if element > 0:
            corr[ii, jj+j] = (element+0.5)/factor
        elif element < 0:
            corr[ii, jj+j] = (element-0.5)/factor

Notes

• get_intg_record currently has no caller in the package — MF32 (LCOMP=2) is not parsed yet — so this is latent rather than user-visible today.
• The symmetrisation at the end is fine: np.diag(corr.diagonal()) is evaluated against the pre-addition matrix, so the diagonal correctly stays at 1.
• Found while porting the reader to Rust. The port reproduces the current behaviour deliberately, with a comment pointing here, so the two agree until this is settled.

[shimwell]

Cross-checked against other readers: confirmed, and there are two more bugs in the same function

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

1. The reported bug — confirmed

ENDFtk advances the column with the index, readMatrixElements.hpp:

for ( unsigned int index = 0; index < record.K().size(); ++index ) {
  long value = record.K()[index];
  if ( value != 0 ) {
    is.emplace_back( record.I() );
    js.emplace_back( record.J() + index );   // <- column advances

Here every element of the row goes to corr[ii, jj], so only the last one written survives. Real bug.

2. NROW_RULES[3] should be 13, not 12

ENDFtk uses IntegerBase<3, 13> for NDIGIT=3. Its print.hpp gives the full layout — I(5), J(5), one space unless NDIGIT=6, then N fields of width NDIGIT+1, then padding of 1/3/0/1/0 columns for NDIGIT 2/3/4/5/6. Every combination sums to exactly 66:

NDIGIT	N	5+5+space	N×(NDIGIT+1)	pad	total
2	18	11	54	1	66
3	13	11	52	3	66
4	11	11	55	0	66
5	9	11	54	1	66
6	8	10	56	0	66

With 3: 12 a full NDIGIT=3 row silently loses its thirteenth entry.

3. NDIGIT=6 has no leading space, so the offset is 10 and not 11

Both references agree, and this one is independent of ENDFtk's table. endf-parserpy:

range_iter = range(11, 65, ndigit + 1) if ndigit <= 5 else range(10, 65, ndigit + 1)

get_intg_record always uses 11+(ndigit+1)*j. For NDIGIT=6 that reads every field one column late, and the last one runs to column 67 — past the end of the data and into MAT. So NDIGIT=6 rows are misread entirely rather than slightly.

_{endf-parserpy's range(11, 65, 4) yields 14 starts for NDIGIT=3, which overruns the other way; on that one point ENDFtk's 13 is the value consistent with a 66-column record, and I would take ENDFtk as the reference.}

Provenance, and why this matters more than it looks

This predates the port: OpenMC's own implementation, before it switched to depending on this package (8053111~1, openmc/data/endf.py), is byte-identical including corr[ii, jj] and NROW_RULES = {2: 18, 3: 12, ...}.

But OpenMC now imports this function from here — openmc/data/endf.py has from endf.records import (..., get_intg_record) and pyproject.toml lists endf as a dependency. So all three bugs are currently live in OpenMC's resonance covariance reading (resonance_covariance.py calls it in two places), and fixing them here fixes them there.

---

Generated by Claude Code