View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001086OpenFOAMBugpublic2013-11-18 13:002013-11-27 15:07
Reporterbillie Assigned Touser4 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionno change required 
PlatformLinuxOSUbuntuOS Version13.10
Summary0001086: flux run-time post-processing disregards flipMap
DescriptionIt looks like the faceZone flipMaps are not respected when trying to evaluate the face flux for the zones.

The relevant post-processing code is:

massFlow_inte
{
    type faceSource;
    log yes;
    valueOutput false;
    source faceZone;
    sourceName inte_1;
    operation sum;
    fields
    (
        phi
    );
}
Steps To ReproduceAttached you find a sample test case where the problem occurs. If you run the Allrun script the results of the zone post-processing are only correct (which means the flux is the same as defined for the inlet boundary patch "0.0001") if orientFaceZone is run to give all faces the same orientation. If orientFaceZone is omitted the flux is reported wrong as it seems the flipMap is not checked.

The corresponding swak4foam post-processing code which is currently commented out in the controlDict does not require to run orientFaceZone to report the correct flux.
Additional InformationI need to run renumberMesh not only to decrease the matrix bandwidth but also to fix the flipMaps which are not exported correct by Hypermesh.

It simply sets the flipMap to:
flipMap List<bool> $nrFaces{1};

Running renumberMesh creates the correct flipMap.
TagsNo tags attached.

Activities

billie

2013-11-18 13:00

reporter  

example.tar.xz (487,644 bytes)

user4

2013-11-20 09:18

  ~0002646

On your initial mesh the faceZone inte_1 has 'inconsistent' normals. renumberMesh preserves the orientation correctly.

(to visualise: switch on 'Include Zones', select inte_1 only and use 'Cull Backface' in the Display tab.

With orientFaceZone it will set all the orientations to be in the same direction and your summed flux is 'what you expect'.

I don't see a problem with anything. You could see if your mesher can output faceZones with the correct orientation.

billie

2013-11-20 12:13

reporter   ~0002647

I know that there are inconsistent normals and that the fliMap is wrong thus I run renumberMesh which among other things also corrects the flipMap. However I was under the impression that the flipMap is considered when calculating the flux (like flipping all fluxes where for the faces in the flipMap with negative orientation) but apparently this is not the case.

Two additional questions here.
First, what exactly is the flipMap used for if not for things like this? Would it be possible to add such a feature?

Second, with outputting the correct orientation you mean that the faceZone will have consistent normals i.e. all faces have either 1 or 0 orientation?

user4

2013-11-20 14:32

  ~0002648

The flipMap describes for each face in the facezone whether the orientation of the face is according to the face owner (flipMap = false) or face neighbour (flipMap = true). Only for a regular, structured mesh will the faceZone be all 1s or 0s.

The flipMap is part of the mesh specification generated by your mesh generator. renumberMesh and faceSource functionObject both respect it. Either run orientFaceZone or fix your mesh generator.

billie

2013-11-21 09:07

reporter   ~0002650

Last edited: 2013-11-27 07:43

 Okay, so just in case I did not understand everything. Am I correct that if the faceZone is inconsistent and the flipMap does reflect this (orientation is defined according to face owner or neighbour) the faceSource function object should provide the flux 'which I expect'?


If yes then there must be a bug in the faceSource function object as renumberMesh changes the flipMap provided by the mesher and corrects it. If I take a look at the flipMap for inte_1 in the faceZones file after running renumberMesh I get exactly 60 '1s' and 312 '0s' and this are the same numbers I count in paraview with cull backface an cull frontface respectively.
However I did notice something strange when I took a look at the owner cells of the faceZone after running renumberMesh. The cells were all on one side of the zone, but shouldn't the flipMap consist only of '0s' or '1s' then. To create the cellSet for the owners I did use the following code in topoSetDict:
actions
(
    {
        name inte_1Faces;
        type faceSet;
        action new;
        source zoneToFace;
        sourceInfo
        {
            name inte_1;
        }
    }

    {
        name inte_1OwnerCells;
        type cellSet;
        action new;
        source faceToCell;
        sourceInfo
        {
            set inte_1Faces;
            option owner;
        }
    }
)


If no or better in any case to help fixing the mesher (I already reported the incorrect flipMap issue to the company we licensed the mesher from) I want to describe how to define the flipMap properly. So please tell me if the following description is correct:

The flipMap describes for each face in the facezone whether the orientation of the face is according to the face owner (flipMap = false) or face neighbour (flipMap = true).

The owner is the cell with the lower number and the neighbor with the higher number.

(The direction of the face points from owner to neighbor or from the lower to the higher number.)
This probably does not make sense. The documentation says the face orientation is defined by the face points. So it is probably like the following. If the face orientation points from owner to neigbor the flipMap is 1 and if it points from neigbor to owner it is 0 or the other way round.

user4

2013-11-27 15:07

  ~0002665

If the flipMap=0 the orientation is the same as the face.

Issue History

Date Modified Username Field Change
2013-11-18 13:00 billie New Issue
2013-11-18 13:00 billie File Added: example.tar.xz
2013-11-20 09:18 user4 Note Added: 0002646
2013-11-20 12:13 billie Note Added: 0002647
2013-11-20 14:32 user4 Note Added: 0002648
2013-11-21 09:07 billie Note Added: 0002650
2013-11-27 07:43 billie Note Edited: 0002650
2013-11-27 15:07 user4 Note Added: 0002665
2013-11-27 15:07 user4 Status new => closed
2013-11-27 15:07 user4 Assigned To => user4
2013-11-27 15:07 user4 Resolution open => no change required
2013-11-27 15:07 user4 Fixed in Version => 2.2.x