[Tobi]

Dear FOAM'er,

I am always wondering, if there is a common setup for U and p_rgh for an complete open domain. E.g.: We have a air domain (1m^3) and put a hot steel plate into the middle. Due to natural convection we get a flow. The boundaries of the air domain should be as ... ? I already found some working set-ups which also make sense in the mathematical point of view (in my opinion) but the pressure residuals for p_rgh is always between 0.1 and 0.01. I think there are already some people out here, who did something like that and have more experience than me. In fact the 6 sides of the airi domain should have somehow the following:

• Atmospheric pressure everywhere
• Velocity should be based on the pressure field

At the moment I have the total pressure for p_rgh set to 1e5 everywhere and the velocities are treated with the pressureInletOutletVelocity boundary condition. However, even if it makes sense to me, the numerical system seems not to be very happy about the choice of my boundary conditions. I will let it run through the night and see how it will run. Another option that is much faster (dt) is to set up the case as following:

• Side walls of the air domain -> slip + fixedFluxPressure
• Top patch fixedValue for p_rgh (1e5) and inletOutlet for U
• Bottom patch totalPressure (p0 1e5) and an pressure inlet bc for U

However, the p_rgh is still somewhere between 0.1 and 0.01. It might be okay in that case but I am not really happy about that.

[tomf]

Hi Tobi,

I vaguely remember doing something similar some time ago where I used totalPressure (all 1e5) + pressureInletOutletVelocity on all open domain boundaries. I know at least that the result was satisfactory visually, do not remember the residual behavior.

Cheers,
Tom

[Tobi]

Hi Tom,

thank you for your reply. I checked your BC (as they were my first suggestion too) but the problem is with the outflow. Based on the totalPressure BC, the faces for p_rgh are always set to a fixed value, which is not realistic. However, I changed it to fixedFluxPressure with pressureInletOutletVelocity. Here it seems okay first but based on the fact that I get somehow a small inflow on the top and based on the fact that the pressure on the inflow faces are not been reduced like (p_rgh - 1/2 rho U^2), I get an acceleration till my simulation crashes. Well, now I made the outlet being a inletOutlet which does not seem so correct but we will see. I keep you updated. In my opinion we need at the top something like fixedFluxPressure for the outflow and some decrease of the pressure based on the velocities if we have inflow. So a combination of totalPressure + fixedFluxPressure. Well, I might do it in that way - we will see.

[Tobi]

Update:

the top patch was used with fixedFlux and inletOutlet while keeping the inletValue zero. This is reliable for Pressure and Velocity. However, as I already stated, the best way would be an own BC which makes a fixedFluxPressure for outflow and a totalPressure for inflow.

[KateEisenhower]

Hi Tobi,

very interesting thread! Once I ran a similar case with

pressure: fixedValue
velocity: zeroGradient

Now I looked up the suggested pressureInletOutletVelocity BC:

Description                           
This velocity inlet/outlet boundary condition is applied to pressureboundaries where the pressure is specified.  A zero-gradient condition is applied for outflow (as defined by the flux); for inflow, the velocity is obtained from the patch-face normal component of the internal-cell value.

My understanding up to now was, that zeroGradient is doing exactly the same. Can you clarify this?

Best regards,

Kate

[Tobi]

Hi Kate,

first of all thank you for the reply. I am not 100% sure in the case here but first of all, if you specify the p_rgh with fixedValue, and U with pressureInletOutletVelocity you will get problems, if you have backflow (therefore the totalPressure should be used but is not physical here based on the wrong pressure if we have outflow - in my opinion). Okay, lets just assume a case where you cool a part in the middle of your domain based on free convection:

• The fluid gets hotter -> the density lower and you get the buoyancy force which is directed upwards
• p_rgh is the pressure without the hydrostatic part but if we accelerate the fluid, this value will decrease, too.
• If we follow the fluid upwards to the top patch we would have the following szenario (at least I had it). p_rgh decreases based on the reduce of kinematic pressure (1/2 U^2 rho) but only in the cells where I had a fluid flowing upwards
• Now if we set p_rgh to be fixed, you will have a discrepancy at the boundary face and the cell center value of p_rgh. The boundary patch has a fixed value while the cell center one is the reduced one based on flow (which is lower).
• Now using a pressureInletOutletVelocity it follows that the flux is based on the pressure boundary condition and the cell center of corresponding cell.
• The boundary face has a higher p_rgh value than the cell center. So we get a dp which is inwards directed.
• I observed that depending on the pressure drop, I got an inflow which is a problem because with an inflow you should decrease the pressure at each face too (like the totalPressure BC is doing) in order to equilibrate the inflow to compensate the pressure difference.
• In my configuration, the pressure drop did not vanish based on the fixedValue p_rgh boundary and my fluid was always accelerating inwards (based on dp).
• This was done till my system blow up

