CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Programming & Development

Volume Average for magnitude U

Register Blogs Community New Posts Updated Threads Search

Like Tree9Likes

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   September 3, 2012, 17:22
Default Volume Average for magnitude U
  #1
Senior Member
 
Mojtaba.a's Avatar
 
Mojtaba Amiraslanpour
Join Date: Jun 2011
Location: Tampa, US
Posts: 308
Rep Power: 15
Mojtaba.a is on a distinguished road
Send a message via Skype™ to Mojtaba.a
Hi,
I am using simpleFunctionObject to average some fields in volume. I can do this for simple filelds like T. for instance I add the following code into controlDict file:

Quote:
functions
(
temp_average
{
type volumeAverage;
functionObjectLibs
(
"libsimpleFunctionObjects.so"
);
verbose true;
fields (T);
}
);
But I don't know how to to do this for total velocity magnitude. When I use U instead of T in above code, I get average volume of velocity vector. I need average velocity magnitude.
How can I do that? any suggestions?
mm.abdollahzadeh likes this.
Mojtaba.a is offline   Reply With Quote

Old   September 3, 2012, 17:42
Default
  #2
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,225
Rep Power: 51
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by Mojtaba.a View Post
Hi,
I am using simpleFunctionObject to average some fields in volume. I can do this for simple filelds like T. for instance I add the following code into controlDict file:

But I don't know how to to do this for total velocity magnitude. When I use U instead of T in above code, I get average volume of velocity vector. I need average velocity magnitude.
How can I do that? any suggestions?
With the big brother of the simpleFunctionObjects: swak4Foam. Something like:

Code:
functions
{
  velAverage
  {
     type swakExpression;
     functionObjectLibs
     (
       "libsimpleSwakFunctionObjects.so"
     );
     verbose true;
     variables (
        "totalV=sum(vol());"
     );
     expression "vol()*mag(U)/totalV";
     accumulations (
        sum
     );
}
);
That would be the volume-weighted average.

An alternative would be to construct a separate field:
Code:
functions
{
    makeMagU {
       type expressionField;
         functionObjectLibs
        (
            "libswakFunctionObjects.so"
        );      autowrite false;
       fieldName magU;
       expression "mag(U)";
    }
    temp_average
    {
        type volumeAverage;
        functionObjectLibs
        (
            "libsimpleFunctionObjects.so"
        );
        verbose true;
        fields (magU);
    }
}
caduqued, kaifu and Mojtaba.a like this.
gschaider is offline   Reply With Quote

Old   September 4, 2012, 02:07
Default
  #3
Senior Member
 
Mojtaba.a's Avatar
 
Mojtaba Amiraslanpour
Join Date: Jun 2011
Location: Tampa, US
Posts: 308
Rep Power: 15
Mojtaba.a is on a distinguished road
Send a message via Skype™ to Mojtaba.a
Hi Bernhard and thanks for your useful answer. there is problem I have while running my case. When I use your second code in controlDict File, I get the following error message in openFOAM:

Quote:
--> FOAM Warning :
From function dlLibraryTable:pen(const fileName&, const bool)
in file db/dynamicLibrary/dlLibraryTable/dlLibraryTable.C at line 96
could not load "libswakFunctionObjects.so"
--> FOAM Warning :
From function dlLibraryTable:pen(const dictionary&, const word&, const TablePtr&)
in file lnInclude/dlLibraryTableTemplates.C at line 67
Could not open library "libswakFunctionObjects.so"



--> FOAM FATAL ERROR:
Unknown function type expressionField

Valid functions are :

23
(
executeIfEnvironmentVariable
executeIfExecutableFits
executeIfFunctionObjectPresent
executeIfObjectExists
functionObjectListProxy
initSwakFunctionObject
panicDump
patchAverage
patchFieldFlow
patchIntegrate
patchMassFlow
patchMassFlowAverage
patchProbes
probes
readGravitation
sets
surfaces
trackDictionary
volumeAverage
volumeIntegrate
volumeMinMax
writeAdditionalFields
writeFieldsOften
)



