[DanM]

Hello,

I am using OpenFOAM-2.0 to model a channel flow with the interFOAM solver. The set up is very simple: The model consists of a 400m long, 55m high channel filled about 2/3 with water, while the top phase is air. The boundary conditions are as follows:

INLET
U: 1m/s current for the water phase
alpha: zeroGradient
p_rgh: zeroGradient

OUTLET
U: zeroGradient
alpha: zeroGradient
p_rgh: totalPressure/fixedValue/inletOutlet

Unfortunately I have not been able to determine outlet boundary conditions for p_rgh that lead to physical results. I have made the following observations:

When using totalPressure (or fixedValue) the water phase at the outlet decreases significantly in the outlet region (see picture1). On the other hand, inletOutler conditions for p_rgh at the outlet cause high unphysical fluctuations in the velocity profile while the channel seems to fill up with the water phase as shown in picture2.

I have also tried pressureInletOutletVelocity for U at the outlet without any success.

I also found that when specifying the whole domain as one single phase the results do converge towards 1 in the whole domain when using interFoam.

Has someone been able to attain physical results for a multiphase channel flow using interFOAM? I would appreciate any kind of help! Thanks a lot,

Dan

[mgdenno]

DanM,

Here is what I do (I am still kind of new to this but have had some success):

I have been breaking the inlet in to 2 sections, one for the water (alpha = 1) (the lower 2/3 in your case) and one for air (alpha =0)(top 1/3). This controls the water level at the inlet boundary. I just recently noticed that the wigleyHull example uses calculated for alpha for the inlet which may make this not necessary but I haven't tried it yet.

Inlet:
U: fixedValue is good
alpha: fixedValue = 1 (or maybe calculated)
p_rgh: buoyantPressure

Outlet:
U: inletOutlet or zeroGradient
alpha: inletOutlet or zeroGradient
p_rgh: inletOutlet or totalPressure

You may want to take a look at the wigleyHull example in LTSInterFoam.

Not sure how to make the water level stay at "normal depth" type solution at the downstream boundary. It hasn't impacted most of the cases I have been looking at. One thing you could do is extend the downstream boundary far enough downstream so that it doesn't impact the area you are interested in.

Hope that helps some,

MD

[Stephy]

Hello,

I have the same type of channel with an obstacle in it. I have my mesh .msh which is okay according to checkMesh (all tetrahedral).

I have not a long experience of OpenFOAM so the previous message was going a little bit too fast for me, I'm sorry.

So I converted my msh using fluentMeshToFoam in the DamBreak tutorial because I thought interfoam would be the good solver to use, and I chose laminar for simplicity purposes, hoping that soon I will be able to deal with turbulence.

My mesh is simple:
one lower inlet for water (defined as velocity inlet with Gambit),
one higher inlet for air (pressure inlet with Gambit),
two side walls, the floor wall, and the top wall,
one lower outlet for water (pressure outlet with Gambit),
one higher outlet for air (pressure outlet with Gambit),
one closed obstacle made of walls.

What do you think of my boundaries under Gambit ?

on the generated mesh in openfoam I have either "patch" or "wall" for their types.

What should I do next ? completely modify "U" and "p" to put those boundaries and their type and the value of U and p ?

Thanks!!

[DanM]

Thanks for the reply MD! I have tried specifying alpha for the different phases individually but unfortunately without success. When using totalPressure conditions for p_rgh at the outlet, disturbances at the inlet result when the channel fills up (see picture 3). On the other hand, when using inletOutlet as an outlet condition for p_rgh, the unphysical outlet behavior dominates to the extend that the channel still empties (see picture 4). Here the simulation actually crashes when the water phase begins to sink significantly at the inlet.

Unfortunately elongating the channel is not an option for me. I'm running wave simulations on top of the current and need a few wave periods until I reach convergence (which mounts up to about 50s of simulated time). By then the channel has practically run empty with any kind of length that is still feasible.

I took a quick look at the boundary conditions of the LESinterFOAM case and couldn't find anything new in there. I will investigate further if similar effects occur there.

About Stephy's post:

I'm not quite sure I understand your problem correctly:

Originally Posted by Stephy

I converted my msh using fluentMeshToFoam in the DamBreak tutorial because I thought interfoam would be the good solver to use.

Why do you have to convert the mesh from the DamBreak tutorial? The mesh is already in the correct format in the tutorial, isn't it?

Concerning:

Originally Posted by Stephy

What do you think of my boundaries under Gambit ? on the generated mesh in openfoam I have either "patch" or "wall" for their types.

