|
[Sponsors] |
![]() |
![]() |
#1 |
New Member
sandip
Join Date: Jan 2012
Posts: 20
Rep Power: 14 ![]() |
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 . |
|
![]() |
![]() |
![]() |
![]() |
#2 |
Senior Member
Niels Gjoel Jacobsen
Join Date: Mar 2009
Location: Copenhagen, Denmark
Posts: 1,901
Rep Power: 37 ![]() ![]() |
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 |
|
![]() |
![]() |
![]() |
![]() |
#3 |
Disabled
Join Date: Mar 2011
Posts: 174
Rep Power: 15 ![]() |
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. |
|
![]() |
![]() |
![]() |
![]() |
#4 |
Senior Member
David Gaden
Join Date: Apr 2009
Location: Winnipeg, Canada
Posts: 437
Rep Power: 22 ![]() |
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 |
|
![]() |
![]() |
![]() |
![]() |
#5 |
New Member
sandip
Join Date: Jan 2012
Posts: 20
Rep Power: 14 ![]() |
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. |
|
![]() |
![]() |
![]() |
![]() |
#6 |
Senior Member
Daniel WEI (老魏)
Join Date: Mar 2009
Location: Beijing, China
Posts: 689
Blog Entries: 9
Rep Power: 21 ![]() |
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 |
|
![]() |
![]() |
![]() |
![]() |
#7 |
Senior Member
Niels Gjoel Jacobsen
Join Date: Mar 2009
Location: Copenhagen, Denmark
Posts: 1,901
Rep Power: 37 ![]() ![]() |
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]] } Kind regards, Niels |
|
![]() |
![]() |
![]() |
![]() |
#8 |
Senior Member
Sandeep Menon
Join Date: Mar 2009
Location: Amherst, MA
Posts: 403
Rep Power: 25 ![]() |
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).
|
|
![]() |
![]() |
![]() |
![]() |
#10 |
Senior Member
Daniel WEI (老魏)
Join Date: Mar 2009
Location: Beijing, China
Posts: 689
Blog Entries: 9
Rep Power: 21 ![]() |
Owner index must be smaller than neighbour index, right?
__________________
~ Daniel WEI ------------- Boeing Research & Technology - China Beijing, China |
|
![]() |
![]() |
![]() |
![]() |
#11 |
Senior Member
Fumiya Nozaki
Join Date: Jun 2010
Location: Yokohama, Japan
Posts: 266
Blog Entries: 1
Rep Power: 19 ![]() |
You are absolutely correct, owner index < neighbour index.
Please see the following URL: http://openfoamwiki.net/index.php/Write_OpenFOAM_meshes. |
|
![]() |
![]() |
![]() |
![]() |
#12 | |
Senior Member
Daniel WEI (老魏)
Join Date: Mar 2009
Location: Beijing, China
Posts: 689
Blog Entries: 9
Rep Power: 21 ![]() |
I saw a warning from here,
Quote:
Any ideas?
__________________
~ Daniel WEI ------------- Boeing Research & Technology - China Beijing, China |
||
![]() |
![]() |
![]() |
![]() |
#13 |
Senior Member
Sandeep Menon
Join Date: Mar 2009
Location: Amherst, MA
Posts: 403
Rep Power: 25 ![]() |
Take a look at the renumberMesh source code. It'll tell you how ordering needs to be done.
|
|
![]() |
![]() |
![]() |
![]() |
#14 |
Senior Member
Daniel WEI (老魏)
Join Date: Mar 2009
Location: Beijing, China
Posts: 689
Blog Entries: 9
Rep Power: 21 ![]() |
Oh, cool, after renumber the mesh, everything is fine!
__________________
~ Daniel WEI ------------- Boeing Research & Technology - China Beijing, China |
|
![]() |
![]() |
![]() |
![]() |
#15 |
Member
Jack
Join Date: Aug 2012
Posts: 47
Rep Power: 14 ![]() |
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 |
|
![]() |
![]() |
![]() |
![]() |
#16 |
Senior Member
Sandeep Menon
Join Date: Mar 2009
Location: Amherst, MA
Posts: 403
Rep Power: 25 ![]() |
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. |
|
![]() |
![]() |
![]() |
![]() |
#17 |
Member
Jack
Join Date: Aug 2012
Posts: 47
Rep Power: 14 ![]() |
Thank you very much!
Jack |
|
![]() |
![]() |
![]() |
![]() |
#18 | |
Member
Lianhua Zhu
Join Date: Aug 2011
Location: Wuhan, China
Posts: 35
Rep Power: 15 ![]() |
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:
|
||
![]() |
![]() |
![]() |
![]() |
#19 | |
Member
Lianhua Zhu
Join Date: Aug 2011
Location: Wuhan, China
Posts: 35
Rep Power: 15 ![]() |
Quote:
Lianhua |
||
![]() |
![]() |
![]() |
|
|