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

execFlowFunctionObjects

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

Like Tree4Likes
  • 2 Post By thomasArk47
  • 1 Post By wyldckat
  • 1 Post By Nucleophobe

Reply
 
LinkBack Thread Tools Display Modes
Old   March 23, 2010, 03:06
Default execFlowFunctionObjects
  #1
New Member
 
Alexis Espinosa
Join Date: Aug 2009
Location: Australia
Posts: 12
Rep Power: 7
alexisespinosa is on a distinguished road
I do not know exactly if this is a bug, because I do not know exactly if execFlowFunctionObjects utility was intended to have this behaviour, but I think something should be fixed anyway. Here is the story:

I tried to use execFlowFunctionObjects to postprocess my data from all saved timesteps.

My data come from a simulation from 0 to 500.0 seconds saved every 0.5s. I have U,p and phi saved in every timestep directory. The problem is that I did not set the force calculation during the icoFoam run. So I do not have the variation of the forces along time over my cylinder.

Now, instead of running the case again with the settings in the controlDict dictionary, I tried to use execFlowFunctionsObjects utility to postprocess the data that I have already saved. All the information for calculating the forces over my cylinder is there, so I was hoping that i could avoid running the case again.

I thought that execFlowFunctionObjects could do that work?
Was this utility created for doing this kind of work?

So, I set the force function in the controlDict dictionary and ran execFlowFunctionsObjects utility. It asked me to set the transport model in the Transport dictionary, and I did it to Newtonian. Then it ran and sent messages to the screen that it was processing every saved timestep !!! And it almost did it!!!! It took some time to postprocess the 1001 saved time steps, BUT AT THE END I JUST GOT ONE LINE IN THE forces.dat file, a line with the forces for the last time step (500.0)

So, The utility read and calculated the forces for every saved time step, but at the end it just gave me the result for the last time step. I suppose that this is a bug!!!

I ran the utility again to see what was happening and indeed, it is processing every time step and saving the forces.dat for every calculated force, but the problem is that it generates a forces.dat file for every time step with just one line in it (the forces calculated for that time) and overwrites the existing one. This happens every timestep and at the end I finish with just one file and with just one line in the file.

Why is this happening?
Is this the correct behaviour of the utility?
How can I obtain ONE file with the 1001 lines of the calculated forces? Anyway, the utility is calculating them and the data are getting lost!!

Thanks a lot,
Alexis Espinosa

PD. Settings at the end of controlDict:
functions
(
forces
{
type forces; //Type of function object
functionObjectLibs ("libforces.so"); //Lib to load
patches (cylinder); //List of patches to apply; for example (cylinder wall1 wall2);
rhoName rhoInf; //Settings for density
rhoInf 1.0; //Needed for calculating the forces.
pName p; //Settings for pressure and Velocity
Uname U;
CofR (0 0 0); //Centre of rotation
outputControl timeStep;
outputInterval 1;
}

);
alexisespinosa is offline   Reply With Quote

Old   November 20, 2010, 11:19
Default Problem with execFlowFunctionObjects
  #2
New Member
 
Daniel Cebrián
Join Date: Nov 2010
Posts: 8
Rep Power: 6
danielcebrian is on a distinguished road
I have the same problem with execFlowFunctionObjects, I logged in only
last simulation time step.
I try to fix it.
If I get something I write.
danielcebrian is offline   Reply With Quote

Old   June 4, 2013, 10:36
Default same problem
  #3
New Member
 
Baek, Donghae
Join Date: Jan 2013
Location: Seoul
Posts: 24
Rep Power: 4
wes1204 is on a distinguished road
I also have same problem.

the result is recorded at only last timestep.

help me...
wes1204 is offline   Reply With Quote

Old   June 5, 2013, 18:15
Default
  #4
New Member
 
Thomas Boucheres
Join Date: May 2013
Posts: 12
Rep Power: 4
thomasArk47 is on a distinguished road
Hi,

the behavior of the execFlow*** utilitary is the "normal" one, i.e not a bug. Indeed, if you inspect the source file, you can see that this utilitary allocates (i.e build a new) the function objects at each processed time step. So, this behavior clearly leads to the behavior you have seen with all function objects which encapsulate a kind of temporal dynamic. The most common example of such a function object is the one of a FO which derives from a functionObjectFile (which is roughly speaking an object storing a file opened once a time and which would be used throughout all time steps).

