Here’s the XML I’ve been using for these tests. It’s about as simple as I can make it (no TRISO) where I know the problem is still occurring.
settings.xml (593 Bytes)
geometry.xml (200.7 KB)
materials.xml (5.7 KB)
I recompiled OpenMC to try and print a bit more info right before the fatal error in the overlap check and got some interesting info. According to the error message, the particle believes it’s in cell 670 and has detected that cell 671 “overlaps” with 670. Interestingly, the global coordinate system position and direction are as follows
Current global coordinate position r=(18.6115, 228.396, 70.5)
Current global coordinate direction u=(-0.79841, 0.635684, -0.0776792)
I’ve gone to this location in the plotter (hovering with my cursor) which you can see in the bottom right corner)
In the bottom left corner, you can see that this position is actually in cell 671! For some reason, OpenMC thinks it’s in cell 670 during the overlap check (from
model::cells[p.coord(j).cell()]->id_) when it actually is not.
I believe this suggests that at some point, an event has caused the particle to think it’s in a different cell than it actually is in, causing an “artificial” overlap. I’m currently testing openmc -g again to see if this singular event is the only overlap by removing the fatal_error and letting the particle continue onwards to see if each subsequent event is considered an overlap or if it’s just this one time.