CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Post-Processing (http://www.cfd-online.com/Forums/openfoam-post-processing/)
-   -   Problem with calcMassFlow (http://www.cfd-online.com/Forums/openfoam-post-processing/64324-problem-calcmassflow.html)

fightingfalcon23 May 7, 2009 05:00

Problem with calcMassFlow
 
Hi everyone,

I am using calcMassFlow and it was so easy until know. But actually I try to solve a strange problem:

I am working with the rho-option. When I use a rho >1 the tool works fine. But when I use a rho < 1 the tool shows volumeflow and not the massflow.

Does anybody know this problem and perhaps a solution?

Thanks for reading
fightigfalcon23

fightingfalcon23 May 7, 2009 05:12

One mor information

After some more test I know, that the tool calculates the massflow, but shows [m^3/s] as unit!

fightingfalcon23 May 18, 2009 10:38

Question changed
 
Hi everyone,

the problem isn't solved yet. But the question changed:

Does calcMassFlow work with the phi-field? I have a compressible case and I want to calculate the massflow. So I want the kg/s. But when I take a look into the c-file, I think, the tool is working with phi, so I don't have to define rho. My knowledge about programming is quite low. Can anybody explain me, how the tool works. For example the createPhi.h?

Thanks a lot for reading

Kind regards
ff23

gschaider May 19, 2009 18:06

Quote:

Originally Posted by fightingfalcon23 (Post 216524)
Hi everyone,

the problem isn't solved yet. But the question changed:

Does calcMassFlow work with the phi-field? I have a compressible case and I want to calculate the massflow. So I want the kg/s. But when I take a look into the c-file, I think, the tool is working with phi, so I don't have to define rho. My knowledge about programming is quite low. Can anybody explain me, how the tool works. For example the createPhi.h?

Thanks a lot for reading

Kind regards
ff23

The rho-option only makes sense for incompressible cases (http://openfoamwiki.net/index.php/Co...MassFlow#Usage). For compressible rho is already included in phi

Bernhard

fightingfalcon23 May 20, 2009 04:20

Thank you Bernhard for your answer. I assumed sth. like this! But why the tool uses the unit m^3/s instead of kg/s? And why the unit changes when the density strains 1?

Or short: When the rho-option in the calcMassFlowDict is commented. Do I get the massflow in kg/s no matter what unit is used in the output?

Regards
ff23

gschaider May 20, 2009 10:10

Quote:

Originally Posted by fightingfalcon23 (Post 216689)
Thank you Bernhard for your answer. I assumed sth. like this! But why the tool uses the unit m^3/s instead of kg/s? And why the unit changes when the density strains 1?

Or short: When the rho-option in the calcMassFlowDict is commented. Do I get the massflow in kg/s no matter what unit is used in the output?

Regards
ff23

The unit of the result depends on the unit of phi (which in turn depends on compressible/incompressibel), this is multiplied with the unit of an area and if a rho is found this is multiplied with the unit of rho THE WAY IT IS DEFINED IN THE PARAMETER FILE.

m^3/s is alright for the incompressible case ((kg/s)/(kg/m^3)). See discussions elsewhere ("Why is the viscosity wrong?" "Because there is no rho in it")

In my opinion the unit can not change because of the value. Are you sure that the dimensions of rho were not changed as well

Bernhard

heavy_user February 24, 2010 13:51

HI There (and special greetings to bernhard, again :D)

i might have discoverd "something"...

I figured a while ago that I had a non constant Massflow on an incompressible case on the Inlet, where U and P are assigned fixedValue(with pisoFoam) -> :confused:.
I used the calcMassflow tool on the inlet patch.

Using sample to get the velocity at z=0 (equal to inlet) I found that U_z was NOT equal to the U_z i assigned fixedValue.
Once I patched the InternalField with another Value than the Inlet i figured that "sample" used values from the internalField for the first cell(s) on the inlet boundary. The rest seems to be ok.


0/U:

Code:

internal field...

....
(0 0 67.5994)
(0 0 67.5306)
(0 0 66.1131)
(0 0 64.7139)
(0 0 62.9875)
(0 0 60.518)
(0 0 57.8623)
(0 0 54.5632)
(0 0 47.2048)
(0 0 11.1045)
(0 0 6.33799)
(0 0 7.44856)
(0 0 8.03774)
(0 0 8.36019)
(0 0 8.59227)
(0 0 8.74051)
(0 0 8.83197)
(0 0 8.89193)
(0 0 8.94192)
(0 0 8.99695)
(0 0 9.05744)
(0 0 9.09803)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
)
;

boundaryField
{
        inlet
    {
        type            fixedValue;
        value          nonuniform List<vector>
100
(
(0 0 53)
(0 0 53)
(0 0 53)
(0 0 53)
(0 0 53)
(0 0 53)
(0 0 53)
(0 0 53)
(0 0 53)
(0 0 53)
(0 0 53)
(0 0 53)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
)
;

    }
    sidewall
    {
        type            fixedValue;
        value          uniform (0 0 9.2);
    }
    sym
    {
        type            symmetryPlane;
    }
    frontandback
    {
        type            empty;
    }
    outlet
    {
        type            zeroGradient;
    }
}

results from sample @z=0 (Inlet) for t=0sec

Code:

Location(y)      Uz
0                  67.552
1.50015e-05    59.5432
3.0003e-05      58.9277
4.50045e-05    58.3122
6.0006e-05      57.6967
7.50075e-05    57.0812
9.0009e-05      56.4657
0.000105011    55.8502
0.000120012    55.2348
0.000135014    54.6193
0.000150015    54.0038
0.000165017    53.3883
0.000180018    53
0.00019502      53
0.000210021    53
0.000225023    53
0.000240024    53
0.000255026    53
0.000270027    53
0.000285029    53
0.00030003      53
0.000315032    53

The inlet with Uz=53m/sec is supposed to be 0.0026m wide and has 11 grid-points. (total inlet section is 0.15m with 100 grid points and a grading of 30)

So I came up with 2 possible reasons for that:

-1 ) BCs are messing with each other (at (0 0 0) I have a corner with inlet(all fixed value) and symmetryPlane crossing)

-2 ) Or "sample" and "calcMassflow" are adressing values stored in cells with z != 0 . (which i would bet on right now, since the values of the cell above the inlet-cell and the inlet cell with the strangevalue happen to be quite similar).


