[sbaffini]

Dear all,

I have a doubt about how a correct pressure inlet bc should be implemented and would like to hear from anyone who has coded this.

Let's first clarify that I'm talking about this. The description there clarifies that for incompressible flows it implies:

1. Static pressure Ps is extrapolated from neighbor cell to the boundary face (with 0 gradient)
2. Bernoulli and the input total pressure are used to determine the velocity magnitude at inlet
3. Temperature at inlet is specified as static

For compressible flows it is only slightly different, as it uses the isentropic relations (and the input temperature is the total one), but it is otherwise the same bc. The main point of the compressible procedure that I need here is the determination of the Mach number from given total and static pressure, that is, the compressible analogue of the second point above:



The main issue with the previous implementation is that, in practice, nothing prohibits the static pressure in the neighbor cell Ps to be bigger than the total pressure value P0 used as input. This may be just a random initialization, the output of some iterations or, physically, a neighbor inlet with a much higher total pressure and the right kind of geometry. I think it really doesn't matter, it can simply happen and the formulas above would fail because of a negative number under the square root.

In the past I used two different routes to overcome this.

First route, later abandoned (but left in as a differently labeled bc), was based on actually extrapolating the Mach number instead of the static pressure and then using the isentropic relations to determine the static pressure and temperature. The problem here was that it didn't really solve the issue for incompressible flows, where the dynamic pressure could still come out larger than the prescribed total pressure.

The second route, which I disliked in the beginning (as I dislike all the limiters), but eventually started to make sense: just limit the extrapolated static pressure from the neighbor cell to be lower or, at most, equal to the prescribed total pressure at inlet.

I successfully used both versions and still have both, so it is, in part, just a semantical issue. In the end, however, I decided for the latter to be my pressure inlet because it is more general and usable, does what most people would expect it to do and, moreover, I have found it used also in TLNS3D.

So, the question is: how have you handled this in your code? how did you code the pressure inlet bc?

The only textbook where I could find this bc mentioned and treated in the above terms (any other textbook just uses a treatment based on Riemann invariants) is the one by Moukalled et al. but, besides being not perfectly clear, I don't use a pressure based method and their description doesn't seem to apply to my density based case. Also, I use the inlet bc weakly, so the provided values will still be just the left state of a convective flux based on the Roe riemann solver.

I just focused on the ideal gas case here, but more general gases would be interesting as well (some papers treat the isentropic/adiabatic change numerically, via Newton-Raphson).

[FMDenaro]

Originally Posted by sbaffini

Dear all,

I have a doubt about how a correct pressure inlet bc should be implemented and would like to hear from anyone who has coded this.

Let's first clarify that I'm talking about this. The description there clarifies that for incompressible flows it implies:

1. Static pressure Ps is extrapolated from neighbor cell to the boundary face (with 0 gradient)
2. Bernoulli and the input total pressure are used to determine the velocity magnitude at inlet
3. Temperature at inlet is specified as static

For compressible flows it is only slightly different, as it uses the isentropic relations (and the input temperature is the total one), but it is otherwise the same bc. The main point of the compressible procedure that I need here is the determination of the Mach number from given total and static pressure, that is, the compressible analogue of the second point above:



The main issue with the previous implementation is that, in practice, nothing prohibits the static pressure in the neighbor cell Ps to be bigger than the total pressure value P0 used as input. This may be just a random initialization, the output of some iterations or, physically, a neighbor inlet with a much higher total pressure and the right kind of geometry. I think it really doesn't matter, it can simply happen and the formulas above would fail because of a negative number under the square root.

In the past I used two different routes to overcome this.

First route, later abandoned (but left in as a differently labeled bc), was based on actually extrapolating the Mach number instead of the static pressure and then using the isentropic relations to determine the static pressure and temperature. The problem here was that it didn't really solve the issue for incompressible flows, where the dynamic pressure could still come out larger than the prescribed total pressure.

