Fix bug in PURR related to heating values #18
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request fixes a subtle bug in
purr
when generating heating values in the probability table whenihave=2
. If a user asks for partial heating values for MT=302 and MT=402 but not MT=318 (which seems reasonable if the isotope in question is not fissionable), this results inihave=2
.purr
will then try to use the partial heating values to account for fluctuations in the heating values when generating ptables. However, inrdheat
, the fact that MT=318 is missing means that the heating values for it are never set. Furthermore, theheat
array that is used inpurr
is never initialized, so the uninitialized values are then used at the end ofpurr
when calculating heating values. Namely,heat(3,ie,it)
will be uninitialized and may possibly be NaN which eventually causes a floating point exception somewhere down the line. For me, this always seemed to happen here.So far in my testing, this seems to have resolved the random NaNs causing problems for me when building with gfortran (as described in #16). However, I don't know if it will do the same for @brown170.
Semi-related question -- I see that the CMake file for NJOY now (supposedly) requires gfortran 5.1+. Is there a particular reason for this? I say supposedly because it doesn't appear that
CMAKE_Fortran_COMPILER_VERSION
actually gets set (at least on my machine). I have similar logic in the CMakeLists.txt file for OpenMC that relies on execute_process instead.