[maddalena]

Hello everybody,
I have the same problem as above: for an airfoil at Re 1.5*10^6, cl matches well with theoretical value, while cd is two times the wanted cd. I am using kOmegaSST as implemented in OF (and not with the lowRe variation), y+ is between 30 and 110 everywhere, with an average value of 70. The fvSchemes is as follows:

• gradSchemes: faceMDLimited Gauss linear 0.5;
• divSchemes: Gauss linearUpwind cellLimited Gauss linear 1;
• laplacianSchemes: Gauss linear limited 0.5 or 0.33

I have tried different grids and different turbulence schemes (kEpsilon, RNGkEpsilon, realizableKE, kOmega) but I have not succeded in reducing the difference. The low-Re model cases are not converging, even with low relaxation, finer grid at the boundary layer and potentialFoam initialization.
Is there anyone that has some ideas on what can be the cause of the problem? Something else I can try or I can check?
Suggestions are welcome.
Cheers

mad

[MadsR]

Hi Mad

In general you will have a hard time not overpredicting drag and even more so if you have such high y+ as you have. Correct drag prediction is highly dependent on resolving the viscous effects in the boundary layer. You normally need a low-Re turbulence model (i.e. no wall functions) and a y+ of no more than 2. Cl is normally not a problem to predict correctly as it is mainly pressure driven. Actually 100% overprediction of drag is not unheard of, but you should be able to get down to "only" 10-20% overprediction of drag. This all is quite dependent of type of airfoil, angle of attack (HIGHLY - in the linear, substall, region you should be able to do fine), CFD package, turbulence model, 2D/3D, transition modelling, etc.

/Mads

[maddalena]

Originally Posted by MadsR

In general you will have a hard time not overpredicting drag and even more so if you have such high y+ as you have. Correct drag prediction is highly dependent on resolving the viscous effects in the boundary layer. You normally need a low-Re turbulence model (i.e. no wall functions) and a y+ of no more than 2.
/Mads

... But for a high Re model, Y+ should be everywhere between 30 and 100, is it right? So your suggestion is to use the finer mesh with a low-Re approach... launderSharmaKE is what I usually choose, but suggestions are welcome...

[MadsR]

Yes for a highRe model y+ should be in that order of magnitude but I am not too surprised that you can't predict drag better than you observe with a highRe model. I would suggest finer mesh with a y+ around or below 2 and a lowRe model. komega-SST in lowRe mode is a good choice (when we're talking RANS simulation). I am not sure if there is a lowRe implementation of komega-SST in OpenFOAM though, then Launder-Sharma would be my second choice.

/Mads

[maddalena]

Hi Mads,
I succeeded in running two different cases:

• a launderSharmaKE case, with an average y+ of 2.5, however cd is 5 times larger than expected,

• a k-omegaSST case, with an average y+ of 36, and cd is -25% than the theoretical cd.

Of course, the two meshes are different to match the y+ requirement. I am thinking of adopt a high-Re approach, knowing that I can have differences on real values. However, after investigating the logs/p_0 file, I am not happy with the convergence history. Indeed, cl is +15% from the theoretical value.
Have you some suggestions on how to reduce pressure residual? My fvSolution is:

    p
    {
        solver          GAMG;
        tolerance       1e-09;
        relTol          1e-04;
        smoother        GaussSeidel;
        nPreSweeps      0;
        nPostSweeps     2;
        cacheAgglomeration true;
        nCellsInCoarsestLevel 10;
        agglomerator    faceAreaPair;
        mergeLevels     1;
    }

while fvSchemes is:

gradSchemes: faceMDLimited Gauss linear 0.5;
divSchemes: Gauss linearUpwind  cellLimited Gauss linear 1;
laplacianSchemes: Gauss linear limited 0.5;

Thank you...

mad

[MadsR]

Mad,

I have most experience with the k-omega-SST model so I do not know why you see such bad drag prediction from the L-S model, I know it is widely used for aerodynamics and I have also used it a few times, so I do not know what's wrong here. Remember that y+ is not the whole story, you also need to have enough cells within the boundary layer, i.e. the stretching should be kept reasonable and definitely below a factor of 1.15-1.2. In any case 500% error on the drag signifies that something isn't right.

