[francois]

Hi all,

I've downloaded plusPostRANSUtility2.0.zip and try to use it on my case (swirling flow in a pipe). I've got strange results with it : the min and max y+ values printed on a wall patch at the output don't match the ones found in the yPlus file.

For example, I've got:

* output of plusPostRANS
Summary:
y+ for Patch 2 named pipeWall-Up: min: 0.8746923999 max: 2.039454412 average: 1.526102563 avgUGradWall: 612.5482318

* timeDirectory/yPlus file
pipeWall-Up
{
type calculated;
value uniform 2.22815734e-11;
}

The value is constant over the entire wall patch .... strange isn't it ?

I'm using openFOAM version 2.1.0 with simpleFoam solver and a LaunderSharmaKE low reynolds model.

My boundary condition on the wall patch are :

* For k:
pipeWall-Up
{
type fixedValue;
value uniform 1e-10;
}

* For epsilon:
pipeWall-Up
{
type fixedValue;
value uniform 1e-10;
}

* For nut:
pipeWall-Up
{
type nutLowReWallFunction;
Cmu 0.09;
kappa 0.41;
E 9.8;
value uniform 3.003634983e-13;
}

* For U
pipeWall-Up
{
type fixedValue;
value uniform (0 0 0);
}

Do you have any advice for me ?
Thank you for your help.

Cheers
Francois

[owayz]

Hi francoise,
Well if you look in to the utility the yplus on patch which is printed out is not the one which is written as a field.
to calculate the yplus in the whole field (i.e. the one that is written out as a field), uTau (friction velocity on wall) averaged over the whole wall patch is used.
So thats the reason why you can't find the min and max values as the ones that are in yPlus field file.
Plus I really don't understand y you are getting something like a uniform value on the wall. The utility worked fine for me. Also you boundary conditions are almost similar to mine so I am not able to figure out why is this happening.
Regards,
Awais

[owayz]

May be your nut wall function is the problem. Try changing it to something like.
I used zerogradient BC for mut on wall.
regards,,
Awais

[francois]

Awais,

Thank you very much for your kind answer, it's very nice from you !

I've tried what you suggested (change nut wall BC from nutLowReWallFunction to zeroGradient) but unfortunately it doesn't change anything the yPlus field is always uniform on the wall with a value near zero in timeDirectory/yPlus file :

pipeWall-Up
{
type calculated;
value uniform 3.887124583e-11;
}

Any idea ?
Thank you very much for your help.

Take care
françois

[florian_krause]

Hi Francois,
what is written in timeDirectory/y at the pipeWall-Up patch?

Regards,
Florian

[francois]

Hi Florian,

Thank you for your kind and quick answer

In my previous post I indeed forgot to mention that the y field was also zero on my wall patches:

pipeWall-Up
{
type calculated;
value uniform 1e-15;
}

I've made the test with nut boundary condition as zeroGradient and nutLowReWallFunction. The result is the same for y and yPlus fields.

It's very nice from you to take the time to answer my questions, I really appreciate.
Thank you very much !

François

PS: I thought that yPlusRAS could be used with low Re models WHEN using nutLowReWallFunction boundary condition for nut on the wall. But the output values between plusPostRANS and yPlusRAS are quite different and seems to be unphysical with yPlusRAS.

[florian_krause]

Hi Francois,
there you have the reason why yPlus at the wall patch is practically zero

y is zero because it is the wall distance... and well, since pipeWall-Up is the wall, it is zero of course.

Can you please check internalField values of y and yPlus (you can also do that in Paraview using a threshold value) in timeDirectory/y and /yPlus

Let me know if those values make sense to you.

Best,
Florian

[francois]

Florian,

Thank you very much for your explanations and sorry for my misunderstanding.

I thought that plusPostRANS wrote the normal distance from wall to cell center (aka y) and yPlus values for the first adjacent wall cell in the corresponding wall patches boundary field. With yPlusRAS, this is this behavior for yPlus boundary field values. I thought that plusPostRANS had the same behavior, my bad ...

Anyway, how do you then plot the yPlus field for the first adjacent wall cell in Paraview ? As you mentioned before, if I just select one of my wall patch the y or yPlus values will be zero.

And yes the y and yPlus values "seems" to be correct
Thanks again for your so helpful behavior

Regards,
François

[florian_krause]

Originally Posted by francois

Florian,

Thank you very much for your explanations and sorry for my misunderstanding.

I thought that plusPostRANS wrote the normal distance from wall to cell center (aka y) and yPlus values for the first adjacent wall cell in the corresponding wall patches boundary field. My bad ...

Anyway, how do you then plot the yPlus field for the first adjacent wall cell in Paraview ? As you mentioned before, if I just select one of my wall patch the y or yPlus values will be zero.

And yes the y and yPlus values "seems" to be correct
Thanks again for your so helpful behavior

Regards,
François

Let me explain - the primary purpose of the utility was to print the max yPlus value so that I can judge how well my wall region is resolved (I added average and min yPlus cause it might be helpful in some cases).

Then I needed to plot uPlus over yPlus. So, for convinience I wrote out yPlus and uPlus internal fields which I can for instance postprocess using the sample utility (for instance sampling from pipe center to the wall)

