AngleDistribution.forward_fraction returns uninitialized memory for ACE-derived distributions, so removal_xs is nondeterministic there

[shimwell]

AngleDistribution.forward_fraction allocates its result with np.empty and then fills only the entries whose distribution is a Legendre or a Tabulated1D:

fractions = np.empty(len(self.energy))

for i, mu_i in enumerate(self.mu):
    if isinstance(mu_i, Legendre):
        ...
    elif isinstance(mu_i, Tabulated1D):
        ...

return fractions

An AngleDistribution built by AngleDistribution.from_ace contains neither type. Its entries are Tabular (for a tabulated cosine distribution or the 32 equiprobable bins) and Uniform (for isotropic), so every entry falls through both branches and is returned as whatever np.empty happened to hand back.

That propagates: IncidentNeutron.removal_xs calls forward_fraction on the elastic angular distribution, so for any nuclide read from an ACE table it returns garbage — and garbage that changes between calls, because the value depends on what was last in that block of memory:

>>> import endf, endf.ace
>>> t = endf.ace.get_tables('tests/Li6.ace')[0]
>>> n = endf.IncidentNeutron.from_ace(t)
>>> n.removal_xs('294K', 0.0).y[0]
np.float64(10.40895)
>>> for cutoff in (-1.0, 0.0, 0.5):
...     print(cutoff, n.removal_xs('294K', cutoff).y[0])
-1.0 10.40895
0.0 -97.93729010250001
0.5 -97.93729010250001

The same call gives a different answer depending on what ran before it. The first line is the total cross section unchanged, i.e. a forward fraction that happened to be zero; the others are negative removal cross sections, which is not a physical answer.

The ENDF path is unaffected — AngleDistribution.from_dict produces Legendre and Tabulated1D — which is presumably why the tests in tests/test_removal_xs.py (all ENDF) pass.

Two things would fix it:

1. fractions = np.zeros(len(self.energy)) instead of np.empty, so an unhandled type is at least deterministic.
2. Handle the two ACE shapes, which both have a well-defined answer. For a Tabular, the forward fraction is 1 - C(mu_cutoff) where C is the CDF the class already computes; for a Uniform over [a, b] it is (b - max(a, mu_cutoff)) / (b - a), clamped to [0, 1].

With (2), removal_xs becomes meaningful for ACE data rather than merely deterministic.

Found while porting the reader to Rust: there is no behaviour to reproduce here, so the Rust forward_fraction implements (2), and its removal cross section is compared against the Python one only on the ENDF path, where the Python answer is well-defined.

[shimwell]

Cross-checked against other readers: no equivalent exists elsewhere

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

Nothing to compare against. forward_fraction and removal_xs are original to this package:

• OpenMC has neither — grepping openmc/ for both names returns nothing.
• ENDFtk and endf-parserpy are format readers. Neither derives quantities from an angular distribution, so neither has an opinion.

So unlike the other issues I raised, this one cannot be settled by asking what another reader does. It has to stand on the code, and it does:

fractions = np.empty(len(self.energy))

for i, mu_i in enumerate(self.mu):
    if isinstance(mu_i, Legendre):
        ...
        fractions[i] = ...
    elif isinstance(mu_i, Tabulated1D):
        ...
        fractions[i] = ...
# no else

np.empty does not initialise. Any mu_i that is neither a Legendre nor a Tabulated1D leaves fractions[i] holding whatever was in that memory, so the result depends on what the allocator handed back — which is why the same removal_xs call can give different answers in the same process depending on what ran before it.

For ENDF-derived distributions every entry is one of the two types and the array is fully written, which is why this only shows on ACE data.

Verdict: real bug, and a np.zeros would not fix it — a zero forward fraction is a physical claim, and the wrong one. The defensible options are to handle the remaining shapes, or to raise on one that is not handled, rather than to return a number that was never computed.

For the record, the Rust port computes the fraction properly for the ACE shapes instead of reproducing this, since there is no behaviour here worth matching; the golden harness therefore skips removal_xs on the ACE path, and that exclusion is commented with this issue number in tools/dump_golden.py.

---

Generated by Claude Code

[shimwell]

A Rust port of this reader computes these rather than leaving them uninitialised, if that is useful as a reference for a fix.

AngleDistribution::forward_fraction handles every shape including the two an ACE table produces (Tabular and Isotropic), so there is no np.empty path left to return whatever was in memory. The Python behaviour for ACE data is not merely different from the Legendre case, it changes between calls, so there was nothing to match and the port computes the integral instead.

Source: crates/endf/src/mf/mf4.rs, pub fn forward_fraction. The golden-comparison harness skips this one function against the Python reader for exactly this reason.