OK. Because usually when a cellSet looks like this the mesh has been reordered. The definition of the slaveCells is that they should all be on one side of the faceSet (to say "this is left"). From the picture you show it is not clear to me where the faceSet would be. It looks to me like for instance the one cell on the left "string" is on an inconsistent side compared to the others (and several others too). In that case a wrong mass-flow is perfectly explainable (as for instance this one face contributes with the wrong sign to the sum)

You've got a point there. Will check this and report back tomorrow.

Attachment 26291

Above are the cells for one faceZone which is marked red. So you say for one faceZone the slaveCells should be all on the same side. I thought it is normal if the cells are on different sides marking one side as positive and the other as negative and consider this for the flux calculation.

The question is why are some cells on the right side? Below is the code from topoSetDict I use for creating the zones.

Greetings to all!

@Daniel: If I remember this correctly, in order to define a "faceZone", one needs to have a "faceSet" and a "cellSet", where:

• The "faceSet" indicates which faces are going to be part of the "faceZone".
• The "cellSet" indicates a group of cells on the side of the master or slave... I can't remember which one it should be :(

In order for this situation on the image to occur, it means that the "cellSet" was messed up, in the sense that it must have over-selected some of the cells on the right, leading to this result.

This is basically because a "set" only indicates a selection and a "zone" indicates a part of the mesh that acts as a ghostly geometry/mesh sub-domain, which means that the normals to that geometry are important.

Best regards,
Bruno

As I mentioned already, I create the faceZone in Hypermesh. If I prefix a set of internal faces with "inte_" the faceZone is created automatically when exporting to the OpenFOAM format. This is the same as if I would have exported it as a Fluent mesh and convert it with fluent3DMeshToFoam. I can define a face orientation in Hypermesh but this has no influence on the orientation in the OpenFOAM mesh.

Afterwards I create the inte_*SlaveCells cellSets with topoSetDict by specifying the faceZones. So it seems instead of selecting just one side (the slave side as specified in topoSetDict) the cells on all sides are selected.

You can diagnose which exact cells have been selected by running:
And then open in the folder "VTK" the respective file on ParaView.

I already posted a picture of the selected cells in post #18 and #23 of this thread. There is no need to use foamToVTK as paraFOAM is able to display the cellSets without it. Just select "Include Sets" after starting paraFoam above the "Mesh parts" selection box.

