Fix Weight Window Infinite Loop Bug

[jtramm]

The Problem

I have been working a lot with weight windows recently, and ran into a case where an infinite loop was triggering on a JET-like model. The particle was getting stuck at the same place as in PR #3423 (during the mesh tally bin crossing evaluation). However, I was noticing that the problem only seemed to occur when weight windows were turned on.

After (lengthy!) investigations, I found that the issue stemmed from particles that split right after crossing a surface (in this particular case, it was a Z toroid). The banked particles don't know that they've just collided with the surface, so once revived were registering a distance to surface of 1e-14 with the surface they just crossed. This seems to have set in motion the conditions for the infinite loop.

The Fix

To fix this I simply add in a new surface field to the SourceSite object. This field is always set to its normal default of SURFACE_NONE, except when the site is generated via particle splitting. In that case, it inherits the surface() from the parent particle at the time the particle copy is created. In my testing, this seems to work great.

I'm open to other ideas to fix this.

Checklist

• [x] I have performed a self-review of my own code
• [x] I have run clang-format (version 15) on any C++ source files (if applicable)
• [x] I have followed the style guidelines for Python source files (if applicable)
• [x] 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]

Maybe you could move the particle forward a TINY_BIT after it crosses the surface and then split it?

[jtramm]

That would help, but personally I think it is perhaps better to stay consistent with the ray tracing policy already in play (i.e., keeping track of what surface was previously intersected).

[jtramm]

@paulromano I had thought about that, but it appears that the surf_id field is used to store a specific surface id (as in the user provided ID for a surface from the XML input) when generating items from a surface source. Conversely, the item we are trying to store is akin to the GeometryState::surface_ field, which is listed as being "Surface token for the surface that the particle is currently on". I'm not sure I fully understand the contexts here, but my thinking was that a "token" was more akin to a sense (e.g., positive or negative), rather than being related to the user provided surface ID. Let me know if I'm understanding this wrong though!

[paulromano]

@jtramm I just made an update to use the surf_id member; the only change needed is to store the sense by making it positive/negative. Can you give this a try to see if it still works to solve the infinite loop bug?

[jtramm]

Thanks for taking a look! The proposed change @paulromano doesn't seem to work -- I'm getting the hang again.

[paulromano]

@jtramm Sorry I did have an indexing bug in there. That should be fixed now -- can you try one more time?

[jtramm]

This is working again now -- thanks for the assist on this @paulromano!