[Verfblikje]

Dear fellow forummembers,

As the title states, I am trying to capture stall on a three-element airfoil. It is a general aviation airfoil with a double slotted flap.

Using the Spalart-Allmaras model I am not able to get a reasonable result. C_L values hover around 0.02 and drag is in the region of 2E-22. I have been trying to get a reasonable result for some while now, but no luck.

Then, I have also tried k-omega SST. Even at 8 degrees angle of attack (35 degrees flap setting), the airfoil stalls. Even though I am not sure what the stall angle of attack should be, I assume it will be higher than 8. I have yet to try lower angles. I used the wiki article to give me boundary conditions. I have tried the standard settings from the motorBike tutorial and tried some other boundary conditions.

The flow seems to trip at the leading edge of the main element.
Some further information about the case:
Re = 1.5 * 10^6
U = 18 m/s
chord = 1.25 m

Could you give me some tips for improving my results?

Thanks in advance,

Nick

P.S. I am running OpenFOAM 2.1.0

[Maff]

I'm having similar problems.

I just tried the airFoil2D tutorial (OpenFOAM 2.1.0), but with kOmegaSST model.
The detachment occurs too soon, at the leading edge.
With SpalartAllmaras and kOmega models, the detachment occurs at the very end of the trailing edge.
What can cause this discrepancy?
Is this related to omegaWallFunction?
Why is it affecting more the kOmegaSST model than the kOmega model?

[DLuo]

I'd recommend this NASA page. Rather than jump straight to a 3 element high lift airfoil, start small and see if you can get one of these grids to correlate with the literature.

http://turbmodels.larc.nasa.gov/naca0012_val.html

[KateEisenhower]

Hi Maff and Verfblikje,

I know you posted some three years ago. Did you finally solve your problems? It would be very nice if you could share your BCs and solver settings. I am currently dealing with very high velocity (ca. 100 times higher than expected) in a simpleFoam low-Re komegaSST setting. Did you experience that as well?

Best regards,

Kate

[DLuo]

Kate,
Before you get into BCs please describe your mesh. Is it 2D or 3D. Fully structured or unstructured? Boundary layer growth? Attempted Y+ value? Snappy, Pointwise, or other grid generator? Far-field distance and shape?
The limitations of your simulation begin here. CFD is always garbage in garbage out and without a nice clean grid, you'll find that your there's only so much you can get out of a simulation. The reason I like to point to that naca0012 validation page is because an extremely nice clean fully structured (hexahedral) grid is provided whereupon many different codes have had lots of success running, validating, and benchmarking their solvers/setups.

[KateEisenhower]

Originally Posted by DLuo

Kate,
Before you get into BCs please describe your mesh. Is it 2D or 3D. Fully structured or unstructured? Boundary layer growth? Attempted Y+ value? Snappy, Pointwise, or other grid generator? Far-field distance and shape?
The limitations of your simulation begin here. CFD is always garbage in garbage out and without a nice clean grid, you'll find that your there's only so much you can get out of a simulation. The reason I like to point to that naca0012 validation page is because an extremely nice clean fully structured (hexahedral) grid is provided whereupon many different codes have had lots of success running, validating, and benchmarking their solvers/setups.

Hi DLuo and thank you for your answer,

I am working on a unstructured 3D mesh with boundary layer and an attempted y+ value of 1. The model is placed in a wind tunnel with the dimensions (6*L)*(6*L)*L with L being the greatest dimension of the model. The mesh currently is created with enGrid.
Please note that I am in the mesh iteration process and my mesh is not perfect yet. My farfield distance is probably to small as well.
I just want to make sure that my problem lies within the mesh and therefore I want to doublecheck on my boundary conditions which I have listed below.

Object is the airfoil which spans from the front to the back. Top and bottom are the other two walls of the wind tunnel.

U:

internalField   uniform (14.1414 0 0);

boundaryField
{
    inlet
    {
        type            fixedValue;
        value           uniform (14.1414 0 0);
    }        

    outlet
    {
        type            zeroGradient;
    }

    object
    {
        type            fixedValue;
        value           uniform (0 0 0);
    }

    front
    { 
        type            slip;
    }

    back
    { 
        type            slip;
    }

    top
    { 
        type            slip;
    }

    bottom
    { 
        type            slip;
    }
}

p:

internalField   uniform 0;

boundaryField
{
    inlet
    {
        type            zeroGradient;
    }

    outlet
    {
        type            fixedValue;
        value           uniform 0;
    }

    object
    {
        type            zeroGradient;
    }

    front
    {
        type            slip;
    }

    back
    {
        type            slip;
    }

    top
    {
        type            slip;
    }

    bottom
    {
        type            slip;
    }
}

k:

internalField   uniform 7.13045903e-3;

