Adding isomeric branching to chain

[shimwell]

Description

Opening this PR to open the public discussions on adding isomeric branching ratios to openmc. working towards closing #2757

The two changes this PR makes are

• Chain.from_endf() now reads MF=9/MF=10 activation product data from ENDF neutron sub-library files to resolve isomeric reaction products and their energy-dependent yields
• Chain XML format gains a new <isomeric_branching> element that stores per-reaction energy grids and yield arrays for each product state (ground, metastable)

I think this won't interfere with the existing depletion and follow up PRs will be needed to make use of this data. For example we would need to change form_matrix, IndependentOperator.

But it would be interesting to know if this method is acceptable before moving forwards

1. is the format of the new isomeric_branching xml tag acceptable?
2. is the method of extracting isomeric branching data from the nuclear data acceptable? @paulromano

Also keen to hear from @yrrepy @jbae11 @eepeterson @jckica who have all done work on this as well

Checklist

• I have performed a self-review of my own code
• I have followed the style guidelines for Python source files (if applicable)
• I have made corresponding changes to the documentation (if applicable)
• I have added tests that prove my fix is effective or that my feature works (if applicable)

[yrrepy]

I have just upgraded my build, and the branching ratios are no longer on the chain. They are auto-fetched at runtime.
What is critical on the chain is the targets (iso products) and a flag alerting to iso BR.
I'll shortly provide an example chain.

With iso BR on the chain, the chain blows up from 20MB to 100MB (CCFE-709/UKAEA-1102 structure).
Which makes the chain file an awkward size.

Furthermore, currently the chain gets distributed to each worker node during deplete, I have upgraded my workflow and can now run 200 MPI ranks. If this chain gets distributed that's 80MB*200MPI=16GB RAM, not huge, but could either eat into max # ranks or max # materials being depleted.

Separately, I think different ENDF libraries/evaluation have inconsistent ways of storing isomeric targets on MF. Which is why the GENDF is such a solution

[shimwell]

On the file size topic would moving from xml to hdf5 help #3882

[AARyzhkov]

I am very interested in this PR. I have been lucky to work with activation data for transuranic fuel while having issues with U232, and this PR will allow avoiding them in future. The issues were strongly connected with BRs, and consequently, it was necessary to prepare them. This is where I have encountered LFS with NJOY requiring providing it instead of a state number

Having that in mind, I have noticed Am242_m2 in tests instead of Am242_m1, as the former does not conventionally participate in a neutron transport simulation. The issue is that an LFS number in MF9/10 relates to the level, not the isomeric state, and the link between these is defined via MF8, where the states are stored (as subtly mentioned in the ENDF docs). Besides, the second check can be done by comparing the excitation energy of Am242_m1 (4.8630E+04 eV), which is provided in the ENDF file for LFS=2. The third check is possible by comparing the half-life, which also corresponds to Am242_m1. These examples show that Am242_m2 is actually Am241_m1 here. This aspect has to be accounted for an arbitrary nuclide, not only Am241(n,g)

So far, I think this can be circumvented by simply numbering the isomeric states while iterating over n_states with corresponding changes in the PR instead of taking LFS values directly

[yrrepy]

On the file size topic would moving from xml to hdf5 help #3882
yes, quite likely

Attached is what my latest chain looks like with and without the ratios
Chain_JEFF40-Iso.zip

The following commit enabled direct access to the GENDF file's iso BR at runtime.
9dc8cd3