[openmc-users] Mysterious changes in k-effective with same input deck?

OpenMC is a stochastic code, not a deterministic code, so you should get different results every time you run it.

Look into the tag in the settings.xml file. There are some things you can adjust in there to get a more percise result.

I think, the general idea is you want to run enough particles to get a ‘convergent solution’. As you increase the number of histories run, the K value will bounce around and eventually converge on a value. Plot K as a function of the number of histories, and you’ll see what I mean.

Hi Kendra,

Glad to hear that you were able to find the error and that after fixing it your results seem to match MCNP well. Unfortunately because of OpenMC’s reliance on the xml-fortran package for parsing the input files, sometimes things that should get caught will go through without OpenMC complaining. One thing that you can do to ensure that your inputs do not contain any syntax errors is to validate them against the RELAX NG schemata provided with OpenMC. There are two ways to go about this:

  1. Use the emacs text editor and set it up to automatically validate your files as you’re writing them (see http://mit-crpg.github.io/openmc/usersguide/install.html#configuring-input-validation-with-gnu-emacs-nxml-mode)

  2. Use the ‘jing’ program to validate a file. For example, if your OpenMC source is in ~/openmc and your file to check is ~/inputs/materials.xml, you could run: jing -c ~/openmc/src/templates/materials.rnc ~/inputs/materials.xml. I just took an input file an made the same error you did, and when I try to validate it using jing, it returns:

/home/romano/inputs/materials.xml:18:44: error: value of attribute “ao” is invalid; must be a floating-point number

If you are on ubuntu (or a debian derivative), you can install jing via ‘sudo apt-get install jing’

Best regards,
Paul