|
[Sponsors] |
What is the difference between taking mass flow rate from Openfoam and Parafoam? |
![]() |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
![]() |
![]() |
#1 |
New Member
Merve Akkus
Join Date: Jun 2020
Location: Turkey
Posts: 3
Rep Power: 6 ![]() |
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. Last edited by Makkus; November 23, 2020 at 10:09. |
|
![]() |
![]() |
![]() |
![]() |
#2 |
New Member
Join Date: Aug 2021
Posts: 11
Rep Power: 5 ![]() |
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. |
|
![]() |
![]() |
![]() |
![]() |
#3 |
New Member
Join Date: Aug 2021
Posts: 11
Rep Power: 5 ![]() |
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 :-) |
|
![]() |
![]() |
![]() |
![]() |
#4 |
Senior Member
Join Date: Apr 2020
Location: UK
Posts: 711
Rep Power: 14 ![]() |
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. |
|
![]() |
![]() |
![]() |
![]() |
#5 |
Senior Member
Joachim Herb
Join Date: Sep 2010
Posts: 650
Rep Power: 22 ![]() |
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.
|
|
![]() |
![]() |
![]() |
Tags |
flowratepatch, massflowrate, openfoam, paraview, postprocess |
|
|
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
Map of the OpenFOAM Forum - Understanding where to post your questions! | wyldckat | OpenFOAM | 10 | September 2, 2021 05:29 |
OpenFOAM 5.0 Released | CFDFoundation | OpenFOAM Announcements from OpenFOAM Foundation | 11 | June 5, 2018 23:48 |
Simulating Creeping (Stokes) Flow in OpenFOAM | shanleyk | OpenFOAM Running, Solving & CFD | 3 | July 9, 2015 15:41 |
[OpenFOAM] OpenFoam (Ubuntu): paraFoam via Xming+PuTTY | raketenmaid | ParaView | 4 | February 5, 2013 05:20 |
New OpenFOAM Forum Structure | jola | OpenFOAM | 2 | October 19, 2011 06:55 |