From function functionObject::New(const word& name, const Time&, const dictionary&)
in file db/functionObjects/functionObject/functionObject.C at line 89.

FOAM exiting
and when I use your first code I get the following error:

Quote:
--> FOAM FATAL IO ERROR:
keyword valueType is undefined in dictionary "::vel_average"

file: ::vel_average from line 65 to line 77.

From function dictionary::lookupEntry(const word&, bool, bool) const
in file db/dictionary/dictionary.C at line 400.

FOAM exiting
I have compiled swak4Foam without any error (maybe just some warnings), can you please help me in this manner?
Mojtaba.a is offline   Reply With Quote

Old   September 4, 2012, 06:08
Default
  #4
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,225
Rep Power: 51
gschaider will become famous soon enoughgschaider will become famous soon enough
Sorry. I should have said that I wrote the examples without testing them:
Quote:
Originally Posted by Mojtaba.a View Post
Hi Bernhard and thanks for your useful answer. there is problem I have while running my case. When I use your second code in controlDict File, I get the following error message in openFOAM:
I expected a typo in the library but I can't find it. Check with

ls $FOAM_USER_LIBBIN/libswakFunctionObjects.so

if it really exists.

Quote:
Originally Posted by Mojtaba.a View Post
and when I use your first code I get the following error:


I have compiled swak4Foam without any error (maybe just some warnings), can you please help me in this manner?
This one is easy. Forgot

valueType internalField;

BTW: this is generally applicable for working with OpenFOAM: if it is complaining about a missing entry then add that entry (in this case valueType) and then use the "banana trick": http://openfoamwiki.net/index.php/Op...de/Use_bananas
Mojtaba.a likes this.
gschaider is offline   Reply With Quote

Old   September 4, 2012, 08:07
Default
  #5
Senior Member
 
Mojtaba.a's Avatar
 
Mojtaba Amiraslanpour
Join Date: Jun 2011
Location: Tampa, US
Posts: 308
Rep Power: 15
Mojtaba.a is on a distinguished road
Send a message via Skype™ to Mojtaba.a
Quote:
Originally Posted by gschaider View Post
Sorry. I should have said that I wrote the examples without testing them:


I expected a typo in the library but I can't find it. Check with

ls $FOAM_USER_LIBBIN/libswakFunctionObjects.so

if it really exists.
You are right, it doesn't exists. now How can I find libswakFunctionObjects.so and put it in this folder? Am I going to do this manually?

Quote:
This one is easy. Forgot
valueType internalField;

BTW: this is generally applicable for working with OpenFOAM: if it is complaining about a missing entry then add that entry (in this case valueType) and then use the "banana trick": http://openfoamwiki.net/index.php/Op...de/Use_bananas
yea,Thanks, this solved the problem. banana trick rules !
Mojtaba.a is offline   Reply With Quote

Old   September 4, 2012, 10:32
Default
  #6
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,225
Rep Power: 51
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by Mojtaba.a View Post
You are right, it doesn't exists. now How can I find libswakFunctionObjects.so and put it in this folder? Am I going to do this manually?
No. Either rerun the compilation and see if thee is a problem with that lib or (more likely) I mistyped the test. Have a look in $FOAM_USER_LIBBIN for a similar name

Quote:
Originally Posted by Mojtaba.a View Post
yea,Thanks, this solved the problem. banana trick rules !
Good
gschaider is offline   Reply With Quote

Old   September 4, 2012, 13:00
Default
  #7
Senior Member
 
Mojtaba.a's Avatar
 
