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

vertice ordering?

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

Like Tree1Likes
  • 1 Post By AmiN.D

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   December 22, 2011, 02:38
Red face vertice ordering?
  #1
New Member
 
Balaji Sankar
Join Date: Nov 2011
Posts: 19
Rep Power: 14
Bajji is on a distinguished road
Hi,

I am trying to write the blockmeshDict file. can somebody please say how should i order my vertices?

1) where should my origin be in the block ? with the origin, I can figure out the direction using the right handed coordinate system but where to put my origin?
I have seen the user guide but no help in this..

Pl help. am getting tonnes of wrong oriented faces in checkMesh..
Bajji is offline   Reply With Quote

Old   December 22, 2011, 03:09
Default
  #2
Senior Member
 
Bernhard
Join Date: Sep 2009
Location: Delft
Posts: 790
Rep Power: 21
Bernhard is on a distinguished road
The ordering of your points is not important. The ordering in the face and the hexes is. The face should be oriented such, the normal (defined via right-hand-rule) is pointing outward. In other wards: If you look from the inside out, you should order the point in a clockwise manner.

The numbering of the hexes is given in Fig 5.5: http://www.openfoam.org/docs/user/blockMesh.php

Have fun
Bernhard is offline   Reply With Quote

Old   December 22, 2011, 05:29
Default
  #3
New Member
 
Balaji Sankar
Join Date: Nov 2011
Posts: 19
Rep Power: 14
Bajji is on a distinguished road
Thanks for the reply.
Sorry i didn't put my question correctly. I try again:

1)in each hex block, i should start numbering from on vertex. How should i chose which vertex to start from? Once i know the starting vertex, I can start from there and move along the edges as shown in the user guide.

2) how should i orient the local co ordinate axis at the starting vertex? i can figure out that first i have to go along x(x1) , then in the direction of y(x2), finally in the direction of z(x3). After this i go along x and y in the new plane that is offset from the old one. But in which direction should i orient the local x axis in the first place?

Pl help.
Bajji is offline   Reply With Quote

Old   December 23, 2011, 06:09
Red face origin of hex block
  #4
New Member
 
Balaji Sankar
Join Date: Nov 2011
Posts: 19
Rep Power: 14
Bajji is on a distinguished road
Hi ,

I am am still having the same problem. I am trying to mesh the space between 2 concentric cylinders and i couldn't figure out where to put the origin of each hex block.
I am ok with numbering scheme of faces, to have the normal pointing out.
In my attempts, I get a good mesh until 3 quadrants, shown in pic2. But when i join the fourth and final hex block to the third and first, I get blockmesh error:

--> FOAM FATAL IO ERROR:
ill defined primitiveEntry starting at keyword 'blocks' on line 40 and ending at line 115

file: /home/balaji/OpenFOAM/balaji-2.0.1/run/cc7/constant/polyMesh/blockMeshDict at line 115.

From function primitiveEntry::readEntry(const dictionary&, Istream&)
in file db/dictionary/primitiveEntry/primitiveEntryIO.C at line 165.

FOAM exiting

I have put the order of my origins in each block in pic 1 ( it is z=0 plane).
I have also posted my blockMeshDict. Some body pl help..
Attached Images
File Type: jpg origin of each block.jpg (12.2 KB, 84 views)
File Type: jpg 3quadrants.jpg (10.8 KB, 108 views)
Attached Files
File Type: zip blockMeshDict.zip (1,011 Bytes, 49 views)
Bajji is offline   Reply With Quote

Old   December 23, 2011, 13:38
Default
  #5
Senior Member
 
mturcios777's Avatar
 
Marco A. Turcios
Join Date: Mar 2009
Location: Vancouver, BC, Canada
Posts: 740
Rep Power: 28
mturcios777 will become famous soon enough
Make sure to read over your blockMesh file very carefully. Your blocks are defined just fine. You are missing a space on your last hex definition, between simpleGrading and the left parenthesis.

