CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Programming & Development (http://www.cfd-online.com/Forums/openfoam-programming-development/)
-   -   Definition of y+ in yPlusRAS (1.7.1) (http://www.cfd-online.com/Forums/openfoam-programming-development/80595-definition-y-yplusras-1-7-1-a.html)

 Taka1 September 30, 2010 07:45

Definition of y+ in yPlusRAS (1.7.1)

I have computed flow around a spheroid using simpleFoam(1.7.1) and Fluent using k-omega-SST model and an identical mesh.

The results were very similar except that value of y+ computed by yPlusRAS is much smaller than that in Fluent.

Only the value is different and the pattern of the distribution was similar. So it looked as if the y+ value in Foam was multiplied by a factor.

I also confirmed that the magnitude of the wall shear stress is almost the same in Foam and Fluent.

The height of the cell next to the wall is 5e-6, and the value of wall distance at the cell center is 2.5e-6.
The magnitude of wall shear stress at a point is 4.6e-3, rho is 1, and nu is 2.38e-7.
Then, I suppose the value of y+ is

y+ = 2.5e-6 * sqrt (4.6e-3) / 2.38e-7 = 0.7

Fluent gives this value, but Foam gives 0.04.

I wonder if the definition of y+ is not this way in Foam.

I appreciate any suggestion or comment.

Regards

 niklas September 30, 2010 07:56

without too much effort, checking in RASModel.C

Code:

```        Yp = pow(Cmu, 0.25)             *y_[patchNo]             *sqrt(k()().boundaryField()[patchNo].patchInternalField())             /nu().boundaryField()[patchNo];```
so yes, there is a factor there Cmu^0.25.

 Taka1 September 30, 2010 08:45

Thank you very much for the very quick answer. I looked at RASModel.C.

There is a factor of Cmu^0.25, that is 0.55.
On top of that, y+ in RASModel is based on k (not on tau_w).

So yPlusRAS assumes that the first point is in the log-arithmetic layer.

 bastil October 1, 2010 03:17

Quote:
 Originally Posted by Taka1 (Post 277276) Thank you very much for the very quick answer. I looked at RASModel.C. There is a factor of Cmu^0.25, that is 0.55. On top of that, y+ in RASModel is based on k (not on tau_w). So yPlusRAS assumes that the first point is in the log-arithmetic layer.
There were some posts about that some time ago. yPlusRAS calculates a value that is called ySTAR in FLUENT. I have proposed to change that but without any success so far.

 niklas October 1, 2010 04:43

1 Attachment(s)
There is a utility called yPlusLES where yPlus is calculated like below.
Code:

```                yPlus.boundaryField()[patchi] =                     d[patchi]                   *sqrt                     (                         nuEff.boundaryField()[patchi]                       *mag(U.boundaryField()[patchi].snGrad())                     )                   /sgsModel->nu().boundaryField()[patchi];```
so the wall shear stress is now calculated using the velocity surface-normal gradient
It is very easily modified to handle the RAS models instead and
I've attached that here. (Note that its only for incompressible flows)

If you think the yPlus calculation is a problem, which I can assume that you do since
an erroneous y+ value can result in an erroneous calculation of the viscosity,
you can just modify the RASModel.C file to be in accordance with the
calculation in this utility.

what values does this utility yield btw?

 Taka1 October 1, 2010 07:51

There were some posts about that some time ago. yPlusRAS calculates a value that is called ySTAR in FLUENT.

Yes, I noticed that. But in Fluent, values of ySTAR and yPLUS were similar.
It seems that lo-Re correction is applied to ySTAR in Fluent.

what values does this utility yield btw?

I tried your "yPlus", and confirmed yPlus value is almost exactly the same as Fluent!

Thank you very much for valuable comments and a tool.

 jms March 15, 2011 10:29

Hi Niklas,

There is one very important thing I want to comment though. The equation that you can find in it uses a variable "d", i.e. the nearWall distance. I had a look at the values of this d. I expected them to be the same all over the airfoil I am computing (since I am using a mesh with constant 1st cell height of 2.75e-5). To be sure that this is constant after having converted it to OF, I checked that in a post processor and this 1st cell height is constant, so there are no "conversion issues"). :S

What I get is that they oscillate between 9e-6 and 1.3e-05. I don´t like this because the value of the computed yPlus then is not perfect.

Thanks,

Regards,

José

 niklas March 15, 2011 11:19

height of cell is not used at all for calculating y+,
it is defined by the face normal distance of cell centre to the wall face centre.
i.e. mag((Cf-Cc) & Sf), where
Sf = face normal of length 1
Cf = face centre
Cc = cell centre
So on a flat surface it should be cell height/2, but on curved surfaces...it can vary.

How do you ensure that the cell height is always the same and what does that mean?
Especially on curved surfaces.
How do you calculate this?
Is it calculated as the wall normal distance (at node) from wall node to the node above
or
is it defined by the averged wall normal distance from face center or node below?

The variation in y-distance is probably due to these inconsistencies which will
be visible on curved surfaces.
If you want a constant y-value, you need to make sure that the mesher you have use
the same definition as foam.

 jms March 15, 2011 12:44

1 Attachment(s)
Hi Niklas,

Yes, you are right, I was also thinking that it was taking the cell height / 2 to calculate y+ since it is a "cell center based code". So, we agree on that! :D

I know that the 1st cell height is constant because I have opened the mesh in a post processor (ParaView of CFX´s post processor) and I can see it! You can also see the leading edge of my airfoil in the picture I attach. I have measured it with this ruler from the software, of course, and this first cell height is the same all over the airfoil. Don´t you think then that nearWallDist should give the same value for all the cells?

Then, what I have understood from your last message is that this point of the code yPlus.C you uploaded...
"volScalarField::GeometricBoundaryField d = nearWallDist(mesh).y();"
is not giving the right value of wallDistance for all the surfaces, is it? What to do otherwise?
any idea?

Thanks,

José

 grjmell March 21, 2011 12:22

sorry deleted

 vaina74 March 24, 2011 10:40

I'm really surprised to find out that yPlusRAS evaluate y*, not y+. Why was y* implemented?! I can't understand the reason. I looked for it on internet and it seems to be used only in FLUENT. In the FLUENT User Guide I read:
Quote:
 Note that y+ and y* have comparable values when the first cell is placed in the log-layer.
But are they still comparable in the subviscous layer? I'm not sure about that, so the question is: how can I check my mesh quality if I'm going to solve the boundary layer? Only a yPlusRAS (based on y*) is available. Anyway, I can't get the physical sense of y*. I'm probably wrong, but I think that the average fluctuating kinetic energy is correlated to fluctuations, not to local or friction velocity. I can have large or small fluctuations with high or low velocity. Can anyone explain that?

 rob3rt 0ng April 24, 2011 22:13

Hi All,

How can I ask OpenFOAM to recall the wall distance (y) as used for the calculation of yPlus?

I tried typed in wallDist it doesnt recognise it.

Thanks

 rob3rt 0ng April 24, 2011 23:32

Ah I think I figured it out. Thanks

 camoesas October 4, 2011 07:53

Quote:
 Originally Posted by rob3rt 0ng (Post 304911) Ah I think I figured it out. Thanks

would you mind to share your experience?

 rob3rt 0ng October 4, 2011 07:58

Quote:
 Originally Posted by camoesas (Post 326614) would you mind to share your experience?
Hi,

When you run either one of yPlusRAS or yPlusLES, it already gives you the wall distance (y). Check the time folder.

Regards,
Robert

 newToOpenFoam October 13, 2011 04:16

Hi Niklas,

I tried to run wmake on the yPlus code you uploaded, but I get the following error message:
/usr/bin/ld: cannot find -lgenericPatchFields
Is it due to the fact that I am using OF 1.6, or there something that I have missed?

 camoesas October 13, 2011 08:14

HI Johan,

Make sure you're using the newer version. In this thread there are two versions of Niklas' yPlus function. I dont know which one is in here.

Anyway this wont solve your problem. And so far I cant tell you how to solve it. I have a simlar problem with OF-2.0.0:

cannot find:
Code:

`nutWallFunction/nutWallFunctionFvPatchScalarField.H`
I guess the name has changed...
I'll keep you updated, if I can fix it.

 Saxwax October 13, 2011 21:07

First Cell Normal Distance

1 Attachment(s)
Hi José,

I'm not sure if you are still interested in this thread but I thought I might just post this up anyway. I've attached a sketch that (hopefully) shows how the first cell centre normal distance will be different to 1/2 the cell "height" (I'm assuming you have projected surface normals a uniform distance or something similar). If my diagram is wrong then I am sure I will find out soon enough :) - it seems consistent with the variation of first cell centre normal distance that you have indicated.

I think that if you want more consistent first cell centre normal distances then you may want to refine your surface mesh more in the areas with high curvature.

Regards,

D.

 Saxwax October 17, 2011 00:36

yPlus code change for OF 2.0.*

1 Attachment(s)
To compile the yPlus code for OF 2.0.* requires a few small changes:

There are multiple nutWallFunctions available in 2.0.* - the RASModels.C file utilises nutkWallFunction in the y+ (Yp) function that is used by yPlusRAS. The nutWallFunction header needs to be changed to the nutkWallFunction header.

I'm not sure on the C++ lingo on this next one but (line 92 of the attached file)

RASModel->nu().boundaryField()[patchi]

Is changed to

RASModel->nu()().boundaryField()[patchi]

Again, I have based this on RASModel.C (not my C++ knowledge or lack there of)

Please note I know virtually nothing about C++, I have simply switched a few pieces of code until the C file could be compiled. Hopefully someone who knows more than me can have a look at this to check that the changes make sense.

Regards,

D.

 camoesas October 17, 2011 07:33

HI Saxwax,

Thanks for your hint I`ve got compiled it now.
testing it now!

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