thermal analysis with buoyantBoussinesqSimpleFoam
 

Hi,
I'd like to simulate the thermal anlysis of a car.
I'm thinking to use the solver "buoyantBoussinesqSimpleFoam".
I saw the post:
- http://www.cfd-online.com/Forums/ope...am-solver.html
- http://www.cfd-online.com/Forums/ope...planation.html

I have some question:
1) Is it possible make what I want with "buoyantBoussinesqSimpleFoam"? Or I'm wronging solver?
2) Is it correct to simulate the heat flux of the engine like a fixedGradient for the Temperature? In this case I need the alfa_eff of the engine! If it exists, does anyone know a stardard value of alfa_eff for an car engine?
3) If I have the correct heat flux of the engine, could I use the BC "wallHeatFlux"? Do I set it into T file?

Before to try with the car, I'm training myself with a simple model: a hot sphere into a room.
I tried before a closed room:
T: initialField 298, fixedGradient for the sphere, zeroGradient for the walls
p: buoyantPressure for all
U: fixedValue (0 0 0) for all
Then I tried to add an inlet in front of the sphere and an outlet in the back side of the sphere:
T: initialField 298, fixedGradient for the sphere, zeroGradient for the walls, inlet and outlet
p: fixedValue 0 for the outlet, buoyantPressure for the other patchs
U: fixedValue (1 0 0) for the inlet, inletOutlet for the outlet, fixedValue (0 0 0) for the other patchs

But I obtain a strange result.
The map of pressure and velocity in a section is not correct: I have over pressure near the inlet and big velocity near the outlet.
My results are quite similar to the results showned in the posts above!!!
Therefore, I made some stream lines: they start straight and when overcome the sphere, they turn on the right!
I though the error was on inlet / outlet BCs! So I started changing the BCs first for inlet and outlet and then for all the patch (I tried also the slip type for the wall) and I entered in a blind loop!

Could anyone give me any suggestion?

Thank for any reply!

Andrea

Sorry, they turn in gravity "g" direction!

I tried new BCs:
T: initialField 298, fixedGradient for the sphere, fixedValue $internalField for the walls
p: fixedValue 0 for outlet, buoyantPressure for the other patches
U: fixedValue (1 0 0) for inlet, inletOutlet for outlet, fixedValue (0 0 0) for the other patchs

But with poor results...
In the end I switch of the gravity g (0 0 0) and now the air flow seems correct and goes straight.
But I thinking the results are not correct without g...

Can anyone give me any advice?

Thank for any reply

Andrea

Hello,
I tried these BCs with gravity on (0 0 -9.81).
Temperature
Velocity
Pressure
Now the results look good (figure attached)
Could anyone give me any feedback?
Does exist in literature any experimental test of a hot sphere into air flow to reproduce with buoyantBoussinesqSimpleFoam?

Thanks

Andrea

Hi Andrea,

I suggest you not use fixedValue for pressure as outlet unless it is perpendicular to the direction of gravity. In the new solvers, p = P - pRef, so p will be stratified. Using a fixed value outlet will give rather odd results. There is a new boundary called uniformDensityHydrostaticPressure that will do a better job.

Hello,

I would like to simulate the filling of a tank with hot water using buoyantBoussinesqPisoFoam but I always get an unphysical high velocity in the middle of the tank. In the initial state the tank is already completely filled with cold water.

The tank is a closed cylinder with an inlet at the top and an outlet at the bottom. Both are perpendicular to the direction of gravity.
The BCs are:
U: fixedValue at the inlet, zeroGradient at the outlet, fixedValue(0 0 0) at the walls
T: fixedValue at the inlet, zeroGradient all other patches
p: zeroGradient at the inlet, fixedValue 0 at the outlet, buoyantPressure at the walls.