Since I have some oszillations in the flow, guess nr. 2 might also explain the variation of massflow, calculatet with "calcmassflow" on the inlet-patch, with time .

So whats the deal??

regards!

gschaider February 25, 2010 10:02

Quote:

Originally Posted by heavy_user (Post 247249)
HI There (and special greetings to bernhard, again :D)

Since I have some oszillations in the flow, guess nr. 2 might also explain the variation of massflow, calculatet with &quot;calcmassflow&quot; on the inlet-patch, with time .

So whats the deal??

regards!

If you're referring to the calcMassFlow-utility I published a long time ago: I deny all responsibility: that one doesn't bother with cell values. It calculates the mass flow by summing phi on the boundary patches (preferably the one written by the solver, otherwise calculates it with the usual rho*U&Sf)
Try patchIntegrate that comes with OF to double check.
Bernhard

heavy_user March 10, 2010 11:47

Quote:

Originally Posted by gschaider (Post 247399)
If you're referring to the calcMassFlow-utility I published a long time ago: I deny all responsibility: that one doesn't bother with cell values. It calculates the mass flow by summing phi on the boundary patches (preferably the one written by the solver, otherwise calculates it with the usual rho*U&Sf)
Try patchIntegrate that comes with OF to double check.
Bernhard

Hi Bernhard,

thanks for your reply!
I checked on things and your tool seems to be summing up correctly, as i supposed, of course!

I have been arround the issue for a while now, but i still dont get it.
Today I found that Phi, written by the solver, changes signs on the Inlet :eek:.
The inlet is supposed to have an Vz >0 everywhere. Vx and Vy equal 0.
It is a plain surface. The elemtents of the surface all have positive Areas.
I hope that I have no negative density ;).

I used pisoFoam for the calculation.
And if you take a look here, I think OF might do strange things...

Flux at Inlet:

Code:

inlet
    {
        type            calculated;
        value          nonuniform List<scalar>
100
(
-1.25981e-05
-1.30805e-05
-1.33893e-05
-1.36134e-05
-1.38567e-05
-1.40602e-05
-1.41434e-05
-1.41355e-05
-1.4095e-05
-1.3902e-05
-1.31093e-05
-9.64385e-06
1.7047e-07
-1.74841e-06
-2.05471e-06
-2.25842e-06

-2.40662e-06
-2.54314e-06
-2.66513e-06
-2.77539e-06
-2.87822e-06
-2.97853e-06
-3.08141e-06
-3.19131e-06
-3.31188e-06
-3.43418e-06
-3.60092e-06
-3.71049e-06
-3.82419e-06
-3.94185e-06
-4.06364e-06
-4.18971e-06
-4.32012e-06
-4.45501e-06
-4.59444e-06
-4.73854e-06
-4.88737e-06
-5.04103e-06
-5.19963e-06
-5.36327e-06
-5.53207e-06
-5.70612e-06
-5.88557e-06
-6.07059e-06
-6.26128e-06
-6.4577e-06
-6.65992e-06
-6.86808e-06
-7.08232e-06
-7.30207e-06
-7.52482e-06
-7.76061e-06
-8.00158e-06
-8.24945e-06
-8.50465e-06
-8.76747e-06
-9.03807e-06
-9.31671e-06
-9.60457e-06
-9.89892e-06
-1.02011e-05
-1.05115e-05
-1.08309e-05
-1.11605e-05
-1.15004e-05
-1.18502e-05
-1.22089e-05
-1.25791e-05
-1.29589e-05
-1.33496e-05
-1.37506e-05
-1.41629e-05
-1.4587e-05
-1.50224e-05
-1.54696e-05
-1.59294e-05
-1.64026e-05
-1.68883e-05
-1.73874e-05
-1.79009e-05
-1.84308e-05
-1.8977e-05
-1.95397e-05
-2.01193e-05
-2.07192e-05
-2.13353e-05
-2.19705e-05
-2.26241e-05
-2.32976e-05
-2.39955e-05
-2.47173e-05
-2.54673e-05
-2.62533e-05
-2.7059e-05
-2.7894e-05
-2.87623e-05
-2.96668e-05
-3.06039e-05
-3.15747e-05
-3.24931e-05
)
;
    }

Velocity at inlet Patch:

Code:

inlet
    {
        type            fixedValue;
        value          nonuniform List<vector>
100
(
(0 0 67.552)
(0 0 67.77)
(0 0 67.035)
(0 0 65.8686)
(0 0 64.7974)
(0 0 63.5496)
(0 0 61.7962)
(0 0 59.7163)
(0 0 57.5885)
(0 0 54.9667)
(0 0 50.2231)
(0 0 36.2949)
(0 0 0.315833)
(0 0 6.57834)

(0 0 7.44999)
(0 0 7.96628)
(0 0 8.26225)
(0 0 8.49278)
(0 0 8.65498)
(0 0 8.76455)
(0 0 8.83736)
(0 0 8.88867)
(0 0 8.932)
(0 0 8.97775)
(0 0 9.03216)
(0 0 9.0771)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
(0 0 9.2)
)
;
    }

Pressure @inlet
Code:

    inlet
    {
        type            fixedValue;
        value          uniform 101325;
    }

so what is goin on??

The only thing I found on that is UG P77, which says:

phi = (fvc::interpolate(U) & mesh.Sf()) + fvc::ddtPhiCorr(rUA, U, phi);

Which leaves the only conclusion that the Correct-Function is messing with my BC.
I consulted some literature, which says, that non reflecting BC can lead to non constant flux.
I used perfectly reflecting BC (fixed U and p) since I have to impose something.
The shearlayer (see U-profile) produces some waves, which I can observe....but... :confused:

any ideas?

regards!

gschaider March 15, 2010 06:45

Quote:

Originally Posted by heavy_user (Post 249378)
so what is goin on??

The only thing I found on that is UG P77, which says:

phi = (fvc::interpolate(U) & mesh.Sf()) + fvc::ddtPhiCorr(rUA, U, phi);

Which leaves the only conclusion that the Correct-Function is messing with my BC.
I consulted some literature, which says, that non reflecting BC can lead to non constant flux.
I used perfectly reflecting BC (fixed U and p) since I have to impose something.
The shearlayer (see U-profile) produces some waves, which I can observe....but... :confused:

any ideas?

regards!

The other culprit could be the interpolate(U). But I think this is no more a calcMassFlow-problem

Bernhard

heavy_user March 15, 2010 07:13

Quote:

Originally Posted by gschaider (Post 249987)
The other culprit could be the interpolate(U). But I think this is no more a calcMassFlow-problem

Bernhard

Hi Bernhard,

it is most certainly not a problem of calcMassFlow, since i did not use it.
The things posted above are from an Time-Folder created by OF "solving" the case.

But how can the sign change during that interpolation??

regards!

gschaider March 15, 2010 09:43

Quote:

Originally Posted by heavy_user (Post 249994)
Hi Bernhard,

it is most certainly not a problem of calcMassFlow, since i did not use it.
The things posted above are from an Time-Folder created by OF "solving" the case.

But how can the sign change during that interpolation??

regards!

If it interpolates from a large value to a small value and ignores that prescribed the value on the patch it might undershoot. Just an idea. But I'd have to look at the implementation to see if that could be the case

Bernhard


All times are GMT -4. The time now is 14:49.