Unexpected behaviour of mesh size and -nofem settings in 2D

User Help
#1

First of all, thank you for actively developing these useful meshing tools.
I encountered behaviour of the mesh size settings that I did not expect in MMG2D (5.6.0).
I created a simple test mesh with a triangular hole of which the edges may not be altered. For all tests I added ‘-hgrad -1 -hgradreq -1’ to the input command line options.

When I prescribe a maximum edge length of all triangles using the global options ‘-hmin 0 -hmax 0.1’ I obtain the expected results, see attachment 1. When I use an external parameter file “.mmg2d” to prescribe the same minimal and maximal edge lengths (and remove the global size options from the input string) for all triangles, I obtain different results, see attachment 2. The edge size seems to decrease much more gradually in this case. If ‘-nofem’ is added, the results are even worse.

Could you please help me figuring out what is going on and if this is unexpected behaviour?

Thank you in advance!

2
2671×669 85.9 KB

3
3676×668 82.7 KB

#2

The result when adding ‘-nofem’ and the input files I used:

4
4689×676 61.5 KB

demo.mesh (529 Bytes)
demo.mmg2d (94 Bytes)

#3

Hi,

I think that this behaviour is related to the way we compute the hmax value when it is not provided by the user but I am not entirely sure. Is it possible to attach an image of the input mesh too please?

Just to help you to understand how Mmg works: it is not possible to perform mesh adaptation without an hmax value, so if the user don’t provide this value, we compute it from the input mesh:

  • without an input metric, we set it to twice the bounding box size;
  • with an input metric we set it to ten times the maximal edge size.

Then we perform a first wave of mesh adaptation to roughly respect the boundary approximation and the hmax/hmin values.

From the obtained mesh, we compute our internal metric (sizemap) in which we integrate the effects of various options (the gradation and required gradation for example but also the local parameters). I have to check all of this but I suppose that we are observing a (very strong) sensitivity of the sizemap to this temporary mesh.

An issue with the local parameters is that it is expensive to check everywhere so a way to preserve the process efficiency has been to not check these values everywhere (which explains that its behaviour is different than the behaviour of the global params, even in equivalent settings).

In practice, which kind of behaviour would you like to have (I guess that you have tried to reproduce an issue on a toy test case)?

Best Regards,
Algiane

#4

Thank you for your quick reply.

In all cases, I prescribe the hmax value myself for all triangles (either by using the ‘-hmax’ command line setting, or by using a local parameters file). The input mesh is a very rough triangularization using ‘Triangle’ (2D meshing software), which I refine using MMG. I would like to be able to merge an existing mesh with the mesh created by MMG. That is also the reason why the edges in the hole are not allowed to be changed, as they should match perfectly with the other mesh. The size of the triangular hole is a bit large in this example, but a similar behaviour occurs with smaller triangular holes.

The input mesh:

input
input688×699 14.4 KB

#5

Hello,

I think that the branch feature/local-param-consistency solves your issue (see github issue #121).

Please let me know if it doesn’t work on your real test case.

Best Regards,
Algiane

#6

Thank you very much! This patch fixed the issue!

#7