CFD Online Discussion Forums

CFD Online Discussion Forums (
-   OpenFOAM (
-   -   unbounded reversed flow on outlets (

kwardle May 8, 2009 16:08

unbounded reversed flow on outlets
I have had problems with unbounded reversed flow on outlet boundaries in a number of different simulations I have tried using interFoam and interDyMFoam--particularly in rotating domains.

One example. I have been trying to set up a rotating domain problem using GGI. The general geometry is similar to the one described in another post for using MRF ( except that there are multiple radial outlets from the rotating portion. I have tried a variety of different outlet types for U (pressureInletOutletVelocity, intletOutlet, zeroGradient, fixedValue) and pd (totalPressure, fixededValue ) on these boundaries and get pretty much the same behavior every time. The solution appears to go as normal for a few time steps and then the velocity begins to blow up--but still converge--until the magnitude of the velocity gets too high. Looking at the results in paraview, I see that it is the inward velocity on the outlets that is to blame. I have tried using very small time steps (~1e-7) and a variety of solutions schemes as well as upwinding. I have also explored different meshes, and reproduced the same behavior using sliding mesh instead of GGI. It seems this is a BC issue.

I have tried initializing from a uniformly rotating field and gotten the exact same behavior. It would seem that setting an outlet boundary condition for U of inletOutlet with an inletValue of (0 0 0) should impose a limit on reversed flow. In my experience, it has absolutely no effect which is quite confusing.

I have also worked a lot with Fluent and somewhat with Star-CD and Star-CCM+ for similar simulations and in general, openFoam seems to be much more sensitive to reversed flow and blows up very easily in these conditions. What are the commercial codes doing differently to deal with reversed flow? How can I get a solution using OpenFOAM for such cases?

Any insight would be very much appreciated. Thanks.

mabinty May 15, 2009 10:20

Hi Kent!

I have the same problem as you describe even though I m working on another problem (see Was it already possible for you to find a solution for that??


kwardle May 15, 2009 11:31

No I have not, but I really need one. I am pretty certain that this is a common complaint as I have heard it from others--it seems that OF is very sensitive to reversed flow--and I really hope that someone out there can (and is willing to) address this.

hjasak May 16, 2009 02:12

Why don't you slap an inletOutlet boundary condition on U and kill the back-flow; otherwise, use a total pressure boundary condition at the outlet, which will stabilise things for you.


mabinty May 16, 2009 03:16


What my case concerns I have an "open" boundary where hot air exits at the top and ambient air at the lower part of the boundary. Hence I prescribed pressureDirectedInletOutletVelocity for U and experimented with the BCs for p (calculated, fixedValue, outletInlet, totalPressure) and pd (fixedFluxBouyandPressure, zeroGradient). But everytime the in-comming velocity blows up; beside this also the values for k and epsilon (standard k-eps) constantly increase.

Thx in advance for any comments!

kwardle May 18, 2009 09:38

Thanks for the suggestions. Unfortunately, as I mentioned in the original post I have tried this and for some reason it does not work. If the inletOutlet BC is used with an inletValue of (0 0 0) then there should not be any inflow, right? Any inward directed flow would be stopped. For some strange reason this does not work for one case I am working on. In my simplified version the inletOutlet BC works fine, but in my more complex geometry the inflow still happens and blows things up. I have tried to use a totalPressure BC in combination with a pressureInletOutletVelocity and gotten the same problem. I thought maybe it was a mesh problem, but the mesh checks out with no errors and I have also tried from scratch with other meshes (the original one is converted from a Gambit .msh)

It may also be that this is a problem with using GGI for the rotating region--but as you said after the webcast last Thurs, this shouldn't be the problem. Even so, my geometry does not require GGI and I could get by with MRF but unfortunately I don't have a working MRFinterFoam solver... I get the smae behavior with sliding mesh too.

Note the the outlets (there are two separate patches each with four distinct channels) are all oriented normal to the rotation axis. Not sure if this complicates things.

What really baffles me is that I get the same behavior if I set the rotation speed to 0.1, 1, 10, 100 rpm. (I actually need the solution for > 3000 rpm). This makes me think it is a solution convergence problem, but everything is converging fine--just to a blown up solution. I tried changing a few things in fvSolution, but to no avail.

Any help would be very much appreciated.

mabinty May 18, 2009 10:47


Finally I was able to reach a stable calculation (see

Best regards,

kwardle May 18, 2009 15:23

I looked closer at the results and with inletOutlet BCs what I am actually getting is oscillatory behavior the flow is out at first and then in, then out, etc. -- oscillating and growing with each time step after the first 5 or so which seem stable. I also tried to use the fixedMeanValue BC that Aram mentions worked for him--same behavior. Something must be wrong with my case but I can't seem to find it.

All times are GMT -4. The time now is 18:12.