CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Running, Solving & CFD

Stall capture on 3 element airfoil: what turb model?

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree4Likes
  • 1 Post By DLuo
  • 1 Post By DLuo
  • 2 Post By DLuo

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   February 21, 2012, 12:44
Default Stall capture on 3 element airfoil: what turb model?
  #1
New Member
 
Nick
Join Date: Dec 2011
Posts: 11
Rep Power: 14
Verfblikje is on a distinguished road
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

Last edited by Verfblikje; February 21, 2012 at 12:45. Reason: additional info
Verfblikje is offline   Reply With Quote

Old   March 26, 2012, 13:39
Default
  #2
New Member
 
Join Date: Mar 2012
Posts: 20
Rep Power: 13
Maff is on a distinguished road
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?
Maff is offline   Reply With Quote

Old   May 15, 2014, 17:05
Default
  #3
Member
 
D L
Join Date: Jun 2012
Posts: 49
Rep Power: 13
DLuo is on a distinguished road
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
DLuo is offline   Reply With Quote

Old   June 10, 2015, 04:55
Default
  #4
Senior Member
 
Join Date: Mar 2015
Posts: 250
Rep Power: 12
KateEisenhower is on a distinguished road
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
KateEisenhower is offline   Reply With Quote

Old   June 12, 2015, 19:35
Default
  #5
Member
 
D L
Join Date: Jun 2012
Posts: 49
Rep Power: 13
DLuo is on a distinguished road
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.
DLuo is offline   Reply With Quote

Old   June 15, 2015, 03:39
Default
  #6
Senior Member
 
Join Date: Mar 2015
Posts: 250
Rep Power: 12
KateEisenhower is on a distinguished road
Quote:
Originally Posted by DLuo View Post
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:
Code:
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:
Code:
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:
Code:
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:
Code:
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:
Code:
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
KateEisenhower is offline   Reply With Quote

Old   June 16, 2015, 01:13
Default
  #7
Member
 
D L
Join Date: Jun 2012
Posts: 49
Rep Power: 13
DLuo is on a distinguished road
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 likes this.
DLuo is offline   Reply With Quote

Old   June 16, 2015, 11:40
Default
  #8
Senior Member
 
Join Date: Mar 2015
Posts: 250
Rep Power: 12
KateEisenhower is on a distinguished road
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.

Quote:
Originally Posted by DLuo View Post
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.

Quote:
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.

Quote:
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)

Quote:
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
KateEisenhower is offline   Reply With Quote

Old   June 17, 2015, 00:01
Default
  #9
Member
 
D L
Join Date: Jun 2012
Posts: 49
Rep Power: 13
DLuo is on a distinguished road
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
DLuo is offline   Reply With Quote

Old   June 17, 2015, 02:53
Default
  #10
Senior Member
 
Join Date: Mar 2015
Posts: 250
Rep Power: 12
KateEisenhower is on a distinguished road
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.
KateEisenhower is offline   Reply With Quote

Old   June 17, 2015, 10:54
Default
  #11
Member
 
D L
Join Date: Jun 2012
Posts: 49
Rep Power: 13
DLuo is on a distinguished road
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 likes this.
DLuo is offline   Reply With Quote

Old   July 10, 2015, 04:07
Default
  #12
Senior Member
 
Join Date: Mar 2015
Posts: 250
Rep Power: 12
KateEisenhower is on a distinguished road
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 is offline   Reply With Quote

Old   July 12, 2015, 09:21
Default
  #13
Senior Member
 
Join Date: Mar 2015
Posts: 250
Rep Power: 12
KateEisenhower is on a distinguished road
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 is offline   Reply With Quote

Old   August 14, 2015, 06:16
Default
  #14
Senior Member
 
Join Date: Mar 2015
Posts: 250
Rep Power: 12
KateEisenhower is on a distinguished road
Hello DLuo,

Recently, I rediscovered the following post. I think you were right, at least with the magical barrier of Max non-orthogonality = 85.
Quote:
Originally Posted by DLuo View Post
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
KateEisenhower is offline   Reply With Quote

Old   February 22, 2017, 16:30
Default
  #15
Member
 
D L
Join Date: Jun 2012
Posts: 49
Rep Power: 13
DLuo is on a distinguished road
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.
KateEisenhower and Niteck like this.
DLuo is offline   Reply With Quote

Reply

Tags
komegasst, openfoam 2.1.0, stall, turbulence model

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Problem running simpleFoam on a multi element airfoil vinz OpenFOAM Running, Solving & CFD 18 April 11, 2013 12:26
Stall capture with simpleFoam L1011 OpenFOAM Running, Solving & CFD 0 April 15, 2011 16:20
ICED AIRFOIL and SAS model Typhoon CFX 0 April 8, 2011 19:09
Limitation of 2D and 3D model element number Soon CFX 3 January 30, 2006 16:15
Multi Element Airfoil J.Dumas Main CFD Forum 2 May 13, 2000 08:24


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