I am not sure about that but it was my interpretation of the behavior of the system and an analyze of the pressure and velocity values. That's why I was asking that we need like a fixedFluxPressure for outflow and and totalPressure behavior for inflow combined with the pressureInletOutletVelocity BC. I got rid of that problem by defining that there is no inflow allowed (inletOutlet) for U. However, in my case the top patch was close to the heated part which can also influence the system.

Any other ideas/analyzes are welcomed.
Personally the p field should be defined as fixed or totalPressure but I did not checked it if it is possible and will lead to reliable results.

PS: pressureInletOutletVelocity behaves like an zeroGradient if we have outflow (face center value is equal to the cell center one) but if we have inflow it is based on the pressure difference from the face center to cell center (as far as I got it).

[KateEisenhower]

Thank you! This post is really helpful.

I should have mentioned that my case is an incompressible one. The movement of the fluid is because of objects moving inside the domain. That is why you don't know where the fluid is entering and where it is leaving the domain.

Best regards,

Kate

Edit: Regarding your PS: What is zeroGradient doing then when we have inflow?

[Tobi]

Hey Kate,

well zeroGradient is just no gradient between face center and cell center. At least the normal component for vector quantities should be similar. And of course, your system could be different and therefore the fixedValue + zeroGradient is appropriate. My driving force was the buoyancy and due to the fact that this kind of problems (everywhere an opened domain) is a bit tricky to model based on the numerical system, I just wanted to ask if someone could give me some advise about that. At the end I made my own conclusion, if it is right I am not 100% sure.

[j91]

Hi,

As I don't know the intricacies of all these boundary conditions, I'm having a little trouble following. However, am I correct in my assumption that the problems you're describing here are mostly encountered when dealing with free convection problems where flow velocity is governed by temperature (density) differences?

Thanks,
Jonathan

[Mcesar]

I simulated an open domain in buoyantBoussinesqSimpleFoam (free convection case) with the open boundaries set as fixedMean to p_rgh and pressureInletOutlet for velocity. It worked well, and p_rgh residual achieved 10^-4.

[Tobi]

Hi Mcesar,

interesting point. I have the same problematic again, and your bc works at the beginning till it crashes. In any case, deactivating the gravity force results in a working case but the pressure p_rgh is uniform everywhere which makes kind of sense but the physical component - bouyancy - is missing.

Hmm...

[hokhay]

Hi Tobi,
I am facing the same problem as well. Have you found the perfect solution already? Could you please clarify your finding?

Jason

[hectorgabriel85]

Originally Posted by Tobi

Hi Mcesar,

interesting point. I have the same problematic again, and your bc works at the beginning till it crashes. In any case, deactivating the gravity force results in a working case but the pressure p_rgh is uniform everywhere which makes kind of sense but the physical component - bouyancy - is missing.

Hmm...

Hi, I adhere to hockay

[loewieke53]

Hi Tobi,

I am dealing with the exact same problem and I was also thinking to create a boundary condition for the pressure which combines totalpressure (inflow) en fixedFluxPressure (outflow). This is when I found this thread. Did this idea work for you?

Kind regards,

Louis

[Tobi]

Hi,


I never investigated into that problem anymore and I believe it still persists. I am not sure how advanced users are setting up the system here. Good luck anyway (any solution is warmly welcomed).

Tobi

[loewieke53]

Hi,

I am almost 100% sure that the combination of fixedFluxPressure (outlet) and totalPressure (inflow) would fix the problem. I am however too unexperienced in C++ to create such a BC and test it. Do you know someone who could help me?

Kind regards,

Louis

[Tobi]

Hi Louis,

why you need programming skills here? Both conditions can be applied directly to the patches.

[loewieke53]

Hi Tobi,

Is there a way to apply two boundary conditions at one patch, where the one BC will be used during an outward flux and the other one during an inward flux? I thought this was only possible by programming a new boundary condition.

Kind regards,

Louis

[Tobi]

Ah you were talking about the fluxes at one patch (you mentioned outlet and inflow). The totalPressure applies a fixedValue (maybe a fixedFluxPressure) at outflow while for inflow, it adjusts the pressure at each face according to the velocity.

[Bodo1993]

Originally Posted by Tobi

Hi Mcesar,

interesting point. I have the same problematic again, and your bc works at the beginning till it crashes. In any case, deactivating the gravity force results in a working case but the pressure p_rgh is uniform everywhere which makes kind of sense but the physical component - bouyancy - is missing.

Hmm...

Hi Tobi,

I encounter the same problem in twoLiquidMixingFoam, a solver for two miscible incompressible fluids. In this solver, the mixture density is interpolated linearly (not a constant value). I face the issue of backflow regularly in my simulations. I start to notice the effect once the mixed phase reaches the outlet boundary. I have tried almost all combinations of the outlet and inlet boundaries, but the problem persists. As you mentioned, when I turn the gravity off, I do not observe a back flow. It tells me that there is an issue with the buoyancy term here. I wish there is a solution for this problem and I am wondering if it is a bug in the solver.

I would greatly appreciate your thoughts and suggestions.