CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Native Meshers: blockMesh (http://www.cfd-online.com/Forums/openfoam-meshing-blockmesh/)
-   -   results with checkMesh...please comment (http://www.cfd-online.com/Forums/openfoam-meshing-blockmesh/79850-results-checkmesh-please-comment.html)

nileshjrane September 6, 2010 12:34

results with checkMesh...please comment
 
I have made a mesh in blockMesh after a long struggle. But now i am not able to run any kind of solver run with it. COmpressible, imcompressible, laminar, turbulent, inviscid, p-based, rho-based...nthing seems to work. Everytime i get huge negative pressures, huge courant numbers and divergence no matter what BC or solver setting i use.

So i am wondering is is because of the mesh??? Now my mesh is pretty coarse, no refinment at all. nice hex mesh, with only one problem, that i had to do mergepatchpairs and which gives some distorted cells.

This is the output of checkMesh:
Quote:

Create time

Create polyMesh for time = 0

Time = 0

Mesh stats
points: 62755
faces: 182738
internal faces: 175446
cells: 60000
boundary patches: 7
point zones: 1
face zones: 3
cell zones: 0

Overall number of cells of each type:
hexahedra: 55098
prisms: 4196
wedges: 0
pyramids: 0
tet wedges: 0
tetrahedra: 0
polyhedra: 706

Checking topology...
Boundary definition OK.
Point usage OK.
Upper triangular ordering OK.
Face vertices OK.
Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces ...
Patch Faces Points Surface topology
Combustor 1692 1854 ok (non-closed singly connected)
Head 1000 1040 ok (non-closed singly connected)
Fuelinlet 200 201 ok (non-closed singly connected)
AirinletX 400 401 ok (non-closed singly connected)
AirinletY 400 401 ok (non-closed singly connected)
Outlet 1200 1201 ok (non-closed singly connected)
Airpipe 2400 2544 ok (non-closed singly connected)

Checking geometry...
Overall domain bounding box (-0.089 -0.089 0) (0.17 0.17 1)
Mesh (non-empty, non-wedge) directions (1 1 1)
Mesh (non-empty) directions (1 1 1)
Boundary openness (-3.46157e-17 3.39964e-16 -3.75078e-16) OK.
***High aspect ratio cells found, Max aspect ratio: 1632.72, number of cells 400
<<Writing 400 cells with high aspect ratio to set highAspectRatioCells
Minumum face area = 1.24511e-09. Maximum face area = 0.00112629. Face area magnitudes OK.
Min volume = 2.37717e-10. Max volume = 4.87164e-06. Total volume = 0.0260461. Cell volumes OK.
Mesh non-orthogonality Max: 68.7054 average: 9.51964
Non-orthogonality check OK.
Face pyramids OK.
***Max skewness = 5.59368, 8 highly skew faces detected which may impair the quality of the results
<<Writing 8 skew faces to set skewFaces

Failed 2 mesh checks.

End

As you can see, i got 8 skew cells but max skewness is about 6. what this number 5.59 in checkmesh signifies??? What value is good?? (in Gambit 0.85 for hex is considered all right.)


And please give me some comment, that whether these few bad cells can be the nemesis of my simulation??? Should i think of remeshing??

Please help. I am already frustrated a lot:mad::mad:..

linnemann September 6, 2010 14:59

Hi

I would definitely re-mesh.

And if I were you I would isolate the bad cells using

foamToVTK -faceSet highAspectRatioCells (or cellSet cant remember)
foamToVTK -faceSet skewFaces

Open your original mesh and the the vtk files and highlight the vtk ones and see what aspects of your geometry creates the bad cells.
I've had similar problems where it turned out to be two edges lying very close to one another making it useless for any kind of solving, even though it was only 4 cells. Also an aspect ratio of 1600 is insane, this means you have a cell 1600 times longer than it is high/wide (correct me if I'm wrong).

you definitely have to get rid of the high aspect ratio cells and I would say with regards to skewness that if you want reliable/stable results I would stay below 2. I never have issues when I keep it in that range. Again you could go higher, but some care have to taken with regards to limiters/relaxation in fvSchemes and fvSolution

Hope this is useful in any way.

nileshjrane September 6, 2010 19:44

2 Attachment(s)
Hello Niels,

Thanx for the reply. It is helpful indeed. I m new to OF and i really want to get grip on it. And every bit of info is welcomed from me.:)

Well you are right about Aspect ratio (i read somewhere that OF does not accept cells with AR more than 1000, is that right???). I managed to get reed of them.

