View Issue Details

IDProjectCategoryView StatusLast Update
0001993OpenFOAMBugpublic2020-02-19 15:49
Reporterwill Assigned Towill  
Status resolvedResolutionfixed 
PlatformGNU/LinuxOSOpenSUSE LeapOS Version42.1
Product Versiondev 
Fixed in Versiondev 
Summary0001993: Face centres (and by extension, cell centres) are calculated incorrectly when the initial guess is outside the face
DescriptionprimitiveMesh::makeFaceCentresAndAreas calculates the cell centres first by making an initial guess of the centre, then doing an area weighted average of the centres of the triangles made between this guess and each edge. The problem is that it uses the magnitude of each triangle's normal. If the initial guess is outside the face, then some of the triangles will be inverted, and their contributions to the average should be subtracted.
Steps To ReproduceRun blockMesh and calcCellCentres on the attached case. The centre of the smaller cell should be coincident with the inner points at (x, y) = (0.25, 0.25). You can work this out by hand by averaging the centres of the two triangles. OpenFOAM does not reproduce this result.
Additional InformationA fix can be found here <>ยท Essentially, the magnitude operation is replaced by a dot product with the unit normal, which is calculated in a separate loop. Inverted triangles have opposite normals, which generate the correct sign.

This changes the behaviour of the worst cells significantly. Snappy's quality criteria will be affected, and the coefficients of many interpolations and gradient calculations will change. I havent the resources to run big snappy cases and assess the effect of this change. I guess it might be sensible to put a switch in to control the behaviour.
TagsNo tags attached.



2016-02-14 12:00


veryConcaveFace.tar.gz (2,432 bytes)


2016-02-14 12:04

manager   ~0005940

Mantis has mangled linking the URL a bit. Without angle brackets...


2016-02-14 20:34

manager   ~0005942

Thanks for the update; I am testing a few large snappyHexMesh cases now, will report any problems.


2016-02-15 11:19

manager   ~0005944

This change generally works fine, at least for the cases for which it does not significantly affect the face-centre. The only case for which I see a serious problem is with the foamyHexMesh mixerVessel case for which this change causes the meshing to crash:

Face collapsing is on
    Initial face length factor = 0.35
Control mesh quality = on
    Minimum edge length reduction factor = 0.5
    Minimum face area reduction factor = 0.5
    Maximum number of collapse iterations = 10
    Maximum number of edge/face reduction factor smoothing iterations = 1
    Maximum number of times a point can contribute to bad faces across
    collapse iterations = 3
Selectively disabling wanted collapses until resulting quality satisfies constraints in system/meshQualityDict

Outer Iteration = 0

    "Edge Filter Factor": min = 1e-06 av = 1e-06 max = 1e-06
        9964310 / 9964310 elements used

    Inner iteration = 0

        Collapsing 219079 small edges
[2] More than six unsigned transforms detected:
6(((-1.468232221e-07 7.520275254e-06 2.867305949e-05) (1 0 0 0 1 0 0 0 1) 0) ((4.769817608e-08 -2.443097266e-06 2.546124074e-06) (1 0 0 0 1 0 0 0 1) 0) ((-2.638528285e-12 1.351677346e-10 5.465866648e-11) (1 0 0 0 1 0 0 0 1) 0) ((-1.47770
9621e-11 7.568818042e-10 -1.142231587e-09) (1 0 0 0 1 0 0 0 1) 0) ((2.716529779e-11 -1.391405303e-09 4.215973237e-09) (1 0 0 0 1 0 0 0 1) 0) ((1.32806266e-11 -6.802331476e-10 -4.83081769e-10) (1 0 0 0 1 0 0 0 1) 0))
[2] From function void Foam::globalIndexAndTransform::determineTransforms()
[2] in file primitives/globalIndexAndTransform/globalIndexAndTransform.C at line 183.
FOAM parallel run exiting


2016-02-16 21:40

manager   ~0005956

Hmmm, that's a pain, though I kind of expected a change this low down in the bowels of openfoam was likely to affect something.

I don't really to know what to do with this bug, it's just something I noticed when looking at tracking last year. The face calculation as it is is demonstrably wrong in extreme cases, but what effect this has, even whether it is detrimental or beneficial, I don't know. I simply thought that there should be a record of it, hence this report.

If I had to make a recommendation, or if I were charged with fixing this, I would probably apply my patch, but put a debug switch in or similar that lets cases revert to the current behaviour, and then set the switch for this foamy case. It's not an ideal solution, but it would get the change out and therefore widely tested. I'm also struggling to think of any other approach other than simply not fixing it.


2016-02-16 22:45

manager   ~0005957

I am OK with the change in principle and would rather not put it on a switch but someone would need to spend a bit of time looking into the problem triggered in foamyHexMesh; the issue is likely to be associated with some bad faces generated during the collapsing process which might be easy to fix.


2016-02-19 19:37

manager   ~0005974

The foamy case runs for me in serial. Not sure if that makes the problem better or worse, but it's more information.


2016-03-08 14:36

reporter   ~0006020

The error comes from the global transformations calculation. Each of them is a displacement (for separated coupled patches) and a rotation (for rotational coupled patches). As far as I remember the mixerVessel does not have any separated coupled patches nor rotational ones and there should be only one transform ((0 0 0)(1 0 0 0 1 0 0 0 1)). I guess there is an accumulation of errors (the faces can be minute, leading to large errors) which prevents the transforms from merging.


2020-02-19 15:49

manager   ~0011198

Resolved by

Issue History

Date Modified Username Field Change
2016-02-14 12:00 will New Issue
2016-02-14 12:00 will File Added: veryConcaveFace.tar.gz
2016-02-14 12:04 will Note Added: 0005940
2016-02-14 20:34 henry Note Added: 0005942
2016-02-15 11:19 henry Note Added: 0005944
2016-02-16 21:40 will Note Added: 0005956
2016-02-16 22:45 henry Note Added: 0005957
2016-02-19 19:37 will Note Added: 0005974
2016-03-08 14:36 MattijsJ Note Added: 0006020
2020-02-19 15:49 will Assigned To => will
2020-02-19 15:49 will Status new => resolved
2020-02-19 15:49 will Resolution open => fixed
2020-02-19 15:49 will Fixed in Version => dev
2020-02-19 15:49 will Note Added: 0011198