Previously I have made some sensitivity analysis of max(y+)@airfoil, and I normalized those results and put them below. You can see that one must be careful with y+ as it really can change results a lot. What I did was to systematically vary the size of the first cells at the wall and monitor the influence on the drag. I used CFX with steady simulation with k-omega-SST without transition. CFX has automatic wall functions but at these low y+ it is always in lowRe mode (I hope :-)).



Your solution parameters seems correct. Are you doing steady simulations? If so you might not need to solve to such a tough relative tolerance. It might help your solution to develop faster into fully developed flow if you set it to, say, 0.01 or even higher. At least that is how I understood it.

/Mads

[IMG]file:///C:/Users/mreck/AppData/Local/Temp/moz-screenshot.png[/IMG]

[maddalena]

Originally Posted by MadsR

Remember that y+ is not the whole story, you also need to have enough cells within the boundary layer, i.e. the stretching should be kept reasonable and definitely below a factor of 1.15-1.2.

Ok, y+ is not the whole story, but for sure it helps!
The mesh I generated has an aspect ratio as high as 150 close to the wall , so that's probably why the lowRe case is not working properly. According to this: http://geolab.larc.nasa.gov/APPS/YPlus/, I should have a first cell layer of 0.0000322 meter, that implies a cell number that is not admissible for me. Thus I probably remain on the high-Re model, knowing that the drag is overestimated.

As for the relTol of my fvSolution, yes, I am running a steady simulation, but I read somewhere to keep the relTol tight to obtain better convergence and a stable simulation... Indeed, I succeded to have 2% on cl and 75% on cd. These values are not very far from the point I enter in the discussion yesterday, but at least now I know why and where I should move to improve my results.

Really enlighten your job on y+-cd relationship! It has already been saved on my favourite folder.

Thankyou,

cheers,

mad

[MadsR]

Mad,

An aspect ratio of 150 close to the wall is nothing :-) I assume that you are using hex-meshes and most modern solvers can handle aspect ratios way into 10,000 or even 100,000 and these figures are definitely common in airfoil flows. I am not entirely sure how OpenFOAM copes with high aspect ratio cells though.

Your 75% off on drag is, as you mention, not too bad - I can't remember your particular airfoil, but the thicker it is the more difficult it also is to model.

/Mads

[maddalena]

Wait wait wait...
you wrote

Originally Posted by MadsR

the stretching should be kept reasonable and definitely below a factor of 1.15-1.2.

Is stretching different from aspect ratio? Mmm...
Indeed, my airfoil is thick. Thus, things are not as bad as I think. Uhmmm...
In any case, from this discussion I really learned a lot! That's is never useless!

[MadsR]

Well, maybe I wasn't making myself really clear :-) by [cell-] aspect ratio you would normally mean the ratio between cell-sides and by stretching I was referring to the factor you normally apply when successively increasing the cell-side-height when moving away from the airfoil. You probably know this page where you can read more about this expansion factor. I am not sure about reasonable expansion factors with blockMesh, but try different factors and look at your cell-count and checkMesh output.

Note: You should be able to model a 2D airfoil with around 250k cells, at least my sensitivity investigations seem to point towards this cell-count being reasonable together with a max(y+) of around 2.

Also you might check for influence of exterior boundaries, how far away are your outer bounds?


/Mads

[maddalena]

Ah, ok! Your stretching is my cell grading! I am using 1.1, that is under the limit you pointed out.

My mesh quality is quite good, there is no error from checkMesh. I have only certain cells that are a little bit too distorted in my opinion, but checkMesh does not complain about them.

With the actual set-up, I have around 50k cells for the lowRe mesh, and around 10k for the highRe mesh. The domain is 15 chords far away, and it is of a circular shape, since I need to invesigate a wide range of AoA. Should I further increase it? I think it is a matter of refinement of results, and it cannot lower cd of so much I need for the lowRe case!

mad

[MadsR]

My investigations on cl/cd sensitivity from proximity of outer boundaries show that there can be a substantial influence on the cd (not so much on cl). I am not able to explain that yet, and I would actually expect the impact being on the cl instead.
Anyways, 15 chords is (to my knowledge) definitely not enough. Try to double it and see if your result change, and then try to double it once more if it does.

