When using complex geometries, the boundary condition of a cell is determined by the face closest to the cell center. However, the closest face is not uniquely determined, when the closest point on the mesh lies on an edge. This happens very frequently close to convex edges of the geometry. As a result, boundary conditions close to edges of the mesh are set inconsistently. In some cases this leads to huge disturbances in the flow field.
This merge request makes sure that if the closest point lies on an edge, always the same face is determined. Below are two screenshots of the flag field in an exemplary geometry before and after the change.
Some notes to the reviewer:
The loop that determines the handle of the half edge terminates as long as the surrounding code functions properly. Should we introduce a second fallback exit criterion? We could for instance check the number of hops or cycles around the face.
After deciding for the other face adjacent to the edge, the region is recomputed relative to the new face. Should we assert that the new distance is equal (very close to) the original minimal distance? Or should we find a way to determine the new region without recalculating the distance to the face?
- This merge request only considers edges not vertices. I think that the number of cells which are closest to a vertex is far more limited (in my cases only a single boundary cell). This one cell is always consistent with exactly one adjacent face, so no further treatment is necessary.
- In this merge request, the decision for a face is made by comparing halfedges. Alternatively, faces could be compared. On some faces, this would make all adjacent edges map to the same boundary. However, it would make the mapping less consistent for other faces (so there is no benefit). Choosing the correct face in a way that the choice is globally consistent (all adjacent edges around every face share the same boundary) seems to be a much harder problem. At the same time I do not see a practical benefit.