For future reference, when OF gives you an ill defined primitiveEntry error (in any input file), that means there is something wrong with the syntax, and you've likely missed a space/comma/colon/semicolon etc.
mturcios777 is offline   Reply With Quote

Old   December 24, 2011, 12:52
Talking Thanks a lot.....
  #6
New Member
 
Balaji Sankar
Join Date: Nov 2011
Posts: 19
Rep Power: 14
Bajji is on a distinguished road
Thanks a thousand^thousand ton .
I got the mesh finally to look right. I didn't know blockMesh was so picky.
Thanks a lot mturcios777.
Have put a pic of my mesh below.
Attached Images
File Type: jpg mesh.jpg (17.3 KB, 85 views)
Bajji is offline   Reply With Quote

Old   March 29, 2012, 03:30
Default
  #7
Member
 
Join Date: Nov 2009
Location: Germany
Posts: 96
Rep Power: 16
val46 is on a distinguished road
Hi Bernhard,

Quote:
The ordering of your points is not important.
Are you sure about that?

The user guide says:

Quote:
- the x1 direction is described by moving from vertex 0 to vertex 1;
- the x2 direction is described by moving from vertex 1 to vertex 2;
I ordered my points in a different order and got tons of errors.


Best Regards,
Toni
__________________
"When I meet God, I am going to ask him two questions: Why relativity? And why turbulence? I really believe he will have an answer for the first." Werner Heisenberg
val46 is offline   Reply With Quote

Old   March 29, 2012, 03:38
Default
  #8
Senior Member
 
Bernhard
Join Date: Sep 2009
Location: Delft
Posts: 790
Rep Power: 21
Bernhard is on a distinguished road
What you mention comes in only at the point where you define your blocks. This has to be consistent with the order in the vertices subdict. If you change the ordering in vertices, you have to change the numbers in your block and patch definitions.
Bernhard is offline   Reply With Quote

Old   March 29, 2012, 04:11
Default
  #9
Member
 
Join Date: Nov 2009
Location: Germany
Posts: 96
Rep Power: 16
val46 is on a distinguished road
Hi Bernard,
thanks for your fast reply.
If I understand you right, it doesn't matter how I order my vertices as long as the new order matches the correct block definition.

My model consists of many blocks. I went back to just 2 blocks to see what I'm doing wrong:


Code:
convertToMeters 0.001;

vertices
(

    (0 0 0)
    (10 0 0)
    (30 0 0)

    (0 0 10)
    (10 0 10)
    (30 0 10)

    (0 8 0)
    (10 8 0)
    (30 8 0)

    (0 8 10)
    (10 8 10)
    (30 8 10)

);

blocks
(
    hex (0 1 4 3 6 7 10 9) (20 10 10) simpleGrading (1 1 1)
    hex (1 2 5 4 7 8 11 10) (10 10 10) simpleGrading (1 1 1)
);

edges
(
);

boundary
(
    inlet
    {
        type patch;
        faces
        (
            ( 0 6 9 3 )                
        );
    }
    outlet
    {
        type patch;
        faces
        (
            ( 2 8 11 5 )               
        );
    }
    sym_front
    {
        type symmetryPlane;
        faces
        (
            (0 1 4 3)
            (1 2 5 4)
        );
    }
    sym_back
    {
        type symmetryPlane;
        faces
        (
            ( 6 7 10 9 )
            ( 7 8 11 10 )
        );
    }
    sym_up
    {
        type symmetryPlane;
        faces
        (
            ( 3 4 10 9 )
            ( 4 5 11 10 )                                 
        );
    }
    walls_solids
    {
        type wall;
        faces
        (
            ( 0 1 7 6 )
            ( 1 2 8 7 )
                              
        );
    }
);

mergePatchPairs
(
);
Now I get a mesh with these warnings:

