Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introducing partial reaction identifiers for summation reactions #14

Merged
merged 7 commits into from
Nov 8, 2024

Conversation

whaeck
Copy link
Member

@whaeck whaeck commented Aug 16, 2024

This adds partial reaction identifiers for partial reactions. This also introduces an electro-atomic eleastic deficit reaction to account for the fact that electro-atomic data do not define all partials for elastic. Logic was added in the endf reaction identifiers to detect these cases.

@whaeck whaeck requested a review from joewpeterson September 9, 2024 18:53
Base automatically changed from feature/distributions-part8 to develop October 19, 2024 14:42
Copy link

@cjosey cjosey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All looks reasonable. Couple of design questions for the future.

@@ -78,13 +79,61 @@ namespace endf {
875, 876, 877, 878, 879, 880, 881, 882, 883, 884,
885, 886, 887, 888, 889, 890, 891
};
inline static const std::map< int, std::vector< int > > partials_ = {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[future design question]

How would you handle a situation in which a user requests MT=1 and the file has both MT=4 and what MT=4 sums from?

Is there a way of defining priority, or do you intend to add a canonical summation rule? (e.g., sum from 1000 downward, replacing anything precalculated).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still have to add these partials. The only reason I haven't is because I'm not handling incident neutron data properly yet.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I fixed the MT1 situation, see fix/review-part2. We just loop over all available MTs and select the ones that are primary.

case 106 : return material.hasSection( 3, 750 ) ? true : false;
case 107 : return material.hasSection( 3, 800 ) ? true : false;
case 16 : return material.hasSection( 3, 875 ) ? true : false;
case 18 : return material.hasSection( 3, 19 ) ? true : false;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[future design question]

I just learned about MF=10 MT=18. It seems a lot of tools just go ahead and "lower" this into an equivalent MF=3 MT=18, without all the fission-specific blocks. Thoughts on how to approach?

Copy link
Member Author

@whaeck whaeck Nov 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Subactinide fission (MF10 MT18) was added a few years ago. The data was put in MF10 and not MF3 for the simple reason that ENDF rules require certains types of information to be present for fission that were not available for subactinide fission. You know, things like nubar, fission energy release components, etc.

I think that it should have been put in MF3 as a cross section and that the rules should have been updated instead of just dumping the data in MF10. These special exceptions make no sense to me. This can be handled like any other reaction. Other notorious offenders of the "we have to do something special for this instead of doing things proeprly" are the electron and photoatomic data.

@whaeck whaeck merged commit dd02953 into develop Nov 8, 2024
8 checks passed
@whaeck whaeck deleted the refactor/reaction branch November 8, 2024 23:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants