Geometry error handling

General information etc.
Post Reply
Posts: 18
Joined: Tue Jan 12, 2016 11:38 am
Security question 1: No
Security question 2: 92

Geometry error handling

Post by Andy_Turner » Thu Aug 25, 2016 5:29 pm

Hi Jaakko and colleagues

A very basic question on Serpent 2 geometry error handling.

I note that, for CSG geometry:
1. if geometry has an undefined region, the simulation will abort when a neutron enters the region. The error is "Cell universe / overlap or undefined cell"
2. if geometry has an overlap, the simulation will continue.

So in the case of [2], I assume it picks the first cell it tests as being inside. The [1] error message, however suggests overlaps would also be flagged as an error. Suggest the error message is updated, if overlaps are actually OK...

Anyway, my main question...MCNP, when it encounters a geometry error (overlap or undefined region), the history is abandoned and the calculation continues until a user-specified number of histories have been abandoned in this way. It also prints the coordinates of the event causing the loss.

When working with complicated CSG geometry, such as for fusion, a small rate of lost particles are inevitable due to the fact it is generated from CAD, with surfaces that are written to some finite precision. Often where three surfaces meet can cause issues. Anyway, the ability for the user to say, actually please permit up to 1000 histories to be abandoned before terminating the calculation will be essential.

(A rendezvous and restart capability - in the case of mode failure, or wanting to extend a run - is also absolutely essential but that's another topic).

That would not be an issue of course wit h STL geometry with its implied background universe. For fusion, we would likely wish to use STL geometry. However in order to gain acceptance in this field, it would be necessary to first show favourable comparisons using CSG geometry. Perhaps an implied background option for CSG to deal with undefined regions would be equally useful.

Many thanks
- Andy Turner, CCFE

User avatar
Jaakko Leppänen
Site Admin
Posts: 2445
Joined: Thu Mar 18, 2010 10:43 pm
Security question 2: 0
Location: Espoo, Finland

Re: Geometry error handling

Post by Jaakko Leppänen » Thu Aug 25, 2016 10:50 pm

Overlaps are not detected in conventional geometries, because the cell search loop is terminated when the first cell test is passed. Even though this is not a terminating condition, it is not entirely without problems. Serpent keeps count of successful cell tests for each universe, and sorts the list accordingly. This is to push the most likely cells at the top of the list, which may speed up the calculation if the universe contains a large number of cells. With overlaps this means that the returned cell pointer depends on the order in which the cell loop is executed. So the cell that actually fills the overlapping space is not necessarily the first one listed in the input. It may depend on the random number sequence, or even change during the transport simulation. For small overlaps this is not a major problem, but it's something to be aware of.

I don't remember why the "overlap or" part was added in the error message. As you said, it doesn't make sense, but I have a feeling that in some situations an overlap may cause an unrecoverable error. At some point there were a lot of problems with boundary conditions and this may be somehow related to that. With certain options the path of escaped particles has to be stopped at the outer boundary. With delta-tracking this means that the path has to be back-traced to the boundary from virtual collisions occurring in "outside" type cells. This procedure may fail if there's an overlap in the outside cells. I think the root cause of the problem was fixed (instead of back-tracing, the point is traced forward from the previous point), but I think it's best to keep the note about the overlap just in case.

Now that users are constructing more and more complicated geometries it makes a lot of sense to add some tolerance for geometry errors. The reason why this option hasn't been available sooner is that Serpent started out as a reactor physics code, and in reactor applications the geometries are usually so simple that it's better to have the user resolve the errors instead of offering a "cheat" that may result in false results. I'll add this feature in my TODO-list.

The restart capability is trickier, because it requires storing a lot of data, i.e. a lot of changes in several subroutines. There is a sort of debug option that allows you to start the simulation from the particle history that caused the simulation to fail, but it requires some hard-coded hacks etc.

Having a background universe for everything that's not defined is probably doable. I'll add that in my TODO list.
- Jaakko

Post Reply