Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix for non-zero CDF start points in incoherent inelastic data #2290

Merged
merged 3 commits into from
Nov 10, 2022

Conversation

HunterBelanger
Copy link
Contributor

TSLs which are processed with either NJOY or FRENDY (I don't know about other codes) have the odd peculiarity that for incoherent inelastic scattering, the CDF for the outgoing energy always starts at a value greater than zero (regardless of the incident energy in question). When sampling the outgoing energy, if the sampled random value $\xi < \text{CDF}[0] $, then the sampled outgoing energy can actually be negative ( I believe Coline might have mentioned this to you recently @paulromano ).

In PapillonNDL, I chose to handle this problem in the following manner: if the CDF does not start at 0, I then add a new point for outgoing energy = 0 eV, with a PDF of 0, and a CDF of 0. This choice should be correct according to Eq. 7.6 in the ENDF manual, for the double differential xs. While a new energy-PDF point has been added, I don't bother re-normalizing the distribution or re-computing the CDF, because in my experience, the CDF is never normalized to begin with, and this only changes the discrepancy by a factor which is generally much smaller than the current difference one gets when integrating the PDF. A set of discreet, equiprobable angles must also be created for this new outgoing energy of 0. I create a set of isotropically distributed discreet angles, as Eq. 7.6 also seems to imply that in the limit as $E' \rightarrow 0$, $\alpha \rightarrow \frac{E}{A_0kT}$, and the difference between $\alpha_\text{min}$ and $\alpha_\text{max}$ becomes smaller and smaller. When $\alpha_\text{max} - \alpha_\text{min}$ is very small, we can likely approximate $S(\alpha,\beta)$ as being a constant in $\alpha$, hence why I propose the isotropic distribution. It certainly isn't well defined to have a neutron with zero energy, and then to consider the angular distribution, but I think this is reasonable in this case.

In this PR, I have applied the same doctoring to the TSL data that I do in PapillonNDL.

In general, this change to the nuclear data is so small, I have not been able to notice any statistical difference when sampling the distributions (the CDF already starts at a very small value, even if it isn't zero). There is one exception to this however, which is found in the TSL for Mg at 20K from JEFF-3.3, at an incident energy near 1 eV. The two plots bellow compare the sampling from PapillonNDL with OpenMC (original and my proposed data doctoring).

Mg-20K at 1 01eV-energy-orig

Mg-20K at 1 01eV-energy-new

Here, we can see that applying this doctoring to the data leads to a very large difference in the outgoing energy distribution (this is also the case for the angular distribution as well, though I have not posted it here). Looking at the OpenMC results for the top image, we see a large peak which appears in the PDF at low outgoing energies. This is because the PDF in the tabulated data near 1eV appears to be increase when considering lower and lower outgoing energies. When this at point at outgoing energy 0 is added, with PDF and CDF of 0, this then "flattens" the triangle, and changes the lower end of the distribution drastically. The fact that the PDF is increasing as the outgoing energy decreases is not physically correct though (confirmed with the evaluator for the evaluation), and it appears to be a problem with how NJOY and FRENDY are processing the data. Since the TSL for Mg at 20K in it's original form is already un-physical, I do not see this effective change in the "un-physicalness" to be an issue myself; the same portion of particles end up with un-physical energies in the tail, it is just the shape of this un-physical tail which changes.

Apart from this odd case with Mg, I have yet to observe any statistically significant changes in other evaluations, and this change helps ensure that negative energies cannot occur. It is very rare that this occurs however, as the CDF does usually start at a very small value, so there is a very low probability of sampling in that vicinity.

Copy link
Contributor

@paulromano paulromano left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this proposed fix @HunterBelanger! Coline did mention this issue (as well as others) so it doesn't come as a surprise. Your fudging of the data here seems reasonable and, as you pointed out, won't affect most evaluations in practice.

I just have a few small wording suggestions but otherwise I think this is good to merge. Would you like me to regenerate the Mg TSL data that is part of our JEFF-3.3 library once this is in?

Comment on lines +673 to +674
# The equiprobable angles produced by NJOY are not always
# sorted. This is problematic when the smearing algorithm
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I never realized this! Do you have an example of a particular library/nuclide/reaction/distribution for which this happens?

Copy link
Contributor Author

@HunterBelanger HunterBelanger Nov 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this is actually a common occurrence as well (though not systematically the case as with the CDFs). In ENFB/B-VIII.0, I have seen warnings from PapillonNDL about this for important evaluations like H-H2O (all temperatures), D-D2O (all temperatures), O-D2O (all temperatures), and several other materials as well. I don't think it happens for every single incident/outgoing energy pair, but it certainly happens at least once in each of those evaluations. PapillonNDL stops reading the ACE file after the first error, so its hard for me to say with certainty how prevalent it is. When bench marking PapillonNDL, I don't believe I ever noticed a statistical difference with OpenMC due to my sorting of the angles, but this is still less than ideal, as smearing assumes that they are sorted. If you want, I have programs which directly sample the distributions, either from PapillonNDL or OpenMC, and then a script which gets the p-value of the energy and angle distributions to compare.

Another issue I noticed with the ENDF/B-VII.1 ACE files is that the scattering angles where sometimes larger than 1, or less than -1 (this happens in the ligher water TSL for sure). This was a bug in not-so-old versions of NJOY, but has since been fixed. I added a check for this to PapillonNDL, and because of that, I simply can't use the older ENDF/B-VII.0 ACE files that were distributed with MCNP for example. Currently, I don't see a check for this in the OpenMC processing. There isn't really a good solution for this problem, other than re-processing the evaluation with the newer version of NJOY. Do you want me to add a check for this @paulromano ? It might cause people problems if they want to generate HDF5 files from these older ACE files, but maybe this is better than letting them use physically invalid data ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I should specify, when I mention ENDF/B-VIII.0 here, these are the ACE files made from lib80x, distributed by LANL.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Re: the check for values outside of [-1,1], perhaps the best thing to do would be to add a warning so that at least we're letting the user know they may be dealing with bad data. That doesn't necessarily need to be done as part of this PR though.

openmc/data/thermal.py Outdated Show resolved Hide resolved
openmc/data/thermal.py Outdated Show resolved Hide resolved
@HunterBelanger
Copy link
Contributor Author

As to regenerating the Mg TSL in JEFF-3.3, I'm not sure it's necessary. Whether my fix is used or not, the data is still physically inaccurate. I'm not sure there if there is an argument to be made as to which physically inaccurate description is "better". People might find the unsorted angles of more concern, but I am not sure it is worth re-processing all of the TSLs for all of the libraries, given I have yet to notice a statistically significant change in the sampling.

Copy link
Contributor

@paulromano paulromano left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks again for the fix! Feel free to submit another PR adding a warning for the mu outside of [-1,1] issue if you'd like.

@paulromano paulromano merged commit 2ed86f5 into openmc-dev:develop Nov 10, 2022
@HunterBelanger HunterBelanger deleted the fix_tsl_data branch November 10, 2022 17:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants