Refactor depletion chain data

[paulromano]

This pull request makes some major changes to the DepletionChain class and modest changes to Nuclide. I've combined the data from the Yield class into the Nuclide class (as part of the yield_data and yield_energies attribute). Thus, now the decay, reaction Q values, and yield data appears together in the same class. Together with this, the format of the chain.xml file has also changed:

• <nuclide_table> can now have a decay_energy attribute
• <reaction_type> can now have a Q attribute
• Recoverable fission energy is stored as the Q value for fission.
• The type attribute of <decay_type> is used correctly now instead of being "?" everywhere. Additionally,multiple decays (e.g., beta-, n, n) are handled correctly.
• Decays to metastable states are handled correctly.
• <neutron_fission_yields> are now directly embedded in <nuclide_table>. The hierarchy has also changed to better reflect how the data is actually stored in ENDF files. Namely, I allow the number of energies at which yields are tabulated and the list of products to vary by parent. As an example, here's what U235 looks like

  <neutron_fission_yields>
  <energies>0.0253 500000.0 14000000.0</energies>
  <fission_yields energy="0.0253">
  <products>Cr66 Cr67 ...</products>
  <data>2.4098305e-14 0.0 ...</data>
  </fission_yield>
  <fission_yields energy="500000.0">
  ...
  </fission_yields>
  ...
  </neutron_fission_yields>

There is now a make_depletion_chain function that will create a chain file given a list of ENDF decay files, FPY files, and incident neutron files (used to get reaction Q values). When I create a chain file from ENDF/B-VII.1 data, there are a few data issues that should be noted:

• Several decay modes have daughter nuclides with no data, e.g. Ni48 beta+ -> Co48, and Co48 doesn't exist. The only other nuclides with this issue are very heavy (Cf, Bk, Es). The replace_missing function in depletion_chain.py handles this gracefully by assuming that the daughter nuclides decay until a stable product is reached. Some heuristics are used to assume whether the missing daughter has a beta-, beta+, or alpha decay.
• Some fission products don't exist in the decay library. My approach is to first check if the ground state exists and use that if present. Otherwise, just assume successive beta- decays until you get to a nuclide that exists in the decay library. It appears this happens with nuclides that account for about 0.5% of the total yield.
• A bunch of nuclides with fission, e.g. Ra223, don't have known fission product yields. For now, we just assume they don't fission (a better assumption might be to just assume the FPY distribution of another nuclide, maybe U235?)
• Some nuclides in the decay sublibrary are listed as unstable with a half-life of 0.0 seconds. These nuclides appear to be ones that have extremely long half-lives (i.e., they are naturally occurring with a specified abundance), so we can just treat them as stable.

The full test suite passes for me. I need to do some more testing with a full chain file generated from ENDF/B-VII.1 data, but thought I'd submit this PR so that you can start reviewing.

[cjosey]

This is becoming a more complicated review than I anticipated. I'll have it done in an hour or two.

[paulromano]

I've confirmed that this capability works with JEFF data (decay/FPY library from JEFF 3.1.1, neutron library from JEFF 3.2). There are a few neutron files that are badly formatted (e.g., Gd-152 is ISO-8859-1 encoded which is against ENDF rules) but once they are fixed everything runs fine. There are actually fewer errors reported (no fission products that don't have decay data, no missing reaction products).

[cjosey]

So, last few notes, as this is close to merging.

1. It is probably safe to remove ``chain_full.xml'' as it is formally obsolete.
2. I am getting subtle numerical differences (17th digit sort of things) between my chain and the LFS one. This really doesn't matter and probably doesn't need to be fixed. As long as a user uses the same chain, then RNG sequences will be fine.
3. The new download script is super nice.
4. import sys in depletion_chain.py isn't needed.

[paulromano]

Thanks for pointing me to tqdm by the way, I love it. I'll get rid of the old full chain file. Do you want me to add in a chain file for JEFF too?

[cjosey]

I'm not sure on JEFF. See, I don't know if it would ever be used before the chains are modified again for capture branching ratios. I'll leave that choice up to you.

Also, before I forget again, I did email Kord asking about how he would handle the missing yield data.

I guess I would use yield data for the closest isotope A number and scale to conserve mass.

Ugly call!

I am fine leaving it as is for now, as I would really rather do some research on the topic to see what is done elsewhere.

[paulromano]

Good point, let's wait for branching ratios (I'll start cogitating on that one).

[paulromano]

@cjosey I believe that I've addressed all your actionable comments. Let me know if I'm still missing something.

[cjosey]

It all appears good. In fact, I was making one last check to ensure the yields were right and discovered that the old decay chain was much worse than it should've been. For example Xe135's U235 yield was the total yield (stable + metastable). So, I guess we can count this as a bugfix release.