[Thomas Baumann]

Hallo all,

I have problems with the mass flow solving problems with buoyantBoussinesqSimpleFoam-solver.
I'm solving axis-symmetric flows with heat transfer, density changes can be neglected. The meshes are made with the blockMesh-utility. The resiudals are very good (ca. 10e-9).

So as test case I solved an easy case with a heated pipe. Solving with the k-epsilon turbulence model for different k, and epsilon show at the inlet wrong values. (inlet = 0.2917 0 0, gravity is in minus x1-direction) In the diagramm you can see the inlet profil. So the massflow is wrong for the whole case (green and red, blue is good).


So you can see, the values of the simulations show bad results, indeed a wrong mass-flow. Only neglecting gravity forces result the right inlet profil.

Some steps afterwards:


Solving this problem with simpleFoam (so no temperaturefield is beeing determinated, I get good results, indeed the same as solving with buoyantBoussinesqSimpleFoam without gravity:
The two curves lie at the same positions:



Solving a channel-flow (not axis-symmetric, but symmetric) I get very good results. So the wrong inlet-mass-flow is only existing using buoyantBoussinesqSimpleFoam and axial-symmetric flow-problems.

Has anybody an idea?

Best regards, Thomas

[elorriaux]

Hello,

how do you compute your mass flow and, what is your result and what is the radius of your pipe?

I have already checked such things on axi cases and it was ok.


edit: sorry I just saw the profiles after my answer. In fact, I think the main question is why are you getting such profiles while you are specifying an uniform velocity at inlet! I think there's something wrong in your postprocessing.

Here is what I'm getting when I'm setting a uniform velocity at the inlet of an axi case:




Etienne.

[Thomas Baumann]

Hello,

for the plots in my first posting I used the sampledict using:

interpolationScheme cell;
type midPoint;

I build some 3d-meshes, too. I got the same problems with the massflow.
Using the postprocessing-utility for the inlet or outlet boundary condition: (e.d. patchIntegrate phi inlet) and compare them with the theoretical (inletbulkvelocity*area) I get big differences if the gravity isn't zero. If there's no gravity the massflow results are very good, for axis-symmetric and 3d-meshes.
So I think the problem is the buoyantBoussinesqSimpleFoam solver.

I wrote a new one without the hydrostatic pressure in the Navier-Stokes-Equations.

in createFields.H
volScalarField deltarho
(
IOobject
(
"deltarho",
runTime.timeName(),
mesh
),
beta*(T - TRef)
);

in UEqn.H
fvc::interpolate(deltarho)*(g & mesh.Sf())
instead of
fvc::interpolate(rhok)*(g & mesh.Sf())

It was necessary to modify the pressure-file, that the residuals do converge, so in pEqn.H:

surfaceScalarField buoyancyPhi = rUAf*fvc::interpolate(deltarho)*(g & mesh.Sf());
instead of:
rUAf*fvc::interpolate(rhok)*(g & mesh.Sf());

The first simulations show the theoratical mass-flow.

So for more informations about my simulations:
I'm solving thermal turbulent liquid-metal-flows with the buoancyBoussinesqSimpleFoam solver and RAS-models. The untypical conditions within these simulations are a high density (e.d. 11000kg/m^3) and the high thermal conductivity (e.d. Pr = 0.022).

Regards Thomas

[elorriaux]

Hello Thomas,

in fact, phi is not really the phi you are thinking in buoyantBoussinesqSimpleFoam. Look at pEqn.H, lines 11 to 13:

surfaceScalarField buoyancyPhi =
rUAf*fvc::interpolate(rhok)*(g & mesh.Sf());
phi += buoyancyPhi;

So phi does not reflect velocity fluxes anymore and it is not the right value to use to compute flow rates.

To be sure, I've just verified it on a small test case, with density = 11000 kg/m3, gravity = 9.81 m/s2 normal to the inlet patch.

patch area = 0.0040438 m2
imposed velocity = 0.4 m/s
so imposed flow rate should be 0.00161752 m3/s (add a minus for surface orientation)

patchIntegrate phi inlet = -0.00125536 m3/s
patchIntegrate buoyancyPhi = 0.000362164 m3/s

So effectively, integrating phi shows 22% error on the flow rate, but integrating (phi - buoyancyPhi) gives -0.001617524 m3/s.

It looks good to me

Regards, Etienne.

[Thomas Baumann]

Hello Etienne,

thank you very much for your hinds.
I have calculated the massflow of the 3d-case in another way:
I calculated the velocity-magnitude and calculated the massflow (neglecting density changes)

foamCalc mag U
patchIntegrate magU inlet
patchIntegrate magU outlet

for no gravity:
inlet: 0.000408379 m^3/s
oulet 0.000408379 m^3/s

gravity in flow direction:
inlet: 0.00040379 m^3/s
oulet: 0.000463418 m^3/s

gravity in minus flow direction:
inlet: 0.00040739 m^3/s
outlet: 0.000362151 m^3/s

So the outflowrate depends on the gravity-tensor using the velocity-field and not the phi-field. The massflow isn't constant over the hole pipe.

Or is a part of the mass-flow in the buoyancyPhi and I have to correct my velocity-field for post-processing?

Regards Thomas

[elorriaux]

Hello Thomas,

I can't really be more helpful since I can't see the same behavior on my case. Integrating U gives the right flow rate on my case.

What about the convergence? It's suspicious to get such errors on the flow rate if the continuity convergence is OK.

Which values are you using for beta and TRef? What is the mean value of your temperature field? Are you still in good agreement with the boussinesq assumption?

Regards, Etienne.

[Thomas Baumann]

Hi Etienne,

the residuals are good.
Uy, Ux, Uz, epsilon, p , T and k < 10e-7.


time step continuity errors : sum local = 1.3705e-08, global = 4.21107e-10, cumulative = 2.44451e-05

So I think they should be good enough.

For beta I'm using 0.000128.
The inlet-temperature is about 573 K, the same as the reference temperature.
Temperature changes are smaller than 50 K, so density changes are smaller than 0.5 percent. I think you can use here the boussinesq assumption.

I'm solving the problem with the modified solver now, because here is the mass-flow okay and I don't need the hydrostatic pressure for my calculations. I need some results in January...
But I'm still trying to find the mistake or whatever.

So thanks a lot and best regards,
Thomas