boundaryField
{
    inlet
    {
        type            fixedValue;
        value           uniform 7.13045903e-3;
    }

    outlet
    {
        type            zeroGradient;
    }

    object
    {
        type            zeroGradient;
    }

    front
    {
        type            slip;
    }

    back
    {
        type            slip;
    }

    top
    {
        type            slip;
    }

    bottom
    {
        type            slip;
    }

}

omega:

internalField   uniform 0.5;

boundaryField
{

    inlet
    {  
        type            fixedValue;
        value           uniform 0.5;
    }

    outlet
    {
        type            zeroGradient;
    }

    object
    {
        type            omegaWallFunction;
        value           uniform 0.5;
    }

    top
    {
        type            slip;
    }

    bottom
    {
        type            slip;
    }

    front
    {
        type            slip;
    }

    back
    {
        type            slip;
    }
}

nut:

internalField   uniform 0;

boundaryField
{
    inlet
    {
        type            calculated;
    }

    outlet
    {
        type            calculated;
    }

    object
    {
        type            fixedValue;
        value           uniform 0;
    }

    front
    {
        type            calculated;
        value           uniform 0;
    }

    back
    {
        type            calculated;
        value           uniform 0;
    }

    top
    {
        type            calculated;
        value           uniform 0;
    }

    bottom
    {
        type            calculated;
        value           uniform 0;
    }

}

It would be very nice if anyone could comment on this. Currently, I am running it with the kOmegaSST model. But I want to try with the SpalartAllmaras as well. Can I use the same BCs then?

Thanks in advance,

Kate

[DLuo]

Kate,

Your setup seems reasonable enough. You should be able to use a fixed value of 0 for the object in your k variable if you have a y+ ~1. In my 2D sims with OpenFoam I typically use
"type freestream;
freestreamValue uniform [variable value];"
for most of my inlet and outlet BCs. The exception being "p" where the inlet/outlet is of type freestreamPressure. In general it checks the local velocity vector and the surface normal to determine if flow is going into the domain or out of the domain and then enforces velocity (if going in) or pressure (if going out). In fact my inlet/outlet are combined into 1 patch in a circular domain and given this particular BC. Examples should be available either in the incompressible tutorials or online.
If you want to use SA turbmodel then the same BCs would apply, you would just need a nuTilda variable in place of k and omega.
If you're doing a 2D sim, the top and bottom faces I assume are the faces at either side of the span of the airfoil correct? I would suggest imposing an "empty" patch type and BC on those as that appears to be the proper convention for OF.

I've found that running checkMesh on your grid helps tell you how likely your mesh will be tolerated by OF. Max Non-orthogonality > 85 will give you very suspect results, as will max skew > 5. Obviously with a y+ ~1, you will have very high AR, so you'll have to ignore that metric.
You have to understand that OF solvers were written to work best with snappy type meshes. 3D Tets aren't well received by OF, 2D Tris are a little better but still not great. When it comes to running wall-resolved meshes in OF, I'm afraid you're stuck in a very tightly confined box.

[KateEisenhower]

Hi Andy,

Thank you, this post was very helpful for me. I built a snappyHexMesh now which passed the checkMesh without any issues. And at first glance, it gives me way better results than my mesh from enGrid. But there is still a lot of fine tuning neccessary. The problem is always the creation of a decent boundary layer.

Originally Posted by DLuo

Kate,

Your setup seems reasonable enough. You should be able to use a fixed value of 0 for the object in your k variable if you have a y+ ~1.

Okay I'll try this. I read somewhere else it might be better to use k=1e-12 or a similar value.

In my 2D sims with OpenFoam I typically use
"type freestream;
freestreamValue uniform [variable value];"
for most of my inlet and outlet BCs. The exception being "p" where the inlet/outlet is of type freestreamPressure. In general it checks the local velocity vector and the surface normal to determine if flow is going into the domain or out of the domain and then enforces velocity (if going in) or pressure (if going out). In fact my inlet/outlet are combined into 1 patch in a circular domain and given this particular BC. Examples should be available either in the incompressible tutorials or online.
If you want to use SA turbmodel then the same BCs would apply, you would just need a nuTilda variable in place of k and omega.

Okay I will try this too.

If you're doing a 2D sim, the top and bottom faces I assume are the faces at either side of the span of the airfoil correct? I would suggest imposing an "empty" patch type and BC on those as that appears to be the proper convention for OF.

Actually the characteristics of my problem require a 3D simulation. Would you recommend using a symetry BC in this case (my airfoil spans from front to back and is connected to the boundaries)

I've found that running checkMesh on your grid helps tell you how likely your mesh will be tolerated by OF. Max Non-orthogonality > 85 will give you very suspect results, as will max skew > 5. Obviously with a y+ ~1, you will have very high AR, so you'll have to ignore that metric.
You have to understand that OF solvers were written to work best with snappy type meshes. 3D Tets aren't well received by OF, 2D Tris are a little better but still not great. When it comes to running wall-resolved meshes in OF, I'm afraid you're stuck in a very tightly confined box.

Thanks a lot for this information!

Best regards,

Kate

[DLuo]

