What is the easiest way to wri
 

What is the easiest way to write the drag/lift to the log file, each time-step, for post-processing.

Do I have to point to the function dragCoefficient in the main loop of icoFoam (for example) ?

Thanks, Frank

Yes, edit the top-level code a
 

Yes, edit the top-level code and add all the post-processing you wish to do for every time-step at the end of the time loop, somewhere around runTime.write();

You can write your data into the same place as everything else using

Info << "blah blah" << endl;

Alternatively, you can open yourself a file using

#include "OFstream.H"

in the header section and something like:

OFstream logSummaryFile
(
runTime.path()/("logSummary." + runTime.timeName() + ".dat")
);

logSummaryFile
<< runTime.theta() << tab
<< p.weightedAverage(mesh.V()).value() << tab
<< T.weightedAverage(mesh.V()).value() << tab
<<>k()))().weightedAverage(mesh.V()).value()
<< tab
<< 1 - b.weightedAverage(mesh.V()).value()
<< endl;

(taken from combustion/engineFoam/logSummary.H)

You can, of course, write and format your lift and drag data as well in the same way.

Enjoy,

Hrv

Thank you, the structure of Op
 

Thank you, the structure of OpenFOAM becomes clearer and clearer to me. Nevertheless I got another question.

How can one call the liftDrag function from within the main function in icoFoam? Or needs the complete drag routine from within liftDrag.C be copied to icoFoam.C

I am not very familiar with C++, but still learning.

Thanks,
Frank

Hi Hrv, I followed your sug
 

Hi Hrv,

I followed your suggestion and included the calculation of lift and drag coefficients within icoFoam with Frank's help. Basically, just after

runTime.write();

I include a file:

#include "computeForces.H"

which performs calculations for lift and drag using routines from liftDrag.H and prints them out as follows:

Info
<< "\nWall patch = " << patchI << "\n"
<< "Wall patch name = " << patches[patchI].name() << "\n"
<< "Uav = " << Uav << "\n"
<< "Aref = " << Aref << "\n"
<< "DragCoefficient = " << dragCoefficient(U,p,nu,patches[patchI].name(),Uav,Aref)<<"\n"
<< endl;

etc.

However, I notice that during a parallel run, the lift and drag coefficients printed in the log file are different than those of the serial run. As I change the number of CPUs using the -np argument in mpirun (of course after performing a lamboot for the same number of CPUs), I get different values as well. Is there anything more to be done in terms of parallelizing the output as well?

For instance if the partitioning leaves one half of a set of walls in 1 CPU and another half split in two other CPUs, how does one concert all the computed lift and drag coefficients from all CPUs and put them together in a single log file?

Alternatively, is there anyway to get mpirun to print the output of each icoFoam instance to a separate log file or some such?

Please bear with me here. Thanks for your patience!

Have a look at lift and drag c
 

Have a look at lift and drag calculation: at every point where it says "sum" put gSum. Now you will get the identical results. The file lives in:

/home/hjasak/OpenFOAM/OpenFOAM-1.3/src/postProcessing/incompressible/liftDrag/

A copy of the bug fix is attached + apologies for the trouble.



Hrv

Brilliant! It worked like a ch
 

Brilliant! It worked like a charm. Thanks very much for your help. I just had to update the libincompressiblePostProcessing.so after doing a M-x-replace-string in emacs and then rebuild the liftDrag utility.

I have one question regarding
 

I have one question regarding gSum. In the end of each time-step I write the forces on my patches to the logfile. For each patch I call a function to calculate and write the total force to the logfile where I use gSum :

sumForce=gSum(force); //where force is a vectorField

Then when using:
Info << sumForce << endl; // gives the result for the master node.
Sout << sumForce << endl; //gives correct result for each node, but then I will need to sum all nodes before analysing the logfile

Why does not gSum(force) sum the force for each node?
Do you have any suggestions how I should rewrite my application?

Thanks,
Martin

I don't whant to open another
 

I don't whant to open another thread, so this seems to be the right one.

