[florian_krause]

Dear all,

This issue was already discussed in some length in various threads. Therefore I finally reviewed and attached my plusPostRANS utility.

It calculates y+ and u+ values when using one of the available low-Re RANS turbulence models. I hope the code as well as the output will be self-explaining

I also attached a case. It is a straight pipe (wedge) with periodic inlet/outlet boundary conditions. The Reynolds number based on the mean axial velocity is Re=5300. You can run the case using pisoFoam.

I would appreciate any feedback, it might be still improved at some point!

Best regards,
Florian

[jms]

Dear Florian,

Thank you very much for the utility you have uploaded. I really need something like that.

I am doing a study of the flow around an airfoil using k-w SST in low-Re meshes. I tried your utility and hve some comments. Everything looks ok for me until the point where you write these two lines:
1) yPlus = y.y() * uTauAvg / RASModel->nu();
2) uPlus = U / uTauAvg;

1) yPlus is what you call "YpTemp", isn´t it? I don´t know why you use this uTauAvg value you have calculated to recalculate it.
2) uPlus =u_mean/uTau. This would be the velocity of the mean flow over the what you call "uTau".

If you agree and you change it, could you please upload it? Otherwise give me some comments about it.

Thank you very much!

Best Regards,

José

[florian_krause]

Dear Jose,
thanks for your feedback!

First I calculate y+ of the first grid point normal to the wall(s). I store the values in YpTemp and output the corresponding min, max, avg values on the screen.
Then I calculate the wall-averaged friction velocity uTauAvg (see below why I do that).

I think it is clear so far and for some people the y+ value of the first grid point normal to the wall might be sufficient.

Within the two mentioned lines I calculate fields of y+ and u+. If you think about a fully developed turbulent channel or pipe flow you might want to compare your results to, for instance, available DNS data by means of the near wall velocity profile in wall units or in other words comparing a profile of u+ over y+.

I hope it is clear now?

Best,
Florian

[vaina74]

Florian, you're simply great. Seven years for this useful, precious utility.
I builded it and seems to work fine. I hope it's right too :-)
I can't really understand the implementation of y*. 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 the question is: even if it was true (but it doesn't look so after my first tests), are they still comparable in the subviscous layer? I'm not sure about that, if I check my mesh quality when going to solve the boundary layer. 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.
Well, I hope your utility will be tested and included in OF. I builded it in OF-1.5-dev and it's OK - I simply changed some paths.

