Description
While investigating a discrepancy in low-energy gamma dose calculations between MCNP and OpenMC, I traced the difference to the underlying photoatomic data libraries. The issue disappeared when comparing the codes with apples-to-apples ND. An obvious solution but I think it highlighted the issue of transparent tracking of the source of the ND in the distributed libraries.
In my opinion it’s hard to track down exactly which nuclear data was used to generate OpenMC HDF5 libraries. I know there was also an issue/misunderstanding when tracking down the origin of the FENDL data for example.
Potential Solutions
A couple of potential solutions:
-
Expand the current description of each library on the data download page with the source of the ND used. LANL usually release a document describing each of their ACE file releases. I don’t think we need to be as thorough, especially if we are just grabbing those files and converting them, but some trace back would be great. Origin, dates of download etc. We could also link to the specific processing script from the ND git repo (https://github.com/openmc-dev/data) that was used.
-
Potentially store ND metadata directly in the HDF5 files (source evaluation, library version, processing details, etc.).
-
For future MCNP benchmarking, considering most MCNP simulations still use MCPLIB84, convert it to HDF5 for the use with OpenMC.
I fully acknowledge this kind of issue is a symptom of the confusing world of nuclear data evaluations, but I think it would make life easier to users especially for benchmarking, V&V and qualification efforts to have a clear, traceable and potentially citable source of OpenMC ND.
Original post on the issue in the forum: https://openmc.discourse.group/t/how-to-generate-the-data-of-photoatomic-in-h5-format-by-myself-through-the-file-of-mcplib84/4468/5?u=boratbh
Description
While investigating a discrepancy in low-energy gamma dose calculations between MCNP and OpenMC, I traced the difference to the underlying photoatomic data libraries. The issue disappeared when comparing the codes with apples-to-apples ND. An obvious solution but I think it highlighted the issue of transparent tracking of the source of the ND in the distributed libraries.
In my opinion it’s hard to track down exactly which nuclear data was used to generate OpenMC HDF5 libraries. I know there was also an issue/misunderstanding when tracking down the origin of the FENDL data for example.
Potential Solutions
A couple of potential solutions:
Expand the current description of each library on the data download page with the source of the ND used. LANL usually release a document describing each of their ACE file releases. I don’t think we need to be as thorough, especially if we are just grabbing those files and converting them, but some trace back would be great. Origin, dates of download etc. We could also link to the specific processing script from the ND git repo (https://github.com/openmc-dev/data) that was used.
Potentially store ND metadata directly in the HDF5 files (source evaluation, library version, processing details, etc.).
For future MCNP benchmarking, considering most MCNP simulations still use MCPLIB84, convert it to HDF5 for the use with OpenMC.
I fully acknowledge this kind of issue is a symptom of the confusing world of nuclear data evaluations, but I think it would make life easier to users especially for benchmarking, V&V and qualification efforts to have a clear, traceable and potentially citable source of OpenMC ND.
Original post on the issue in the forum: https://openmc.discourse.group/t/how-to-generate-the-data-of-photoatomic-in-h5-format-by-myself-through-the-file-of-mcplib84/4468/5?u=boratbh