[Shamoon Jamshed]

delta p = (L/D)/(0.5*rho*v*v)

[KLG]

why can't we use multiphase model when we are considering density based solver ? we can enable wet steam or off the mutiphase model while density based solver is enabled?

[KLG]

can anyone mail me the journal or article regarding results obtained by simulating open type shock tube in fluent?
I have no idea what type of contours comes as a result of the simulation of open type shock tube?
mail: kanchugurung94@gmail.com

[kamel86]

I am looking to simulate supercritical water inside the vertical tube so which is more acceptable density based solver or pressure based solver?

[liebowitz]

Originally Posted by RRD

How do you quantify Highspeed?

I think the general consensus is that compressibility effects start to become evident at Mach numbers greater than 0.3. Of course this applies mostly to gases, with liquids you might just ignore compressibility altogether

[Hitesh12]

Here is the information from Ansys v18.2.2

https://www.sharcnet.ca/Software/Ans...eOverview.html

[Tobi]

Originally Posted by johnfriend

Historically speaking, the pressure-based approach was developed for low-speed incompressible flows, while the density-based approach was mainly used for high-speed compressible flows. However, recently both methods have been extended and reformulated to solve and operate for a wide range of flow conditions beyond their traditional or original intent."
"In both methods the velocity field is obtained from the momentum equations. In the density-based approach, the continuity equation is used to obtain the density field while the pressure field is determined from the equation of state."
"On the other hand, in the pressure-based approach, the pressure field is extracted by solving a pressure or pressure correction equation which is obtained by manipulating continuity and momentum equations."
The pressure-based solver traditionally has been used for incompressible and mildly compressible flows. The density-based approach, on the other hand, was originally designed for high-speed compressible flows. Both approaches are now applicable to a broad range of flows (from incompressible to highly compressible), but the origins of the density-based formulation may give it an accuracy (i.e. shock resolution) advantage over the pressure-based solver for high-speed compressible flows."


refer: http://courses.cit.cornell.edu/fluent/wedge/step4.htm

HI everybody,



an old thread but I have my doubts about the quoted statements for density based solvers in OpenFOAM. Here, we solve the momentum-pressure coupling in both, density and pressure based solvers and transport the energy through the field. Knowing the pressure and enthalpy (temperature) at each cell, we can re-calculate the density field which is then applied.

The statement above is somehow misleading for me as it is written that we use the density to get the pressure. I am not sure how other software tools are handling this situation but in FOAM it should be clearly visible to everybody that we do the following:

• Solve energy
• Solve momentum (or at least construct it)
• Solve Poisson for pressure and recalculate fluxes to update U
• Update the density based on the actual energy and pressure

Redo until converged. I might get the code wrong but for me it seems that the density is updated using EOS rather than the pressure.

Hints, feedback, critics are always welcomed.

[arjun]

Originally Posted by Tobi

HI everybody,



an old thread but I have my doubts about the quoted statements for density based solvers in OpenFOAM. Here, we solve the momentum-pressure coupling in both, density and pressure based solvers and transport the energy through the field. Knowing the pressure and enthalpy (temperature) at each cell, we can re-calculate the density field which is then applied.

The statement above is somehow misleading for me as it is written that we use the density to get the pressure. I am not sure how other software tools are handling this situation but in FOAM it should be clearly visible to everybody that we do the following:

• Solve energy
• Solve momentum (or at least construct it)
• Solve Poisson for pressure and recalculate fluxes to update U
• Update the density based on the actual energy and pressure

Redo until converged. I might get the code wrong but for me it seems that the density is updated using EOS rather than the pressure.

Hints, feedback, critics are always welcomed.

Rho central foam in my understanding solves for density and obtains pressure from it.


The blast foam library based on / using it also does the same.

[Tobi]

Okay, «rhoCentralFoam» is a special solver and here the pressure is obtained by:

p = rho/psi

However, I don't think this is not valid for the other foam solvers. The blastFoam library is a special solver that I don't know in details. But okay. You are right. I am not an expert in this topics.
Well, I see, I might be wrong here. This would make sense in addition too as Fluent does not solve for the pressure (at least I cannot see any residuals for the pressure field).

[arjun]

Originally Posted by Tobi

Okay, «rhoCentralFoam» is a special solver and here the pressure is obtained by:

p = rho/psi

However, I don't think this is not valid for the other foam solvers. The blastFoam library is a special solver that I don't know in details. But okay. You are right. I am not an expert in this topics.
Well, I see, I might be wrong here. This would make sense in addition too as Fluent does not solve for the pressure (at least I cannot see any residuals for the pressure field).

By special solver you mean they are density based solver. They are different class of solver. They usually get the flux by ROE, AUSM or other such schemes.


-----------------------------