Ok, now it is also clear that this behavior is not the required one. But it is rather easy to adapt the execFlowFunctionObject utilitary to achieve the good behavior. You must modify the src/postProcessing/postCalc sources to add functions init, preCalc and postCalc in addition to the native calc one. After that go to the applications/utilities/postProcessing/miscellaneous/execFlowFunctionObject and modify "accordlngly"

I join here an archive containing the files needed for this adaptation. Dezip it, copy loopPostCalc into src/postProcessing/ and execLoopFlowFunctionObject in applications/utilities/postProcessing/miscellaneous/. Compile both. At end, you will have an new utilitary named execLoopFlowFunctionObject.
It has an option \"-loopMode\" which leads to the good behavior for your problem (without this otption, the behavior is the one of the native execFlowFunctionObject). As a test, you can run the tutorial incopressible/potentialFreeSurface***/oscillating***. Erases the created postProcessing directory during the simulation and try to run both execFlowFunctionObject (you will have the same behavior as you have seen) and with execLoopFlowFunctionObject -loopMode. It should be good now.

Good luck.
Attached Files
File Type: gz ExecLoop.tar.gz (3.6 KB, 22 views)
wyldckat and xilef like this.
thomasArk47 is offline   Reply With Quote

Old   August 21, 2013, 05:27
Default
  #5
Member
 
Amin
Join Date: May 2013
Posts: 76
Rep Power: 4
Mirage12 is on a distinguished road
Hello

I have the same problem.

I copied the files and tried to compiled them, but i got 2 errors

Compiling of execLoopFlowFunctionObjects

Code:
Making dependency list for source file execLoopFlowFunctionObjects.C
SOURCE=execLoopFlowFunctionObjects.C ;  g++ -m64 -Dlinux64 -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-
virtual-dtor -O3  -DNoRepository -ftemplate-depth-100 -I/opt/openfoam220/src/postProcessing/loopPostCalc -I/opt/openfoam220
/src/transportModels -I/opt/openfoam220/src/turbulenceModels -I/opt/openfoam220/src/turbulenceModels/LES/LESdeltas/lnInclude -I/opt/openfoam220/src/thermophysicalModels/basic/lnInclude -I/opt/openfoam220/src/finiteVolume/lnInclude -IlnInclude -I. -I/opt/openfoam220/src/OpenFOAM/lnInclude -I/opt/openfoam220/src/OSspecific/POSIX/lnInclude   -fPIC -c $SOURCE -o Make/linux64GccDPOpt/execLoopFlowFunctionObjects.o

g++ -m64 -Dlinux64 -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3  -DNoRepository -ftemplate-depth-100 -I/opt/openfoam220/src/postProcessing/loopPostCalc -I/opt/openfoam220/src/transportModels -I/opt/openfoam220/src/turbulenceModels -I/opt/openfoam220/src/turbulenceModels/LES/LESdeltas/lnInclude -I/opt/openfoam220/src/thermophysicalModels/basic/lnInclude -I/opt/openfoam220/src/finiteVolume/lnInclude -IlnInclude -I. -I/opt/openfoam220/src/OpenFOAM/lnInclude -I/opt/openfoam220/src/OSspecific/POSIX/lnInclude   -fPIC -Xlinker --add-needed -Xlinker --no-as-needed Make/linux64GccDPOpt/execLoopFlowFunctionObjects.o -L/opt/openfoam220/platforms/linux64GccDPOpt/lib \
         /opt/openfoam220/platforms/linux64GccDPOpt/lib/loopPostCalc.o -lOpenFOAM -lincompressibleTransportModels -lincompressibleRASModels -lincompressibleLESModels -lfluidThermophysicalModels -lspecie -lcompressibleRASModels -lcompressibleLESModels -lfiniteVolume -lgenericPatchFields -lOpenFOAM -ldl   -lm -o /opt/openfoam220/platforms/linux64GccDPOpt/bin/execLoopFlowFunctionObjects
g++: error: /opt/openfoam220/platforms/linux64GccDPOpt/lib/loopPostCalc.o: No such file or directory
make: *** [/opt/openfoam220/platforms/linux64GccDPOpt/bin/execLoopFlowFunctionObjects] Error 1
Compiling of loopPostCalc

