[ChukerSweet]

Hi guys! New here.
I'm trying to define a simple cube.

vertices
(
(0 0 0)
(1.125 0 0)
(1.125 0 0.05)
(0 0 0.05)
(0 0.1875 0)
(1.125 0.1875 0)
(1.125 0.1875 0.05)
(0 0.1875 0.05)
);

blocks
(
hex (0 4 5 1 3 2 6 7) (20 20 1) simpleGrading (1 1 1)
);

The idea in the order of the vertices in hex is to have the normal pointing outside right?
so the face 0451 and 3267 point in opposite direction...
from guide
"the ordering of the point labels is such that the face normal points outside of the computational domain"

Well ofcourse it doesn't work.
If I try hex (0 1 5 4 3 2 6 7) so both normal point out to the same direction ( like it is in the cavity or any of the blocks in the damBreak example ) doesn't work either.

The error is :
"face 0 in patch 0 does not have neighbour cell face: 4(0 4 7 3)"

Plz help, why is my order wrong? And why do we have to put the vertices in order in the first place, if we are going to set each boundary condition specifying the face anyway?

[alexeym]

Hi,

in fact the error is not in block definition but in boundary description. Can you post whole blockMeshDict?

[ChukerSweet]

Ohhh. Here is the whole thing.

convertToMeters 0.1;

vertices
(
(0 0 0)
(1.125 0 0)
(1.125 0 0.05)
(0 0 0.05)
(0 0.1875 0)
(1.125 0.1875 0)
(1.125 0.1875 0.05)
(0 0.1875 0.05)
);

blocks
(
hex (0 4 5 1 3 2 6 7) (20 20 1) simpleGrading (1 1 1)
);

edges
(
);

// ************************************************** *********************** //
boundary
(
fixedWalls
{
type wall;
faces
(
(0 3 7 4)
(1 0 4 5)
(3 2 6 7)
(1 5 6 2)
);
}
frontAndBack
{
type empty;
faces
(
(0 1 2 3)
(4 7 6 5)
);
}
);

mergePatchPairs
(
);

// ************************************************** *********************** //

[alexeym]

Hi,

I don't know what you're trying to achieve but the following blockMeshDict (I did not change the rest of the dictionary)

convertToMeters 0.1;

vertices
(
 (0 0 0)
 (1.125 0 0)
 (1.125 0.1875 0)
 (0 0.1875 0)
 (0 0 0.05)
 (1.125 0 0.05)
 (1.125 0.1875 0.05)
 (0 0.1875 0.05)
);

blocks
(
hex (0 1 2 3 4 5 6 7) (20 20 1) simpleGrading (1 1 1)
);

generates mesh without any complains. You definition of block generated a mesh with negative volume, meaning you've done mistake in numbering nodes of the block (but as the order of vertices was very inconvenient, I've decided skip looking for the error).

[ChukerSweet]

yes you were right.
now with
hex (0 1 5 4 3 2 6 7)
and then boundaries
(0 3 7 4)
(1 0 4 5)
(3 2 6 7)
(1 5 6 2)
(0 1 2 3)
(4 7 6 5)

Works just fine. I don't understand however why the order in the hex definition is relevant at all. if it has the vertices referred to a single system of coo anyway.

[Bernhard]

See here: http://www.openfoam.org/docs/user/blockMesh.php

You don't only generate the geometry, but also want to now how it is oriented. Therefore, based on the ordering of the points, some internal coordinate system for the hex can be defined, which makes all kinds of calculations and definitions simple. Basically you will end up mixing minus signs, which does all weird checks. blockMesh cannot deduce what you actually intended to do, so it is better that is just fails, so that you can correct your dictionary according to the instructions Finding these errors is really cumbersome, and mostly it helps you more to start from scratch

[ChukerSweet]

yes indeed that seams to be the case. For now I just adopted the convention that the normal of both faces should agree. Moreover this should happen in the same directions for all the elements that compose my 2D system.
Thanks allot for the replies!