femm uses Triangle poly format internally
Posted: 12 Mar 2023, 17:31
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.
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.