View Issue Details

IDProjectCategoryView StatusLast Update
0002536OpenFOAM[All Projects] Bugpublic2018-07-10 11:24
ReporterkarlvirgilAssigned Tohenry 
Status closedResolutionno change required 
PlatformLinuxOSCentOSOS Version7
Product Versiondev 
Fixed in Version 
Summary0002536: Bug in faceZone sum of phi
DescriptionI’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 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.
Steps To ReproduceRun 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.
TagsblockMesh, faceSource, faceZone, refineMesh, setSet, snappyHexMesh, topoSet


related to 0002421 closedhenry Conflict between CreateBaffle and flowRateInletVelocity boundary condition 



2017-05-03 14:18


channelFlow.tgz (83,018 bytes)


2017-05-03 14:38

updater   ~0008072

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".


2017-05-03 15:27

reporter   ~0008075

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.


2017-05-05 12:26

reporter   ~0008100

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.

Issue History

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