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.

[paulromano]

Since this test is literally just running OpenMC to make sure it completes, I don't think it really belongs in regression_tests. Can you 1) move it to the unit_tests directory and 2) construct the model using the Python API since it is simple enough? Also, is there any way we can get the .h5m file to be smaller? 57 kB is not huge but more than I would normally like to add for a new test.

[pshriwise]

Fair point. It does check for a regression of this particular pathology with DAGMC geometry, but you're right it doesn't really fit into the regression test suite. I've moved it into the unit tests under weight windows.

I'll think on how to reduce the size of the .h5m file but it's already about as minimal as it can get -- 3 cubes (8 vertices, 12 triangles each) with one material assignment. I could remove one of the cubes but I doubt it would change the file size substantially. Another option might be to adapt one of the other DAGMC models in the repo. However, the key to this model is that several surfaces are very close to each other, with the outer surface set with a vacuum boundary condition. The current set of DAGMC models in the repo don't meet that condition.

[paulromano]

Thanks @pshriwise!