Mojtaba Amiraslanpour
Join Date: Jun 2011
Location: Tampa, US
Posts: 308
Rep Power: 15
Mojtaba.a is on a distinguished road
Send a message via Skype™ to Mojtaba.a
Quote:
Originally Posted by gschaider View Post
No. Either rerun the compilation and see if thee is a problem with that lib or (more likely) I mistyped the test. Have a look in $FOAM_USER_LIBBIN for a similar name
I cleaned and recompiled swak4Foam.There is no libswakFunctionObjects.so in $FOAM_USER_LIBBIN again.
I have attached the log file of recompilation.
Attached Files
File Type: gz make.log.tar.gz (6.7 KB, 9 views)
Mojtaba.a is offline   Reply With Quote

Old   September 4, 2012, 13:33
Default
  #8
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,225
Rep Power: 51
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by Mojtaba.a View Post
I cleaned and recompiled swak4Foam.There is no libswakFunctionObjects.so in $FOAM_USER_LIBBIN again.
I have attached the log file of recompilation.
OK. Seems you're working with a OF 2.0 and there was a change in the interface of the coded-FunctionObject. Go to Libraries/swakFunctionObjects/Make/files and remove the line with swakCodedFunctionObject.C (you won't miss it). Then that library should compile.

Also go to Libraries/Allwmake and in the first line replace /bin/sh with /bin/bash
Mojtaba.a likes this.
gschaider is offline   Reply With Quote

Old   September 4, 2012, 14:00
Default
  #9
Senior Member
 
Mojtaba.a's Avatar
 
Mojtaba Amiraslanpour
Join Date: Jun 2011
Location: Tampa, US
Posts: 308
Rep Power: 15
Mojtaba.a is on a distinguished road
Send a message via Skype™ to Mojtaba.a
Quote:
Originally Posted by gschaider View Post
OK. Seems you're working with a OF 2.0 and there was a change in the interface of the coded-FunctionObject. Go to Libraries/swakFunctionObjects/Make/files and remove the line with swakCodedFunctionObject.C (you won't miss it). Then that library should compile.

Also go to Libraries/Allwmake and in the first line replace /bin/sh with /bin/bash
Wow, Thanks Bernhard ! Now it works like a charm ! I have libswakFunctionObjects.so in $FOAM_USER_LIBBIN right now !

Bernhard is there any way to define a new volume to calculate averages in this specified volume?
Mojtaba.a is offline   Reply With Quote

Old   September 4, 2012, 14:18
Default
  #10
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,225
Rep Power: 51
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by Mojtaba.a View Post
Wow, Thanks Bernhard ! Now it works like a charm ! I have libswakFunctionObjects.so in $FOAM_USER_LIBBIN right now !

Bernhard is there any way to define a new volume to calculate averages in this specified volume?
swak can do calculations on cellZones and cellSets if that's what you mean.

Specification of zones and set is either done in the mesh generator or with the topoSet (or the setSet)-utility. But the usage of those has nothing to do with swak4Foam (except that swak provides topoSources based on expressions)
gschaider is offline   Reply With Quote

Old   September 4, 2012, 14:39
Default
  #11
Senior Member
 
Mojtaba.a's Avatar
 
Mojtaba Amiraslanpour
Join Date: Jun 2011
Location: Tampa, US
Posts: 308
Rep Power: 15
Mojtaba.a is on a distinguished road
Send a message via Skype™ to Mojtaba.a
Quote:
Originally Posted by gschaider View Post
swak can do calculations on cellZones and cellSets if that's what you mean.

Specification of zones and set is either done in the mesh generator or with the topoSet (or the setSet)-utility. But the usage of those has nothing to do with swak4Foam (except that swak provides topoSources based on expressions)
You mean that if i make a zone using toposet or the setset utility, I can not use this zone in swak4Foam?
Mojtaba.a is offline   Reply With Quote

Old   September 4, 2012, 14:52
Default
  #12
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,225
Rep Power: 51
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by Mojtaba.a View Post
You mean that if i make a zone using toposet or the setset utility, I can not use this zone in swak4Foam?
No. I just mean that I don't feel responsible for them and won't explain them in detail
Mojtaba.a likes this.
gschaider is offline   Reply With Quote

