Repository navigation
Apply virtual material densities to microscopic tally results - #4029
Conversation
|
Ok this PR is clearly much more concise than #4027 which I think we all like 👍 It does appear to me at least to come at a small cost:
So it comes down to in this case we value simplicity, maintainability and clean tally inputs over exact covariance-aware collapsed sigma and slightly less user effort. If it suits we can leave these open for a while to give us a chance to discuss them at the next F4E UKAEA Proxima fusion meeting |
Related to this, one downside to #4027 is that it misses out on the ability to break down the response by nuclide. |
|
What do you think about a keyword argument that decide if we collapse along the nuclide axis or not? |
In this case I would lean slightly towards avoiding extra keyword args that grow the API surface for this niche use case and users can collapse themselves. |
shimwell
left a comment
There was a problem hiding this comment.
Thanks Paul I agree this is the option to go for, LGTM in for the impending release if it is not too late
Scores the silicon neutron kerma with all three naturally occurring silicon nuclides and applies their atom densities afterwards with Tally.apply_virtual_material, which arrived in openmc-dev/openmc#4029. This replaces the hand rolled fictional density algebra that a single Si28 bin needed. The mass density chosen for the silicon cancels out of the dose, so what the material actually buys is the isotopic mix, and the per nuclide breakdown is printed to show it: Si30 is 3.1% of the atoms but only 1.5% of the heating. Fixes found while making that change: - Mesh tally results were never divided by the voxel volume, so every silicon and biological dose number was 3771.69 times too large. The sibling notebook 5_mesh_dose_from_neutrons.ipynb already does this. - The photon silicon tally scored almost nothing. OpenMC scores photon energy deposition collision by collision against the nuclide that was actually hit, so multiply_density has no effect and a silicon nuclide bin is exactly zero wherever there is no silicon. The tally is removed and the limitation is documented, with the photon route covered separately in 8_photon_dose_in_a_virtual_material.ipynb. - tallies.out was 314 MB for half a million voxels, now switched off. - Non positive voxels are masked so a logarithmic colour scale cannot fail at reduced particle counts. - The statepoint is reloaded before apply_virtual_material, which scales the tally in place and is not idempotent, so the cell can be re-run. - openmc.data.JOULE_PER_EV replaces a truncated constant, the materials are passed to the Model explicitly and the em dashes are gone.
Description
This PR is an alternative to #4027. It adds an in-place
Tally.apply_virtual_material()method for applying thenuclide atom densities of an
openmc.Materialto tally results generated withmultiply_density=False. This supports calculations such as determining dose in silicon when silicon is not present in the transport model. The method preserves the tally's nuclide dimension, scales all statistical moments consistently, and assigns zero density to tally nuclides absent from the virtual material. The new method only requires 60 lines of code, most of which is just documentation/error checks; the actual implementation is ~15 lines.I've also added a section in the user's guide discussing the use of virtual materials, showing an example of computing dose in Si.
Checklist
I have run clang-format (version 18) on any C++ source files (if applicable)