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
I still have to save the mesh and solution to mmg format and use mmg app.
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
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,
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
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
Hello @prudhomm,
Thanks for the log! I notice now a couple of things: apparently there are 15148 triangles in input
and mmg finds 15148 indipendent domains:
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)
Oops you are right my bad!
I understood properly but wasn’t careful in the implementation. I will fix ASAP
I hope this fixes it!
Then mmg should start giving more meaningful errors if it finds too small or negative elements, like:
(which I suspect it is skipping due to the previous problem)
ok it works better. I used @Algiane recommendation and get the following mesh
if I remove them the algorithm fails often
Metric gradation from required entities can be sometime buggy…
Could you try with a smaller MMG3D_DPARAM_hausd? Since there is a geometric surface containing all the required elements, asking for an increased accuracy (smaller Hausdoff parameter) near the boundary should also propagate smaller sizes a bit further into the domain.
it is better, I get something like that
with
MMG3D_Set_iparameter(mesh,sol,MMG3D_IPARAM_nosizreq,1);
MMG3D_Set_dparameter(mesh,sol,MMG3D_DPARAM_hgradreq,-1);
If I set my own metric, it get stuck after a few 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 6053
BEST 1.000000 AVRG. 0.925292 WRST. 0.008296 (4828)
HISTOGRAMM: 99.85 % > 0.12
99.36 % > 0.5
0.8 < Q < 1.0 5395 89.13 %
0.6 < Q < 0.8 569 9.40 %
0.4 < Q < 0.6 66 1.09 %
0.2 < Q < 0.4 13 0.21 %
0.0 < Q < 0.2 10 0.17 %
** SETTING TOPOLOGY
Connected component or subdomains: 2469
Tagged edges: 3943, ridges: 33, refs: 3910
4 corners, 0 singular points and 1445 non manifold points detected
30 calculated normal vectors
– RESULTING EDGE LENGTHS 9063
AVERAGE LENGTH 0.0589
SMALLEST EDGE LENGTH 0.0012 2775 259
LARGEST EDGE LENGTH 1.2723 27 1911
0.60 < L < 1.30 197 2.17 %
HISTOGRAMM:
0.00 < L < 0.30 8739 96.43 %
0.30 < L < 0.60 127 1.40 %
0.60 < L < 0.71 34 0.38 %
0.71 < L < 0.90 78 0.86 %
0.90 < L < 1.30 85 0.94 %
– PHASE 1 COMPLETED. 0.006s
– PHASE 2 : ISOTROPIC MESHING
** GEOMETRIC MESH
2 splitted
1210 vertices removed
240 edge swapped
2 splitted, 1210 collapsed, 240 swapped
25 splitted
21 vertices removed
64 edge swapped
25 splitted, 21 collapsed, 64 swapped
22 splitted
12 vertices removed
12 edge swapped
22 splitted, 12 collapsed, 12 swapped
20 splitted
10 vertices removed
10 edge swapped
20 splitted, 10 collapsed, 10 swapped
20 splitted
10 vertices removed
10 edge swapped
20 splitted, 10 collapsed, 10 swapped
** 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): 390 updated, 4 iter.
193 splitted
91 vertices removed
396 edge swapped
193 splitted, 91 collapsed, 396 swapped
166 splitted
28 vertices removed
218 edge swapped
166 splitted, 28 collapsed, 218 swapped
32 splitted
12 vertices removed
37 edge swapped
32 splitted, 12 collapsed, 37 swapped
33 splitted
3 vertices removed
8 edge swapped
33 splitted, 3 collapsed, 8 swapped
51 splitted
6 vertices removed
21 edge swapped
51 splitted, 6 collapsed, 21 swapped
197 edge swapped
426 vertices moved, 1 iter.
417 splitted, 473 collapsed, 197 swapped, 426 moved
488 edge swapped
856 vertices moved, 1 iter.
998 splitted, 567 collapsed, 488 swapped, 856 moved
378 edge swapped
1212 vertices moved, 1 iter.
1033 splitted, 672 collapsed, 378 swapped, 1212 moved
301 edge swapped
1494 vertices moved, 1 iter.
936 splitted, 643 collapsed, 301 swapped, 1494 moved
it is a pity, the mesh is quite good, but it seems we have very small elements at the tip
Nice to see it!
By “stuck” you mean that suddenly it refuses to improve the mesh and returns? The mesh does seem to have almost null elements near the tip, I can’t see if they are there before adapting.
Maybe the time step could be reduced only when the Harmonic extensions produces elements with volume below a given tolerance!
by stuck I mean that mmg is stuck during the adaptation process (I wait a few minutes before killing the process).
There is no time here yet (we are at time=0) . The reference domain (an horizontal bar, a tail actually) is not at all the real domain the displacement is what you see on the last message. Then the tail beats over time
I am refactoring the code at the moment to have a full tail beating setup.
I will post a report and possibly some videos 
Hello,
Yes, the tip seems to be ok on this picture.
If it is possible for you to share the input mesh and metric (maybe in PM) of the iteration that deadlock, I am interested to investigate why Mmg fails. For the mesh where Mmg creates very small elements too (it doesn’t seem to be a normal behaviour so it worth to check if we don’t have an issue with one of our operator).
Thank you by advance,
Algiane
@Algiane I will try to save the mesh and metric in mmg format (I currently don’t do it). There is nothing special about the geometry, no problem to share it. do I post it here or send it to you by email ?
The 3D version seems a bit more sensitive than the 2D one.
in the mean time here is a video
hopefully the 3D will follow.
PS: if you or @lcirrott or both are interested in collaboration, you would be most welcome !
If the 2D mesh can be shared, we can continue here I think (so if someone is interested he will have the entire conversation).
We would be happy to have a verbal discussion and to see your results!
I will contact you by PM.
Regards,
Algiane