Question on Lagrangian movement + relation between meshes

[prudhomm]

Hi

We are developing an application which uses the ALE framework.
We mix remeshing and ALE map to construct meshes after applying some displacements

we start from a reference mesh then we apply the displacement defined on the reference mesh in an iterative way
last iteration

zoom

the elements associated to the right part are very elongated .
any idea why ? any suggestions where to look ?

I use the relation between meshes to apply the displacement at each iteration defined on the initial reference mesh. it works nicely

we use a simple metric

[prudhomm]

here is the second iterations where the issue starts

with a woom

[prudhomm]

the initial mesh and the first iteration:

at the tip we can already see some elongated element. I expect this from the harmonic extension that is being solved but then I apply the remesher before starting the next iteration.

cc: @lcirrott

[lcirrott]

Hello,
Are you using Lagrangian motion and remeshing in the same call (with -lag 2)? Or using a metric map?
Remeshing inside the Lagrangian mode uses different/fewer remeshing operators than Mmg in standard adaptation mode, so it could be more robust to do motion and remeshing through two separate calls to Mmg.
If you are already doing this, are you computing the metric map on the displaced mesh?

[lcirrott]

Sorry maybe I missed a point… You are using your harmonic extension to get a displacement field to move the mesh, and not Mmg, right?

[prudhomm]

Exactly. Then we remesh the displaced mesh depending on the quality of the mesh.
The remeshing is not quite what I expect. Some elements are distorted a lot and it gets worse and worse

[prudhomm]

Everything is done in a c++ code.
The remeshing part is done by a c++ class wrapping mmg
I use the label trick to store some relation between the meshes. Then I can easily apply displacement from the ref mesh to the current mesh

[prudhomm]

Perhaps I should try letting mmg move the mesh given the displacement field on the object and the boundary of the domain? But then we need elas

[lcirrott]

So it seems an adaptation problem…
I think that it is best to continue to use your elastic/harmonic solver, since you have full control on it and it lets you the freedom to subdivide the displacement in smaller steps in case you get convergence problems or inverted elements.

The picture at the second iteration is already after adaptation? Any warning from Mmg? (Verbosity >= 6 can help)

Can you save a mesh-metric pair with MMG3D_saveMesh and MMG3D_saveSol to test the same thing from command line?

[prudhomm]

I will do that tonight.
Do you expect that due to different options the mmg command line might give different results?
I use the default mmg options in feelpp, I should probably start adding the list of mmg options in feelpp and enable them from command line

[lcirrott]

No, I was just suggesting it for easier debug since the problem does not seem to come from feelpp Otherwise the behaviour should be the same!
My first guess is that there is some warning that gets suppressed with low verbosity (maybe too small volumes that block the adaptation).

The default options are a good starting point if your metric specifies good edge lengths (not too big or too small, so if you don’t need to limit them) and since you don’t need to control the accuracy on the boundary (otherwise the Hausdorff parameter becomes essential).

[prudhomm]

@lcirrott setting debug to 1, makes the code to crash
here is the 4th remesh

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
MODULE MMG2D: 5.5.2 (Nov. 17, 2020)
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
git branch: No git branch found
git commit: No git commit found
git date: No git commit found

– MMG2DLIB: INPUT DATA
– INPUT DATA COMPLETED. 0.000s
MAXIMUM NUMBER OF POINTS (NPMAX) : 50000
MAXIMUM NUMBER OF TRIANGLES (NTMAX) : 100000

– PHASE 1 : DATA ANALYSIS

– MESH QUALITY 15326
BEST 1.000000 AVRG. 0.914612 WRST. 0.002656 (4075)
HISTOGRAMM: 99.27 % > 0.12
96.45 % > 0.5
0.8 < Q < 1.0 13658 89.12 %
0.6 < Q < 0.8 891 5.81 %
0.4 < Q < 0.6 403 2.63 %
0.2 < Q < 0.4 206 1.34 %
0.0 < Q < 0.2 168 1.10 %
** SETTING TOPOLOGY
Connected component or subdomains: 15326
Tagged edges: 23039, ridges: 100, refs: 22939
0 corners, 0 singular points and 7714 non manifold points detected