Old   September 4, 2012, 15:27
Default
  #13
Senior Member
 
Mojtaba.a's Avatar
 
Mojtaba Amiraslanpour
Join Date: Jun 2011
Location: Tampa, US
Posts: 308
Rep Power: 15
Mojtaba.a is on a distinguished road
Send a message via Skype™ to Mojtaba.a
Quote:
Originally Posted by gschaider View Post
No. I just mean that I don't feel responsible for them and won't explain them in detail
Bernhard, Thank you for your grateful help.
Mojtaba.a is offline   Reply With Quote

Old   October 17, 2012, 11:46
Default
  #14
Member
 
Simon Arne
Join Date: May 2012
Posts: 42
Rep Power: 13
simpomann is on a distinguished road
Hey,

I am sorry to bring this up again, but I experience problems with the described way of calculating the average mag(U) over a plane.


I have a simple pipe (flow is 12m/s with air, laminar, no turb model yet) and added the following to my controlDict:

Code:
functions
{
    makeMagU {
       type expressionField;
         functionObjectLibs
        (
            "libswakFunctionObjects.so"
        );      autowrite false;
       fieldName magU;
       expression "mag(U)";
    }
    makerho {
       type expressionField;
         functionObjectLibs
        (
            "libswakFunctionObjects.so"
        );      autowrite false;
       fieldName rho;
       expression "1.199";
    }

messung_40d
    {
        type            faceSource;
        functionObjectLibs ("libfieldFunctionObjects.so");

        enabled         true;
        outputControl   outputTime;

        // Output to log&file (true) or to file only
        log             true;

        // Output field values as well
        valueOutput     true;  //true;

        // Type of source: patch/faceZone/sampledSurface
        source          sampledSurface;

        sampledSurfaceDict
        {
                type cuttingPlane;
                planeType           pointAndNormal;
                pointAndNormalDict
                {
                        basePoint       (0.185 0 0);  
                        normalVector    (1 0 0);
                }
                source cells; // sample cells or boundaryFaces
                interpolate true;
        }
        // Operation: areaAverage/sum/weightedAverage ...
        operation       areaAverage;

        fields
        (
            p
            U
        magU
        );
    }

messung_48d
    {
        type            faceSource;
        functionObjectLibs ("libfieldFunctionObjects.so");

        enabled         true;
        outputControl   outputTime;

        // Output to log&file (true) or to file only
        log             true;

        // Output field values as well
        valueOutput     true;  //true;

        // Type of source: patch/faceZone/sampledSurface
        source          sampledSurface;

        sampledSurfaceDict
        {
                type cuttingPlane;
                planeType           pointAndNormal;
                pointAndNormalDict
                {
                        basePoint       (0.281 0 0);
                        normalVector    (1 0 0);
                }
                source cells; // sample cells or boundaryFaces
                interpolate true;
        }
        // Operation: areaAverage/sum/weightedAverage ...
        operation       areaAverage;

        fields
        (
            p
            U
        magU
        );
    }


}
And I get an output over my plane (cut through the pipe after 40 diameters, flow is straight x-directional):
Code:
# Source : sampledSurface sampledSurface
# Faces  : 204
# Time    sum(magSf)    areaAverage(p)    areaAverage(U)    areaAverage(magU)
100    0.000104042    -0.511471    (14.8039 0.00143989 0.0096608)    14.804
200    0.000104042    -1.07848    (15.1898 -0.002704 0.00862669)    15.1898
300    0.000104042    -1.10052    (15.2711 -0.002448 0.00478738)    15.2711
400    0.000104042    -1.13157    (15.2688 -0.00338944 0.00642759)    15.2688
500    0.000104042    -1.05324    (15.2643 -0.00676656 0.00863005)    15.2643
600    0.000104042    -1.30854    (15.2804 -0.00189827 0.00590263)    15.2804
700    0.000104042    -1.30885    (15.2774 -0.00181508 0.00626128)    15.2774
800    0.000104042    -1.29363    (15.2785 -0.00386213 0.00488485)    15.2785
900    0.000104042    -1.29393    (15.278 -0.00271772 0.00544641)    15.2781
1000    0.000104042    -1.28934    (15.2778 -0.00274002 0.00545235)    15.2781
If I load the case into paraView, slice at the same distance, extract and integrate variables (cell values) I end up with a more reasonable mag(U) average of 12.009.

