SST k-omega model, definition of gamma or alpha in the production term
 

What is the definition of gamma in the SST k-omega model? I've read through various resources, but none of them seem to reference what this constant in the omega production term actually is.

https://www.cfd-online.com/Wiki/SST_k-omega_model has the variable in the production term, but does not define it below. They define but none of these are used in the equations.

https://en.wikipedia.org/wiki/Menter...ress_Transport: is not defined.

https://www.afs.enea.it/project/nept.../th/node67.htm also has an term, but they only define what is.

https://turbmodels.larc.nasa.gov/sst.html uses , but they only have definitions of .

I had to dig up Menters original 1994 paper, but it didn't really explain it either. Instead, the paper uses 2 sets of constants. They define the set 1 constants to be for the SST-inner, and the set 2 constants to be for the k-epsilon model. The only possible explanation I can think of is that the set 1 constants are used near the wall (where the k-omega model is used), and the set 2 constants are used in the free stream. However, I was under the impression that the SST k-omega model incorporates a blending function that transitions between the 2 regimes, so this explanation doesn't make sense.

Is there something that I'm missing? I just find it very strange that none of these resources fully define the parameters they use.

Don't have my code or reference now, but I'm pretty sure gamma is a blend of gamma1 and gamma2. Maybe look at the Fluent theory guide or Openfoam, they should both have it clear

They should be blended by F1

Follow the blending via the F1 function for alpha infinity.

The difference between alpha and alpha infinity is the low Reynolds number correction that you perform in the standard k-omega model. You normally don't do this correction in Menter's SST. In Fluent, the low Re correction is implemented for the SST model regardless (though off by default).

Ok I think I understand the blending function now. I don't really know what low Reynolds number correction is at this stage.

I've also been trying to understand wall functions. I've read that k-epsilon needs wall functions. Why is this? I've also read that doesn't k-omega support wall functions, yet most CFD codes say that wall functions are used in k-omega, which seems contradictory to me. I'm also aware that is some connection between low Re models and the use of wall functions, but I don't exactly know what it is. I'm struggling to find good (or any) resources that explain all this stuff to someone learning it for the first time.

Low-Re is a misleading terminology that has found mixed favors in literature.

One of the main problems (in terms of semantics) stems from the fact that:

1) It can explicitly refer to a correction which might be used in the k-omega model (and maybe other models as well)

2) It has been abused as a term to refer to models that can work with low y+ (i.e., close to the wall). Besides the clash with the previous point, the abuse here also comes from the fact that, as you might imagine, this model feature has mostly nothing to do with the Re of the flow (which must be high for the applicability of a RANS model inthe first place).

This becomes embarassingly misleading when a model, like k-omega indeed, falls in both categories. However, to the best of my knowledge, also because k-omega can already work at low y+ values, the Low-Re correction of the k-omega has not found widespread use, so you can kind of forget it for now.

So, this leaves us with models that either can (also misleadingly called low-Re) or can't (also misleadingly called high-Re) work with low y+ values. If they can then they don't need a wall function, if they can't they do need one (and the mesh must have a high y+ everywhere).

K-epsilon models can't work at low y+ values, unless they have wall dampings for one or more terms. So they need wall functions.

Spalart-Allmaras and most k-omega flavors work at low y+ values. Yet the question arises: does this mean that we can't use them at high y+ values? The answer is: it depends. In their basic formulation? No. But there are modifications that allow them to "work" (the definition of which is kind of left to the reader) both at low and high y+ values.

For obvious reasons, most commercial CFD codes have such all-y+ implementations of these models. Yet, none of these modifications was part of the original model and, to the best of my knowledge, only for the k-w SST this has been later addressed by the original author (Menter). For example, Spalart and Wilcox never produced a reference work that addressed wall function implementation for their models.

while this explanation is quite good and in line with the literature on the subject it also shows how underdeveloped the CFD theory (and its implementation in the CFD codes) is. I mean, common, probably 50 turbulent models are floating around (and more are generated every year), each of them with couple of conditions boosting the options to choose from in the vicinity of say hundred. It is just a nightmare for the standard CFD user because he's never sure in the fidelity of his results, especially with complex geometries that take days to run. Disappointing..

Well, you know, it's not like it is somebody's fault. Truth is, we know basically nothing about turbulence.

Also, we really want to do something hard that, especially in the RANS case, is not really well posed, like at all. If you converge with, say, N RANS models, it means that there are, at least, N solutions to the problem. If you consider that none of them is the ground truth, then there are at least N+1 solutions to the same problem.