I have reincluded liftDrag utility in OF 1.3 and fix the sum/gSum bug in OpenFOAM/OpenFOAM-1.3/src/postProcessing/incompressible/liftDrag/liftDrag.C,
and I would like to perform lift and drag calculation after each solver iteration, as pUl| did.
Obviously, it doesn't work to me. More in detail, the very liftDrag utility works in serial, but not in parallel!
Here follows a part of the output (I've added "Pout << Uav" in liftDrag.C):

SERIAL:
-------------------
Time = 0
Reading U

Reading p

Inlet velocity: (149.98815 0 -1.887)
Inlet velocity: (149.98815 0 -1.887)
Wall patch 0 named ground :
[...]



PARALLEL:
-------------------
Create mesh for time = 0

Time = 0
Reading U

[2] --> FOAM Warning :
[2] From function average(const UList<type>&)
[2] in file /home/fde/OpenFOAM/OpenFOAM-1.3/src/OpenFOAM/lnInclude/FieldFunctions.C at line 454
[2] empty field, returning zero
[... various ...]
[3] --> FOAM FATAL ERROR : Uinf is zero.
[3]
[3] From function vector momentCoefficient
(
const volVectorField& U,
const volScalarField& p,
const dimensionedScalar& mu,
const word& patchName,
const vector& Uinf,
const scalar& Aref,
const scalar& Lref
)
[3]
[3] in file liftDrag/liftDrag.C at line 567.
[3]
FOAM parallel run exiting

And, regarding Uav value (I have 3 patches with the same imposed velocity):
Inlet velocity: (99.9921 0 -1.258)
[0] Inlet velocity: (99.9921 0 -1.258)
[1] Inlet velocity: (149.98815 0 -1.887)
[2] Inlet velocity: (0 0 0)
[3] Inlet velocity: (0 0 0)

----------------------
I guess this is an error. All parallel processes should have the same reference value for Uinf, while each process now seems to sum only the patches that belong to it.

What's wrong with it?
pUl|, how could you perform this calculation?

Francesco

I basically followed Frank Bos
 

I basically followed Frank Bos's instructions. I will attach my modified icoFoam source later today when I get to the office. Maybe that will help http://www.cfd-online.com/OpenFOAM_D...part/happy.gif

Thanks a lot! In the meanwhil
 

Thanks a lot!
In the meanwhile, I rewrote force computation, using the code inside liftDrag.C, but without calling the routines directly.
So I have assigned a Uinf velocity and a reference area, accordingly to my case.
It seems to work in parallel now, but I'm not completly confident about results, so any suggestion will be welcome!

http://www.ualberta.ca/~madhav
 

http://www.ualberta.ca/~madhavan/icoFoam.tar.bz2
http://www.ualberta.ca/~madhavan/liftDrag.tar.bz2

The source also does time-averaging and writing out velocity/pressure probes based on the points specified in probeLocations.

Good Luck http://www.cfd-online.com/OpenFOAM_D...part/happy.gif

Thank you very much! It's mor
 

Thank you very much!
It's more or less what I did, except for the average (I'm using a steady state solver), but it's very useful to have a comaprison.

Hi, I was wondering from wh
 

Hi,

I was wondering from what source the drag relaxation time was obtained, as incorportated in the IcoLagrangian solver?

Regards
Jeff

Hey, I tried to compile the
 

Hey,

I tried to compile the liftDrag source files given by pUl| in version 1.4, but it gave me the following error. Can anybody figure out the error.


-lincompressiblePostProcessing -lfiniteVolume -lOpenFOAM -liberty -ldl -lm -o /scratch/amer/OpenFOAM/OpenFOAM-1.4.1/applications/bin/linux64GccDPOpt/liftDrag
/usr/lib/../lib64/crt1.o: In function `_start':
../sysdeps/x86_64/elf/start.S:109: undefined reference to `main'
collect2: ld returned 1 exit status
make: *** [/scratch/amer/OpenFOAM/OpenFOAM-1.4.1/applications/bin/linux64GccDPOpt/liftDrag ] Error 1

Usually this type of error com
 

Usually this type of error comes from the fact that you typed wmake instead of wmake libso.

Dragos

Hi all! According to liftdr
 

Hi all!

According to liftdrag.H, the drag force can be evaluated for newtonian fluids.

The viscous term is -mu*(part u_i / part x_j+part u_j / part x_i ) n_j *dA

mu is the kinematic viscosity, dA is the area of the face, U is the velocity of the fluid, n is the normal vector of the face.

The liftdrag.H tells however the middle part to be sngrad(), the normal gradient of the velocity gradient, this would read grad(U)n (?), however a closer look in the code i would rather use the deviatoric part of (grad(U)+grad(U)^T) times the normal of the surface. I have been searching the code part for sngrad but ended up only at FvPatchField::snGrad which seems not doing the thing according to me, or do I owe someone an apology for this statement?

I could of course just accept the liftDrag.H as it is but i would like to have some understanding of the code.

Best Regards

Johan

For clarification, deviatoric
 

For clarification, deviatoric part was a missplaced word, taken from another text i was reading. So please kindly disregard that. What I was implicating is that from the plausible code piece FvPatchField::sngrad(), i didnt follow how that part of the could should generate the viscous term corresponding to the symmetric gradient of the velocity field times the normal vector of the surface.

Best Regards

Johan

Greetings again, I solved t
 

Greetings again,

I solved the issue! So ignore my previous two posting.

/Johan