ElmerGrid "forgets" some names converting from gmsh

[robtovey]

Cross-posting from github issue

I have a gmsh file which specifies 28 "PhysicalNames" but unfortunately the resulting "mesh.names" file only contains 14 of them.

Please see the original post for more details, but feel free to interact on either platform.

The problem appears to be independent of the actual names and probably is related to the fact that some of the named boundaries intersect.
richb2k has kindly attempted to reduce the problem to a minimal reproducible example, however so far we have just confirmed that the problem does not occur every time there are overlapping boundaries.

The problem is reproducible with the attached .msh file running:

Code: Select all

ElmerGrid 14 2 buggy_mesh.msh -names -out ElmerMesh

The resulting mesh.names file only contains the first 8 of 22 boundary names. The output of the command is also attached, the only thing that stands out to me are the two lines:

Code: Select all

Physical given tag range is [2 28] !-- the correct original tag range
...
Physical read tag range is [2 14] !-- the wrong final tag range

So the tags are parsed/detected, but not "read".

Any help would be appreciated.

Remaining metadata:
- my OS is ubuntu 22
- ElmerSolver version is "Version: 9.0 (Rev: unknown, Compiled: 2023-09-07)", installed through "apt install elmerfem-csc"

[kevinarden]

I do not think this is a bug, it is not how Elmer is interpreting the file and not how it is intended to interpret the file. Creating physical names in gmsh does not create additional elements that can become boundaries, Elmer converts the nodes and elements, then uses the physical names to put them into bodies and boundaries. It will not create a new boundary or body because a different physical name was created.

In the following example I create a square with 4 triangles, and it has four boundary elements. However, I create 6 curve physical names to try and create six boundaries.

However from ElmerGrid I only get four boundaries, because ElmerGrid first converts the the nodes and elements and then goes to find a body or boundary for them to belong. It is working as it is intended to do, it is not a bug. If you want multiple boundaries on edges of elements, you have to create multiple elements to be the boundary, not multiple groups.

This might be a nice feature to add but it is not a bug, and ElmerGrid is not "forgetting"

mesh.png

(88.09 KiB) Not downloaded yet

bug.geo

(707 Bytes) Downloaded 29 times

[Rich_B]

It makes sense for ElmerGrid to eliminate duplicate boundaries. On the other hand, to remove boundaries silently is not nice. It would be nice if ElmerGrid would output a message something like: Duplicate boundary 123 found, keeping first occurrence of boundary 122.

Just my two cents.

Rich.

[Rich_B]

The attached archive includes bug.geo and four scripts. The scripts will run gmsh and output the msh file in both format 2 and format4, followed by ElmerGrid converting both msh files into elmer mesh format.

ElmerGrid converts the gmsh format 2 msh file, retaining the duplicate boundaries.
ElmerGrid converts the gmsh format 4 msh file, removing the duplicate boundaries.

Rich.

[robtovey]

Thank you both for helping clarify what's happening.

From a user perspective it feels buggy because it's not documented and not consistent. In the three geometries I've tried:
- all of the boundaries are preserved from gmsh version 2
- ElmerGrid fails with a message of unsupported features in version 3
- only some of the boundaries are preserved from version 4
- when only some of the boundaries are preserved, the result depends on ordering in the geo file
The only documentation for mesh.names is the flag `-nonames`, maybe I'm missing something? Otherwise something like Rich suggests would be great. At the moment ElmerGrid prints "BC/body name for physical group X is: Y". If a group is knowingly dropped, then a similar "Removing duplicate BC/body physical group X" would have clarified that this was intended behaviour.

I appreciate that names are more of a "user convenience" feature and not essential for the backend operation, but they are very useful.

I'm still not sure what ElmerGrid's policy is for preserving names. The logic I can see (in 2D) is:
- it is permitted to have multiple named 2D bodies with overlapping (un-named) 1D boundaries
- it is permitted to have multiple named 1D boundaries with overlapping 0D points
- behaviour when multiple named 1D boundaries with overlapping 1D sections is not guaranteed
Or maybe the top two points are not guaranteed either?

[kevinarden]

It is going to behave differently with or without the autoclean. From ElmerGRid I get all of the element defined boundaries if I do not use the autoclean, and I can use all of the boundaries in the solver. I can not however read them all into ElmerGUI, even if I open the ElmerGrid created mesh.

[robtovey]

For completeness, here is a set of test cases which I think demonstrates the full behaviour:

test.zip

Set of test cases for different gmsh versions

(3.19 KiB) Downloaded 25 times

A quick summary, the physical setup is that there is a disk inside an annulus where the inner boundary of the annulus exactly matches the boundary of the disk. The sif file attaches an outwards force on the external boundary of the annulus, which should pull it away from the disk. The correct solution is a stretched annulus which doesn't touch the disk.

I have included three geometry files which always define three named boundaries: the boundary of the disk, the outer boundary of the annulus (where the force is applied), and "other". The three files each define "other" differently:
Case 1 - "other" is equal to the boundary of the disk (contact boundaries have different names but the same id in gmsh)
Case 2 - "other" is the full boundary of the annulus (contact boundaries have different id's, but "other" also contains the outer boundary of the annulus)
Case 3 - "other" is just a deep copy of the boundary of the disk (all boundaries have unique names and disjoint id's)

The behaviour of the output simulation depends on both the format version of the .msh file and the contents of the .geo file:
- with version 2, ElmerGrid always copies all three names to mesh.names without raises an error or warning, but the solver gives the wrong output in Case 1 where the contact boundaries are unable to separate. Cases 2 and 3 give the correct output.
- with version 3, ElmerGrid always fails with a seg fault and a message that version 3 is not supported
- with version 4, ElmerGrid only preserves the three names in Case 3, where the simulation is correct. ElmerGrid ignores one of the names in Cases 1 and 2, the simulations are completed without errors or warnings but give meaningless results (because the id numbers referenced in the sif file no longer reference the correct physical groups)

Overall, using ElmerGrid with version 2 gives the user the benefit of the doubt whereas with version 4 it assumes the worst and requires unique id's for each name.
Hopefully someone will find this characterisation useful in the future.