Benchmark against MCNP and Tripoli4 unsatisfactory

Validation and Verification
1

Hello,

I have tried to benchmark the photon transport implemented in OpenMC against MCNP and Tripoli4, with JEFF33 data. So I modeled two spheres, the inner most is in U235 (density of 19.5g/cm3) and the outer most is made of air (N14 at 80% and O16 at 20%, with a density of 0.001g/cm3). Their respective radius are 8,5cm and 15cm. Both are centered on the same point. I also placed a cylinder in the sphere of air, at a distance of the center of 10.5cm. The cylinder has a radius of 2cm and a height of 5cm. The material it is made is Si28 at 50% and C0 (C12 in MCNP) at 50% and has a density of 3.15g/cm3. All materials are at 293.15K.

The image shows an “XZ” cut at Y=0.

image
image1000×1000 29.8 KB

I made a criticality calculation and measured the heat deposited by neutrons and photons on the cylinder. I also measured the flux discretized in 18 energy groups of neutrons and photons in the different parts/cells. I found significant differences for the heat deposition caused by photons. The figures below illustrates that issue. MCNP and Tripoli4 seems to agree on the same value while OpenMC does not. However, the mean squared error for the comparison of Tripoli4 and OpenMC against MCNP shows that the photon transport is correct since they all agree.

Energy levels in MeV are : [
0.00E+00,
1.00E-01,
2.00E-01,
3.00E-01,
4.00E-01,
5.00E-01,
7.00E-01,
1.00E+00,
2.00E+00,
3.00E+00,
4.00E+00,
5.00E+00,
6.00E+00,
7.00E+00,
8.00E+00,
9.00E+00,
1.00E+01,
1.50E+01,
2.00E+01
]

heating
heating3409×1281 37.9 KB

fluxes
fluxes3438×1905 153 KB

I provide you the zip, in the issue opened in github, containing the excel sheet used for post processing and the OpenMC code I implemented for that purpose in Jupyter notebook.

It seems there is a bug in the OpenMC heating tally.

Any lead on that ?

2

Hi Azim,

try tallying photon, electron and positron heating.
Add all three together, including and summing any negative values

Perry

3

Hi,

Thank you for answer. Can you explain in which way this could solve the mismatch ?

4

Because OpenMC subdivides the energy. Most of the photon kerma energy is in the ‘electron’ bin.

5

Hi,
Thank you for the clarifications. However, it does not fix the issue for me. The details of the calculation are shown below.

Photon [eV/sp] Positron[eV/sp] Electron[eV/sp]
1.590e+01 +/- 7.470e-01 6.305e-01 +/- 5.630e-01 1.378e+03 +/- 8.190e+00

Image1
Image13409×1281 40.9 KB

6

@azim Does the photon flux spectrum in the relevant material/cell agree between OpenMC and MCNP? If you are able to share your MCNP model too, that may be helpful for spotting potential differences.

7

The flux spectrum shown above is for the flux in the relevant cell. So yes, it does agree. In the github issue I added the output file of MCNP (“crit-ref” I could not attach it here because of the file extension) where you will find all the input data for the simulation.

8

Can you post the .xmls (in the closed issue is fine). I can’t run the markdown ipynb
Also the latest MCNP input (fyi, your Oxygen is wrong (8016 not 16032))

It could be the OpenMC delayed_photon_scaling

9

Thank you for pointing out the mistake in MCNP. This will be corrected. I will repost the corrected result. I am not familiar with the delayed_photon_scaling, I will look into that.
Here are the xml’s.
settings.xml (435 Bytes)
materials.xml (587 Bytes)
geometry.xml (543 Bytes)

10

Just ran this;
I’m 99.9% sure that it’s the delayed gammas.
I get a result 40% lower with delayed gammas off; in-line with your MCNP/Tripoli result.

By default MCNP does not simulate delayed gammas, only prompt gammas.
Depending on the nuclear system in question delayed gammas can be ~50% of the total gamma energy produced (or compelled) from fission.

There are delayed gamma modules in MCNP (act gam, something like that). And other means to simulate delayed gammas (R2S, etc.)

These delayed gammas can also sometimes be called capture gammas or other.