Open paulromano opened 4 years ago
@rockfool @bforget @liangjg Do any of you have thoughts about a longer-term solution for what to do with (n,alpha) and other non-capture reactions that do not have a threshold when using multipole data? (n,alpha) in B10 is probably the most conspicuous example, but I'm sure there are others as well.
I just have a straightforward solution like this: all the non-capture cross sections that are found in ACE or ENDF file could be fitted into wmp library. But I have no experience to estimate the additional computation burden.
@rockfool To be clear, are you proposing to fit each non-capture cross section individually, or to have a single residue that accounts for all non-capture cross sections ((n,alpha) + (n,p) + ...)? Along the same lines, an easy way to get capture correct would be to fit it specifically rather than calculate it as absorption - fission.
Personally, I prefer fitting each non-capture cross section individually if it (MT number) exists in ACE or ENDF file. And I also agree with your comment on explicit implementation of capture cross section.
One of the clear benefits of doing each non-capture cross section individually is that it makes it much easier to deal with photon production. But, it will make the implementation a bit more complicated and it's not clear what the performance implication would be.
I agree that we should find residues for each individual reaction (sub-threshold), but we should hopefully only need them when evaluating tallies. The biggest concern is the increased memory costs, but they shouldn’t need any extra Faddeeva evaluations.
I met with similar issue as well. Take an example for B-10 (n, alpha) reaction rate at BOC of VERA 2E testing case, This will cause significantly increased B-11 production in the depletion. This is because the absorption is considered as gamma in current wmp implementation. No (n, alpha) cross section can be explicitely expressed by poles and residues.
Originally posted by @rockfool in https://github.com/openmc-dev/openmc/issues/1697#issuecomment-713566425