CFD Online Discussion Forums

CFD Online Discussion Forums (
-   OpenFOAM (
-   -   owner - neighbour relations for processor boundaries (

RoE October 4, 2011 07:57

owner - neighbour relations for processor boundaries

I am trying to save cell centred values of a volScalarField to two scalar lists (ownPsi and neighPsi) defined on the cell faces as in the following piece of code:


scalarField ownPsi (mesh.nFaces(), 0.0);
scalarField neighPsi (mesh.nFaces(), 0.0);

const fvPatchList& patches = psi.mesh().boundary();

forAll(patches, patchI)

    const fvPatch& p = patches[patchI];
    const polyPatch& pp = p.patch();

    if (typeid(pp) == typeid(processorPolyPatch))
        label start = pp.start();

        forAll(pp, faceI)
            // global face index
            label gFaceI = start + faceI;
            label cellI = pp.faceCells()[faceI];
            label own = mesh.owner()[gFaceI];
            label neigh = mesh.neighbour()[gFaceI];

            Pout << "Cell: " << cellI << " owner: " << own << " neigh: " << neigh <<nl;

            if (cellI == own)
                ownPsi[gFaceI] = psi[cellI];
                neighPsi[gFaceI] = psi[cellI];

However, it seems that (cellI == own) is always true and the faces are owned by both cells. Does the owner - neighbour relation not hold for processor boundaries? Or is there a mistake in my code? Is there any other way to distinguish the two adjacent cells of a processor boundary?

Thanks in advance!

deepsterblue October 4, 2011 08:40

You appear to be confused - a processor boundary is like any other patch. it does not contain any neighbour information (obviously, because it's a boundary).

In fact, you're pretty lucky to have your code run at all, because the mesh.neighbour() list ends at the number of internal faces in the mesh, and you'd have a nice, pretty seg-fault if the second part of your condition was ever executed.

What you can guarantee, however, is that the processor boundary of the other sub-domain (which talks to this boundary patch) will contain an identical number of faces, and both patches have the faces ordered identically within the patch, such that their zeroth points and face centres align geometrically. Since they point in opposite directions (always out of the domain), and the right-hand face-orientation rule, the 1st point corresponds to the (n-1)th point, the 2nd with the (n-2)th point, and so on for face-pairs...

RoE October 4, 2011 08:49

Hello Sandeep,

thank you for your quick reply! I got it now -- I used to think that the faces of a processor patch would need the owner-neighbour relation. So thank you very much for the clarification! I realised that label mesh.neighbour()[gFaceI]; does not work in this case and forgot to delete it....

Best wishes,

All times are GMT -4. The time now is 05:38.