This is a follow up to this forum post:
viewtopic.php?p=28090#p28090
Here's some background on femm:
femm, Finite Element Method Magnetics, at https://www.femm.info/wiki/HomePage, uses the Triangle poly format file as an intermediate meshing solution. The geometry is generated by the femm gui and stored in a femm format file, with extension .fem. While running a solution, femm generates a Triangle poly file, and then calls Triangle to use the poly file to generate the mesh. The femm solver then uses that mesh to solve the problem. After solving, femm then deletes all of the Triangle files, including the poly file.
This femm forum post gives a working method to save the generated Triangle files:
https://groups.io/g/femm/message/2047?p ... 2C54947378
Basically, rename the femm solver so the solver can't load, and execution halts, leaving behind the temporary files.
The femm website lists several examples of using femm, so the information has been publicly published. Downloading and starting to run the examples, and saving the Triangle files, provides several examples of poly files.
The poly files must then be converted to .node and .ele mesh files by running Triangle with the right command line switches, such as '-pqcA'. The 'A' switch is needed to read the regions input and add the regions information in the output .ele file. A working copy of Triangle is included in the bin folder of femm, which can be downloaded from the femm website.
So to summarize, using gmsh terminology, the poly file (the geo file) is the manually created geometry input file. Triangle is then called to convert the poly file into two mesh files, .node and .ele. The equivalent actions when running gmsh are to load a geo file, give the mesh command, then save the resulting msh file.
From all this, a few things are notable. First, ElmerGrid has been updated to successfully deal with a C-style zero based index. Next, ElmerGrid should not need to read the poly file, all the information is contained in the .node and .ele files. The .node file includes the vertex numbers, the vertex coordinates, and the boundary numbers. The .ele file includes the element numbers, the vertex numbers that define each triangular element, and a region number. The region number is almost the same as a body number in Elmer terms. The difference is that in the defining poly file, each region number must be unique. For example, if one wanted to number three regions as one body, you can't do that in a poly file, you will end up with three bodies in the .ele file. This situation can then be addressed in the sif file.
ElmerGrid issues:
1. femm uses negative boundary numbers, which ElmerGrid doesn't know how to handle.
2. femm optionally numbers regions, that are similar to body numbers, but the region numbers are not read by ElmerGrid.
Attached is an archive of the DoubleSidedLIM example, with .poly, .node and .ele files. This example has several boundary numbers and several region numbers, so it's good exercise for ElmerGrid.
Rich.
femm uses Triangle poly format internally
femm uses Triangle poly format internally
- Attachments
-
- DoubleSidedLIM.zip
- (208.64 KiB) Downloaded 1 time
Re: femm uses Triangle poly format internally
After further checking, Triangle needs to output the .edge file in addition to .node and .ele. Elmergrid then should read all three files. The three Triangle mesh output files are similar in content to the Elmer mesh files, specifically *.node -> mesh.nodes, *.ele -> mesh.elements, and *.edge -> mesh.boundary. The Triangle mesh output files don't have an equivalent file to mesh.header, instead the number of nodes, elements, and boundaries are on the first line of each respective file.
When calling Triangle, be sure to use the following switches: 'e' to output the edge file and 'A' to convert regions to bodies and add to the ele file. Optionally, add 'j' to have Triangle remove unused nodes. For information, the 'p' switch says to use a poly file for input, the 'c' switch says to fill in concave meshes, and 'q' is to set the minimum angle in each triangle. Using 'q' alone, sets the minimum angle to 20 degrees, while 'q33.0' will set the minimum angle to 33 degrees.
Recommended command line entries to convert from a Triangle poly file to an Elmer mesh:
When calling Triangle, be sure to use the following switches: 'e' to output the edge file and 'A' to convert regions to bodies and add to the ele file. Optionally, add 'j' to have Triangle remove unused nodes. For information, the 'p' switch says to use a poly file for input, the 'c' switch says to fill in concave meshes, and 'q' is to set the minimum angle in each triangle. Using 'q' alone, sets the minimum angle to 20 degrees, while 'q33.0' will set the minimum angle to 33 degrees.
Recommended command line entries to convert from a Triangle poly file to an Elmer mesh:
Rich.Triangle -p -q33.0 -e -A -j filename <or> Triangle -pq33.0eAj filename
ElmerGrid 11 2 filename -autoclean
-
- Site Admin
- Posts: 4529
- Joined: 22 Aug 2009, 11:57
- Antispam: Yes
- Location: Espoo, Finland
- Contact:
Re: femm uses Triangle poly format internally
Hi
I hope it could work better now. Initially I thought that .poly would be the file to get the boundaries. Now they are read from .edge ignoring the ones with "0" label. Offset 0/1 in indexing is also taken care of.
-Peter
I hope it could work better now. Initially I thought that .poly would be the file to get the boundaries. Now they are read from .edge ignoring the ones with "0" label. Offset 0/1 in indexing is also taken care of.
-Peter
Re: femm uses Triangle poly format internally
Hello Peter,
Great, thanks for you help with Triangles!
Rich.
Great, thanks for you help with Triangles!
Rich.
Re: femm uses Triangle poly format internally
Hello Peter and Rich,
Thank you very much for this help and provided solution. I tested two cases here and got excellent results.
Actually, I had a surprise as it worked beyond what I was expecting. As illustrated in the attached images, FEMM defines circuits differently from what elmer does. We can define same material for all bodies and there is a circuit property which is added. Since material is the same, I thought the body would be identified similarly. But, FEMM differentiates the bodies with different circuit definitions as well and this is passed to Elmer:
Also, I would like to add another way to get the mesh files from FEMM. When you download the binaries from xfemm:
https://sourceforge.net/projects/xfemm/ ... ase%203_0/
It has a function called fmesher.exe (\xfemm_v3_0_win64.zip\xfemm_mingw_win64\cfemm\bin\fmesher.exe). It can be used with the command:
The output files here are the same as the one from the procedure Rich suggested. (PS., just be careful to use the file extension with lowercase letter)
After that, just do:
You don`t have to use triangle again.
Thank you very much for this help and provided solution. I tested two cases here and got excellent results.
Actually, I had a surprise as it worked beyond what I was expecting. As illustrated in the attached images, FEMM defines circuits differently from what elmer does. We can define same material for all bodies and there is a circuit property which is added. Since material is the same, I thought the body would be identified similarly. But, FEMM differentiates the bodies with different circuit definitions as well and this is passed to Elmer:
Also, I would like to add another way to get the mesh files from FEMM. When you download the binaries from xfemm:
https://sourceforge.net/projects/xfemm/ ... ase%203_0/
It has a function called fmesher.exe (\xfemm_v3_0_win64.zip\xfemm_mingw_win64\cfemm\bin\fmesher.exe). It can be used with the command:
Code: Select all
fmesher --write-poly filename.fem
After that, just do:
Code: Select all
ElmerGrid 11 2 filename -autoclean
-
- Site Admin
- Posts: 4529
- Joined: 22 Aug 2009, 11:57
- Antispam: Yes
- Location: Espoo, Finland
- Contact:
Re: femm uses Triangle poly format internally
Hi gforti,
Nice advances in the workflow! Did you get to test also some computational results? It would certainly be nice to see comparison of those too.
-Peter
Nice advances in the workflow! Did you get to test also some computational results? It would certainly be nice to see comparison of those too.
-Peter