It is in the nature of the thing we are trying to do. To be honest, to me, as long as they satisfy basic properties required by a RANS solution, they are all equally valid. Maybe all the N RANS solutions are even more reasonable than the ground truth...

I don't know sbaffini, it doesn't sound very promising.. I wander if NASA, Boeing, Lockheed-Martin, Airbus, etc big guys use the same Fluents, starCCMs, etc codes, or have something proprietary that is much more advanced and accurate (and which we'll never see). My frustration comes from the fact that billions of dollars are spent to send a probe billions km from here to find a "dark matter" in the space and they are not even sure if it would be able to communicate back the findings (if any). At the same time we don't know much about how the freaking air flows around us. Similarly, we don't know what is happening 20 km below the surface of earth either. How is that fair and logical (no need to answer)?
Regarding the confusing variety of turbulence models - you probably know that Floefd uses a single (they call it modified) K-epsilon TM to deal with all kind of flows including compressible, as far as I remember. It is obviously convenient, but from your explanation above, it looks like a single model could not be a panacea. I am a regular CFD user, with a very long experience/frustration however, and value a lot your opinion (of being on the theoretical side of the CFD).

I can tell you that these companies do have Fluent, StarCCM, etc. and utilize them to some degree. But I can also tell you that they use embarrassingly low-fidelity models (by CFD'ers standards), often 1-eqn SA. They use much more crude modeling tools to get the work done. Of course, they also do a ton of testing and don't blindly rely on inaccurate CFD.


The seaweed is also greener is somebody else's lake

I know, and the frustration is common. I've been for most of my academic path on the user side of things, just working on LES theory. Thus, for long time, I only looked at RANS from the user perspective and, for some reason, I had the feeling that, differently from LES, RANS was at least "operationally" well defined, with a clear implementation. What I learned working in development is that this couldn't be farthest from truth. There is no single aspect that, from the theoretical point of view, should just be like it is because it is theoretically sound and clear. It's a whole Grandma's recipe that gets passed on, obviously with certain merits.

I don't think anyone has any secret recipe here. Yet, I feel that a single model option in a code is more business related than anything else.

If you want my opinion, I think that a RANS model is, at present, a tunable tool to handle the turbulence problem. Different models have different features and tuning possibilities, besides complexity and cost. Probably, among the common choices there is some redundancy. One way to look positively at this is that each industry really has the chance to better suit its needs, yet not necessarily with great success (but better than nothing).

Hi Everyone,

I have a question about the k-omega SST model in Fluent and would be thankful if you could help me with that.

I am using this turbulence model to simulate blood flow through the aortic valve. I used the default values for each of the models' involving parameters. I am getting this warning message in the solution output:

Based on the Fluent Manual, it seems the values of the parameters below are universal. Does this mean that there is no need to modify the default values?
Attachment 91759

I passed the CFD course a long time ago but remember there were some parameters, like the Prandtl number, that were case-dependent and needed to be set using experimental data.

In literature, there are many papers published in reputable journals that used this turbulence model but did not mention anything about these parameters and their values.

Would you please let me know why I am getting this warning message and how I can fix it?

I tried to modify the values of turbulence intensity and length scales at boundary conditions, but this didn't help.


Many thanks in advance!

You are hijacking the thread but...

The warning is self-explanatory. Every iteration the solver calculates the turbulent viscosity. It also checks the ratio of turbulent viscosity to molecular viscosity. If this ratio exceeds the limit (which is a user defined number) then it the limiter is applied and the warning message is sent. The default value for the limiting ratio is an absurdly large ratio. In other words, your solver calculated a turbulent viscosity that makes no sense. Any turbulence model you use will check for this turbulent viscosity ratio. There are inumerable reasons why you would encounter this error, from wrong settings, to bad mesh, to anything. The warning is commonly encountered in early iterations and generally goes away as the solution converges. If your warning never goes away then you have an issue that might need attention. I'm only half-joking when I say the error will go away if you turn off the turbulence model. The reason it is half-serious is because you'll likely find more errors when you do this. However, I will say it is not the model constants that are causing the warning. You have a serious issue with your setup if you run into this warning persistently.

The model constants are definitely not universal (they are obtained from experimental data). Few people ever change from the defaults and so it is implicitly understood that, if not mentioned, the defaults are being used for whatever software is being used. You should (if you were so inclined) make your own measurements and put in the right model constants for your problem. But if you knew the model constants, you wouldn't be doing RANS in the first place, so it is a catch-22. There are no universal turbulence models. That's why we call them models and not turbulence laws.

Dear LuckyTran,

Thanks for your detailed response. I appreciate your help.