Volume Calculation enhancement including refactoring and real-valued scoring implementation

[vitmog]

Description

This PR is just a modification of PR #3645 reduced according to the suggestion of @GuySten: all code about the ray tracing volume estimator was removed by a single commit.

This PR:

• Implements refactoring for real-valued scorings and batch structured samples;
• Introduces the max_iterations parameter which partially fixes Volume calculation enhancements #1702;
• Fixes an error with the vol_calc regression test input which became explicit after the volume estimator's change;
• Brings the results text output format closer to the OpenMC style.

However, the number of changed lines is still quite large because the refactoring required moving code blocks from the VolumeCalculation::execute() routine to specific new ones. I think it could be useful to take a look at the full code of each variant: original and current. If the current variant seems worse than the original, then the proposed refactoring is not successful, I guess.

The implementation of the new features is quite straightforward except for the refactoring which is discussed below separately.

Details

The initial scheme of the hit estimator was intended for binary scoring only, i.e. a score could be equal just either to $0$ or $1$, and did not support the sample splitting into batches. Thus the simplified tallies were used which are represented just by two integer STL vectors per problem assumed to conform to each other. Therefore, usage of real-valued scoring required implementation of fully-fledged tallies and related MPI-structures. Also, some semantic changes have been made for refactoring of the quite large VolumeCalculation::execute() method to simplify the further extension of its functionality. Despite the significant size of changes, the original general code structure and algorithms were kept.

The switch to real-valued scoring to batches instead of the binary-valued ones required creation of the data structures for tallies and methods to work with them. In its turn, that required organization of the MPI and OpenMP data interchanges.

Of course, I would have been happy not to refactor the code, but the only alternative -- to follow the original VC-paradigm by adding several hundred more of lines right in VolumeCalculation::execute() and extending the MPI data interchange for packing diverse-type data into the vector buffers -- seemed like the worse variant. While the goal of my work was not refactoring, it is not completed -- there are still issues of improvement. Perhaps some blocks of code, like tally manipulations, could be replaced by analogs from the main part of OpenMC, but they have seemed to me not abstract enough to reuse them here right now. It could be interesting also in the context of the issue of "filtered" tallies normalization by Volume Calculation.

To simplify reviewing, I have added notes as temporary comments about relative changes starting from // TO REVIEWER: by a single commit in the rest.

@GuySten, after rethinking, I got that, probably, it is not what you expected, because the size has not decreased dramatically. It is because, on the one hand, I cannot split the refactoring keeping the full functionality at the intermediate stages, because the data structures and MPI/OpenMP-related parts are coupled tightly. On the other hand, pushing the introduced features only could require some redesign and make this PR unrelated to the main PR. Please let me know about your thoughts.

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)

[GuySten]

If you're already fixing this PR, could you also move the MPI datatype declaration and destruction to src/initialize.cpp and src/finalize.cpp in the same way the other MPI data types are declared and destroyed?

[vitmog]

No problem, I will move the MPI-related part along with the fix, but not until 12 hours from now

[vitmog]

The tests run for an artificial commit 0a9409f instead of the pushed ones. The challenge now is to know where it is located and where it came from.

[vitmog]

@GuySten I aligned the MPI-related part as it is intended and realized that it is a much more clean solution. I am sorry for the delay.

Regarding to the tests, I hope that the error will disappear on its own after this branch refresh. If not, I have the only idea to recreate the PR.

[vitmog]

@GuySten I found my mistake with a MPI type declaration and fixed it. Seemingly, such errors may cause undefined behavior, so I could not reproduce it on my machine.

Could you please run the tests again?

[vitmog]

@GuySten I have reproduced the error and fixed it. I hope now it will work.

[paulromano]

I'm planning on reviewing this PR so just putting a placeholder review for now.

[GuySten]

I've tried to clean up a bit.

I think that we have too much nesting in VolumeCalculation.
I suggest moving the NuclResult struct, the VolTally struct and the TallyDomain enum outside and wrapping all of them in a vol namespace inside the openmc namespace.

[vitmog]

@GuySten Thank you for the corrections! I had missed these points.

Regarding your issue of the structs movement, I personally do not see disadvantages of such a nesting by itself and I have to say the following:

• The CalcResults struct is reused once outside of the VolumeCalculation class for the ray tracing estimation, that is why I was used the friend option there;
• It would be an ideal solution to use standard OpenMC Tallies with Filters instead of VolTally, but I am not dived inside this area;
• The NuclCalc struct seems to be used in VolumeCalculation only (or there are some analogs in the code?).

Thus, CalcResults extraction is reasonably at least.

[GuySten]

In my opinion vol::TallyDomain::UNIVERSE or just TallyDomain::UNIVERSE is cleaner than VolumeCalculation::TallyDomain::UNIVERSE

[vitmog]

@GuySten Maybe it is right, but I would to remind that this enum class declaration is not a part of my PR and the complete refactoring even was not a goal of this PR, as I mentioned that in the description.

I prefer to concentrate on algorithms, performance, and flexibility of implementation, that is on more functional aspects of the development. In this PR, I have tried just to follow the existent style and keep the solutions to be unchanged where it did not conflict with the declared intention. Thus, if the maintainers and contributors would like to improve naming, comments, etc., I can be only grateful and I do not have any intention to interfere it.

Probably, the name VolTally is redundant in this context and can be replaced onto simple Tally. I just wanted to avoid the overlap with the existent Tally.

[GuySten]

Ok. I will open a separate PR for that.
I will let @paulromano resume the review because he asked to review this PR anyway.