- yes, exactly. I'm ususally using the Pointwise Y+ Calucator (http://www.pointwise.com/yplus/) where the distance of the first cell from wall is denoted as delta s.

- no-slip, of course, my bad. As for the boundary conditions for the y+ = 1 case: k_wall = 0, and since omega = O(y^-2) (where y is distance to the wall) in the vicinity of the wall you should use some analytical estimate. One of possible approaches is to set

omega_wall = Const * nu / (beta * y^2)

where beta = 0.075, nu is kinematic viscosity, y is distance between the wall and centre of gravity of the first cell and Const = 6 (but you can try Const = 9 as well).

About the mesh - your domain is really big, IMHO too much. You're dealing with simple incompressible flow, so there will be no shock-waves and the flow should be quite "nice". 10 c in front of, above and below the aerofoil is OK, as for behind - 7c is quite enough (in some cases even 5c is ok). My mesh is indeed a C-mesh (although multiblock, which produces those two mesh density lines behind the aerofoil). Even if you have a good computation power the fact is that all your simulations can be ~4 times faster, I wouldn't hesitate ;)

P.

Hi Petr,

Thanks for your Reply,

so you mean to say I have to use Omega_wall = 9*1.5e-5/(0.075*0.00033^2) = 16528.9

Where Y = 0.00033 the existing value just to make the point clear

(by any chance do u have any reference for this as I am coming across it for the first time)

so for omega boundary condition
So what omega value do I use for the inlet boundary condition I am currently using the below which was calculated using the http://www.cfd-online.com/Wiki/Turbu...ary_conditions
equations for omega

Thanks for your opinion about the domain I think I will reduce domain size to 10c behind airfoil as well as there is lot of URANS simulations pending

Regards,
Hasan K.J

Hi Hasan,

the relation for omega comes from omega transport equation by Wilcox (Wilcox D. C.: Reassesment of the scale-determining equation for advanced turbulence models, AIAA J., 26, 1299-1310, (1988)), which (near the wall) can be reduced to

mu * d^2 omega/d y^2 - betta * rho * omega^2 = 0 (1)

Solution of (1) is the mentioned relation for omega. As for the inlet - I'm using the same equations you've referred to but combined with the fixedValue BC (but of course, both ways are possible).

P.

Hi Petr,

Thanks for the reference I will go through it in detail,

So for the wall is the boundary condition on my previous post looks reasonable enough for the omega ?

because I have never used the equation before I feel that the value is massive but I will have to do the simulations to see what happens but since you have a very good understanding and previous experience I would go with your word, if that is the type of value we are looking at for omega at airfoil wall.

Regards,
Hasan

Hello Petr,

Even using the Local velocity to find the Y distance using the online calculators gives me a wrong Y+ value when i check the Y+ after the simulations and I am aware openFOAM finds the Y* and I am using an altered yPlus utility to cacluate the Y+ after the simulation what could I do find the right Y distance for a Y+ of 30 any advice.

Kinds Regards,
Hasan K.J

Hi Hassan,

what values of y+ did you get during the last simulation?

What I've advised should lead to y+ <= 30 (not y+ = 30 all over the profile).

Btw, what values of k and omega do you set on the inlet?

Regards, P.

Hi Petr,

I am not trying for Y+ all over the the profile only for some regions and My max Y+ is not going above 12 I was hoping at least my Max Y+ will go above 30 my main aim was to get an average Y+ of 30 when I run the utility,

The K and W are the values I calculated using CFD wiki at the inlet, K =0.0216 and W = 9.45 at the inlet. and I am using wall functions as it is giving better results

Just came across this page:http://www.cfd-online.com/Forums/ope...lus-field.html
thinking might be of somehelp but dont know

Kind Regards,
Hasan K.J

Hi Hasan,

that seems quite good. I'd be interester in the results you achieve with this utility.

I've checked once more the schemes you are using and I'd give a try to the following settings:

gradSchemes
default cellLimited Gauss linear 1.0;

divSchemes
div(phi,U) bounded Gauss linearUpwindV grad(U);
div(phi,k) bounded Gauss linearUpwind grad(k);
div(phi,omega) bounded Gauss linearUpwind grad(omega);

laplacianSchemes
default Gauss linear corrected;

snGradSchemes
default corrected

according to http://www.dicat.unige.it/guerrero/o...sandtricks.pdf
and http://sourceforge.net/projects/open...k.tar/download

Should there be convergence problems of turbulent quantities start with simple 1st order upwind and after e.g. 200 iteration switch to 2nd order upwind as is written above.

Then to speed-up the convergence a bit you can try pre-conditioned version of GaussSeidel, that's DICGaussSeidel for p and DILUGaussSeidel for the rest (U,k,omega).

Hi Petr,

Thanks a lot for your reply,

Yes It is an awesome Utility those people have written, I makes a lot of job so much simpler. However It did not aid me much with my problem.

Infact I have been using that tips and tricks for sometime now It is a very good link. I have tried the schemes long ago on the same case and they don't give the changes we are expecting !!

However I have figured out the actual problem
The problem was clearly with the mesh and the first cell height.

How i figured out was but just taking a linear relationship between the Y+ i was getting from OpenFOAM to get the Y+ that i needed.

finally I had changed the first cell size to 0.0011m in the meshing software. (which is basically a random value i got with some linear relationship)

