Opening capabilities for UKDD decay library processing

[eitan-weinstein]

Closes #260 (after reopening it too).
)
This PR expands ALARAJOYWrapper's ability to handle decay libraries beyond EAF distributions to UKDD (i.e. decay_2020) decay libraries. This follows the long-standing discussions between @gonuke, @bohmt, and myself and I finally was able to figure out how to get this workable. This will not only allow for better comparisons against FISPACT-II for our forthcoming paper, but will also allow for ALARAJOYWrapper to more closely follow the data recommendations in FENDL3.2x, which specify the use of decay_2020 as the preferred decay library.

The key issues with decay_2020 that prevent it from being immediately applicable to ALARAJOY are that it is distributed in files for individual nuclides which need to be compiled (minor) and that many of these files have distinct formatting issues (more major) that prevented them from being readable by EAFLib.C, which should be able to read any properly formatted ENDF/B file. I made use of the NEA tool endf-parserpy and it's custom errors to diagnose the issues with any individual UKDD file, which are patched and then compiled to a single decay library file that is readable by ALARAJOYWrapper and EAFLib.C with only minor changes to the latter.

[eitan-weinstein]

I've moved this PR back to being a draft because I ran into an issue of certain radionuclides being reported as stable in inventories calculated with ALARA binary libraries produced from decay_2020 with these processing methods. Upon further investigation, I found that this issue was coming from two sources:

1. Ground-state radionuclide products of reactions contained in the TENDL data that are not present in the decay library.
2. Nuclides (seemingly only isomers, at least so far) whose half-lives are being correctly parsed by EAFLib.C, but for some reason have malformed data that is leading them to ultimately be written out to the binary library as being stable.

For the first issue, this relates back to the conversations from #204 , but our course of action was predicated on the assumption that we would only have this kind of mismatch for isomeric daughters. Importantly, this issue is not new to the changes introduced here, but I only noticed it now because the number densities of these exotic radionuclides were generally small enough to not make meaningful contributions in the aggregate results and slipped under the radar in the various analyses I've been conducting. However, for the "Activation Handbook" irradiation of tungsten, which is the case that first alerted me to these issues now, there were 4 radionuclides present in the inventory with reported half-lives of -1 (stable) that were simply missing both from the previously used EAF decay library and the current UKDD decay library (¹⁸⁰Tm, ¹⁸²Yb, ¹⁸³Yb, and ¹⁸⁶Lu). While their number densities were relatively small, their inclusion as falsely stable nuclides (surely amongst others as well, though I have not yet compiled a complete list of all of these cases), is obviously untenable and nonphysical. It seems to me that the most physically appropriate solution would have to be discarding the reactions that produce these products entirely in tendl_processing.iterate_MTs() because, unlike the isomer deexcitation method that we apply for the similar case of isomers lacking decay data, we do not have any physically reasonable basis for an assumed near-immediate decay pathway to a determinate nuclide/state. While it would be preferrable not to have to discard any data from the TENDL cross-sections, we may simply be limited by the state of the nuclear data sources themselves. I would certainly be open to further discussion on this matter @gonuke and @bohmt to see if we should handle this type of edge case differently, but for now I'll implement a discarding method for such nuclides to this PR.

For the second issue, I am still working to identify where under-the-hood in ALARA these other half-lives are being either lost or overwritten. I am confident that this is not an issue with ALARA's source code but rather with the UKDD processing introduced in this PR because these nuclides (^177mLu, ^177mHf, ¹⁷⁷ⁿHf, ¹⁷⁸ⁿHf, ¹⁷⁹ⁿHf, ¹⁸²ⁿTa, and ¹⁹¹ⁿIr for the W "Activation Handbook" irradiation) all have the correct half-lives in the old ALARAJOY ALARA binary library that used EAF decay data. I know that EAFLib.C necessitates ENDF/B formatting and my use of endf-parserpy should be ensuring compliance to ENDF formatting standards, but there must be some other factor that this does not cover, so I will continue digging in to resolve this.

[eitan-weinstein]

My suspicion that this second false-stability error source was only present for isomers appears to be correct, with the following being the total list of UKDD-2020 isomers causing this issue, many of whom appeared in the tungsten results:

1. ^53mFe
2. ^98mY
3. ^93mMo
4. ¹⁵²ⁿEu
5. ^154mEu
6. ^177mLu
7. ^177mHf
8. ¹⁷⁷ⁿHf
9. ¹⁷⁸ⁿHf
10. ¹⁷⁹ⁿHf
11. ^190mOs
12. ¹⁹¹ⁿIr
13. ¹⁹²ⁿIr
14. ^185mPt
15. ¹⁹⁶ⁿAu
16. ^198mAu
17. ^206mTl
18. ^202mPb
19. ^204mPb
20. ^212mPo

Tellingly, I was able to identify these nuclides as the culprits as they all have two entries in the ALARA library index, one containing all of the activation reaction pathways and one with the decay pathways, when in reality they should be singular. Between these, the latter listed the correct half-lives, while the former labeled them as stable. Knowing this, I should be able to identify -- and hopefully resolve relatively painlessly -- the source of this duplication within the original UKDD files where their decay data is contained.

[eitan-weinstein]

Interestingly, for all of the above-listed isomers, when convert_lib is run with their individual files from the uncompiled decay_2020/ directory, the ALARA binary index appropriately contains a single section with the correct half-life for the given nuclide, meaning the issue is arising from the compilation itself, rather than the in-situ file reformatting that occurs ahead of the appending step.

[eitan-weinstein]

Ok it looks like I've resolved this isomer issue! In my previous processing before my most recent commit (041d3b5), I had excluded the TEND record from each individual file (except the actual final file) while being appended to the compiled file. My reasoning was in trying to keep with proper ENDF formatting, given that we are making a single large "tape". Nevertheless, after toying with its removal, the transmutation/decay duplication issue disappeared and EAFLib.C looks to be able to appropriately handle this decay data now.

While this outcome is not entirely satisfying because it does not explain why this issue was only popping up for these 20 isomers and no other nuclides, given that the TEND removal was applied uniformly.

Nevertheless, I'm re-opening this PR now and will move forward with the reproduction of my analysis plots for the FNS and "Activation Handbook" studies.

[eitan-weinstein]

As further confirmation of the correctness of these updates, here's the new comparison of nuclide contributions to decay heat for the tungsten irradiation that initially drew my attention to the issues guiding my work for the past few days:

Aside from minute differences in contribution percentages, the responses for ALARA and FISPACT-II for this tungsten irradiation are now nearly identical and the hafnium isomers are behaving appropriately.

[gonuke]

Sorry for the delay in getting to this. A few questions to make this a little cleaner, I hope.

[gonuke]

See above about a new private function for this

[gonuke]

Can't we just avoid introducing this in the first place?

[gonuke]

Found another question about the logic/flow.

[eitan-weinstein]

Now that I'm no longer relying on endf-parserpy for its custom exceptions, my most recent commit detaches these updates from being dependent on it, instead using the ENDFtk-based create_endf_file_obj() function from tendl_processing.py. In order to avoid circular import errors, tendl_processing.create_endf_file_obj() is imported within reaction_data.compile_decaylib().

On top of minimizing dependencies, it seems that extracting the KZA with ENDFtk is much faster than endf-parserpy, which is a nice added benefit.

[gonuke]

A couple of additional comments while you're in the flow...