And your clue on locating bad cells is really helpful. I am actually trying to mesh a geometry in which two small pipes join one big cylinder. I could not mesh it using blockmesh by simple block decomposition so had to use "mergepatchpairs". This is giving those bad skewed cells. Please see the pictures attached. I have thought of a way to eliminate use of this "mergepatchpair" so i wont get these bad cells. Still out of curiosity, i would like to know is there any better way of doing this?? or may be using "mergepatchpair" in better way?? i tried to use fine mesh around the merged patches but it only makes situation bad. Any suggestion or guideline would be much appreciated.

One more question, if i may trouble you some more. How skewness is measured?? As far as i remember, in Fluent it ranges between 0 to 1. But in OF it can go more than 1 so certainly there is a difference in OF the way skewness is calculated. (The definition i know is something like this: skewness = max[ (90-anglemax)/90 , 90/(90-anglemin)] I remember it vaguely. This will give value bet 0 to 1)

Thank you very much for your help..Have a nice day..:)

MadsR January 21, 2011 06:00

Just for the record: aspect ratios of more than 1000 is by no means insane - we have it in airfoil aerodynamics all the time - and on wind turbine blades.

Aspect ratios of 1e5 or even higher is usual business when you want to have a first cell height of around 1e-6 chordLengths. checkMesh reports a problem with this, and I don't know how sensitive the OpenFOAM solver is to this (I am investigating that), but all (other) major CFD codes eats those bad aspect ratios with a smile.

/Mads

madeye May 7, 2011 09:27

i'm not sure if i'm right here, but since this is almost exactly the problem i have, i didn't want to open a new thread.
i also have similar outputs for checkMesh and my courant number explodes and it actually gives out 'nan' for it.

check Mesh tells me following:
Quote:

Checking geometry...
Domain bounding box: (-0.1 0 -0.025) (1.8 0.61 0.025)
Boundary openness (-6.91952e-19 -1.3839e-17 5.84483e-15) OK.
***High aspect ratio cells found, Max aspect ratio: 1.06743e+197, number of cells 888
<<Writing 888 cells with high aspect ratio to set highAspectRatioCells
Minumum face area = 0.00125. Maximum face area = 0.0025. Face area magnitudes OK.
Min volume = 2e-300. Max volume = 2e-300. Total volume = 1.776e-297. Cell volumes OK.
Mesh non-orthogonality Max: 180 average: 180
***Number of non-orthogonality errors: 1714.
<<Writing 1714 non-orthogonal faces to set nonOrthoFaces
***Error in face pyramids: 5328 faces are incorrectly oriented.
<<Writing 3614 faces with incorrect orientation to set wrongOrientedFaces
Max skewness = 2.57229e-14 OK.
All angles in faces OK.
Face flatness (1 = flat, 0 = butterfly) : average = 1 min = 1
All face flatness OK.

Failed 3 mesh checks.

End
also, when i try
Quote:

foamToVTK -faceSet highAspectRatioCells
it tells me this
Quote:

unexpected class name cellSet expected faceSet
while reading object highAspectRatioCells

file: /Users/connylenz/OpenFOAM/connylenz-1.5/run/interFoam/test8/constant/polyMesh/sets/highAspectRatioCells at line 15.

From function regIOobject::readStream(const word&)
in file db/regIOobject/regIOobjectRead.C at line 114.
i already also checked
Quote:

foamToVTK -faceSet wrongOrientedFaces
foamToVTK -faceSet nonOrthoFaces
which gave me these images
http://img218.imageshack.us/img218/6...orthofaces.png

http://img718.imageshack.us/img718/5...entedfaces.png

according to the images, all my faces are wrong orientated, which i really don't know how that could happen.
i really don't know what to think of them. they don't look bad at all. especially since i tried to keep the aspect ratio around 1.
interessting is as well, that the same mesh works for a different scale (when i mesh it smaller...)

are there any suggestions what best to do??


thanks in advance
conny

nileshjrane May 9, 2011 04:41

My guess would be...you have defined the hex blocks incorrectly..e.g. if correct hex block is (1 2 3 1 4 5 6 4) you might have done (1 2 3 1 5 4 6 5) or something like that..the wrongly oriented faces and the aspect ratio of e+197 suggest this thing..check your hex blocks...

madeye May 9, 2011 08:52

i figured it out. it was none of that. for some reason i changed convert to meters from 0.001 to 1 and changed my vertices, so that the numbers still have the same scale. i ended up without problems.
thanks anyways!


All times are GMT -4. The time now is 21:10.