But when I converted the mesh to OpenFOAM and checked the Y+ using the online utilities this was the result I got
And also the boundary layer problem I had with the results were sorted in the results with this mesh.

But the funny Problem I am having now is when I assign a first cell height of 0.0011m in my meshing software I donot know why I am getting 0.00057 when the utility calculates the first cell distance in openFOAM. I am getting the correct results only when the Utility says my Y+ is 30.

I just have to figure out why this is happening If not just have to play with first cell height every single time :( :(. By any chance do you know how to check the distance between two points in ParaView

And if at all you have time please have a look at this post
http://www.cfd-online.com/Forums/ope...tml#post527629
Thanks a lot for all your replies and time.
Hasan K.J

Hi Hasan,

my experience with ICEM is limited - I was using it 4 years ago for 3D tetra meshing...

However, for measuring distance of two points in Paraview you can use the ruler tool (with 2D option in the layout window on). As far as I know Paraview doesn't snap to points with ruler, but if you zoom close enough you'll get reasonable value...

P.

Hi Petr,

There is no problem with mesh conversion from ICEM to openFOAM since the ruler option reads the same distance of first cell in paraView that I have used in ICEM. so this option is out I think it id just the yPlus utility takes someother factors into consideration and calculates Y as the value it gives and It appears to be 1/2 of the actual first cell distance so it does make some sense

Thanks again :)
Hasan K.J

I'll give my two cents on this problem.

I know this may looks like an obvious observation but...have you considered that "y" in the y+ formula is NOT the first near-wall cell height? It is the first near-wall cell CENTROID height indeed, which is half of the cell height for a prism cell. This because in finite volume methods (as in OF) we refer to cell centroids and not to cell vertex as in finite-element methods. I suppose that's why you have that mismatch...I've never had this kind of mismatch in my sim, y+ was correctly calculated by OF. I've tested also on ICEM mesh converted to OF format.

Best,

Andrea

Hey Andrea,

Thanks for your reply and I think that is pretty much why I am having this problem, now it makes total sense !!!.

So my question now is to have a required Y+ should my first near-wall cell centroid be set to the distance given by the online calculators and not my first cell wall ? for the solution to be accurate.
or it is just the utility that uses this method to calculate it this manner and I should go by my usual method of setting my first cell height to the distance given by the online calculators.

Thanks for your time
Regards,
Hasan K.J

Yes you should set your first near wall cell centroid position to be equal to the y coming from on line calculators. If you prefer to refer to first near wall cell height, you should set it to the double of y coming from y+ calculators, to obtain the required y+.

Regards,

Andrea

Hi Andrea,

Good afternoon. I am following this thread, as I have the same problem as Hasan KJ. I have set the y double in meshing process to get the required y+ in meshing software (cfMesh, Ansys ICEM). I have checked in paraview that the first wall thickness is same as specified in Meshing. But when I am calculating y+ in openFoam, it gives me different values. Another thing is that I am getting different y+ from yPlusRAS and yPlusLES. Any kind of suggestions will help me a lot.

Regards,

Ali

Hi Ali,

YPlusRAS calculates the Y star and not the Y Plus so

You might want to look in to these following threads for further details.

http://www.cfd-online.com/Forums/ope...-testcase.html

http://www.cfd-online.com/Forums/ope...lus-field.html

hope this helps you,

all the best,
Hasan K.J

Well, in my understanding the yPlusRAS utility let you have the y+ or the y* depending on what is the boundary condition you are using on your wall.

I mean, if I use the nutLowReWallFunction then from its code I get:

where y is the centroid distance from the wall patch, nuw is the kinematic viscosity and Uw is the fluid velocity both evaluated in the cell centroid next to the wall. We know that

y+=(y*U_tau)/nu
(where * mean multiply, I'm not referring to y* here)

and the formula in nutLowReWallFunction gives me exactly the y+ value, because we know that U_tau = sqrt(nu*dU/dy) evaluated at wall, assuming that y is the axis perpendicular to the wall.

Therefore I get the exact y+ value from the yPlusRAS utility if I use the nutLowReWallFunction boundary condition.

This is also consistent with the comments I found here:

http://www.openfoam.org/mantisbt/view.php?id=835

Please correct me if you have other info about this topic.

Best regards,

Andrea

Hi
I use LowRe model. When I type in ''yPlusRAS -compressible'', y+ is zero in all cells.
I noticed that you mentioned that this command was for HighRe model.
What can I do when I use LowRe model?

yPlusRAS works both for HighRe and LowRe turbulence models, the only difference is that it uses nut for incompressible flow while it uses mut for compressible flow.

There should be some other problem that gives you y+=0 in your cells...how do you check y+ value?

I noticed that there is no rho file in the folders. When I look into the file '' yPlusRAS.C ''

IOobject rhoHeader
(
"rho",
runTime.timeName(),
mesh,
IOobject::MUST_READ,
IOobject::NO_WRITE
);

if (!rhoHeader.headerOk())
{
Info<< " no rho field" << endl;
return;
}

Info<< "Reading field rho\n" << endl;
volScalarField rho(rhoHeader, mesh);

This probably means that the rho file must be required when using yPlusRAS.
And I am using sonicFoam, there is phi instead of rho.
So this is the reason why all the plus values is zero.
But still have no idea how to obtain the yPlus value, maybe rho from the state equation and then use yPlusRAS.

Do you have other suggestions? And thanks for your replying.