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:
Thank you,
Hui
The run_depletion.py (3.9 KB) is slightly modified from the pin cell depletion example and using：
@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
- What happens with the 0.12.0 hotfix release?
- 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
Dear @andrewjohnson,
Thank you for your response.
The released versions in Releases · openmc-dev/openmc · GitHub are used and the results are summarized as:
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
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
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
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
- Build an arbitrary openmc version
- Re-install the python library
- Re-run your problem for a given version
- 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.
@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