Sorry, I got lost in the middle of the conversation and only read with more attention the latest post :(
And since I didn't know which reader for ParaView you were using, I assumed the worst case scenario, hence suggesting foamToVTK.

Then the picture in the post #18 is of the cellSet from which the faceZones are derived from?
If so, is that cellSet created by HyperMesh? Because if it is, then it's a bug in HyperMesh.

I say this because the normals for the faceZones are calculated based on the centers of the cells on the provided cellSet.

In Hypermesh I did create the volume mesh. From the volume mesh I did create the patches and the faceZones. As I mentioned in post #25 the faceZone is created when exporting the mesh from Hypermesh. So basically everything needed for the mesh is already there when exporting the mesh except the cellSet. The cellSet is then derived from the faceZone exported with the mesh.

I also do not understand why I have to create the slaveCells cellSet as the face orientations are already there. In the faceZones file exported there is a flipMap after each faceZone which defines the orientation of the individual faces.

Hi Daniel,

Sorry for making you repeated yourself once again :( I re-read the posts now and had a better look into the case you had shared with me. Hopefully I didn't miss anything this time.

And my conclusion is the same as Bernhard's:
and I think I've got some proof:

1. The faceZones are provided by HyperMesh.
2. You used renumberMesh to sort the mesh into a better order for the parallel run.
3. But there is no indication in "log.renumberMesh" that the faceZone normals have been preserved. And there is no "renumberMeshDict" file in the "system" folder.

Therefore, even though you used topoSet after the renumber, the damage had already been done to the faceZones.


Now, in order to fix this problem, the change will likely have to be done prior to running the simulation :( Although if the renumber is identical, you might be able to copy the fixed "faceZones" file from a another case folder where the mesh was renumbered from the original.
As for the fixed renumbered mesh, I have not tested this, but it seems that renumberMesh can use a dictionary file, as exemplified at "applications/utilities/mesh/manipulation/renumberMesh/renumberMeshDict": https://github.com/OpenFOAM/OpenFOAM...numberMeshDict - it seems to have options that might helped preserve the flipMaps for the faceZones.


As for the necessity for the cellSets by swak4Foam: I have no idea. I can only guess that the pre-identified cells can help have a faster calculation, instead of having to infer said set from the faceZones... possibly at the start or on each iteration. Either way, as I wrote before, there is a relation between faceZones and cellSets, and that's for assigning the normals to the faceZones.

Best regards,
Bruno

OK. Consider this: we have 4 cells (labeled A, B, C and … D). Between them there are two faces (1 and 2) in a faceZone/Set like in this sketch

A B
1 2
C D

Now if A is the owner of 1 and D the owner of 2 then the faceNormal of 1 points down and 2 up (or the other way round; I keep forgetting). That means in order to get consistent mass flows we need the flip-field. For a faceZone this is already defined and swak is content (of course you depend on the preprocessing utility to define it correctly. If the programmer was lazy the flip is set to some arbitrary value). No cellSet needed

faceSets have no flip-information. Therefor the slave-cellSet is needed (in our case that would be either AB or CD) to get directional information. The cellSet is only used by swak the first time that the flip-map is constructed

Well to check this I simply tried running the case without renumbering and the results were the same. Also the faceZones did look the same.

However one strange thing happened:
If you remember the table with the results for the different postprocessing methods I posted in comment #16. The results for case Swak4Foam2 were I did not use flip were correct. Now without renumbering I get the same wrong results as for the OpenFOAM and Swak4Foam1 method. The results for the other methods remain the same.

Maybe this is related to the following observation. The flipMaps from the faceZones exported from Hypermesh all look like this:

This means either all have the same orientation or Hypermesh does not care about the orientation and sets all to 1. After renumbering the zones inte_1 and inte_2 have some faces flipped to 0. Zone inte_3 to inte_6 remain like they are.

To find this out I manually switched the flipMaps back to being all 1 for zone inte_1 and inte_2. Now all postprocessing tools report the same correct mass flow.

So it looks like renumberMesh is flipping some orientations it should not flip. However if do not run renumber there is something wrong as well. Am I going crazy?

From looking at the renumberMesh code it looks like everything which is related to faceZone orientation is done unconditionally.

This clarifies a lot, thanks for the explanation. So faceZones with correct flipMaps do not require the slaveCells cellset. faceSets require it as the faces do not have their orientation defined.

This is probably OK (but this is just a theory): all cells on one side of the zone belong to one block and the cells on the other side to another (at least that is how mesh generators usually do this). That means that the lowest cell number of one block is higher than the highest of the other. As OF needs for a face the cell-number of the owner to be lower than the neighbour. From that follows that the flip is the same for all faces

Honestly, I think that you are triggering two bugs here:

1. One bug in HyperMesh, regarding faceZone exports;
2. and another in OpenFOAM, regarding renumbering the mesh.

The only way to ascertain which is which, is to create simple test cases and then diagnose if the problem occurs in them as well... because this feels like one of those bugs that only occur in certain specific situations :(.


The other idea is to fall back to the safest bet: define in HyperMesh the cellSets and faceSets and then use OpenFOAM to create its own faceZones. If this fails, then something veeery wrong is going on :(

I have created a simple test case where the same problem occurs and sent it to Altair. Lets se if they care about the face orientation or not.

Regarding falling back to the safest bet, I currently have no idea ho to define faceSets and cellSets in Hypermesh.

To test this I tried to manipulate some cell numbers in Hypermesh but it seems the mesh is renumbered at export time so I can not check if this is true.

But it writes Zones? Then you can always use the topoSet-utilitiy to create the corresponding sets from that. That would be the ultimate proof that the flip generated by Hypermesh is wrong: build sets (including the slave-cellZone). Use them to generate a new faceZone and check if the flip-field is uniform for that too

I did create three new faceZones using different methods. Therefore I did create the slaveCells from the exported faceZone, the faceSet from the exported faceZone and the ownerCells of the faceSet.

From this I did create a faceZone from only the faceSet, another one from the faceSet and the slaveCells and a third one from the faceSet and the ownerCells.

Create slaveCells from faceZone:
Create faceSet from faceZone:
Create ownerCells cellSet:
Create new faceZone1 from faceSet only:
Create new faceZone2 from faceSet and slaveCells:
Create new faceZone3 from faceSet and ownerCells:
Without renumbering the flipMap of the exported faceZone looks like this:
flipMap List<bool> 372{1};
and the flipMaps of the tree created faceZones like this:
faceZone1
flipMap List<bool> 372{0};
faceZone2
flipMap List<bool> 372{1};
faceZone3
flipMap List<bool> 372{0};

With renumbering the flipMap of the exported faceZone looks like this:
Attachment 26483
and the flipMaps of the tree created faceZones like this:
faceZone1
flipMap List<bool> 372{0};
faceZone2
identical to the attached faceZone
faceZone3
flipMap List<bool> 372{0};

I don't know which conclusion I should draw from this. faceZone2 from the faceSet and the slaveCells is always identical to the exported or renumbered one. For the other two faceZones the renumbering does not affect the result i.e. they are the same as without renumbering. But I guess only the method which creates faceZone2 is important.

Greetings to all!

(I hope I didn't miss anything this time.)
If my memory doesn't fail me, this geometry wasn't very complex on the face zone locations; more specifically, the faceZones were oriented with a particular axis orientation. Therefore, you can simply do this:

1. Convert the faceZones to faceSets.
2. Use the "box to cellSet" option and select the group of cells to the right or left of each one of the faceSets. In other words, created your own cellSet selection, not one derived from the original faceZones.
3. Finally create new faceZones based on the faceSets and the manually created cellSets.

There aren't any problems if you select all of the mesh cells on the mesh to the right or left of a faceSet. All that matters is that at least the cells on only one side of the faceSet are selected.
The tutorial "heatTransfer/buoyantSimpleFoam/circuitBoardCooling" is a good example of this.

Best regards,
Bruno