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

low reynolds re turbulence boundary and yPlus values

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

Like Tree5Likes

Reply
 
LinkBack Thread Tools Display Modes
Old   January 4, 2010, 11:35
Default low reynolds re turbulence boundary and yPlus values
  #1
Member
 
Join Date: Apr 2009
Location: Karlsruhe, Germany
Posts: 96
Rep Power: 8
Thomas Baumann is on a distinguished road
Hallo all,

I'm solving with the buoyantBoussinesqSimpleFoam solver with low-re turbulence models, so I don't use any wall-functions.

So I'm using for my k field e.d.:
wall1
{
type fixedValue;
value uniform 0.00000001;
}

for the epsilon field:
wall1
{
type fixedValue;
value uniform 0.000001;
}
and for the nut field:
inlet
{
type calculated;
}

Is it right to set the nut field to calculated? The simulations works great, the residuals are ca. 10-9.
When trying to plot the yPlus values with yPlusRAS I get following message:
no nutWallFunction patches
Writing yPlus to field yPlus

Plotting them in paraview I see only yPlus = 0.
So do I need a wallfunction in my nut-field? Or did I set the case wrong?

Thanks a lot,
Thomas
Thomas Baumann is offline   Reply With Quote

Old   January 8, 2010, 08:22
Default
  #2
Member
 
Join Date: Apr 2009
Location: Karlsruhe, Germany
Posts: 96
Rep Power: 8
Thomas Baumann is on a distinguished road
Hi all,

shouldn't the yPlus value be calculated without using wallfunctions by:

y+ = (y*u_tau)/nu
with
u_tau=sqrt(Tau_wall/rho)
Tau_wall = mu du/dz at the nearest cell to the wall.
so Tau_wall = mu * u_cell/y_cell


So:
y+=sqrt (y * u_cell/nu)

So I'm not sure, but in the RAsModel.C and in the yPlusRAS.C data should be modified to calculate the yPlus-values for low-reynolds turbulence models.

Regards Thomas

Last edited by Thomas Baumann; January 9, 2010 at 07:45.
Thomas Baumann is offline   Reply With Quote

Old   January 8, 2010, 11:07
Default
  #3
Senior Member
 
BastiL
Join Date: Mar 2009
Posts: 471
Rep Power: 11
bastil is on a distinguished road
I am not sure about this but interested.
First of all I think you still have to use a low re turbulence model in 1.6 for low-re calculations. Afaik it is not possible to use one of the high-reynolds models and only set nut to calculated. I guess you did this?
I think calculation of y+ is independend of high or low re model always done by the formula you have given. So this should be ok.
I don't kow if setting nut to calculated is right for low-re-turbulencemodels, maybe someone can help us about that.
bastil is offline   Reply With Quote

Old   January 11, 2010, 04:17
Default
  #4
Senior Member
 
Florian Krause
Join Date: Mar 2009
Location: Munich
Posts: 103
Rep Power: 8
florian_krause is on a distinguished road
Hi Thomas and bastil,

I had exactly the same issue, for my (periodic) pipe flow with RANS models. For obatining fields of u+ and y+ (especially for plotting u+ over y+ velocity profiles) I created a new utility which does the job for me.

Since its really an ugly piece of code, I would prefer to send it to you via eMail then uploading it here or posting the entire code, so if you are still interested, please tell me and provide me with your eMail adress.

Best,
Florian
florian_krause is offline   Reply With Quote

Old   January 11, 2010, 05:23
Default
  #5
Member
 
Join Date: Apr 2009
Location: Karlsruhe, Germany
Posts: 96
Rep Power: 8
Thomas Baumann is on a distinguished road
Hallo basil and Florian,

firstly I'm using real low-reynolds turbulence models e.d. LaunderSharmaKE and LamBremhorstKE.

For high reynolds-number models you calculate the y+ values in an different way, because you are modelling the velocity-profil in the wall-next-cell. So you have to get the real wall-velocity-gradient, using the velocity-field values give you too low gradients.
The y-plus value is calculated in the RASModel.C with the log-law:
Yp = pow(Cmu, 0.25)
*y_[patchNo]
*sqrt(k()().boundaryField()[patchNo].patchInternalField())
/nu().boundaryField()[patchNo];

