CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM

y+ and u+ values with low-Re RANS turbulence models: utility + testcase

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree43Likes

Reply
 
LinkBack Thread Tools Display Modes
Old   March 26, 2011, 06:30
Default y+ and u+ values with low-Re RANS turbulence models: utility + testcase
  #1
Senior Member
 
Florian Krause
Join Date: Mar 2009
Location: Munich
Posts: 103
Rep Power: 7
florian_krause is on a distinguished road
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
Attached Files
File Type: gz plusPostRANSUtility.tar.gz (2.4 KB, 716 views)
File Type: gz plusPostRANSTestcase.tar.gz (54.6 KB, 437 views)
florian_krause is offline   Reply With Quote

Old   March 28, 2011, 11:50
Default
  #2
jms
Member
 
José
Join Date: Jan 2011
Posts: 73
Rep Power: 5
jms is on a distinguished road
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é
jms is offline   Reply With Quote

Old   March 28, 2011, 18:16
Default
  #3
Senior Member
 
Florian Krause
Join Date: Mar 2009
Location: Munich
Posts: 103
Rep Power: 7
florian_krause is on a distinguished road
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
florian_krause is offline   Reply With Quote

Old   March 29, 2011, 06:31
Default
  #4
Senior Member
 
Join Date: Feb 2010
Posts: 191
Rep Power: 6
vaina74 is on a distinguished road
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:
Quote:
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.
mgg likes this.
vaina74 is offline   Reply With Quote

Old   March 29, 2011, 07:04
Default
  #5
jms
Member
 
José
Join Date: Jan 2011
Posts: 73
Rep Power: 5
jms is on a distinguished road
@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é
jms is offline   Reply With Quote

Old   March 29, 2011, 07:45
Default
  #6
Senior Member
 
Join Date: Feb 2010
Posts: 191
Rep Power: 6
vaina74 is on a distinguished road
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.
vaina74 is offline   Reply With Quote

Old   March 29, 2011, 10:50
Default
  #7
Senior Member
 
Florian Krause
Join Date: Mar 2009
Location: Munich
Posts: 103
Rep Power: 7
florian_krause is on a distinguished road
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
florian_krause is offline   Reply With Quote

Old   March 29, 2011, 11:21
Default
  #8
Senior Member
 
Join Date: Feb 2010
Posts: 191
Rep Power: 6
vaina74 is on a distinguished road
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 :-)
vaina74 is offline   Reply With Quote

Old   May 9, 2011, 01:36
Default
  #9
Member
 
Robert Ong
Join Date: Aug 2010
Posts: 45
Rep Power: 6
rob3rt 0ng is on a distinguished road
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
rob3rt 0ng is offline   Reply With Quote

Old   May 9, 2011, 03:56
Default
  #10
Senior Member
 
Florian Krause
Join Date: Mar 2009
Location: Munich
Posts: 103
Rep Power: 7
florian_krause is on a distinguished road
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
florian_krause is offline   Reply With Quote

Old   May 9, 2011, 04:16
Default
  #11
Member
 
Robert Ong
Join Date: Aug 2010
Posts: 45
Rep Power: 6
rob3rt 0ng is on a distinguished road
That's crystal clear to me. Thanks very much for your time and attention.

Regards,
Robert
rob3rt 0ng is offline   Reply With Quote

Old   May 10, 2011, 07:02
Default
  #12
Senior Member
 
Join Date: Feb 2010
Posts: 191
Rep Power: 6
vaina74 is on a distinguished road
Hi, Florian. I have two more little questions for you.

1. I don't understand what you mean with
Quote:
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:
Code:
[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.
vaina74 is offline   Reply With Quote

Old   May 10, 2011, 08:11
Default
  #13
Member
 
Robert Ong
Join Date: Aug 2010
Posts: 45
Rep Power: 6
rob3rt 0ng is on a distinguished road
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
rob3rt 0ng is offline   Reply With Quote

Old   May 10, 2011, 08:17
Default
  #14
Senior Member
 
Join Date: Feb 2010
Posts: 191
Rep Power: 6
vaina74 is on a distinguished road
Mh. I don't think so. I also set
Code:
type            fixedValue;
value           uniform (0 0 0);
as wall velocity
vaina74 is offline   Reply With Quote

Old   May 10, 2011, 09:55
Default
  #15
Member
 
Robert Ong
Join Date: Aug 2010
Posts: 45
Rep Power: 6
rob3rt 0ng is on a distinguished road
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
rob3rt 0ng is offline   Reply With Quote

Old   May 10, 2011, 13:07
Default
  #16
Senior Member
 
Florian Krause
Join Date: Mar 2009
Location: Munich
Posts: 103
Rep Power: 7
florian_krause is on a distinguished road
@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

Last edited by florian_krause; May 11, 2011 at 03:39.
florian_krause is offline   Reply With Quote

Old   May 17, 2011, 04:33
Default
  #17
Senior Member
 
Join Date: Feb 2010
Posts: 191
Rep Power: 6
vaina74 is on a distinguished road
Quote:
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:
Quote:
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).
vaina74 is offline   Reply With Quote

Old   July 1, 2011, 09:25
Default not compatible with OF 2.0.0
  #18
Senior Member
 
romant's Avatar
 
Roman Thiele
Join Date: Aug 2009
Location: Stockholm, Sweden
Posts: 344
Rep Power: 10
romant is on a distinguished road
hej,

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

Code:
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.
__________________
~roman
romant is offline   Reply With Quote

Old   July 1, 2011, 10:19
Default
  #19
Senior Member
 
Florian Krause
Join Date: Mar 2009
Location: Munich
Posts: 103
Rep Power: 7
florian_krause is on a distinguished road
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
florian_krause is offline   Reply With Quote

Old   July 11, 2011, 03:41
Default
  #20
Member
 
Join Date: Oct 2010
Location: Stuttgart
Posts: 35
Rep Power: 6
grandgo is on a distinguished road
Quote:
Originally Posted by vaina74 View Post
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:
Code:
[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:

Code:
    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:

Code:
#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
mm.abdollahzadeh likes this.

Last edited by grandgo; July 11, 2011 at 04:18.
grandgo is offline   Reply With Quote

Reply

Tags
low-re rans, y+ value

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Low values of Lift force vmlxb6 CFX 1 February 2, 2011 05:13
Incompressible Turbulence models achinta OpenFOAM 4 May 27, 2010 10:35
turbulence models? haider FLUENT 0 March 7, 2006 23:58
Turbulence Models and external flow. Alan FLUENT 3 November 22, 2005 04:46
Turbulence boundary values lego CFX 9 October 25, 2002 11:55


All times are GMT -4. The time now is 21:10.