If you're modelling the full span of the object, then a slip condition would probably be better than a symmetry. However, I don't think it would make a very noticeable impact on your results if you chose slip or symmetry for the side walls.

Regarding snappyHexMesh, just be sure about how it's generating the layers. To keep a nice wall resolved mesh I think it's almost necessary to make sure the layer generation is using absolute height rather than relative height. If you're using relative height the areas of higher curvature would get a tighter refinement which would drop the first cell height off the object giving you an undesirable change in y+. Unfortunately, I haven't played with absolute height enough to give further tips.
Good luck

[KateEisenhower]

Absolutely. It's not easy to get decent boundary layers with sHM.
Would a tighter refinement be a problem? I always had the understanding that everything below y+=1 is okay under all cirmustances.

[DLuo]

I truth it should be fine, but as a personal preference I don't like my BL going from ~1 to ~0.5 in adjacent cells. I'm sure the wall-resolved numerics should be ok, but sudden jumps like that aren't generally appreciated in best-practice meshing for CFD.

[KateEisenhower]

Hello and special thanks to DLuo for his help so far!

A few days ago I posted my initial/boundary conditions for U, p, k, omega and nut. Now I noticed that I totally forgot about epsilon. Since kOmegaSST switches to k-epsilon behavior in the farfield, one should define the turbulent dissipation too. Well, obviously I am wrong here because the solver doesn't complain about the missing file.
So, my question is, why doesn't the simpleFoam solver require a epsilon file?

Best regards,

Kate

[KateEisenhower]

Hello,

I have a quick update: I created an epsilon file in the 0 folder, but when I go to the, for example, 3000 folder after starting the iteration, I can only see U, p, k, omega, nut and phi files. This seems to implicate that the kOmegaSST model doesn't even use the epsilon file I created. Please correct me if I am wrong!

Best regards,

Kate

[KateEisenhower]

Hello DLuo,

Recently, I rediscovered the following post. I think you were right, at least with the magical barrier of Max non-orthogonality = 85.

Originally Posted by DLuo

I've found that running checkMesh on your grid helps tell you how likely your mesh will be tolerated by OF. Max Non-orthogonality > 85 will give you very suspect results, as will max skew > 5. Obviously with a y+ ~1, you will have very high AR, so you'll have to ignore that metric.
You have to understand that OF solvers were written to work best with snappy type meshes. 3D Tets aren't well received by OF, 2D Tris are a little better but still not great. When it comes to running wall-resolved meshes in OF, I'm afraid you're stuck in a very tightly confined box.

Still I have problems with my boundary layer. My research showed me so far, that simpleFoam works better with 6 nodes prisms (tris at the surface) than with 8 nodes prisms (quads at the surface). But with 6 nodes prisms I checkMesh complains about nonOrthoFaces at tight corners. Does this match with your experience?

Best regards,

Kate

[DLuo]

Hi Kate,

This is way overdue but I figured I'd answer this question anyway to help any poor souls wandering this way.
First off the issue about needing epsilon file for kOmegaSST simulations. kOmegaSST works like kEpsilon in the far-field not by introducing an epsilon value but rather in the formulation of the turbulence model and the accompanying coefficients/constants required for that model. Therefore when you noticed your final time didn't include an epsilon file it's because the solver, when running kOmegaSST, doesn't calculate any epsilon values so it doesn't have anything to write once you've advanced the time past 0.

On to the question of 3D cases with y+~1 meshes. In Openfoam, you're pretty much out of luck, it's not really going to work unless you drop your surface spacing way tight. This is because if it hasn't failed the other checks, the high AR values in the 3D model are now contaminating your solution. I've had some limited success with going to double-precision but OF just isn't built to do a good job calculating wall resolved BL. In my experience I can get a nice well correlated solution in 2D but as soon as I try to extrude my mesh in 3D everything goes to hell.
If you (wayward soul) are still trying to get your y+1 mesh to run, here's what I recommend, don't use triangular prisms because while your BL might be OK, it means that somewhere the mesh has tets in order to connect the prisms to a hex mesh or, worse yet, even a fully unstructured tet mesh. OF really just doesn't work with tet meshes and therefore you'll have a hard time getting things to run without some serious tampering of the fvSchemes (cellLimited everything). You'll have better luck generating a Hex-BL but the width and length of those cells should be no greater that 200x the 1st layer height. This means 2 things, your AspectRatio metric will be OK, and your cell count will balloon like crazy. I hope you have a lot of computing resources to run that mesh.

You're best bet would be to generate a mesh in SHM using the absolute height method for your surfaceLayers and sizing the surface cells to meet that y+ and Aspect ratio requirement. Unfortunately you'll only get roughly 10 layers so you may need to pick a really aggressive growth rate. If all else fails, try a y+~50 and use the wall-functions included with OF. They claim that it's a continuous wall function so it should properly predict what's happening in the log-layer. Perhaps someone else will contribute their findings of wall-resolved vs wall-function tests.