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