Hello,

does anybody now why doing

massFlow()@boundary

and

areaInt(Density*Velocity w)@boundary

I get different results? The boundary normal is directed as z axes so I should have the same result.

If I want to evaluate the mass flow of a specific variable thru the boundary it is better to use

massFlowInt(var)@boundary

or

areaInt(Density * Velocity w * var)@boundary

(they also give different results).

Thanks for any suggestion.

Fabrizio.

Hi Fabrizio,

When you calculate mass flow in Post, it uses the integration point flows which are reported from the solver. Element faces are broken into sectors, with integration points at the center of each face. By integrating over the sector faces you'll get different results from integration over element faces. Furthermore, the mass flow at the face won't be exactly the same as Density*Velocity w because of the effects of pressure as the velocity field varies.

You could review the solver theory documentation to see how the equations are discretized and these mass flows are calculated. In summary, by using the solver IP values, Post is providing a more accurate representation of the mass flows.

If you need to use the mass flow in a more general calculation, you can use the Mass Flow variable, which will also use IP values. If you integrate 'Mass Flow*var' over the face (i.e. sum(Mass Flow*var)@boundary) you should get the same result as massFlowInt(var)@boundary.

-CycLone

P.S. There are a other integrated values for which you may see these differences. For instance, Post will use IP values for Force calculations.

Hello CycLone,

thank you very much for your answers. (By the way I apologize for the typing errors in the subject).

So areaInt function in Post doesn't use IP value of the variable, and this should explain the differences. In fact looking at the .out file of the solver I see that the mass flows reported in the balances are exactly the same as the ones computed in Post by massFlow.

I had a look at the solver documentation: it is not easy to figure the IP positions in a 3D mesh! Anyway as far as I understand if the mass flow rate is computed using the IP it is not exactly computed on the patch since IP are not located exactly on the boundary patch... Did I understand it well?

Thanks again.

Fabrizio.

Just one more thing about this.

I noted that using massFlow()@inlet and massFlow()@outlet() I recover the same results as the .out file mass balance.

But using massFlowInt(smoke)@outlet and massFlowInt(smoke)@inlet I get different results from the .out file balance...

Hi Fabrizo,

It is exactly computed on the boundary patch. It looks like the solver theory doesn't explicitly show this, but at boundaries an integration point is located on the boundary sub-face.

-CycLone

Is smoke introduced at your inlet or within the volume? If it is within the volume, the solver OUT file will include the internal sources in the balance.

-CycLone

So near boundaries integration points are forced to be on the boundary patches. Ok, this means I can trust blindly in what I get if the integral quantity is computed by using integration points..

Thanks.