Skip to content

Distinguish atomic and nuclear masses - #4129

Merged
GuySten merged 5 commits into
openmc-dev:developfrom
paulromano:fix-masses
Sep 13, 2026
Merged

GuySten merged 5 commits into
openmc-dev:developfrom
paulromano:fix-masses

Conversation

@paulromano

Copy link
Copy Markdown
Contributor

Description

While working on a feature, I noticed that there is an inconsistency in our ATOMIC_MASS table in C++. Namely, several light isotopes use named constants like MASS_PROTON, MASS_ALPHA, etc. within the table, but those named constants represent nuclear masses (which exclude the mass of electrons), not atomic masses (which include electron mass). This PR makes the ATOMIC_MASS table consistently contain neutral ground-state atomic masses and adds dedicated helpers for atomic and nuclear mass lookup. ParticleType::mass() continues to provide the bare rest mass needed for particle kinematics, while light nuclei use their CODATA constants and heavier nuclei are derived from the corresponding atomic masses.

Note that existing inverse-velocity and time-cutoff regression tests remain unchanged because the masses of transportable neutrons, photons, electrons, and positrons are unaffected.

Checklist

  • I have performed a self-review of my own code
  • I have run clang-format (version 18) on any C++ source files (if applicable)
  • 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)

paulromano and others added 5 commits September 11, 2026 23:46
Three non-functional follow-ups to the atomic/nuclear mass split:

- Scope the CODATA 2018 attribution in atomic_mass.h to the bare-particle
  MASS_* constants it actually describes, and point out that the
  ATOMIC_MASS table below it comes from AME2020 instead.
- Document that nuclear_mass(0, 1) returns the CODATA neutron mass, and
  note the deliberate asymmetry with atomic_mass(0, 1), which returns zero
  because a free neutron has no corresponding neutral atom.
- Compare against the AME2020 literals with == rather than Approx in the
  atomic mass test section. These are exact lookups from a literal table,
  so Approx's default ~1e-5 relative tolerance would not catch a
  wrong-but-close table entry. The derived comparisons keep Approx, since
  evaluating atomic_mass() - Z * MASS_ELECTRON in two different contexts
  may differ under FP contraction.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017Z78GT8mhn4WcG3XN8by7v

@GuySten GuySten left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@GuySten GuySten added the Merging Soon PR will be merged in < 24 hrs if no further comments are made. label Sep 13, 2026
@GuySten
GuySten merged commit 141cd30 into openmc-dev:develop Sep 13, 2026
20 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Merging Soon PR will be merged in < 24 hrs if no further comments are made.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants