ElmerGrid "forgets" some names converting from gmsh

[robtovey]

My gmsh file specifies 28 "PhysicalNames" but unfortunately the resulting "mesh.names" file only contains 14 of them.

Minimum working example

For example, this occurs if I run ElmerGrid 14 2 buggy_mesh.msh -names -out ElmerMesh on the file attached (the .txt extension just so github would attach it).

In the gmsh file:

1 2 "Rotor-0_HoleMag_R0-T0-S0_Boundary"
1 4 "Rotor-0_HoleMag_R0-T1-S0_Boundary"
1 6 "Rotor-0_HoleVoid_R0-T0-S0_Boundary"
1 8 "Rotor-0_HoleVoid_R0-T1-S0_Boundary"
1 10 "Rotor-0_HoleVoid_R0-T2-S0_Boundary"
1 12 "Rotor-0_LaminationBore"
1 13 "Rotor-0_LaminationYoke"
1 14 "Rotor-0_Lamination_Boundary"
1 15 "Rotor_Hole_Left_0"
1 16 "Rotor_Hole_Left_1"
1 17 "Rotor_Hole_Right_0"
1 18 "Rotor_Hole_Top_0"
1 19 "Rotor_Hole_Top_1"
1 20 "Rotor_Magnet_Bot_0"
1 21 "Rotor_Magnet_Bot_1"
1 22 "Rotor_Magnet_Left_0"
1 23 "Rotor_Magnet_Left_1"
1 24 "Rotor_Magnet_Right_0"
1 25 "Rotor_Magnet_Right_1"
1 26 "Rotor_Magnet_Top_0"
1 27 "Rotor_Magnet_Top_1"
1 28 "Rotor_Tangential_Bridge"
2 1 "Rotor-0_HoleMag_R0-T0-S0"
2 3 "Rotor-0_HoleMag_R0-T1-S0"
2 5 "Rotor-0_HoleVoid_R0-T0-S0"
2 7 "Rotor-0_HoleVoid_R0-T1-S0"
2 9 "Rotor-0_HoleVoid_R0-T2-S0"
2 11 "Rotor-0_Lamination"

And in "mesh.names":

! ----- names for bodies -----
$ Rotor-0_HoleMag_R0-T0-S0 = 1
$ Rotor-0_HoleMag_R0-T1-S0 = 3
$ Rotor-0_HoleVoid_R0-T0-S0 = 5
$ Rotor-0_HoleVoid_R0-T1-S0 = 7
$ Rotor-0_HoleVoid_R0-T2-S0 = 9
$ Rotor-0_Lamination = 11
! ----- names for boundaries -----
$ Rotor-0_HoleMag_R0-T0-S0_Boundary = 2
$ Rotor-0_HoleMag_R0-T1-S0_Boundary = 4
$ Rotor-0_HoleVoid_R0-T0-S0_Boundary = 6
$ Rotor-0_HoleVoid_R0-T1-S0_Boundary = 8
$ Rotor-0_HoleVoid_R0-T2-S0_Boundary = 10
$ Rotor-0_LaminationBore = 12
$ Rotor-0_LaminationYoke = 13
$ Rotor-0_Lamination_Boundary = 14

The interesting thing is that I can see all the body names read in ("BC name for physical group X is: Y"), but they don't come out in the final result. I can't see any errors in the command line log.
The only other feature which catches my eye is:

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

What I've tried

• I'm confident the gmsh file is not the problem, it renders and correctly identifies each of the named components in its native GUI
• with and without autoclean enabled, the only difference is renumbering in mesh.names
• The most related bug report I've found is ElmerGrid mesh.names mismatch when converting Gmsh file #249, but I've confirmed that the behaviour is completely independent of the actual names.
• resorting/renumbering the definitions of the names in the gmsh file changes how many boundaries are in the mesh.names, but it's always a subset

The only thing I can think that is causing a problem is that named entities are not completely disjoint. For example:
Rotor-0_HoleMag_R0-T0-S0_Boundary = Rotor_Hole_Left_0 + Rotor_Hole_Right_0 + Rotor_Hole_Top_0 + Rotor_Hole_Bottom_0 + ...
Should that be a problem?

Let me know if there's anything else you would like me to test locally. Any help would be great.

Some system info

• elmer version 9.0
• ubuntu os
• installed with sudo apt install elmerfem-csc

[richb2k]

