Extension of the framework nuclides

[jakehader]

Description

Update to the nuclides that are built into the ARMI framework. This expands the set of nuclide bases to include 4614 nuclides and imports the half-life data from the chart of the nuclides from a combination of the RIPL-3 database and from the IAEA chart of the nuclides.

Other Changes:

• Each Element now has a phase and a group.
• Element.nuclideBases becomes Element.nuclides - This is an API-breaking change.

---

Checklist

• This PR has only one purpose or idea.
• Tests have been added/updated to verify that the new/changed code works.

• The code style follows good practices.
• The commit message(s) follow good practices.

• The release notes (location doc/release/0.X.rst) are up-to-date with any bug fixes or new features.
• The documentation is still up-to-date in the doc folder.
• The dependencies are still up-to-date in setup.py.

[jakehader]

This will take some time to review, but please see the attached ipython notebook that can be used to check the data that is being proposed in this PR against the IAEA Chart of the Nuclides - https://www-nds.iaea.org/relnsd/vcharthtml/VChartHTML.html

Note that GitHub doesn't allow file uploads of .ipynb so the extension is changed to .txt.

iaea-check.txt

[jakehader]

@john-science - I am not sure why the tests didn't run. Is this something that has been failing? Unit tests pass locally for me.

[jakehader]

Here is complete comparison of the results between what is being proposed in the framework compared to three different sources. In general there is good agreement, and the major differences are in very short half-lives. The abundance differences are within the ranges of uncertainties reported and should be reasonable. All natural abundances sum to 1.0 within 4 decimal places and there is a unit test that demonstrates this.

mass-comparisons.txt
nusf-comparisons.txt
abundance-comparisons.txt
halflife-comparisons.txt

[john-science]

@jakehader Assuming we get the unit tests working and all that...

Do you think this will require any breaking to our downstream projects?

NOTE: @opotowsky @sombrereau @drewj-usnctech

[john-science]

@jakehader @ntouran How much do we expect this to slow down ARMI? This is a lot more nuclides.

[opotowsky]

@john-science - I am not sure why the tests didn't run. Is this something that has been failing? Unit tests pass locally for me.

  File "/home/runner/work/armi/armi/armi/physics/neutronics/fissionProductModel/lumpedFissionProduct.py", line 506, in createLFPsFromFile
    lfp = self._readOneLFP(lfpLines)
  File "/home/runner/work/armi/armi/armi/physics/neutronics/fissionProductModel/lumpedFissionProduct.py", line 576, in _readOneLFP
    nuc = nuclideBases.byMccId[nucLibId]
KeyError: 'GE73 5'

Once this is handled I can run some tests downstream. They also fail on the above unit test failure

[drewj-usnctech]

Thanks for the ping. No problems on our end

[jakehader]

@jakehader @ntouran How much do we expect this to slow down ARMI? This is a lot more nuclides.

It's actually faster to initialize than dynamically loading the RIPL-3 data from it's files that we currently suggest in the manual/docs.

The key thing here is that the set of active nuclides (i.e., the ones model within the blocks, components, etc. during a run) are set up with the blueprint nuclide flags. This in principle there will be no significant downstream impacts. The half life data is being adjusted so that might twiddle some depletion results but nothing major.

[jakehader]

@john-science - I am not sure why the tests didn't run. Is this something that has been failing? Unit tests pass locally for me.

  File "/home/runner/work/armi/armi/armi/physics/neutronics/fissionProductModel/lumpedFissionProduct.py", line 506, in createLFPsFromFile
    lfp = self._readOneLFP(lfpLines)
  File "/home/runner/work/armi/armi/armi/physics/neutronics/fissionProductModel/lumpedFissionProduct.py", line 576, in _readOneLFP
    nuc = nuclideBases.byMccId[nucLibId]
KeyError: 'GE73 5'

Once this is handled I can run some tests downstream. They also fail on the above unit test failure

I should convert to a draft because I'm still working. Should be available soon for more testing. Also, don't worry about doing the integration and unit testing internal for this @opotowsky - I will do so and open other PRs.

[jakehader]

Thanks for the ping. No problems on our end

