BOL keff disagreement: transport vs depletion

User Support
1

Dear All,

I’m switching to 13.0 dev. I have trouble with the depletion. Why the keff at BOL calculated by the direct transport is different from that by the depletion if a “complicated” chain is used? Please see the following table:

image

Thank you,

Hui

The run_depletion.py (3.9 KB) is slightly modified from the pin cell depletion example and using：

2

@maximeguo This is very interesting. My first guess would be the introduction of the “trace” nuclides needed to account for reaction rates in isotopes that don’t exist at beginning of life. But, if they are truly introduced in trace amounts, we should not expect to see this. And we don’t see the same difference using 0.12.0-dev.

For reproducing purposes, it doesn’t look like the 0.12.0-dev commit you’ve provided is correct. It leads to a 404 error on github and doesn’t appear in my local repository - https://github.com/openmc-dev/openmc/blob/78a92ecb08513d5a9a3365e607bb365eb59a2fff

Two recommendations that could yield more information

  1. What happens with the 0.12.0 hotfix release?
  2. What happens when you create the operator with a lower dilute_initial for the larger chain? The current default is 1e3 atoms/cc which should not make this large of a difference.

Drew

3

Dear @andrewjohnson,

Thank you for your response.

The released versions in Releases · openmc-dev/openmc · GitHub are used and the results are summarized as:

version12
version12939×784 29.7 KB

The version 0.12.dev is maked in May 2020 that is between version 0.11.0 and 0.12.0.
A smaller dilute_initial make no difference.

Best regards,

Hui

4

Very interesting. I’m confused as to why your 0.12.0-dev doesn’t have this issue, but each 0.12.x release does not.

But that’s not the issue at hand here.

I’ll do some investigating and see what comes up.

Drew

5

For the 0.12.0-dev, there is no modification on my part. This 0.12.0-dev is between released version 0.11.0 and 0.12.0. I can push/upload it if anyone needs it.

In my simulations, BOL keff disagreement appears in >0.12.0 released version. I worried there could be errors in my usage? Does this disagreement appear in someone else’s simulations?

Hui

6

Does your 0.12.0-dev commit not exist in the upstream github? If you can provide this it will help reproducing. But you’ve also pointed out this exists for later versions like b62708f911d05e269e5c3083287e70d050ed35f9 which does exist in the 0.13.0-dev stream.

I have not been able to commit substantial time to reproducing but this is very much on my mind. I hope to find more time in a few weeks.

One way to dial in where the regression happened would be to perform a git-bisect - Git - git-bisect Documentation where a script is prepared to

  1. Build an arbitrary openmc version
  2. Re-install the python library
  3. Re-run your problem for a given version
  4. Compare the actual BOL keff under depletion to that used in steady state

By setting up a git bisect such that 0.11.0 is termed a “good” commit and b62708f911d05e269e5c3083287e70d050ed35f9 is a “bad” commit, git will automatically search through the commit log, running this script on each commit looking for the one that introduced the regression. Care should be taken to handle the associated uncertainty on k as you’re unlikely to retrieve a value that is exactly equal to floating point precision.

I’ve been trying to set up such a bisect to run as a github workflow to leverage their computing resources as I don’t have a lot on my end.

7

@andrewjohnson Thank you for your help. git-bisect is a useful tool.
I have no idea why ”0.13.0-dev Git SHA1 | b62708f911d05e269e5c3083287e70d050ed35f9” and “0.12.0-dev Git SHA1 | 78a92ecb08513d5a9a3365e607bb365eb59a2fff” do not exist in the stream. I have downloaded them and built without modifications.
To eliminate ambiguity, the disagreement at BOL K-eff does not exist in released version 0.11.0 while appear in released version 0.12.0.
The git-bisect is shown as below:

################################################################################