So you can only use it for high-reynolds-turbulence-models.
So Florian, it would be very kind of you to send me your code. I will send you my e-mail adress.

Regards,
Thomas

Last edited by Thomas Baumann; January 26, 2010 at 18:50.
Thomas Baumann is offline   Reply With Quote

Old   January 11, 2010, 05:43
Default
  #6
Senior Member
 
Florian Krause
Join Date: Mar 2009
Location: Munich
Posts: 103
Rep Power: 8
florian_krause is on a distinguished road
In fact, my utility is intended for the use of low-Re RANS models. I myself use the LaunderSharmaKE model.

Best,
Florian
florian_krause is offline   Reply With Quote

Old   January 11, 2010, 07:18
Default
  #7
Senior Member
 
BastiL
Join Date: Mar 2009
Posts: 471
Rep Power: 11
bastil is on a distinguished road
Quote:
Originally Posted by Thomas Baumann View Post
The y-plus value is calculated in the RASModel.C with the log-law:
Yp = pow(Cmu, 0.25)
*y_[patchNo]
*sqrt(k()().boundaryField()[patchNo].patchInternalField())
/nu().boundaryField()[patchNo];

So you can only use it for high-reynolds-turbulence-models.
I see. I was not aware of this.
What is the correct way to set-up a low-reynolds case in 1.6? Is it to set type calculated; for nut? Is there an example out there for this?

Regards.
bastil is offline   Reply With Quote

Old   January 25, 2010, 04:15
Lightbulb Summarizing
  #8
Senior Member
 
maddalena's Avatar
 
maddalena
Join Date: Mar 2009
Posts: 436
Rep Power: 12
maddalena is on a distinguished road
Hello,
please can someone check if this is correct?
  1. using a high-Re turbulence model and setting nut as nutWallFunction, the velocity profile near the wall is modeled as a high-Re model requires; i.e. the previous OF version behavior is reproduced. In this way, y+ can be obtained as output.
  2. using a high-Re turbulence model and setting nut as calculated, the velocity profile near the wall is obtained from the velocity field, and the y+ is required by the calculation, thus it is not an output. In this case, the velocity gradient at the wall are too high and the boundary layer is thicker than it should be.
  3. using a low-Re turbulence model requires to set nut as calculated, since this is the only possible way to solve the flow; no y+ value as output.
  4. using a low-Re turbulence model and if a y+ value is necessary as output, the modification made by Florian should be used.

Cheers,
Maddalena

PS: this will answer to a similar question I posted some days ago here as well...
mali likes this.

Last edited by maddalena; January 25, 2010 at 12:32.
maddalena is offline   Reply With Quote

Old   January 26, 2010, 17:08
Default
  #9
Senior Member
 
BastiL
Join Date: Mar 2009
Posts: 471
Rep Power: 11
bastil is on a distinguished road
Maddalena,

al you write makes perfectly sence to me. However I am not sure about the exact of 1.6. Maybe one of the developers can comment on this since there are many similar threads around there at the moment.
bastil is offline   Reply With Quote

Old   January 27, 2010, 04:03
Question
  #10
Senior Member
 
maddalena's Avatar
 
maddalena
Join Date: Mar 2009
Posts: 436
Rep Power: 12
maddalena is on a distinguished road
Hello BastiL,
yes, it would be great if the developers could comment on that!
Some more observations:
  • It seems to me that using the setup 1 is more difficult to keep the simulation stable (i.e. k and epsilon explode) in comparison of setup 2. But since the latter gives higher wall velocity gradient, should not to be the other way round?
  • Can one conclude that setup 2 is a sort of coupling between high-Re and low-Re turbulence model, and this can be used in the proper boundaries if the turbulence field of the case requires a high-Re model in a zone and a low-re model in a different zone?
Cheers,

maddalena
maddalena is offline   Reply With Quote

Old   January 27, 2010, 04:37
Default
  #11
Senior Member
 
Florian Krause
Join Date: Mar 2009
Location: Munich
Posts: 103
Rep Power: 8
florian_krause is on a distinguished road
Hello,

