CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM

owner and neighbor

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree1Likes
  • 1 Post By deepsterblue

Reply
 
LinkBack Thread Tools Display Modes
Old   January 5, 2012, 09:19
Default owner and neighbor
  #1
New Member
 
sandip
Join Date: Jan 2012
Posts: 20
Rep Power: 5
vmsandip2011 is on a distinguished road
can anybody suggest some links or resources which will give more information about the owner and neighbor file how the connectivity is defined etc.
I tried to read user guide but very less information is given there
thanks in advance .
vmsandip2011 is offline   Reply With Quote

Old   January 5, 2012, 09:27
Default
  #2
ngj
Senior Member
 
Niels Gjoel Jacobsen
Join Date: Mar 2009
Location: Rotterdam, The Netherlands
Posts: 1,592
Rep Power: 24
ngj will become famous soon enoughngj will become famous soon enough
Hi Sandip

The owner/neighbour list are given for each and every face in the computational domain (the neighbour, however, is -1 for boundary faces).

So for face number 0, you could have that owner[0] = 10 and neighbour[0] = 114, which means that the owner cell has index 10, whereas the neighbour cell has index 114. I would recommend to loop over the neighbour list only for the internal faces, as I recall that it might actually not have the size of all of the faces, but only the size of the number of internal faces.

Kind regards,

Niels
ngj is offline   Reply With Quote

Old   January 5, 2012, 12:08
Default
  #3
Senior Member
 
Join Date: Mar 2011
Posts: 174
Rep Power: 6
anon_a is on a distinguished road
You may also be interested in Hrvoje Jasak's Ph.D. dissertation, section 3.2
http://powerlab.fsb.hr/mwg-internal/...?id=4AI5YdtMgD
Even if it is not entirely what you want, it contains a lot of useful stuff and is a must read.
anon_a is offline   Reply With Quote

Old   January 5, 2012, 13:35
Default
  #4
Senior Member
 
David Gaden
Join Date: Apr 2009
Location: Winnipeg, Canada
Posts: 397
Rep Power: 12
marupio is on a distinguished road
Each internal face in a mesh has an "owner" and a "neighbour" cell. These are the two cells it borders. There's nothing special about this, and if you are talking only about geometry, we don't need to tell them apart... but since the algorithms need consistent directions for fluxes, we must distinguish them. A positive flux goes from "owner" to "neighbour".

If you are just looking at the text in the file, here's what it means:

The owner and neighbour files each contain a list of cell numbers. The position in that list is the face number. For example:

