[St.Pacholak]

hi everyone,

im trying to run a pimpleDyMFoam case in parallel to assign velocity and pressure field around a multi-patched-body. Every patch has its own motion function and the motion function of second patch is linked to motion of first patch and so on.
In detail u can imagine as a long chain moving by a given function.

All in all Foam is nearly doing, what i want to do .. but after calculating first time step of motion and try to start second, im getting following error message:

[1] 
[1] 
[1] --> FOAM FATAL ERROR: 
[1] face 13696 area does not match neighbour by 1.8814% -- possible face ordering problem.
patch:procBoundary1to0 my area:9.48981e-06 neighbour area:9.31293e-06 matching tolerance:0.001
Mesh face:531510 vertices:4((-0.130045 0.120446 -0.0525838) (-0.129434 0.120114 -0.051378) (-0.135286 0.120316 -0.0479868) (-0.135963 0.120644 -0.0491677))
Rerun with processor debug flag set for more information.
[1] 
[1]     From function processorPolyPatch::calcGeometry()
[1]     in file meshes/polyMesh/polyPatches/constraint/processor/processorPolyPatch.C at line 199.
[1] [0] 
FOAM parallel run exiting

[0] 
[0] --> FOAM FATAL ERROR: 
[0] face 13696 area does not match neighbour by 1.8814% -- possible face ordering problem.
patch:procBoundary0to1 my area:9.31293e-06 neighbour area:9.48981e-06 matching tolerance:0.001
Mesh face:528905 vertices:4((-0.130045 0.120446 -0.0525838) (-0.135963 0.120644 -0.0491677) (-0.135286 0.120318 -0.0480168) (-0.129434 0.120117 -0.0514081))
Rerun with processor debug flag set for more information.
[0] 
[0]     From function processorPolyPatch::calcGeometry()
[0]     in file meshes/polyMesh/polyPatches/constraint/processor/processorPolyPatch.C at line 199.
[0] 
FOAM parallel run exiting
[0] 
[1] 
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 0 in communicator MPI_COMM_WORLD 
with errorcode 1.

NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.
--------------------------------------------------------------------------
[3] 
[3] 
[3] --> FOAM FATAL ERROR: 
[3] face 13882 area does not match neighbour by 0.93207% -- possible face ordering problem.
patch:procBoundary3to2 my area:6.15477e-06 neighbour area:6.21241e-06 matching tolerance:0.001
Mesh face:528637 vertices:4((0.13715 0.0052535 -0.0759097) (0.13633 0.00488129 -0.0748861) (0.135391 0.00931068 -0.0745448) (0.136205 0.00956401 -0.0756424))
Rerun with processor debug flag set for more information.
[3] 
[3]     From function processorPolyPatch::calcGeometry()
[3]     in file meshes/polyMesh/polyPatches/constraint/processor/processorPolyPatch.C at line 199.
[3] 
FOAM parallel run exiting
[3] 
[2] 
[2] 
[2] --> FOAM FATAL ERROR: 
[2] face 13882 area does not match neighbour by 0.93207% -- possible face ordering problem.
patch:procBoundary2to3 my area:6.21241e-06 neighbour area:6.15477e-06 matching tolerance:0.001
Mesh face:548447 vertices:4((0.13715 0.0052535 -0.0759097) (0.136205 0.00956401 -0.0756424) (0.135391 0.00931068 -0.0745448) (0.13633 0.00489243 -0.0748445))
Rerun with processor debug flag set for more information.
[2] 
[2]     From function processorPolyPatch::calcGeometry()
[2]     in file meshes/polyMesh/polyPatches/constraint/processor/processorPolyPatch.C at line 199.
[2] 
FOAM parallel run exiting
[2] 
--------------------------------------------------------------------------
mpirun has exited due to process rank 0 with PID 15194 on
node imfd118 exiting without calling "finalize". This may
have caused other processes in the application to be
terminated by signals sent by mpirun (as reported here).

I'm only getting this error when running case parallel. I can run it on a single core but it would take ages to solve my hole case .. even in parallel case it's about to run weeks i guess.

It seems to be a problem of mesh splitting by processor and loosing some points, when mesh is moved .. I decomposed my mesh with hierarchical method but all other methods are also not working and giving same problem.

So did any of u got the same problem or has an idea how to solve this dilemma ?!?!

greetz and thx

[St.Pacholak]

Ok, found the problem ... it's a bit tricky.

I was using an own boundary condition using and modifying angularOscillatingVelocity (AOV). When substracting pointField of current patch to gain movement only, there are 2 parameter already implemented in AOV:

-> local point field p.localPoints
-> another point parameter p0_

i was using p.localPoints and got some difference between local patch coordinates on several processors. When using p0_ instead this difference was elliminated and it's working now.

Hope this will help someone with the same problem. :-)

[McCarra]

Hello Steffen,

Could you explain a bit more on the solution? I'm having the same problem and I don't understand what you propose to solve it.
I also have mesh movement and use my own boundary condition which was created from modifying AngullarOscillatingVelocity so your idea must work in my case too.

Thanks!

[St.Pacholak]

Ofc .. take a closer look into my BC file created by modifying angularOscillatingVelocityPatchVectorField.C

/*---------------------------------------------------------------------------*\
  =========                 |
  \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox
   \\    /   O peration     |
    \\  /    A nd           | Copyright (C) 1991-2010 OpenCFD Ltd.
     \\/     M anipulation  |
-------------------------------------------------------------------------------
License
    This file is part of OpenFOAM.

    OpenFOAM is free software: you can redistribute it and/or modify it
    under the terms of the GNU General Public License as published by
    the Free Software Foundation, either version 3 of the License, or
    (at your option) any later version.

    OpenFOAM is distributed in the hope that it will be useful, but WITHOUT
    ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
    FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
    for more details.

    You should have received a copy of the GNU General Public License
    along with OpenFOAM.  If not, see <http://www.gnu.org/licenses/>.

\*---------------------------------------------------------------------------*/

