CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Running, Solving & CFD (https://www.cfd-online.com/Forums/openfoam-solving/)
-   -   Near wall treatment in k-omega SST (https://www.cfd-online.com/Forums/openfoam-solving/86855-near-wall-treatment-k-omega-sst.html)

Arnoldinho April 4, 2011 10:57

Near wall treatment in k-omega SST
 
Hi all,

the last days I tried to get a bit deeper in the general understanding of turbulence modeling, and esp. in Menter's k-omega SST model. Still a few questions remain, esp. concerning the implementation of the model in OF-1.7.x, so hopefully someone can help me a bit out.

Question in short form: Is the current k-omega SST implementation (in OF-1.7.x) capable of automatically switching between low-Re and high-Re model?

Question in long form:
If I understood it right, the k-omega SST model is a combination of the k-omega and k-epsilon model plus a shear stress transport model, using blending functions to choose the appropriate model depending on the region (boundary layer or free stream). So the basic implementation from [1] is a high-Re model. Low-Re models don't use any wall functions as they are grid-resolved. Some paper say that the viscous sublayer is between 0 < y+ < 5. Others say, that a good solution can only be achieved when y+ < 1, sometimes even < 0.1. So what is 'right' here, how big is the error if I'm in a range of y+ 0.5-8?

I have a (interFoam) model using different grid resolutions (esp. first layer cell heights) in different regions at the walls. Additionally, different flow situations, i.e. different water velocities and also water waves are simulated, which lead to local- and time-varying different y+ and u+ values. Therefore I need some kind of near wall treatment, automatically switching between low-Re and high-Re formulation, depending on the location and flow-situation.
So my question is: Is the current k-omega SST implementation (in OF-1.7.x) capable of automatically switching between low-Re and high-Re model? If this is hopefully true, do I then select omegaWallFunction?

Looking at the source code of omegaWallFunction and comparing it to [2] I found that the blending function for y+ is a bit different. E.g. in the implementation,
Code:

scalar omegaLog = sqrt(k[faceCellI])/(Cmu25*kappa_*y[faceI])
and
Code:

Cmu25 = pow(Cmu_, 0.25)
is used, whereas the paper says
Code:

omegaLog = 1/0.3*kappa *ut/y
So the difference lies in the Cmu25 and using k instead of the velocity profile ut near the wall (computed out of uVis and uLog).

In the wall functions implementation, a wall roughness can be specified. Does this still work if switched to a low-Re model?

I already ran some test cases using omegaWallFuntions, nutRoughWallFunction, kqRWallFunction and a y+ between 0.5-8. Nevertheless, the results seemed to be quite grid-depending...


Best, Arne

[1] Menter: Two-Equation Eddy-Viscosity Turbulence Models for Engineering Applications, 1994
[2] Menter: The SST Turbulence Model with Improved Wall Treatment for Heat Transfer Predictions in Gas Turbines, 2003

Sylvain May 2, 2011 10:07

Hello Arne,

Nice thread you started here. I'm also interested in wall functions those days, and I took a closer loop to what it is actually implemented.

Regarding the omegawallfunction first. What disturbs me is that the omega which is actually computed at the wall cell is a combination of omega_vis and omega_log.

Omega=sqrt(omega_vis^2+omega_log^2).

If you make a parallel with the epsilonwallfunction, with epsilon=c_mu*k*omega, you find that what is prescribed for epsilon is equivalent to what is prescribed for omega_log. I'm not yet very familiar with the komega-SST model, so maybe this combination of the viscous value and the log value is linked to equation of omega, I don’t know. What I would have except is that for y+<y_lam the code uses omega_vis, and for y+>y_lam, the code uses omega_log. It's what you call switching from low to high Reynolds. I'm simulating a train with a yaw angle. For low yaw angle the forces calculated match well the values found in wind tunnel, for higher yaw angles the forces are far too low. I suspect the wall functions. But again I don't know.

Regarding the roughness, as far as I have understood, it is implemented via nut. You calculate a new value of nut=nu(y+*kappa/(ln(E_star+)-1). E_star is the only parameter modified by the roughness. Then I suppose that nut is used to calculate the value of the velocity in the wall cell using the wall shear stress tau_w/rho=u_star^2=(nu_t+nu)*du/dy
which yields to
u(y)=u_star*log(y+*E_star)
And I think that is all for the roughness, means there is no direct connection I'm aware of between the values of omega (or epsilon) in the wall cell and the surface roughness.
I'm also trying to compute atmospheric boundary layers, I couldn't' succeed in maintain the theorical profile in OpenFOAM adjusting the correct parameters of Ks and Cs, Fluent does. I think I'm missed something, but I don't know what.

Sylvain May 5, 2011 06:25

Hi Arne,

I found that post this morning, might be helpfull.


http://www.openfoam.com/mantisbt/view.php?id=179

I quote Henry

Quote:


Note that the k-omega SST model we provide is in high-Re form and does not include the wall-damping terms often included in the k-omega model for near-wall and low-Re flow. However, you can still use the k-omega SST model for low-Re and near wall flow for a range of resolutions if you use a continuous wall-function (which in OpenFOAM-1.7.x is named nutSpalartAllmarasWallFunction for historical reasons) and this should be used as the wall BC in nut. The BC of k for the continuous wall-function should be kqRWallFunction.

If these changes do not help it may be worth investigating the viscosity averaging in omegaWallFunctionFvPatchScalarField:

scalar omegaVis = 6.0*nuw[faceI]/(beta1_*sqr(y[faceI]));
scalar omegaLog = sqrt(k[faceCellI])/(Cmu25*kappa_*y[faceI]);
omega[faceCellI] = sqrt(sqr(omegaVis) + sqr(omegaLog));

we have found cases for which this causes a sudden change in the viscosity near the wall if the mesh is sufficiently fine and that just using the logarithmic part give more continuous behavior:

omega[faceCellI] = omegaLog;


Arnoldinho May 5, 2011 11:45

Hi Sylvain,

thanks for giving me a feedback to my topic and sorry for not having answered yet. I'm quite busy with other things in OF right now, regarding implementing new things (but still at the very beginning...)

I already got the information from somebody else and other threads that using komegaSST works for high- and low-Re grids (mixture) when using it together with nutSpalartAllmarasWallFunction and omegaWallFunction. If Henry says so as well, then it well be right...

Concerning omega, this is what I got from another member (thanks for that!):
"The menters version uses y+ for wall distance, but OF uses y* (compare with http://my.fit.edu/itresources/manual...ug/node512.htm). This seems to be standard procedure in OpenFOAM, for example if you use yPlusRAS you don't get y+ but y*".

I will have a detailed look on this again and check it with some simple test when there is some more time...

Greetings,
Arne

In the meanwhile, please let me know when you got new insights ;-)

rob3rt 0ng May 9, 2011 01:48

Hello Arne and Sylvain,

Not sure if this helps but there's a handy utility created by Florian, you may find it here http://www.cfd-online.com/Forums/ope...tml#post306730

On the same note, if I have a fine mesh at y* (or y+) less than 1 everywhere, I can opt not to use wall functions (according to Dr. Weller at post#54 in http://www.cfd-online.com/Forums/ope...megasst-3.html). Am I right?

Thanks for your time and attention.

Regards,
Robert

flowris July 12, 2011 08:34

Wall functions should only be used for 30 < y+ < 100-300, which means that the first cell is in the log layer and not in the sublayer. If you want to use kOmega_SST without a wall function, y+ should be around 1.

Arnoldinho July 12, 2011 08:46

Quote:

Wall functions should only be used for 30 < y+ < 100-300
Yes, you are right. Although regarding different sources, you also get different limiting values for the viscous sub-layer (0 < y+ < 1, 5) and the log-layer (30, 70 < y+ < 100, 200, 300). I also remember a thread where OF has been tested as low re model without wall functions: an y+ value < 0.2 lead to 'wrong' results as well. For the buffer layer (e.g. 5 < y+ < 30), a blending is needed.

Arne

romant July 13, 2011 03:59

k-Omega SST low Re considerations
 
hej,

as I have noticed now, the change in the "wall function" as suggested by henry is not to reliable. I found however, that when using k-omega SST in a low Re mode, one should have a very smooth transition of the cell size around the y+ < 200. Then the results become quite reliable.

Arnoldinho July 13, 2011 07:53

Quote:

Originally Posted by romant (Post 315930)
one should have a very smooth transition of the cell size around the y+ < 200

So which transition value do you suggest? Normally the cell growth ratio should be something up to 1.2.

romant July 13, 2011 08:21

not checked
 
hej,

i haven't checked at which time the model breaks down, but in the end I used 1.1 to 1.15 as my cell growth ratio.

sivakumar July 23, 2013 11:22

Low Re BC for K, Omega and nut
 
Dear all,
I am trying to simulate fan with low re number turb model,
I have gone through so many post regarding wall treatment, still it is not clear for me.

My yPlus vale is 3 to 6,

I tried for k -->

top0
{
type fixedValue;
value uniform 0;
}

top1
{
type fixedValue;
value uniform 0;
}

For Omega;

top0
{
type omegaWallFunction;
value uniform 0;
}

top1
{
type omegaWallFunction;
value uniform 0;
}

and for nut;

top0
{
type calculated;
value uniform 0;
}

top1
{
type calculated;
value uniform 0;
}

my questions are;

is it right setting? for low re number turb model.

when I try this settings, it is reporting the following error

Create time

Create mesh for time = 0

Reading field p

Reading field U

Reading/calculating face flux field phi

Selecting incompressible transport model Newtonian
Selecting RAS turbulence model kOmegaSST
bounding k, min: 0 max: 0 average: 0
bounding omega, min: 0 max: 0 average: 0

#0 Foam::error::printStack(Foam::Ostream&) in "/home/cerecam/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#1 Foam::sigFpe::sigHandler(int) in "/home/cerecam/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#2 in "/lib/x86_64-linux-gnu/libc.so.6"
#3 Foam::divide(Foam::Field<double>&, Foam::UList<double> const&, Foam::UList<double> const&) in "/home/cerecam/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#4 void Foam::divide<Foam::fvPatchField, Foam::volMesh>(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) in "/home/cerecam/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/lib/libincompressibleRASModels.so"
#5 at kOmegaSST.C:0
#6 Foam::incompressible::RASModels::kOmegaSST::F2() const in "/home/cerecam/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/lib/libincompressibleRASModels.so"
#7 Foam::incompressible::RASModels::kOmegaSST::kOmega SST(Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::transportModel&, Foam::word const&, Foam::word const&) in "/home/cerecam/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/lib/libincompressibleRASModels.so"
#8 Foam::incompressible::RASModel::adddictionaryConst ructorToTable<Foam::incompressible::RASModels::kOm egaSST>::New(Foam::GeometricField<Foam::Vector<dou ble>, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::transportModel&, Foam::word const&) in "/home/cerecam/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/lib/libincompressibleRASModels.so"
#9 Foam::incompressible::RASModel::New(Foam::Geometri cField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::transportModel&, Foam::word const&) in "/home/cerecam/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/lib/libincompressibleRASModels.so"
#10
in "/home/cerecam/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/bin/MRFSimpleFoam"
#11 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#12
in "/home/cerecam/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/bin/MRFSimpleFoam"
Floating point exception (core dumped)




please give me some idea what is wrong,

Tanks for your time and help,
Sivakumar

gillimaniac July 26, 2013 04:49

You've got a floating point exception. Mostly it's caused by some division by 0.
Try setting your k-value to 1e-11 instead to zero.

behest November 7, 2014 08:33

OMEGA on the wall surface in SST model
 
Dear all,
I am working with Fluent and I have simulated a flat plate and the mesh is enogh fine (Y+<=1). The turbulence model that I use is k-w SST and I uncheck Low-Reynolds-Number in the turbulence panel. I export the omega value on the plate surface and now I am trying to find what equation fluent uses for it. It would be appriciated if you help me about the equation.

I used this equation but the answer was not the same with Fluent.
OMG=sqrt(OMG_vis^2+OMG_log^2)
OMG_vis=6*ro*(U_tau^2)/(0.075*Mu*Yplus^2)
OMG_log=ro*(U_tau^2)/(0.3*k*Mu*Yplus)

ro=dinsity
U_tau=friction velosity
Mu=viscosity
k=0.41

RodriguezFatz November 10, 2014 03:59

Ali, this may be just a matter of cell and face value. Do you actually know, whether Fluent shows you the value of the wall or the value of the near wall cell?
Anyway, I think Fluent boundary condition of omega is not a boundary condition but setting the frist cell value to a fixed value. So there is actually no wall value of omega and if you plot the wall values this is some extrapolation of the (fixed) first cell value. I may be wrong with this.

behest November 12, 2014 07:40

Thank you very much for replying.
To be honest, Fluent gives us value of the wall. My case study is a 2D flat plate and all values are the face one. To get the OMGa value of the wall, I did it in Display/plot/xy plot and then I selected Specific Dissipation Rate (Omega) and chose plate in the Surfaces. The Fluent gives us the Omega value of the plate surface. I checked the value of the cell adjecent (next cell after the wall boundary) and that value was not the same that I obtained with mentioned equation.
In Fluent, we need a boundary condition for Omega near the wall to solve turbulence equation. Actually, Omega value of the wall surface is obtained by a formule (my problem is to find this formule in SST).
Moreover, I do not think that the Omega value of the wall is extrapolation of the first cell value because Omega value has an increasing behaviour when closing to the wall and finally, it is logically accepted that dissipation should be sharply increased on the wall surface.


Quote:

Originally Posted by RodriguezFatz (Post 518282)
Ali, this may be just a matter of cell and face value. Do you actually know, whether Fluent shows you the value of the wall or the value of the near wall cell?
Anyway, I think Fluent boundary condition of omega is not a boundary condition but setting the frist cell value to a fixed value. So there is actually no wall value of omega and if you plot the wall values this is some extrapolation of the (fixed) first cell value. I may be wrong with this.


RodriguezFatz November 12, 2014 07:58

Let's assume you y+<1, then you can just calculate the OMG_vis value you mentioned above. OMG_log << OMG_vis.
What value do you get for OMG_vis and what does Fluent show you in the plot?

behest November 12, 2014 08:17

3 Attachment(s)
When y+<1, then OMG_vis should give us the omega value of the wall. The problem is that the value of calculating the OMG_vis is not match to the Fluent one. I attach the Omega value of the wall, obtained by Fluent and equation OMG_vis. You can find that two results are not the same. It seems that Fluent uses different equation or another damping function or ....

Quote:

Originally Posted by RodriguezFatz (Post 518729)
Let's assume you y+<1, then you can just calculate the OMG_vis value you mentioned above. OMG_log << OMG_vis.
What value do you get for OMG_vis and what does Fluent show you in the plot?


RodriguezFatz November 12, 2014 08:19

What is "x"?

behest November 12, 2014 08:23

"x" is a direction along the plate, x=0 is the leading edge of the plate and x=1.7 is the end of it.

Quote:

Originally Posted by RodriguezFatz (Post 518734)
What is "x"?


RodriguezFatz November 12, 2014 08:24

So your y+ changes along the plate?

behest November 12, 2014 08:38

2 Attachment(s)
Yes, it changes. I put all information in the excel file, enclosed here


Quote:

Originally Posted by RodriguezFatz (Post 518736)
So your y+ changes along the plate?


RodriguezFatz November 12, 2014 09:00

This looks strange. Is "wall_dist" the first cell distance in "m"? Is this exported from Fluent or from your meshing tool?
I am asking because, did you write down the OMG_vis formula without wall units? It's
OMG_vis = 6 * nu / (0.072 y^2)
So for constant y (in m) you should have a constant omega wall value...

behest November 12, 2014 09:20

Yes, "wall_dist" is the adjcent cell to the wall in "m" and it is exported from Fluent.
The OMG_vis formula is based on y+ not y and y+ is a nondimensional parameter. Moreover, Omega depents on wall shear, too; so that it has not constant value along the plate.
The main problem is that what formula Fluent uses for the Omega value of the wall.

Quote:

Originally Posted by RodriguezFatz (Post 518743)
This looks strange. Is "wall_dist" the first cell distance in "m"? Is this exported from Fluent or from your meshing tool?
I am asking because, did you write down the OMG_vis formula without wall units? It's
OMG_vis = 6 * nu / (0.072 y^2)
So for constant y (in m) you should have a constant omega wall value...


RodriguezFatz November 12, 2014 09:26

Quote:

Originally Posted by behest (Post 518750)
The OMG_vis formula is based on y+ not y and y+ is a nondimensional parameter. Moreover, Omega depents on wall shear, too; so that it has not constant value along the plate.

Write down the OMG_vis formula in dimensional units and not in non-dimensional units like you use it. You will see, that OMG_vis does not depend on any flow values at all. It just depends on the wall distance of your first cell (in "m") and on dynamic viscosity.
You will get
OMG_vis = 6 * nu / (0.072 y^2)
No y+, no wall shear.

behest November 12, 2014 09:37

Yes, you are right. Then, how is Fluent calculate the omega of the wall?
Actually, the same formula is written in Fluent theory guide,

Quote:

Originally Posted by RodriguezFatz (Post 518753)
Write down the OMG_vis formula in dimensional units and not in non-dimensional units like you use it. You will see, that OMG_vis does not depend on any flow values at all. It just depends on the wall distance of your first cell (in "m") and on dynamic viscosity.
You will get
OMG_vis = 6 * nu / (0.072 y^2)
No y+, no wall shear.


RodriguezFatz November 12, 2014 09:43

Are you 100% sure about the grid? Is the wall distance really constant?

behest November 12, 2014 09:58

2 Attachment(s)
Yes, I am sure, because my case study is a flat plate and I use hexahedral elements (structural mesh) and cells have the same wall distance.
I enclosed two figures of the mesh

Quote:

Originally Posted by RodriguezFatz (Post 518760)
Are you 100% sure about the grid? Is the wall distance really constant?


RodriguezFatz November 13, 2014 07:55

I remember when I checked these values for one of my cases everything was alright. There must be some mistake in the data. Can you upload the whole fluent case?

behest November 13, 2014 08:14

Yes, sure, you can find the cas and data file in the Dropbox, linked here:

https://www.dropbox.com/sh/rg87mkr95...MyjuKLP-a?dl=0

Quote:

Originally Posted by RodriguezFatz (Post 518973)
I remember when I checked these values for one of my cases everything was alright. There must be some mistake in the data. Can you upload the whole fluent case?


RodriguezFatz November 13, 2014 08:59

Ali, you should try to understand my post #14 in this thread (very first post of me). I think you can not plot omega on the surface, because Fluent doesn't let you. You are currently plotting interpolated values. Try this: plot "k" along the plate. You will see, that it isn't zero everywhere. This doesn't make sense, because k-boundary condition is zero. This can only be explained by interpolation errors during post-processing.

I also found in the userguide:

In ANSYS FLUENT you can choose to display the computed cell-center values or values that have been interpolated to the nodes. By default, the Node Values option is turned on, and the interpolated values are displayed. For line contours or profiles, node values are always used. If you are displaying filled contours or profiles and you prefer to display the cell values, turn the Node Values option off. Filled contours/profiles of node values will show a smooth gradation of color, while filled contours/profiles of cell values may show sharp changes in color from one cell to the next.

For face-only functions (e.g., Wall Shear Stress), the cell values that are displayed for boundary zone surfaces will actually be the face values. This is only true in the case of boundary zone surfaces created for postprocessing, where the actual cell values are used for the part of the surface which lies in the interior. These face values are more
accurate, as face-only functions are computed on the faces and not on the cells.

Yuby April 21, 2015 03:38

Hi!

I don't understand this:

Quote:

Wall functions should only be used for 30 < y+ < 100-300, which means that the first cell is in the log layer and not in the sublayer. If you want to use kOmega_SST without a wall function, y+ should be around 1.
I mean, if you run the motorbike tutorial (simpleFoam), and then you run the yPlusRAS utility (you can do it because it uses wallfunctions for every variable) you get:

Code:

/*---------------------------------------------------------------------------*\
| =========                |                                                |
| \\      /  F ield        | OpenFOAM: The Open Source CFD Toolbox          |
|  \\    /  O peration    | Version:  2.3.0                                |
|  \\  /    A nd          | Web:      www.OpenFOAM.org                      |
|    \\/    M anipulation  |                                                |
\*---------------------------------------------------------------------------*/
Build  : 2.3.0-f5222ca19ce6
Exec  : yPlusRAS -latestTime
Date  : Apr 21 2015
Time  : 09:20:56
Host  : "usuario-SATELLITE-P50-A-14G"
PID    : 6279
Case  : /home/usuario/OpenFOAM/usuario-2.3.0/run/tutorials/incompressible/simpleFoam/motorBike
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Disallowing user-supplied system call operations

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

Create mesh for time = 500

Time = 500
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 kOmegaSST
kOmegaSSTCoeffs
{
    alphaK1        0.85034;
    alphaK2        1;
    alphaOmega1    0.5;
    alphaOmega2    0.85616;
    gamma1          0.5532;
    gamma2          0.4403;
    beta1          0.075;
    beta2          0.0828;
    betaStar        0.09;
    a1              0.31;
    b1              1;
    c1              10;
    F3              false;
}

Patch 3 named lowerWall y+ : min: 4.88086 max: 3607.62 average: 206.955

Patch 5 named motorBike_frt-fairing:001%1 y+ : min: 1.19946 max: 832.435 average: 124.919

Patch 6 named motorBike_windshield:002%2 y+ : min: 10.6911 max: 166.337 average: 75.398

Patch 7 named motorBike_rr-wh-rim:005%5 y+ : min: 4.1793 max: 512.061 average: 163.725

Patch 8 named motorBike_rr-wh-rim:010%10 y+ : min: 2.58583 max: 509.935 average: 196.126

Patch 9 named motorBike_fr-wh-rim:011%11 y+ : min: 5.40472 max: 597.576 average: 187.444

Patch 10 named motorBike_fr-wh-brake-disk:012%12 y+ : min: 107.562 max: 338.746 average: 216.073

Patch 11 named motorBike_frame:016-shadow%13 y+ : min: 35.4755 max: 730.857 average: 258.606

Patch 12 named motorBike_rear-susp:014%14 y+ : min: 0.253153 max: 414.543 average: 77.3381

Patch 13 named motorBike_rear-susp:014-shadow%15 y+ : min: 0.300651 max: 344.091 average: 72.7773

Patch 14 named motorBike_frame:016%16 y+ : min: 35.5895 max: 782.373 average: 252.4

Patch 15 named motorBike_rr-wh-rim:005-shadow%17 y+ : min: 6.08735 max: 483.529 average: 174.497

Patch 16 named motorBike_rr-wh-chain-hub:022%22 y+ : min: 12.6166 max: 518.445 average: 200.842

Patch 17 named motorBike_rearseat%24 y+ : min: 4.59619 max: 681.697 average: 145.558

Patch 18 named motorBike_frt-fairing%25 y+ : min: 4.95551 max: 305.27 average: 75.9044

Patch 19 named motorBike_windshield%26 y+ : min: 7.26132 max: 450.868 average: 94.9765

Patch 20 named motorBike_headlights%27 y+ : min: 11.7862 max: 197.488 average: 65.7203

Patch 21 named motorBike_driversseat%28 y+ : min: 1.01499 max: 753.983 average: 127.026

Patch 22 named motorBike_rear-body%29 y+ : min: 0.596934 max: 993.403 average: 116.239

Patch 23 named motorBike_fuel-tank%30 y+ : min: 1.739 max: 566.51 average: 84.194

Patch 24 named motorBike_exhaust%31 y+ : min: 3.85593 max: 935.894 average: 203.403

Patch 25 named motorBike_rr-wh-rim%32 y+ : min: 2.09283 max: 497.315 average: 73.341

Patch 26 named motorBike_fr-mud-guard%33 y+ : min: 6.73648 max: 640.736 average: 131.08

Patch 27 named motorBike_fr-wh-rim%34 y+ : min: 4.9542 max: 746.132 average: 166.426

Patch 28 named motorBike_fr-wh-brake-disk%35 y+ : min: 4.49047 max: 568.912 average: 184.304

Patch 29 named motorBike_fr-brake-caliper%36 y+ : min: 40.765 max: 675.114 average: 327.912

Patch 30 named motorBike_fr-wh-tyre%37 y+ : min: 3.78615 max: 717.634 average: 116.777

Patch 31 named motorBike_hbars%38 y+ : min: 29.7385 max: 803.726 average: 350.639

Patch 32 named motorBike_fr-forks%39 y+ : min: 4.94379 max: 767.731 average: 163.808

Patch 33 named motorBike_chain%40 y+ : min: 1.35618 max: 801.723 average: 291.154

Patch 34 named motorBike_rr-wh-tyre%41 y+ : min: 2.02377 max: 621.427 average: 94.479

Patch 35 named motorBike_square-dial%42 y+ : min: 12.783 max: 20.3879 average: 18.4621

Patch 36 named motorBike_round-dial%43 y+ : min: 133.509 max: 461.298 average: 269.324

Patch 37 named motorBike_dial-holder%44 y+ : min: 4.75498 max: 447.694 average: 145.443

Patch 38 named motorBike_rear-susp%45 y+ : min: 0.533745 max: 690.342 average: 158.851

Patch 39 named motorBike_rear-brake-lights%46 y+ : min: 66.039 max: 679.236 average: 293.376

Patch 40 named motorBike_rear-light-bracket%47 y+ : min: 4.5641 max: 589.924 average: 154.913

Patch 41 named motorBike_frame%48 y+ : min: 0.825434 max: 937.666 average: 135.254

Patch 42 named motorBike_rear-mud-guard%49 y+ : min: 3.30992 max: 553.535 average: 110.729

Patch 43 named motorBike_rear-susp-spring-damp%50 y+ : min: 13.8833 max: 329.802 average: 90.9432

Patch 44 named motorBike_fairing-inner-plate%51 y+ : min: 1.26159 max: 331.501 average: 77.0047

Patch 45 named motorBike_clutch-housing%52 y+ : min: 0.284496 max: 528.746 average: 89.331

Patch 46 named motorBike_radiator%53 y+ : min: 105.444 max: 1107.61 average: 652.528

Patch 47 named motorBike_water-pipe%54 y+ : min: 109.441 max: 719.566 average: 342.032

Patch 48 named motorBike_water-pump%55 y+ : min: 58.1246 max: 400.726 average: 216.617

Patch 49 named motorBike_engine%56 y+ : min: 0.095713 max: 864.928 average: 90.6738

Patch 50 named motorBike_rear-shock-link%57 y+ : min: 16.4089 max: 252.338 average: 134.633

Patch 51 named motorBike_rear-brake-fluid-pot-bracket%58 y+ : min: 2.38783 max: 795.973 average: 126.167

Patch 52 named motorBike_rear-brake-fluid-pot%59 y+ : min: 70.8986 max: 461.902 average: 232.822

Patch 53 named motorBike_footpeg%60 y+ : min: 80.5822 max: 573.279 average: 304.165

Patch 54 named motorBike_rr-wh-chain-hub%61 y+ : min: 4.50327 max: 354.193 average: 162.007

Patch 55 named motorBike_rear-brake-caliper%62 y+ : min: 13.9359 max: 808.401 average: 285.541

Patch 56 named motorBike_rider-helmet%65 y+ : min: 5.23685 max: 622.124 average: 109.845

Patch 57 named motorBike_rider-visor%66 y+ : min: 39.7826 max: 160.656 average: 121.427

Patch 58 named motorBike_rider-boots%67 y+ : min: 1.5236 max: 732.281 average: 128.206

Patch 59 named motorBike_rider-gloves%68 y+ : min: 3.46863 max: 891.645 average: 276.421

Patch 60 named motorBike_rider-body%69 y+ : min: 1.42095 max: 782.554 average: 99.6377

Patch 61 named motorBike_frame:0%70 y+ : min: 7.67993 max: 623.53 average: 266.79

Patch 62 named motorBike_frt-fairing:001-shadow%74 y+ : min: 1.71476 max: 885.956 average: 126.73

Patch 63 named motorBike_windshield-shadow%75 y+ : min: 9.79227 max: 503.034 average: 104.015

Patch 64 named motorBike_fr-mud-guard-shadow%81 y+ : min: 6.33128 max: 511.078 average: 129.128

Patch 65 named motorBike_fr-wh-brake-disk-shadow%83 y+ : min: 6.77294 max: 525.776 average: 173.026

Patch 66 named motorBike_rear-mud-guard-shadow%84 y+ : min: 2.3761 max: 535.362 average: 102.709

Patch 67 named motorBike_rear-susp-spring-damp-shadow%85 y+ : min: 12.0661 max: 370.146 average: 116.931

Patch 68 named motorBike_radiator-shadow%86 y+ : min: 123.77 max: 941.179 average: 598.408

Patch 69 named motorBike_rear-shock-link-shadow%87 y+ : min: 19.2968 max: 294.77 average: 145.051

Patch 70 named motorBike_rear-brake-fluid-pot-bracket-shadow%88 y+ : min: 2.29904 max: 427.28 average: 131.788

Patch 71 named motorBike_rr-wh-chain-hub-shadow%89 y+ : min: 6.38424 max: 360.01 average: 170.899

Writing yPlus to field yPlus

End

As you can see, there are many different values of y+... I am a little bit confused :confused:

roadRunner April 21, 2015 04:21

yPlus value is calculated for each cell next to the wall, each cell has it's y+ value, that's why you have min/max and avg values.

Yuby April 21, 2015 04:26

I know..

But they are not in the supposed interval, that's because I posted that

romant April 21, 2015 05:00

Quote:

Originally Posted by Yuby (Post 542916)
I know..

But they are not in the supposed interval, that's because I posted that

You have to consider that the tutorials are not for academic analysis. They are there to show the capabilities of OpenFOAM. However, when you design your cases, you will need to take care of numerics yourself. You will also find LES cases running with low res schemes in the tutorials, which does not mean this should be done like that in real life. Keep in mind the tutorial cases should run fast on many difference computers.

Yuby April 21, 2015 05:08

Infinite thanks, Roman! :)

If I use the same wall functions of the motorbike tutorial (nutKwallfunction, kqRwallfunction and omegawallfunction) and standard k omega model what values of y+ I should have? And for standard k epsilon with epsilonwallfunction?

roadRunner April 21, 2015 09:00

Quote:

Originally Posted by Yuby (Post 542916)
I know..

But they are not in the supposed interval, that's because I posted that

Oh, sorry, I misunderstood your question.

romant April 22, 2015 03:19

Quote:

Originally Posted by Yuby (Post 542930)
Infinite thanks, Roman! :)

If I use the same wall functions of the motorbike tutorial (nutKwallfunction, kqRwallfunction and omegawallfunction) and standard k omega model what values of y+ I should have? And for standard k epsilon with epsilonwallfunction?

For all these wall functions, one should consider to have the y+ between 35 and 150, at about 35 the log layer starts. If you have more than 150, let's say up to 300, this could sometimes also work, but I wouldn't necessarily rely on it. The best way of finding out is to run a simple case (channel flow, pipe flow in 3D) against experimental values and see what gives good results and what doesn't

More information on wall functions and near wall behavior can be found in

1. Wilcox, D. C. (2006). Turbulence modeling for CFD (3rd ed.). La Canada Calif.: DCW Industries.

2. Pope, S. B. (2000). Turbulent flows. Cambridge [u.a.]: Cambridge Univ. Press.

3. Schlichting, H., & Gersten, K. (2000). Boundary Layer Theory (8th Revise). Darmstadt: Springer Berlin Heidelberg.

4. Bredberg, J. (2000). On the Wall Boundary Condition for Turbulence Models. Göteborg, Sweden. (gives explanation of wall functions in OpenFOAM)

5. Schiestel, R. (2008). Modeling and Simulation of Turbulent Flows. London, UK: ISTE. http://doi.org/10.1002/9780470610848

KateEisenhower June 9, 2015 09:35

Quote:

Originally Posted by Arnoldinho (Post 315824)
Yes, you are right. Although regarding different sources, you also get different limiting values for the viscous sub-layer (0 < y+ < 1, 5) and the log-layer (30, 70 < y+ < 100, 200, 300). I also remember a thread where OF has been tested as low re model without wall functions: an y+ value < 0.2 lead to 'wrong' results as well. For the buffer layer (e.g. 5 < y+ < 30), a blending is needed.

Arne

Hello Arne,

It's the first time I hear about y+ values below 0.2 leading to wrong results. Do you have more information about this?

Best regards,

Kate

mahbood March 8, 2017 13:48

Helllo,
So by having all in hand,
now in modelling high-speed flow with K-w sst, if your first grid is in Y+=150 (log layer). and you are interested in studying the vorticity of separated flow downstream of a backstep (Backward Facing Step), does this putting first grid point on log layer make any problem? :confused:
what is the difference between Fluent and OpenFoam in this?
Can anyone introduce me some papers in this regard?

Thanks


All times are GMT -4. The time now is 22:33.