[Guvennergiz]

Dear CFD Fellows,

Is there a decision table, diagram or software you use for turbulence model selection? What I'm looking for is not a table with information for each model, but rather a visual with decision steps such as "if the flow contains a-b-c, these models can be used". In the relevant case, after following the characteristic factors of your flow, I expect turbulence models to be proposed in the last section that can best define the flow.

Thank you for your interest.

Best regards,

Güven

[arjun]

It is very very difficult thing to answer. What makes it so difficult is the fact that in practice there is no such thing as best turbulence model (this parts needs some explanation).

In general you would see that LES/DES models give you most reliable results other than DNS. Then you would have RANS models mostly two equation models and then 1 equation model.

The problem is that (the explanation part of that earlier statement) the same turbulence model behaves differently with different solvers. For example take some SA DES model , now this could give you worse results with software X but gives you best results in software Y. This happens because of many many additional reasons (how the solver does the descretization etc etc many things).

So you may end up in a situation where SST K Omega gives you better result with software X compared to DES from software Y.


So the best way about it is to first narrow down the software that you are likely to use and explore which model is most reliable in that. Here reliable means gets good results most of the time.

This is why lots of companies i know actually test all turbulence models on some of their pet test cases and judge for their use which turbulence model they would use.

[CFDfan]

It is like asking how the watch works - it would be a very long story

The turbulence models are both, the application area and the software specific. So you focus, as suggested, on the software you are going to use and then on the application area and after that find and run examples (you know the correct results of) in this application area to figure out which turbulence model will give the closest match. BTW, I guess you know that, but you shouldn't worry about the turbulence model of Solidworks Flow simulation, because it uses a single model.

[Guvennergiz]

Dear Fellows,

We are all choosing a Turbulence Model for our flows. We are already creating decision chart in our heads. So, why not put these decision steps together and create a real chart? Please do not think so complicated. At the end of the chart there won't be only one Turbulence Model for relevant case, there will be list (at end of different decision steps same model could be listed too). After that you can do some literature search to select the best model in the list.

Please consider that.

Best regards,
Güven

[sbaffini]

Originally Posted by Guvennergiz

Dear Fellows,

We are all choosing a Turbulence Model for our flows. We are already creating decision chart in our heads. So, why not put these decision steps together and create a real chart? Please do not think so complicated. At the end of the chart there won't be only one Turbulence Model for relevant case, there will be list (at end of different decision steps same model could be listed too). After that you can do some literature search to select the best model in the list.

Please consider that.

Best regards,
Güven

I understand and feel the pain, I swear, both for numerics and turbulence models, because I was there, but that's not how these things work, not at all. And this is one of the reasons for which CFD codes "made easy" don't usually work well, unless they are very very specific to a certain field.

Of course there are guidelines, but, you know, it's not that you have hundreds of models, so you don't need a chart or a table. If you studied the minimum necessary amount to do CFD, you know how a k-omega differ from a k-epsilon or spalart-allmaras. Or how, say, a Roe scheme may differ from the AUSM, a coupled solver from a segregated one, etc. It's stuff you can grasp after a couple of reads.

One reason you have guidelines instead of charts is also because a chart would give you a sense of certainty, safety, that you are not supposed to have even in the simplest flow, because:

1) It is quite probable that your flow is complex, and there is a set of features that may challenge all the models. So, in the end, no model is quite right but neither plain wrong. This is the large majority of cases and your choice might, in the end, depend from the specific quantity you are most interested in for that specific simulation (which, indeed, can change from time to time)

2) As others mentioned, there is no such thing as an official gold standard for turbulence models, but just benchmarks and references. Let me give you an example: in the original k-omega formulation, Wilcox suggests a very appalling way to fix omega at walls, something that no one working on complex unstructured CFD codes is probably willing to use. Indeed, I'm pretty sure that no one does it that way. What is the reference for the k-omega implementation? Was Wilcox correct/reasonable in the first place when he devised his way of fixing omega at walls? Truth is that the omega equation is just a reasonable model, not ground truth that you can experiment with in real life, so omega at walls is part of the model and every CFD code does it in its onw way.

3) Even different methods like FEM and cell-centered FVM are night and day with respect to model implementations, especially boundary conditions. Some FVM things simply do not apply at all in FEM and viceversa. Implementations try to work around such differences but, again, there is no gold standard for this.

4) Arjun mentioned LES. I just want to mention that not everyone in academia agrees on which form the equations should have in LES. Just let that sink in for a minute

5) If nothing of the above applied, and there was certainty for all of them, I would still not give you a chart. The reason is that you don't, kind of, release such things into the wild like if they were animals, let them do their job on some physical stuff, and then return to their cages. They are applied to geometry, mesh and boundary conditions provided by the user. The mesh resolution alone (not even considering topology or orthogonality) has such an influence by itself, trough wall functions, that the best you can have is a chart for a single model for a single type of flow. Have you ever looked at how many different kind of wall functions are out there, also depending from the specific code they are used into? Another question is: are Spalart-Allmaras and k-omega models supposed to be all y+ models or should they always be used without wall functions?

These are the first things coming to my mind. There are few more hundreds details out there that you only know when you actually do CFD. As I said, most (if not all) of this knowledge is well catalogued and can be accessed easily. In the form of a chart or a table? The possible outcome (limited if not wrong) is really not worth the effort in my opinion.

