[fightingfalcon23]

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]

One mor information

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

[fightingfalcon23]

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]

Originally Posted by fightingfalcon23

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]

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]

Originally Posted by fightingfalcon23

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]

HI There (and special greetings to bernhard, again )

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) -> .
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:

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

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]

Originally Posted by heavy_user

HI There (and special greetings to bernhard, again )

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]

Originally Posted by gschaider

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 .
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:

 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:

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

    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...

any ideas?

regards!

[gschaider]

Originally Posted by heavy_user

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...

any ideas?

regards!

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

Bernhard

[heavy_user]

Originally Posted by gschaider

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]

Originally Posted by heavy_user

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