
[Sponsors] 
November 22, 2011, 13:37 
p_rgh issues with interFoam (2.0.x)

#1 
Member
Join Date: May 2009
Posts: 51
Rep Power: 9 
I am simulating a simple 2D laminar flow of a submerged cylinder near a freesurface (domain figure attached). After testing many pressure and velocity boundary conditions, I cannot obtain a reasonable p_rgh field with interFoam. The stagnation pressure should be somewhere around 500, but the p_rgh throughout the water fraction is orders of magnitude greater (see attached screenshot). If I set the gravity vector to zero, I get a reasonable p_rgh result where the stagnation pressure matches the expected value (see attached). Is this be due to the way the gravity term is treated in interFoam?
Some things I have tried in various combinations: pRefValue in both water and air and zeroGradient for p on boundaries buoyantPressure on the cylinder, outlet, both inlets totalPressure on the outlet and atmosphere fixedValue 0 for p on outlet extending the domain (the one pictured is ~100D upstream and downstream) cAlpha of 0, 1, 2 p_rgh and p_rghFinal relaxation factors of 0.3 and off cranking up the p tol to e12 orienting the mesh so that the g vector is either in y or z (desperation mode) I would appreciate any help. 

November 22, 2011, 14:03 

#2 
Senior Member
Niels Gjoel Jacobsen
Join Date: Mar 2009
Location: Deltares, Delft, The Netherlands
Posts: 1,693
Rep Power: 27 
Hi Grezgorz
Warning: Only using 1.6, but hope this helps anyway. Looking at your results, I can think of a possible reason. Is your free surface positioned at z = 0 m? In the momentum equation, the following will dominate the reference value of p_rgh In the case z = 0 m, then the term vanishes at the surface, which is the only place, where is nonzero. If z is nonzero, this results effectively in a excess pressure in the water column which differs zero and thus produce the depicted results. There are two possible solutions: 1. Move the free surface. 2. Substract some far field p_rgh from your field in e.g. paraView and check that the stagnation pressure is in the correct order of magnitude. Good luck, Niels 

November 22, 2011, 16:48 

#3 
Member
Join Date: May 2009
Posts: 51
Rep Power: 9 
Niels,
You are right, setting the fs at z=0 did the trick! Thank you very much. Greg 

April 17, 2012, 07:05 
problems with interFOAM

#4 
New Member
Sam Mathew
Join Date: Apr 2010
Location: India
Posts: 19
Rep Power: 8 
Hi,
I was trying a simple tank draining problem and was trying to specify the right boundary conditions. I am implementing my case in 2.1.0 and it is basically a tank with water filled up to a specific height with a small outlet port at the bottom center of the tank. At the top I gave the same boundary conditions as in the Dam_break case. I am having difficulty with specifying appropriate boundary conditions for the outlet port. I have been basically playing around with values for alpha, p_rgh and U. 1. For p_rgh = 0 (as suggested here): The water does not flow out of the domain. The other parameters were U = (0,0,0), zeroGradient and alpha = {InletOutlet}, 0. 2. For p_rgh  zeroGradient: The flow is going out but still the results are quite strange. While keeping alpha = {InletOutlet} and U  zeroGradient, the water suddenly jumps up and after a few time steps, it starts draining. It seems as if, the solver detects a high pressure at the outlet port and causes flow to occur from higher to lower pressure, but then realizes actually there is gravity acting against and then the liquid flows out. The reason I gave p_rgh to be zeroGradient is because I understood that it is the dynamic pressure and the dynamic pressure at the outlet cannot be zero but rather the normal gradient should be zero. I would be thankful for any help since I am not able to grasp yet the right implementation. In other solvers (like FLUENT, CFX), I would just specify the static pressure to be zero at the outlet with the possibility for reverse flow of air into the domain. 

April 17, 2012, 23:30 
p_rgh and initial velocity specification

#5 
New Member
Sam Mathew
Join Date: Apr 2010
Location: India
Posts: 19
Rep Power: 8 
Hi,
I was finally able to solve the problem using the second formulation but with a finer mesh. <This approach has finally been deduced to be wrong. Please read further down for the way I solved it.> I have another question with regard to the p_rgh formulation in OpenFOAM. If I want to specify some initial velocity in the fluid (e.g., due to rigid body motion of the tank), do I only need to specify it as the internal field in the U file or also the p_rgh file? Regards, Sam Last edited by SamCFD; April 23, 2012 at 00:38. 

April 19, 2012, 14:07 

#6 
New Member
Nikhil
Join Date: Sep 2011
Posts: 11
Rep Power: 6 
Hello Sam,
p_rgh is not dynamic pressure. It is defined as p_rgh = p  rho*gh (look up pEqn.H in interFoam). It is a variable constructed for numerical advantage. You have to specify the initial velocity in the U file only. Regards, Nikhil 

April 23, 2012, 00:36 
Re: p_rgh and initial velocity specification

#7 
New Member
Sam Mathew
Join Date: Apr 2010
Location: India
Posts: 19
Rep Power: 8 
Thanks Nikhil. I figured it out and have realized a more appropriate strategy for defining such problems.
The right approach is actually to define p_rgh as zero at the outlet. This is already explained in Dr. Rusche's PhD thesis. Actually, I observed that in VOF simulations, especially, if you have pressure B.C. at inlet and outlet it is helpful to patch one cell layer at the inlet/outlet (whichever is relevant) with the liquid phase fraction of 1 if it is entering the domain, or 0 if it is leaving the domain, respectively. I remembered that around 3 years ago, I got this strategy from one of the posts on the FLUENT forum while I was implementing a swirlinjector problem in FLUENT. There seems to be some commonality between the numerical codes as it worked now in OpenFOAM as well. Sam Last edited by SamCFD; April 23, 2012 at 00:52. 

Thread Tools  
Display Modes  


Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
InterFoam stops after deltaT goes to 1e14  francesco_b  OpenFOAM Running, Solving & CFD  8  July 31, 2013 02:29 
Segmentation fault in interFoam run through openMPI  voingiappone  OpenFOAM  16  November 2, 2011 07:49 
OpenFOAM 2.0.x libscotch issues  gfilip  OpenFOAM Installation  4  July 11, 2011 11:23 
Slow interFoam compared with other CFD tools?  Ralph M  OpenFOAM Programming & Development  1  November 17, 2010 07:46 
Open Channel Flow using InterFoam type solver  sxhdhi  OpenFOAM Running, Solving & CFD  3  May 5, 2009 21:58 