[Schag]

Hi all,

quite new to openFOAM, I'm trying to simulate a flow through a channel with rasInterFoam.
My issue comes from the fact that the air flow above water surface quickly gets high velocity magnitudes, and I don't really understand why.

A quick review of my case:
a 140m channel with a vertical pile in the middle.
I have slip conditions on sides, velocity inlet for water with hydrostatic pressure at outlet.
For air, the top of my domain is totalPressure for pd and pressureInletOutletVelocity for U. I have zeroGradient conditions on pd and U for vertical air boundary conditions (above inlet and outlet of water).

Do you have any idea, advices?

Thanks a lot

Regards,

Julien

[martinr]

Hi Julien,

Have you found any explanation to the air velocity behaviour? I ask you because I have got the same problem and I am a bit lost.

Greetings
Martin

[pauls]

Hello Martin and Julien,
I had similar problems. Searching this forum I found that all OpenFOAM solvers are unstable for this setup. The source of instability seems to be the density contrast between air and water. Any momentum transfer across the interface generates a huge velocity jump.
Discussions show that no solution is available in OpenFOAM, and no attempts are made to find one. We are still using commercial codes for FSI including a water-air interface. I don't know what they a doing differently, but obviously there is a solution.

Paul

[myheroisalex]

Hello together,

I was dealing with the same trouble and for my setup the following BCs did the best Job:
For U at the atmo:
type pressureDirectedInletOutletVelocity;
value uniform (0 0 0);
inletDirection uniform (0 0 -1);
For pressure at atmo:
type fixedValue;
value uniform 0;
alpha1/gamma:
type inletOutlet;
inletValue uniform 0;
value uniform 0;

Just my two cents, maybe that helps

[pauls]

Just my two cents, maybe that helps

Thanks, but still the rasInterFoam solver speeds up the air above the interface to about 1000 times the velocity of the water below the interface, if the water surface develops waves.

Maybe you can upload a complete case directory, showing your successful run? Did you integrate for sufficiently long periods, or just a few seconds?

Paul

[myheroisalex]

Hi Paul,

I am dealing with a moving box ('ship') in another box('water/air-domain').
When I first set up a case for the (simple) situation that the ship does not move at all, i got somehow crazy velocities in the air domain (~10m/s after 1s time).
The BCs I posted above do not totally remove that problem, but I now have velocities about 0.03 m/s after 1s time.
My experience then is that every additional function you want to use let those strange velocities grow and grow (In my case mesh movement). Because the mesh movement didnt not work very good for me (again strange velocities, but now due to mesh motion) I didnt simulate more than 1s of time.
The solver I used was interDyMFoam on OpenFOAM-1.6.

I uploaded the p and U-dictionaries for you: http://uploaded.to/?id=n2smuro7x9xrsj43rd5vnyi8epq8kq5w

[pauls]

I was dealing with the same trouble and for my setup the following BCs did the best Job:

Do you agree, that "the best Job" is not satisfying for any practical purposes? For the records, this problem is far from being solved.
Running a simulation for 1 second may be a step in the right direction, but obviously better stability is needed. Can anyone suggest ideas about what exactly causes this error and where to go for a solution?

Paul

[myheroisalex]

Originally Posted by pauls

Do you agree, that "the best Job" is not satisfying for any practical purposes?

From my point of view: yes. But there are a lot of much more experienced people here and somewhere I saw some setups and/or result-screenshots of wave generation, so it has to be possible in any way.
My experience with Ansys CFX, as an commercial solver, is that it is able to build a free surface model without unwanted velocities in the air domain.

[jcriner]

As a starting point, you may wish to try the following:

1. Have a look at U on your atmospheric patch (not the vol mesh, actually load the patch in Paraview). See if there is "checkerboarding" (regions of Uinlet and other regions where U = most likely zero).

2. If the answer to 1. is yes, and your inlet velocity is nominally parallel to your atmosphere patch, then have a look at what pressureInletOutletVelocity / pressureDirectedInletOutletVelocity are actually doing in the code based on flux phi, refValue, valueFraction, tangentialVelocity, and inletDirection. You may find that your inlet velocity is tangent to your atmosphere patch and when the flux is numerically out it sets zero gradient, and when the flux is numerically in it is setting the tangential velocity to some value (0???) inconsistent with your inlet U. If so, that certainly isn't helping things although it may not solve all of your problems.

James

[bigred]

I'm not sure if this helps or is applicable, but I just skimmed through the funkySetFields utility, that may help out. http://openfoamwiki.net/index.php/Co...funkySetFields
see section 3.2.2

[pauls]

bigred, funkySetFields has nothing to do with the problem.
FunkySetFields is used for the initial conditions.
Velocities explode during the integration independent of initial conditions.

Paul

[wes1204]

I also got same problem.

I am simulating curved open channel to capture secondary current at apex of curve.

actually air velocity structure is out of my concern.

but problem is that high velocity of air above free surface make large turbulent stress near by free surface and it affect to secondary flow of water.

this high velocity of air is physically not correct in my view.

anybody who solved the problem please give advise