Discrepancy between OpenMC and SCALE depletion results

imelnyk · June 11, 2026, 6:25am

Hi there,

I am modeling depletion of VVER-440 fuel assembly using CoupledOperator and CECMIntegrator and want to compare the results of the OpenMC simulation with a similar SCALE6.2.4 t-6 depl sequence results. However, there is a noticeable discrepancy in the k_{eff} - Burnup depth results:

It looks like the OpenMC graph is squeezed horizontally by a factor of 10 compared to the SCALE’s one. I also fond a peak typical for that fuel composition and assembly profile between 10 and 20 MWd/kgU and the similar peak on OpenMC graph is about 1 and 2 MWd/kgU.

Could you please check the chunk of OpenMC code and hint me what am I doing wrong?

# settings 
settings = openmc.Settings()
settings.batches = 100
settings.inactive = 20
settings.particles = 10_000

settings.temperature['method'] = 'interpolation'
settings.temperature['multipole'] = True

# source
min_extents = (-assembly_case_in_edge, -assembly_case_in_apothem, -124.)
max_extents = (assembly_case_in_edge, assembly_case_in_apothem, 124.)
source_dist = openmc.stats.Box(lower_left=min_extents, upper_right=max_extents)
settings.source = openmc.IndependentSource(space=source_dist, constraints={'domains': [uo2_type1, uo2_type2, uo2_type3, uo2_type4],
                                                                           'fissionable': True})
settings.export_to_xml()

# depletion
import openmc.deplete
chain_path = '/home/imelnyk/openmc-nuclear-data/endfb-vii.1-hdf5/chain_endfb71_pwr.xml'
# set volumes .....
# .................
# .................

model = openmc.Model(geometry=geom, settings=settings)
depletion_operator = openmc.deplete.CoupledOperator(model, chain_path, normalization_mode='energy_deposition')
power_mass_density = 35. # W/gU
time_steps = [1., 2., 3., 4., 5., 6., 7.571428571] + 60 * [28.57142857]
integrator = openmc.deplete.CECMIntegrator(depletion_operator, timesteps=time_steps, power_density=power_mass_density, timestep_units='d')
integrator.integrate()

Probably, there might be an error in timesteps(?).
P.S. Some fuel pins contain Gd.

Cheers,
Ihor

doriangaboo · June 11, 2026, 2:16pm

I believe, it may have to do with OpenMC’s timesteps being relative to the previous given timestep point, so your current time steps

[1., 2., 3., 4., 5., 6., 7.571428571]

aren’t seen as constantly increasing by 1, that series is interpreted as [1,3,6,10,15,21,28.571428571].

I’m just getting started with OpenMC myself, so I am not incredibly familiar with the burnup capabilities, but I did learn about this a few days ago.

wahidluthfi · June 11, 2026, 2:27pm

Hi imelnyk,
Since you use the burnup MWD/kg as x axis, I think there must be something in the composition. If you have made sure the geometry, power density, timestep and accumulation time was identic berween each code, you might want to compare the fuel and burnable poison BP composition calculated by each code during depletion. You can use time as x axis when comparing both results.

Also, you might want to check that the depleteable parameter on the material was set as True, either for the fuel or BP, and each should have a proper volume so that the initial isotope mass between each code was the same. The power density will be multiplied by the heavy metal mass, so you could also do a sensitivity analysis by directly supplying the fuel assembly power to the openmc.

imelnyk · June 12, 2026, 6:05am

Hi @doriangaboo,
Thanks for your answer! However, I’m not sure that the time steps are supposed to be cumulative, since the opposite is literally specified in the lecture on depletion:

imelnyk · June 12, 2026, 7:49am

Hi @wahidluthfi,

Thanks for your advises! I double check the material and couldn’t find anything suspicious for the moment. I set the material for fuel pins with BA mixing UO2 and Gd materials. I thought that I any material contain Uranium it should be implicitly treated as a depletable, but probably it does not work for Gd. So, I set the Gd mat. to be depletable explicitly and start the calculations. I will see the results later …

wahidluthfi · June 12, 2026, 1:21pm

Okay, you can also compare the decrease in fissile and BP isotope materials vs time or burnup between each code to find some clue, because I think the decrease in reactivity should have come from those isotopes; either your fissile atomic density decreases faster in openmc, or the BP is not depleted, suppressing the reactivity without even burning it.

doriangaboo · June 14, 2026, 6:47pm

Reading back what I said I definitely wrote that poorly, my apologies. I was trying to communicate what they state there, how a burn up calculations with 6 time steps of 30 days, would be defined like [30,30,30,30,30,30] instead of [30, 60, 90, 120, 150, 180]

Unfortunately I can’t speak to whether that could be the cause, I’m not familiar enough with burnup mechanics, but hopefully you get it! Best of luck

