When running the depletion caclutations i get an error “ERROR: Need to specify a positive density on material 2.”. In my materials.xml file, my material density is positive. When changing the material-densities to >1, i get another error" ERROR: Something went wrong reading surface coeffs".
I am running on Ubuntu 18.04.3 LTS, and with version Version | 0.11.0.
I have tried to fix this, but without luck yet… I was wondering id anyone has experienced the same error?
(The script seems to work when running on mac…)
thoriumBreederReactor.py (17.9 KB)
I was able to run your script on my machine ok without running into the error about a positive density. During a depletion calculation, OpenMC will automatically change the number densities of isotopes in a material, and that error may occur if it somehow sets the density to a negative value. So, that is to say, the issue is not with your original materials.xml file (which has all positive densities), but with the densities that OpenMC is calculating during the depletion simulation. One thing I did notice is that the number of particles you are running is pretty low, which may result in high uncertainties – I suspect this could potentially be an issue that would lead to weird depletion results. You may want to try increasing the number of particles you are running to get a solution with lower statistical uncertainty.
Could it be Ubuntu-related? I have seen a couple of these problems, all on ubuntu machines. I was also able to run the script on my mac.
I’ve also come across negative densities warnings and then a fatal error when running low particle depletion simulations.
Increasing the particle count does appear to help
I’m running a fixed source simulation but the warnings include negative values for al sorts of materials including U, Pu
Section of negative density warnings
WARNING: nuclide U237 in material 2 is negative (density = -0.9951013842992699 at/barn-cm)
WARNING: nuclide U238 in material 2 is negative (density = -3526956.7335471865 at/barn-cm)
WARNING: nuclide U239 in material 2 is negative (density = -1.380556308531165e-20 at/barn-cm)
WARNING: nuclide Np237 in material 2 is negative (density = -1424582297.7047794 at/barn-cm)
WARNING: nuclide Pu237 in material 2 is negative (density = -189386387003.1177 at/barn-cm)
WARNING: nuclide Pu238 in material 2 is negative (density = -43362829476.93741 at/barn-cm)
WARNING: nuclide Pu239 in material 2 is negative (density = -251745308282681.72 at/barn-cm)
WARNING: nuclide Pu241 in material 2 is negative (density = -1108650206.4232354 at/barn-cm)
WARNING: nuclide Pu242 in material 2 is negative (density = -707637784806302.4 at/barn-cm)
Then the simulation terminals with this subcritical error which is interesting as I’m running a fixed source simulation with steel
Simulating batch 1
ERROR: The secondary particle bank appears to be growing without bound. You are
likely running a subcritical multiplication problem with k-effective
close to or greater than one.
My materials.xml is fairly standard steel material, no fissionable material included
<?xml version='1.0' encoding='utf-8'?>
<material depletable="true" id="2" name="dished_vessel" volume="1723741.591484405">
<density units="g/cm3" value="7.96" />
<nuclide ao="0.36891872000000003" name="Si28" />
<nuclide ao="0.018732640000000002" name="Si29" />
<nuclide ao="0.012348640000000001" name="Si30" />
<nuclide ao="0.395395" name="Cr50" />
<nuclide ao="7.624799" name="Cr52" />
<nuclide ao="0.8645909999999999" name="Cr53" />
<nuclide ao="0.215215" name="Cr54" />
<nuclide ao="0.5" name="Mn55" />
<nuclide ao="5.20205" name="Fe54" />
<nuclide ao="81.66106" name="Fe56" />
<nuclide ao="1.88591" name="Fe57" />
<nuclide ao="0.25098" name="Fe58" />
<nuclide ao="0.14649" name="Mo92" />
<nuclide ao="0.09187" name="Mo94" />
<nuclide ao="0.15873" name="Mo95" />
<nuclide ao="0.16673" name="Mo96" />
<nuclide ao="0.09582" name="Mo97" />
<nuclide ao="0.24292" name="Mo98" />
<nuclide ao="0.09744" name="Mo100" />
@Shimwell If you run a fixed source calculation on a system where keff is very close to or greater than 1, you’ll end up with essentially a runaway chain reaction which causes OpenMC problems because it would blow out memory to store the increasing populations of secondary particles (fission neutrons). When you run OpenMC in k-eigenvalue mode, fission production is scaled by 1/keff so that this doesn’t happen, but in fixed source mode no such scaling happens.
Yep that behavior is understandable. I’m just surprised that steel became critical when depleted.
It took me a while but I think this was because the default normalization_mode is “fission-q”. Changing it to “source-rate” helped.
operator = openmc.deplete.Operator(
I notice we are passing in the
model here so perhaps I could add a check that looks at the
model.Settings.run_mode and if it is equal to
fixed source then I guess it could throw up a warning if
fission-q normalization is found to be the
@Shimwell Yes, that seems like a sensible warning to add. A pull request would be much appreciated!