Building in PREPRO-processed activation data (as formatted for FISPACT-II) - #314
Building in PREPRO-processed activation data (as formatted for FISPACT-II)#314eitan-weinstein wants to merge 2 commits into
Conversation
|
Something interesting that I am coming across following my updates in #317 and producing comparative cross-section plots between FISPACT-II PREPRO data and ALARAJOY data is a significant mismatch in cross-section positioning for almost all reactions, with the exception of (n,γ) and (n,p) (at least within the limited scope of 54Fe that I've checked thus far today). For example, there is very clear alignment in the (n,γ) case, with some small discrepancies in the upper resonance range, but not terribly concerning:
On the other hand, all other reactions for 54Fe show what appears to be a misalignment that would be resultant from the order reversal of the PREPRO energy groups (rather than cross-sections):
At face value, it's hard to decipher the meaning of this. In the current ALARAJOY methodology, cross-section arrays are reversed before they are saved to the output DSV because the order of energy groups in TENDL is opposite to ALARA's expected ordering. If, across the board (including (n,γ), (n,p)), signs of a falsely applied double-reversal were the case, then we'd have a sign that PREPRO-output GENDF files follow the same group structure ordering as we need in ALARA. Given that that's not the case, however, I'm left wondering whether the energy group ordering is inconsistent across PREPRO output data or some other fundamental processing issue in the PREPRO workflow (which I find unlikely) or there is some other hidden bug that may explain how we're getting structurally different results across all reaction types except MT = 102. Having just discovered this, I will continue digging around and seeing if I can better identify the source of this discrepancy. |


Closes #311.
This PR introduces the capability for
tendl_processing.pyto parse groupwise nuclear data produced by PREPRO (via itsGROUPIEmodule) and incorporate it into the ALARAJOY workflow. This is motivated by the desire to compare input groupwise cross-section data between ALARA and FISPACT-II prior to any activation simulations. Unlike the ALARAJOY workflow, which allows users to create their own ALARA binary libraries from TENDL data, FISPACT-II's nuclear data is distributed in it's preprocessed, ready-to-go format through FISPACT-II's NEA GitLab nuclear data repository.There are two main formatting differences between NJOY/GROUPR-produced GENDF files and those produced by PREPRO/GROUPIE:
GROUPR-formatted GENDF files will only contain MF3. To produce excitation pathway-specific cross-sections, MF9/10 data can be highlighted during input (see Handling isomers produced beyond (n,n*) reactions #229), but will ultimately be written out in a subsection format within MF3 to the final GENDF output.GROUPIE, on the other hand, preserves MF10 in its GENDF formatting, meaning MF3 will not contain any subsections, just the cumulative reaction cross sections for all pathways (if multiple exist). MF10 contains the pathway data itself.GROUPRandGROUPIE, requiring different parsing approaches.To accommodate these differences, I restructured the main data structure in which to store parsed GENDF data to now being a dictionary keyed by
MFand valued by a sub-dictionary with keys'MTs'and 'non_zero_xs'(adapting the nomenclature from my original architecture). The definition of this dictionary is as such:The special case of
MF == 10fornon_zero_xsallows for the GROUPIE MF10 subsections to be stored with each LFS as the key to a similar list-of-dictionary structure that would otherwise appear at that same level for the standard MF3 case.The biggest actual changes that I've made in the code itself, however, is in the creation of a new class
GENDFParserthat stores all of these internal methods relating to the different possibilities for GENDF parsing. As I was building this, I was considering that because there were so many free-floating functions withintendl_processing.pythat only pertained to use withinextract_gendf_data(), that it would be most appropriate to organize these all within a class. I know that we had discussed that in general, that it would probably not be worth the time/effort to restructure all of ALARAJOYWrapper to an object-oriented architecture, however, in this limited case, it seemed appropriate to me to conceptually distinguish all of the parsing-specific functions from the rest of thetendl_processingmodule. With all of that said, I recognize that it makes the size of this PR rather large, at least as far as number of lines of code changed is concerned. If you think it would be preferable @gonuke to make a separate preceding PR that just builds out the already existing GENDF parsing functionality to aGENDFParserclass, without theGROUPIEcapabilities, I could do work backwards to do so.