Your two side walls, the floor wall, the top wall, and the obstacle should be defined as "wall", the rest are patches. If your case is 2D you should define the sides as "slip".

[Stephy]

Thanks for you answer !

Concerning the Dambreak, I was just saying that I took the mesh I made for my case (obstacle partially submerged in a channel) and I put it in the folder of the dambreak, and inside this folder I launch the terminal and convert my mesh (which is in msh format out of Gambit) using fluentMeshToFoam (and then a checkMesh says my mesh is correct, I wanted to make sure of that too). I just thought it was a good idea to put it there so then I can adapt the other files of the initial Dambreak to make everything work in my system, I just did not want to start everything from scratch.

But basically, I only have my mesh .msh ready to go with the correct BC defined with Gambit. What is the best to do next ?
I know I have to fill in the correct U, p, and alpha (and something else ?) files in "0" according to my mesh and boundary conditions, but I'm not quite sure of how to do that... espically with the free surface flow thing and the separation between air and water...

Could you help me please ? thanks a lot !

[DanM]

I would suggest the following tutorial which describes step by step how to set up a free surface flow using the interFoam solver:

http://www.tfd.chalmers.se/~hani/kurser/OS_CFD_2007/HassanHemida/Hassan_Hemida_VOF.pdf

Since you are interested in a channel flow you need to alter your inlet and outlet conditions according to your needs. Just refer to what I posted in this thread for possible boundary conditions and let me know if you have any further question. Regarding outlet conditions for an interFoam channel flow I hope that this thread will eventually lead to a solution.

[mgdenno]

Originally Posted by DanM

If your case is 2D you should define the sides as "slip".

I read somewhere that for 2D cases you want to set the faces paralell to flow as empty, not slip, which is consistent with the tutorials.

Stephy,

Not sure what stage you are at, but after you convert your mesh I would look in the constant/polyMesh/boundary file to see how the faces imported. From there you can change the patch type (i.e. wall, patch, symmetry, etc). Then for each defined patch in that file you need to specify a boundary condition in your U, p_rgh, and alpha.

[Stephy]

my boundary file is like this:

