Bug fix: calculating thermal elastic scattering cross section
Created by: paulromano
I'm working on a large refactor of our thermal scattering data/classes (see #1233) which is 99% done. Before I submit a PR for it, I wanted to show that the changes I was making don't change test results. This has been true other than a few exceptions:
- During the refactor, I discovered a bug in how we calculate the thermal elastic scattering cross section. Right now, our
ThermalScatteringclass stores two "thresholds", one for inelastic and one for elastic. These are really maximum energies, not thresholds. The inelastic threshold always corresponds to the upper energy that the S(a,b) treatment should be used. The elastic threshold corresponds to the last energy listed for Bragg edges / a tabulated cross section. Right now, if the particle energy is above the elastic threshold but below the inelastic threshold, the elastic cross section is taken to be zero. This is not actually correct. In the case of coherent elastic scattering, being above the last Bragg edge does not imply that the cross section is zero. Fixing this changed any tests that use materials having a thermal scattering table with elastic data (lattice_hex_coincident, triso, salphabeta, void).
- There is a change in two tests that are sensitive to order of operations (asymmetric_lattice, cmfd_feed_2g) because of the way that we interpolate cross sections between two points. For thermal elastic and inelastic scattering, right now we use
(1 - f) xs[i] + f*xs[i+1]. After the refactor, this will become
xs[i] + f*(xs[i+1] - xs[i])(because it relies on the
This PR isolates these two changes before making the big refactor. I've also made some updates in setup.py and MANIFEST.in.
Also, I noticed a typo on a constant for the default Watt spectrum in settings.cpp that is now fixed.