View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002536 | OpenFOAM | Bug | public | 2017-05-03 14:18 | 2018-07-10 11:24 |
| Reporter | karlvirgil | Assigned To | henry | ||
| Priority | high | Severity | major | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Platform | Linux | OS | CentOS | OS Version | 7 |
| Product Version | dev | ||||
| Summary | 0002536: Bug in faceZone sum of phi | ||||
| Description | I’ve been trying to get to the bottom of a bug in the functionObject faceZone sum of phi. I have a simple, 2D channel flow test case that I’m running with fireFoam to debug (using the latest OpenFOAM-dev). If the mesh is constructed with blockMesh without invoking snappy or refineMesh, then everything is fine and the summations are correct. However, if either snappy or refineMesh is used then the flipMap that gets created is wrong. A case such as this, when run as-is, has all the faceZone summations for sum(phi) incorrect except for the inlet/outlet patches which do not need flipMap. However, if I run renumberMesh –overwrite before running the case, then the sum(phi) values are correct. I’ve attached small examples showing these three cases (blockMesh only, blockMesh with refineMesh, and blockMesh with refineMesh and renumberMesh). The only difference between the cases is in the mesh.sh script. sim(phi) should be -0.03 at all face zones in the steady-state solution. In the incorrect case, sum(phi) comes out to be -0.0235 for the faceZones. Look in postProcessing/zone*/0/surfaceFiledValue.dat. Could you consider this as soon as possible? It affects many of our cases. Thanks | ||||
| Steps To Reproduce | Run mesh.sh in each of the three cases attached. Then run fireFoam. Then look at the postProcessing/zone*/0/surfaceFiledValue.dat files and notice that only the channelFlowHenry case and the channelFlowRefineHenryFixed cases yield the correct mass flow. | ||||
| Tags | blockMesh, faceSource, faceZone, refineMesh, setSet, snappyHexMesh, topoSet | ||||
|
|
|
|
|
A workaround for now is to use the utility "orientFaceZone" after the mesh manipulations are completed, so that the "faceZones" are reoriented as needed. The downside is that this requires knowing the practical reference points and it has to be executed once per "faceZone", which may not be practical for really complex "faceZones". |
|
|
Unfortunately, even the orientFaceZone does not do the trick here (I've already tried it in hopes that it would). Only renumberMesh seems to get the flipMap correct. |
|
|
In surfaceFieldValue use 'orientedFields' entry to denote oriented fields, e.g. fields (Uf); orientedFields (phi); I checked the face orientation (using e.g. 'Cull backface' visualisation) and it all is consistent. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2017-05-03 14:18 | karlvirgil | New Issue | |
| 2017-05-03 14:18 | karlvirgil | File Added: channelFlow.tgz | |
| 2017-05-03 14:18 | karlvirgil | Tag Attached: blockMesh | |
| 2017-05-03 14:18 | karlvirgil | Tag Attached: faceSource | |
| 2017-05-03 14:18 | karlvirgil | Tag Attached: faceZone | |
| 2017-05-03 14:18 | karlvirgil | Tag Attached: openfoam-dev | |
| 2017-05-03 14:18 | karlvirgil | Tag Attached: snappyHexMesh | |
| 2017-05-03 14:18 | karlvirgil | Tag Attached: topoSet | |
| 2017-05-03 14:18 | karlvirgil | Tag Attached: refineMesh | |
| 2017-05-03 14:18 | karlvirgil | Tag Attached: setSet | |
| 2017-05-03 14:38 | wyldckat | Note Added: 0008072 | |
| 2017-05-03 14:40 | wyldckat | Relationship added | related to 0002421 |
| 2017-05-03 15:27 | karlvirgil | Note Added: 0008075 | |
| 2017-05-05 12:26 | MattijsJ | Note Added: 0008100 | |
| 2017-05-05 15:50 | henry | Assigned To | => henry |
| 2017-05-05 15:50 | henry | Status | new => closed |
| 2017-05-05 15:50 | henry | Resolution | open => no change required |
| 2018-07-10 11:24 | administrator | Tag Detached: openfoam-dev |
