View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001993 | OpenFOAM | Bug | public | 2016-02-14 12:00 | 2020-02-19 15:49 |
| Reporter | will | Assigned To | will | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | GNU/Linux | OS | OpenSUSE Leap | OS Version | 42.1 |
| Product Version | dev | ||||
| Fixed in Version | dev | ||||
| Summary | 0001993: Face centres (and by extension, cell centres) are calculated incorrectly when the initial guess is outside the face | ||||
| Description | primitiveMesh::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 Reproduce | Run 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 Information | A fix can be found here <https://github.com/OpenFOAM/OpenFOAM-dev/compare/master...will-bainbridge:veryConcaveFaceCentres>ยท 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. | ||||
| Tags | No tags attached. | ||||
|
|
|
|
|
Mantis has mangled linking the URL a bit. Without angle brackets... https://github.com/OpenFOAM/OpenFOAM-dev/compare/master...will-bainbridge:veryConcaveFaceCentres |
|
|
Thanks for the update; I am testing a few large snappyHexMesh cases now, will report any problems. |
|
|
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] [2] [2] --> FOAM FATAL ERROR: [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] [2] From function void Foam::globalIndexAndTransform::determineTransforms() [2] in file primitives/globalIndexAndTransform/globalIndexAndTransform.C at line 183. [2] FOAM parallel run exiting |
|
|
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. |
|
|
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. |
|
|
The foamy case runs for me in serial. Not sure if that makes the problem better or worse, but it's more information. |
|
|
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. |
|
|
Resolved by https://github.com/OpenFOAM/OpenFOAM-dev/commit/f85edb01fe02ffb4e88be01ceff958c65a2becb4 |
| 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 |
