Mesh generation with MMG2D ignoring edge table


#1

Hi all,

I am trying to generate a 2D triangular mesh of a domain defined by a set of points and a set of edges.
I test the MMG2D generation tools you provide both on my own input mesh using lib and on the acdc example using mmg2d bin.

The result of command ‘’./mmg2d_O3d -ar 10 /tmp/acdc.mesh /tmp/ko.mesh’’ gives unexpected result. See result below

In the log I get this message :
– PHASE 1 : MESH GENERATION

Error: MMG2_insertpointdelone: some vertex are not inserted 1.

Warning: MMG2_pack: unexpected edge table… Ignored data.

Is something wrong in the way I use mmg2d?

Pierre

PS: I am using MODULE MMG2D-IMB/LJLL : 5.3.8 (Apr. 10, 2017) ISO


#2

Hi Pierre,

Thank you for pointing out this problem.
The acdc.mesh file was invalid. It contains 2 points with the same coordinates and 1 edge with null length.

I update the mesh on the Mmg website. Normally, you have now only 62 points in your mesh and mmg2d must works!

Regards,

Algiane


#3

Hi Algiane,

thank you for the answer. I have just tried with the updated acdc.mesh file and it works perfectly.
If I well understand I suppose I have the same kind of invalidities in my own mesh. I will track down for this issues.

Do you provide seme tools to ease the detection of these invalidities?

Thanks again for your help,

Best regards,

Pierre


#4

I am sorry, we de not provide tools to check the mesh validity (but very often the code crashes on invalid meshes). In your case, I use the medit software to visualize the mesh and I ask to see the vertices indices (P shortcut). Thus I see that I had 1 vertex with 2 indices.

In your case, the error messages you get means that Mmg fails to insert an edge. I see 3 different reason for this:

  • one edge has a 0 length
  • one edge is duplicated
  • a bug in Mmg

I hope that it will help,

Regards,

Algiane


#5

Thanks for your help in my problem. I will check vertex ids with medit viewer as you mentioned.

BTW, in your updated acdc.file there is (line 89) an extra edge from vertex 22 to vertex 22.

Regards,
Pierre


#6

After scanning my mesh file (attached to this post), it appears that there is no 0 length edge nor duplicated edge.
As you can see by viewing the file, the domain is try to mesh is a long and thin domain. The set of edges bounds this domain is a single loop (with ordered vertices).

So here is my file, you can use it for debug purpose if necessary.
input_boundary.mesh (29.9 KB)

Thanks for helping,
Regards,
Pierre


#7

I am careless with this mesh! I will update it again!


#8

Hi Pierre,

I am looking at the input_boundary.mesh mesh and obviously, there is an issue with Mmg2d (probably something due to a wrong handling of the machine epsilon). I will look at it as soon as possible.

Regards,

Algiane


#9

Hi Algiane,

thank you for your help. I also think there is a problem with mmg2d since I tried to first remesh the given domain boundaries to avoid small edges. I set a constant resolution for edges equals to 1m and the smallest edge is now 0.25m et the biggest 1.13m. I have the same problem with this new input mesh.

Best regards,

Pierre


#10

Hi Pierre,

I just push (in develop branch) some modifications in mmg2d to correct your bug (it was due to the epsilon machine management).

There is still 2 epsilon values that are maybe too large in Mmg but as your test case seems to work, I prefer not changing it.

Let me know if you encounter other similar problems.

Regards,

Algiane


#11

Hi Algiane,

I have tried the develop branch for 2d mesh generation. As you mentioned, it works well with the mesh I had given (“input_boundary.mesh”) using exe.

I have done a new test calling mesh generation functions form the lib. In this case, there is still the “unexpected edge table” message. There is something interesting: in my code, I save the input mesh used in MMG2D_mmg2dmesh(…) : ok_with_exe.mesh (29.9 KB)

I tried to use this mesh with the exe (./mmg2d_O3d -hmax 1 ok_with_exe.mesh out.mesh). Everything is ok.
But using the lib function
MMG2D_mmg2dmesh(…) it does not work.

Do you think I do something wrong in the initialization of mesh data?

The function I used before running mesh generation are (in this order):

MMG2D_Init_mesh(… );
MMG2D_Set_meshSize( … );
MMG2D_Set_vertex( … ); and MMG2D_Set_requiredVertex( …); for each vertex
MMG2D_Set_edge(… ); and MMG2D_Set_requiredEdge( … ); for each edge
MMG2D_Set_solSize( … );
MMG2D_Set_scalarSol(… ); for each vertex
MMG2D_saveMesh(…);

Thank you for the help