Originally Posted by johnfriend
Historically speaking, the pressure-based approach was developed for low-speed incompressible flows, while the density-based approach was mainly used for high-speed compressible flows. However, recently both methods have been extended and reformulated to solve and operate for a wide range of flow conditions beyond their traditional or original intent."
"In both methods the velocity field is obtained from the momentum equations. In the density-based approach, the continuity equation is used to obtain the density field while the pressure field is determined from the equation of state."
"On the other hand, in the pressure-based approach, the pressure field is extracted by solving a pressure or pressure correction equation which is obtained by manipulating continuity and momentum equations."
The pressure-based solver traditionally has been used for incompressible and mildly compressible flows. The density-based approach, on the other hand, was originally designed for high-speed compressible flows. Both approaches are now applicable to a broad range of flows (from incompressible to highly compressible), but the origins of the density-based formulation may give it an accuracy (i.e. shock resolution) advantage over the pressure-based solver for high-speed compressible flows."

[arjun]

BTW in wildkatze you can chose ROE fluxes and thus it can sort of behave similar to density based solver as far as flux dissipation goes. (instead of Rhie and Chow).

[Tobi]

Special is related to the fact that it is another implementation than solvers such as

• pisoFoam
• pimpleFoam
• simpleFoam
• rho*Foam
• combustion/sovlers
• multiphase/solver

as here, it is demonstrated how to implement a central-differencing discretisation.
The other solvers do have each single term in a «semantic» form rather than direct code.
However, maybe I got things wrong in the «rhoCentralFoam»

[arjun]

I think the issue is that most people use the solvers you have mentioned as they can deal with large number of cases. The density based solvers are used in high speed compressible flows that is much smaller area.



None the less openfoam indeed has the density based algorithm. It may not be a popular one but it has.

Originally Posted by Tobi

Special is related to the fact that it is another implementation than solvers such as

• pisoFoam
• pimpleFoam
• simpleFoam
• rho*Foam
• combustion/sovlers
• multiphase/solver

as here, it is demonstrated how to implement a central-differencing discretisation.
The other solvers do have each single term in a «semantic» form rather than direct code.
However, maybe I got things wrong in the «rhoCentralFoam»

[Tobi]

So actually, if I got everything correct.

• rhoSimpleFoam
• rhoPimpleFoam
• combustion solver ( I did not went through all)
• the heat transfer solvers
• ...

are pressure-based solvers as we solve a Poisson equation. Honestly, I thought the pressure-based are incompressible (divided by density) and density do include the density as variable. Then it does make sense to use a pressure-based solver and using an EOS. Otherwise, it would not make sense.

[arjun]

Yes.

Pressure based solvers are mainly solving pressure poisson equation as you noted.

Originally Posted by Tobi

So actually, if I got everything correct.

• rhoSimpleFoam
• rhoPimpleFoam
• combustion solver ( I did not went through all)
• the heat transfer solvers
• ...

are pressure-based solvers as we solve a Poisson equation. Honestly, I thought the pressure-based are incompressible (divided by density) and density do include the density as variable. Then it does make sense to use a pressure-based solver and using an EOS. Otherwise, it would not make sense.

[FMDenaro]

I am not sure that for solving the equations within the divergence-free constraint it makes really sense to denote either pressure or density-based approaches.

[sbaffini]

Last time I checked, density based solvers in OF (e.g., rhoCentralFoam) were pretty much explicit, naive, painfully slow implementations, not really representative of modern implementations.

Most modern, all Mach, implementations typically use pressure as independent variable and determine density from the EOS

[arjun]

Originally Posted by sbaffini

Last time I checked, density based solvers in OF (e.g., rhoCentralFoam) were pretty much explicit, naive, painfully slow implementations, not really representative of modern implementations.

Most modern, all Mach, implementations typically use pressure as independent variable and determine density from the EOS

Nonetheless they are of different class of algorithm.

I believe that the places they will be used the explicit nature makes sense and in fact could be advantage over the "most modern" algorithms.
Typically where they are used the delta t is very small , for example in combustion the delta is like 1E-9 to 1E-6 types.

Here using implicit algorithm might be unnecessarily costly.

While in smaller time steps the pressure based algorithm that use Rhie and Chow type of flux dissipation even de-couple.

so density based solvers have their place. Even as we speak this topic I am seriously evaluating the implementation of explicit solver into Wildkatze (for the reasons i mentioned above).

[sbaffini]

Sure but, for anything steady they are just a pain in the ...

Honestly, also looking at the implementation, they have been put there just like the Black-Scholes and solid solvers, just because they could.

So, let me take the chance to highlight that an actual solver that works is a totally different business (and I'm sure you know, but not all the OF users do, because most people in academia don't as well)

[arjun]

Originally Posted by sbaffini

Sure but, for anything steady they are just a pain in the ...

Honestly, also looking at the implementation, they have been put there just like the Black-Scholes and solid solvers, just because they could.

So, let me take the chance to highlight that an actual solver that works is a totally different business (and I'm sure you know, but not all the OF users do, because most people in academia don't as well)

They most of the time pain in unsteady too. During my time at CD Adapco I learned that most people avoid the coupled solver, which is basically what we call density based solver (written to solve pressure as you said).
It can be very slow to converge and in transient cases it is costlier than good SIMPLE method.
This is why added only the flux option into the Wildkatze because then the cost is similar to Rhie chow based method while the decoupling issue is somewhat taken cared of.