Allow me to digress and guess that (but don't take me wrong here) what you probably want, as someone learning a new subject, is some way to catalogue the new knowledge while you acquire it. In this case, there is nothing wrong if you try to put up some turbulence model table, it will actually help you a lot and I suggest you to do it. But that's a learning tool for you that, with time, you will see how useless it is in practice. We all did this.

In contrast, the more general idea that CFD can be so automatized and reduced to decision charts and tables, is just a marketing scam. Otherwise how would software vendors increase sales of such highly technical pieces of software? And the idea they came up with is just brilliant: let's just don't make it technical anymore!!! In this context you will see a lot of tables, charts, youtube videos, tutorials, etc. But in this case we are not anymore on the same page.

[LuckyTran]

Too many people think the decision is of type "if p then q" (because who doesn't like flowcharts!?) when it is much more realistically "if !p then !q".

It's already shortsighted to consider a flow as being characterized by a single flow feature that even makes this chart possible. But even if that were true, it's not about looking for a specific flow feature and deciding whether to use SA or k-epsilon or k-omega model. We all know DNS exists, we're just unable to fulfill the conditions to make it work and so we do our best to make something else that does work.

What ends up happening is, we change the problem (we pick the flow!) until the flow works for our turbulence model with our capability. We literally change the domain definition. Instead of modeling an entire sewer network, I model only this one needle valve. I don't model the entire aircraft (the external flow over the surfaces and flow through the engines), I model just the things that I can handle. So and so model isn't good for combustion? Well, if I delete the engine, then it's a non-issue!

So once you've finally executed all these steps, it can certainly feel like you made a bunch of linear decisions to arrive at the conclusion that you needed to do it a certain way. The actual decision making process isn't linear, it isn't circular either. There are ends and they meet in the middle.

Just look at any sport like Football/Soccer. One side wins because they have a higher score than the other. And they score by kicking the ball at the goal. So the win condition is to kick the ball at the goal, yeah? But have you listened to any interview of a professional player and asked them what they did better than the other team that won them the game? No one answers "I kicked the ball." There are a million things must happen before you can kick the ball into the goal. But if you were to tell a little 6 year old child how to play football, isn't that the first thing you would tell them? Just kick the ball into the goal. It's the same game with the exact same rules...

[Gerry Kan]

Salam Güven:

In theory and practice, this kind of heuristics are counterproductive because the correlation between turbulence model and their suitability are, in polite terms, highly non-linear, and thus they cannot be summarily presented.

Since you are probably doing this for a living (based on your signature and your LinkedIn profile), I will provide you with some anecdote. In the past I have been requested to do commercial "validation" exercises where all it matters is that your CFD code matches the supplied measurement data, no matter how poorly and arbitrarily they are collected, and in most cases they are. In some cases they worked, in other cases, not so good.

In the end, it is the code with the most tuning factors wins, where results can effectively be fudged to match whatever number being thrown at it for "validation". Sadly, in the end that's what only really mattered to those with the wallet. If you are seriously looking into an end-all solution to your dilemma, you might find this route much more rewarding.

Gerry.

[CFDfan]

Originally Posted by Gerry Kan

Salam Güven:
In the end, it is the code with the most tuning factors wins, where results can effectively be fudged to match whatever number being thrown at it for validation.
Gerry.

Sadly, that's what I found as well, and we all know what this (these) codes are.

[FMDenaro]

Originally Posted by Guvennergiz

Dear CFD Fellows,

Is there a decision table, diagram or software you use for turbulence model selection? What I'm looking for is not a table with information for each model, but rather a visual with decision steps such as "if the flow contains a-b-c, these models can be used". In the relevant case, after following the characteristic factors of your flow, I expect turbulence models to be proposed in the last section that can best define the flow.

Thank you for your interest.

Best regards,

Güven

Just to have an idea of the complexity of an "ideal" flow chart, have a look to Introduction in Chap 10 of the Ferziger, Peric and Street textbook. It is recalled what Bardina addressed 40 years ago

[arjun]

BTW here Prof Garry Page's presentation summerises the results obtained by various turbulence models and various solvers

https://autocfd.eng.ox.ac.uk


All these calculations are run on same mesh with same boundary conditions. So only two variables here : Solvers and Turbulence model.

[Guvennergiz]

Originally Posted by arjun

BTW here Prof Garry Page's presentation summerises the results obtained by various turbulence models and various solvers

https://autocfd.eng.ox.ac.uk/#presentations


All these calculations are run on same mesh with same boundary conditions. So only two variables here : Solvers and Turbulence model.

Dear Arjun,

"400 Bad Request" error appears when I click to the link.

[arjun]

Originally Posted by Guvennergiz

Dear Arjun,

"400 Bad Request" error appears when I click to the link.

does this work

https://autocfd.eng.ox.ac.uk

[Guvennergiz]

Originally Posted by arjun

does this work

https://autocfd.eng.ox.ac.uk

Thank you for sharing. At the page 24-25 there is such a good comparison plot.

[CFDfan]

Check this out. It's quite explanatory. It limits the TM options but as I said before they are strongly related to the application area.

https://www.engineering.com/story/ch...cfd-simulation

Gerry, below, in italic, is something that supports what you said before (this was my thinking too). That is how Fluent, with its numerous TM, portrays the impression of being the perfect code, because at least one of the TM can be fudged to give the expected answer.
"When someone shops for a CFD code, they might think that it would be an advantage to have many turbulence models,” said Paul Malan, director of fluids applications for SIMULIA R&D. “Let’s say that they make the purchase of their perfect code with, say, 50 different models. They are thrilled, because surely at least one of these will give the right answer. But when he starts to solve a real problem, he has to choose one of the 50. Which should he choose? And once he has made the choice, how does he know it is giving the right answer