wahidluthfi · June 15, 2026, 10:58pm

Regarding “a burn up calculations with 6 time steps of 30 days”, it would be [30,30,30,30,30,30] or [30] * 6. you can also check the depletion notebook from openmc.

github.com/openmc-dev/openmc-notebooks

depletion.ipynb

develop

{
 "cells": [
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "# Pincell Depletion\n",
    "This notebook is intended to introduce the reader to the depletion interface contained in OpenMC. It is recommended that you are moderately familiar with building models using the OpenMC Python API. The earlier examples are excellent starting points, as this notebook will not focus heavily on model building.\n",
    "\n",
    "If you have a real power reactor, the fuel composition is constantly changing as fission events produce energy, remove some fissile isotopes, and produce fission products. Other reactions, like $(n, \\alpha)$ and $(n, \\gamma)$ will alter the composition as well. Furthermore, some nuclides undergo spontaneous decay with widely ranging frequencies. Depletion is the process of modeling this behavior.\n",
    "\n",
    "In this notebook, we will model a simple fuel pin in an infinite lattice using the Python API. We will then build and examine some of the necessary components for performing depletion analysis. Then, we will use the depletion interface in OpenMC to simulate the fuel pin producing power over several months. Lastly, we will wrap up with some helpful tips to improve the fidelity of depletion simulations."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": 1,
   "metadata": {},
   "outputs": [],
   "source": [

This file has been truncated. show original

But as long as that plot of you use the pregenerated time you are getting from openmc depletion result, i.e. deptime, kinf = depletion_results.get_keff(time_units='d') or deptime, atom_U235 = depletion_results.get_atoms(mat=fuel, nuc='U235', nuc_units='atom/b-cm', time_units='d'), then the depletion time was a cumulative time, not the time step.

imelnyk · August 17, 2026, 8:59am

Dear @wahidluthfi,

I’m sorry for the late reply since I slightly suspended these studies. Recently, I re-ran the simulation with explicitly specified depletable property for UO2 + Gd2O3 material and got the following graph for e.g. ^{157}Gd nuclei number density:

It looks like that for BP/BA fuel type (the blue line) gadolinium-157 burns up almost immediately, might it suggest that something is wrong with depletion rate? This drop in the Gd number density suspiciously matches with that small peak you might’ve seen on the K_{eff} vs. burn-up depth graph which appears to be the same as for the previous runs (w/o depletable property).

Cheers,
Ihor

P.S.
Giving the shape and numerical ranges of the two curves below:

it looks like the problem is in the power density settings, since the all the ^{235}U burned-up up to 10 MW*d/kgU.

wahidluthfi · August 18, 2026, 9:40am

Since you already mentioned the power density, I see that you use the power density in your integrator, power_mass_density = 35. # W/gU as power density.

So, just to make sure, have you declared the depleted material volume in your input? You can check the initial heavy metal mass with get_mass from your fuel material definition. From the depletion manual, “openmc will multiply the power density by initial heavy metal inventory to get the total power if power is not specified”. openmc.deplete.CECMIntegrator — OpenMC Documentation

I havent use the power_density parameter in the integrator since most of the time, I am declaring the total heavy metal volume in my model and applied specific power for this volume of HM, so I have no experience with this kind of power density input.

imelnyk · August 18, 2026, 10:52am

A typical VVER-440 fuel assembly consists of 126 fuel pins and one central tube. In the current problem 4 types of fuel (depending on uranium enrichment and presence/absence of BA) are considered: only one type among these 4 has Gd. So, therefore the FA contains 4 different types of fuel rods (pins). A typical pin is represented as a cylinder with another hollow cylinder centered inside the outer one (actually filled with helium). The FA configuration of interest has 6 pins with BA, 30 pins filled with fuel_type1, 6 with fuel_type2 and rest are fuel_type3 filled.

Volume of a single pin is calculated as:

pin_volume = math.pi * ( r_out**2 - r_in**2) * height

then this value is multiplied by the number of pins for each fuel_type and assigned to it’s material instances via the .volume property:

fuel_type1.volume = 6 * pin_volume; # with Gd burnable absorber
fuel_type2.volume = 30 * pin_volume 
fuel_type3.volume = 6 * pin_volume
fuel_type4.volume = (126 - 6 - 30 - 6) * pin_volume

Topic		Replies	Views
Have a trouble during the depletion of the openmc User Support	3	342	June 24, 2024
PWR UO2 Benchmark Validation and Verification	16	1866	February 1, 2022
Issue with Depletion Calculations User Support	4	312	August 16, 2024
Depletion compare with restart depletion Validation and Verification	10	1552	January 12, 2022
Different Burnup Results User Support	3	226	September 20, 2025

Discrepancy between OpenMC and SCALE depletion results

Related topics