CFD Online Discussion Forums - Negative flow inlet

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)

- OpenFOAM Running, Solving & CFD (https://www.cfd-online.com/Forums/openfoam-solving/)

- - Negative flow inlet (https://www.cfd-online.com/Forums/openfoam-solving/241626-negative-flow-inlet.html)

Negative flow inlet

There are several posts about natural convection in this forum, but none of those solves my problem.

I have created a 2D 0.5m high small "scale" and model for a case, with partly heated wall. There is one inlet and outlet.
This is a k-epsilon model using perfectGas and buoyantSimpleFoam as solver, for air.

Boundary conditions, system folder and velocity profiles are attached in this post. if you want to run the case, I have to create a blockMesh, My mesh exeeds the storage limit.

The problem I am struggling with is negative flow at inlet (left picture). The U_magnitude is positive, but both U_X and U_Y are negative and U_Z is zero. The outlet flow (right picture) is positive, resulting in a constant loop of the model and after 100k+ iterations, the model crashes.

How do i manage to add a positive inlet flow to the model? I have tried different approaches with outletInlet for U, p_rgh and T + many other approaches, without any success . What fixed mye positive outlet flow was setting T_outlet to inletOutlet.

pressure is calculated using: p = p_rgh + rho*gh + pRef. p_rgh is pressure without hydrostatic pressure.

p_rgh diverges, which is a common problem in this forum.

QUICK scheme have been used to discretize the momentum and energy equations, without luck. (Litterature study suggest using QUICK scheme for the mentioned eq's)

Any help solving this back flow problem?

your p_rgh boundary

Code:

     inlet

    {

    type         fixedValue;

    value         uniform 0;

    }

    outlet

    {

        type         zeroGradient;

    }

your U boundary

Code:

    inlet

    {



        type            zeroGradient;     

    }

    

    outlet

    {

        type            pressureInletOutletVelocity;

        inletValue      uniform (0 0 0);

        value           uniform (0 0 0);

    }

Quote:

This velocity inlet/outlet boundary condition is applied to pressure
boundaries where the pressure is specified. A zero-gradient condition is
applied for outflow (as defined by the flux); for inflow, the velocity is
obtained from the patch-face normal component of the internal-cell value.

Hence you are using pressureInletOutletVelocity on a patch without a specified pressure.

The problem with natural convection is that your flow does not result from a boundary condition, but is generated inside the domain. The problem with that is, that your boundaries are essentially inlet or outlet and you need conditions which can switch based on what is present. For example totalPressure/prghTotalPressure and pressureInletOutletVelocity. This might however not be all that stable especially with high order schemes like quick. The best thing one can do is move the atmosphere far away from the problem and use stable but not all that realistic boundary conditions. For your geometry however this should be solvable.

Also are you sure you want to calculate natural convection with steadyState conditions? natural convection is a pretty transient phenomenon.

Quote:

Originally Posted by Bloerb (Post 823868)

your p_rgh boundary

Code:

     inlet

    {

    type         fixedValue;

    value         uniform 0;

    }

    outlet

    {

        type         zeroGradient;

    }

your U boundary

Code:

    inlet

    {



        type            zeroGradient;     

    }

    

    outlet

    {

        type            pressureInletOutletVelocity;

        inletValue      uniform (0 0 0);

        value           uniform (0 0 0);

    }

Now what does that mean. You are fixing the pressure at the inlet to zero with a zeroGradient velocity. Which means your "inlet" isn't an inlet but a pressure of 0. Which is THE typical outlet condition for fixed velocity inlets. Unless the pressure inside your domain is lower nothing will flow into the domain from this inlet. Now the definition of pressureInletOutletVelocity:
Hence you are using pressureInletOutletVelocity on a patch without a specified pressure.

The problem with natural convection is that your flow does not result from a boundary condition, but is generated inside the domain. The problem with that is, that your boundaries are essentially inlet or outlet and you need conditions which can switch based on what is present. For example totalPressure/prghTotalPressure and pressureInletOutletVelocity. This might however not be all that stable especially with high order schemes like quick. The best thing one can do is move the atmosphere far away from the problem and use stable but not all that realistic boundary conditions. For your geometry however this should be solvable.

Also are you sure you want to calculate natural convection with steadyState conditions? natural convection is a pretty transient phenomenon.

I am working as well in a natural convection flow, where 3 of 4 boundaries are open. I impose known values in one of these patches but there are still 2 "degress of freedom" and it is not so easy to find a well-posed BC in the available ones. If you know how the fluid should act close to the boundaries it could be possible to prepare a custom BC.

Thank you for the reply.
Okey, I will fix the inlets. Any suggestions to solve this inlet?
a baginner, and in the other tutorials uses fixed fluxpresssure with fix velocities. I want the solver to determine the inflow by it self. As you say, the model is determined with what is happening inside the domain, and setting fixed values may confuse the model?
When I am later validating the large scale model, measured valus will be used, and can be the reserve plan to set fixed inlet and outlet values.

I agree with the atmosphere, and it will be in my mind when I put the solver into the large scale/actual case.

Yeah, natural convection is transient, but at the moment my computer is not capable to solve PIMPLE case, too slow...
For large scale, I have access to a cluster, so pimple will not be a problem then

FixedFluxPressure acts as a zeroGradient BC, therefore any imposed value would be needed.

You could use a PIMPLE simulation (you could coarse the mesh) as a starting point for your steady simulations. If BCs are not posed properly the steady solvers stops and suggests you to use potentialFoam

You have too much degrees of freedom here.

I recommend using a closed volume with no inlet or outlet. Simply lengthen your wall at the top and the bottom. These added walls have a nonslip boundary, but no heating.

You get some kind of circular flow. But if your volume is large enough, the downward flow does not influence your heated side.

If you want to study the transient flow / beginning of rising that may be sufficient. If you want to study the stationary case you should add a cooling at the opposite side. So the fluid does not heat to infinity or to the wall temperature (dependung on your b.c.).

I think that is a far better model. I used a similar for my calculations of gravity driven convection / dissolving of a component at the boudary.