What did I do wrong here?
I thought my lines to the control dict would just create a field mag(U) out of the calculated U vector field and then place a slice through it and calculate an average.
Is it possible that the SWAK-code leaves out cells with a mag(U) value of 0 for some reason? My mesh is pretty rough, so a high percentage of the cells actually has the wall boundary condition of U = (0 0 0).

I found out that my average values for pressure seem to be perfectly fine (SWAK sampling and manual paraView pp lead to the exact same numbers)!
So its only a mag(U) thing here...

Last edited by simpomann; October 17, 2012 at 12:24.
simpomann is offline   Reply With Quote

Old   October 17, 2012, 12:52
Default
  #15
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,225
Rep Power: 51
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by simpomann View Post
Hey,

I am sorry to bring this up again, but I experience problems with the described way of calculating the average mag(U) over a plane.


I have a simple pipe (flow is 12m/s with air, laminar, no turb model yet) and added the following to my controlDict:

<snip>

And I get an output over my plane (cut through the pipe after 40 diameters, flow is straight x-directional):
Code:
# Source : sampledSurface sampledSurface
# Faces  : 204
# Time    sum(magSf)    areaAverage(p)    areaAverage(U)    areaAverage(magU)
100    0.000104042    -0.511471    (14.8039 0.00143989 0.0096608)    14.804
200    0.000104042    -1.07848    (15.1898 -0.002704 0.00862669)    15.1898
300    0.000104042    -1.10052    (15.2711 -0.002448 0.00478738)    15.2711
400    0.000104042    -1.13157    (15.2688 -0.00338944 0.00642759)    15.2688
500    0.000104042    -1.05324    (15.2643 -0.00676656 0.00863005)    15.2643
600    0.000104042    -1.30854    (15.2804 -0.00189827 0.00590263)    15.2804
700    0.000104042    -1.30885    (15.2774 -0.00181508 0.00626128)    15.2774
800    0.000104042    -1.29363    (15.2785 -0.00386213 0.00488485)    15.2785
900    0.000104042    -1.29393    (15.278 -0.00271772 0.00544641)    15.2781
1000    0.000104042    -1.28934    (15.2778 -0.00274002 0.00545235)    15.2781
If I load the case into paraView, slice at the same distance, extract and integrate variables (cell values) I end up with a more reasonable mag(U) average of 12.009.

What did I do wrong here?
I thought my lines to the control dict would just create a field mag(U) out of the calculated U vector field and then place a slice through it and calculate an average.
Is it possible that the SWAK-code leaves out cells with a mag(U) value of 0 for some reason? My mesh is pretty rough, so a high percentage of the cells actually has the wall boundary condition of U = (0 0 0).

I found out that my average values for pressure seem to be perfectly fine (SWAK sampling and manual paraView pp lead to the exact same numbers)!
So its only a mag(U) thing here...
I really love a good bug-hunt as much as the next guy but I'm afraid I'm not going to go hunting here (at least not in swak). Have a look at the averages of U (which are untouched by swak): they're completely consistent with the ones for mag(U). So I'd say the problem is in the faceSource. Or the velocity field is not what you expect it to be.

What you can do to check is:
- set autowrite for magU to true and check it in Paraview
- emulate the area-weighted average in with a swakExpression on the same sampledSurface (I think the expression would be "mag(U)*area()/sum(area())" with an accumulation sum)
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request
gschaider is offline   Reply With Quote

