|
[Sponsors] |
November 12, 2010, 06:36 |
LowRe-SST in OpenFOAM 1.7?
|
#1 |
New Member
Peter
Join Date: Aug 2010
Posts: 16
Rep Power: 16 |
Hi@all!
I have a question concerning the SST-model implemented in OpenFoam 1.7 Can I use this model for Low-Re flows? I know that there were two different models implemented in OpenFoam 1.5, one lowre version and one normal version, see here: http://openfoam-extend.svn.sourcefor...ncompressible/ In 1.7, there is only one version of the SST model, and I was wondering why, therefore I had a closer look on the sourcecode: I compared both versions of the 1.5-SST-models, the only difference are the implemented wall functions in the highRe SST-model. Then, I compared both OF versions, 1.5 and 1.7. The "0" files in OF 1.5 were different. Here, a "zeroGradient" entry was required for k, omega and nut. The wall functions were directly implemented in the turbulence model and not defined in the "0" folder, is that correct? In 1.7, you have to define all wall functions in the "0" folder, they are no longer defined in the turbulence model code. If it is so, I only would have to change my wall functions in the "0" folder in 1.7 to zeroGradient to get a lowRe version of the SST, true? Maybe a developer of OF could answer my question, if the SST-model in 1.7 could be used for flows with lowRe meshes (y+1 distance to the wall). Thanks, Peter |
|
November 12, 2010, 11:13 |
|
#2 |
Senior Member
Felix L.
Join Date: Feb 2010
Location: Hamburg
Posts: 165
Rep Power: 18 |
Hello, Peter,
many turbulence models based upon the turbulence quantities k and omega can be integrated down to the wall without further addition of viscous damping functions like it is neccessary for e.g. the k-epsilon turbulence models. See Wilcox' book for more information about that - for engineering interests the near-wall performance of the k-omega (and k-omega SST) models is accurate enough to obtain for example reasonable skin friction or drag coefficients. Using kOmegaSST for lowRe meshes in OF 1.7 works, when imposing the following BCs at the walls: U: fixedValue (0 0 0) k: fixedValue 1e-11 (or a similar, nonzero but low value!) omega: omegaWallFunction nut: calculated The omegaWallFunction automatically sets omega to the correct near wall value - it works for both lowRe and highRe meshes and is a very convenient boundary condition, since omega_wall depends on the wall grid spacing and omegaWallFunction does the calculation for you. As I stated in my thread the skin friction coefficients predicted by the kOmegaSST turbulence model implementation in OF 1.7 on lowRe meshes are slightly too high, so a little correction should be neccessary. Greetings, Felix. |
|
November 14, 2010, 17:18 |
|
#3 |
New Member
Peter
Join Date: Aug 2010
Posts: 16
Rep Power: 16 |
Hi Felix!
Thank you for your answer. The reason why I was asking this, is a thread you have already seen (and answered to): http://www.cfd-online.com/Forums/ope...behaviour.html I am still not able to explain the strange behaviour of the SST-model within a simple rectangular channel. It gives a wrong prediction of the turbulent viscosity. After checking the mesh, rebuilding it with blockmesh and testing several boundary and initial conditions, the same problem occured again and again. I am sure that the problem has to be the tubulence model, but unfortunately I don't now what exactly causes this behavior. I was told that the reason for this behavior might be that the SST-model implemented in OF is not the Low-Re version. Peter |
|
February 16, 2011, 05:43 |
|
#4 |
Senior Member
Anne Gerdes
Join Date: Aug 2010
Location: Hamburg
Posts: 168
Rep Power: 16 |
Dear Foamers,
Sorry I posted the same reply in another thread but saw that this thread is much more fitting.... I am currently computing kOmegaSST with OF 1.7.0 on a lowRe mesh. Is there an alternative for omegaWallFunction as boundary condition? I always get bounding omega and omega increases to values approx. e+07 When I was computing with zeroGradient for Omega at the wall, I did not observe those problems. So would it be ok to set on the wall Omega zeroGradient k fixedValue e-11 ? In another thread talking about OF1.5-dev I read that zeroGradient is a working boundary condition for Omega. So I was wondering if this could work for OF1.7.0, too. Looking forward to reading your answers! Anne |
|
February 16, 2011, 08:39 |
|
#5 |
Senior Member
Felix L.
Join Date: Feb 2010
Location: Hamburg
Posts: 165
Rep Power: 18 |
Hello, Anne,
according to D.C. Wilcox and his pertubation analysis, setting omega at the first near wall cell to is the asymptotically correct wall boundary condition for omega, when y+<2.5. I.e. a dirichlet boundary condition should be imposed. This BC equals to OpenFOAMs omegaWallFunction when your mesh is fine enough to resolve the viscous sublayer. As you can see omega_w is proportional to 1/y^2! So it's no exception to get omega values of order 10^10 for very fine meshes. However, Wilcox points out that this BC might lead to numerical instabilities and proposes the slightly rough surface boundary condition: with the surface roughness k_R selected to be small enough to simulate a smooth surface. This is an alternative wall boundary condition for omega currently not being implemented in OpenFOAM, but this is still a dirichlet BC. Please refer to Wilcox' book if you need further information about this boundary condition. Another surface boundary conditon for omega is proposed by Menter (see this link for reference): These are the alternatives I know of. Personally, I've had good experience with the first and the last option, but I've never tried the second one. However, these are all dirichlet boundary conditions and until now I've only encountered neumann boundary conditions imposed for omega in combination with wall functions (i.e. high-Re-meshes with y+>30). I am not sure if the results of your calculations are siginificantly worsened when using zeroGradient for omega, all I know is that this BC is - per se - not asymptotically correct. Technically this doesn't neccessarily mean that your results are wrong, when using zeroGradient. There is a paper somewhere where the authors are comparing the different boundary conditions of omega and they also used zeroGradient. Unfortunately I can't find this paper anymore, maybe you'll stumble over it during your research. So due to lack of this paper I did a quick simulation of a simple flat plate test case comparing omegaWallFunction and zeroGradient as wall BCs for omega. The resulting skin friction coefficient distributions along the plate is attached. As you can see, the skin friction coefficient ist overpredicted by ~50% using zeroGradient. So I really wouldn't recommend this as a surface boundary condition for omega. Your numerical trouble using omegaWallFunction could be defused by either using one of the alternative BC definitions or by modifying the numerical and spatial setup. Greetings, Felix. |
|
February 16, 2011, 09:16 |
|
#6 |
Senior Member
Anne Gerdes
Join Date: Aug 2010
Location: Hamburg
Posts: 168
Rep Power: 16 |
Hey Felix,
It is interesting to read about the different possibilities for boundary conditions for Omega. And your picture show that zeroGradient is not a real alternative for Omega. In my computation I get values for omega with a maximum of e+7 and an average value of e+6 and the OpenFOAM output says "bounding omega". Nevertheless I will now go on running the case and see how the results will be. Thank you very much for your detailed answer! |
|
February 16, 2011, 16:18 |
|
#7 |
Senior Member
Felix L.
Join Date: Feb 2010
Location: Hamburg
Posts: 165
Rep Power: 18 |
Hello, Anne,
"bounding omega" only occurs when there are negative or zero values of omega appearing in some CVs - high values usually aren't a problem. These negative values most likely happen to appear due to unbounded numerical discretization. Applying a limiter to the convective omega scheme can solve unboundedness, but of course reduces the order of accuracy of your simulation a bit. If your case converges well, unboundedness of omega shouldn't be that much of a problem. Greetings, Felix. |
|
February 17, 2011, 04:25 |
|
#8 |
Senior Member
Anne Gerdes
Join Date: Aug 2010
Location: Hamburg
Posts: 168
Rep Power: 16 |
Thank you! I did not know that the negative values are the problem
These values are now after approximately 1000 time steps reduced to a minimum value of -1e-5 So I hope that my simulation works fine now. Thank you for your help! |
|
February 24, 2011, 03:59 |
|
#9 | |
Senior Member
BastiL
Join Date: Mar 2009
Posts: 530
Rep Power: 20 |
Quote:
I am having similar troubles but with fine meshes (y+<1). How would you exacly limit omega, please? Thanks. Regards Bastian |
||
February 24, 2011, 08:17 |
|
#10 |
Senior Member
Felix L.
Join Date: Feb 2010
Location: Hamburg
Posts: 165
Rep Power: 18 |
Hello, Bastian,
well it depends upon which scheme you are using for div(phi,omega)? If you've got e.g.: Code:
div(phi,omega) Gauss linearUpwind Gauss linear; Code:
div(phi,omega) Gauss linearUpwind cellMDLimited Gauss linear 1; Greetings, Felix. |
|
December 21, 2011, 11:41 |
|
#11 | |
Member
Eric M. Tridas
Join Date: May 2011
Location: Tampa, Florida
Posts: 48
Rep Power: 15 |
Hey Felix,
I know this is an old post but I found this interesting: Quote:
Thanks, Eric |
||
March 23, 2012, 05:33 |
|
#12 |
Senior Member
Anne Gerdes
Join Date: Aug 2010
Location: Hamburg
Posts: 168
Rep Power: 16 |
Dear Foamers,
does someone know what happens when setting k to zeroGradient (or kqRWallFunction which is the same as zeroGradient I think?) instead of fixedValue 0 for a lowRe computation with kOmegaSST, OpenFOAM-1.7. and omega to omegaWallFunction? My results seem to look better when using kqRWallFunction for k, instead of fixedValue 0. Could the y+ value of ~ 5 be the reason? Is it too big for a lowRe computation? |
|
March 23, 2012, 07:01 |
|
#13 | |
Senior Member
Vesselin Krastev
Join Date: Jan 2010
Location: University of Tor Vergata, Rome
Posts: 368
Rep Power: 20 |
Quote:
Hope this helps V. |
||
March 30, 2012, 05:46 |
|
#14 |
Senior Member
Anne Gerdes
Join Date: Aug 2010
Location: Hamburg
Posts: 168
Rep Power: 16 |
Thank you for your answer. I set the value to a small but non-zero value.
But I guess my y+ value mighjt be too big. I will work on that. Kind Regards Anne |
|
April 10, 2013, 15:00 |
|
#15 |
New Member
Jialin Su
Join Date: Mar 2013
Location: Loughborough
Posts: 29
Rep Power: 13 |
Hi Foamers,
I find this thread fairly interesting. But could someone explain the reason why k can't be set to exactly zero at the boundary? and if I want to use the omega boundary condition of Menter, how shall I do it? As far as I understand, this BC is like setting the value at the cell centre just next to the wall instead of at the wall, right? If this is the case, how shall I do it? Regards, Callum |
|
June 8, 2013, 07:35 |
|
#16 |
Senior Member
Ehsan
Join Date: Oct 2012
Location: Iran
Posts: 2,208
Rep Power: 27 |
HI Jilian
I have also problem with assigning omega "value" in case I have chosen omegaWallFunction in low-Re mesh. did you solve the problem and find out the answer? and are these settings also applicable for compressible and unsteady cases?
__________________
Injustice Anywhere is a Threat for Justice Everywhere.Martin Luther King. To Be or Not To Be,Thats the Question! The Only Stupid Question Is the One that Goes Unasked. |
|
June 12, 2013, 12:42 |
|
#17 |
New Member
Jialin Su
Join Date: Mar 2013
Location: Loughborough
Posts: 29
Rep Power: 13 |
Hi...Sorry for the late reply...
I didn't really specify the omega value as I set the boundary condition to omega wall function. According to the implementation, it is a blending of the asymtoptic solutions of omega at the log region and the viscous sub-layer. It should be automatically calculated based on the wall distance. You can find this information from either CFX or Fluent theory guide. So basically for both high Re and low Re the boundary condition is always omega wall function. it will automatically switch based on the wall distance. The initial value can be just a random large value. I put like 10000. It would be recalculated by the code during the simulation anyway. I did use it for compressible unsteady flow and I suppose it is working all right. |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
k-omega SST OpenFOAM 1.7 | paka | OpenFOAM | 18 | June 12, 2014 10:01 |
OpenFOAM 1.7 installation on Redhat linux | maxims | OpenFOAM Installation | 2 | November 30, 2012 05:29 |
[swak4Foam] OpenFOAM 1.6 and 1.7 with interFoam, groovyBC give different strange results | Arnoldinho | OpenFOAM Community Contributions | 7 | December 9, 2010 17:29 |
Cross-compiling OpenFOAM 1.7.0 on Linux for Windows 32 and 64bits with Mingw-w64 | wyldckat | OpenFOAM Announcements from Other Sources | 3 | September 8, 2010 07:25 |
k Omega SST SAS for OpenFOAM 1.5??? | barath.ezhilan | OpenFOAM Running, Solving & CFD | 3 | June 2, 2010 08:41 |