CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Post-Processing

Problem with calcMassFlow

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Display Modes
Old   May 7, 2009, 05:00
Default Problem with calcMassFlow
  #1
Member
 
Sebastian
Join Date: Mar 2009
Location: Munich, Germany
Posts: 30
Rep Power: 8
fightingfalcon23 is on a distinguished road
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 is offline   Reply With Quote

Old   May 7, 2009, 05:12
Default
  #2
Member
 
Sebastian
Join Date: Mar 2009
Location: Munich, Germany
Posts: 30
Rep Power: 8
fightingfalcon23 is on a distinguished road
One mor information

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

Old   May 18, 2009, 10:38
Default Question changed
  #3
Member
 
Sebastian
Join Date: Mar 2009
Location: Munich, Germany
Posts: 30
Rep Power: 8
fightingfalcon23 is on a distinguished road
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
fightingfalcon23 is offline   Reply With Quote

Old   May 19, 2009, 18:06
Default
  #4
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,915
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by fightingfalcon23 View Post
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
gschaider is offline   Reply With Quote

Old   May 20, 2009, 04:20
Default
  #5
Member
 
Sebastian
Join Date: Mar 2009
Location: Munich, Germany
Posts: 30
Rep Power: 8
fightingfalcon23 is on a distinguished road
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
fightingfalcon23 is offline   Reply With Quote

Old   May 20, 2009, 10:10
Default
  #6
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,915
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by fightingfalcon23 View Post
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
gschaider is offline   Reply With Quote

Old   February 24, 2010, 13:51
Default
  #7
Senior Member
 
Join Date: Dec 2009
Posts: 112
Rep Power: 7
heavy_user is on a distinguished road
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:

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!
heavy_user is offline   Reply With Quote

Old   February 25, 2010, 10:02
Default
  #8
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,915
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by heavy_user View Post
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
gschaider is offline   Reply With Quote

Old   March 10, 2010, 11:47
Default
  #9
Senior Member
 
Join Date: Dec 2009
Posts: 112
Rep Power: 7
heavy_user is on a distinguished road
Quote:
Originally Posted by gschaider View Post
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:

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

any ideas?

regards!
heavy_user is offline   Reply With Quote

Old   March 15, 2010, 06:45
Default
  #10
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,915
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by heavy_user View Post
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
gschaider is offline   Reply With Quote

Old   March 15, 2010, 07:13
Default
  #11
Senior Member
 
Join Date: Dec 2009
Posts: 112
Rep Power: 7
heavy_user is on a distinguished road
Quote:
Originally Posted by gschaider View Post
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!
heavy_user is offline   Reply With Quote

Old   March 15, 2010, 09:43
Default
  #12
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,915
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by heavy_user View Post
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
gschaider is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
UDF compiling problem Wouter Fluent UDF and Scheme Programming 6 June 6, 2012 04:43
Incoherent problem table in hollow-fiber spinning Gianni FLUENT 0 April 5, 2008 10:33
natural convection problem for a CHT problem Se-Hee CFX 2 June 10, 2007 06:29
Adiabatic and Rotating wall (Convection problem) ParodDav CFX 5 April 29, 2007 19:13
Is this problem well posed? Thomas P. Abraham Main CFD Forum 5 September 8, 1999 14:52


All times are GMT -4. The time now is 21:31.