|
[Sponsors] |
y+ and u+ values with low-Re RANS turbulence models: utility + testcase |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
March 26, 2011, 06:30 |
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: 17 |
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 |
|
March 28, 2011, 12:50 |
|
#2 |
Member
José
Join Date: Jan 2011
Posts: 73
Rep Power: 15 |
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é |
|
March 28, 2011, 19:16 |
|
#3 |
Senior Member
Florian Krause
Join Date: Mar 2009
Location: Munich
Posts: 103
Rep Power: 17 |
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 |
|
March 29, 2011, 07:31 |
|
#4 | |
Senior Member
Join Date: Feb 2010
Posts: 213
Rep Power: 17 |
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:
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. |
||
March 29, 2011, 08:04 |
|
#5 |
Member
José
Join Date: Jan 2011
Posts: 73
Rep Power: 15 |
@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é |
|
March 29, 2011, 08:45 |
|
#6 |
Senior Member
Join Date: Feb 2010
Posts: 213
Rep Power: 17 |
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.
|
|
March 29, 2011, 11:50 |
|
#7 |
Senior Member
Florian Krause
Join Date: Mar 2009
Location: Munich
Posts: 103
Rep Power: 17 |
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 |
|
March 29, 2011, 12:21 |
|
#8 |
Senior Member
Join Date: Feb 2010
Posts: 213
Rep Power: 17 |
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 :-) |
|
May 9, 2011, 02:36 |
|
#9 |
Member
Robert Ong
Join Date: Aug 2010
Posts: 86
Rep Power: 16 |
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 |
|
May 9, 2011, 04:56 |
|
#10 |
Senior Member
Florian Krause
Join Date: Mar 2009
Location: Munich
Posts: 103
Rep Power: 17 |
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 |
|
May 9, 2011, 05:16 |
|
#11 |
Member
Robert Ong
Join Date: Aug 2010
Posts: 86
Rep Power: 16 |
That's crystal clear to me. Thanks very much for your time and attention.
Regards, Robert |
|
May 10, 2011, 08:02 |
|
#12 | |
Senior Member
Join Date: Feb 2010
Posts: 213
Rep Power: 17 |
Hi, Florian. I have two more little questions for you.
1. I don't understand what you mean with Quote:
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 Thanks for your help, regards. |
||
May 10, 2011, 09:11 |
|
#13 |
Member
Robert Ong
Join Date: Aug 2010
Posts: 86
Rep Power: 16 |
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 |
|
May 10, 2011, 09:17 |
|
#14 |
Senior Member
Join Date: Feb 2010
Posts: 213
Rep Power: 17 |
Mh. I don't think so. I also set
Code:
type fixedValue; value uniform (0 0 0); |
|
May 10, 2011, 10:55 |
|
#15 |
Member
Robert Ong
Join Date: Aug 2010
Posts: 86
Rep Power: 16 |
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 |
|
May 10, 2011, 14:07 |
|
#16 |
Senior Member
Florian Krause
Join Date: Mar 2009
Location: Munich
Posts: 103
Rep Power: 17 |
@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 04:39. |
|
May 17, 2011, 05:33 |
|
#17 | ||
Senior Member
Join Date: Feb 2010
Posts: 213
Rep Power: 17 |
Quote:
Quote:
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). |
|||
July 1, 2011, 10:25 |
not compatible with OF 2.0.0
|
#18 |
Senior Member
Roman Thiele
Join Date: Aug 2009
Location: Eindhoven, NL
Posts: 374
Rep Power: 21 |
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’
__________________
~roman |
|
July 1, 2011, 11:19 |
|
#19 |
Senior Member
Florian Krause
Join Date: Mar 2009
Location: Munich
Posts: 103
Rep Power: 17 |
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 |
|
July 11, 2011, 04:41 |
|
#20 | |
Member
Join Date: Oct 2010
Location: Stuttgart
Posts: 35
Rep Power: 16 |
Quote:
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; 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 best regards grandgo Last edited by grandgo; July 11, 2011 at 05:18. |
||
Tags |
low-re rans, y* value, y+ value |
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Low values of Lift force | vmlxb6 | CFX | 1 | February 2, 2011 06:13 |
Incompressible Turbulence models | achinta | OpenFOAM | 4 | May 27, 2010 11:35 |
turbulence models? | haider | FLUENT | 0 | March 8, 2006 00:58 |
Turbulence Models and external flow. | Alan | FLUENT | 3 | November 22, 2005 05:46 |
Turbulence boundary values | lego | CFX | 9 | October 25, 2002 12:55 |