|March 23, 2010, 03:06||
Join Date: Aug 2009
Posts: 14Rep Power: 9
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,
PD. Settings at the end of controlDict:
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
CofR (0 0 0); //Centre of rotation
|November 20, 2010, 11:19||
Problem with execFlowFunctionObjects
Join Date: Nov 2010
Posts: 8Rep Power: 8
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.
|June 4, 2013, 10:36||
Join Date: Jan 2013
Posts: 24Rep Power: 6
I also have same problem.
the result is recorded at only last timestep.
|June 5, 2013, 18:15||
Join Date: May 2013
Posts: 41Rep Power: 5
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.
|August 21, 2013, 05:27||
Join Date: May 2013
Posts: 76Rep Power: 5
I have the same problem.
I copied the files and tried to compiled them, but i got 2 errors
Compiling of execLoopFlowFunctionObjects
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
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
|September 12, 2013, 05:09||
Join Date: Oct 2012
Posts: 2,209Rep Power: 19
interesting! I thought this issue only occurs for me!
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.
|September 15, 2013, 06:31||
Join Date: Mar 2009
Location: Lisbon, Portugal
Blog Entries: 39Rep Power: 106
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
Last edited by wyldckat; September 15, 2013 at 06:32. Reason: see "edit:"
|January 27, 2014, 19:05||
Join Date: Aug 2012
Blog Entries: 1Rep Power: 6
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
execFlowFunctionObjects >> log.forces