Old   October 17, 2012, 15:54
Default
  #16
Member
 
Simon Arne
Join Date: May 2012
Posts: 42
Rep Power: 13
simpomann is on a distinguished road
Hey,

Great thanks for your quick reply!
I checked the magU field, slicing and integrating it in a paraView leads to 12.05 m/s, so the field data actually seems to be ok!

The problem seems to be the sampled Surface (as you suggested). But is it a user fault or a bug?
I tested the same function object in different cases, the results for velocity were always a bit higher than expected and they differ from those obtained in paraView up to 20%. The results from paraView always seem more accurate to me (considering my expectations/boundary etc).
As it is working out for the pressure field perfectly, I would say the sampled Surface is defined and adressed correctly, there must be something in the way this deals with the mag(U) field.
Because I am only a user (and student), I lack the knowledge to understand the problem.

I try to make use of your second advice but i struggle with the code. I put an update here asap.

# "keyword weightField is undefined" , lets see if I can find out where I have to initialise this one
# okay, i think i figured out the place for the code
#okay i was wrong!

Last edited by simpomann; October 18, 2012 at 05:44.
simpomann is offline   Reply With Quote

Old   October 17, 2012, 17:37
Default
  #17
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,225
Rep Power: 51
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by simpomann View Post
Hey,

Great thanks for your quick reply!
I checked the magU field, slicing and integrating it in a paraView leads to 12.05 m/s, so the field data actually seems to be ok!

The problem seems to be the sampled Surface (as you suggested). But is it a user fault or a bug?
I tested the same function object in different cases, the results for velocity were always a bit higher than expected and they differ from those obtained in paraView up to 20%. The results from paraView always seem more accurate to me (considering my expectations/boundary etc).
As it is working out for the pressure field perfectly, I would say the sampled Surface is defined and adressed correctly, there must be something in the way this deals with the mag(U) field.
Because I am only a user (and student), I lack the knowledge to understand the problem.
Can't comment on that. Are you using the latest version (because you might have stumbled on a bug that might already be fixed ... but that is just a guess).

If the problem is in the sampledSurface-code then it will affect swak too. If it is in the faceSource-code ... not

Quote:
Originally Posted by simpomann View Post
I try to make use of your second advice but i struggle with the code. I put an update here asap.

# "keyword weightField is undefined" , lets see if I can find out where I have to initialise this one
# okay, i think i figured out the place for the code
#okay i was wrong!

What I understood: For a weighted average I have to initialise another Field, so I tried and added:
Code:
    makegewichtungsfeld {
       type expressionField;
         functionObjectLibs
        (
            "libswakFunctionObjects.so"
        );      autowrite true;
       fieldName gewichtungsfeld;
       expression "magU*area()/sum(area())";
    }
And I modified the function object for the measurement:
Code:
messung_40d
    {
        type            faceSource;
        functionObjectLibs ("libfieldFunctionObjects.so");

        enabled         true;
        outputControl   outputTime;

        // Output to log&file (true) or to file only
        log             true;

        // Output field values as well
        valueOutput     true;  //true;

        // Type of source: patch/faceZone/sampledSurface
        source          sampledSurface;

        sampledSurfaceDict
        {
                type cuttingPlane;
                planeType           pointAndNormal;
                pointAndNormalDict
                {
                        basePoint       (0.185 0 0);  
                        normalVector    (1 0 0);
                }
                source cells; // sample cells or boundaryFaces
                interpolate false;
        }
        // Operation: areaAverage/sum/weightedAverage ...
        operation       weightedAverage;
    weightField     gewichtungsfeld;

        fields
        (
        magU
        );
    }
But potential and simpleFoam end up with this error
Code:
--> FOAM FATAL ERROR: 
 Parser Error at "1.6-9" :"syntax error, unexpected TOKEN_area"
