Closed craffael closed 3 years ago
The "strange" refinemen pattern probably arises from a 2-stage longest edge bisection in response to hanging nodes. Since the algorithm never reverts local refinements, this is inevitable. It also complies with the specification of longest-edge bisection.
I see.
Just for your information: after a few refinement steps one ends up with quite ill-conditioned triangles:
Which example/test code generates this sequence of meshes. I will take a look and try to understand how such bad triangles can emerge.
It's the file examples/fe/hp_fem_L_shape/main.cc
. Tip: if paraview crashes or shows wiggly mesh lines, set the degree of the vtk output to 1 on line 133 of main.cc
I have found the problem. An exotic case of bisection refinement (rp_quadsetc) is triggered when all three edges of a triangle are marked.
Corrected the local refinemen algorithm in mesh_hierarchy.cc
.
Created a pull request.
While I was working on the hp-fem example, I noticed that MeshHierarchy refines triangles in an unexpected way when all three edges are marked for refinement.
E.g. this triangle
is refined to
Interestingly this only happens when we do local refinement. If we refine the mesh globally, we get the expected refinement for this triangle:
To reproduce the problem, just run the example in
examples/fe/hp_fem_L_shape
(currently only available in branchconvergencestudies
) and check the generated vtk files.