Simulation file orders

I am running a depletion for pincell, but the code produces simulation files in the following order:
Creating state point statepoint.500.h5…

=======================> TIMING STATISTICS <=======================

Total time for initialization = 1.9750e+00 seconds
Reading cross sections = 1.9009e+00 seconds
Total time in simulation = 1.3405e+03 seconds
Time in transport only = 1.3379e+03 seconds
Time in inactive batches = 3.9147e+00 seconds
Time in active batches = 1.3366e+03 seconds
Time synchronizing fission bank = 9.2673e-02 seconds
Sampling source sites = 8.3004e-02 seconds
SEND/RECV source sites = 9.2869e-03 seconds
Time accumulating tallies = 2.2916e+00 seconds
Time writing statepoints = 1.2069e-01 seconds
Total time for finalization = 3.7025e-03 seconds
Total time elapsed = 1.3432e+03 seconds
Calculation Rate (inactive) = 25544.5 particles/second
Calculation Rate (active) = 673.351 particles/second

============================> RESULTS <============================

k-effective (Collision) = 1.16213 +/- 0.00135
k-effective (Track-length) = 1.16254 +/- 0.00150
k-effective (Absorption) = 1.16290 +/- 0.00113
Combined k-effective = 1.16269 +/- 0.00100
Leakage Fraction = 0.00000 +/- 0.00000

Creating state point openmc_simulation_n0.h5…
Maximum neutron transport energy: 20000000 eV for U235
Initializing source particles…

Creating state point statepoint.500.h5…

=======================> TIMING STATISTICS <=======================

Total time for initialization = 0.0000e+00 seconds
Reading cross sections = 0.0000e+00 seconds
Total time in simulation = 1.2887e+03 seconds
Time in transport only = 1.2883e+03 seconds
Time in inactive batches = 1.1053e+02 seconds
Time in active batches = 1.1782e+03 seconds
Time synchronizing fission bank = 1.0325e-01 seconds
Sampling source sites = 9.4158e-02 seconds
SEND/RECV source sites = 8.6428e-03 seconds
Time accumulating tallies = 1.4241e-01 seconds
Time writing statepoints = 5.8090e-02 seconds
Total time for finalization = 2.8803e-03 seconds
Total time elapsed = 1.2929e+03 seconds
Calculation Rate (inactive) = 904.721 particles/second
Calculation Rate (active) = 763.889 particles/second

============================> RESULTS <============================

k-effective (Collision) = 1.13129 +/- 0.00131
k-effective (Track-length) = 1.12995 +/- 0.00156
k-effective (Absorption) = 1.13100 +/- 0.00119
Combined k-effective = 1.13103 +/- 0.00101
Leakage Fraction = 0.00000 +/- 0.00000

[openmc.deplete] t=516967.6083773616 s, dt=1550902.825132085 s, source=16378
Maximum neutron transport energy: 20000000 eV for U235
Initializing source particles…
then
Creating state point openmc_simulation_n0.h5…
then
Creating state point statepoint.500.h5… it always overwrites the t statepoint.500.h5.

Shoudn’t be in order of point openmc_simulation_nx.h5…
op = openmc.deplete.CoupledOperator(model, chain_file)
integrator = openmc.deplete.CECMIntegrator(op, timestep_deltas, power, timestep_units=“d”)

Hi, What is your specific question? The statepoint.500 is the statepoint for each transport step and is used by the program to track that information before the depletion step is run afterwards. For example, if you’re using the predictor integrator for 2 depletion steps it will run 1 transport > 1 depletion > 2nd transport > 2nd depletion > final transport. You don’t really need to the information within these statepoints as you can gather it from other files. The statepoint files n0, n1… nx are the values at the end of the depletion step and you might want to gather information from them so the program saves these.

1 Like

When I look at other example codes related to depletion, I notice that after the statepoint file is generated, an openmc_simulation_ file is also typically produced. However, in my case, this doesn’t happen for every depletion iteration. Instead, the following sequence continues:

Creating state point statepoint.500.h5…

=======================> TIMING STATISTICS <=======================

Total time for initialization = 0.0000e+00 seconds
Reading cross sections = 0.0000e+00 seconds
Total time in simulation = 1.2651e+03 seconds
Time in transport only = 1.2646e+03 seconds
Time in inactive batches = 1.0787e+02 seconds
Time in active batches = 1.1572e+03 seconds
Time synchronizing fission bank = 1.0080e-01 seconds
Sampling source sites = 9.1983e-02 seconds
SEND/RECV source sites = 8.3837e-03 seconds
Time accumulating tallies = 1.9426e-01 seconds
Time writing statepoints = 3.6670e-02 seconds
Total time for finalization = 2.5327e-03 seconds
Total time elapsed = 1.2663e+03 seconds
Calculation Rate (inactive) = 927.022 particles/second
Calculation Rate (active) = 777.747 particles/second

============================> RESULTS <============================

k-effective (Collision) = 1.10408 +/- 0.00126
k-effective (Track-length) = 1.10407 +/- 0.00144
k-effective (Absorption) = 1.10379 +/- 0.00110
Combined k-effective = 1.10390 +/- 0.00096
Leakage Fraction = 0.00000 +/- 0.00000

[openmc.deplete] t=15509028.251320846 s, dt=10339352.167547235 s, source=16378
Maximum neutron transport energy: 20000000 eV for U235
Initializing source particles…
At this stage, no simulation file is created—only the statepoint file is overwritten. Then, at a later point, both the statepoint.500.h5 and an openmc_simulation_ file are produced. My question is: is there any problem, or is this just how it works in my case?

Hai Aydemiralisir, welcome to the openmc community.
From what I know, openmc depletion will produce

  • summary.h5 summarize your model,
  • h5 for each depletion step where your defined tally being saved for each step, which I think were came from processed statepoint.h5 and renamed into specific step, i.e:
    openmc_simulation_n0.h5
    openmc_simulation_n1.h5
  • and a depletion_results.h5 which summarize your depletion calculation.

So, the calculated tally results for your model (if any) can be access through the openmc_simulation_n_.h5, and the parameter related to depletion results can be access from the depletion results, such as depleteable material composition, mass, activity, some reaction rate, so on. I think you can discover it.

But I also noticed that the previous version of openmc (0.14.0/1) didn’t report openmc_simulation_n.h5 properly, but it only happened when I use stochastic implementation of depletion integrator, such as SICELI and SILEQI. Since I am not good at coding, so I just raise the problem to the github last year.

1 Like