I am encountering behavior that I believe is intended but would like to confirm and understand the rationale behind it. It pertains to the delayed_fraction parameters when using a nuclide filter.
1. OpenMC Version:
I am using OpenMC version 0.15.3
2. Problem Description:
I have a material containing multiple fissile nuclides (U235, U238, Pu239, etc.) . When I run a tally with a nuclide filter to track the Iterated Fission Probability(IFP) for each nuclide, the reported values for IFP delayed fraction numerator and IFP common denominator are identical for every fissile nuclide, including their uncertainties.
I’m not a developer but I am a very frequent user of the IFP in different codes. I think this type of filter is not implemented for this tally, in the same way an energy filter can be quite complex.
As this method is, in some way, a recursive method (Fig. 1 from [1]) when you calculate the parameter in, for instance, Cycle 2 the code is actually summing the lifetimes/delayed neutrons from g=2 weighting these parameters with the descendants in g=4 (equivalent to weight with the adjoint flux). It means that in g=4 you have to know the nuclide which interacted in g=2.
In the OpenMC framework you have L latent generations, so in batch N the code is summing lifetimes/delayed neutrons from neutrons in batch N-L. It makes difficult the implementation of filters because you have to study the nucleus with which the neutron interacted L generations before (so more memory has to be used to save this information).
I don’t know if the fact that the filter does not work is intentional, but it makes sense. The code can become very expensive in terms of memory usage.
[1] G. Truchet, P. Leconte, A. Santamarina, E. Brun, F. Damian, A. Zoia. “Computing adjoint-weighted kinetics parameters in TRIPOLI-4 by the Iterated Fission Probability method”Annals of Nuclear Energy 85 (2015) 17–26.
Thank you so much for taking the time to provide such a detailed and insightful explanation. This is incredibly helpful for my understanding.I will definitely take some time to study the [Truchet et al. (2015)] paper more closely to deepen my knowledge of the underlying method.