Code:
--> FOAM Warning : 
    From function cellModel::mag(const labelList&, const pointField&)
    in file meshes/meshShapes/cellModel/cellModel.C at line 128
    zero or negative pyramid volume: -133.3333 for face 0
My new guess is I have wrong face orientations. What do you think?
__________________
"When I meet God, I am going to ask him two questions: Why relativity? And why turbulence? I really believe he will have an answer for the first." Werner Heisenberg
val46 is offline   Reply With Quote

Old   March 29, 2012, 04:18
Default
  #10
Senior Member
 
Bernhard
Join Date: Sep 2009
Location: Delft
Posts: 790
Rep Power: 21
Bernhard is on a distinguished road
Please make a sketch of your situation and follow the order in the as in the manual. You're now defining them the wrong way around:

Code:
 hex( 0 1 7 6 3 4 10 9)
 hex( 1 2 8 7 4 5 11 10)
or
Code:
 hex (0 3 4 1 6 9 10 7)
 hex(1 4 5 2 7 10 11 8)
Bernhard is offline   Reply With Quote

Old   March 29, 2012, 08:28
Default
  #11
Member
 
Join Date: Nov 2009
Location: Germany
Posts: 96
Rep Power: 16
val46 is on a distinguished road
Finally...

I tried your first suggestion.
(I couldn't see how the second suggestion differs from my first try.)
It works, thank you!

Because of your help and the user guide i got it working.
__________________
"When I meet God, I am going to ask him two questions: Why relativity? And why turbulence? I really believe he will have an answer for the first." Werner Heisenberg
val46 is offline   Reply With Quote

Old   January 24, 2017, 01:39
Default ill defined primitiveEntry starting at keyword 'vertices' on line 21 and ending at li
  #12
New Member
 
sudhakar singh
Join Date: Jun 2016
Posts: 12
Rep Power: 9
Sud09463 is on a distinguished road
hello,
I am trying to create a cuboid mesh using blockMesh having 5 blocks, one at centre and other four blocks around the central one. but after running the blockMesh command, i am getting following error and i am not able to figure out my mistake.

--> FOAM FATAL IO ERROR:
"ill defined primitiveEntry starting at keyword 'vertices' on line 21 and ending at line 107"

file: /home/sud/mmcRun/CH4D60/constant/polyMesh/blockMeshDict at line 107.

From function primitiveEntry::readEntry(const dictionary&, Istream&)
in file lnInclude/IOerror.C at line 132.

FOAM exiting

My blockMeshDict file is:

convertToMeters 0.001;

vertices
(
(-22.85 -22.85 0) //0
(22.85 -22.85 0) //1
(22.85 22.85 0) //2
(-22.85 22.85 0) //3

(-91.40 -91.40 0) //4
(91.40 -91.40 0 //5
(91.40 91.40 0) //6
(-91.40 91.40 0) //7

(-22.85 -22.85 470) //8
(22.85 -22.85 470) //9
(22.85 22.85 470) //10
(-22.85 22.85 470) //11

(-91.40 -91.40 470) //12
(91.40 -91.40 470) //13
(91.40 91.40 470) //14
(-91.40 91.40 470) //15
);

blocks
(
hex (0 1 2 3 8 9 10 11) (40 40 240) simpleGrading (1 1 1) //centre
hex (3 2 6 7 11 10 14 15) (40 40 240) simpleGrading (1 1 1) //top
hex (4 0 3 7 12 8 11 15) (40 40 240) simpleGrading (1 1 1) //left
hex (5 1 0 4 13 9 8 12) (40 40 240) simpleGrading (1 1 1) //bottom
hex (5 6 2 1 13 14 10 9) (40 40 240) simpleGrading (1 1 1) //right
);

edges
(
);

boundary
(
outlet
{
type patch;
physicalType particleOutflow;
faces
(
(11 10 9 8)
(15 14 10 11)
(15 11 8 12)
(8 9 13 12)
(10 14 13 9)
);
}

side
{
type patch;
physicalType particleOutflow;
faces
(
(6 5 13 14)
(7 6 14 15)
(4 7 15 12)
(5 4 12 13)
);
}

inletCoflow
{
type patch;
physicalType noParticleOutflow;
faces
(
(0 1 2 3)
(2 6 7 3)
(3 7 4 0)
(0 4 5 1)
(1 5 6 2)
);
}

);

mergePatchPairs
(
);


can someone figure out where i am making mistake?
Sud09463 is offline   Reply With Quote

Old   June 18, 2020, 15:36
Unhappy
  #13
New Member
 
AmiN
Join Date: Nov 2014
Posts: 13
Rep Power: 11
AmiN.D is on a distinguished road
Can someone help me with the HEX order? I'm trying to do an elbow simulation and dont have problem defining the first two blocks, but i'm getting this error which means my third hex is not right handed and Idk why it's not!

--> FOAM FATAL IO ERROR:
Block hex (9 8 12 13 11 10 14 15) (10 10 10) simpleGrading (1(1) 1(1) 1(1)) has inward-pointing faces
4(13 15 14 12) 4(9 13 12 8) 4(11 10 14 15)




Code:
convertToMeters 1;
convertToMeters 1;

vertices
(


(0 0 0) //0
(0.2 0 0) //1
(0.2 0.0355 0) //2
(0 0.0355  0) //3
(0 0 0.01) //4
(0.2 0 0.01) //5
(0.2 0.0355 0.01) //6
(0 0.0355 0.01) //7


//Elbow
//(0.2 0 0) //""1""
(0.26775 0.06775 0) //8
(0.23225 0.06775 0) //9
//(0.2 0.0355 0) //"""2"""
//(0.2 0 0.01) //"""5"""
(0.26775 0.06775 0.01) //10
(0.23225 0.06775 0.01) //11
(0.2 0.0355 0.01) // 6//

//Right blocks

//third

  //(0.23225 0.06775 0)  //9
  //(0.26775 0.06775 0) //8
  (0.26775 0.41775 0) //12
  (0.23225 0.41775 0) //13
  //(0.23225 0.06775 0.01) //11
  //(0.2 0.06775 0) //10
  (0.26775 0.41775 0.01) //14
  (0.23225 0.41775 0.01) //15
);

blocks
(
    hex (0 1 2 3 4 5 6 7) (10 10 10) simpleGrading (1 1 1)
    hex (1 8 9 2 5 10 11 6) (10 10 10) simpleGrading (1 1 1)
    hex (9 8 12 13 11 10 14 15) (10 10 10) simpleGrading (1 1 1)
);

edges
(
  arc  2 9 (0.22281 0.04494 0)
  arc  6 11 (0.22281 0.04494 0.01)
  arc 1 8 (0.2479 0.01984 0)
  arc 5 10 (0.2479 0.01984 .01)
);

boundary
(

    inlet
      {
        type patch;
        faces
        (
        (3 0 4 7)
      );}
);

mergePatchPairs
(
);
hhu_lulu likes this.
AmiN.D is offline   Reply With Quote

Reply

Tags
blockmesh, hex, origin, vertice

Thread Tools Search this Thread
Search this Thread:

Advanced Search
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 Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
area does not match neighbour by ... % -- possible face ordering problem St.Pacholak OpenFOAM 10 February 7, 2024 22:50
[Commercial meshers] Face ordering problem for nonrectangular cyclic boundary conditions cfdmarkus OpenFOAM Meshing & Mesh Conversion 3 August 17, 2011 16:07
possible face ordering problem prameelar OpenFOAM 0 August 15, 2011 14:45
[blockMesh] Cyclic BC's: Possible face ordering problem? (Channel flow) sega OpenFOAM Meshing & Mesh Conversion 3 September 28, 2010 13:46
Upper triangular ordering deepsterblue OpenFOAM Running, Solving & CFD 0 December 3, 2007 12:41


All times are GMT -4. The time now is 07:11.