|
[Sponsors] |
[blockMesh] Why is this cube not well define? |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
June 17, 2014, 11:48 |
Why is this cube not well define?
|
#1 |
New Member
Lala Sasa
Join Date: Jun 2014
Posts: 16
Rep Power: 12 |
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? |
|
June 17, 2014, 11:54 |
|
#2 |
Senior Member
|
Hi,
in fact the error is not in block definition but in boundary description. Can you post whole blockMeshDict? |
|
June 17, 2014, 12:52 |
|
#3 |
New Member
Lala Sasa
Join Date: Jun 2014
Posts: 16
Rep Power: 12 |
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 ( ); // ************************************************** *********************** // |
|
June 17, 2014, 13:28 |
|
#4 |
Senior Member
|
Hi,
I don't know what you're trying to achieve but the following blockMeshDict (I did not change the rest of the dictionary) Code:
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) ); |
|
June 17, 2014, 13:35 |
|
#5 |
New Member
Lala Sasa
Join Date: Jun 2014
Posts: 16
Rep Power: 12 |
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. |
|
June 18, 2014, 03:23 |
|
#6 |
Senior Member
Bernhard
Join Date: Sep 2009
Location: Delft
Posts: 790
Rep Power: 22 |
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 |
|
June 18, 2014, 07:02 |
|
#7 |
New Member
Lala Sasa
Join Date: Jun 2014
Posts: 16
Rep Power: 12 |
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! |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
HELP----Surface Reaction UDF | Ashi | Fluent UDF and Scheme Programming | 1 | May 19, 2020 21:13 |
Define new turbulence model in Fluent | micro11sl | Fluent UDF and Scheme Programming | 55 | October 27, 2016 17:25 |
Cooling cube in a room | John_Major | System Analysis | 0 | July 4, 2015 03:24 |
udf problem | eb.nabizadeh | Fluent UDF and Scheme Programming | 2 | March 1, 2013 00:28 |
Installing OF 1.6 on Mac OS X | gschaider | OpenFOAM Installation | 129 | June 19, 2010 09:23 |