Code:
g++ -m64 -Dlinux64 -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3  -DNoRepository -ftemplate-depth-100 -I/opt/openfoam220/src/finiteVolume/lnInclude -IlnInclude -I. -I/opt/openfoam220/src/OpenFOAM/lnInclude -I/opt/openfoam220/src/OSspecific/POSIX/lnInclude   -fPIC -Xlinker --add-needed -Xlinker --no-as-needed Make/linux64GccDPOpt/loopPostCalc.o -L/opt/openfoam220/platforms/linux64GccDPOpt/lib \
          -lOpenFOAM -ldl   -lm -o OpenFOAM.out
Make/linux64GccDPOpt/loopPostCalc.o: In function `Foam::tryInit()':
loopPostCalc.C:(.text+0x1ad): undefined reference to `Foam::init()'
Make/linux64GccDPOpt/loopPostCalc.o: In function `Foam::tryPreCalc(Foam::argList const&, Foam::Time const&, Foam::fvMesh const&)':
loopPostCalc.C:(.text+0x21d): undefined reference to `Foam::preCalc(Foam::argList const&, Foam::Time const&, Foam::fvMesh const&)'
Make/linux64GccDPOpt/loopPostCalc.o: In function `Foam::tryCalc(Foam::argList const&, Foam::Time const&, Foam::fvMesh const&)':
loopPostCalc.C:(.text+0x28d): undefined reference to `Foam::calc(Foam::argList const&, Foam::Time const&, Foam::fvMesh const&)'
Make/linux64GccDPOpt/loopPostCalc.o: In function `Foam::tryPostCalc(Foam::argList const&, Foam::Time const&, Foam::fvMesh const&)':
loopPostCalc.C:(.text+0x2fd): undefined reference to `Foam::postCalc(Foam::argList const&, Foam::Time const&, Foam::fvMesh const&)'
Make/linux64GccDPOpt/loopPostCalc.o: In function `main':
loopPostCalc.C:(.text.startup+0x464): undefined reference to `Foam::fvMesh::fvMesh(Foam::IOobject const&)'
loopPostCalc.C:(.text.startup+0x53d): undefined reference to `Foam::fvMesh::readUpdate()'
loopPostCalc.C:(.text.startup+0x5a3): undefined reference to `Foam::fvMesh::~fvMesh()'
loopPostCalc.C:(.text.startup+0x770): undefined reference to `Foam::fvMesh::~fvMesh()'
loopPostCalc.C:(.text.startup+0x7c4): undefined reference to `Foam::fvMesh::~fvMesh()'
collect2: ld returned 1 exit status
make: *** [OpenFOAM.out] Error 1
SOS
Mirage12 is offline   Reply With Quote

Old   September 12, 2013, 05:09
Default
  #6
Senior Member
 
immortality's Avatar
 
Ehsan
Join Date: Oct 2012
Location: Iran
Posts: 2,186
Rep Power: 16
immortality is on a distinguished road
Hi,
interesting! I thought this issue only occurs for me!
writing execFlowFunctionObjects
__________________
Injustice Anywhere is a Threat for Justice Everywhere.Martin Luther King.
To Be or Not To Be,Thats the Question!
The Only Stupid Question Is the One that Goes Unasked.
immortality is offline   Reply With Quote

Old   September 15, 2013, 06:31
Default
  #7
Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 8,306
Blog Entries: 34
Rep Power: 84
wyldckat is just really nicewyldckat is just really nicewyldckat is just really nicewyldckat is just really nice
Greetings to all!

Just to inform that I have not yet confirmed this, but I believe that Thomas' execLoopFlowFunctionObject application might not be necessary if you're already using the latest OpenFOAM 2.2.x: http://www.openfoam.org/download/git.php

All I know is that when using the latest git version, I had no problems in using execFlowFunctionObjects.

edit: forgot to mention that I documented the existence of Thomas' execLoopFlowFunctionObject application here: http://openfoamwiki.net/index.php/Ex...unctionObjects

Best regards,
Bruno
Nucleophobe likes this.

Last edited by wyldckat; September 15, 2013 at 06:32. Reason: see "edit:"
wyldckat is offline   Reply With Quote

Old   January 27, 2014, 19:05
Default
  #8
Member
 
Ken
Join Date: Aug 2012
Posts: 61
Blog Entries: 1
Rep Power: 5
Nucleophobe is on a distinguished road
Good to know Bruno!

In case you don't have access to OpenFOAM 2.2.x (I'm running on a cluster with OpenFOAM 2.1.x), you can always just run
Code:
execFlowFunctionObjects >> log.forces
and extract what you need from the log file. Not very elegant, but it works!
wyldckat likes this.
Nucleophobe 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



All times are GMT -4. The time now is 10:30.