setup 1 - for my high-Re kEpsilon simulations I also use wall function for nut, I have no problems with instability and exploding k and epsilon values.... (might be a flaw somewhere else in your setup)

setup 3 - why should it be neccesary to use calculated for nut? I use zeroGradient and the simulation results are quite good (look at attached uPlus yPlus plot), I just made a test using calculated and its not changing considerably.

best,
Florian
Attached Images
File Type: jpg yPlus_uPlus_rb5300.jpg (49.6 KB, 658 views)
florian_krause is offline   Reply With Quote

Old   January 28, 2010, 18:37
Default
  #12
Senior Member
 
BastiL
Join Date: Mar 2009
Posts: 471
Rep Power: 11
bastil is on a distinguished road
Quote:
Originally Posted by maddalena View Post
Hello,
please can someone check if this is correct?
  1. using a high-Re turbulence model and setting nut as nutWallFunction, the velocity profile near the wall is modeled as a high-Re model requires; i.e. the previous OF version behavior is reproduced. In this way, y+ can be obtained as output.
  2. using a high-Re turbulence model and setting nut as calculated, the velocity profile near the wall is obtained from the velocity field, and the y+ is required by the calculation, thus it is not an output. In this case, the velocity gradient at the wall are too high and the boundary layer is thicker than it should be.
  3. using a low-Re turbulence model requires to set nut as calculated, since this is the only possible way to solve the flow; no y+ value as output.
  4. using a low-Re turbulence model and if a y+ value is necessary as output, the modification made by Florian should be used.
After some review of other threads I think I got it:
1. is right. This is the traditional "Hi-Re" modelling.
2. I do not think you should do this.
3. I think we must not set nut for that case. Set k end epsilon as "zeroGradient". Look at the tutorial compressible/sonicFoam/ras/nacaAirfoil (uses LaunderSharmaKE). This is the traditional "Low-Re" modelling.
4. is right
to add 5. If you have a hybrid/all yplus model OpenFOAM 1.6 offers kind of a hybrid wall function. This seems to work quite fine at least for komega-Turbulence. You need to set nut to "nutSpalartAllmarasWallFunction" even though this name is quite confusing. It is intended as kind of a general purpose blending function... (Compressible kOmegaSST). Sometimes I simply wish the documentation to be better....
chegdan, ubald, solefire and 1 others like this.

Last edited by bastil; January 29, 2010 at 06:17.
bastil is offline   Reply With Quote

Old   February 5, 2010, 04:26
Default
  #13
Senior Member
 
BastiL
Join Date: Mar 2009
Posts: 471
Rep Power: 11
bastil is on a distinguished road
To come to an end I have posted a bug report to get the yPlus-calculation fixed.
bastil is offline   Reply With Quote

Old   April 11, 2010, 06:27
Default
  #14
New Member
 
Join Date: Feb 2010
Posts: 21
Rep Power: 7
jishnusoni is on a distinguished road
Hello All,

I am trying to simulate an impingingjet using the simpleFoam in OF1.6.x. I am trying to follow the threads and tried different things. But I am still getting the same error. I am posting my error and attaching my initial bc. Your support will be greatly appreciated.

Time = 759

DILUPBiCG: Solving for Ux, Initial residual = 0.364807, Final residual = 0.0331038, No Iterations 1
DILUPBiCG: Solving for Uy, Initial residual = 0.401396, Final residual = 0.0185339, No Iterations 1
DILUPBiCG: Solving for Uz, Initial residual = 0.439448, Final residual = 0.0046591, No Iterations 1
GAMG: Solving for p, Initial residual = 0.569614, Final residual = 0.00428777, No Iterations 66
time step continuity errors : sum local = 3.14096e+42, global = 3.09629e+39, cumulative = 6.80133e+40
DILUPBiCG: Solving for epsilon, Initial residual = 1.08298e-09, Final residual = 1.08298e-09, No Iterations 0
DILUPBiCG: Solving for k, Initial residual = 0.000115294, Final residual = 2.84805e-06, No Iterations 2
ExecutionTime = 47327.3 s ClockTime = 48069 s

Time = 760