Any recommendations or other needs coming from this? I'm not sure if you're still using Serpent @drewj-usnctech, but maybe a run down on if the nuclide bases work for getting Serpent IDs correctly would be nice. I am not sure if it's the same between ENDF/B-VII.0, ENDF/B-VII.1, and ENDF/B-VIII.0. Is there any good resource for this?

[drewj-usnctech]

Thanks for the ping. No problems on our end

Any recommendations or other needs coming from this? I'm not sure if you're still using Serpent @drewj-usnctech, but maybe a run down on if the nuclide bases work for getting Serpent IDs correctly would be nice. I am not sure if it's the same between ENDF/B-VII.0, ENDF/B-VII.1, and ENDF/B-VIII.0. Is there any good resource for this?

Except for some rare exceptions, Serpent and MCNP ids align very well. We haven't hit major stumbling blocks

[jakehader]

Thanks for the ping. No problems on our end

Any recommendations or other needs coming from this? I'm not sure if you're still using Serpent @drewj-usnctech, but maybe a run down on if the nuclide bases work for getting Serpent IDs correctly would be nice. I am not sure if it's the same between ENDF/B-VII.0, ENDF/B-VII.1, and ENDF/B-VIII.0. Is there any good resource for this?

Except for some rare exceptions, Serpent and MCNP ids align very well. We haven't hit major stumbling blocks

Thank you. So the way I read this is that you do not use nuclideBase.getSerpentId()? Would you care if we removed this?

[drewj-usnctech]

So the way I read this is that you do not use nuclideBase.getSerpentId()? Would you care if we removed this?

Sorry that was not the intent I meant to express. We do use nuclideBase.getSerpentId to get the more human readable nuclide names (Al-27) vs. the more traditional ZZAAA form (13026)

To the point of

I am not sure if it's the same between ENDF/B-VII.0, ENDF/B-VII.1, and ENDF/B-VIII.0

I'm pretty sure the only thing that changes from evaluation to evaluation is the library suffix, not so much the nuclide naming structure. So you might see 13026.03c in one eval, but 13026.08c later, both at the same temperature. I might be missing something in my interpretation of your comment though

[jakehader]

So the way I read this is that you do not use nuclideBase.getSerpentId()? Would you care if we removed this?

Sorry that was not the intent I meant to express. We do use nuclideBase.getSerpentId to get the more human readable nuclide names (Al-27) vs. the more traditional ZZAAA form (13026)

To the point of

I am not sure if it's the same between ENDF/B-VII.0, ENDF/B-VII.1, and ENDF/B-VIII.0

I'm pretty sure the only thing that changes from evaluation to evaluation is the library suffix, not so much the nuclide naming structure. So you might see 13026.03c in one eval, but 13026.08c later, both at the same temperature. I might be missing something in my interpretation of your comment though

Okay thank you for that. Don't want to mess things up for you so I will definitely keep this!

[keckler]

This is only a partial review. Just hitting the low-hanging fruit.

I have NOT yet reviewed nuclideBases.py

[keckler]

I think this docstring needs to be updated:

[jakehader]

Thanks @keckler! Looking at the comments now to address

[keckler]

I can also confirm that all of the half-life data for ground state isotopes compares well against the IAEA data that was referenced above. In this case, "well" means that none of the half-lives are more than 1e-8% different than each other, with the exception of N11, which has 2 half-lives produced by the IAEA's API. One of those values agrees very well, and the other is off by >200%. However, that isotope has a half-life down near 1e-22 seconds.

Still working on verifying the following:

• Half-lives of excited states
• Mass
• Abundance
• Spontaneous fission yields

I will get to these tomorrow.

[keckler]

Thanks for making those changes, and thanks for all your hard work on this huge effort!

[john-science]

NOTE: This line is added as an unrelated bug fix, to a line added here.

[jakehader]

Good call out. This line was updated because some of our internal tools/plugins still need files to hang around in the working directory (i.e., cross sections) due to this data not being stored on the parameter system. This is a legacy functionality that wasn't retested completely in #952. This brings it back to default to storing data files in the working directory if savePhysicsFiles is not provided. It would be great to get rid of this completely in the future, but it is a discussion about where does the nuclear data live? I would love it was on the reactor core data model so that we didn't need to carry the database + other files around and it was all self-consistent.