– RESULTING EDGE LENGTHS 22939
AVERAGE LENGTH 0.1551
SMALLEST EDGE LENGTH 0.0015 5729 3212
LARGEST EDGE LENGTH 1.0000 1638 5728
0.60 < L < 1.30 1073 4.68 %

 HISTOGRAMM:
 0.00 < L < 0.30     19112   83.32 %  
 0.30 < L < 0.60      2754   12.01 %  
 0.60 < L < 0.71       610    2.66 %  
 0.71 < L < 0.90       455    1.98 %  
 0.90 < L < 1.30         8    0.03 %  

– PHASE 1 COMPLETED. 0.197s

– PHASE 2 : ISOTROPIC MESHING
** GEOMETRIC MESH
** COMPUTATIONAL MESH
** Defining isotropic map

– SIZEMAP CORRECTION : overwritten of sizes at required vertices

– GRADATION : 1.300000 (2.300000)
** Grading mesh
gradation: 0 updated, 1 iter.
** Grading required points.
gradation (required): 6747 updated, 9 iter.
5 splitted
5 splitted, 0 collapsed, 0 swapped
11 splitted
11 splitted, 0 collapsed, 0 swapped
68 vertices moved, 1 iter.
67 splitted, 8 collapsed, 0 swapped, 68 moved
2 edge swapped
88 vertices moved, 1 iter.
24 splitted, 4 collapsed, 2 swapped, 88 moved
1 edge swapped
89 vertices moved, 1 iter.
7 splitted, 6 collapsed, 1 swapped, 89 moved
59 vertices moved, 3 iter.
– PHASE 2 COMPLETED. 0.018s

– MESH QUALITY 15504
BEST 1.000000 AVRG. 0.908374 WRST. 0.001493 (15502)
HISTOGRAMM: 98.94 % > 0.12
95.61 % > 0.5
0.8 < Q < 1.0 13688 88.29 %
0.6 < Q < 0.8 906 5.84 %
0.4 < Q < 0.6 442 2.85 %
0.2 < Q < 0.4 231 1.49 %
0.0 < Q < 0.2 237 1.53 %

– RESULTING EDGE LENGTHS 23206
AVERAGE LENGTH 0.4418
SMALLEST EDGE LENGTH 0.0135 7668 7652
LARGEST EDGE LENGTH 3.2033 309 7723
0.60 < L < 1.30 6019 25.94 %

 HISTOGRAMM:
 0.00 < L < 0.30     11075   47.72 %  
 0.30 < L < 0.60      6088   26.23 %  
 0.60 < L < 0.71       944    4.07 %  
 0.71 < L < 0.90       985    4.24 %  
 0.90 < L < 1.30      4090   17.62 %  
 1.30 < L < 1.41        16    0.07 %  
 1.41 < L < 2.00         1    0.00 %  
 2.00 < L < 5.00         7    0.03 %  

– MESH PACKED UP
NUMBER OF VERTICES 7803 CORNERS 0
NUMBER OF TRIANGLES 15504
NUMBER OF EDGES 23118

MMG2DLIB: ELAPSED TIME 0.219s

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
END OF MODULE MMG2D

[lcirrott]

Thanks! Still no errors from this log, but it does tell that the output edge lengths are terrible. Is it with verbosity >=6 ?
Are you passing only the outer domains to mmg, with required boundary faces? What kind of metric are you passing?

[prudhomm]

it is with verbosity=8
the metric can be based on the distance to the boundary of the object, min, avg or max mesh size.
I can also disable the metric and use simply .hsiz .hmin or .hmax parameter from mmg.
The result is always the same.
regarding the object, I pass it to mmg as well but have the elements required and I use the label trick to keep track of them. I could also just have the interface required(I have to do a little of work to enable that)
is that a problem to pass the object ? I want to use the new mesh immediately afterwards

[prudhomm]

I still have to save the mesh and solution to mmg format and use mmg app.

[prudhomm]

here is what happens in remeshing

before:

after

a few elements have been created, essentialy splitting.
idem at the next step, but then the elements are getting really elongated

[Algiane]

Hi,

Thank you for all these precisions.

