y+ and u+ values with low-Re RANS turbulence models: utility + testcase
2 Attachment(s)
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 |
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é |
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, 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. |
@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é |
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.
|
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 |
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 :-) |
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 |
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 |
That's crystal clear to me. Thanks very much for your time and attention.
Regards, Robert |
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: Thanks for your help, regards. |
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 |
Mh. I don't think so. I also set
Code:
type fixedValue; |
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 |
@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 |
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). |
not compatible with OF 2.0.0
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**)’: |
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 |
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; here's the error i get: Code:
#0 Foam::error::printStack(Foam::Ostream&) in "/sw/OpenFOAM/OpenFOAM-1.7.x/lib/linux64GccDPOpt/libOpenFOAM.so" best regards grandgo |
All times are GMT -4. The time now is 17:31. |