Density Based vs Coupled
 

Folks,
I generally use two classes of codes. High speed codes like CFD++, Vulcan etc which are described as density based solvers. And incomprehensible codes such as Star-CCM and Fluent, described as pressure based solvers.


Now Fluent and Star both have "coupled solvers" which allow them to solve problems where one would more typically use a density based code.


And in a similar fashion one can invoke "preconditioning" in the high speed tools which allow them to solve problems down as far as Mach 0.2, or so it is claimed


My experience with both these approaches is so simply use the appropriate tool if at all possible, and that running CFD++ to do a subsonic pipe network would or running Fluent to run a Scramjet are simply exercise in frustration.



So to my question. I doubt highly that the density based codes with a lot of preconditioning are actually numerically equivalent to a pressure based solver. IE the equations are descritized differently and solved differently.


Are the numerics for a "coupled" solver in a code like Fluent or Star really that similar to the numerics for a density based solver such as CFD++



Thanks
Andy

FYI


The coupled solver in Star is a density based solver.


Fluent has a density based solver literally called the density based solver. As a matter of fact, the prevalence of Fluent is one reason that such solvers are popularly known as density-based solvers.


Fluent and Star are compressible codes.

1. It is a popular misunderstanding that only density based solvers should only be applied to compressible flows and only pressure based solvers should be applied to incompressible flows. To paraphrase, truly incompressible solvers don't even (practically) exist anymore. The trick is to understand what accelerates the convergence and to tune those parameters for the specific problem. One set of tuning does not work for all classes of flows. The default tuning in any commercial solver is tuned for the typical customer. The fault is not in the algorithm or the tool, the user's training is simply insuffficient.
2. Density-based solvers aren't equivalent to pressure-based solvers. One excels at eliminating fast errors. And while it can be a source of frustration when your simulation divergees, it certainly is not fruitless. You can tune a pressure based solver to be very fast in highly compressible cases, I do this daily in my work. It's not mandatory but very helpful because there are huge economic advantages.
3. Density based solvers in Fluent and Star-CCM do act like density based solvers in any other algorithm.

I see that an increased interest appears in literature about "All Mach numbers" solvers.
The real world is full of compressible low-Mach flows, and results can be obtained in several ways. I personally worked with low-Mach solver for combustion as well as full compressible flow model, without any pre-conditioning, at low Mach flows. I think the pre-conditioner is just a tool to use higher time-steps but is not strictly mandatory.

Real World
 

So it may not be the numerics and more the tuning of various things like turbulence models to the flow regime. I have done side by side comparisons of Fluent, Star-ccm, Vulcan and CFD++ in a back pressured diffuser with a Mach 2 inflow. The two "high speed" codes absolutely do a better job at suppressing normal stress generated turbulence and appear (I mean its not like there is any real data on BL thickness in these situations ;-) to do a better job at boundary layer thickening at the shock impingement points. None of them get it completely right.

Additionally I can run the "high speed" solvers at much higher CFL numbers with good convergence than the "low speed" solvers.Things that take a day to converge in CFD++ may take a week or more in Fluent or Star using the "density" solvers.





So if the fundamental equation formulation is the same for all four cases (and I am still not sure it is) then we are looking at solution methods / solvers, limiters, and tuning of physical models to a flow regime. I would certainly buy that argument.



Keep in mind that all the "high speed cases" that Fluent and Star show are for external flow. And it does seem to be that up to about Mach 5 they can do the job. But reentry problems, orbital rockets and a lot of other stuff fly a lot faster than that. And the minute I put a wall around that flow things get real interesting. Admittedly supersonic diffusers are a pretty rare use case ;-)

This part may be true for your cases but not always true. I have come across many cases where density based coupled solver in starccm was frustratingly slow due to courant number issues. (You should talk to support staff of fluent and ccm and they encounter these things all the time).

Second do you have some mesh and set up to share that you think is not possible with pressure based solvers. This is where my personal interest lies. I would like to try it in wildkatze and see how it does. It might help the solver become better if we see it can't handle it.

After say, Mach 2 there is nothing inherently different about a Mach 3 flow versus a Mach 30 flow or a Mach 300 flow. The structures in the flow come from the viscous and kinematic interactions with bodies (i.e. walls), not due to the "high-speededness"

Interstellar winds move much faster and are much more "high-speed" than reentry vehicles and they follow the very simple gas dynamics equations. Anyone that claims any numerical code suddenly stop working at Mach 5 as if they have suddenly been swallowed by a computer bug is simply parroting.

As long as you ignore the issues involved with high temperature thermodynamics and the loss of thermodynamic equilibrium that may be correct. But for Ma > 5 such effects begin to contribute significantly to the overall flow physics. The classic example referred to by Anderson in his hypersonics textbook is the miscalculation of the reentry vehicle temperature that arises when such effects are ignored and the simple gas dynamic equations are used.

Yes and that is my point. It is being actively ignored. It is not a miscalculation, it is a misrepresentation of physical reality. The algorithm is doing exactly what you tell it to do. Garbage in should give garbage out–this is Gauss's famous exception that proves the rule.

For the most part it resolved by simply supplying the correct cp tables as a function of temperature and pressure, which is something you should be doing at all temperatures and pressures regardless even when Mach number is not 5. Anyone that has read Anderson's text knows that it simply adding an extra 2 dof's for the vibrational motions. So again, there is nothing inherently impossible about Mach 5. And most people doing these Mach>5 limits don't even take any of these physics into account. They really are just increasing the Mach number and watching their solution blow up and then blaming it on the physics (which cannot be a problem because it's not included in their physical model). The issues people encounter are are not physical nor numerical, they're personal. There is no reason their solver should blow up at Mach=3 when they assume an ideal gas with constant specific heats (the same assumptions they make at M=2 or M=1).

Always keep in mind that all of the "high speed cases" that Fluent and Star have shown are related to flow originating from the outside. It would seem that they are capable of doing the operation up to around Mach 5. There are a variety of objects that travel at speeds that are far greater than that, such as orbital rockets and reentry problems. The moment I began to confine that flow, things began to take on an intriguing dimension. It is important to note that applications that make use of supersonic diffusers are rather unusual.