[Makkus]

Hi dear Foamers,

I am trying to understand whether my converged Openfoam solution is true or not. To estimate the accuracy of the solution I am observing the mass flow rate for inlet and outlet patches. I am modelling a square pipe geometry with simpleFoam and buoyantSimpleFoam. When I search how to find the mass flow rate in Openfoam, I found 2 ways:

1. It can be find from Openfoam postprocessing:
by typing postProcess -func 'flowRatePatch(name=inlet)' -latestTime in terminal,

2. It can be find from Paraview:
1. calculate with Mag(U) from calculator
2. apply Extract Block filter
3. apply Integrate Variables filter

(By the way, I am using air at room temperature, so its density is 1, it's density won't be change because of the incompressible flow)

These two ways are giving different mass flow rate values. I am wondering about what is the difference between finding mass flow rate from Openfoam postprocessing and Paraview?

I would be glad if you help.

[Daniel_C]

I got the same issue.

The function object gives me:

sum(Outlet_yz) of phi = 0.4298776
sum(Outlet_xz) of phi = 0.06296753
sum(Outlet_xz) of phi = 0.04716788
Total = 0.54001301

This fits perfectly my inlet conditions with 0.54 m³/s.

paraFoam instead gave:

Outlet_yz = 0.439209
Outlet_xz = 0.131476
Outlet_xz = 0.0856227
Total = 0.6563077 ---> 21.5 % too high!

Interestingly, the flowrates pointing in the xz normal direction are almost twice as big as the openFOAM results.

[Daniel_C]

Had some time to make my thoughts. It should of course be clear that calculating a flux through a face has to be done according to the rules of logic and mathematics. That said, it has to be calculated from dot product between flow vector and face normal vector.

The pipeline in paraFoam should be as follows:

1. GenerateSurfaceNormals filter
2. Calculator: U_X*Normals_X+U_Y*Normals_Y+U_Z*Normals_Z
3. IntegrateVariables filter

Alternatively just use:
1. SurfaceFlow filter


This gives correct values for the flowrate because it calculates the net flow across the 2D surface. Especially when applying boundary conditions like inletOutlet, backward flow can occur. The sign of Vektor components has to be accounted for.

Furthermore, mag(U) gives the Vektor length and does not incorporate the flow angle between velocity and the face. Hence the product between the both vector U and area of face A gives wrong values if they are not perpendicular.

Just my thoughts, correct me if I am wrong :-)

[Tobermory]

Yes, correct Daniel. The volume flux through the surface requires the dot product of the velocity field and the surface area.

Here is another observation. though: mass flux, phi, is defined at the cell faces (which is why you can sum it directly at the inlet and outlet planes). Likewise, continuity is enforced at the cell surface (consider Gauss divergence theorem). These will be "exact" calculations.

The parafoam calculation is an estimate using the cell centre U field (and rho field if compressible)... which is calculated from the face fluxes and the pressure gradient; the resulting velocity field, U, therefore includes interpolation errors and often doen not obey continuity to the same level of accuracy as the phi field.

Finally, if your boundaries have a complex shape, then strictly speaking you should be interpolating the (rho*U) field to the inlet or outlet surface and integrating there ... although that will introduce more interpolation errors.

Anyway, the TLDR is that the functionObject phi summation gives you the true continuity error.

[jherb]

Please also consider, that the velocity field in OpenFOAM is based on cell center values and extrapolated to the faces. If you want to compare to the same value, OpenFOAM is using in the postProcessing functions, you have to use the phi field. If you use the native OpenFOAM reader in paraview, this field is not available by default, but you have to convert it to VTK first with foamToVTK.