CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Running, Solving & CFD (http://www.cfd-online.com/Forums/openfoam-solving/)
-   -   LowRe-SST in OpenFOAM 1.7? (http://www.cfd-online.com/Forums/openfoam-solving/81977-lowre-sst-openfoam-1-7-a.html)

Peter85 November 12, 2010 06:36

LowRe-SST in OpenFOAM 1.7?
 
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

FelixL November 12, 2010 11:13

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.

Peter85 November 14, 2010 17:18

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

Anne Lincke February 16, 2011 05:43

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

FelixL February 16, 2011 08:39

1 Attachment(s)
Hello, Anne,


according to D.C. Wilcox and his pertubation analysis, setting omega at the first near wall cell to

\omega_{\rm w}={{6\nu}\over{\beta y^2}}

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:

\omega_{\rm w}={{2500\nu}\over{k_{\rm R}}}

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):

\omega_{\rm w}=10{{6\nu}\over{\beta y^2}}

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.

Anne Lincke February 16, 2011 09: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!

FelixL February 16, 2011 16: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.

Anne Lincke February 17, 2011 04:25

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!

bastil February 24, 2011 03:59

Quote:

Originally Posted by FelixL (Post 295596)
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.

Felix,

I am having similar troubles but with fine meshes (y+<1). How would you exacly limit omega, please? Thanks.

Regards Bastian

FelixL February 24, 2011 08:17

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;
you can apply a multi-dimensional limiter to the gradient discretization by setting:

Code:

div(phi,omega) Gauss linearUpwind cellMDLimited Gauss linear 1;
But there are many different ways, limitedLinear might be another choice.


Greetings,
Felix.

eric.m.tridas December 21, 2011 11:41

Hey Felix,

I know this is an old post but I found this interesting:

Quote:

I did a quick simulation of a simple flat plate test case comparing omegaWallFunction and zeroGradient as wall BCs for omega.
What value of y+ did you have along this plate (if you can recall)?

Thanks,

Eric

Anne Lincke March 23, 2012 06:33

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?

vkrastev March 23, 2012 08:01

Quote:

Originally Posted by Anne Lincke (Post 351070)
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?

Yes, the y+ should be lesser than 1 everywhere (or at least with only a few parts of the near-wall domain with, let's say, y+ between 1 and 2). And be careful with the "zero" k value: it should not be exactly 0, but something like 1e-12. About using the omegaWallFunction or not for low-Re computations, I've obtained similar (and quite good) results both using it or employing Menter's fixed value BC.

Hope this helps

V.

Anne Lincke March 30, 2012 05:46

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

callumso April 10, 2013 15:00

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

immortality June 8, 2013 07:35

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?

callumso June 12, 2013 12:42

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.


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