meshadaptation/pragmatic

Boundary coarsening too aggressive

Opened this issue · 11 comments

croci commented

If the mesh is coarsened significantly pragmatic adapt coarsens the boundary too aggressively so that entire boundary elements disappear. See pictures attached: original.png
is the original mesh, adapt.png was obtained using adapt and coarsen.png with coarsen (this behaviour is much worse with coarsen). I apologise, but I am not allowed to share the actual meshes. @taupalosaurus we talked about a (maybe?) easy fix for this while at Oxford.

Original:
original
Adapt:
adapt
Coarsen:
coarsen

How is the boundary mesh computed?

Can you reveal the total area of the mesh? It might be that pragmatic does not make use of the boundary IDs in the coarsening, but instead resorts to comparing the area/volumes of the old and new triangulation -- unless this has been fixed. At least I can see that coarsen.h still contains std::abs(total_new_av-total_old_av)/std::max(total_new_av, total_old_av)>DBL_EPSILON

Alternatively, the tolerance for the calculation of the boundary mesh should be decreased.

croci commented

The boundary mesh is computed using FEniCS, roughly lines 459-468 in adaptivity.py.in

For adapt:

Donor mesh area : 3.27806152928198244e+01
Target mesh area: 3.27480590762396488e+01
Change : 3.25562165801756009e-02
Relative change : 9.93154530180726143e-04

for coarsen:
Donor mesh area : 3.27806152928198244e+01
Target mesh area: 3.23668979074600358e+01
Change : 4.13717385359788636e-01
Relative change : 1.26207937729103017e-02

@taupalosaurus had an idea on how to fix this

The default tolerance in adaptivity.py.in is 30 degrees. I think this explains it. Just use tol=1 in detect_colinearity?

croci commented

The problem is not in the boundary tags: even if a large portion of the boundary is marked with the same ID pragmatic should just not collapse an element that introduces a large local volume change.

If tol=1 is used then what happens is that every element in the boundary is given a different tag and this is equivalent to not coarsen the boundary at all, which gives rise to knife elements on the boundary.

I think you are right that
#1 pragmatic should not collapse an element that introduces a large local volume change
#2 Setting tol=1 for a coarse metric will give strange elements
but I think you would get exactly the same behaviour, if pragmatic actually preserved local volume changes.
Perhaps you could scale the boundary mesh tolerance together with the metric?

Ideally, one would want an exact/analytic description of the boundary to avoid these issues.

Yes, the problem is they don't have an analytic description of their surface - so as in issue #15, in the long run, we need to try to stick to the local curvature of the surface.
At a shorter term, I think playing on the volume tolerance might help - for now it's either no surface coarsening at all, or everything is accepted. I can put a parameter here to at least experiment.

I am not sure this kind of data really does well with CAD: the shape is so irregular you would end up with super high degree polynomials, and surface reprojection would be costly, no ?

@croci I had a similar bug in #111 (see my last comment). Could it be the same thing here, and your boundary tag is 0 on that portion of the boundary ?

croci commented

@taupalosaurus No, it is not possible, the tags are set by the detect_colinearity routine in adaptivity.py.in. I made sure to avoid using a 0 tag (also I checked the tags and there are no 0 tags).