You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
According to njoy/NJOY2016#395 the discrete primary gammas were handled wrongly in NJOY2016 for the ENDF/B-VIII.1 library.
We should regenerate this library when that PR is merged using the updated version of NJOY2016.
I can confirm that regenerate is needed for Pt and Ta.
I have myself regenerated ENDF/B-VIII.1 H5 with NJOY2016.79 and interrogation shows that the Pt/Ta now match those of the updated Lib81 Pt/Ta.
I think this and other findings elsewhere, openmc-dev/openmc#4075, underscore that we need some sort of provenance stamping and metadata in the library.
Moreover, in the official releases
@paulromano, thanks for the update. I've opened openmc-dev/openmc#4117 to preserve source-evaluation metadata separately for photoatomic and atomic-relaxation data through HDF5 export and import.
It retains the ENDF library, version, and release as source_library, source_version, and source_release attributes on the existing element and subshells groups. This component-level information would complement the NJOY, OpenMC, and data-repository provenance discussed here.
Would these field names and group locations fit the release metadata format you are planning, or would you prefer an adjustment? I'd like to keep the two efforts consistent.
Activity
yrrepy commentedon Sep 9, 2026
I can confirm that regenerate is needed for Pt and Ta.
I have myself regenerated ENDF/B-VIII.1 H5 with NJOY2016.79 and interrogation shows that the Pt/Ta now match those of the updated Lib81 Pt/Ta.
https://mcnp.discourse.group/t/fixes-for-lib81-pt-190-pt-198-and-ta-180m-neutron-capture-gammas-now-available/4872
https://nucleardata.lanl.gov/files/LA-UR-26-24142.pdf
https://nucleardata.lanl.gov/ace/lib81/
yrrepy commentedon Sep 9, 2026
Regenerate is also needed to incorporate the missed UinUO-*P.endf TSL.
PR #105
yrrepy commentedon Sep 9, 2026
I think this and other findings elsewhere, openmc-dev/openmc#4075, underscore that we need some sort of provenance stamping and metadata in the library.
Moreover, in the official releases
shimwell commentedon Sep 9, 2026
Yep would be nice to stamp information like:
paulromano commentedon Sep 9, 2026
Yes, I agree with you guys. I'm working on a better setup for how we release data that will include all this metadata and will keep you posted.
JROChub commentedon Sep 10, 2026
@paulromano, thanks for the update. I've opened openmc-dev/openmc#4117 to preserve source-evaluation metadata separately for photoatomic and atomic-relaxation data through HDF5 export and import.
It retains the ENDF library, version, and release as
source_library,source_version, andsource_releaseattributes on the existing element andsubshellsgroups. This component-level information would complement the NJOY, OpenMC, and data-repository provenance discussed here.Would these field names and group locations fit the release metadata format you are planning, or would you prefer an adjustment? I'd like to keep the two efforts consistent.