FoamFile
{
version 2.0;
format ascii;
class polyBoundaryMesh;
location "constant/polyMesh";
object boundary;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

7
(
outletair
{
type patch;
nFaces 342;
startFace 314511;
}
inletair
{
type patch;
nFaces 336;
startFace 314853;
}
outletwater
{
type patch;
nFaces 340;
startFace 315189;
}
inletwater
{
type patch;
nFaces 336;
startFace 315529;
}
top
{
type wall;
nFaces 3834;
startFace 315865;
}
obstacle
{
type wall;
nFaces 1960;
startFace 319699;
}
parois
{
type wall;
nFaces 11794;
startFace 321659;
}
)

// ************************************************** *********************** //

"parois" meaning side walls and bottom,
top being the "ceiling".

Then, I want some flow coming in through the inletwater and going out through the outlets (outletair and outletwater). I just want air above that so I guesse my inletair is just a free inlet with no flow of air.

what should be the "type" of each of those 7 boundaries in the "U", the "p_rgh" and "alpha1.org" files ? right now I have the following:

For U:
FoamFile
{
version 2.0;
format ascii;
class volVectorField;
location "0";
object U;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions [0 1 -1 0 0 0 0];

internalField uniform (0.1 0 0.1);

boundaryField
{
outletair
{
type pressureInletOutletVelocity;
value uniform (0 0 0);
}
inletair
{
type pressureInletOutletVelocity;
value uniform (0 0 0);
}
outletwater
{
type pressureInletOutletVelocity;
value uniform (0 0 0);
}
inletwater
{
type fixedValue;
value uniform (0 0 1);
}
top
{
type pressureInletOutletVelocity;
value uniform (0 0 0);
}
obstacle
{
type fixedValue;
value uniform (0 0 0);
}
parois
{
type fixedValue;
value uniform (0 0 0);
}
defaultFaces
{
type empty;
}
}


// ************************************************** *********************** //




For p_rgh:
FoamFile
{
version 2.0;
format ascii;
class volScalarField;
object p_rgh;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions [1 -1 -2 0 0 0 0];

internalField uniform 0;

boundaryField
{
outletair
{
type totalPressure;
p0 uniform 0;
U U;
phi phi;
rho rho;
psi none;
gamma 1;
value uniform 0;
}
inletair
{
type totalPressure;
p0 uniform 0;
U U;
phi phi;
rho rho;
psi none;
gamma 1;
value uniform 0;
}
outletwater
{
type totalPressure;
p0 uniform 0;
U U;
phi phi;
rho rho;
psi none;
gamma 4;
value uniform 0;
}
inletwater
{
type totalPressure;
p0 uniform 0;
U U;
phi phi;
rho rho;
psi none;
gamma 4;
value uniform 0;
}
top
{
type totalPressure;
p0 uniform 0;
U U;
phi phi;
rho rho;
psi none;
gamma 4;
value uniform 0;
}
obstacle
{
type buoyantPressure;
value uniform 0;
}
parois
{
type buoyantPressure;
value uniform 0;
}
defaultFaces
{
type empty;
}
}

// ************************************************** *********************** //



and for alpha1:
FoamFile
{
version 2.0;
format ascii;
class volScalarField;
object alpha;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions [0 0 0 0 0 0 0];

internalField uniform 0;

boundaryField
{
outletair
{
type inletOutlet;
inletValue uniform 0;
value uniform 0;
}
inletair
{
type inletOutlet;
inletValue uniform 0;
value uniform 0;
}
outletwater
{
type inletOutlet;
inletValue uniform 0;
value uniform 0;
}
inletwater
{
type inletOutlet;
inletValue uniform 1;
value uniform 1;
}
top
{
type inletOutlet;
inletValue uniform 0;
value uniform 0;
}
obstacle
{
type zeroGradient;
}
parois
{
type zeroGradient;
}

defaultFaces
{
type empty;
}
}

// ************************************************** *********************** //



which does not work. when typing "interFoam", I am getting:
Create time

Create mesh for time = 0


PIMPLE: Operating solver in PISO mode

Reading field p_rgh

Reading field alpha1



--> FOAM FATAL IO ERROR:
cannot find file

file: /home/alex/OpenFOAM/alex-2.0.0/run/tutorials/multiphase/interFoam/laminar/dam2/0/alpha1 at line 0.

From function regIOobject::readStream()
in file db/regIOobject/regIOobjectRead.C at line 73.

FOAM exiting

[Stephy]

oops sorry, to fixed this fatal error I actually renamed alpha1.org to alpha1 and then type interFoam launches the computations.

However, could you give me your opinion concerning my files U, p_rgh and alpha1 ? I did not really know how to fill them so I am sure the computation is going to show weird results if its does not simply crash...

[Stephy]

Does anybody have any idea or suggestion on how to make this work ?

[mgdenno]

Stephy,

Take a look at this thread:

http://www.cfd-online.com/Forums/ope...lowing-up.html

It contains a working set of boundary conditions for channel flow. There are probably other examples in the forums too, but I am familiar with this one. In this thread, the issue was with my fvSchemes, not my boundary conditions.

Good luck!

MD

[DanM]

I would like to steer this thread back to the original discussion related to the unphysical behavior within the channel, heavily influenced by the outflow boundary conditions. As advised by MD, I took a look at the LTSInterFoam and was able to successfully apply it to my channel set up and run it with the standard interFoam solver (thanks a lot for the hint!). The problem seems to be not only related to the boundary conditions, but also the initial field conditions are crucial. As seen in the velocity file of the LTSInterFoam case, a uniform velocity of 1m/s is prescribed to the field in the x-direction as an initial condition. I set up two cases, one with a specified internalField of (1 0 0) and a second case where the initial internalField is set to (0 0 0). Otherwise the setup of both cases is absolutely identical. The results of the velocity field within the channel are shown in picture5. As can be seen, the water phase does not remain at a constant level when the initial field is set to 0, and the velocity profile does not converge to a constant value. Conversely, the set up with initial condition (1 0 0) for the internalField renders excellent results both related to the conservation of the phases and the velocity profile in the channel. To summarize, here the conditions used to attain these results:

U
internalField: uniform (1 0 0)
inlet: uniform velocity of 1m/s in the x-direction
outlet: zeroGradient
top: pressureInletOutletVelocity
any wall: no slip

p_rgh
inlet: bouyantPressure
outlet: zeroGradient
top: totalPressure
any wall: buoyantPressure

alpha1
inlet: calculated
outlet: zeroGradient
top: inletOutlet
any wall: zeroGradient

nut
internalField: uniform 5e-07
inlet: fixedValue uniform 5e-07
outlet: zeroGradient
top: zeroGradient
any wall: nutkWallFunction

omega
internalField: uniform “user value”
inlet: fixedValue
outlet: inletOutlet
top: inletOutlet
any wall: omegaWallFunction

k
internalField: uniform “user value”
inlet: fixedValue
outlet: zeroGradient
top: inletOutlet
any wall: kqRWallFunction

[mgdenno]

Thanks for sharing your findings. That is interesting. You can also set the velocity field using setFields (i.e. if you only wanted to set the water velocity).

[PeMo]

Hey Dan,

just find your thread. I was facing exact the same problems by setting the BC for an open channel flow (OF 2.0). I had the reverse conditions for the pressure inlet (zeroGradient) and outlet (buoyant pressure) which leads to quite the same results. Also I initialized the internal Field with the setField option (or later with the potentialFoam solver for my final goal an open channel curve in 3D). However first I am still fighting with some bc problems.
My results are always showing sth. which looks like a reflection of the outlet BC. This phenomena disappears if I enlarge the cell size (10mm to 20mm for the shown 4m x 0.8m area). I am not quite sure but i dont think this is a physical appearance, cause this disturbance is traveling upstream, which should be impossible for a supercritical flow (v=4.7m/s, Fr=3).
This is similar to your basic problems (picture 4). Did you move further in the meanwhile, or are your facing similar problems?

(Also a additional attached region with a coarse net, as suggested in numerical wave tanks to damp the waves didn't solve the problem)

Hopefully you or other experts could give me a hint how to proceed.

Thanks in advanced

Peter

[WSc]

Hi Peter,

I had a similar problem. I could fix it by reducing the time step.

Regards,
Wolfgang

[PeMo]

Thanks Wolfgang for your response,
reducing the time step didn't help in my case, I solved it through playing around (and reducing) the interface compression (cAlpha). Of course this smeared the surface a bit, but in order of cell size, so its workable for me.

P.

[kflora]

Originally Posted by DanM

The problem seems to be not only related to the boundary conditions, but also the initial field conditions are crucial. As seen in the velocity file of the LTSInterFoam case, a uniform velocity of 1m/s is prescribed to the field in the x-direction as an initial condition. I set up two cases, one with a specified internalField of (1 0 0) and a second case where the initial internalField is set to (0 0 0). Otherwise the setup of both cases is absolutely identical. The results of the velocity field within the channel are shown in picture5. As can be seen, the water phase does not remain at a constant level when the initial field is set to 0, and the velocity profile does not converge to a constant value. Conversely, the set up with initial condition (1 0 0) for the internalField renders excellent results both related to the conservation of the phases and the velocity profile in the channel. To summarize, here the conditions used to attain these results:

U
internalField: uniform (1 0 0)
inlet: uniform velocity of 1m/s in the x-direction
outlet: zeroGradient
top: pressureInletOutletVelocity
any wall: no slip

p_rgh
inlet: bouyantPressure
outlet: zeroGradient
top: totalPressure
any wall: buoyantPressure

Dan,

I just found your post after making a post for a similar situation myself http://www.cfd-online.com/Forums/openfoam/97987-setting-bcs-riverine-flows-using-interfoam-new-post.html.
What I have found is that when you use the zeroGradient for the outlet velocity BC, then if your initial conditions are very accurate for your given flow rate then the outflow will match the inflow and the WSEL will be stable; however, if this is not the case then it will change. To compound the problem is when your inlet is not entirely submerged and your initial internal velocities are off, then if the water surface adjusts (down or up) enough to change the water level at the inlet, the mass flow rate will then change and you could end up in a loop where you either end up with no flow or no air left.

I'm curious if you resolved this issue to your satisfaction or if you (or anyone else) has any input for my post.

Kevin

[mgdenno]

Kevin,

I experienced the problem you describe regarding the water level going up or down at the inlet if the internal velocity was not just right. I have had reasonable success dealing with this by breaking the "inlet" face into two separate patches that I name "inlet" and "aboveInlet" with the top edge of "inlet" patch near the expected water surface elevation. I then set alpha1 = 1 for the "inlet" patch and alpha1 = 0 for "aboveInlet" patch. This is not perfect but is the best I have found so far. I understand that with swak4Foam you can set the height of alpha1 = 1 to be at a specific elevation. I am planning to try this soon, but haven't had a chance to yet.

MD

[vonboett]

I currently work with
outlet
{
type buoyantPressure;// see interFoam/channel flow tutorial
value uniform 0;
}
in p_rgh and I can recommend it

[pedroxramos]

Hello there!

I'm working in a simulation of the flow around a cylinder in a open channel. The problem is very similar to this one. I can't have the correct water depth in the outlet.

Please, see the video: https://dl.dropboxusercontent.com/u/...ier9abril3.avi

What boundary condition you suggest for the outlet?

Best regards.