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 tests again?