[thiagopl]

I am working on a transient buoyancy driven flow. The domain has a inner heated plate and some openings trough which air should flow once heated. It is a chimney, basically. The air should flow only at the presence of a temperature difference and a gravitational field. After some work I noticed the even when there is no temperature difference, the air was flowing and its magnitude was clearly dependent of my pressure (p_rgh) boundary conditions.
To investigate that I propose a simple question: how to make the air stands still on a buoyant solver?
Attached is a toy case (see figure) which I tested different combinations of p_rgh boundary conditions and all of them results in air movement, even though there is no temperature difference.

To me the following boundary conditions make sense to me:
ambient.bottom
p_rhg: totalPressure, p_0=101325
U: pressureInletOutletVelocity
p: $calculated, once it is a p_rgh solver

ambient.top:
p_rhg: total pressure, p_0=101325
U: pressureInletOutletVelocity
p: $calculated, once it is a p_rgh solver

But it results in a downward flow. Certainly this pressure boundary condition results in a pressure difference which is driven the flow.

[jherb]

Have you tried fixedValue (or fixedMean) as boundary condition for p_rgh?

[thiagopl]

Hi jherb,

Thank you for your interest in the topic. I tried the fixedValue boundary condition as the following:

    ambient.bottom
    {
    type        fixedValue;
    value        uniform 101325;
    }
    ambient.top
    {
    type        fixedValue;
    value        uniform 101325;
    }

It still results in a downard flow as in totalPressure condition. As the figure attached shows, there is a small inbalance in p_rhg along the chimney axis which apparently causes the downard flow. The fixedValue also forces this "not so much natural" behaviour of p_rgh curve. The velocity boundary conditions also doesn't affect the results.

[jherb]

Okay. A shot in the dark: set g to 0 and look what happens.



Another idea: In the fvSolution file, you have set tolerance for p_rgh to 1e-4. Set it to something much smaller (1e-7 or 1e-8). Also increase the number of nOuterCorrectors to something like 10.

[thiagopl]

Hi jherb,

A colleague also alert me about the residuals control* and the temperature. Then I lowered the residuals and also improved the schemes. Now I get only what it seems to be round off errors on p_rgh and T (see figure). The number of nOuterCorrectors didn't affect the results.

I also turn the gravity off I get zero velocity everywhere, what suggests the driven force comes from the buoyancy term. But, if I change the direction of the gravity vector, say up and down along y axis, the final velocity field doesn't change accordingly, it remains downward! So now it seems to be a pressure thing.

This accelarating velocity field reachs Uy=-0.04 m/s after 60s. If I put "bubble" of higher temperature (+1 K) in the domain, the bubble rises a bit and then is pushed down. I if closed the domain the bubble rises perfectly.

Other threads in this forum discussed about this behaviour. I will keep trying...

[jherb]

I have looked at your case file and I think the problem is, that specifying the presssure on all openings is overdeterming the problem. It looks like p_rgh and U show a checkerboard pattern at the lower end of the pipe.

If you set the pressure boundary condition to zeroGradient at the button inlet (probably it does not matter on which end), the problem goes away and the velocity settles to zero in the whole flow domain.

In the attached case, a "bubble" rises first up and then the velocities go back to (nearly) zero. If you start the case without the call to setFields in Allrun, then there should be zero velocity all the time.


(I increased the viscosity by a factor of 100 to have more friction, so the slow down happens faster. Just doing this without changing the boundary conditions does not help.)


Another edit:
If you set the boundary on the top to something, which imposes constant pressure on the whole outlet, the bubble is not really leafing the flow domain. On the other hand, if you set it to fixedMean, convergence takes much longer and the case without a bubble has small velocities at this outlet which take long to settle down.

[Gerry Kan]

Dear Thiago and Joachim:

I am also noticing similar issues with buoyancy in OpenFOAM.

Instead of p_rgh, I implemented gravity effects directly in the momentum and energy equations (rho*g in UEqn, and rho*(U&g) in EEqn). I did it this way because I cannot assume constant density as one would for p_rgh (yes, my flow solver is compressible).

In a hydrostatic setting, i.e., fixedValue p and T on the bottom and fixedGradient on top, I get a net non-zero vertical movement, even though the p, T and appear as expected. My observation is similar to what Thiago is seeing.

If I set gravity to zero I get the trivial solution.

Somehow the solver is seeing the gravity-induced pressure gradient as an upward driving force. Any ideas what else could be missing?

Thanks in advance, Gerry.

[thiagopl]

Hi all,

First, thank you Joachin for the time spent. I think your suggestion solved the problem and also shed some light on another problem. In the following I try to sumarized the findings.

Boundary conditions in open domain inlet/outlet for buoyant cases
As suggested by Joachin, with the zeroGradient condition for p_rgh the results show a near zero (~1e-4) velocity field as physically expected. Attached is the animation showing the velocity component profiles along the chimney height. The legend represents the ambient.bottom-ambient.top boundary condition. For comparison purposes I added the case in which the gravity is set to zero.

fvSolution
Although at first it seemed to me (as also found in many other threads) that the problem here is about the right setup of boundary conditions, I think it is not (only). Actually I had also tried this boundary condition combination as many others. Therefore, attached is a figure that shows the same case, zeroGradient-zeroGradient, ran with my fvSolution and the fvSolution sent by Joachin. So, no matter the boundary condition, a bad setup of the fvSolution seems to produce the downward flow reported initially.

Bubble case
I also tested the case with a bubble of +1 K and nu=1.8e-5 within the domain. The bubble rises and leaves the domain in a good way (pretty qualitative...).

Finally, I think that the figure chimney2Dnew answers the initial question of the thread.


Edit: tha main thing about the fvSolution has to do with a good configuration of the PIMPLE algorithm which this link may help.

[jherb]

Just one note: In you figure you say zeroGradient p_rgh as bottom and top boundary condition. But in my setup, p_rgh was set to fixedMean at the top and zeroGradient at to bottom.

[thiagopl]

Joachin,

Correct, one should be aware of it.
The fixedMean for p_rgh resulted in a strange small velocity pattern near its boundary, as you already noticed. This is shown on the video of the velocity profiles I posted.
Bellow is a link for a video of the case with mu=1.8e-5 and a +1 K bubble. There you can see the velocity pattern generated near the top boundary set with fixedMean (p_rgh) and how it influences the flow as the bubble leaves the domain.
Video

*In the video both images have the same scale factor of 0.5 for the velocity glyph.

[jherb]

Thank you for the videos. I am surprised that it works with two zeroGradient, because you set no pressure level. But as this is a transient simulation, you start with a given one, so it might work.


I think a solution might be to model the open atmospheric boundary at the top with a big volume (but probably with a coarse mesh) and at top of this set a fixed boundary condition.