$git checkout v0.12.0
$git bisect start
$git bisect bad
$git bisect good v0.11.0
Bisecting: 677 revisions left to test after this (roughly 9 steps)
[030a5873257d926eb3e02dd51ebe1ce062eac7a0] Get the source_dlopen test working
*****Rebuild OpenMC and run pincelle depletion example, the BOL k-eff:
*****Combined k-effective = 1.16347 +/- 0.00029
$ git bisect good
Bisecting: 380 revisions left to test after this (roughly 8 steps)
[571ed3b6ab449e555fc9c8452106425d26b19bd3] Merge pull request #1536 from paulromano/model-run-fix
*****Rebuild OpenMC and run pincelle depletion example, the BOL k-eff:
*****Combined k-effective = 1.16347 +/- 0.00029
$ git bisect good
Bisecting: 190 revisions left to test after this (roughly 8 steps)
[128faa49b03fd633b3bf858d8c844a655261d642] Add particle_type_to_str and str_to_particle_type functions
*****Rebuild OpenMC and run pincelle depletion example, the BOL k-eff:
*****Combined k-effective = 1.16347 +/- 0.00029
$ git bisect good
Bisecting: 95 revisions left to test after this (roughly 7 steps)
[59526fb5dd5dbbf692fb992cd33d6dd7d1d557b1] Small change
*****Rebuild OpenMC and run pincelle depletion example, the BOL k-eff:
*****Combined k-effective = 1.16347 +/- 0.00029
$ git bisect good
Bisecting: 47 revisions left to test after this (roughly 6 steps)
[151724b14be4ecd1eaadfbb8af75652f11bca76e] Disabling blas/lapack in MOAB build.
*****Rebuild OpenMC and run pincelle depletion example, the BOL k-eff:
*****Combined k-effective = 1.16099 +/- 0.00026
$ git bisect bad
Bisecting: 23 revisions left to test after this (roughly 5 steps)
[ea9ff2280570f527d8c71ac8d456be7d07c74080] Change data::elements to a vector of unique_ptr
*****Rebuild OpenMC and run pincelle depletion example, the BOL k-eff:
*****Combined k-effective = 1.16099 +/- 0.00026
$git bisect bad
Bisecting: 11 revisions left to test after this (roughly 4 steps)
[5e8c7a55fec1d805fbfb82d0f593c2a2b7988fa6] Provide better error message if missing FPY parent is not in chain
*****Rebuild OpenMC and run pincelle depletion example, the BOL k-eff:
*****Combined k-effective = 1.16347 +/- 0.00029
$ git bisect good
Bisecting: 5 revisions left to test after this (roughly 3 steps)
[9c5ada6dd0045d727c08a36b02345034307f7b85] Change Nuclide/PhotonInteraction constructor to not take index

*****Rebuild OpenMC and run pincelle depletion example, the BOL k-eff:
*****Combined k-effective = 1.16347 +/- 0.00029
$ git bisect good
Bisecting: 2 revisions left to test after this (roughly 2 steps)
[2e29ffacfe1d04ce7581d04b4a35f5c5ee096c00] Use openmc_load_nuclide consistently
*****Rebuild OpenMC and run pincelle depletion example, the BOL k-eff:
*****Combined k-effective = 1.16099 +/- 0.00026
$git bisect bad
Bisecting: 0 revisions left to test after this (roughly 1 step)
[e57916896934ed0530c41f06af11df66db9a4240] Calculate min/max energies during simulation_init
*****Rebuild OpenMC and run pincelle depletion example, the BOL k-eff:
*****Combined k-effective = 1.16099 +/- 0.00026
$ git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[6aed01783761517f68a3724f2731c89578574c8f] Call Nuclide::init_grid during simulation_init
*****Rebuild OpenMC and run pincelle depletion example, the BOL k-eff:
*****Combined k-effective = 1.16347 +/- 0.00029
$ git bisect good
e57916896934ed0530c41f06af11df66db9a4240 is the first bad commit
commit e57916896934ed0530c41f06af11df66db9a4240
Author: Paul Romano paul.k.romano@gmail.com
Date: Wed Jun 17 15:49:20 2020 -0500

Calculate min/max energies during simulation_init

include/openmc/simulation.h | 3 ++
src/cross_sections.cpp | 51 ----------------------------------
src/simulation.cpp | 68 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 71 insertions(+), 51 deletions(-)

################################################################################

I hope this could be useful to find the potential error. If there’s anything else I can do to help, please feel free to contact me.

Best regards,

Hui

8

I believe the cause of this issue has now been identified.

During depletion calculations, OpenMC adds all nuclides in the depletion chain that have available neutron cross-section data to the transport calculation at very small concentrations. After commit e57916896934ed0530c41f06af11df66db9a4240, the upper neutron transport energy is determined as the minimum upper energy bound among all loaded nuclide cross-section datasets.

In this example, the full depletion chain contains Be7, whose neutron cross-section data extend only up to 8.1 MeV. Therefore, when the full chain is used, the maximum neutron transport energy is limited to:

Maximum neutron transport energy: 8100000 eV for Be7

This changes the transport calculation and consequently affects the calculated keff.

In contrast, when the simplified depletion chain is used, the output is:

Maximum neutron transport energy: 20000000 eV for Na23

Thus, the difference between the transport and depletion results is not caused by the very small Be7 concentration itself, but by Be7 limiting the global neutron transport energy range to 8.1 MeV.

I suggest paying close attention to the following message in the OpenMC output:

Maximum neutron transport energy: ...

It can help identify whether a nuclide introduced through the depletion chain is unintentionally restricting the transport energy range.

The following function can also be used to check which nuclides in the depletion chain have neutron cross-section data with an upper energy limit below 20 MeV:

test_max_energy.py (1.5 KB)