Skip to content

foamMeshToFluent delivers meshes that are non-conformal with specifications and that are incompatible with Fluent utility tmerge

Summary

When a mesh is exported from OpenFoam in Fluent format using foamMeshToFluent, a msh is generated that consists of several sections with a defined structure, see e.g. here or here.

The exported mesh can be read into Ansys Fluent and ICEM without any problems. However, if the officially shipped Ansys utility tmerge is used for merging two or more msh files into one, the merged mesh shows artifacts when loaded into Fluent. The same occurs, when tmerge is only given one msh file and writes it to new msh file that should in theory have an identical content as the input file (unless of some differences in formatting). However, this is not the case. tmerge writes a wrong number of points into the point section header:

original msh file after tmerge
grafik grafik

As a consequence, Fluent does not import all nodes of the new msh file but only a few, while all other nodes fall down to (0,0,0), which creates the artifacts after import. After some trial and error, the reason seems to be the id that foamMeshToFluent writes in the node header. While Ansys assigns id 3 per default (e.g. when exporting a mesh from Ansys Meshing to msh file), foamMeshToFluentwrites id 1. This interferes with id 1, which is also used for the cell header. When manually changing the node header id from 1 to 3, tmerge does the correct job and all artifacts are gone.

Steps to reproduce

  1. Export an arbitrary blockMesh with foamMeshToFluent:

  2. Load this msh file in Fluent and display mesh -> everything looks fine.

  3. Take the same msh file, let it run through tmerge and write it to a new msh file:

    Windows: "C:\Program Files\ANSYS Inc\v231\fluent\fluent23.1.0\utility\tmerge\win64\tm3d.exe" case.msh case_new.msh

    Linux: ./mnt/software/ansys_inc/v231/fluent/fluent23.1.0/utility/tmerge/lnamd64/tmerge_3d case.msh case_new.msh

  4. Load this new msh file in Fluent and display mesh -> mesh has artifacts.

What is the current bug behaviour?

foamMeshToFluent defines the node section in a msh file under id 1 (see last line):

(0 "FOAM to Fluent Mesh File")

(0 "Dimension:")
(2 3)

(0 "Grid dimensions:")
(10 (0 1 163c 0 3))
(12 (0 1 efa 0 0))
(13 (0 1 339c 0 0))

(10 (1 1 163c 1 3)
...

What is the expected correct behavior?

Ansys always defined the node section in a msh file with id 3 as per default (see last line):

(0 grid written by ANSYS Meshing
   nodes:       (10 (id start end type) (x y z ...))
              faces:       (13 (id start end type elemType)
                (v-0 v-1 .. v-n right-cell left-cell ...))
   cells:       (12 (id start end type elemtype))
   parent-face: (59 (start end parent child) (nchilds child0 child1 ...))
)
(2 3)
(10 (0 1 c 0))
(13 (0 1 b 0))
(12 (0 1 2 0))
(10 (3 1 c 1 3)(
...

Relevant logs and/or images

grafik

Environment information

  • OpenFOAM version : v2212, 10 and all previous
  • Operating system : Ubuntu 2204 LTS @ WSL2.0 and all other systems

Possible fixes

In /usr/lib/openfoam/openfoam2212/applications/utilities/mesh/conversion/foamMeshToFluent/fluentFvMesh.C, the first 1 after (10 ( in line 104 should simply be replaced by a 3 (see last line):

    // Writing points
    fluentMeshFile
            << "(10 (3 1 ";
 
    fluentMeshFile.setf(ios::hex, ios::basefield);
    fluentMeshFile
        << nPoints() << " 1 3)"
        << std::endl << "(" << std::endl;

There will be no negative consequences/ interference as foamMeshToFluent specifies

  • the internal faces under id 2 ff.: << "(13 (2 1 ..." (ll. 135 f.),
  • boundary faces starting from id 10 (hex a): << "(13 (" << patchi + 10 << ... (ll. 71 f.) and
  • cells under id 1: << "(12 (1 1 " << ... (ll. 221 f.)

Hence, ids 3 to 9 are unused and may be used for node header id. To be consistent with Ansys, I would choose id 3 as suggested above.

Edited by Dave