[ashishmagar600]

Hello,

I am trying to convert an OpenFOAM mesh from binary to ascii. The binary mesh was previously generated from StarCCM.

However, on conversion to ascii, the neighbour cellIds are shown as "-1" for most of the end part.

Here is the neighbour file:

461199
(
1
2
3
4
56786
4
5
7
56788
57202
.....

-1
-1
-1
-1
-1
-1
-1
-1
-1
)

I have never encountered such an issue, nor am I able to find such a thing anywhere on the forum.

Any suggestions are welcome.

Thanks.

PS: I did checkMesh, it didn't throw any error related to this.

[wyldckat]

Originally Posted by ashishmagar600

I am trying to convert an OpenFOAM mesh from binary to ascii. The binary mesh was previously generated from StarCCM.

Quick request: Please elaborate on how exactly you converted the Star-CCM+ mesh to OpenFOAM mesh, because this looks like a problem with the conversion.

[ashishmagar600]

I don't know exactly how the mesh was converted, I was only given the OF mesh. (There is another team working on it, I will see and ask them how they converted to OF).

However, I noted that when I write the neighbors from the code

        labelList  m_nei( mesh.neighbour() );        

        for( label i=0; i < m_nei.size(); i++)
        {
                OS1 << m_nei[i] << nl;
        }

and then write it to a file, it entirely skips the "-1" values.

Exmaple:
neighbour file from polyMesh/

1184680
(
1
2
87465
5
7
6
7
...
357970
357971
357971
357972
357972
-1
-1
...
-1
)

And neighbour printed from code:

992701
(
1
2
87465
5
7
...
357970
357971
357971
357972
357972
)

Surprisingly, it has skipped all the "-1" values.

[wyldckat]

Quick answer: Then the -1 values might be a bug from the mesh export tool that the other team used.

And if OpenFOAM was able to ignore the -1 values, I guess it shouldn't be a problem. But this is meant to be a fairly rare problem, because I don't remember ever seeing this before.

I can only guess that the -1 values appeared because the mesh exporter was being literal about an interface, for example, a baffle where the faces that were once shared between cells, where split into two sides and the cells were uncoupled, leaving behind a loose -1 indication of the neighbour cell that used to have.

[deepsterblue]

OpenFOAM meshes place boundary faces at the end of the face list (after all interior faces), and since boundary faces do not possess a neighbor cell, the neighbor value was automatically assigned a value of -1, to keep the owner / neighbor list lengths equal. I believe this practice was abandoned sometime circa OF-1.4, presumably due to storage considerations. But for backwards compatibility, such meshes are still supported in current versions. The polyMesh code simply truncates the list to the number of interior faces.

[ashishmagar600]

Thank you @deepsterblue and @wyldcat, for helping out.

@wyldcat, please mark this thread as solved.

Thanks a lot.