[alexisespinosa]

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;
}

);

[danielcebrian]

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.

[wes1204]

I also have same problem.

the result is recorded at only last timestep.

help me...

[thomasArk47]

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.

[Mirage12]

Hello

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

Compiling of loopPostCalc

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

[immortality]

Hi,
interesting! I thought this issue only occurs for me!
http://www.cfd-online.com/Forums/ope...tml#post451291

[wyldckat]

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]

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

and extract what you need from the log file. Not very elegant, but it works!

[amuzeshi]

Originally Posted by alexisespinosa

I do not know exactly if this is a bug, because I do not know exactly if execFlowFunctionObjects utility was ...);

I have, more or less a similar problem in a multi-region problem using solids4Foam: I really appreciate your idea in advance.
How to calculate drag coeff when using solids4Foam

Ali