Different boundary conditions between OF1.6 and OF1.7.1 for interFoam
2 Attachment(s)
I try to model a gravitydriven free surface flow down an inclined open channel (inlcuding capillary effects) and succeded with OF1.6, based on the damBreak case of the tutorials. The obtained results are in a very good agreement with experiments.
I used the same case with OF1.7.1 after adopting the differences (p>p_rgh) to be able to compare the results between the two versions. Unfortunately I am not able to reproduce the results obtained from OF1.6. In OF1.7.1 The channel "fills" (completely) from the outlet, which does not make sense at all (see attaches pictures for a simple 2d simulation after t=5s, inclination angle 40°). Here are my boundary conditions (for the simplified 2d version): U: inlet > groovyBC with parabolic velocity profile (also tried fixedValue) outlet > zeroGradient substrate > fixedValue; value uniform (0 0 0); atmosphere > pressureInletOutletVelocity; value uniform (0 0 0); p_rgh: inlet > buoyantPressure; value uniform 0; outlet > zeroGradient substrate > buoyantPressure; value uniform 0; atmosphere > totalPressure; p0 uniform 0; U U; phi phi; rho rho; psi none; gamma 1; value uniform 0; alpha: inlet > zeroGradient outlet > zeroGradient substrate > zeroGradient atmosphere > inletOutlet; inletValue uniform 0; value uniform 0; Since in OF1.7.1 p_rgh is the sum of the dynamic and the static pressure, I already changed the p_rgh boundary conditions without succes. How do I have to change the boundary conditions to have the same results as in OF1.6? Thanks in advance. 
Hi
I have not tried either of the versions, however I think I have an idea. What is the value of the vertical coordinate, say z, at the surface elevation at the outlet? If it differs from zero try to make a translation of your mesh, so the interface exits the outlet at z = 0. Best regards, Niels 
Quote:
For the simulated 2d case, the film height is 2.5 mm and is located at z=2.5mm. However, in the simulations I will also vary the flow rate and therefore the interface located at z=0 would leed to a time dependent mesh ... 
I see, I just had experienced that having the outlet interface at z=0 was the best setup.
One other thing, it typically does not go well to have a Dirichlet condition at both pressure and velocity at the inlet and zeroGradient at the outlet on both quantities.  Niels 
I just had implemented Neumann boundary conditions (zeroGradient) for the pressure on both, the inlet and the outlet. The problem of the "channel filling" still remains. From my point of view the source of the problem is the redefinition of the pressure to p_rgh.

hello,
I think that your outlet BC is wrong for p_rgh. I would try to use outletinlet for inlet/outlet with p_rhg. Another solution is to use buoyantPressure (like inlet). olivier 
5 Attachment(s)
Quote:
What in my opinion leads to the filling is that p_rgh is getting larger and larger at the outlet resulting in fluid transported upwards. aha 
2 Attachment(s)
This is an interesting problem, for it might be that this problem is related to mine.
My first guess was that you might have set the setFieldsDict/blockMeshDict file wrong, so that the water at the inlet has a higher still water level than the rest of the domain. But then I thought about my problem which is actually the same, maybe, but in 3D. I have regular incoming waves in my domain coming from the (water)inlet and I don't know where they are coming from. Actually I thought I have non reflective BC everywhere, but that seems not to be the case. Some might say its due to blockage from the solid for it is too close to the inlet, but in that case I would expect different waves and no such regular waves as it is the case here. Attached you find a picture of the wave pattern and a table with my BC form the 0 folder. It would be great if you could leave me a comment on this. thanks for your trouble best regards Colin 
Actually I can only guess what your problem might be, based on the given information.
How high is your interface level from the setFieldsDict. In some stability calculations with surface waves I had unphysical waves when the interface was to close from the atmosphere bc. Have you tried to solve it in the stable (laminar) regime (without all the k,nut,nuTilda,R variables)? Did you solve the same case with OF1.6? Also you might compare with the following setup: instead of using two boundaries for the two phases (e.g. inlet and airinlet), have you tried to use groovyBC? 
Hi,
thank you for your comments on my case. 1) no I didn't try to solv it with OF 1.6.x 2) my alpah1 level with 0.5 is 0.001 m thick. 3) No I haven't tried to solve it with laminar flow I directly went into turbulent flow. 4) hm groovyBC heard that before but I'm not sure what that is and how to implement them. But I will have a look at them. Anyway, thanks for your trouble regards Colin 
Colin,
are you trying to model regular waves coming from the inlet (BTW., where is it?), or normal inflow  with waves magically been generated inside the model? I guess your BCs (sides and outlet) are not nonreflective; at least they are not working as nonreflective ones in my case. I'm still struggling with this, as I need a nonreflective BC at the outlet to model waves in a flume. groovyBC works quite well (at least for generating waves at the inlet), although it is not working with tet meshes in my case... Arne 
Hi Aha ,
I have exactly the same problem, I'm trying to run a 2D flume, gravity driven flow, with laminar interFoam solver . When I used the buoyant pressure downstream condition for the p_gh field , the water level slowly rises at the boundary, and backs up in the all domain until it stabilises itself. I'm still confused as to why it does this ? has it got a physical meaning ? is this effectively an hydraulic jump travelling upstream ? What other downstream condition can be used ? Cheers, Olivier 
Hi Arne
I don't try to model regular incoming waves. (The inlet is on the right side) I think I've got the solution to my problem. I talked to Prof. Jasak showing him these pictures and he told me that the outlet BC are not transmissive, but reflective. However he gave me the hint to implement a numerical beach at the end to get rid of these waves. The waves are by the way not generated magically but they come from the ship hull Appart from that I haven't found a solution to my problem. So currently I try to implement the beach, but appart from one equation I don't have anything yet. So it seems that my problem is not related to the previous one mentioend in the beginning. However thanks for your help regards Colin 
Hi guys,
am I right when guessing that all the boundary conditions in OF 1.7 (or earlier) used with the interFoam solver are reflective and therefore not transmissive? Like Olivier, I also want to model a flume  in 3D case but at the moment with only one cell in y direction for first tests. I need waves, currents and later a combination of both. Therefore I use the groovyBC condition. For waves as input, I already solved the problem of the 'outflow' numerically with cells becoming larger to the end. Sadly, this does not work for a current flow also generated by groovyBC. Here, the water level in the channel rises by time... Have you already found any solutions? Arne 
Dear Aha,
Did you solved this problem? I'm getting exact the same as you, the channel is filling totally. If I look at your case, what is the Fr number? It looks like an hydraulic jump. Any other how knows what the correct p_rgh boundary condition is? In the code I found the UniformDensityHydrostaticPressure BC. Description Hydrostatic pressure boundary condition calculated as pRefValue + rho*g.(x  pRefPoint) where rho is provided and assumed uniform. Going to try this. Will keep you informed. Arnout 
This bc for p_rgh worked good for me:
out { type totalPressure; p0 uniform 0; U U; phi phi; rho rho; psi none; gamma 1; value uniform 0; } 
Hi Foamers
what's the meaning of the buoyantpressure BC in openfoam 1.6 ? how does it apply pressure condition? how can we use that at inlet or outlet boundary? 
All times are GMT 4. The time now is 01:18. 