[AndyR]

Folks,
So the general default setting for most solvers is to limit the turbulent viscosity ratio to 100,000. That number has, in fact, worked well for the bulk of the problems I have run. But... why 100,000. Certainly that's a lot of turbulent viscosity! But if we have a well posed problem and an apparently reasonable grid, and all engineering variables are well converged, all residuals are well behaved, and we still see significant clipping, what is the solution telling us?
After all 100,000 is a somewhat arbitrary number. And if we see these values in the bulk flow, it is hard to see how a finer mesh would reduce the viscosity ratio (though I may be missing something here).

Is this just a function of the steady state assumption in any RANS approach?

Just musing upon this.
Andy R
JCC where are you?

[agd]

First, keep in mind that this is a ratio. For the codes I am familiar with it is the ratio of the turbulent eddy viscosity to the molecular viscosity, and the molecular viscosity is generally quite small. Second, the range (I have seen 100,000 to 250,000 used) generally is the result of a great deal of numerical experimentation and code tuning using a well-established set of known physical flows. Limiters like this are used to prevent the turbulence models from running away - they provide some measure of robustness to non-linear equations that are only models of physical behavior. That's the last thing to keep in mind - these are models, and the eddy viscosity is a single term being used to represent a whole lot of physics.

[AndyR]

So I follow all that, I guess its the value of the limiter I am after. We can go look at the COKE coefficients of good old K-e and find that they were specifically intended so K-e calculations do an excellent job on a flat plate. And then we all sort of smile quietly to ourselves and pretend that they can be used on our non-flat plate geometry. With some success as it turns out. But I have never found a way to trace back to the value of 100,000 or as you have mentioned the value of 250,000 (which code was that by the way). Did this come from say a fully developed pipe flow calculation? Or was it simply a number that the various code developers found worked for a broadly applicable set of cases.
In the end the viscosity closure seems physical. You can measure the turbulence levels in a wind tunnel by measuring the drag on a sphere and comparing it to the "correct" value. That extra drag comes from the turbulence, but the same effect would be observed if the flow were simply more viscous. In the end its a model that works, just always thought the limiter value was an extra special bit of empiricism on top of the empiricism inherent in any model.

[LuckyTran]

Order of magnitude analysis yields that the viscosity ratio is O(1000). 100000 is an arbitrarily larger number that is supposed to be non-sense. You can set the limiter to whatever value you want, but if your converged solution has a viscosity ratio above 10,000 it's almost certainly wrong.

[gnwt4a]

a random guess would be because it is the limit of single precision floating point arithmetic.

[AndyR]

LuckyTran,
So if I go back Anderson, Tannehill, & Pletcher, I find that Prandtl's definition of turbulent viscosity is density*L* (du/dy) where L is a turbulent length scale.
The equation used in the K-e model is similar in that it is linear with density.
So that order of 1000 is for a specific fluid at a specific state with a specific length scale. So if we assume the length scale is driven mostly by the geometry, then for a high shear flow with a large density the turbulent viscosity can be quite high.
I am running air at moderate velocities, Mach 0.1 to 0.2, and high pressures, 150 atmospheres. So density is high, shear is high, L is ???.
The result is very high turbulent viscosity and thus a high ratio.

I am going to grab a few points in the solution and try and back out turbulence intensities and length scales and see if they seem reasonable. If they do, it would tell me that, for this specific case, the limiter should in fact be higher.

-Andy

[AndyR]

So it all works out with a TVR limiter of 450,000.
I have a dozen or so cells that hit the limiter, but those seem to be cells that Star-CCM is applying cell remediation on... wink wink.

Lesson learned for me, system model defaults from vendor are generic.
As you push into physical states that are less usual (in the engineering sense) these may need to be revisited.

Thanks for listening
ANdy

[LuckyTran]

Nice confirmation bias you have going there.

Clearly you have a bad mesh if cell quality remediation is being invoked.

[AndyR]

Lucky Tran.


So after raising my TVR limiter to a more realistic value. The solution has been re-converged. The engineering quantities of interest. Delta P and flow splits changed by only a few percent. So in the end, the improvement of the solution, did not really change any design drivers. Given the "error" inherent in the RANS assumption, I will call those changes insignificant.



Could my mesh be better. Of course. Is it good enough, I think so. Any automatically generated mesh has flaws. Period. Don't kid yourself.

How those particular flaws get handled is always a question. STAR-CCM is up front about it. If you have a highly skewed cell, and the solution seems to be going unbounded locally, it will attempt to apply some local cheats to reduce the influence of that cell. If I have 20 iffy cells out of 80 million cells, do you really think that will change the lift/drag/delta P/temperature rise or other integrated engineering quantity? Do you think that change is significant given the overall confidence in those values? My answer is no to both questions.



This pursuit of numeric perfection is what leads to silly things like quadratic k-epsilon and fifth order accurate discretization schemes.



As to confirmation bias



AN OOM analysis shows that for reasonable estimates of turbulence intensity and length scale, combined with the densities and velocities in the flow field in question, that the turbulent viscosity ratio can go as high as 1,000,000. Thus the code default of 100,000 is not a good value for my problem.



For those of you newbs who have been following this.



Lesson: Code defaults may work 90% of the time, but if they dont it may not be you, it may be them. Check the numbers for your physics. But do keep in mind it is usually you! ;-)




Lesson: CFD is just a tool. an engineering tool. Dont spend more effort on "accuracy" and "quality" than the solution warrants. Regardless of the numeric accuracy of your solver and the quality of your grid, the usefulness of your answer is likely more limited by higher level modeling assumptions. Keep your level of effort consistent with the required results. The pursuit of numeric perfection is one of the reasons that managers think CFD "takes to long" and why those same managers push for thinks like the EFD solver built into Solidworks.



My 2 cents
Andy R
Pushing nodes since '84