# OpenMC Independent Depletion Operator Split Time Steps **URL:** \ **Category:** User Support\ **Created:** [June 12, 2023, 3:27pm UTC](https://openmc.discourse.group/t/openmc-independent-depletion-operator-split-time-steps/3091 "2023-06-12T15:27:22Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![LukeSeifert](https://avatars.discourse-cdn.com/v4/letter/l/50afbb/32.png) [@LukeSeifert](https://openmc.discourse.group/u/LukeSeifert)\ **Post date:** [June 12, 2023, 3:27pm UTC](https://openmc.discourse.group/t/openmc-independent-depletion-operator-split-time-steps/3091/1 "2023-06-12T15:27:22Z")
Hi all, I have a simulation where I would like to have transport coupled depletion for some time steps and transport independent depletion for some time steps. The issue I had was that running with full transport coupling seems to take the same amount of time as the transport independent operator. However, in my results, the keff data was not present for the transport independent steps, so it seemed like things were running as intended. After looking into things a bit, I noticed the issue is that OpenMC performs transport again instead of using the previous result data if the independent operator steps aren’t in a list. I’ve included a minimal working example here to demonstrate what I mean. The desired behavior from this MWE is for OpenMC to run the first step with transport, and then run the independent steps using the data from the first step. However, transport is run each time for each transport independent step. Is there a way to avoid this if there are not many transport independent steps in a row and the days are split up in the script? I know the solution for this MWE would be to remove the loop for the transport independent simulations and instead use a list of day steps, but for my more complex problem I want to have a mix of transport coupled and independent steps. Because of this mix of operator types, I can only get slight improvements by making lists of steps that use the same operator type in a row. ```auto import openmc import numpy as np import openmc.deplete def model(): f = openmc.Material(name="f") f.add_element("U", 1, percent_type="ao", enrichment=4.25) f.add_element("O", 2) f.set_density("g/cc", 10.4) w = openmc.Material(name="w") w.add_element("O", 1) w.add_element("H", 2) w.set_density("g/cc", 1.0) radii = [0.42, 0.45] f.volume = np.pi * radii[0] ** 2 w.volume = np.pi * (radii[1]**2 - radii[0]**2) materials = openmc.Materials([f, w]) surf_f = openmc.Sphere(r=radii[0]) surf_w = openmc.Sphere(r=radii[1], boundary_type='reflective') cell_f = openmc.Cell(fill=f, region=-surf_f) cell_w = openmc.Cell(fill=w, region=+surf_f & -surf_w) geometry = openmc.Geometry([cell_f, cell_w]) settings = openmc.Settings() settings.particles = 100 settings.inactive = 0 settings.batches = 10 return openmc.Model(geometry, materials, settings), f, w if __name__ == " __main__": power = 174.0 rate = 1E-5 chain_file = f'../../data/chain_casl_pwr.xml' nuclide_list = ['U235'] time_step = 1 total_independent_steps = 3 model, fuel, water, materials = model() # First depletion step with transport op = openmc.deplete.CoupledOperator(model, chain_file) integrator = openmc.deplete.PredictorIntegrator( op, [1], power, timestep_units = 'd') integrator.integrate() # Depletion steps without transport for i in total_independent_steps: previous_results = openmc.deplete.Results('depletion_results.h5') micro_xs = openmc.deplete.MicroXS.from_model(model, fuel, chain_file) operator = openmc.deplete.IndependentOperator(fuel, micro_xs, chain_file, prev_results=previous_results) integrator = openmc.deplete.PredictorIntegrator( op, [1], power, timestep_units = 'd') integrator.integrate() ``` ---
**Author:** ![Shimwell](https://yyz2.discourse-cdn.com/free1/user_avatar/openmc.discourse.group/shimwell/32/3876_2.png) [@Shimwell](https://openmc.discourse.group/u/Shimwell)\ **Post date:** [June 13, 2023, 8:29am UTC](https://openmc.discourse.group/t/openmc-independent-depletion-operator-split-time-steps/3091/2 "2023-06-13T08:29:55Z")
Hi LukeSeifert Thanks for posting this, if I understand correctly would removing that for loop help? I have a more linear example [here](https://github.com/fusion-energy/neutronics-workshop/pull/212/files) which calls these methods in this order and I don’t make use of the `prev_results` argument. openmc.deplete.MicroXS.from\_model openmc.deplete.IndependentOperator openmc.deplete.PredictorIntegrator Also just to note this part of openmc is getting some attention and has had a few improvements in the deveplo branch that might be of interest [pr2540](https://github.com/openmc-dev/openmc/pull/2540), [PR2539](https://github.com/openmc-dev/openmc/pull/2539) and [PR2559](https://github.com/openmc-dev/openmc/pull/2559) ---
**Author:** ![LukeSeifert](https://avatars.discourse-cdn.com/v4/letter/l/50afbb/32.png) [@LukeSeifert](https://openmc.discourse.group/u/LukeSeifert)\ **Post date:** [June 13, 2023, 4:52pm UTC](https://openmc.discourse.group/t/openmc-independent-depletion-operator-split-time-steps/3091/3 "2023-06-13T16:52:28Z")
Hi Shimwell, Thanks for the response! I see now that the `microXS.from_model` function requires an OpenMC run to generate those cross sections, which is why my simulations were taking far longer than expected. So, moving the `micro_xs` variable declaration outside the loop speeds things up and requires only one additional transport simulation. It seems that `from_array` and `from_csv` for `microXS` do not require transport to be run, so I will try and get one of those to pull data from the most recent transport run. I’m not sure how easy/difficult that will be, but I will post an update here once I’ve worked on things more. ---
**Author:** ![oyardas2](https://avatars.discourse-cdn.com/v4/letter/o/8491ac/32.png) [@oyardas2](https://openmc.discourse.group/u/oyardas2)\ **Post date:** [June 14, 2023, 1:27pm UTC](https://openmc.discourse.group/t/openmc-independent-depletion-operator-split-time-steps/3091/4 "2023-06-14T13:27:21Z")
> [@LukeSeifert](#): > > the keff data was not present for the transport independent steps, so it seemed like things were running as intended. Unfortunately, the `IndependentOperator` currently does not have the ability to estimate k\_inf (we can’t really estimate k\_eff unless we do simulations with the geomerty, which would require doing a particle simulation which was what we wanted to get away from in the first place!). I had planned from the start to add it in, but I ran out of time. There is [an open issue in the OpenMC repo](https://github.com/openmc-dev/openmc/issues/2132) with some starter code if you want to take a crack at it.