[eugene]

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.

[andrea.pasquali]

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

Thank you

Andrea

[eugene]

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.

[andrea.pasquali]

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

Thanks

Andrea

[eugene]

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

[andrea.pasquali]

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

[eugene]

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

[mihaipruna]

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

[stefan.gracik]

Originally Posted by mihaipruna

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.

[mihaipruna]

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)

[Kanarya]

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

[Saran16]

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:rintStack(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)

[jipai]

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