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?

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 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?

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):

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!

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.

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.