#include "angularOscillatingVelocityPointPatchVectorField.H"
#include "pointPatchFields.H"
#include "addToRunTimeSelectionTable.H"
#include "Time.H"
#include "polyMesh.H"

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

namespace Foam
{

// * * * * * * * * * * * * * * * * Constructors  * * * * * * * * * * * * * * //

angularOscillatingVelocityPointPatchVectorField::
angularOscillatingVelocityPointPatchVectorField
(
    const pointPatch& p,
    const DimensionedField<vector, pointMesh>& iF
)
:
    	fixedValuePointPatchField<vector>(p, iF),
	.....
    	p0_(p.localPoints())
{}

....

void angularOscillatingVelocityPointPatchVectorField::updateCoeffs()
{
    if (this->updated())
    {
        return;
    }

    const polyMesh& mesh = this->dimensionedInternalField().mesh()();
    const Time& t = mesh.time();
    const pointPatch& p = this->patch();

    	...

    vector e1 = vector(1, 0, 0);
    vector e2 = vector(0, 1, 0);
    vector e3 = vector(0, 0, 1); 

    vectorField p0Rel = p0_ - origin;

    vectorField::operator=
    (
        (
          e1*p0Rel.component(0)
	+ e2*(p0Rel.component(1)*cos(angle) - p0Rel.component(2)*sin(angle))
	+ e3*(p0Rel.component(1)*sin(angle) + p0Rel.component(2)*cos(angle))
	+ shift
	- p0_
        )/t.deltaTValue()
    );

    fixedValuePointPatchField<vector>::updateCoeffs();
}

...


// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

makePointPatchTypeField
(
    pointPatchVectorField,
    angularOscillatingVelocityPointPatchVectorField
);

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

} // End namespace Foam

// ************************************************************************* //

In source code above u can see all important lines being bold and red.

As i alread told it's a bit tricky. Take a look into calculation part:

   vector e1 = vector(1, 0, 0);
   vector e2 = vector(0, 1, 0);
   vector e3 = vector(0, 0, 1);

    vectorField p0Rel = p0_ - origin;

    vectorField::operator=
    (
        (
          e1*p0Rel.component(0)
	+ e2*(p0Rel.component(1)*cos(angle) - p0Rel.component(2)*sin(angle))
	+ e3*(p0Rel.component(1)*sin(angle) + p0Rel.component(2)*cos(angle))
	- p0_
        )/t.deltaTValue()
    );

-> u have to use always "p0_" for calculation and not "p.localPoints()". So if ur mixing up both of them there will be a difference between points that are lying on more than one processor after moving.
-> Btw, when i tried using already implemented velocity calculation in this BC it didnt give me the write solution. So I had to modify it to that code ur seeing above. It's only rotation around x-axis possible with this code.

Hope this will be helpful for u. Plz write ur feedback after u tried it out.

[McCarra]

Yes you are absolutely right. Removing p.localpoints from the operator was all I had to do. No more face area mismatches for now!

Thank you very much Steffen!

[McCarra]

Hello again,

by replacing p0_ with p.localPoints the simulation starts. However it causes a velocity divergence in a corner of my domain, even when ran in one processor. If I undo the p0_ replacement, the divergence disappears and there are no errors when ran in one processor, but the parallel process -4 processors- does not start and displays the error shown at post #1 of this thread. So I'm again facing the same error.

Do you know how this can be solved?

Thanks for your help Steffen!

Mc

[McCarra]

What would be the code like for a z-axis rotation?

[flowris]

Hello,

I am also trying to make a modified angularOscillatingVelocityPatchVectorField.C, but suffering from the parallel run of the original file as well as my modifications.

I tried the adaptation in #4, but it only works in serial. When I run it on 4 processors, I have similar errors as in #1.

-> u have to use always "p0_" for calculation and not "p.localPoints()". So if ur mixing up both of them there will be a difference between points that are lying on more than one processor after moving.

I do not really understand why p0_ is better than p.localpoints(), because to me it seems that they are copies of each other (angularOscillatingVelocityPatchVectorField.C line 52 and 82). Anyways, I am not a C++ programmer, so I much misunderstand the code.

[McCarra]

Try removing the list (p0 nonuniform List<vector>) that appears in each processor*/0/pointMotionU after the decomposition. In my case it works flawless now.

Hope it helps!

Mc

[St.Pacholak]

Sorry, haven't read forum for a while. Rotation around z-axis would be:

vector e1 = vector(1, 0, 0);
vector e2 = vector(0, 1, 0);
vector e3 = vector(0, 0, 1);

vectorField p0Rel = p0_ - origin;

vectorField:perator=
(
(
e1*(p0Rel.component(0)*cos(angle) - p0Rel.component(1)*sin(angle))
+ e2*(p0Rel.component(0)*sin(angle) + p0Rel.component(1)*cos(angle))
+ e3*p0Rel.component(2)
- p0_
)/t.deltaTValue()
);

Hope this will help ;-)

Regarding to similarities of p0_ and p.localPoints ... I'm not sure about it, but i think the position or assignment of the points are modified in function p0_ .. that's why there's a difference after calculation with both. Try to use "p0_" only, that should fix the problem.

[thuc_wind]

Hi, maybe late but I hope my solution will help someone else!

I also encounter this problem, this issue might come from the decompose method. I used Hierarchical and this error happened, then I changed to Scotch and it worked.

[ShaneheSSSS]

Besides, the above error could also be addressed by adding:

preservePatches (cyclic1 cyclic2);

in system/decomposeParDict