DILUPBiCG: Solving for Ux, Initial residual = 0.506818, Final residual = 0.00973123, No Iterations 2
DILUPBiCG: Solving for Uy, Initial residual = 0.603294, Final residual = 0.0122224, No Iterations 2
DILUPBiCG: Solving for Uz, Initial residual = 0.280386, Final residual = 0.00518198, No Iterations 2
GAMG: Solving for p, Initial residual = 0.0695246, Final residual = 0.000686704, No Iterations 30
time step continuity errors : sum local = 1.41992e+43, global = 4.71133e+41, cumulative = 5.39147e+41
DILUPBiCG: Solving for epsilon, Initial residual = 3.87187e-11, Final residual = 3.87187e-11, No Iterations 0
DILUPBiCG: Solving for k, Initial residual = 1, Final residual = 0.0894909, No Iterations 1
bounding k, min: -7.27376e+51 max: 5.05817e+89 average: 5.17561e+84
ExecutionTime = 47386.5 s ClockTime = 48159 s

Time = 761

DILUPBiCG: Solving for Ux, Initial residual = 0.417362, Final residual = 0.0145424, No Iterations 1
DILUPBiCG: Solving for Uy, Initial residual = 0.51114, Final residual = 0.0224704, No Iterations 1
DILUPBiCG: Solving for Uz, Initial residual = 0.376437, Final residual = 0.0288099, No Iterations 1
GAMG: Solving for p, Initial residual = 0.629327, Final residual = 0.00528483, No Iterations 8
time step continuity errors : sum local = 1.11456e+78, global = 4.87405e+75, cumulative = 4.87405e+75
DILUPBiCG: Solving for epsilon, Initial residual = 4.23728e-09, Final residual = 4.23728e-09, No Iterations 0
#0 Foam::error:rintStack(Foam::Ostream&) in "/home/jish/OpenFOAM/OpenFOAM-1.6.x/lib/linux64GccDPOpt/libOpenFOAM.so"
#1 Foam::sigFpe::sigFpeHandler(int) in "/home/jish/OpenFOAM/OpenFOAM-1.6.x/lib/linux64GccDPOpt/libOpenFOAM.so"
#2 ?? in "/lib/libc.so.6"
#3 Foam::PBiCG::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/home/jish/OpenFOAM/OpenFOAM-1.6.x/lib/linux64GccDPOpt/libOpenFOAM.so"
#4 Foam::fvMatrix<double>::solve(Foam::dictionary const&) in "/home/jish/OpenFOAM/OpenFOAM-1.6.x/lib/linux64GccDPOpt/libfiniteVolume.so"
#5 Foam::lduMatrix::solverPerformance Foam::solve<double>(Foam::tmp<Foam::fvMatrix<doubl e> > const&) in "/home/jish/OpenFOAM/OpenFOAM-1.6.x/lib/linux64GccDPOpt/libincompressibleRASModels.so"
#6 Foam::incompressible::RASModels::kEpsilon::correct () in "/home/jish/OpenFOAM/OpenFOAM-1.6.x/lib/linux64GccDPOpt/libincompressibleRASModels.so"
#7 main in "/home/jish/OpenFOAM/OpenFOAM-1.6.x/applications/bin/linux64GccDPOpt/simpleFoam"
#8 __libc_start_main in "/lib/libc.so.6"
#9 _start at /build/buildd/eglibc-2.10.1/csu/../sysdeps/x86_64/elf/start.S:116
Floating point exception




thanks

regards
jish
Attached Files
File Type: gz 0.tar.gz (1.4 KB, 78 views)
jishnusoni is offline   Reply With Quote

Old   April 12, 2010, 11:56
Default
  #15
Member
 
Moritz Wied
Join Date: Mar 2010
Location: suttgart, germany
Posts: 35
Rep Power: 7
Mo-ITB is on a distinguished road
Hi everybody,

i am new in openFoam and at the moment also trying to make a low-Reynolds-Model work.
I use the LamBremhorstKE with the pisoFoam solver. I think that k and epsilon explode, and i get this error message:








/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 1.6 |
| \\ / A nd | Web: www.OpenFOAM.org |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : 1.6-f802ff2d6c5a
Exec : pisoFoam
Date : Apr 12 2010
Time : 17:38:30
Host : itb15
PID : 13551
Case : /CFD/Moritz/ahmed_low_re_2
nProcs : 1
SigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
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 turbulence model type RASModel
Selecting RAS turbulence model LamBremhorstKE
--> FOAM Warning :
From function GeometricField<Type, PatchField, GeoMesh>::readIfPresent()
in file /CFD/Daniel/src-openfoam/install/OpenFOAM-1.6/src/OpenFOAM/lnInclude/GeometricField.C at line 107
read option IOobject::MUST_READ suggests that a read constructor for field epsilon would be more appropriate.
^[[5;5~LamBremhorstKECoeffs
{
Cmu 0.09;
C1 1.44;
C2 1.92;
alphaEps 1.3;
}


Starting time loop

Time = 1e-07

Courant Number mean: 0 max: 0
DILUPBiCG: Solving for Ux, Initial residual = 1, Final residual = 1.31903e-16, No Iterations 1
DILUPBiCG: Solving for Uy, Initial residual = 0, Final residual = 0, No Iterations 0
DILUPBiCG: Solving for Uz, Initial residual = 0, Final residual = 0, No Iterations 0
DICPCG: Solving for p, Initial residual = 1, Final residual = 0.0978004, No Iterations 297
time step continuity errors : sum local = 5.58285e-08, global = -1.88251e-10, cumulative = -1.88251e-10
DICPCG: Solving for p, Initial residual = 0.0402446, Final residual = 9.95978e-07, No Iterations 367
time step continuity errors : sum local = 8.99511e-11, global = 1.63882e-14, cumulative = -1.88235e-10
#0 Foam::error:rintStack(Foam::Ostream&) in "/usr/local/OPENFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libOpenFOAM.so"
#1 Foam::sigFpe::sigFpeHandler(int) in "/usr/local/OPENFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libOpenFOAM.so"
#2 ?? in "/lib64/libc.so.6"
#3 Foam::divide(Foam::Field<double>&, Foam::UList<double> const&, Foam::UList<double> const&) in "/usr/local/OPENFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/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 "/usr/local/OPENFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libincompressibleRASModels.so"
#5 Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > Foam:perator/<Foam::fvPatchField, Foam::volMesh>(Foam::tmp<Foam::GeometricField<doub le, Foam::fvPatchField, Foam::volMesh> > const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) in "/usr/local/OPENFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libincompressibleRASModels.so"
#6 Foam::incompressible::RASModels::LamBremhorstKE::c orrect() in "/usr/local/OPENFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libincompressibleRASModels.so"
#7 main in "/usr/local/OPENFOAM/OpenFOAM-1.6/applications/bin/linux64GccDPOpt/pisoFoam"
#8 __libc_start_main in "/lib64/libc.so.6"
#9 __gxx_personality_v0 in "/usr/local/OPENFOAM/OpenFOAM-1.6/applications/bin/linux64GccDPOpt/pisoFoam"
Gleitkomma-Ausnahme







I also ran the model with a coarser mesh, there it started calculating but k and epsilon went to -e12 to e12 and it finally crashed.
by the way, is it allowed that those values become negative?


Does anybody know if the LamBremhorst-Model is working in the actual version?

If yes, could you give me a hint, which initial conditions you use?
As boundary cond. i use

epsilon zeroGradient
k fixed value 0.000000001
nut calculated

all surfaces are defined as patch.

it would be great if somebody could explain experiences maybe already made.

all the best,
Moritz
Mo-ITB is offline   Reply With Quote

Old   June 10, 2010, 08:50
Default
  #16
Senior Member
 
BastiL
Join Date: Mar 2009
Posts: 471
Rep Power: 11
bastil is on a distinguished road
Quote:
Originally Posted by Thomas Baumann View Post
For high reynolds-number models you calculate the y+ values in an different way, because you are modelling the velocity-profil in the wall-next-cell. So you have to get the real wall-velocity-gradient, using the velocity-field values give you too low gradients.
The y-plus value is calculated in the RASModel.C with the log-law:
Yp = pow(Cmu, 0.25)
*y_[patchNo]
*sqrt(k()().boundaryField()[patchNo].patchInternalField())
/nu().boundaryField()[patchNo];
Florian, Thomas,

after reporting a bug the Problem has been fixed in 1.6.x. Since I sometimes still use 1.5-dev I am wondering if the problem with yPlusRAS exists there, too. As far as I see - yes. Right? If yes, Florian could you please send me your fixed version? Thanks.

Regards Bastian

Edit: To make it clear: My older post was generally right (saying that yplus should be calculated identially for all turbulence models). The fact ist that yPlusRAS calculates a value that FLUENT refers to as ySTAR:
Yplus and ystar
yPLUS is defined here:
http://www.cfd-online.com/Wiki/Dimensionless_wall_distance_(y_plus) and is independant of turbulence modelling (however, you have to get the wall shear stress right)

Last edited by bastil; June 10, 2010 at 09:28.
bastil is offline   Reply With Quote

Old   February 10, 2011, 20:44
Default
  #17
Member
 
Robert Ong
Join Date: Aug 2010
Posts: 45
Rep Power: 6
rob3rt 0ng is on a distinguished road
Hi Thomas/Florian/Bastil,

I am having the same problem as Thomas had. If it is possible would you mind make the code to calculate yPlusRAS publicly available?

Thanks and regards,
Robert
rob3rt 0ng is offline   Reply With Quote

Old   February 11, 2011, 02:38
Default
  #18
Senior Member
 
Florian Krause
Join Date: Mar 2009
Location: Munich
Posts: 103
Rep Power: 8
florian_krause is on a distinguished road
Hi guys!

I am sorry but I have no access to any data at the moment (vacation!)

Thomas, didn't I send you my utility to calculate y-plus for low-Re RANS models once. If so, maybe you could send it to Robert.

Since so many prople are asking for it, I will review it and make it public after my vacation in mid of March.

Best,
Florian
florian_krause is offline   Reply With Quote

Old   February 11, 2011, 06:40
Default
  #19
Senior Member
 
romant's Avatar
 
Roman Thiele
Join Date: Aug 2009
Location: Stockholm, Sweden
Posts: 359
Rep Power: 11
romant is on a distinguished road
Hej,

thank you florian, that would just be great.
__________________
~roman
romant is offline   Reply With Quote

Old   February 6, 2012, 06:28
Default
  #20
Member
 
Sebastian Saegeler
Join Date: Nov 2009
Location: Munich
Posts: 70
Rep Power: 7
sebastian is on a distinguished road
Quote:
Originally Posted by bastil View Post
After some review of other threads I think I got it:
1. is right. This is the traditional "Hi-Re" modelling.
2. I do not think you should do this.
3. I think we must not set nut for that case. Set k end epsilon as "zeroGradient". Look at the tutorial compressible/sonicFoam/ras/nacaAirfoil (uses LaunderSharmaKE). This is the traditional "Low-Re" modelling.
4. is right
to add 5. If you have a hybrid/all yplus model OpenFOAM 1.6 offers kind of a hybrid wall function. This seems to work quite fine at least for komega-Turbulence. You need to set nut to "nutSpalartAllmarasWallFunction" even though this name is quite confusing. It is intended as kind of a general purpose blending function... (Compressible kOmegaSST). Sometimes I simply wish the documentation to be better....
For me it does not make any sense to set k and epsilon to zeroGradient at the wall. I recently had a look in the original paper and they use k = epsilon = 0 there, which is conform to my understanding of a low-Re-model so far.
Concerning the turbulent viscosity mut or nut, I have tested a calculated as well as a zeroGradient boundary condition. There was no difference difference in both calculations.

Just for a comparison I have tested k and epsilon with a zeroGradient bc. This results in an unphysical thickening of the boundary layer.

Sebastian
sebastian is offline   Reply With Quote

Reply

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
YPlus Values and SST Model Jenny CFX 1 June 22, 2008 18:47
Turbulence models and boundary layer Stanislav Kraev FLUENT 1 March 14, 2006 06:55
Yplus values for walls in CFX4.4 Forrest CFX 5 March 3, 2004 05:13
X-Y plot of Yplus in Fluent 5.3 Luo FLUENT 24 April 11, 2000 06:07


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