|
[Sponsors] |
area does not match neighbour by ... % -- possible face ordering problem |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
April 12, 2011, 08:47 |
area does not match neighbour by ... % -- possible face ordering problem
|
#1 |
New Member
Steffen
Join Date: Apr 2011
Posts: 4
Rep Power: 15 |
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). 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 |
|
April 12, 2011, 11:40 |
Solved !!
|
#2 |
New Member
Steffen
Join Date: Apr 2011
Posts: 4
Rep Power: 15 |
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. :-) |
|
April 14, 2011, 17:54 |
|
#3 |
Member
|
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! |
|
April 15, 2011, 07:54 |
|
#4 |
New Member
Steffen
Join Date: Apr 2011
Posts: 4
Rep Power: 15 |
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 // ************************************************************************* // 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() ); -> 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. |
|
April 23, 2011, 06:50 |
|
#6 |
Member
|
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 |
|
April 28, 2011, 11:22 |
|
#8 | |
Senior Member
Join Date: Apr 2010
Posts: 151
Rep Power: 16 |
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:
|
||
November 22, 2011, 10:02 |
|
#10 |
New Member
Steffen
Join Date: Apr 2011
Posts: 4
Rep Power: 15 |
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. |
|
February 7, 2024, 21:50 |
|
#11 |
New Member
Thuc
Join Date: Feb 2024
Posts: 3
Rep Power: 2 |
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. |
|
September 4, 2024, 04:28 |
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 |
Besides, the above error could also be addressed by adding:
preservePatches (cyclic1 cyclic2); in system/decomposeParDict |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|
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 |