Hi,
I’ve been using OpenMC to conduct fusion blanket neutronics simulations, including TBR, DPA, neutron flux, nuclear heating, and dose rate calculations. I am now looking into conducting shutdown dose rate calculations and was wondering if that capability was already built in OpenMC since there is a depletion module and a dose rate calculation feature too?
Thank you in advance for your help,
All the best,
@vprst Great to hear you are interested in this topic! As a matter of fact, we have an active project that is funded by Office of Science/FES here in the US (@pshriwise and @eepeterson are my collaborators on this) to develop shutdown dose rate capabilities in OpenMC, namely to support both R2S and D1S workflows. We’re getting pretty close to having something functional and have been testing it out on the FNG dose benchmark from SINBAD.
I’d love to talk with you further about your particular interests and needs to ensure that whatever capabilities we’re putting together will be useful for you. Let me know if you’re up for a chat sometime!
I should also note that we have a project board that you can find here (useful for tracking development on various subtasks):
Well I was just looking to do this as well sounds like it is under active development. I guess there is no way to build and normalize a source term from the isotopes and activities in the depletion results?
In particular I would like to be able to take materials from a depletion calc with simplified geometry (just a core) and use that to do dose and heating calculations in the context of a larger system.
Thanks,
Josh
@jpayne As a matter of fact, such a functionality just got merged into the main branch today:
Along with another feature that is close to being merged, it should be possible to take a depleted material, get the photon source, and feed that back in as a photon source term over a cell to do a dose/heating calculation.
These features are really fantastic, thank you!!! I have a couple of questions about these capabilities, and am hoping to get some guidance.
First, I’m using the Source.domains functionality in conjunction with DAGMC, and am sometimes running into source sampling efficiency problems, particularly with small volumes: More than 95% of external source sites sampled were rejected. Please check your external source's spatial definition. Currently I’m using a bounding box on the entire DAGMC universe, which is clearly too big. Is there some existing functionality to get bounding boxes of individual DAGMC volumes, so that I can make my Source.space box much smaller without having to manually define it?
Second, with the new decay_photon_energy capability, I occasionally run into the issue where some of the source photons produced are at energies below the cutoff for my xs tables: ERROR: Source energy below range of energies of at least one cross section table. For now, I’m using ENDFB 7.1 depletion chains downloaded using this script and ENDFB 8.0 photon cross sections downloaded from Data Libraries | OpenMC. Does anyone have thoughts/suggestions on how to deal with these photons below the cutoff energies of the data tables?
Again, thank you for these new features, they are really great!
Hey @kevinm387, glad you’re enjoying them! @pshriwise might be able to give some ideas regarding the bounding box for DAGMC volumes.
For the source energy issue, I’ve also run into that as well. The issue is that the data we use for thick-target bremsstrahlung results in an energy cutoff around 1 keV, so any photons that are produced below become problematic. Right now, I’m manually removing them from my source:
mask = energy.x > cutoff
energy.x = energy.x[mask]
energy.p = energy.p[mask]
For most practical cases, ignoring these low-energy photons should have a negligible effect on the results (in my case, they were well below .1% of the total energy).
I’m planning on updating the code so that these low-energy photons will just be killed immediately and deposit their energy locally so that no special preprocessing of the energy distributions is needed. Hopefully by our next release you’ll be able to take advantage of that.
Hi @kevinm387,
The best suggestion I have for now is to use the mbconvert tool provided by MOAB to extract the volumes you’re interested in sampling over into a separate file. You could then create DAGMCUniverse objects using those new files to get their bounding boxes, though you wouldn’t want to use these new objects for transport.
In a shell:
$ mbconvert -v 1 original_file.h5m vol_1.h5m
And then in Python
import openmc
vol_1_univ = openmc.DAGMCUnvierse('vol_1.h5m')
vol_1_univ.bounding_box
For more info on that shell tool, you can use mbconvert -h to see additional options. That tool will take a list of volume IDs in the case that you’d like to get the bounding box of that set of volumes, for example.
Thank you @paulromano and @pshriwise, really appreciate these suggestions!
I was thinking about the bounding box part of this discussion the other day as well.
We currently look at all of the coordinates in the tstt nodes coordinates group and get the mix max values to get the global bounding box
However we could cycle through node IDs that belong to each tstt element connectivity. This would allow us to get bounding boxes for each volume.
However we might want a mesh based approach instead
Updated the shut down dose rate example on the fusion-energy neutronics_workshop with help from Paul
If anyone is looking for a shut down dose rate simulation feedback on this one is most welcome
Thanks @Shimwell for the sddr example. I tested it on the fng shut down dose rate sinbad benchmark. I encountered the error: “Box/fission spatial source must have six parameters specified.”
I attached my input file to get your feedback. The error occurs during the photon transport with either cell of mesh tally.
fng_sddr_cell.py (4.2 KB)
geometry.xml (33.2 KB)
materials.xml (8.6 KB)
@Bamsdee Just looking at the script, I believe the problem may be :
space = openmc.stats.Box(*cells[cell_uid].bounding_box)
This may not work depending on the cells that are being used – OpenMC is not always able to calculate a bounding box for a cell. In cases where it is not able too, you’ll get inf values.
Got it. Thank you @paulromano
I was wondering if it’s better to base the calculations on superimposed mesh on the geometry instead of the cells, to avoid such, since the mesh have conventional shapes compared to the cells.
Tested the @eepeterson R2S wrapper on the same problem and didn’t have such issues with the source, though not yet sure of the answer.
@Bamsdee the R2S model wrapper isn’t generic enough to handle other use cases right now, it’s just a contrived toy problem. We still need to implement geometry homogenization for mesh-based activation and a few other things, but should be able to get to it soon with Paul’s recent depletion improvements.
This warning message occurs if there are no decay photons found in the nuclides that are being looked up in the chain file.
It might be the case that the material has no decay gamma emission
Here is a link to the source code which might help understand when this warning message gets printed openmc/openmc/data/decay.py at 382bcb2e8ea63b5ffd9ead818c651e5aa9d4c7ce · openmc-dev/openmc · GitHub
Thank you for your reply, I also found the source code, but this warning is due to my use of ’ chan-nndc-b7.1.xml ’ rather than ’ chan-nndc-b8.0.xml '?
If you know the nuclides then you could check the contents of the chain file to see if it has photon decay data in version 8 and not in version 7.1. I guess version 8 does have more decay data in general
Thank you for your reply, due to network reasons 
, I use ’ pip install openmc _ data download _ nndc _ chain-r b8.0 ’ did not succeed in obtaining ’ chan-nndc-b8.0.xml ', so I choose ’ chan-nndc-b7.1.xml '.How do I get ‘chan-ndc-b8.0.xml’, I will be grateful. 
That might be due me renaming the script. Could you try …
pip install openmc_data
download_endf_chain