On the cell count: with only 10k cells there is no chance (or maybe only by chance :-)) that you will predict cd properly. Even with 50k cells I would wonder. I have also done mesh dependency study following the lines of Richardson extrapolation and found that these 250k-300k cells are a good, generic, cell count for airfoils in the Re=5mio order of magnitude regime. I saw heavy impact on both cl and cd when going to, say, 80k cells.

/Mads

[maddalena]

Indeed cd changes moving the outer boundaries. I was able to reduce cd difference of 60% in regards of theoretical value, with boundaries placed 120 chords away. 240 chords did not bring any improvement. The 120 chords case y+ changed accordingly, reducing to 25 average. The strange thing is that cl difference increase... from 2% with 15 chords to 4% with 120 chords in comparison of expected value. That is with the highRe case and a 20k mesh.
To increase further the cell number, I should increase the cell number on the airfoil surface. But then I need to change the first cell layer thickness to keep my mesh quality good, and this is not fine according to my y+.
I have not try the lowRe approach. 250K cells are definitely too much for my objectives!
So, I think I have a good setup now. Go back to python to write a polar plot script.
Thanks again!


mad

[MadsR]

Okay, sounds good. Thank you for an interesting discussion :-)

Happy foaming,
Mads

[Alhasan]

Hey All,

I am some hard time with Convergence

I have a windtunnel set up with a Blade
My pressure is not going below 0.001 and it is oscillating and so is my Cl and Cd they are oscillating between the same few values

residual control 0.25 for p and 0.7 for U and the rest

i initialised with potential FOAM with turbulence off then turbulence on, then first order schemes, then second order. still there is oscillation

i dunno why, if some one has an explanation please give
when i use

p
    {
        solver          PCG;
        preconditioner  DIC;
        tolerance       1e-07;
        relTol          0.001;
    }

The results are converging well in the residual chart with small oscillations but the Cd Cl are not matching the experimental values

but when i use

p
    {
        solver           GAMG;
        tolerance        1e-7;
        relTol           0.0;
        smoother         GaussSeidel;
        nPreSweeps       1;
        nPostSweeps      3;
        nFinestSweeps    3;
        scaleCorrection true; 
        directSolveCoarsest false;
        cacheAgglomeration on;
        nCellsInCoarsestLevel 50;
        agglomerator     faceAreaPair;
        mergeLevels      1;
    }

the results are matching the experiments well, but oscillating between few values
I need them to converge as i will be the mapping the data around the blade to a C-Grid for a transient simulation.

- So any tips or ideas in getting the residual of P below 0.001 and make it stop oscillating

my schemes are

gradSchemes
{
    default         cellMDLimited Gauss linear 0.5;
}

divSchemes
{
    default         none;
    div(phi,U)      Gauss linearUpwind grad(U);
    div(phi,k)      Gauss upwind;
    div(phi,omega)  Gauss upwind;
    div((nuEff*dev(T(grad(U))))) Gauss linear;
}

laplacianSchemes
{
    default          Gauss linear limited 1.0;
}

Thanks for your time,
Hasan K.J

[wyldckat]

Greetings to all!

@Hasan:

Originally Posted by Alhasan

- So any tips or ideas in getting the residual of P below 0.001 and make it stop oscillating

From your description, my guess is that you are wishing for the "fvSchemes" and "fvSolution" settings to solve something that can only be solved directly in the mesh. In other words, what does this command give you:

checkMesh -allTopology -allGeometry

Best regards,
Bruno

[Alhasan]

Hey Bruno,
Here is the Mesh check stats

 Mesh stats
    points:           7280988
    faces:            21264672
    internal faces:   20692704
    cells:            6992896
    boundary patches: 6
    point zones:      0
    face zones:       0
    cell zones:       0

Overall number of cells of each type:
    hexahedra:     6992896
    prisms:        0
    wedges:        0
    pyramids:      0
    tet wedges:    0
    tetrahedra:    0
    polyhedra:     0