The inlet velocity is 0.3 m/s but in the middle of the tank (after 1 second simulation time) the velocity raises up to 0.7 m/s.
If I use the buoyantPisoFoam from Version OF-1.5-dev I get reasonable results with the exactly same setup (max velocity remains at ~0.3m/s). In OF-1.5-dev the Boussinesq Approx for density is different from the definition in OF-1.6.
Probably, in OF-1.5-dev the gravity term is absorbed into the pressure gradient?
However, both solvers should give similar results with this setup. So, do I need a special BC for the pressure outlet in OF-1.6?


Best regards

Matthias

Hi Matthias,

You boundary conditions look fine for this case. Your problem must be somewhere else.

Hi Eugene!
How are you? thank you very much for your suggestion.
I'm trying the new BC for the outlet. I set
Is it correct? The outlet patch is along Z direction (it's parallel to the gravity direction).
Now it's running with 1 processor fine.
I try to use more processor but I got 1 FATAL ERROR during decomposition step!
What it is? with outlet fixedValue I don't have this problem!

Thanks

The problem is decomposePar does not load the gravity dictionary, so it is not available when the boundary is constructed and therefore causes a fail. This is a general issue with boundaries that try to lookup things from the database during construction - a better solution is to construct fields on-demand.

To fix this, either modify the boundary to check whether g is available before looking it up, or decompose the case with some other boundary like zeroGradient and then manually modify it to the required boundary in each processor directory.

buoyantBoussinesqSimpleFoam: the time step continuity errors blows up to inf.
 

Hi!

I get problems with buoyantBoussinesqSimpleFoam, it must be the mesh or the BC.

Checkmesh gives me:
***Number of edges not aligned with or perpendicular to non-empty directions: 21369
<<Writing 42738 points on non-aligned edges to set nonAlignedEdges
...
Failed 1 mesh checks.

Basically I have a room with a hot cube inside, I use an inlet, outlet, wall, cube-wall and empty (2D case).

The domains simply looks like:
_______________________
| _______[]_____________|

inlet (left side)
outlet (right side)
cube in the middle
top and bottom is wall
empty in the z direction

If I run simpleFoam, everything works just fine, but when i start with buoyantBoussinesqSimpleFoam the time step continuity errors blows up to inf.

I tried many different variants of the pressure BC, but get the same time step continuity errors every time.

Anyone that know why or that has a running case (with inlet and outlet) to send so I can have a look at your setup?

Best regards
John

problem solved
 

Hi

I converted to a 3D case and switch from empty to symmetryPlane instead.
CheckMesh give no errors and the solver works perfect now.

John

You can't use type empty for your patch if in normal direction of your patch you have more than one cell.

Regards

Hi,

I am aware of the use of empty patch with just one cell thickness in the third dimension. What I am saying is that using a 2D case with empty patch wont work for me. My solution was to convert to a real 3D case or stick with the 2D case but use symmetryPlane patch instead of empty.

John

After a lot of trouble, I have found that the new buoyantBousinesq line of solvers really are no good for real world cases. The main problem is the grad(p) and gravity density terms have to cancel out in a stationary fluid, but due to discretisation errors in the grad(p) term, this does not happen on all but the simplest meshes.

Hi Eugene,

After a expert like you comments on these set of solver, My soul is relaxing now knowing there are other people also feeling the same heat with boussinesq solvers.

Forgive my poetry, I am also these days using boussinesq set of solvers for solving a complex heat exchanger problem. I am also facing the problems in matching with experimental results.

I have posted my problems in the following post.
http://www.cfd-online.com/Forums/ope...tml#post258255

Regards
Santhosh

What would you like me to comment on?

The div(phi)*T term prevents local errors due to non-consrvation of fluxes in unconverged velocity fields. It is zero at conergence.

Hi Eugene,

I figured out that little back. Currently I facing convergence problems If I use linear in place of upwind.

Also, If you look at the last post in the above thread (http://www.cfd-online.com/Forums/ope...tml#post258255), I posted residual plot with sensitivity of turbulent prandtl number, Initially, unknowingly, I have used Prt=5 in which case solution is converged.

Later I thought it is not correct to use Prt=5, so I changed it to 0.8 where I could not get convergence.

Can u comment on whether it is proper to use Prt = 5. (I have read an article showing Prt used as turbulence generation due to buoyancy in k equation.)

Regards
Santhosh

Hi,

I read with wikie article

http://en.wikipedia.org/wiki/Turbulent_Prandtl_number

It says Prt range is 0.7-0.9. So I think I should stick to Prt=0.8 and play with others to get the residual down..

Thanks
Santhosh

Dear Eugene,
what do your words mean?
The buoyantBoussinesq solvers are not applicable to simulate, for example, the heating of a building immersed in the atmosphere?

Thank you,

Valeria

My observation is that BuoyantBoussinesq simple foam predicts the flow and temperature profile well. But when it comes to validation (comparing the number) I am finding difficulty.

I tried thermal cavity, the flow profiles are pretty good but validation ( non dimensional velocity and temperature at mid section) is not impressive.

The same observation I have found with industrial heat transfer problem.


PS: I have used only upwind (first order). I could not do linear (second order) as it is not converging well.

Regards,
Santhosh.

Dear Santhosh,

thank you!
I am also trying to simulate a heated cavity immersed in a neutral atmoshere but I am having difficulties to impose boundary conditions on p, U and T.

U: I imposed an experimental velocity profile on inlet, a driving velocity on top and no-slip condition on wall.
p: I imposed buoyantPressure condition on inlet, top, outlet and wall. I tried to impose on outlet both the uniformDensityHydrostaticPressure condition and a stratified profile -rho*g*z but the velocity assumed high and unphysical values.
T: I imposed uniform profile (T=300 K) on inlet, top and wall (I started to simulate the case without heating to compare the results with those obtained by simpleFoam.. I found some differences in U(1), k and epsilon profiles).

There is someone who could help me? Thank you!

Valeria

Dear Valeria,

The solvers are applicable to any case where the Boussinesq approximation can be justified, they just do not work very well on poor meshes. So if you have a perfect block structured mesh, then the solvers work very well (in our experience), but if you have tets, polyhedra or deformed hexes, then the results are completely unphysical. It might just be that we did not use the right combination of differencing schemes, but believe me we tried many.

Also, always use 2nd order or near 2nd order schemes like linearUpwind if you are trying to match experiment - you will be disappointed otherwise.

Hi Eugene,
so what do you think, buoyantBoussinesq is good to study cool down or warm up into automotive cockpit?

Thank you

Andrea

Hi Andrea,

In general, for the default solver implemented in 1.6.x, no. It is highly unlikely that you will be able to make a mesh for an automotive cockpit such that spurious numerical errors from the solver discretisation errors will not overwhelm the balance of buoyant and hydrostatic forces.

The most viable solution we were able to come up with was to reimplement the Boussinesq solvers to more closely match the Boussinesq approximation, i.e.

rhoPrime = -beta(T-Tref)

and then to solve for pPrime instead of p. This formulation more closely matches the "pd" formulation for the compressible buoyant solvers in 1.5.

Hi Eugene,
the problem is just for the Boussinesq approximation, or else for the buoyant solver?
Could I try with buoyantSimpleFoam?

Thanks

Andrea

Hi Andrea,

The problem is that grad(x) where x is a linearly varying field does not return a constant value field on distorted meshes. When you have a relatively high gradient, such as that induced by the hydrostatic force (rho*g), then trying to balance it with grad(p) fails and produces large spurious momentum sources on poor mesh elements.

buoyantSimpleFoam in 1.6 uses the same kind of formulation as the Boussinesq solvers (balancing the pressure gradient against the hydrostatic component). As such I would expect it to have the same problems (I haven't tested it for this purpose myself though, so I cant be sure). buoyantSimpleFoam in 1.5 on the other hand uses the old formulation that splits the hydrostatic component of pressure, so does not suffer from this problem.

Eugene

Hi Eugene,

Thank you very much for your time and for you explanation!

I will try a comparison between OF 1.5 and 1.6.

Another question, and if I put g (0 0 0) what will it happen?

Thanks

Andrea

If g is zero, the buoyancy force will be zero too. The issue with poor meshes should go away, since there will be no hydrostatic pressure gradient and you will be left with something like simpleFoam + uncoupled temperature solution.

Eugene

why is buoyantPressure used in the p field and not in p_rgh like the tutorials show?

I'm wondering the same thing, when I try to calculate it that way, I get an error. When I choose p as the "calculated" boundary condition and p_rgh as the buoyant pressure boundary condition, the solver runs, but I haven't been able to get p_rgh to converge.

I figured it out, p_rgh is actuall p minus rgh so in your BCs p is the buoyant component and p_rgh the rest (mainly dynamic)

Hi All,

I am using buoyantBoussinesqSimpleFoam in order to simulate heat transfer in horizontal pipe which means my g=(0 0 0), but still I am getting minus pressure at outlet,
what does it mean? I have some wrong BC or it is normal?

Thanks in advance!

Kanarya

Hii Foamers
I am new to openfoam when i do the thermal analysis with buoyant boussinesq simplefoam
I get an error message which am unable to figure it out so can anyone say what the error is the error message was


*\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\*
Time = 416

smoothSolver: Solving for Ux, Initial residual = 0.078627081580006655259218462106218794360756874084 47265625, Final residual = 0.004754302950650706773016995754232993931509554386 138916015625, No Iterations 34
smoothSolver: Solving for Uy, Initial residual = 0.071250201313677444248106951363297412171959877014 16015625, Final residual = 0.004371174219772354201107855686814218643121421337 127685546875, No Iterations 38
smoothSolver: Solving for Uz, Initial residual = 0.059798420555534845255429843291494762524962425231 93359375, Final residual = 0.003684226581084196032456201663762840325944125652 313232421875, No Iterations 37
smoothSolver: Solving for T, Initial residual = 0.076515793938819090524994237512146355584263801574 70703125, Final residual = 0.005327684404854957783692626094307343009859323501 5869140625, No Iterations 3
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ??:?
#2 ? in "/lib/x86_64-linux-gnu/libc.so.6"
#3 Foam::GAMGSolver::scale(Foam::Field<double>&, Foam::Field<double>&, Foam::lduMatrix const&, Foam::FieldField<Foam::Field, double> const&, Foam::UPtrList<Foam::lduInterfaceField const> const&, Foam::Field<double> const&, unsigned char) const at ??:?
#4 Foam::GAMGSolver::Vcycle(Foam::PtrList<Foam::lduMa trix::smoother> const&, Foam::Field<double>&, Foam::Field<double> const&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::PtrList<Foam::Field<double> >&, Foam::PtrList<Foam::Field<double> >&, unsigned char) const at ??:?
#5 Foam::GAMGSolver::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const at ??:?
#6 Foam::fvMatrix<double>::solveSegregated(Foam::dict ionary const&) at ??:?
#7 Foam::fvMatrix<double>::solve(Foam::dictionary const&) at ??:?
#8 ? at ??:?
#9 ? at ??:?
#10 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#11 ? at ??:?
Floating point exception (core dumped)

buoyantBoussinesqSimpleFoam
 

Hi everyone,

I encounter exactly the same behaviour for this solver.

After setting g to (0 0 0), I finally got physical results !

I study the air flow in a room with significant heat intakes. So setting g to zero is clearly an oversimplification of the problem.

How can we improve the buoyantBoussinesqSimpleFoam behaviour for middle class meshes ?

In HVAC applications, we cannot expect high quality meshes for each cases. So which solver could be an alternative to buoyantBoussinesqSimpleFoam ?

Best regards
jipai