[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é

[vaina74]

I'm involved with marine propellers, so I study external flows as jms. I understand what he means, I agree with him. I also think you can't have that assumption about averaging operation.

[florian_krause]

Dear Jose,

I totally agree with you on the point that the averaging over the wall is not usefull for your case.

I have implemented that because I was studying, as said in the previous message, fully developed turbulent pipe and channel flow using low-Re RANS models and LES models.

If it really bothers you guys, that it writes the files yPlus and uPlus in the corresponding time directory, I suggest you to remove the relevant sections in the code, so that you just output the min, max, avg y+ value of the first grid point normal to the wall

Best,
Florian

[vaina74]

OK, I can remove the above lines or even don't look at those values :-D
It was just a suggestion in order to make your utility more 'universal', if included in OF in the future.
Anyway, thanks a lot again. Now I see why I obtained strange results from my case, when I tried to have a finer mesh and solve the boundary layer. the f*** y* said 'you're inside it!' but I was in the forbidden zone :-)

[rob3rt 0ng]

Hello All,

I'm still abit unclear about this issue of y+ and y*. So is it right to say that yPLusRAS and yPlusLES return y* values whereas the code Florian uploaded returns y+?

Thanks very much for your time and attention.

Thanks
Robert

[florian_krause]

Hello Robert,

my code calculates y+ as defined here:

http://www.cfd-online.com/Wiki/Dimen...e_%28y_plus%29

so, basically, my little utility calculates the wall normal distance (and velocity) in wall units.

The yPlusRAS utility calculates y* as defined here (normally I try not to quote the FLUENT manual):

http://my.fit.edu/itresources/manual...ug/node512.htm

The yPlusLES utility again calculates y+, quite similar (references to the turbulence model, etc are different) to my utility.

You should check the source code:

http://foam.sourceforge.net/doc/Doxy...8C_source.html

http://foam.sourceforge.net/doc/Doxy...8C_source.html

To understand why, plusPostRANS (my utility) and yPlusLES are used when no wall function are employed, whereas yPlusRAS is used when you employ wall functions.

hope this helps! for everyone, please correct me if I am unclear or wrong at some point.

Best,
Florian

[rob3rt 0ng]

That's crystal clear to me. Thanks very much for your time and attention.

Regards,
Robert

[vaina74]

Hi, Florian. I have two more little questions for you.

1. I don't understand what you mean with

To understand why, plusPostRANS (my utility) and yPlusLES are used when no wall function are employed, whereas yPlusRAS is used when you employ wall functions.

I can't use your code, when a turbulent model with wall functions is applied?

2. I sometimes have the following error, when I run your utility:

[of_mauro@ofmaster:
/daten/of_mauro/tandem/SVA/tandem_35mm_70plusdeg_VERTIG/propeller]
plusPostRANS
/*---------------------------------------------------------------------------*
| ========= | 
|
| \ / F ield | OpenFOAM: The Open Source CFD Toolbox 
|
| \ / O peration | Version: 1.5-dev 
|
| \ / A nd | Revision: exported 
|
| \/ M anipulation | Web: http://www.OpenFOAM.org 
|
*---------------------------------------------------------------------------*/
Exec : plusPostRANS
Date : May 10 2011
Time : 09:35:37
Host : ofmaster.cluster
PID : 11391
Case : /daten/propeller
nProcs : 1

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//
Create time

Create mesh for time = 0

Calculating wall distance

Writing wall distance to field y

Reading field U

Reading/calculating face flux field phi

Initializing the GGI interpolator between master/shadow patches:
stitch_in/stitch_out
Evaluation of GGI weighting factors:
Largest slave weighting factor correction : 0.000660947 average:
0.000164952
Largest master weighting factor correction: 0.0616967 average: 0.000553025

Initializing the GGI interpolator between master/shadow patches:
cyclic_1/cyclic_2
Evaluation of GGI weighting factors:
Largest slave weighting factor correction : 2.61023e-06 average:
4.22461e-09
Largest master weighting factor correction: 2.6471e-06 average:
4.24771e-09

Initializing the GGI interpolator between master/shadow patches:
symmetry_1/symmetry_2
Evaluation of GGI weighting factors:
Largest slave weighting factor correction : 3.33067e-16 average:
6.76395e-17
Largest master weighting factor correction: 2.77556e-15 average:
6.92661e-17

Selecting incompressible transport model Newtonian
Selecting RAS turbulence model kOmegaSST
Summary:

y+ for Patch 0 named blade1: min: 0 max: 0 average: 0 avgUGradWall: 0

y+ for Patch 1 named blade2: min: 0 max: 0 average: 0 avgUGradWall: 0

avg. friction velocity uTau is: 0 (averaged over 2 wall(s))

Floating point exception

Have you ever encountered it? What does it mean, in your opinion?

Thanks for your help, regards.

[rob3rt 0ng]

Hello,

For your question 2, that happens to me as well everytime I set my wall velocity as fixedValue&$internalField. In contrast everytime I set the wall velocity as fixedValue&uniform (0 0 0) or slip, the utility works fine.

Perhaps Florian may comment on this?

Thanks and regards,
Robert

[vaina74]

Mh. I don't think so. I also set

type            fixedValue;
value           uniform (0 0 0);

as wall velocity

[rob3rt 0ng]

Hello again,

As it turns out for my case that both the $internalField and uniform (0 0 0) now give me the y+ value. My problem was setting the wall velocity the same as my inlet velocity, so now for my wall velocity I just set something very close to the inlet velocity.

Thanks
Robert

[florian_krause]

@vaina74-what I mean is, if you use a high-Re RANS model, as for instance standard k-eps RANS model, you will use wall functions and thus your first grid point normal to the wall will not be located at around y+=<1, but somewhere, lets say in the logarithmic region. Then plusPostRANS is not the right tool, because for instance the gradient calculation will not be accurate. I think for this purspose, you should use yPlusRAS.

In fact, if you are about to generate a grid and you want to know if your first grid point is located at the right wall normal distance, then you should be able to use it, plusPostRANS and yPlusRAS should give you almost the same. I never tried that, but would be nice if you would let me know what it gives... sorry for the confusion!

Considering the second problem, without having a look at the case, ICs and BCs I cannot tell you why you get a floating point exception. But it seems that you velocity gradient is for some reason zero?!

Hope I could help!

Best,
Florian

[vaina74]

what I mean is, if you use a high-Re RANS model, as for instance standard k-eps RANS model, you will use wall functions and thus your first grid point normal to the wall will not be located at around y+=<1, but somewhere, lets say in the logarithmic region. Then plusPostRANS is not the right tool, because for instance the gradient calculation will not be accurate. I think for this purspose, you should use yPlusRAS

Well, I didn't understand that, thanks for your specification. I use k-w SST turbulent model with high-Re grids and wall functions. But I don't know if yPlusRAS tool is really meaningful. In another thread i wrote:

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?

I already tried to apply both y+ post-processing tools. Your code seems to output higher values, but I can't say if it depends on my specific case.

About the second problem I wrote about, I attach my IC and BC. What seems strange to me is that your tool sometimes fails (I'm running very similar cases on these weeks in order to test different propellers configurations).

[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.

[florian_krause]

I haven't downloaded and installed OF-2.0.0 yet, so I might be of limited help here...

Anyway, if the plusPostRANS source is not modified, then the compiler seems to complain about RASModel->nu().boundaryField()[patchi]

I would suggest you to check out the source of the yPlusLES utility of OF-2.0.0 and look for differences to the previous version, lets say OF-1.7.x

The point is, in all three codes (yPlusLES.C from OF-2.0.0, yPlusLES.C from OF-1.7.x and plusPostRANS.C from OF-1.7.x) you need something like RASModel->nu().boundaryField()[patchi] or sgsModel->nu().boundaryField()[patchi] respectively.

Best,
Florian

[grandgo]

Originally Posted by vaina74

Hi, Florian. I have two more little questions for you.

1. I don't understand what you mean withI can't use your code, when a turbulent model with wall functions is applied?

2. I sometimes have the following error, when I run your utility:

[of_mauro@ofmaster:
/daten/of_mauro/tandem/SVA/tandem_35mm_70plusdeg_VERTIG/propeller]
plusPostRANS
/*---------------------------------------------------------------------------*
| ========= | 
|
| \ / F ield | OpenFOAM: The Open Source CFD Toolbox 
|
| \ / O peration | Version: 1.5-dev 
|
| \ / A nd | Revision: exported 
|
| \/ M anipulation | Web: http://www.OpenFOAM.org 
|
*---------------------------------------------------------------------------*/
Exec : plusPostRANS
Date : May 10 2011
Time : 09:35:37
Host : ofmaster.cluster
PID : 11391
Case : /daten/propeller
nProcs : 1

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//
Create time

Create mesh for time = 0

Calculating wall distance

Writing wall distance to field y

Reading field U

Reading/calculating face flux field phi

Initializing the GGI interpolator between master/shadow patches:
stitch_in/stitch_out
Evaluation of GGI weighting factors:
Largest slave weighting factor correction : 0.000660947 average:
0.000164952
Largest master weighting factor correction: 0.0616967 average: 0.000553025

Initializing the GGI interpolator between master/shadow patches:
cyclic_1/cyclic_2
Evaluation of GGI weighting factors:
Largest slave weighting factor correction : 2.61023e-06 average:
4.22461e-09
Largest master weighting factor correction: 2.6471e-06 average:
4.24771e-09

Initializing the GGI interpolator between master/shadow patches:
symmetry_1/symmetry_2
Evaluation of GGI weighting factors:
Largest slave weighting factor correction : 3.33067e-16 average:
6.76395e-17
Largest master weighting factor correction: 2.77556e-15 average:
6.92661e-17

Selecting incompressible transport model Newtonian
Selecting RAS turbulence model kOmegaSST
Summary:

y+ for Patch 0 named blade1: min: 0 max: 0 average: 0 avgUGradWall: 0

y+ for Patch 1 named blade2: min: 0 max: 0 average: 0 avgUGradWall: 0

avg. friction velocity uTau is: 0 (averaged over 2 wall(s))

Floating point exception

Have you ever encountered it? What does it mean, in your opinion?

Thanks for your help, regards.

hi vaina,

i've encountered the same problem about some "floating point exception".
do you know the solution for this problem?

EDIT: after some testing i've found out that it's something about this code at the end the .C file:

    yPlus = y.y() * uTauAvg / nuEff;
    uPlus = U / uTauAvg;

if you comment these lines out, the tool will calculate at least. i think it's because somewhere nuEff or uTauAvg is zero and division causes the crash.

here's the error i get:

#0  Foam::error::printStack(Foam::Ostream&) in "/sw/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/libOpenFOAM.so"
#1  Foam::sigFpe::sigFpeHandler(int) in "/sw/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/libOpenFOAM.so"
#2   in "/lib64/libc.so.6"
#3  
 in "/home/stss8/OpenFOAM/stss8-1.7.x/applications/bin/linux64GccDPOpt/uyPlusLES"
#4  
 in "/home/stss8/OpenFOAM/stss8-1.7.x/applications/bin/linux64GccDPOpt/uyPlusLES"
#5  __libc_start_main in "/lib64/libc.so.6"
#6  
 at /usr/src/packages/BUILD/glibc-2.11.2/csu/../sysdeps/x86_64/elf/start.S:116
Gleitkomma-Ausnahme  //floating point exception

i made some changes (LES) and renamed the tool, for your information

best regards
grandgo