# owner and neighbor

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

 January 5, 2012, 09:19 owner and neighbor #1 New Member   sandip Join Date: Jan 2012 Posts: 20 Rep Power: 7 Sponsored Links 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 .

 January 5, 2012, 09:27 #2 Senior Member   Niels Gjoel Jacobsen Join Date: Mar 2009 Location: Deltares, Delft, The Netherlands Posts: 1,749 Rep Power: 29 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

 January 5, 2012, 12:08 #3 Senior Member   Join Date: Mar 2011 Posts: 174 Rep Power: 8 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.

 January 5, 2012, 13:35 #4 Senior Member   David Gaden Join Date: Apr 2009 Location: Winnipeg, Canada Posts: 436 Rep Power: 15 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

 January 7, 2012, 12:56 owner and neighbor #5 New Member   sandip Join Date: Jan 2012 Posts: 20 Rep Power: 7 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. kaifu likes this.

 January 5, 2013, 16:46 #6 Senior Member     Daniel WEI (老魏) Join Date: Mar 2009 Location: Beijing, China Posts: 689 Blog Entries: 9 Rep Power: 14 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 ------------- Boeing Research & Technology - China Beijing, China Email

 January 5, 2013, 17:51 #7 Senior Member   Niels Gjoel Jacobsen Join Date: Mar 2009 Location: Deltares, Delft, The Netherlands Posts: 1,749 Rep Power: 29 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

 January 5, 2013, 22:59 #8 Senior Member   Sandeep Menon Join Date: Mar 2009 Location: Amherst, MA Posts: 392 Rep Power: 17 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

 January 6, 2013, 17:12 #9 Senior Member     Daniel WEI (老魏) Join Date: Mar 2009 Location: Beijing, China Posts: 689 Blog Entries: 9 Rep Power: 14 haha, I see, thank you guys! __________________ ~ Daniel WEI ------------- Boeing Research & Technology - China Beijing, China Email

 January 10, 2013, 02:11 #10 Senior Member     Daniel WEI (老魏) Join Date: Mar 2009 Location: Beijing, China Posts: 689 Blog Entries: 9 Rep Power: 14 Owner index must be smaller than neighbour index, right? __________________ ~ Daniel WEI ------------- Boeing Research & Technology - China Beijing, China Email

 January 10, 2013, 06:00 #11 Senior Member   Fumiya Nozaki Join Date: Jun 2010 Location: Yokohama, Japan Posts: 217 Blog Entries: 1 Rep Power: 11 You are absolutely correct, owner index < neighbour index. Please see the following URL: http://openfoamwiki.net/index.php/Write_OpenFOAM_meshes.

January 10, 2013, 12:54
#12
Senior Member

Daniel WEI (老魏)
Join Date: Mar 2009
Location: Beijing, China
Posts: 689
Blog Entries: 9
Rep Power: 14
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
-------------
Boeing Research & Technology - China
Beijing, China
Email

 January 10, 2013, 12:57 #13 Senior Member   Sandeep Menon Join Date: Mar 2009 Location: Amherst, MA Posts: 392 Rep Power: 17 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

 January 10, 2013, 12:58 #14 Senior Member     Daniel WEI (老魏) Join Date: Mar 2009 Location: Beijing, China Posts: 689 Blog Entries: 9 Rep Power: 14 Oh, cool, after renumber the mesh, everything is fine! __________________ ~ Daniel WEI ------------- Boeing Research & Technology - China Beijing, China Email

 February 21, 2013, 09:47 #15 Member   Jack Join Date: Aug 2012 Posts: 47 Rep Power: 7 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

 February 21, 2013, 09:58 #16 Senior Member   Sandeep Menon Join Date: Mar 2009 Location: Amherst, MA Posts: 392 Rep Power: 17 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

 February 21, 2013, 10:02 #17 Member   Jack Join Date: Aug 2012 Posts: 47 Rep Power: 7 Thank you very much! Jack

August 3, 2014, 02:14
#18
Member

Lianhua Zhu
Join Date: Aug 2011
Location: Wuhan, China
Posts: 35
Rep Power: 8
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
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();

const Field<Type>& issf = ssf;

forAll(owner, facei)
{

}

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)
{
}
}```

Bests,

Lianhua

Quote:
 Originally Posted by ngj 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

August 3, 2014, 03:17
#19
Member

Lianhua Zhu
Join Date: Aug 2011
Location: Wuhan, China
Posts: 35
Rep Power: 8
Quote:
 Originally Posted by zhulianhua 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& gGrad = tgGrad(); const labelUList& owner = mesh.owner(); const labelUList& neighbour = mesh.neighbour(); const vectorField& Sf = mesh.Sf(); Field& igGrad = gGrad; const Field& 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& 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

 Thread Tools Display Modes Linear Mode

 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 OffTrackbacks are On Pingbacks are On Refbacks are On Forum Rules