Calculation of Volumetric Flow Rate and ACH with Butterfly and Openfoam


Hi @TheodorosGalanos,

After simulating airflow through the openings of a geometry (inlet and outlet have the same area, the geometry is tilted 45deg from the wind direction), I’ve been trying to calculate the Volumetric Flow Rate (and later the ACH) for the indoor volume in 2 ways:

  1. Loading probe values in butterfly, multiplying each vector by the area of the face it’s associated with. I obtain 25 m3/s for the inlet and 18 m3/s for the outlet. Which is incoherent.

  2. On Openfoam directly, creating a file in the system folder called volFlowRateSurface (find further below the content, it refers to the inlet surface stl exported from rhino into /constant/triSurface) and running the command [postProcess -func “volFlowRateSurface” -latestTime]. I obtain -13.834 m3/s for the inlet and 12.990 m3/s for the outlet. Which is roughly equal ( difference should reduce with better meshing) and coherent.

Do you know how to consider these?


/--------------------------------- C++ -----------------------------------**

  • ========= |*
  • \ / F ield | OpenFOAM: The Open Source CFD Toolbox*
  • \ / O peration | Website:*
  • \ / A nd | Version: 6*
  • \\/     M anipulation  |*


  • Calculates volumetric flow rate through a specified triangulated surface*
  • by interpolating velocity onto the triangles and integrating over the*
  • surface area. Triangles need to be small (<= cell size) for an accurate*
  • result.*


regionType sampledSurface;
name mySurface;


  • type sampledTriSurfaceMesh;*
  • surface in.stl;*
  • source cells;*
  • interpolate true;*
  • fields*
  • (*
  •    p*
  •    phi*
  •    U*
  • );*

#includeEtc “caseDicts/postProcessing/flowRate/volFlowRateSurface.cfg”

// ************************************************************************* //

the postprocessing function


Hi Olivier,

The OF postprocessing is definitely the way to go since it is more accurate and kind of out of the box. I do think however that it will integrate every single velocity vector on the surface without caring much about direction. In this case this is fine, since it’s clear how the wind is moving, in more complex cases there might be some error.

Kind regards,


thanks for your reply.

Indeed this leads to what you mention, if through the same openings the air moves in and also out.
In butterfly /grasshopper I used a Dot product to test the vector and dispatch if going in or out.

Have no idea how can OF deal with this. If I find something , I’ll update here.



I forget the name of the function object right now but I think the way to deal with this is to create two faceSets, one slave and one master, one infront of the other, denoting the direction you’re mass flow should be calculated for (master -> slave). It’s been a while since I was looking into this, I’ll try and rediscover the function object that uses those faceSets for calculation.