Problems with YPlusRAS and wallShearStress
Dear Foamers,
I am simulating a simple compressible channel flow, using the rhoSimpleFoam solver and the k-Omega-SST turbulence model. For postprocessing, I'd like to compute YPlus to validate my grid and the wall shear stress. The Reynolds-number is about 18000. Also, I calculated Tau_wall and YPlus using correlations to validate my results. For YPlus at the wall: I used the Blasius-correlation to calculate Cf (Cf = 0.079 * Re ^(-0.25)) Then I calculated Tau_wall using Cf = Tau_wall / (0.5 * rho_0 * U_0^2). Using Tau_wall, it was easy to calculate U_tau (= sqrt (Tau_wall/rho)) and yPlus (= U_tau * y/ nu with y = height of the closest cell to the wall, this gives me the y* of the first cell). For Tau_wall: Using the Blasius-correlation and calculate Tau as described above. Unfortunately, the values of yPlus were not even close to the ones given by the openFoam utility, and the values of Tau_wall were different by about 20 percent. The next approach to solve this problem was to write a program, calculating the wall shear stress using the wall velocity gradient, calculated by wallGradU. The shear stress is calculated Tau_wall = nu*rho * du/dn, taking du/dn from wallGradU. This results matched the ones calculated with the correlation much better. (better description of how to calculate wall shear stress can be found here: http://www.cfd-online.com/Forums/ope...interfoam.html) Therefore, I assume that wallShearStress and YPlus give wrong values. Unfortunately, I don't know why. I just know that those tools are using the wall models to calculate the values, but I don't know how this works exactly. Is someone familiar with this problem? Can somebody tell me why these results calculated with this tools are wrong? I think I read somewhere that those tools are only valid for incompressible flows, but not for compressible ones, is that true? Does anyone know a tool to calculate YPlus correctly? I need to plot a diagram uplus/yplus, therefore I need the exact values. Thanks, Peter |
Dear Peter,
I don't know if it would be of any help, but I am doing the same thing, albeit with results based on a LES simulation of channel flow instead of RANS simulation. I'm using a 32^3 mesh. I'm implementing the following procedure:
Regards, Francois. |
Hi Francois!
Thank you for your answer. I did the same as you suggested in postprocessing with Tecplot, using the velocitygradient given by wallGradU and now it works. For other users with the same problem: Don't use wallShearStress, I don't know why, but this tool gives wrong results. And the results given by yPlus are wrong too, because this tool calculates yStar and not yPlus |
thanks for sharing your experiences
can someone else confirm those sad conclusions ? |
1 Attachment(s)
how does this work?
|
Hmm... I thought so there might be something wrong. What I remember, even calculating yPlus/ on 0/ folder at very beginning of simulation for different related meshes it was giving the same yPlus value, whereas different value was expected.
|
Quote:
I've tried your yPlus app, it compiles well run well but the output is zero on my case: Create time Create mesh for time = 100 Time = 100 Calculating wall distance Writing wall distance to field y Reading field U Reading/calculating face flux field phi Selecting incompressible transport model Newtonian Selecting RAS turbulence model kEpsilon kEpsilonCoeffs { Cmu 0.09; C1 1.44; C2 1.92; sigmaEps 1.3; } Patch 2 named centerpiece y+ : min: 0 max: 0 average: 0 Patch 3 named pipewall y+ : min: 0 max: 0 average: 0 Patch 4 named fins y+ : min: 0 max: 0 average: 0 Writing yPlus to field yPlus End The yPlus file is created in the time directory but the boundaryField values on the patches are "uniform 0;" I'm using OF 1.7.1 on ubuntu 10.04. This issue with the computation of the wallShearStress and the yPlus values makes me crazy. Francois |
1 Attachment(s)
It looks like you dont have wallFunctions as boundary conditions.
here's a new version which does the yplus calculation if its just a wall as well. |
Hi Niklas !
Thanks a lot to help me on this issue. The new yPlus app has the same behavior: perhaps there is something wrong with my case ? Will look deeper and try to find something. Thanks François |
Hi Niklas,
I just had a look into your yPlus program and wondered about how you calculate y+. Can you tell me why you use 'nut' to calculate 'u+', and for the calculation of 'y+' you use 'nu' (from RASModel)? Thanks for your help! /Andi P.S.: With your second version of yPlus, I had the same problem as Francois, but only for very thin first layers (should result in appr. y+ =1) |
Dear Andreas, (or anybody who can help me with this problem)
Could you get a value of yplus different to 0 for thin layers too? (I am using a 1st cell height of 2.75e-05) Thanks, José |
Hi Jose,
have a look at the modified yPlusLES tool that Niklas also proposed. This is the way to calculate y+ when dealing with a low-Re mesh. Note that its only for incompressible flow. (which I was calculating then, so my problem was solved this way) /Andreas |
Hi Jose,
have a look at the modified yPlusLES tool that Niklas also proposed. This is the way to calculate y+ when dealing with a low-Re mesh. Note that its only for incompressible flow. (which I was calculating then, so my problem was solved this way) http://www.cfd-online.com/Forums/ope...s-1-7-1-a.html /Andreas |
Hi Andreas,
Thank you very much for your advice. There is one very important thing I want to comment though. The equation that you can find in that file from Niklas uses a variable "d", i.e. the nearWall distance. I had a look at the values of this d. I expected them to be the same all over the airfoil I am computing (since I am using a mesh with constant 1st cell height of 2.75e-5). To be sure that this is constant after having converted it to OF, I checked that in a post processor and this 1st cell height is constant, so there are no "conversion issues"). :S What I get is that they oscillate between 9e-6 and 1.3e-05. I don´t like this because the value of the computed yPlus then is not perfect. Can you tell me anything about this? Thanks, Regards, José |
Hello, José,
you say your mesh is converted from another format to polyMesh (OpenFOAM). Is it the FLUENT-format, by any chance? If so, try setting writeFormat inside the controlDict to binary and then convert the mesh using fluentMeshToFoam. This solved some issues with the meshes in my cases. Greetings, Felix. |
Hi Felix,
I just tried what you told me and I get exactly the same as before, see the line below: :S. (All of them should be the same...) Patch 0 named wall dmin: 0 dmax: 1.33016e-05 daverage: 5.25961e-06 This dmin is 0, but if I show in the command prompt all the "d" calculated there is no 0 appearing, the minimum one is around 9e-06 (as I said before...). Any idea? Thank you very much for your attention, José P.D.: BTW, the reason why I don´t upload the results I told you in the other thread is because, as you see, I am struggling with some other stuff. |
Quote:
Hey Niklas, actually I am working with your yPlus utility. I am trying to remodel it to calculate the wallShearStress for a compressible simulation. For calculating y+ you are using mut and mu. Why are you using mut in the square root? As I know the definition of y+ is with mu instead of mut. Am I wrong? Code:
yPlus.boundaryField()[patchi] = What does this "RASModel->mu..." mean? Thanks a lot! Camoesas |
Quote:
See util /postProcessing/wall/ You may also want to read: http://www.cfd-online.com/Forums/ope...bend-pipe.html Quote:
|
HI Bernhard,
As I know there is no utility to calculate the wallShearStress in compressible cases... :mad: |
the file that Niklas has put doesn't compile in 2.2.0 version.is there any modification?:)
|
in mutkWallFunctionFvPatchScalarField the equation uses for y-plus is related to y-star not y-plus
Code: Code:
y-star=pow(0.09,0.25)*sqr(k)*nearDist()/mu Code:
y-plus=rho*u_star*y/mu which u*=aqrt(taw_w/rho) in the code of mut : Code: Code:
forAll(mutw, faceI) { label faceCellI = patch().faceCells()[faceI]; scalar yPlus = Cmu25*y[faceI]*sqrt(k[faceCellI])/(muw[faceI]/rhow[faceI]); if (yPlus > yPlusLam_) { mutw[faceI] = muw[faceI]*(yPlus*kappa_/log(E_*yPlus) - 1); } } |
Correction necessary on Niklas's code
I believe I am very late to the party. I am currently using the OpenFOAM 2.4.0 and I have to say that they still have not made any changes to the code, even though I believe it would not be a involve a lot of coding. There was a post on the official openFOAM page, in case you might want to have a look, here it is http://www.openfoam.org/mantisbt/view.php?id=835
Well i was using the code Niklas had made, but I believe it requires a correction. Of course it needed to be edited slightly for the OpenFOAM 2.4 but that is not the correction I am talking about. When it calculates the sqrt(viscosity*gradient of velocity), it has to consider the sum of kinematic viscosity+turbulent viscosity , but he has only used the turbulent viscosity (mut.boundaryField()[patchi]). Practically, the turbulent viscoisty can be ignored and we are only left with the kinematic viscosisty. Very close to the wall i.e y+<3, the turbulent viscosity is negligible since it lies in the viscous laminar sub layer where there are negligible turbulent effects. The line I am talking about would be 3rd in the code attached which is from his Niklas's code. Code:
yPlus.boundaryField()[patchi] = |
All times are GMT -4. The time now is 16:16. |