Kinetics parameters using Iterated Fission Probability

[JoffreyDorville]

Description

Calculation of adjoint-weighted kinetics parameters (effective generation time and effective delayed neutron fraction) using the Iterated Fission Probability (IFP) method.

This implementation uses the same approach as the IFP implementation in Serpent 2 documented in [1].

To generate results for both effective generation time and effective delayed neutron fraction, IFP settings need to be set:

settings.iterated_fission_probability = {
    "parameter": "both",
    "n_generation": 5
}

and a specific tally has to be set:

tally = openmc.Tally(name="ifp-scores")
tally.scores = [
    "ifp-time-numerator",
    "ifp-beta-numerator",
    "ifp-denominator"
]

Testing is still in progress. I will update the draft to PR once I have finished the remaining tests.

References

[1] J. Leppänen, M. Aufiero, E. Fridman, R. Rachamin, and S. van der Marck, “Calculation of effective point kinetics parameters in the Serpent 2 Monte Carlo code,” Annals of Nuclear Energy, vol. 65, pp. 272–279, Mar. 2014, doi:10.1016/j.anucene.2013.10.032

Checklist

• I have performed a self-review of my own code
• I have run clang-format (version 15) on any C++ source files (if applicable)
• I have followed the style guidelines for Python source files (if applicable)
• I have made corresponding changes to the documentation (if applicable)
• I have added tests that prove my fix is effective or that my feature works (if applicable)

[zhangzeqin1997]

I have tested this feature, and everything works well at the moment. I would like to inquire if there are any plans to add output for the individual delayed neutron group fractions and decay constants, similar to how it is done in MCNP.

[paulromano]

Thanks for this PR @JoffreyDorville and apologies it's taken me some time to get you some feedback on this. Here is a set of initial comments. In addition to the line comments/questions below, I'll add two other comments:

• It would be nice if some of the logic/functionality here could be isolated into its own source file (ifp.h/ifp.cpp).
• I see quite a few blocks of code that seem repeated (for example, in bank.cpp and eigenvalue.cpp). If there's any way to encapsulate them in a function so that they don't need to be repeated, that would help reduce the total number of lines.

[paulromano]

I see right now this is determined based on user input in the Settings object. I think it would be better if this was determined automatically based on what scores show up in tallies (i.e., if the user specified "ifp-time-numerator" as a score, then activate the logic to collect the information needed accordingly), which leaves less for the user to think about.

[paulromano]

This will result in memory allocation in the middle of a particle's transport, which is never desirable 1) because it can degrade threading efficiency and 2) it doesn't fit GPU programming models well. Is there any way we can avoid the memory allocation?

[paulromano]

Given that lifetime looks identical to time here, can you explain what the difference between the two is?