problem getting interFoam to behave
3 Attachment(s)
Hey all,
I'm trying to learn to use interFoam, so I decided to try to see if I can get the results for a test case on the Flow3D site here: http://www.flow3d.com/cfd101/cfd10...luidflow.html First I tried laminar, and it seems to work pretty well for the first half a second or so. But then the water goes too high up the step and interferes with the waterfall, and never gives the smooth flow from the Flow3D article. The first 2 images show my laminar case at 0.5 and 6.3 seconds. Then I tried with ke turbulence, and the even more nonphysical result shown in the third picture. Any thoughts on where to start looking for what's going wrong and keeping me from getting a good result? Thanks for your assistance! 
It looks like the solution is becoming unstable. It would be useful to know what numerical setup you are using (fvSchemes). If you took it from tutorials, change the div scheme for U from "linear" to a bounded scheme (limitedLinearV 1) or an upwind scheme (linearUpwindV Gauss linear).
Best, Alberto 
4 Attachment(s)
Alberto,
Thank you for the suggestions. I was using linear for the div U term. I tried both suggestions, and the answers are definitely different from before. With the linearLimitedV, the flow attaches to the face of the step, and the upwind is similar, but with a trapped bubble. So I'm still missing something. I attached my fvSchemes and fvSolution files, which now look a lot like the laminar damBreak tutorial. 
OK. Could you share your case?
P.S. I saw you are not solving the momentum predictor. Turn that on too. Additionally, you might want to check if residuals are actually converging. 
1 Attachment(s)
I am more than happy to share the files. I really appreciate your help with this. I have turned on the momentum predictor and it is currently running.
Terp 
2 Attachment(s)
Hi,
I ran your case, and made some changes to it. In particular, the original case sets the top to a wall, and the side on the oulet as Neumann condition. I fixed the mesh to do that. The top part of the step is a slip condition. They model turbulence with RNKkepsilon, so I turned that on. All these changes affect the solution, but do not change the final result a lot. To see something similar to what Flow3D shows, I had to double the mesh and change these settings in fvSolutions Code:
PISO You find a movie here to see the evolution: http://www.youtube.com/watch?v=ZXUsrlRJUT0 Best, 
Thank you for doing all this!
I didn't think the top boundary or the slip condition on the top step would have much affect, and they don't seem to. I'm a little concerned by how easy it is to change the flow behavior by changing the choice of solvers, and that the turn of the water flow towards the right seems to defy gravity. I thought this would be an easy case to model. I guess we're not ready to give up experiments yet. Dave 
Quote:
Quote:
The only major changes to the solver I made are the two parameters on the surface tracking (alphaSubCycles and cAlpha), which are set as in the RAS/damBreak case. The number of subcycles ensures alpha is solved accurately, and is key. The rest of the changes I made are mainly for efficiency (GAMG solver and tolerances). Best, Alberto 
Alberto, is using alphaSubCycles > 0 mandatory even when Co < 0.2 is assured from adjustTimeStep?. I've read that the sub cycling is needed when you want to use larger timesteps in momentum equation, but in case that global timestep is "low" is it still necessary to sub cycle?
Regards. 
I would say that at least 2 subcycles are recommended, but it depends on the application. See the tutorials: with Co = 0.2, correctors are in the 24 range.
Best, 
Aha, I checked the tutorials and things are as you indicated, thx for the ref. I was studying the influence of all other parameters but missed this one (really I didn't find much influence). It seems for Co_mom ~ 0.2 => Co_alpha=0.2/2 or 0.2/4, which is quite conservative even for an explicit time integrator like MULES. I have to suppose that this is due the influence of alpha in momentum equation moreover avoiding divergence of MULES time integrator.
1. Is that right? 2. Are there another reasons? 3. Which is a common evidence of too few alphaSubCycles? Regards 
Quote:
Symptoms of insufficient correctors are a not accurate solution for alpha. Try reducing them :) 
Reference sea level
Hy,
I’m using interFoam in a relatively simple setup. I have a tank filled with water. The top of the tank is open to atmosphere. Close to the bottom the tank has an outlet into a large resevoir of water. The free surface lavel of the reservoir is at 1m. As far as I know the BC for the pressure at the outlet has to be set to 0, as no hydrostatic pressure has to be considered. BUT!!! How can I make the code understand, that my free surface level outside the domain is at 1m? This must be given for sure but I don’t know where. Could anybody give me a hint? Thanks in advance, Toni 
Hi, could you please post a little sketch of your problem?
Regards. 
1 Attachment(s)

Hmm, it depends on the FOAM version you're using, in 1.6 (which is what I'm using) real pressure have to be used, so you have to set the hydrostatic profile at the outlet. In 1.5 and 1.7 things are different (and even different between them I think).
Regards. 
Just remember the definition of p and p_rgh...

1 Attachment(s)
@alberto  So p_rgh is simply uniform, but with a value of rho*g*h?
I performed a chart very quickly to avoid misunderstandings... Attachment 7337 
You have an inverted siphon, choosing 0 as p_rgh gives you an hydrostatic profile at the outlet. Nevertheless BC I suggested is true far from the outlet, because velocity isn't zero in this point. I think the most realistic condition is to simulate a part of the pool near the BC.
Just my 2 cents. Regards. 
Quote:

All times are GMT 4. The time now is 02:55. 