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

face order in fvMesh constructor

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

Reply
 
LinkBack Thread Tools Display Modes
Old   November 2, 2010, 06:59
Default face order in fvMesh constructor
  #1
New Member
 
Patricia
Join Date: Oct 2010
Posts: 22
Rep Power: 6
schmittp54 is on a distinguished road
Hello,
I am looking for information about the required order of faces in the faceList when using the constructor
Quote:
fvMesh(const IOobject &io, const Xfer< pointField > &points, const Xfer< faceList > &faces, const Xfer< labelList > &allOwner, const Xfer< labelList > &allNeighbour, const bool syncPar=true)
.

The following code fragment creates two connected hexahedrons with dimensions (dx,dy,dz)=(0.5,1,1) each. ParaView shows that an extra vertex has been created (first attached image).
If I reorder the faces 0..5 as shown in the commented section of the code, the paraFoam output looks good (second attached image).

Why is the order of the argument "const Xfer< faceList > &faces" relevant, and is the correct order documented anywhere?

Thanks
Patricia

Here is the code fragment, which creates a fvMesh from a pointField, faceList, owner and neighbour list:
Quote:
pointField p(12);
p[0]=vector(0,0,0);
p[1]=vector(.5,0,0);
p[2]=vector(1,0,0);
p[3]=vector(0,1,0);
p[4]=vector(.5,1,0);
p[5]=vector(1,1,0);

p[6]=vector(0,0,1);
p[7]=vector(.5,0,1);
p[8]=vector(1,0,1);
p[9]=vector(0,1,1);
p[10]=vector(.5,1,1);
p[11]=vector(1,1,1);

faceList f(11);
forAll(f,fI) f[fI]=face(4);

f[0][0]=0;f[0][1]=3;f[0][2]=4;f[0][3]=1;
f[1][0]=1;f[1][1]=4;f[1][2]=10;f[1][3]=7;
f[2][0]=6;f[2][1]=7;f[2][2]=10;f[2][3]=9;
f[3][0]=0;f[3][1]=6;f[3][2]=9;f[3][3]=3;
f[4][0]=3;f[4][1]=9;f[4][2]=10;f[4][3]=4;
f[5][0]=0;f[5][1]=1;f[5][2]=7;f[5][3]=6;
/*
f[0][0]=1;f[0][1]=4;f[0][2]=10;f[0][3]=7;
f[1][0]=3;f[1][1]=9;f[1][2]=10;f[1][3]=4;
f[2][0]=0;f[2][1]=6;f[2][2]=9;f[2][3]=3;
f[3][0]=0;f[3][1]=1;f[3][2]=7;f[3][3]=6;
f[4][0]=0;f[4][1]=3;f[4][2]=4;f[4][3]=1;
f[5][0]=6;f[5][1]=7;f[5][2]=10;f[5][3]=9;
*/
f[6][0]=1;f[6][1]=4;f[6][2]=5;f[6][3]=2;
f[7][0]=2;f[7][1]=5;f[7][2]=11;f[7][3]=8;
f[8][0]=7;f[8][1]=8;f[8][2]=11;f[8][3]=10;
f[9][0]=4;f[9][1]=10;f[9][2]=11;f[9][3]=5;
f[10][0]=1;f[10][1]=2;f[10][2]=8;f[10][3]=7;

labelList owners(11);
for (int i=0;i<6;i++) owners[i]=0;
for (int i=6;i<11;i++) owners[i]=1;
labelList neighbours(1);
neighbours[0]=1;

fvMesh *mesh=new fvMesh(
Foam::IOobject
(
Foam::fvMesh::defaultRegion,
"constant",
runTime,
Foam::IOobject::NO_READ
),
p,f,owners,neighbours
);
mesh->write();
Attached Images
File Type: png wrong.png (7.5 KB, 10 views)
File Type: png correct.png (5.7 KB, 7 views)
schmittp54 is offline   Reply With Quote

Old   November 2, 2010, 10:01
Default
  #2
Senior Member
 
Stefan Herbert
Join Date: Dec 2009
Location: Darmstadt, Germany
Posts: 129
Rep Power: 8
herbert is on a distinguished road
Hi Patricia,

I haven't worked with this constructor yet, but in general the internal faces of a mesh have to be on top of the faceList (in your case only the face 4(1 4 10 7), therefore it must be the first element). I'm not sure, if the order of the boundary faces is important, too, but you can check (just make sure, that the internal face is the first one).

In addition the faces should be defined obeying the right-hand-rule but you have already done this way.

Regards,
Stefan
herbert is offline   Reply With Quote

Old   November 2, 2010, 10:42
Default
  #3
New Member
 
Patricia
Join Date: Oct 2010
Posts: 22
Rep Power: 6
schmittp54 is on a distinguished road
Thank you, Herbert

after reading your reply I have also found this explanation in the Wiki:
Quote:
faces for each face an ordered list of point labels. The normal (righthand rule) should point away from the owner cell (so the boundary faces point out of the domain)
The face ordering is quite intricate:
- internal faces get ordered such that when stepping through the higher numbered neighbouring cells in incremental order one also steps through the corresponding faces in incremental order (upper-triangular ordering)
- boundary faces are bunched per patch. The boundary file then tells where the start and size of the patch are in the faces list. For coupled faces there is an additional ordering inside the patch:
  • cyclics: should be ordered such that face 'i' is coupled to face 'i + size()/2' where size() is the number of faces of the patch. Additionally the 0th point of a face is considered coupled to the 0th point of its coupled face.
  • processor: should be ordered such that face 'i' on one processor is coupled to face 'i' on the neighbouring processor. Same additional constraint on the order of the points in a face as cyclics.
Both your answer and the wiki explain why my ordering was wrong.

Thanks
Patricia
schmittp54 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


Similar Threads
Thread Thread Starter Forum Replies Last Post
Import netgen mesh to OpenFOAM hsieh Open Source Meshers: Gmsh, Netgen, CGNS, ... 32 September 13, 2011 05:50
BlockMeshmergePatchPairs hjasak OpenFOAM Native Meshers: blockMesh 11 August 15, 2008 07:36
fluent add additional zones for the mesh file SSL FLUENT 2 January 26, 2008 12:55
Axisymmetrical mesh Rasmus Gjesing (Gjesing) OpenFOAM Native Meshers: blockMesh 10 April 2, 2007 14:00
Trimmed cell and embedded refinement mesh conversion issues michele OpenFOAM Other Meshers: ICEM, Star, Ansys, Pointwise, GridPro, Ansa, ... 2 July 15, 2005 04:15


All times are GMT -4. The time now is 00:29.