Pierre


#12

Hi Pierre,

  1. When you run your test case in command line, do you use a metric too?

  2. This test case is hard because it is very close to the machine epsilon. Maybe you are loosing the double precision somewhere. I have check the library call, it seems to work. (I haven’t use the set_vertex function, I have used the loadMesh one). If you call the saveMesh function after the mesh setters and then the loadMesh function and the library, does it works?

Regards,

Algiane


#13

Hi Algiane,

thanks for answering.
For your first question, I do not use a metric pour le test case in command line. Maybe the difference comes from that point.

I will do the test you mention in #2, and I will come back to you. Is there a way to impose the double precision?

Best regards,
Pierre


#14

Hi,

I have made 2 tests: saving the metric in a .sol file et using both .mesh and .sol in the command line: no problem.
I tried to saveMesh and then to loadMesh, there is a crash (seg fault) when loading (in file inout_2d.c line 96).

EDIT: I was forgetting to init the new mesh object before loading. There is no more crash but the edge table is still ignored. How to set (and test) double precision?

Best regards,
Pierre


#15

In which language is your code? In C, you must use the “double” declaration, in fortran the REAL(KIND=8) one…

I am not sure but you can :

  • compare the mesh that you have saved and that crashes with the mesh that works. If the nodes have the same order you can check their precisions (the number of digits on which they are identical). Or you can do the same thing with a debugger in your code.

  • it reminds me that your problem may still be due to Mmg : if your nodes (or edges) are ordered differently between the mesh that works and the mesh that crashes, the process of mesh generation may fall on another bug…

Regards

  • i

#16

The language of my code is C++. I think it is ok for double precision.

I use the same .mesh for exe and lib (see “ok_with_exe.mesh” in post #11). It crashes only using the lib.

Here is a snap of the code I use.

    MMG5_pMesh mmg_mesh_reload_ptr = nil;
    MMG5_pSol mmgSol = nil;
    MMG2D_Init_mesh( MMG5_ARG_start,
    MMG5_ARG_ppMesh, &mmg_mesh_reload_ptr, MMG5_ARG_ppMet, &mmgSol,
    MMG5_ARG_end );
    MMG2D_loadMesh( mmg_mesh_reload_ptr, "/tmp/ok_with_exe.mesh" );

    MMG2D_Set_solSize( mmg_mesh_reload_ptr, mmgSol, MMG5_Vertex,
        static_cast< int >( vertices.size() ), MMG5_Scalar );
    /// Set the metric
    for( index_t p = 0; p < vertices.size(); p++ ) {
        MMG2D_Set_scalarSol( mmgSol, resolution,
            static_cast< int >( MMG_START_ID + p ) );
    }

    MMG2D_mmg2dmesh( mmg_mesh_reload_ptr, mmg_metric_ptr );

with resolution a double (=1), MMG_START_ID = 1.

BR
Pierre


#17

Hi Pierre,

I am not able to reproduce your bug. In your code, you call the mmg2d library with the mmg_metric_ptr metric and not the mmgSol one, are they identical?

Can you please turn on the debug mode and increase the verbosity of Mmg and send me the Mmg output?

/** Higher verbosity level */
MMG2D_Set_iparameter(mmgMesh,mmgSol,MMG2D_IPARAM_verbose,6);

/** Debug mode */
MMG2D_Set_iparameter(mmgMesh,mmgSol,MMG2D_IPARAM_debug,1);

Thank you by advance,

Regards,


#18

Hi Algiane,

thank you for the answer. Yes the 2 metrics are identical (at least, they are defined the same way).

I run my code with debug and verbosity mode and a get the following message for each call of MMG2D_Set_scalarSol.

Error: MMG2D_Set_scalarSol: unable to set a new solution.
max number of solutions: 0

Finally I get this one:

– MMG2DMESH: INPUT DATA

WARNING: WRONG SOLUTION NUMBER : 551 != 0

There are 551 vertices in the input mesh.

Regards,
Pierre


#19

Hi Pierre,

I wasn’t expected this kind of errors…

It seems that Mmg think that you don’t have vertices.
As you work in C++ which is very close to C, you can print the mmg_mesh_reload_ptr->np and mmg_mesh_reload_ptr->npmax fields. Normally they are non-zero.

Hope we will understand what happens…

BR


#20

Hi Algiane,

here is the log :

mmg_mesh_reload_ptr->npmax: 0
mmg_mesh_reload_ptr->np: 0

Regards,
Pierre

PS: for the mesh I had save:
mmg_mesh_ptr->npmax: 50000
mmg_mesh_ptr->np: 551