BUG: foamMeshToFluent writes empty brackets in msh file

Summary

foamMeshToFluent writes empty brackets in the msh file in the "caption" of the very last section when the names ans types of the domains and the boundaries are declared, p.e.

(12 (1 1 a94fc 1 0)(
4 4 ... 4 4)**()**)
(39 (1 fluid fluid-1)())
(39 (2 interior interior-1)())
...

Those empty brackets () cause ICEM to throw the following error when importing the mesh file: icem read_rampant_file() expecting '(' and got 41 Although, the mesh is imported, the boundary and domain names aren't.

Steps to reproduce

Export a mesh from any OpenFoam test case to Fluent msh via foamMeshToFluent

Environment information

• OpenFOAM version : v2006
• Operating system : ubuntu1804@WSL@Win10

Possible fixes

Removing the empty brackets in the mentioned header enables ICEM to properly read in all mesh informations.

From this unoffcial document, they define trailing empty () after names. Not sure if this was always incorrect, has changed, or if ICEM is buggy.

What documents do you have?

The empty () after the names are correct and they aren't the problem here. The problem are the empty () after the mixed cell zone definition, starting with (12...

In the source you linked, there are no empty () either after t_lastcell:

(12 (id c1 c2 1 0) (
t1 t2 t3 ... t_lastcell
))

Hi @DaveD - it was only a minor fix, but took some time to get to it. Can verify what you said (ie, the extra brackets are definitely not in the documentation). Also verified that the corrected format can also be parsed back in with fluentMeshToFoam.

Thanks! /mark

closed via commit bed1305d

mentioned in commit d19515bf

mentioned in commit 00d50349

mentioned in commit fbbff15e

Fixed in maintenance branches for 1812, 1906, 1912, 2006. While fix in develop after next re-merge.

reopened

Hi @DaveD - could you please recheck this? By inspection, it seems that the mesh conversion might be faulty.

Looking at this line with the neighbour face, it seems rather suspicious to me. The list of neighbour faces is shorter than the list of owner faces. In the best case, the number of faces is incorrect and the neighbour info is rubbish. In the worst case, it might even segfault.

Hey @mark, from your unofficial document, there is no advice under ch. 3. FACE THREADS , that also the neighbour faces have to be written to the mesh file. Those would be duplicates anyway, that a parser (also fluentMeshToFoam?) would dismiss? Am I seeing that right?

In the earliest versions of OpenFOAM, the list of neighbour faces was the same length as the list of the own faces, with the boundary faces being marked with -1 (ie, no neighbour). Can't remember exactly when this changed, but the neighbour list is now always shorter than the own list.

• owner: length = nFaces = (nInternalFaces + nBoundaryFaces)
• neighbour: length = nInternalFaces

So looping over owner is ok, but shouldn't access neighbour if the face is >= nInternalFaces (rubbish, segfault). This is why I wonder that it even works.

Also, from the unofficial docs, they state

3. Define face threads as sets of connections of the nodes. Each face will indicate a c0 and c1 cell. All internal faces have a c0 and c1, boundary faces only have a c0 (and c1 = 0).

So this would be fine with the old definition (neighbour = -1, add 1 to that gives 0). But I wonder about the ordering. The docs says c1 = 0, but the conversion has neighbour/owner, not owner/neighbour.

Hmmm, I think we understand it wrong, but it is also not clearly described:

n1, n2, n3, n4 = circuit of nodes that define face as defined by the right-hand rule RHRule points to C0 cell. Boundary cells are defined such that the rhrule points inward. c0 = index of cell pointed to by the rhrule of the face. c0 never = 0 c1 = index of c1 cell (opposite c0). c1 = 0 on boundaries.

It only says, that the right-hand-rule always points to cell c0 and for boundary cells, the RHR points inward (i.e. c0=owner cell, c1=0). Maybe, for internal faces, the RHR always points outwards (i.e. c0=neighbor, c1=owner)...

For boundary faces, this is recognized in the code in line 212. The loop in line 137 is obviously only over the internal faces, while the loop in line 159 is over the boundary patches/ faces only. So maybe there is no error in the code (and has never been)...

I checked the other direction (parsing fluent -> OpenFOAM). There it clearly expects neighbour/owner (not owner/neighbour) in general, but also has some flipping code if the owner is > neighbour. This means that the order is consistent in both cases. For the boundary patch, the owner face is flipped on writing (apparently that is what Fluent uses: inward oriented), which will be re-flipped on reading again.

I've done some code cleanup. Could you test how the attached files work for you? foamMeshToFluent-test.tar.gz

"c0 = index of cell pointed to by the rhrule of the face"

Cool - that is clearer.

mentioned in commit bed1305d

closed

mentioned in issue #2249 (closed)

@mark Exported the pitzdaily case with foamMeshToFluent v2012. Both Fluent and ICEM (2021 R1) can import the mesh and its boundary. However there's some warning message from ICEM:

Changed invalid part name "__noname__" to "__NONAME__".
Changed invalid part name "inlet" to "INLET".
Changed invalid part name "outlet" to "OUTLET".
Changed invalid part name "upperWall" to "UPPERWALL".
Changed invalid part name "lowerWall" to "LOWERWALL".
Changed invalid part name "frontAndBack" to "FRONTANDBACK".

Is it normal?

@xuegy It should be normal, since ICEM operates with uppercase names only.

mentioned in issue #2675