# Common setup for p_rgh in complete open domains

 Register Blogs Members List Search Today's Posts Mark Forums Read

 February 9, 2017, 11:42 Common setup for p_rgh in complete open domains #1 Super Moderator     Tobias Holzmann Join Date: Oct 2010 Location: Tussenhausen Posts: 2,708 Blog Entries: 6 Rep Power: 51 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. wht likes this. __________________ Keep foaming, Tobias Holzmann

 February 12, 2017, 04:50 #2 Senior Member   Tom Fahner Join Date: Mar 2009 Location: Breda, Netherlands Posts: 638 Rep Power: 32 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 likes this.

 February 14, 2017, 02:34 #3 Super Moderator     Tobias Holzmann Join Date: Oct 2010 Location: Tussenhausen Posts: 2,708 Blog Entries: 6 Rep Power: 51 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. __________________ Keep foaming, Tobias Holzmann

 February 20, 2017, 07:42 #4 Super Moderator     Tobias Holzmann Join Date: Oct 2010 Location: Tussenhausen Posts: 2,708 Blog Entries: 6 Rep Power: 51 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. __________________ Keep foaming, Tobias Holzmann

 February 28, 2017, 05:50 #5 Senior Member   Join Date: Mar 2015 Posts: 250 Rep Power: 12 Hi Tobi, very interesting thread! Once I ran a similar case with Code: ```pressure: fixedValue velocity: zeroGradient``` Now I looked up the suggested pressureInletOutletVelocity BC: Code: ```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 Last edited by KateEisenhower; February 28, 2017 at 06:32. Reason: Formatting

 February 28, 2017, 06:09 #6 Super Moderator     Tobias Holzmann Join Date: Oct 2010 Location: Tussenhausen Posts: 2,708 Blog Entries: 6 Rep Power: 51 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). thiagopl, KateEisenhower, calf.Z and 2 others like this. __________________ Keep foaming, Tobias Holzmann

 February 28, 2017, 06:37 #7 Senior Member   Join Date: Mar 2015 Posts: 250 Rep Power: 12 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? Last edited by KateEisenhower; February 28, 2017 at 06:43. Reason: Addition

 February 28, 2017, 07:15 #8 Super Moderator     Tobias Holzmann Join Date: Oct 2010 Location: Tussenhausen Posts: 2,708 Blog Entries: 6 Rep Power: 51 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. __________________ Keep foaming, Tobias Holzmann

 March 1, 2017, 20:18 #9 New Member   Join Date: Jan 2017 Posts: 4 Rep Power: 9 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

 February 5, 2019, 09:07 #10 New Member   Join Date: Mar 2018 Posts: 10 Rep Power: 8 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. jherb, Tobi and Mondal131211 like this.

 June 28, 2019, 11:09 #11 Super Moderator     Tobias Holzmann Join Date: Oct 2010 Location: Tussenhausen Posts: 2,708 Blog Entries: 6 Rep Power: 51 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... __________________ Keep foaming, Tobias Holzmann

 December 3, 2019, 04:00 #12 Member   Join Date: Nov 2014 Posts: 92 Rep Power: 11 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 likes this.

April 25, 2020, 22:09
#13
Member

Hector
Join Date: Jul 2010
Location: Barcelona
Posts: 30
Rep Power: 15
Quote:
 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...

 June 4, 2020, 11:57 FixedFluxPressure - totalPressure combination #14 New Member   LouisDS Join Date: Dec 2019 Posts: 12 Rep Power: 6 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 Last edited by loewieke53; June 4, 2020 at 16:11.

 June 11, 2020, 06:32 #15 Super Moderator     Tobias Holzmann Join Date: Oct 2010 Location: Tussenhausen Posts: 2,708 Blog Entries: 6 Rep Power: 51 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 __________________ Keep foaming, Tobias Holzmann

 June 12, 2020, 01:30 #16 New Member   LouisDS Join Date: Dec 2019 Posts: 12 Rep Power: 6 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

 July 20, 2020, 03:56 #17 Super Moderator     Tobias Holzmann Join Date: Oct 2010 Location: Tussenhausen Posts: 2,708 Blog Entries: 6 Rep Power: 51 Hi Louis, why you need programming skills here? Both conditions can be applied directly to the patches. __________________ Keep foaming, Tobias Holzmann

 July 20, 2020, 05:42 #18 New Member   LouisDS Join Date: Dec 2019 Posts: 12 Rep Power: 6 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

 July 20, 2020, 08:07 #19 Super Moderator     Tobias Holzmann Join Date: Oct 2010 Location: Tussenhausen Posts: 2,708 Blog Entries: 6 Rep Power: 51 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. __________________ Keep foaming, Tobias Holzmann

September 14, 2020, 10:12
#20
Senior Member

Join Date: Jul 2019
Posts: 148
Rep Power: 6
Quote:
 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.

 Tags p_rgh open domain

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is On HTML code is OffTrackbacks are Off Pingbacks are On Refbacks are On Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post AS_Aero Pointwise & Gridgen 3 July 25, 2013 08:27 mfiandor OpenFOAM Installation 2 January 25, 2010 09:50 gschaider OpenFOAM Installation 113 December 2, 2009 10:23 hjasak OpenFOAM Post-Processing 69 April 24, 2008 01:24 matthias OpenFOAM Installation 20 March 25, 2008 02:36

All times are GMT -4. The time now is 01:47.