"magU*area()/sum(area())"
"      ^^^^             "
Best thanks,

Simon
You got it wrong. You've got to create a sampled surface and then you can do calculations on that. I'll sketch it. You'll have to adapt it to your case (especially the sampledSurface)
Code:
    createPlane
    {
        type createSampledSurface;
        outputControl timeStep;
        outputInterval 1;
        surfaceName plane;
        surface {
  <insert your sampled surface definition here>
        }
    }
    magUAverage
    {
        type swakExpression;
        valueType surface;
        surfaceName plane;
        verbose true;
        expression "mag(U)*area()/sum(area())";
        accumulations (
            sum
        );
    }
The second one just calculates the weighted average over surface (area() is the size of the faces on the surface)

Clearer?
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request
gschaider is offline   Reply With Quote

Old   October 17, 2012, 18:13
Default
  #18
Member
 
Simon Arne
Join Date: May 2012
Posts: 42
Rep Power: 13
simpomann is on a distinguished road
Big thanks,

with this code I can observe the mag(U) value on a self defined plane for each time step!
Wonderful!


This was very helpful. Unluckily the behaviour is the same like the other function object

Greetings,
Simon

Last edited by simpomann; October 17, 2012 at 18:59.
simpomann is offline   Reply With Quote

Old   October 18, 2012, 05:35
Default
  #19
Member
 
Simon Arne
Join Date: May 2012
Posts: 42
Rep Power: 13
simpomann is on a distinguished road
So I tried with your work around as well:
Code:
#         Time          sum
            1      12.0545
            2      12.2684
            3      12.4398
            4      12.7395
            5      12.8805
....
           45      14.2587
           46      14.2731
           47      14.2887
           48      14.3114
           49      14.3319
           50      14.3429
The results are the same like with the other function object (sorry for not using the appropriate names). I checked various time steps manually with paraView and the magU-field created by a function object and the U field (standard) come up to 12 m/s in average no matter which time I look at (at the same point in the mesh), so the fields are okay.

With every timestep the difference between the actual field values and the processed average becomes bigger.

I use Ubuntu 12.04, OF 210 and compiled SWAK 1 month ago so it should be up to date i guess, although I dont know exactly how can i verify this.
simpomann is offline   Reply With Quote

Old   October 18, 2012, 05:56
Default
  #20
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,225
Rep Power: 51
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by simpomann View Post
Big thanks,

with this code I can observe the mag(U) value on a self defined plane for each time step!
Wonderful!
Glad you like it

If you feel like giving back it would be nice if you consider adding this as a little recipie on the openfoamwiki.net (either on the swak-page or linked from it)

Quote:
Originally Posted by simpomann View Post
This was very helpful. Unluckily the behaviour is the same like the other function object
OK. Then my guess is that there is a problem with the underlying sampledSurface (as paraview seems to report the expected values. But just in case: recheck that you used the same data in paraview. It happened before). Several things to try

- check if the area of the surface is as expected (calculate "area()" with an accumulation "sum" on the surface). But that would be too easy
- use the sample-utilitiy to write VTKs of the surface and check in Paraview whether the values there are the same as the ones you get when cutting the volume data in paraview
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request
gschaider is offline   Reply With Quote

Reply


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 Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
[Other] mesh airfoil NACA0012 anand_30 OpenFOAM Meshing & Mesh Conversion 13 March 7, 2022 17:22
how to set periodic boundary conditions Ganesh FLUENT 15 November 18, 2020 06:09
On the damBreak4phaseFine cases paean OpenFOAM Running, Solving & CFD 0 November 14, 2008 21:14
fluent add additional zones for the mesh file SSL FLUENT 2 January 26, 2008 11:55
[blockMesh] Axisymmetrical mesh Rasmus Gjesing (Gjesing) OpenFOAM Meshing & Mesh Conversion 10 April 2, 2007 14:00


All times are GMT -4. The time now is 02:04.