Reset DAGMC history when reviving from source.

[pshriwise]

Description

A particle's DAGMC history should be reset when particles are being sourced from the secondary bank. A history from a previous particle can cause incorrect intersection determination in DAGMC as any previously intersected faces in the history at the time of sourcing from the secondary bank may cause surface intersections to be erroneously ignored.

A hypothetical related to #3600 would be the following:

1. A primary particle undergoes splitting near a vacuum boundary (or exterior surface of the DAGMC model.
2. As its next event, the primary particle then exits the problem through the boundary . During this process the DAGMC triangle through which it exits is stored in the particle's DAGMC history.
3. A new particle is sourced from the secondary bank with the primary particles position at the split and direction. As a result of this identical position and direction the same triangle on the vacuum boundary is struck but ignored by nature of being in the particle's DAGMC history. Thus, an intersection is not found and the particle is considered lost.

This probably hasn't occurred very often because more splitting occurs in materials with higher collision density and collision events reset the particle history. That said, a MWE wasn't terribly difficult to construct and I'm glad to be able to address the problem.

Fixes #3600

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)

[connoramoreno]

Happy to report that this fixed my issue, including on a rebased branch with transformation BC support (#3402). Tally results seem to agree within uncertainty compared to what I saw previously. The minor discrepancy may be due to new features/bug fixes with the way weights are now handled in conjunction with source sampling. Thanks for this quick fix @pshriwise!

[gonuke]

This looks like it definitely makes sense and should fix the problem.

Thanks for the quick solution @pshriwise

[pshriwise]

I've been working with @connoramoreno on adding a minimal test using cube geometries designed to demonstrate this failure mode so we understand it well and don't have a regression. And I'd like to include it here.

[pshriwise]

To provide a quick update on this. The CI failure seen for 2031255 is caused by an issue with how DAGMC performs volume checks when configured to use the MOAB GeomQueryTool (the default). It turns out it is specific to models with axis-aligned nested cubes due to the resulting coincident bounding boxes and how hit tolerances are handled deep in the ray tracer -- what a model to select for this purpose! 😞 But it was a minimal model (mainly in terms of memory/no. of triangles) to add to the repo.

For clarity, this doesn't happen when using DAGMC w/ double-down enabled due to differences in the way it handles point in volume ray queries. This is why those utilizing this branch, including myself, likely haven't encountered this problem.

An easy solution for us to avoid this issue was to rotate the cubes about 45 degrees about each axis to ensure that volume bounding box faces aren't coincident in which case this issue doesn't arise. This should help us isolate the test case to address only the bug at hand here and not be affected by this issue, which will be addressed (and tested) in that project instead.

More info on the MOAB raytracer issue I'm referring to and the proposed fix here.