(
0 // this is face 0
0 // this is face 1
0 // this is face 2
1 // this is face 3
1 // this is face 4
... etc.

So, face 2's "owner" is cell 0, face 4's "owner" is cell 1, and so on.
Note that the owner file is longer than the neighbour file... that's because the owner file also lists boundary faces, whereas the neighbour file does not.

I think I got that right. Keep me honest...
__________________
~~~
Follow me on twitter @DavidGaden
marupio is offline   Reply With Quote

Old   January 7, 2012, 12:56
Default owner and neighbor
  #5
New Member
 
sandip
Join Date: Jan 2012
Posts: 20
Rep Power: 5
vmsandip2011 is on a distinguished road
Thanks for the information.
This means if i have 2 different files like follow :
owner
0
0
1
1
2
2
.
.
.
.
etc.

neighbor
1
20
2
21
3
.
.
.
.
etc.
It gives me information like
face 0 's owner is cell 0 and its neighbor is cell 1
face 1 's owner is cell 0 and its neighbor is cell 20
face 2 's owner is cell 1 and its neighbor is cell 2
So basically it will give me the connectivity information about the cells.
Please correct me if i am wrong.

with regards.
vmsandip2011 is offline   Reply With Quote

Old   January 5, 2013, 16:46
Default
  #6
Senior Member
 
lakeat's Avatar
 
Daniel WEI (老魏)
Join Date: Mar 2009
Location: South Bend, IN, USA
Posts: 688
Blog Entries: 9
Rep Power: 12
lakeat is on a distinguished road
Send a message via Skype™ to lakeat
Does this mean in file "faces" the index order of the faces must be put in this way so that internal faces come first and then all the boundary faces that dont have neighboring cells? If not, how could it identify which face doesn't have any neighbour cell?

If what I am saying above is correct, I am wondering why not keep the "neighbour" array the same size as the "owner" array? And fill in "-1" in the "neighbour" array for all the faces that dont have an neighboring cell. By doing so, the index ordering of the faces in "faces" wont be a problem any more.
__________________
~
Daniel WEI
-------------
NatHaz Modeling Laboratory
Department of Civil & Environmental Engineering & Earth Sciences
University of Notre Dame, USA
Email || My Personal CFD Blog
lakeat is offline   Reply With Quote

Old   January 5, 2013, 17:51
Thumbs up
  #7
ngj
Senior Member
 
Niels Gjoel Jacobsen
Join Date: Mar 2009
Location: Rotterdam, The Netherlands
Posts: 1,592
Rep Power: 24
ngj will become famous soon enoughngj will become famous soon enough
Hi Daniel,

The easy answer to this question is that if you mix internal and boundary faces into a random ordering, then you would either have to have an additional ordering list to know, which faces are internal, or you would have to perform an additional "if" every time you want to loop over all internal faces (which is done a lot, so that would be prohibitively expensive).

In the way it is done you know for sure and without any risk of segmentation fault that the following can be performed (on the top of my head, so perhaps not fully correct)

Code:
const unallocLabelList & own( mesh.owner() );
const unallocLabelList & nei( mesh.neighbour() );

for( label i=0; i < mesh.nInternalFaces(); i++)
{
    // some operation of volfield[own[i]] and volfield[nei[i]]
}
and then you can afterwards safely treat the boundary faces in whatever way you want.

Kind regards,

Niels
ngj is offline   Reply With Quote

Old   January 5, 2013, 22:59
Default
  #8
Senior Member
 
Sandeep Menon
Join Date: Mar 2009
Location: Amherst, MA
Posts: 386
Rep Power: 15
deepsterblue will become famous soon enough
If you had boundary faces scattered in the faces list, the boundary patches would have to maintain a list of indices... Right now, only a start index and patch size is sufficient. Not to mention the extra storage associated with unnecessary -1's for boundaries (the way it was in OF-1.3 and before).
ngj likes this.
__________________
Sandeep Menon
University of Massachusetts Amherst
https://github.com/smenon
deepsterblue is offline   Reply With Quote

Old   January 6, 2013, 17:12
Default
  #9
Senior Member
 
lakeat's Avatar
 
Daniel WEI (老魏)
Join Date: Mar 2009
Location: South Bend, IN, USA
Posts: 688
Blog Entries: 9
Rep Power: 12
lakeat is on a distinguished road
Send a message via Skype™ to lakeat
haha, I see, thank you guys!
__________________
~
Daniel WEI
-------------
NatHaz Modeling Laboratory
Department of Civil & Environmental Engineering & Earth Sciences
University of Notre Dame, USA
Email || My Personal CFD Blog
lakeat is offline   Reply With Quote

Old   January 10, 2013, 02:11
Default
  #10
Senior Member
 
lakeat's Avatar
 
Daniel WEI (老魏)
Join Date: Mar 2009
Location: South Bend, IN, USA
Posts: 688
Blog Entries: 9
Rep Power: 12
lakeat is on a distinguished road
Send a message via Skype™ to lakeat
Owner index must be smaller than neighbour index, right?
__________________
~
Daniel WEI
-------------
NatHaz Modeling Laboratory
Department of Civil & Environmental Engineering & Earth Sciences
University of Notre Dame, USA
Email || My Personal CFD Blog
lakeat is offline   Reply With Quote

Old   January 10, 2013, 06:00
Default
  #11
Senior Member
 
Fumiya Nozaki
Join Date: Jun 2010
Location: Yokohama, Japan
Posts: 168
Rep Power: 7
fumiya is on a distinguished road
You are absolutely correct, owner index < neighbour index.
Please see the following URL:
http://openfoamwiki.net/index.php/Write_OpenFOAM_meshes.
fumiya is offline   Reply With Quote

Old   January 10, 2013, 12:54
Default
  #12
Senior Member
 
lakeat's Avatar
 
Daniel WEI (老魏)
Join Date: Mar 2009
Location: South Bend, IN, USA
Posts: 688
Blog Entries: 9
Rep Power: 12
lakeat is on a distinguished road
Send a message via Skype™ to lakeat
I saw a warning from here,
Quote:
In particular, the faces in the mesh will be reordered in the upper triangular order, i.e. the ordering of the faces depends on the ordering of the cells. Writing the files yourself will not guarantee that the ordering is optimised for OpenFOAM.
Anyone knows what is the trick in making "the ordering of the faces depends on the ordering of the cells"? As I am writing mesh generator myself, and the writing is so far so good until I found a error warning during the checkMesh complaining about the "upper triangular order".

Any ideas?
__________________
~
Daniel WEI
-------------
NatHaz Modeling Laboratory
Department of Civil & Environmental Engineering & Earth Sciences
University of Notre Dame, USA
Email || My Personal CFD Blog
lakeat is offline   Reply With Quote

Old   January 10, 2013, 12:57
Default
  #13
Senior Member
 
Sandeep Menon
Join Date: Mar 2009
Location: Amherst, MA
Posts: 386
Rep Power: 15
deepsterblue will become famous soon enough
Take a look at the renumberMesh source code. It'll tell you how ordering needs to be done.
__________________
Sandeep Menon
University of Massachusetts Amherst
https://github.com/smenon
deepsterblue is offline   Reply With Quote

Old   January 10, 2013, 12:58
Default
  #14
Senior Member
 
lakeat's Avatar
 
Daniel WEI (老魏)
Join Date: Mar 2009
Location: South Bend, IN, USA
Posts: 688
Blog Entries: 9
Rep Power: 12
lakeat is on a distinguished road
Send a message via Skype™ to lakeat
Oh, cool, after renumber the mesh, everything is fine!
__________________
~
Daniel WEI
-------------
NatHaz Modeling Laboratory
Department of Civil & Environmental Engineering & Earth Sciences
University of Notre Dame, USA
Email || My Personal CFD Blog
lakeat is offline   Reply With Quote

Old   February 21, 2013, 09:47
Default
  #15
Member
 
Jack
Join Date: Aug 2012
Posts: 42
Rep Power: 4
JackW is on a distinguished road
Hi,

So I have two quick questions if that's ok!

Is the cell index a free choice? i.e. the numbers that appear in the owner file (obviously they have to be consistent with each other). I mean that with the face/points information OF knows of the cells.

Also I have read the Mesh Description page and I am a little confused with this -1 talk, as I have never seen it before. If I omit them from my neighbours/owners files does OF know automatically that these omitted faces are on the boundary and how do I set my start face in this file - is it just that in the faces file I have to put these consecutively?

Thanks a lot,

Jack
JackW is offline   Reply With Quote

Old   February 21, 2013, 09:58
Default
  #16
Senior Member
 
Sandeep Menon
Join Date: Mar 2009
Location: Amherst, MA
Posts: 386
Rep Power: 15
deepsterblue will become famous soon enough
Although cell indices can be a free choice in theory, it's hard to maintain them in arrays if there are gaps in the cell numbering order. It's probably a safer option to make sure they are numbered sequentially in a continuous way.

Starting with OF-1.4.1 (I think), there's no need to store -1's for boundaries, and even if it is written that way in the neighbour file, OF currently knows to ignore them for backward compatibility, and truncates the array at the number of internal faces.
__________________
Sandeep Menon
University of Massachusetts Amherst
https://github.com/smenon
deepsterblue is offline   Reply With Quote

Old   February 21, 2013, 10:02
Default
  #17
Member
 
Jack
Join Date: Aug 2012
Posts: 42
Rep Power: 4
JackW is on a distinguished road
Thank you very much!

Jack
JackW is offline   Reply With Quote

Old   August 3, 2014, 02:14
Default
  #18
New Member
 
Lianhua Zhu
Join Date: Aug 2011
Location: Wuhan, China
Posts: 28
Rep Power: 5
zhulianhua is on a distinguished road
Hi, Niels,

I have a question for the the understanding of the implementation of boudary condition for the gaussGrad scheme. I think it has something to do with this post, so I post here.

The code below is form
https://github.com/OpenFOAM/OpenFOAM...ad/gaussGrad.C
We can see, the first forAll() expression loops over the owner list, so for the cell adjacent to the boundary, the facei is the boundary face, that means the neighbour[facei] is -1, but how can we index igGrad with -1?
Code:
 GeometricField<GradType, fvPatchField, volMesh>& gGrad = tgGrad();

    const labelUList& owner = mesh.owner();
    const labelUList& neighbour = mesh.neighbour();
    const vectorField& Sf = mesh.Sf();

    Field<GradType>& igGrad = gGrad;
    const Field<Type>& issf = ssf;

    forAll(owner, facei)
    {
        GradType Sfssf = Sf[facei]*issf[facei];

        igGrad[owner[facei]] += Sfssf;
        igGrad[neighbour[facei]] -= Sfssf;
    }

    forAll(mesh.boundary(), patchi)
    {
        const labelUList& pFaceCells =
            mesh.boundary()[patchi].faceCells();

        const vectorField& pSf = mesh.Sf().boundaryField()[patchi];

        const fvsPatchField<Type>& pssf = ssf.boundaryField()[patchi];

        forAll(mesh.boundary()[patchi], facei)
        {
            igGrad[pFaceCells[facei]] += pSf[facei]*pssf[facei];
        }
    }

Bests,

Lianhua

Quote:
Originally Posted by ngj View Post
Hi Daniel,

The easy answer to this question is that if you mix internal and boundary faces into a random ordering, then you would either have to have an additional ordering list to know, which faces are internal, or you would have to perform an additional "if" every time you want to loop over all internal faces (which is done a lot, so that would be prohibitively expensive).

In the way it is done you know for sure and without any risk of segmentation fault that the following can be performed (on the top of my head, so perhaps not fully correct)

Code:
const unallocLabelList & own( mesh.owner() );
const unallocLabelList & nei( mesh.neighbour() );

for( label i=0; i < mesh.nInternalFaces(); i++)
{
    // some operation of volfield[own[i]] and volfield[nei[i]]
}
and then you can afterwards safely treat the boundary faces in whatever way you want.

Kind regards,

Niels
zhulianhua is offline   Reply With Quote

Old   August 3, 2014, 03:17
Default
  #19
New Member
 
Lianhua Zhu
Join Date: Aug 2011
Location: Wuhan, China
Posts: 28
Rep Power: 5
zhulianhua is on a distinguished road
Quote:
Originally Posted by zhulianhua View Post
Hi, Niels,

I have a question for the the understanding of the implementation of boudary condition for the gaussGrad scheme. I think it has something to do with this post, so I post here.

The code below is form
https://github.com/OpenFOAM/OpenFOAM...ad/gaussGrad.C
We can see, the first forAll() expression loops over the owner list, so for the cell adjacent to the boundary, the facei is the boundary face, that means the neighbour[facei] is -1, but how can we index igGrad with -1?
Code:
 GeometricField<GradType, fvPatchField, volMesh>& gGrad = tgGrad();

    const labelUList& owner = mesh.owner();
    const labelUList& neighbour = mesh.neighbour();
    const vectorField& Sf = mesh.Sf();

    Field<GradType>& igGrad = gGrad;
    const Field<Type>& issf = ssf;

    forAll(owner, facei)
    {
        GradType Sfssf = Sf[facei]*issf[facei];

        igGrad[owner[facei]] += Sfssf;
        igGrad[neighbour[facei]] -= Sfssf;
    }

    forAll(mesh.boundary(), patchi)
    {
        const labelUList& pFaceCells =
            mesh.boundary()[patchi].faceCells();

        const vectorField& pSf = mesh.Sf().boundaryField()[patchi];

        const fvsPatchField<Type>& pssf = ssf.boundaryField()[patchi];

        forAll(mesh.boundary()[patchi], facei)
        {
            igGrad[pFaceCells[facei]] += pSf[facei]*pssf[facei];
        }
    }

Bests,

Lianhua
I know why. After testing with a simple case, I found that the mesh.owner() and mesh.neighbour() return only the internal faces' owners and neighbours.

Lianhua
zhulianhua is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT -4. The time now is 12:24.