Outlet boundary condition for wave flume with interFoam solver
 

Dear Foamers,

for the simulation of waves and currents in a flume, I'm now struggling with the problem of the outlet boundary condition. Ideally, waves and currents shall just leave the modelling domain without generating any kind of reflections which would otherwise interfere with the next incoming waves in the flume.

I already read a lot of posts in this forum concerning this topic, but its still not clear to me what the best solution could be for such an outlet boundary condition - and esp. how to implement it. Some posted their ideas (sometimes already months ago), e.g. in the direction of a 'sponge layer'. But I'm not sure if the ideas worked or not. At the moment I'm using numerical absorption by an extended mesh, which works quite well for waves in the flume, but not for currents.
So, if those who already fixed this issue for their simulations and made their own boundary conditions could give a short comment on this, I would be glad!

Another (maybe stupid) question: My understanding of the zeroGradient boundary condition was that it sets the regarded value at the boundary patch equal to the near-patch cell value. Is this right?
My problem is: For modelling constant flow in the flume (no waves) I set p, U and alpha as zeroGradient for the outlet.
For U and alpha at the inlet, groovyBC was used with constant and uniform values. What I got in the simulation is that the water level in the flume rose during runtime, so there was no or at least not enough 'outflow'. Could anyone explain this to me?
I could fix this problem by setting U and alpha for both inlet and outlet using groovyBC - but this only works for constant flow and not for other situations or waves. Which leads to the first topic of a non-reflecting outlet bc...

Hoping to see some of the topics a bit clearer soon,

Arne

Hello Arnoldinho,

I am also struggling with similar issues in a two-phase flow, just a bit different geometry. Have you made any progress regarding the outlet boundaries? Any references perhaps?

Hi Robert,

may I lead you to http://www.cfd-online.com/Forums/ope...tml#post284589?! Nevertheless, no improvement so far... :confused:

Thanks for that! I was afraid that you will mention transmissive boundaries eventually which I believe are not coded in multiphase codes.

But please let also interest in a different post of mine:
http://www.cfd-online.com/Forums/mai...d-channel.html

I am doing 2D closed channel, so apart from increasing mesh size I was thinking of using two horizontal outlets. If set up properly they will become outlets for only one of the phases. But that workaround is not applicable in your case.

Robert, regarding your 2D channel, is this what you mean ? -> http://www.cfd-online.com/Forums/ope...interfoam.html

Hi Arne,

Have you solved the problem? If yes, can you please tell me how?:)

Cheers,
Albert

Hi Albert,

you could have a look at this thesis http://www.google.de/url?sa=t&source...VJ_amw&cad=rja, which has, with some modifications, also worked for most of my cases.

Arne

no ourflow with interFoam
 

...this might be some error on my side, but I did dozends of simulations both with setting type zeroGradient; for the outlet boundary condition in alpha1 as well as using type inletOutlet with inletValue uniform 0 for the atmosphere boundary, and both worked fine using OF 1.7.1 . But now with 2.1.x. I face the same problem as reported in different threads that the phase alpha1 gets reflected at the outflow, no matter if dense or coarse grid, zeroGradient or inletOutlet....

Ok turning old searching the cause of alpha1 being reflected at the outflow, I finally got it. Maybe this is a bug dependent on ubuntu version, but it is quite relevant. The difference between the two pictures below showing an outflow of a channel is only that I moved the grid from positive x quadrant to negative x quadrant. When the whole grid lies at a position that the x-coordinates are smaller than 0 the outflow works! This strange behavior vanishes when using zeroGradient for p_rgh instead of fixedValue 0.

Hi Arne,

I cannot open this link including the thesis you recommended. Would you mind tell me the name of this thesis?

Cheers,
Hua