Is it possible to try the remeshing without the required size computation (-nosizreq) and the required gradation (-hgradreq -1)? Inside feelpp, you just have to add the following lines before the call of the MMG3D_mmg3dlib function:

MMG3D_Set_iparameter(mesh,sol,MMG3D_IPARAM_nosizreq,1);
MMG3D_Set_dparameter(mesh,sol,MMG3D_DPARAM_hgradreq,-1);

Thank you by advance,

[prudhomm]

Hello @Algiane ,I added the options you suggested

here are the results:

it changes at the tip of the structure
the elements are still elongated, it seems that the adaptation step does very little

I had to wait a few hours to be able to post, discourse does not want new users to post too often

here is what mmg says at last iterations

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
MODULE MMG2D: 5.5.2 (Nov. 17, 2020)
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
git branch: No git branch found
git commit: No git commit found
git date: No git commit found

– MMG2DLIB: INPUT DATA
– INPUT DATA COMPLETED. 0.000s
MAXIMUM NUMBER OF POINTS (NPMAX) : 50000
MAXIMUM NUMBER OF TRIANGLES (NTMAX) : 100000

– PHASE 1 : DATA ANALYSIS

– MESH QUALITY 15148
BEST 1.000000 AVRG. 0.783740 WRST. 0.000001 (6293)
HISTOGRAMM: 96.06 % > 0.12
86.67 % > 0.5
0.8 < Q < 1.0 9549 63.04 %
0.6 < Q < 0.8 2762 18.23 %
0.4 < Q < 0.6 1273 8.40 %
0.2 < Q < 0.4 654 4.32 %
0.0 < Q < 0.2 910 6.01 %
** SETTING TOPOLOGY
Connected component or subdomains: 15148
Tagged edges: 22772, ridges: 100, refs: 22672
0 corners, 0 singular points and 7625 non manifold points detected
– PHASE 1 COMPLETED. 0.195s

– PHASE 2 : ISOTROPIC MESHING
** GEOMETRIC MESH
** COMPUTATIONAL MESH
** Defining isotropic map

– GRADATION : 1.300000
** Grading mesh
gradation: 0 updated, 1 iter.
– PHASE 2 COMPLETED. 0.008s

– MESH QUALITY 15148
BEST 1.000000 AVRG. 0.783740 WRST. 0.000001 (6293)
HISTOGRAMM: 96.06 % > 0.12
86.67 % > 0.5
0.8 < Q < 1.0 9549 63.04 %
0.6 < Q < 0.8 2762 18.23 %
0.4 < Q < 0.6 1273 8.40 %
0.2 < Q < 0.4 654 4.32 %
0.0 < Q < 0.2 910 6.01 %

– RESULTING EDGE LENGTHS 22672
AVERAGE LENGTH 0.0869
SMALLEST EDGE LENGTH 0.0008 5007 6734
LARGEST EDGE LENGTH 0.6650 2108 6
0.60 < L < 1.30 1 0.00 %

 HISTOGRAMM:
 0.00 < L < 0.30     21339   94.12 %  
 0.30 < L < 0.60      1332    5.88 %  
 0.60 < L < 0.71         1    0.00 %  

– MESH PACKED UP
NUMBER OF VERTICES 7625 CORNERS 0
NUMBER OF TRIANGLES 15148
NUMBER OF EDGES 22772

MMG2DLIB: ELAPSED TIME 0.208s

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
END OF MODULE MMG2D
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

[lcirrott]

Hello @prudhomm,
Thanks for the log! I notice now a couple of things: apparently there are 15148 triangles in input

– MESH QUALITY 15148

and mmg finds 15148 indipendent domains:

Connected component or subdomains: 15148

This means that there is a different reference on every element in the mesh: this is a bit extreme and it could backfire because mmg would treat every edge as a geometrical surface that it should preserve (geometrically) while adapting, as I feared here but maybe I failed to explain well… Relation between required faces or elements between remeshes - #5 by lcirrott

Couldn’t you put references/labels only on the required elements? (Since they are required, it doesn’t do any harm to have internal surfaces between them)

[prudhomm]

Oops you are right my bad!
I understood properly but wasn’t careful in the implementation. I will fix ASAP