CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM

area does not match neighbour by ... % -- possible face ordering problem

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree4Likes
  • 3 Post By St.Pacholak
  • 1 Post By St.Pacholak

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   April 12, 2011, 08:47
Default area does not match neighbour by ... % -- possible face ordering problem
  #1
New Member
 
Steffen
Join Date: Apr 2011
Posts: 4
Rep Power: 15
St.Pacholak is on a distinguished road
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:

Code:
[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 is offline   Reply With Quote

Old   April 12, 2011, 11:40
Default Solved !!
  #2
New Member
 
Steffen
Join Date: Apr 2011
Posts: 4
Rep Power: 15
St.Pacholak is on a distinguished road
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. :-)
salehi144, Alhasan and hogsonik like this.
St.Pacholak is offline   Reply With Quote

Old   April 14, 2011, 17:54
Default
  #3
Member
 
Usit McCarra
Join Date: Oct 2010
Posts: 51
Blog Entries: 2
Rep Power: 15
McCarra is on a distinguished road
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!
McCarra is offline   Reply With Quote

Old   April 15, 2011, 07:54
Default
  #4
New Member
 
Steffen
Join Date: Apr 2011
Posts: 4
Rep Power: 15
St.Pacholak is on a distinguished road
Ofc .. take a closer look into my BC file created by modifying angularOscillatingVelocityPatchVectorField.C

Code:
/*---------------------------------------------------------------------------*\
  =========                 |
  \\      /  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:

Code:
   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 likes this.
St.Pacholak is offline   Reply With Quote

Old   April 15, 2011, 09:28
Default
  #5
Member
 
Usit McCarra
Join Date: Oct 2010
Posts: 51
Blog Entries: 2
Rep Power: 15
McCarra is on a distinguished road
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 is offline   Reply With Quote

Old   April 23, 2011, 06:50
Default
  #6
Member
 
Usit McCarra
Join Date: Oct 2010
Posts: 51
Blog Entries: 2
Rep Power: 15
McCarra is on a distinguished road
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 is offline   Reply With Quote

Old   April 27, 2011, 05:58
Default
  #7
Member
 
Usit McCarra
Join Date: Oct 2010
Posts: 51
Blog Entries: 2
Rep Power: 15
McCarra is on a distinguished road
What would be the code like for a z-axis rotation?
McCarra is offline   Reply With Quote

Old   April 28, 2011, 11:22
Default
  #8
Senior Member
 
Join Date: Apr 2010
Posts: 151
Rep Power: 16
flowris is on a distinguished road
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.

Quote:
-> 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.
flowris is offline   Reply With Quote

Old   May 2, 2011, 06:45
Default
  #9
Member
 
Usit McCarra
Join Date: Oct 2010
Posts: 51
Blog Entries: 2
Rep Power: 15
McCarra is on a distinguished road
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
McCarra is offline   Reply With Quote

Old   November 22, 2011, 10:02
Default
  #10
New Member
 
Steffen
Join Date: Apr 2011
Posts: 4
Rep Power: 15
St.Pacholak is on a distinguished road
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.
St.Pacholak is offline   Reply With Quote

Old   February 7, 2024, 21:50
Default
  #11
New Member
 
Thuc
Join Date: Feb 2024
Posts: 3
Rep Power: 2
thuc_wind is on a distinguished road
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.
thuc_wind is offline   Reply With Quote

Old   September 4, 2024, 04:28
Default face 0 area does not match neighbour by 49.9414% -- possible face ordering problem.
  #12
New Member
 
Join Date: Mar 2021
Posts: 7
Rep Power: 5
ShaneheSSSS is on a distinguished road
Besides, the above error could also be addressed by adding:

preservePatches (cyclic1 cyclic2);

in system/decomposeParDict
ShaneheSSSS is offline   Reply With Quote

Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
axisymetric-WARNING:non-positive face area exist JORDI FLUENT 9 March 9, 2011 05:15
CFX Solver Memory Error mike CFX 1 March 19, 2008 07:22
WARNING: non-positive face area exist. Alan Main CFD Forum 4 August 17, 2006 07:33
problem related to mesh naveen CFX 3 March 25, 2006 08:47
[Commercial meshers] Trimmed cell and embedded refinement mesh conversion issues michele OpenFOAM Meshing & Mesh Conversion 2 July 15, 2005 04:15


All times are GMT -4. The time now is 22:30.