search

SCOREC / core

parallel finite element unstructured meshes
Other
179 stars 63 forks source link

MA: snapping after refinement (1) can't snap certain stacks and (2) produces dagger elements #77

Open mrasquin opened 7 years ago

mrasquin commented 7 years ago

Two additional issues with snapping are illustrated in this ticket. These issues are different from #73. The same geometry as in ticket #73 is used (subchannel) but matched faces have been removed from the initial mesh (even in the streamwise direction) the for the sake of testing snapping.

The initial mesh is illustrated in the andfthenst figure. Notice that the quarter cylindrical face is meshed with either 3 elements along its small circular edge (front) or 4 elements (back). initial_mesh_view1

The next three figures illustrate the issues (see the red arrows) after one and two uniform refinements (respectively UR1 – top and UR2 - bottom) with snapping on and off (respectively left and right).

1) First issue: all vertices get snapped during UR1 (top right) but some were not snapped after UR2. This is in particular visible in the region of the cylindrical face where the initial mesh resolution transitions from 3 to 4 elements.

2) Second issue: on the inlet face, UR2 with snapping on generates distorted elements (bottom right). In particular some vertices interior to the original elements get duplicated, leading to extra dagger elements.

ur_mesh_view1

Zoom 1 on the inlet face: initial_mesh_view2 ur_mesh_view2

Zoom 2 on the inlet face ur_mesh_view3

I have been able to reproduce these issues with two recursive UR in a single Chef run, as well as with two successive Chef runs with a single UR each so recursive UR is not the root cause here.

To reproduce the issue, I have uploaded a test case named ~/subchannel_0way.tgz at both Colorado and SCOREC.

Note that if the resolution of the initial mesh is refined by a factor 2, both snapping issues seem to be avoided. This means in practice that the current algorithm requires a minimum resolution for vertex snapping during mesh adaptation, even on simple geometries such as a cylindrical face.

Thanks for your help.

Best regards,

Michel

mortezah commented 7 years ago

It is true that cylindrical faces are simple geometries but what makes the snapping in this example to fail, is the fact that you have a non-convex domain. As @mrasquin mentioned one way around this is to start with an initially fine mesh, but that is not always ideal.

I have been working on this issue a while back and added a feature to deal with non-convex geometries, known as First-Problem-Plane. This feature is not active by default. To enable this feature you should use -DENABLE_FPP=ON. This should resolve the issue number 1.

mrasquin commented 7 years ago

Thanks. I will give a try fo FPP and let you know.

mrasquin commented 7 years ago

Here is an update on issue 1.

FPP seems to improve the results but it does not completely fix issue 1. See the attached pictures highlighting the suchannel testcase with two successive uniform refinements (UR) with no FPP (top) and with FPP (bottom)

fpp1 fpp2

The top pictures (no FPP) show that snapping failed for both successive uniform refinements. Some vertices which were not snapped during the first UR resulted in the largest aggregates of unsnapped vertices covering 4 rows of adapted elements. Smaller aggregates of unsnapped verticies covering only two rows of elements are also present, which suggests that new vertices could not be snapped during the second UR although they could be snapped during the first UR.

The bottom pictures (with FPP) show only smaller aggregates of unsnapped vertices covering at most two rows of adapted elements. This suggests snapping for the first UR was successful for all vertices but not for the second UR.

This raises a couple of additional questions:

1) Do you know what could cause FPP to succeed for the first UR and fail for the second UR? The subchannel seems at least to be a good test case to improve further the FPP robustness.

2) FPP is designed to fix snapping for non-convex faces but is there any potential conflict to use FPP for a mesh with a mixture of convex and non-convex faces? In other words, FPP is intended to improve snapping for non-convex faces but can it degrade snapping for convex faces?

3) Would you have any estimation about the prospect for issue 2?

Thank you for your help!