Implement support for continuous S(a,b) data tables
Created by: nelsonag
This PR addresses the issue identified in issue #211 (closed), and thus provides OpenMC with the ability to read thermal scattering tables processed with the iwt=2 option in NJOY. These tables include a continuous secondary energy distribution for inelastic S(a,b) scatters as are provided in the MCNP6 release as the .2_t tables (i.e., lwtr.20t). Data using the discrete secondary energies (which OpenMC already supports) are provided (as was the case for MCNP5 as well) as .1_t tables (i.e., lwtr.10t).
Before this Pull Request can be considered complete, the following tasks must be performed:
Identify format used for the new S(a,b) data
- The ACE Format Guide has not been updated to incorporate the format of this data
- Instead, private communication with Andrew Pavlou (who has authored a paper [PHYSOR 2012] regarding the accuracy of the new format when using MCNP6) revealed that the data should be in a tabular Ein, Eout, mu format, similar to Law 61
- This information was enough for me to reverse-engineer the format for the data (will discuss details in a comment when I have some more time)
Implement reading of that format in to OpenMC
- Since the format was quite different than either an EnergyDist or the information currently stored in the SAlphaBeta class, I had to create a new class just for this information. SAlphaBeta contains an allocatable list of these objects, which take up minimal space if the continuous data is not a .2*t table
Modify physics.F90 to utilize the new data
- This shouldn't be too difficult, as the format is like Law 61 for secondary energies, and like the discrete inelastic S(a,b) collision physics for the choice of angle
- A spot of difficulty is what type of interpolation is assumed for Eout. I will begin by assuming linear interpolation vice histogram, but the format I deciphered doesn't have an INTT-like variable to denote one or the other. This will probably require experimentation.
Sufficiently test the new implementation to ensure the data format was properly reverse-engineered
- This will probably include running problems similar to those done in Pavlou's paper and observing similar eigenvalue changes
- The above still isn't going to be the greatest gauge, since his reported eigenvalue differences are ~0.0004.