1. can you also post the geo file?
2. if you remove all physical names from the geo file, do all boundary entities get converted by elmergrid?
3. feel free to cross post to the forum, it may be helpful.
4. what is the compile date for elmergrid/elmersolver?

[richb2k]

Hello, the attached geo file (rename to remove the txt extension) also 'forgets' one of the boundary conditions, because physical curve bc4 is a duplicate of bc3.
mytest.geo.txt

[robtovey]

Hi @richb2k, thanks for your help on this and your suggestions.

1. can you also post the geo file?

Unfortunately it's not actually generated from a .geo file. It's all done through the gmsh/python api for OpenCascade

2. if you remove all physical names from the geo file, do all boundary entities get converted by elmergrid?

I'm not sure what you mean here. If I remove the name, it removes the tag/numbering so I won't know?

4. what is the compile date for elmergrid/elmersolver?
   September the 7th, 2023

---

the attached geo file also 'forgets' one of the boundary conditions

This example actually runs fine for me!
If I run:

gmsh -2 -format msh2 mytest.geo -o mytest.msh
ElmerGrid 14 2 mytest.msh -names -out mytest

then mesh.names has both bc3=11 and bc4=12, and mesh.boundary also seems to define all of the named boundaries.
Is this not the case for you?

Thanks again.

[richb2k]

Regarding running gmsh with mytest.go, when I run this:
gmsh -2 -format msh2 mytest.geo -o mytest.msh
ElmerGrid 14 2 mytest -names -out mytest

mesh.names includes:
! ----- names for boundaries -----
$ bc1 = 9
$ bc2 = 10
$ bc3 = 11
$ bc4 = 12
$ bc5 = 13

Then when I run this:
gmsh -2 mytest.geo -o mytest.msh
ElmerGrid 14 2 mytest -names -out mytest

mesh.names includes:
! ----- names for boundaries -----
$ bc1 = 9
$ bc2 = 10
$ bc3 = 11
$ bc5 = 13

and bc4 has been removed.

So it appears that ElmerGrid will remove the duplicate bc from the gmsh format 4.1 msh file, but will not remove the duplicate from the gmsh format 2 msh file.

Feel free to post the python/gmsh script to create the buggy_mesh.msh file, that should be straightforward to run in python.

[robtovey]

Interesting, if I also try with -format msh3 then ElmerGrid fails with an error message.
Converting my original file to gmsh version 2.2 preserves the names perfectly.

kevinarden on the forum tells me that this behaviour is not a bug, just not an implemented feature

Unfortunately I can't use version 2.2 all the time because it doesn't implement periodic boundaries.
Do you have any instinct as to whether this is an easy fix in ElmerGrid I might be able to create a PR for?

[richb2k]

It would be better to use the latest default format in gmsh, such as format 4.1. The next question is, how does elmersolver react to duplicate boundaries? Maybe set up a test case and try elmersolver.

[robtovey]

It would be better to use the latest default format in gmsh, such as format 4.1. The next question is, how does elmersolver react to duplicate boundaries? Maybe set up a test case and try elmersolver.

I've made some progress on this today so should hopefully be able to share a couple of test cases soon. My feeling is that the behaviour for version 2 is "hope for the best" and for version 4 it's "assume the worst". Some of ElmerSolver's features are not supported for these duplicate/overlapping boundaries, but sometimes that doesn't matter. I'll try to upload those test cases by the end of this week.

[robtovey]

Ok, so this folder contains three very minimal .geo files and the instructions to run them in the three gmsh formats:
test.zip

Again, I think version 4 will always give the right answer if all names are converted (but there are no error messages when an ID is not mapped). Version 2 trusts that the user has thought through the duplication, so the simulation may be correct or not.

I'm happy to have further discussion about this, especially if anything is unclear in the files, otherwise feel free to close this issue whenever you want.

[richb2k]

The test cases look promising, but haven't had a chance to run them just yet. Maybe you could add the elmersolver case.sif files as well? with unique file names of course. Then post the test archive on the forum.

As the originator, you should be able to close the issue yourself.

[robtovey]

Oops, so sorry I forgot the sif. Here is the version with sif:
test.zip
Not it's exactly the same sif each time, just different behaviour from ElmerGrid. I think this better represents the "silent fail" when ElmerGrid fails to preserve a particular name/tag. I that case, probably there is no correct boundary id which would make the sif file solve correctly.

Thanks again for your help. I'll close the issue then and just feel free to contact me again if I've made further mistakes!