Error when trying to run depletion: "ERROR: Need to specify a positive density on material 2."

User Support
#1

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)

#2

Hi Tellef,

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.

Best regards,
Paul

#3

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.

Best Regards,
Sindre

#4

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 :+1:

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'?>
<materials>
  <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" />
  </material>
</materials>
#5

@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.

#6

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(
        model=model,
        chain_file=chain_filename,
        normalization_mode="source-rate"
    )

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 normalization_mode

#7

@Shimwell Yes, that seems like a sensible warning to add. A pull request would be much appreciated! :pray: