[Taka1]

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.

Thank you for reading.

Regards

[niklas]

without too much effort, checking in RASModel.C

        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]

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]

Originally Posted by Taka1

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]

There is a utility called yPlusLES where yPlus is calculated like below.

                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]

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]

Hi Niklas,

I am using the yPlus file you uploaded. BTW, thank you very much for uploading it...

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.

Can you tell me anything about this?

Thanks,

Regards,

José

[niklas]

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]

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!

Then...some comments!

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]

sorry deleted

[vaina74]

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:

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]

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]

Ah I think I figured it out. Thanks

[camoesas]

Originally Posted by rob3rt 0ng

Ah I think I figured it out. Thanks

would you mind to share your experience?

[rob3rt 0ng]

Originally Posted by camoesas

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]

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?

Thanks in advance

[camoesas]

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:

nutWallFunction/nutWallFunctionFvPatchScalarField.H

I guess the name has changed...
I'll keep you updated, if I can fix it.

[Saxwax]

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]

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]

HI Saxwax,

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