Checking topology...
    Boundary definition OK.
    Cell to face addressing OK.
    Point usage OK.
    Upper triangular ordering OK.
    Face vertices OK.
    Topological cell zip-up check OK.
    Face-face connectivity OK.
    Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces ...
    Patch               Faces    Points   Surface topology                   Bounding box
    inlet               6400     6633     ok (non-closed singly connected)   (-0.054 -0.0675 -0.005) (0.0135 0.0675 0.005)
    outlet              6400     6633     ok (non-closed singly connected)   (0.471678 -0.0910434 -0.00500111) (0.471678 0.0439596 0.005)
    upper               29184    30129    ok (non-closed singly connected)   (-5.71043e-05 -0.00016092 -0.005) (0.135 0.0156933 0.005)
    lower               29184    30129    ok (non-closed singly connected)   (2.92301e-19 -0.00350158 -0.005) (0.135 0.00168067 0.005)
    frontandback        437056   441272   ok (non-closed singly connected)   (-0.054 -0.0910434 -0.00500117) (0.471678 0.0675 0.00500058)
    topandbottom        63744    65802    ok (non-closed singly connected)   (0.0135 -0.0910434 -0.005) (0.471678 0.0675 0.005)

Checking geometry...
    Overall domain bounding box (-0.054 -0.0910434 -0.00500117) (0.471678 0.0675 0.00500058)
    Mesh (non-empty, non-wedge) directions (1 1 1)
    Mesh (non-empty) directions (1 1 1)
    Boundary openness (-3.89742e-17 1.95127e-17 9.96953e-16) OK.
    Max cell openness = 3.26708e-15 OK.
    Max aspect ratio = 67.4095 OK.
    Minimum face area = 3.64765e-10. Maximum face area = 2.83567e-05.  Face area magnitudes OK.
    Min volume = 1.13989e-13. Max volume = 8.86151e-09.  Total volume = 0.000674752.  Cell volumes OK.
    Mesh non-orthogonality Max: 68.5046 average: 8.38422
    Non-orthogonality check OK.
    Face pyramids OK.
    Max skewness = 0.86379 OK.
    Coupled point location match (average 0) OK.
    Face tets OK.
    Min/max edge length = 6.4e-06 0.00635047 OK.
    All angles in faces OK.
    Face flatness (1 = flat, 0 = butterfly) : average = 1  min = 0.999749
    All face flatness OK.
    Cell determinant (wellposedness) : minimum: 5.55889e-08 average: 1.81818
 ***Cells with small determinant found, number of cells: 168328
  <<Writing 168328 under-determined cells to set underdeterminedCells
    Concave cell check OK.

Failed 1 mesh checks.

Regards,
Hasan K.J

[wyldckat]

Originally Posted by Alhasan

    Cell determinant (wellposedness) : minimum: 5.55889e-08 average: 1.81818
 ***Cells with small determinant found, number of cells: 168328
  <<Writing 168328 under-determined cells to set underdeterminedCells
    Concave cell check OK.

There we go: I'm almost willing to bet that the cell that has the determinant of 5.55889e-08 is the one to blame for the oscillation you are seeing in your simulation. The minimum volume and minimum face area are also very small, which are likely related to the cell with the small determinant.

The simplified way to look at this is to imagine that the cell in question is as if it were extremely small (near zero) or that it is very contorted. What this equates to is a distortion in the mesh, that leads to non-physical values, because the numbers are stretched more than they should...

Have a look into this blog post of mine, to see the effects bad meshes can have on results: OpenFOAM: Interesting cases of bad meshes and bad initial conditions

[Alhasan]

But, I made the mesh in salome
and the distance of the first cell was what it had to be even though it was that small, to have a Y+ of 0.5-1, so is there any way to maintain the Y+ and the results
Thanks,
Hasan K.J

[wyldckat]

After the checkMesh command, run this command:

foamToVTK -cellSet underdeterminedCells

Then open in ParaView the VTK file of the same name, located somewhere inside the VTK folder. More specifically:

1. Run paraFoam, to see the mesh. Use the filter "Extract cells by region" to better see inside the mesh.
2. Hide the mesh and open "underdeterminedCells.vtk". Use the fit into screen, so that you can see where it is exactly.
3. Now show the mesh again and gradually zoom out and adjust the other filter, close to the problematic location.

You'll need to generate the mesh with this problematic cell in mind.