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/)
-   -   cyclic && Non-orthogonality !! (http://www.cfd-online.com/Forums/openfoam-meshing-blockmesh/118410-cyclic-non-orthogonality.html)

ali jafari May 27, 2013 09:08

cyclic && Non-orthogonality !!
 
hi

I have flow between two cylinders their top and bottom are cyclic(see attached file). after >blockMesh "OKmesh" display on terminal , but >checkMesh display a fail mesh (nonorthogonality face ) when I see these faces in paraview I find cyclic boundary !!
I check orientations of faces and other blockmesh rules but have not effect
Note : this error occurs in OF 2.2.0 , checkmesh in other version dose not display any error!:confused:
/*--------------------------------*- C++ -*----------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 2.1.1 |
| \\ / A nd | Web: www.OpenFOAM.org |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
FoamFile
{
version 2.0;
format ascii;
class dictionary;
object blockMeshDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

//convertToMeters 0.1;

vertices
(
(0 0.5 0) //0
//inner , bottom circles
(0 0.5 0) //1
(0.5 0 0) //2
(0 -0.5 0) //3
(-0.5 0 0) //4
//outer , bottom circles
(0 0.566 0) //5
(0.566 0 0) //6
(0 -0.566 0) //7
(-0.566 0 0) //8
//inner , top circles
(0 0.5 0.66) //9
(0.5 0 0.66) //10
(0 -0.5 0.66) //11
(-0.5 0 0.66) //12
//outer , top circles
(0 0.566 0.66) //13
(0.566 0 0.66) //14
(0 -0.566 0.66) //15
(-0.566 0 0.66) //16


);

blocks
(
hex (9 13 14 10 1 5 6 2) (35 104 90) simpleGrading (1 1 1) //first 1/4
hex (9 12 16 13 1 4 8 5) (104 35 90) simpleGrading (1 1 1) //2nd 1/4
hex (12 11 15 16 4 3 7 8) (104 35 90) simpleGrading (1 1 1) //3th 1/4
hex (10 14 15 11 2 6 7 3) (35 104 90) simpleGrading (1 1 1) //4th 1/4

//hex (1 5 7 3 9 11 15 13) (4 4 4) simpleGrading (1 1 1) //right half
//hex (1 3 7 5 9 13 15 11) (4 4 4) simpleGrading (1 1 1)
);

edges
(
// in - bottom circle
arc 2 1 (0.3428 0.3639 0)
arc 2 3 (0.3428 -0.3639 0)
arc 3 4 (-0.3428 -0.3639 0)
arc 4 1 (-0.3428 0.3639 0)

// out - bottom circle
arc 5 6 (0.4174 0.3823 0)
arc 6 7 (0.4174 -0.3823 0)
arc 7 8 (-0.4174 -0.3823 0)
arc 8 5 (-0.4174 0.3823 0)

// in - top circle
arc 9 10 (0.3428 0.3639 0.66)
arc 10 11 (0.3428 -0.3639 0.66)
arc 11 12 (-0.3428 -0.3639 0.66)
arc 12 9 (-0.3428 0.3639 0.66)

// out - top circle
arc 13 14 (0.4174 0.3823 0.66)
arc 14 15 (0.4174 -0.3823 0.66)
arc 15 16 (-0.4174 -0.3823 0.66)
arc 16 13 (-0.4174 0.3823 0.66)

);

boundary
(
out
{
type wall;
faces
(
(13 14 6 5)
(13 16 8 5)
(14 15 7 6)
(15 16 8 7)
);
}

in
{
type wall;
faces
(
(1 2 10 9)
(1 4 12 9)
(10 11 3 2)
(11 12 4 3)
);
}

top
{
type cyclic;
neighbourPatch bottom;

faces
(
(16 12 9 13)
(16 15 11 12)
(11 15 14 10)
(14 13 9 10)


);

}

bottom
{
type cyclic;
neighbourPatch top;

faces
(
(8 4 1 5)
(8 7 3 4)
(3 7 6 2)
(6 5 1 2)

);
}

);

mergePatchPairs
(

);

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

Yosmcer May 27, 2013 09:56

1 Attachment(s)
Hello,

Why did you put two points (0 and 1) at the same place?
You do not use the 0 one.

I launched your mesh with
Code:

paraFoam -block
I attached a screenshot of the result. The block are represented by trapezoidal one, this is the way the -block function work, in reality, they follow the edges.

The first 4 blocks are well defined (if the 0 is not considered), but I see a problem with the two last:
//hex (1 5 7 3 9 11 15 13) (4 4 4) simpleGrading (1 1 1) //right half
//hex (1 3 7 5 9 13 15 11) (4 4 4) simpleGrading (1 1 1)

As I can see, all these points are coplanar, so cannot constitute any block.

[EDIT]Sorry, they cannot be the problem as they are commented[/EDIT]

Yosmcer

ali jafari May 27, 2013 12:06

thank you for quick reply but two last dont important because these just note , you can delete them.

please tell me your idea clearly , thank you

Yosmcer May 27, 2013 12:57

2 Attachment(s)
Quote:

Originally Posted by ali jafari (Post 430321)
thank you for quick reply but two last dont important because these just note , you can delete them.

Oh, yes, I was distracted, they are commented, so they cannot be the problem.
Sorry.

[EDIT]

I have the same error with checkMesh:
Code:

Checking geometry...
    Overall domain bounding box (-0.566 -0.566 0) (0.566 0.566 0.66)
    Mesh (non-empty, non-wedge) directions (1 1 1)
    Mesh (non-empty) directions (1 1 1)
    Boundary openness (-7.75343e-16 1.43147e-15 -5.31732e-17) OK.
    Max cell openness = 3.24349e-16 OK.
    Max aspect ratio = 4.38502 OK.
    Minimum face area = 1.38286e-05. Maximum face area = 6.26916e-05.  Face area magnitudes OK.
    Min volume = 1.04619e-07. Max volume = 1.18166e-07.  Total volume = 0.145991.  Cell volumes OK.
    Mesh non-orthogonality Max: 180 average: 7.01164
 ***Number of non-orthogonality errors: 29120.
  <<Writing 29120 non-orthogonal faces to set nonOrthoFaces
    Face pyramids OK.
    Max skewness = 0.019251 OK.
    Coupled point location match (average 0) OK.

Failed 1 mesh checks.

But once I defined cyclic boundary fields for the top and bottom patches in the U and p files, paraFoam runs stressfully without errors.

Code:

(...)
    top
    {
        type            cyclic;
    }

    bottom
    {
        type            cyclic;
    }
(...)

I put all the case I used to sample this blockMeshDict file in attachment.

Yosmcer May 31, 2013 11:56

Is your problem solved?

If I change the patch type to patch instead of cyclic, there is no more non-orthogonality errors.
If I look to the number of non-orthogonality errors, it is equal to 104*35*8 so proportional to two meshing dimensions, but not to the third (90).

However, this error do not prevent you to run the case (I tested with icoFoam, this is just slow as you have a big amount of cells).

[EDIT]

This problem seems to be already known and look solved in the next OpenFOAM version:

http://www.cfd-online.com/Forums/ope...d-2-2-0-a.html

ali jafari May 31, 2013 13:49

thanks for your contribution .
yes , it seems a bug ! I couldn't solve this problem. I changed nCorrector and NnonorthogonalCorrection , but it just was useful for icoFoam and and it didn't work for steady-state solver-problem (simpleFoam) . my problem is steady-state and I'm confused....icoFoam very slow for my case and dont converge to stationary solution.

PLEASE HELP OpenFoam EXPERT !!!!!!!!!! :(

Yosmcer May 31, 2013 14:39

Quote:

Originally Posted by ali jafari (Post 431259)
My problem is steady-state and I'm confused....icoFoam very slow for my case and dont converge to stationary solution.

PLEASE HELP OpenFoam EXPERT !!!!!!!!!! :(

I'm unfortunately not an expert. I noticed that it is slow to run, but I think it is because of the number of nodes. The more node you have, the more time it will take.

Maybe you could try with a less accurate mesh (eg: (5 45 52) instead of (35 90 104)) for the tests, and put the good mesh when you want the best results.

I never used simpleFoam cause icoFoam was asked in the work I had to do, so I cannot help with it.

For icoFoam, pay attention to the Courant Number. Max Courant Number must be under 1 to converge.
You can change this number by changing the mesh resolution and the time step.
It is displayed at each iteration.
See point 2.1.6.2 in tutorial.

I think icoFoam is enough for steady-state, but simpleFoam should also work.

If you think your problem is related to the mesh (But it seams that this IS OK as the non-orthogonality errors seems to not cause problem and just a bug), the tread could be continued here.
If you think the problem is about using the solver (which I think is), you may ask for help in a solver part of the forum, you will have more expert on this.
If you do so, put a link here and say if solved.

Hope you will find the solution.


All times are GMT -4. The time now is 19:23.