Tally Uncertainty; OpenMC vs. MCNP

User Support
1

Hello,

any ideas or insight why an identical case that is run in OpenMC 0.13 and MCNP6.2 (ENDF8)
would consistently have ~30% higher uncertainty (1-sigma rel.error) for OpenMC than in MCNP?

This is for both track-length, f4 type tallies/scores of the same cells.
Same number of particles, fixed source, implicit capture is on. No other special options.

Regards,
Perry

2

That’s interesting – I don’t know offhand why that would be. Are you able to share the models (or simplified versions) that you’re running? I’d be curious to try it out myself and see if we can come up with a plausible explanation.

3

Hi, also, are you using survival biasing in OpenMC?

4

Never mind, just saw the note on the settings…

5

I can’t share the problem.

I have noticed that in MCNP wc1=0.5 and wc2=0.25 (all importances are 1).
It seems the equivalent in OpenMC is weight_avg and weight, I’ve now set that to the same (from OpenMC defaults 1.0 and 0.25). But strangely that changed nothing in the OpenMC calculation (exactly the same results).

I’m continuing to explore the problem (different tallies, etc.)

6

@yrrepy I seem to recall we did eventually have some further discussion on this and that the issue was that this is a photon transport simulation (which doesn’t actually use implicit capture). Is my recollection correct?

7

Hi Paul,
it’s a mixed np problem. I was comparing neutron tallies.

I’m back working on associated problems, I’ll update when I have something concrete to report.

8

Hi there!

I am using survival biasing in neutron transport problem. And it seems there are not big difference between using various parameter values. The maximum reduction in relative error reaches 1%. But the FOM parameter increases twice.

I would like to know if anyone managed to get a significant gain when using survival biasing?

9

I’m definitely noticing a difference between what I use as my weight_avg and weight (wc1, wc2).
Affects tally uncert and FOM, generally in a positive way. Rel. error being impacted by ~30% in some regions.

@paulromano
One thing I’ve noticed recently is that wc1 and wc2 in MCNP actually by default are (-0.5,-0.25).
In MCNP it claims this - actually multiplies the used wcs by the minimum source weight of the used source (be it sdef or ssr).

Taking my OpenMC calc, and manually re-norming the wc1,wc2 does seem to be helping in improving it’s performance relative to MCNP.

10

Interesting point @yrrepy. How are you adjusting the source weight in your simulations? Right now, specifying a source strength in OpenMC doesn’t actually do anything with the weight.

11

I’m using an RSSA from MCNP, converted to OMC Source HDF5 format (via my own MCPL-OMC Python script, not the direct facility the MCPL peeps are working).
I’ve generated various ones with different initial SSW parameters (some analog, some OMC wcx defaults, some MCNP wcx defaults).

I take the weights as is, during the OMC SSR I adjust the wcx manually. I find out the lowest weight neutron on the RSSA, then adjust (multiply) the wcx for the OMC SSR run.

Sorry for all the acronyms but those names are just too long.

12

Hi Katya,
A FOM increase of 2x is significant. It means your calculation is converging twice as fast, it costs 2x less computational resources.

13

The plot thickens.

After some testing in MCNP, with negative wc1 and wc2:

  • for fixed sources; it appears to indeed multiply wc1 and wc2 by the “minimum” weight of the source, but this is usually fixed (a constant)
  • for phase spaces; near as I can tell it is actually multiplying wc1 and wc2 by [total weight of particles on the phase space divided by the number of particles] or [total source weight/records] so, the mean weight of the phase-space. I’m about 98% sure of this. Some info does indicate that it could rather be [total source weight/histories].

They always refer to it as the minimum weight of the source (SWTM) which threw me astray.
For phase-spaces weight cutoffs are certainly not being multiplied by the weight of the minimum weight particle on the phase-space.
I believe biased fixed sources are the only true case where they are multiplied by a minimum weight.

I’m hoping to eventually work on a pull-request that will enable an option to automatically scope a read-in MCPL or H5 source file, determine the mean weight (or whatever factor be it) and multiply the survival biasing weight cutoff parameters by it.

14

To further document this:
under further testing, with phase-spaces in MCNP:
it is not multiplying wc1 and wc2 by the average rssa weight,
rather for each SSR history it is multiplying the weight cutoffs by the starting weight of the history (particle).

->The weight cutoffs are different for each particle history