[cwang5]

Hi,

I'm running OF-1.6.x with a modified version of pimpleDyMFoam, and is using the function mesh.Sf().boundaryField() to calculate the patch area, which was later used to calculate the forces acting on the patch. The function was setup similarly to the force calculation in forces.C.

The surface vector field works fine in serial computation, but when I tried running it in parallel, under certain conditions the mesh.Sf().boundaryField() would return zero value, and the forces/forceCoeffs directory would not be created even though the functions were specified in the controlDict file. The problem seems to happen as long as the domain decomposition was not done along the spanwise direction (z-direction).

I'm not quite sure if it's a problem with the decomposePar code or the Sfb function itself, but would appreciated if someone can suggest a way around this.

John

EDIT: Correction, I've just realized that the forces directory did not show up because I stopped the simulation before the first output, I will update the behavior of the forces functions when I reach that point after restarting the simulation.

[mattijs]

mesh.Sf().boundaryField() is per patch the area. I assume that you mean you get a zero size for some patches if they have zero faces on that particular processor - which is as should be.

Is there still a problem?

[cwang5]

The forces function itself works fine. I guess it's how I wrote my code that's causing the problem. You might want to move this post under the OF programming folder if that's the case.

Anyway, this is the code that I used to calculate the patch area:

scalar pArea = 0;

forAllConstIter(labelHashSet, patchList_, iter)
{
        label patchi = iter.key();
        dimensionedScalar patchArea = sumMag(Sfb[patchi]);
        pArea += patchArea.value();
}

the pArea is actually a sum of patchArea throughout, so it shouldn't matter even if the patch doesn't exist in one of the processor domains, right?

I suppose it has to do with my reading the patch list pointer in the main function under

const dynamicFvmesh& mesh = U.mesh();

instead of the

const fvMesh& mesh = refCast <const fvMesh>(obr_)

as specified in Foam::forces::read


EDIT: Apparently the cause of the problem is slicing the domains right at the patch in question.

[mattijs]

>Apparently the cause of the problem is slicing the domains right at the patch in question.

That should not be a problem. All processors will have all (non-processor) patches. Just that they might have zero faces in them.

[cwang5]

Originally Posted by mattijs

>Apparently the cause of the problem is slicing the domains right at the patch in question.

That should not be a problem. All processors will have all (non-processor) patches. Just that they might have zero faces in them.

Yes, I do see a patches presented in the processorX/constant folder, however, the the summation of sumMag(Sfb[patchi]) function results in zero area if the patch in question is not presented in all partitions.

The case that I am running is attached below to clarify the problem that I am encountering:
If the decomposition was done (using "simple") along the z-axis (xy-plane), the patch area will be computed correctly (although it appears that the motion between different portion of the divided patch doesn't seem to match exactly, I'm still working on that)
However, if the decomposition was done along the x or y axis (hence the patch 'flap' will not exist in one of the partitions) the patch area computed from the code stated in the previous post would return zero value.

Anyway, I am in the process of switching to 1.7 right now in hope that the dynamic mesh solver in the new version would somehow solve the problem. Thanks for taking the time to reply to my messages.

John

The case folder was too big to be uploaded to the forum, so I'm uploading it to rapidshare.
Attachment:
http://rapidshare.com/files/40422175...se.tar.gz.html

[mattijs]

That makes it clear - use gSumMag (does additional global sum) instead of sumMag.

[cwang5]

Originally Posted by mattijs

That makes it clear - use gSumMag (does additional global sum) instead of sumMag.

Oh, wow... that did the trick, thank you so much.

John