[Terp]

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/cfd-101/cfd-10...luid-flow.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 non-physical 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!

[alberto]

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

[Terp]

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.

[alberto]

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.

[Terp]

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

[alberto]

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 RNK-k-epsilon, 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 Flow-3D shows, I had to double the mesh and change these settings in fvSolutions

PISO
{
    momentumPredictor yes;
    nCorrectors     3;
    nNonOrthogonalCorrectors 0;
    nAlphaCorr      1;
    nAlphaSubCycles 4;
    cAlpha          1;
}

You find the case and a snapshot taken at 10s attached. Not exactly the same, but better than before. I also changed the numerical schemes and switched to GAMG as linear solver for the pressure (much faster).

You find a movie here to see the evolution: http://www.youtube.com/watch?v=ZXUsrlRJUT0

Best,

[Terp]

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

[alberto]

Originally Posted by Terp

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.

Hi, the problem is not in the top BC, but you were setting the same pressure BC at the outlet, which is not true, since the top could be atmospheric (I set it to a wall as they say in the link of Flow3D), however you will have a different behavior at the outlet. In other words, I set the problem exactly as in the case reported in the link.

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.

The influence of the turbulence model is expected, since it affects the viscosity of the flow. The flow conditions are hardly laminar.

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 sub-cycles 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

[santiagomarquezd]

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.

[alberto]

I would say that at least 2 sub-cycles are recommended, but it depends on the application. See the tutorials: with Co = 0.2, correctors are in the 2-4 range.

Best,

[santiagomarquezd]

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

[alberto]

Originally Posted by santiagomarquezd

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

Correctors on alpha only affect the evaluation of alpha, not the alpha-U-p coupling, which is left to the PISO loop.

Symptoms of insufficient correctors are a not accurate solution for alpha. Try reducing them :-)

[alfa_8C]

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

[santiagomarquezd]

Hi, could you please post a little sketch of your problem?

Regards.

[alfa_8C]

Untitled.jpg

very simplyfied - hope this is clear enough

[santiagomarquezd]

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.

[alberto]

Just remember the definition of p and p_rgh...

[alfa_8C]

@alberto - So p_rgh is simply uniform, but with a value of rho*g*h?
I performed a chart very quickly to avoid misunderstandings...

def_p_rgh.jpg

[santiagomarquezd]

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.

[alberto]

Originally Posted by alfa_8C

@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

Right. Just set a uniform value at the outlet. Using p_rgh makes actually things a bit simpler in these cases ;-)