Open gridley opened 5 months ago
Just to mention there is an open PR for improving the diff burnable mat over here might be worth checking to see if this changes things.
Could this be related to #2798?
Ran into this issue independently. Here was my input (only have a broken one!)
import openmc
import openmc.deplete
def run_test():
# Generate materials
fuel = openmc.Material(1, "uo2")
fuel.add_element('U', 1.0, enrichment=3.0)
fuel.add_element('O', 2.0)
fuel.set_density('g/cm3', 10.37)
fuel.temperature = 900
fuel.volume = 1.0
materials = openmc.Materials([fuel])
# Geometry
fuel_cell = openmc.Cell(fill=fuel) # change to mat_dict['uo2']
fuel_universe = openmc.Universe(cells=[fuel_cell])
y0 = openmc.YPlane(0, boundary_type='reflective')
y1 = openmc.YPlane(1)
y2 = openmc.YPlane(2, boundary_type='reflective')
x0 = openmc.XPlane(0, boundary_type='reflective')
x1 = openmc.XPlane(1)
x2 = openmc.XPlane(2, boundary_type='reflective')
fuel1 = openmc.Cell(fill=fuel_universe, region= (+x0 & -x1 & +y0 & -y1))
fuel2 = openmc.Cell(fill=fuel_universe, region= (+x0 & -x1 & +y1 & -y2))
fuel3 = openmc.Cell(fill=fuel_universe, region= (+x1 & -x2 & +y0 & -y1))
fuel4 = openmc.Cell(fill=fuel_universe, region= (+x1 & -x2 & +y1 & -y2))
universe = openmc.Universe(cells=[fuel1, fuel2, fuel3, fuel4])
geometry = openmc.Geometry(universe)
settings = openmc.Settings()
settings.run_mode = 'eigenvalue'
settings.particles = 1000
settings.batches = 100
settings.inactive = 10
model = openmc.model.Model(geometry=geometry,
materials=materials,
settings=settings)
chain_file = 'chain_endfb71_pwr.xml'
chain = openmc.deplete.Chain.from_xml(chain_file)
operator = openmc.deplete.CoupledOperator(model, chain_file,
diff_burnable_mats=True)
power = 14e6 # W
time_steps = [1] * 30 # days
integrator = openmc.deplete.PredictorIntegrator(operator, time_steps, power,
timestep_units='d')
integrator.integrate()
if __name__ == "__main__":
run_test()
Output:
| The OpenMC Monte Carlo Code
Copyright | 2011-2023 MIT, UChicago Argonne LLC, and contributors
License | https://docs.openmc.org/en/latest/license.html
Version | 0.14.1-dev
Git SHA1 | 3901709141f6e1e85707fa1ce901199df081cc29
Date/Time | 2024-03-11 10:41:51
OpenMP Threads | 20
Reading settings XML file...
Reading cross sections XML file...
Reading materials XML file...
Reading geometry XML file...
ERROR: Could not find material 2 specified on cell 1
This crashes with ERROR: Could not find material 2 specified on cell 1
. This comes from the model
object calling
https://github.com/openmc-dev/openmc/blob/7ed12788df9cc9c1e6582ab4f634a91fde88be89/openmc/model/model.py#L1025-L1074
which calls determine_paths()
for the model.materials
and then the CoupledOperator
exports the old materials
object:
https://github.com/openmc-dev/openmc/blob/7ed12788df9cc9c1e6582ab4f634a91fde88be89/openmc/deplete/coupled_operator.py#L395-L408
I tried to change the above function to export the model.materials
and that gets the simulation a little further, but there is another bug then with the burnable mats that have been set by the original materials
in the OpenMCOperator
bas class of CoupledOperator
.
Output below:
Traceback (most recent call last):
File "/home/icmeyer/ff_adsr/3d/mitr/depletion_test/test.py", line 57, in <module>
run_test()
File "/home/icmeyer/ff_adsr/3d/mitr/depletion_test/test.py", line 54, in run_test
integrator.integrate()
File "/home/icmeyer/openmc/openmc/deplete/abc.py", line 781, in integrate
n = self.operator.initial_condition()
File "/home/icmeyer/openmc/openmc/deplete/coupled_operator.py", line 391, in initial_condition
materials = [openmc.lib.materials[int(i)] for i in self.burnable_mats]
File "/home/icmeyer/openmc/openmc/deplete/coupled_operator.py", line 391, in <listcomp>
materials = [openmc.lib.materials[int(i)] for i in self.burnable_mats]
File "/home/icmeyer/openmc/openmc/lib/material.py", line 282, in __getitem__
raise KeyError(str(e))
KeyError: 'No material exists with ID=1.'
Could be that my input is not the canoncial way to start a depletion calculation, but the Example documents are pretty sparse on depletion. But anyways, not super familiar with the depletion model and how we expect to be handling the different materials objects the process, will try out the suggested PR and see if it gets me anywhere.
@icmeyer did you ever try taking diff_burnable_mats
out of the depletion call, and instead calling model.differentiate_depletable_mats("divide equally")
before depleting?
Just tried and it works great! Thanks for the tip. So could this be fixed by removing the internal CoupledOperator
logic and just adding something in its __init__
like if diff_burnable_mats: model.differential_deplatable_mats(option)
?
I agree, that'd be the way to do it. Really, I think we should deprecate the diff_burnable_mats
kwarg and force users to use the model method first, since you explicitly have to specify the division technique.
Your approach would be best for backwards-compatibility. Maybe someone else can weigh in on this.
Bug Description
Somehow, the differentiated burnable mats are not making it into the materials file when using
CoupledOperator
. I have been able to see this error ONLY on hex lattices. When I try theexamples/lattice/simple
problem, there seems to not be a problem.Steps to Reproduce
Below is a script which can be placed in the
lattices/hexagonal
directory, based on depleting that example using thepincell_depletion
chain, that exhibits the following error. The error specifically is:Interestingly, telling the model to differentiate the materials beforehand seems to work, whereas the legacy approach does not. Perhaps we should just deprecate the latter, and have the
CoupledOperator
call the model's volume splitting method. It would be nice to understand what's going wrong here, though. It is 100% for sure a python thing.Environment
arch linux, latest commit