The second route, which I disliked in the beginning (as I dislike all the limiters), but eventually started to make sense: just limit the extrapolated static pressure from the neighbor cell to be lower or, at most, equal to the prescribed total pressure at inlet.

I successfully used both versions and still have both, so it is, in part, just a semantical issue. In the end, however, I decided for the latter to be my pressure inlet because it is more general and usable, does what most people would expect it to do and, moreover, I have found it used also in TLNS3D.

So, the question is: how have you handled this in your code? how did you code the pressure inlet bc?

The only textbook where I could find this bc mentioned and treated in the above terms (any other textbook just uses a treatment based on Riemann invariants) is the one by Moukalled et al. but, besides being not perfectly clear, I don't use a pressure based method and their description doesn't seem to apply to my density based case. Also, I use the inlet bc weakly, so the provided values will still be just the left state of a convective flux based on the Roe riemann solver.

I just focused on the ideal gas case here, but more general gases would be interesting as well (some papers treat the isentropic/adiabatic change numerically, via Newton-Raphson).

Paolo, I suppose you are considering a subsonic inflow in case of compressible flow, right?

When I worked (a lot of years a go...) with density based formulation for subsonic inlet I tested different combinations of BCs. The only combination that showed to work properly was a fixed static pressure at the outlet while at the inlet only the stagnation properties were prescribed. That is the total enthalpy cp*T0. Then you can use the isoentropic and adiabatic relations. Unfortunately, I don't remember all details of my code, I doubt I used the extrapolation of the static pressure.

[Eifoehn4]

Dear Paolo,

did you read the complete ANSYS manual?

"The static pressure is ignored by ANSYS FLUENT whenever the flow is subsonic, in which case it is calculated from the specified stagnation quantities."

FMDenaro already pointed in the right direction. A common used subsonic inflow boundary (very likely also used by ANSYS):

1. Total enthalpy and a Riemann invariant from inside
2. Stagnation quantities from outside
3. Static quantities are calculated from (1) and (2) via isentropic law and EOS

See for example:

Chapter 2.7:
https://fun3d.larc.nasa.gov/papers/N...011-217181.pdf

Chapter C:
https://ntrs.nasa.gov/api/citations/...0180001221.pdf

Regards

[sbaffini]

I probably misguided you by using a Fluent based nomenclature.

What I am referring to is, exactly, a total pressure bc. That is, I know total pressure P0 and total temperature T0 at inlet. How do I obtain static pressure Ps and temperature Ts and velocity magnitude V at inlet? Note that I can't compute density before having Ps and Ts.

I am aware of the FUN3D papers but they seem to use a different bc, similar to the pressure far field one in Fluent nomenclature. Also, that doesn't directly apply to my case, as I use a preconditioned density based solvers, hence my Riemann invariants are not, in general, the ideal gas ones

[FMDenaro]

Paolo, after 25 years I did'nt find my fortran source code to check exactly the BCs I implemented.
I try to remember what I did...


From p0 and T0 you have only rho0 and a0. In a 2D case, you need to know 3 conditions and let one free. Let us assume alpha=0, that is the vertical velocity component is zero. Therefore, density, x-momentum and total energy are the variables to work on.
You have no information about the inlet Mach number and the x-velocity, right?
I remember to have tried in extrapolating differente variables, tried density, tried x-velocity, I am not able to remember exactly the best combination I obtained.

If I am able to find some old document I will check ...

[Eifoehn4]

Originally Posted by sbaffini

I probably misguided you by using a Fluent based nomenclature.

What I am referring to is, exactly, a total pressure bc. That is, I know total pressure P0 and total temperature T0 at inlet. How do I obtain static pressure Ps and temperature Ts and velocity magnitude V at inlet? Note that I can't compute density before having Ps and Ts.

I am aware of the FUN3D papers but they seem to use a different bc, similar to the pressure far field one in Fluent nomenclature. Also, that doesn't directly apply to my case, as I use a preconditioned density based solvers, hence my Riemann invariants are not, in general, the ideal gas ones

