CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Meshing & Mesh Conversion (https://www.cfd-online.com/Forums/openfoam-meshing/)
-   -   [Technical] [solved] Neighbour cellId as "-1" (https://www.cfd-online.com/Forums/openfoam-meshing/217175-solved-neighbour-cellid-1-a.html)

ashishmagar600 May 2, 2019 08:39
[solved] Neighbour cellId as "-1"
 
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:
Code:

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 May 5, 2019 10:12
Quote:
Originally Posted by ashishmagar600 (Post 732525)
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 May 6, 2019 01:45
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
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/
Code:
1184680
(
1
2
87465
5
7
6
7
...
357970
357971
357971
357972
357972
-1
-1
...
-1
)
And neighbour printed from code:
Code:
992701
(
1
2
87465
5
7
...
357970
357971
357971
357972
357972
)

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

wyldckat May 6, 2019 19:26
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 May 7, 2019 00:21
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 May 7, 2019 03:54
Thank you @deepsterblue and @wyldcat, for helping out.

@wyldcat, please mark this thread as solved.

Thanks a lot.


All times are GMT -4. The time now is 08:40.