So, y is the distance from a cell center to the wall. And for every internal cell you will find a corresponding yPlus value (thats what you find as internalField values).

I am not sure how you can easily visualize the first wall adjacent cell. But what about the following approach: from the min/max/avg output take the max value. In paraview, use this as a threshold value of the yPlus field and show only cells which have a lower (and equal) YPlus value. This should work...

Good luck!
Florian

[francois]

Thanks Florian for your precisions and so friendly help
Cheers

François

[Sunxing]

Originally Posted by romant

hej,

unfortunately, one cannot compile this one with OF 2.0.0. It throws the following error message:

plusPostRANS.C: In function ‘int main(int, char**)’:
plusPostRANS.C:96:40: error: ‘class Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> >’ has no member named ‘boundaryField’
plusPostRANS.C:99:36: error: ‘class Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> >’ has no member named ‘boundaryField’

apparently, the class geometric field was changed.

Hi, romant

I have met the same problem with you for my version is OF 2.1.1
Have you solved the problem?

Best
Sunxing.

[florian_krause]

Hello Sunxing,
you should have mentioned which version of the utility you have used. Did you use the one Francois linked in post #41 ?

Regards,
Florian

[Sunxing]

Originally Posted by florian_krause

Hello Sunxing,
you should have mentioned which version of the utility you have used. Did you use the one Francois linked in post #41 ?

Regards,
Florian

Hi Florian，

Excuse me please. I didn't noticed the one in post #41 and It worked well for my version.

Best
Sunxing

[lakeat]

Originally Posted by jms

@Florian: This averaging you have done makes sense for me when talking about flow in a pipe or a channel, where you will have the same y+ and u+ in all its walls. However, for an airfoil, where you have this different distribution of velocities and pressures you can not do it. It has to be done without averaging, as I told you in the previous message.
The part of the code that gives you in the command prompt y+ (coming from Yptemp) is ok for me to get y+. However, I cannot use the files yplus and uplus to draw the boundary layer.

@vaina74: I am sure based on the results I get that y* and y+ are not comparable inside the viscous sublayer. This is why I am using Florian´s code and one which was already uploaded but did not create the files "yplus" and uplus".

Regards,

José

Okay, FOAM community,

Since I feel there is a little bit confusion here, and I agree with Jose's concern in this post, so I just rewrote them based on OpenCFD's version of OpenFOAM. You can download them here,

yPlus utility: yPlus.tar.gz
yStar utility: yStar.tar.gz

Here are some descriptions:

1. yPlusRAS is renamed as yStar, and could be only used with RANS turbulence models.
2. yPlus is calculated by a more direct approach according to the equation.
3. yPlus could be used as Low-Re RANS models, and LES.
4. As we are not sure about the first cell grid location, wall shear stress should be calculated with effective viscosity. This is the key difference from Florian's plusPostRANSUtility utility.
5. I think distance to the wall is a very helpful information for most of us, and should be always output to the screen.
6. I think all the averaging calculation and uPlus calculation do not belong here, they will create confusion here, they should be inserted into other utilities like postChannel utility. And actually one can work with UMean field not U field.

7. The utilities are basically just a small modification to the original OpenFOAM codes' name convention. So should work with both incompressible and compressible flows.

Cheers,

[aljazari]

Originally Posted by lakeat

Okay, FOAM community,


yPlus utility: Attachment 16997
yStar utility: Attachment 16998


Cheers,

The original yPlusRAS had a compressible option, can we have this for yPlus?

[lakeat]

Sure, It's easy to add it. I'll look into it when I get back to the office.

[lakeat]

Here they are:

yPlus: yPlus.tar.gz
yStar: yStar.tar.gz

[aljazari]

Originally Posted by lakeat

Here they are:

yPlus: Attachment 17067
yStar: Attachment 17068

Thanks a lot, they are really helpful.

[atg]

Originally Posted by lakeat

Here they are:

yPlus: Attachment 17067
yStar: Attachment 17068

I'm assuming the proper procedure is to extract these files to the same directory where yPlusRAS normally exists, then execute some sort of make command. I did that, creating a directory within
/OpenFOAM-2.1.1/applications/utilities/postProcessing/wall/
called "yPlus"

then executed ./Allwmake from the applications folder. This appeared to work.

But when I fired up a new terminal and tried "yPlus" command from the run/case directory, "command not found" returns.

What am I missing here?

Thanks,
Karl

[aljazari]

Originally Posted by atg

I'm assuming the proper procedure is to extract these files to the same directory where yPlusRAS normally exists, then execute some sort of make command. I did that, creating a directory within
/OpenFOAM-2.1.1/applications/utilities/postProcessing/wall/
called "yPlus"

then executed ./Allwmake from the applications folder. This appeared to work.

But when I fired up a new terminal and tried "yPlus" command from the run/case directory, "command not found" returns.

What am I missing here?

Thanks,
Karl

It seems that it didn't work properly, you don't need to copy yPlus there anyway, you can compile it from any directory. When you open the terminal at the directory where yPlus is located, run:

wmake

It will try to compile however it will give a permission error.

Then in the terminal run:

sudo bash

After entering the root password, run:

wmake

This time it will compile and you will have yPlus working.

Note that you need to do the first step even though it gives a permission error.