I see, good luck anyway.

[sbaffini]

Originally Posted by FMDenaro

Paolo, after 25 years I did'nt find my fortran source code to check exactly the BCs I implemented.
I try to remember what I did...


From p0 and T0 you have only rho0 and a0. In a 2D case, you need to know 3 conditions and let one free. Let us assume alpha=0, that is the vertical velocity component is zero. Therefore, density, x-momentum and total energy are the variables to work on.
You have no information about the inlet Mach number and the x-velocity, right?
I remember to have tried in extrapolating differente variables, tried density, tried x-velocity, I am not able to remember exactly the best combination I obtained.

If I am able to find some old document I will check ...

Thanks, I have indeed also tried several combinations (note however that I cannot work with sound speed or density in my code, as preconditioning and my choice of independent variables makes them hard to work with).

In my first post I mention extrapolating both static pressure and velocity/Mach, but...

... for pressure, without limiting, I end up with a relation that can lead to negative numbers under a square root. Hence my current solution is to extrapolate pressure within the assigned total one at inlet (exactly as it is done in the TLNS3D nasa code). So, I was wondering if anyone had the same problem.

...for mach extrapolation, the compressible case is ok, but I cannot apply the same for the incompressible case (i.e
, velocity extrapolation). That is, I need a limiting on the dynamic pressure, otherwise I can get a negative static pressure. I still have this bc, but I labeled differently and I only use it for compressible cases)

[FMDenaro]

Originally Posted by sbaffini

Thanks, I have indeed also tried several combinations (note however that I cannot work with sound speed or density in my code, as preconditioning and my choice of independent variables makes them hard to work with).

In my first post I mention extrapolating both static pressure and velocity/Mach, but...

... for pressure, without limiting, I end up with a relation that can lead to negative numbers under a square root. Hence my current solution is to extrapolate pressure within the assigned total one at inlet (exactly as it is done in the TLNS3D nasa code). So, I was wondering if anyone had the same problem.

...for mach extrapolation, the compressible case is ok, but I cannot apply the same for the incompressible case (i.e
, velocity extrapolation). That is, I need a limiting on the dynamic pressure, otherwise I can get a negative static pressure. I still have this bc, but I labeled differently and I only use it for compressible cases)

Extrapolating velocity should work also for very very low Mach number, I tested my code for Mach below 0.1 using the conservative variables without any preconditioner.
But if you are speaking about a pure incompressibile formulation I don’t understand your issue…

[LuckyTran]

Please bear with my unfamiliarity with compressible density-based solvers and I'm also not sure how to go about it in a robust way for the actually incompressible Mach=0 case.

For real compressible gases I've done it with a coupled continuity-momentum approach using semi-arbitrary equation of states (in 1D). I did this exploration when I was modeling supercritical heat transfer. With inlet stagnation properties the only undetermined variable is the velocity, which is what you want. So you extrapolate the velocity (more correctly the momentum flux) to the inlet boundary using whatever is your scheme. The same works for inlet static properties except you have the obvious global well-posedness problems if you have inlet static and outlet static properties in a compressible case. There is still a little caveat in that there is locally possible a subsonic and supersonic solution for the inlet boundary. So for a commercial solver, it would be smart to add that check in the code somewhere. There is of course the more typical issue of getting shocks at the inlet because your initial guess was just poor and your calculation most likely diverges.

I've done this using various thermodynamic pairs: pressure & temperature, density & temperaure, enthalpy & entropy, etc. However, always I used a predictor-corrector approach (blatantly using Newton-Raphson everywhere) which makes these categorically more similar to "pressure-based" solvers and not a preconditioned density-based solver. It seems to me the challenge lies with the (preconditioned) density-based solver and/or how to handle the actual incompressible flow case?

Funny story I stopped tinkering with my code because Fluent added built-in support for NIST real gas models which had exactly the supercritical properties that I wanted. Star wasn't as nice, so I would use pre-tabulated properties.