[harwin]

Dear all,

As part of my education at INHOLLAND University Delft, dept. of Aerospace Engineering I am involved in a project in which I and three other students try to get experience in performing CFD calculations.
We try to work through some simple 2D cases like a cilinder in a flow, both laminar and turbulent. Furthermore we are trying to calculate the flow for a NACA0012 airfoil. Problems occur during the turbulent case for both, the cilinder case and the NACA0012 airfoil.

Our supervisor told us that Spalart Allmaras is a solver which will do fine for a airfoil. Though as he is not experienced with OpenFOAM it is difficult for him to give us support in this.
It might be clear now that we are using Spalart Allmaras.

We are able to build a proper mesh (in our opinion) with blockMesh. We use Yplus formulas to calculate the first grid heigth and use simpleGrading to achieve these cellsizes. The problem starts at defining the boundary conditions as there are a lot of boundary conditions we can choose from.

One of the errors we get when trying to run a case is that the solver cannot locate a file <case>\0\nut. Renaming the file 'nuTilda' to 'nut' seems to solve the problem, but is this the right way?

Furthermore we run in to trouble with the courantnumber rising to unacceptable high levels and finally in nan resulting in a extremely small delta t.

I think we are doing something wrong with the boundary conditions. It is hard to find any information on how a certain boundary condition affects the calculation which results in experimenting with boundary conditions.

An overview of our case can be found on http://dolder3.dyns.net.

I hope someone is willing to take some time and have a look at our case and is able to help us. Besides replying on this forum you might want to contact me by e-mail: 03200107@student.inholland.nl

Regards,

Harwin van Maanen

[vinz]

Hi Harwin,

As an aeronautical students (I spent one year in Delt last year), I was interesting in your NACA0012 case. So I downloaded you blockMeshDict on http://dolder3.dyns.net
I generated the mesh with blockMesh and I end up in paraview with the folowing mesh:



Is the blockMeshDict on your website up to date? Or did I make something wrong?
If this is the real mesh, I assume it can be source of troubles for laminar or turbulent case.

Regards,

Vincent

[lr103476]

Hi Harwin,

I've got the same problems with your blockMeshDict when trying to reproduce your mesh. You have to be really precise in defining your different vertices/edges and blocks for the use of blockMesh.

Do you've got the possiblity to use other grid generation programs, other than blockMesh, Gridgen or Gambit for example?

Btw, I am also at Aerospace Engineering (yes, at the Delft University of Technology), slightly more than one year ago I started my PhD project here.......

Regards, Frank

[vinz]

Hi,

In fact, when I saw the post I was very interested in how to do quite complicated meshes (NACA0012) with blockMesh. But it looks like, your mesh confirms that's really not straight forward to create a complex mesh with blockMesh. However this is a good tool for simple cases, and it's great that there is one delivered with OpenFOAM.

Regards,

Vincent

P.S:I was also at TU Delft last year! This is a great university.

[harwin]

Thank you all for your reply

The blockMeshDict to which I linked is not up to date, sorry for that. We also found the errors in the mesh. We already changed the blockmeshdict. Indeed, building such complex meshes with blockMesh is a lot of work. The error occured when we refined the mesh. Though if we correct the error and run a case we run in to problems with our courant number. An extremely small delta t is needed to be able to proceed a calculation, consequently resulting in long calculations. I think it has to do with the value for our first cell size.
We are calculating the first cell size y in the following way. Can someone please have a look at this an tell us whether it is correct or not.

For a turbulent boundary layer
Re = 3.00E6 [-]
U = 100 [m/s]
chord = 1 [m]
rho = 1.225 [kg/m^3]
kappa = 0.41 [-]
C = 5.1 [-]

nu = (chord . U)/Re = 3.33E-5 [m^2/s]

y+ = e^(kappa . (u+ - C)) = 1603 [-]
This follows from: u+ = (1/kappa) . ln(y+) + C (CFD-online wiki)

u+ = U/u* = 23.1 [-]

u* = sqrt(tau_w/rho) = 4.3 [m/s]

tau_w = C_f . 0.5 . rho . U^2 = 23 [Pa]

C_f = 0.074 / Re^(1/5) = 3.75E-3 [-]
(We found this equation in Fundamentals of Aerodynamics, John D. Anderson, Jr.)

Finally we calculate y (first cell size):
y = (y+ . nu)/u* = 1.23E-2 [m]

I hope someone can help us.

Regards,

Harwin

[harwin]

Thank you all for your reply

The blockMeshDict to which I linked is not up to date, sorry for that. We also found the errors in the mesh. We already changed the blockmeshdict. Indeed, building such complex meshes with blockMesh is a lot of work. The error occured when we refined the mesh. Though if we correct the error and run a case we run in to problems with our courant number. An extremely small delta t is needed to be able to proceed a calculation, consequently resulting in long calculations. I think it has to do with the value for our first cell size.
We are calculating the first cell size y in the following way. Can someone please have a look at this an tell us whether it is correct or not.

For a turbulent boundary layer
Re = 3.00E6 [-]
U = 100 [m/s]
chord = 1 [m]
rho = 1.225 [kg/m^3]
kappa = 0.41 [-]
C = 5.1 [-]

nu = (chord . U)/Re = 3.33E-5 [m^2/s]

y+ = e^(kappa . (u+ - C)) = 1603 [-]
This follows from: u+ = (1/kappa) . ln(y+) + C (CFD-online wiki)

u+ = U/u* = 23.1 [-]

u* = sqrt(tau_w/rho) = 4.3 [m/s]

tau_w = C_f . 0.5 . rho . U^2 = 23 [Pa]

C_f = 0.074 / Re^(1/5) = 3.75E-3 [-]
(We found this equation in Fundamentals of Aerodynamics, John D. Anderson, Jr.)

Finally we calculate y (first cell size):
y = (y+ . nu)/u* = 1.23E-2 [m]

I hope someone can help us.

Regards,

Harwin

[vinz]

Hi Harwin,

I didn't try your case on my machine. However some characteristics of your case look strange to me. First, what do you call "an extremly small deltaT"?
And secondly, a y+ of 1603 looks huge. I'm used to make computations with y+ of the order of 1. It shouldn't blow up your computation but could explain some things.


Regards,

Vincent