[billie]

Originally Posted by wyldckat

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.

While this would be a solution for this simple geometry it won't work for in general i. e. if the faceZone does not lie in a coordinate plane.

No offense, but this seems to me like a workaround. I really would like to identify the underlying bug(s) to have solution which generally works.

[wyldckat]

Originally Posted by billie

No offense, but this seems to me like a workaround. I really would like to identify the underlying bug(s) to have solution which generally works.

Yes, that was the idea, to have a workaround until a fix is available.

The only other way I can think of fixing the broken orientations, would be to either use or create a utility application that fixes the orientations, based on which way we want it to go.


Another detail that is bothering me is this: what if this is a problem of OpenFOAM version incompatibility?
For example, Hypermesh might not be fully tested for OpenFOAM 2.2, but somehow works fine in 2.1 or 2.0?

[billie]

Originally Posted by wyldckat

Yes, that was the idea, to have a workaround until a fix is available.

Sorry for being a bit harsh, I did not get your intention. It is just that I am struggling with this problem for months now and do not get further. Altair does not care about my report. I think they are not willing to investigate time into this problem so I try to do their work and find out what is the issue here to make it easier for them to fix it. It is however difficult to do so if there is a bug in OpenFOAM as well. Is there any chance to open a bug for OpenFOAM about this which does not get rejected immediately?

Originally Posted by wyldckat

Another detail that is bothering me is this: what if this is a problem of OpenFOAM version incompatibility?
For example, Hypermesh might not be fully tested for OpenFOAM 2.2, but somehow works fine in 2.1 or 2.0?

I tested wit OpenFOAM 2.2.2, 2.1.1 and 2.0.1. For my simple model the results were off by 25% for 2.2.2 and 5% for 2.1.1 and 2.0.1 when exporting direct to OpenFOAM format. When exporting to Fluent format first for all versions are off by 25%. So there is a difference between versions for native export but all results are unacceptable. The version of Hypermesh I use was released on 9/23/2013 which already includes some fixes for bugs regarding native export to OpenFOAM reported by me. OpenFOAM 2.2.0 was released on 06/03/13 so I guess they work with 2.2.

[wyldckat]

Sometimes there is an exercise that I like to do: to look into the "$FOAM_APPBIN" folder and look at the names of the binaries and try to ascertain which ones look suspicious enough to come in handy
And I think I found one terribly nice one for you: https://github.com/OpenFOAM/OpenFOAM...ideCells.C#L28

Application

insideCells

Description

Picks up cells with cell centre 'inside' of surface.
Requires surface to be closed and singly connected.

And curiously enough, it's already at openfoamwiki.net: http://openfoamwiki.net/index.php/InsideCells

In essence, all you have to do (although it's just another workaround, but since Altair can't fix things on their end, what else is there...) is to:

1. Create closed geometries in STL file format on one of the sides of each faceZone.
2. Then use insideCells to create the corresponding cellSet.
3. Then convert HyperMesh's faceZone into faceSet.
4. Delete the old "faceZones" file.
5. Create the new faceZones based on the faceSets and cellSets.

Either that, or demand your money back from them.


WAIT!! orientFaceZone ... It's orientFaceZone!!!

orientFaceZone [OPTIONS] <faceZone> <outsidePoint>

This is what should be able to fix those annoyingly disoriented flip maps!

[billie]

Originally Posted by wyldckat

WAIT!! orientFaceZone ... It's orientFaceZone!!!
This is what should be able to fix those annoyingly disoriented flip maps!

THIS IS IT! Bruno you are awesome. I already searched for apps which might be helpful but somehow I missed this one. I think this was before we knew that it is a problem with face orientation thus it did not recognize it.

Originally Posted by wyldckat

Either that, or demand your money back from them.

Should have done this already, although I think this is a bug in renumberMesh.

For the exported mesh all face are oriented in the same directions, renumberMesh seems to flip some faces and after running orientFaceZone all faces have the same directions again. I think this is worth an OpenFOAM bug.

[wyldckat]

Originally Posted by billie

For the exported mesh all face are oriented in the same directions, renumberMesh seems to flip some faces and after running orientFaceZone all faces have the same directions again. I think this is worth an OpenFOAM bug.

Since you've got a simple example handy from the bug report for Altair, feel free to report this in the official OpenFOAM bug tracker : http://www.openfoam.org/bugs/

[billie]

Originally Posted by wyldckat

Since you've got a simple example handy from the bug report for Altair, feel free to report this in the official OpenFOAM bug tracker : http://www.openfoam.org/bugs/

Two things before I open a bug that gets rejected.

First It could be possible that until this issue occurred I was just lucky and renumbering did not change the orientation. Which means Hypermesh did always write a mesh were the cell numbers on one side of the faceZone are consistently lower or higher than the corresponding neighbor cell, so the flipMap was always 1 or 0 for all faces. When renumbering this remained the same and no orientations were flipped.

This time this was not the case and renumbering switched some cells as it is supposed to do when a cell number change occurs which requires a change in orientation. The reason for this may be that until now I only had one volume on each side of the faceZone. Now there were more volumes meshed sequentially on both sides.

Second, from reading the OpenFOAM Wiki about swak4Foam and calcMassflow [1] I was under the impression that it requires the slaveCells of the faceZone to calculate the correct mass flux. This was because of the sentence

but beware: for flip to work correctly in this case an appropriate cellSet with the name beforeFilterSlaveCells has to be defined.

The name beforeFilterSlaveCells is a bit misleading as topoSet faceZoneToCell with the slave options does exactly this. However Swak4Foam does require all cells to be on one side of the faceZone and not the slaveCells which are probably located on both sides depending on the orientation. Only then the mass flux is correct. The same goes for OpenFoam postprocessing, the flux is only correct if the faceZone has a consistent orientation.

So if the faceZone flipMap is not consistent it needs to be oriented (after renumbering the mesh of course). This is currently the only way which works. Which means there is no bug I just got into the wrong direction. I thought the face Orientations are considered by OpenFOAM and swak4Foam but apparently they are not.

One question remains. Why not consider the face orientation of the faceZone and sum up all fluxes with positive orientation and add them to the sum of the fluxes with negative orientation to get the correct mass flux? However there is indeed a bug if this is the desired behavior.

Regarding orientFaceZone I need to open another bug because in my work flow I renumber after I split the mesh regions for my multi region cases and currently orientFaceZone does not work per region. This is however a trivial change I managed to code myself :-)

[1] http://openfoamwiki.net/index.php/Co...e_calcMassFlow

[wyldckat]

Hi Daniel,

Originally Posted by billie

This time this was not the case and renumbering switched some cells as it is supposed to do when a cell number change occurs which requires a change in orientation. The reason for this may be that until now I only had one volume on each side of the faceZone. Now there were more volumes meshed sequentially on both sides.

OK... mmm... if I understand you correctly, it would seem that renumberMesh only has problems on multi-region meshes?

Originally Posted by billie

Second, from reading the OpenFOAM Wiki about swak4Foam and calcMassflow [1] I was under the impression that it requires the slaveCells of the faceZone to calculate the correct mass flux. This was because of the sentence
The name beforeFilterSlaveCells is a bit misleading as topoSet faceZoneToCell with the slave options does exactly this. However Swak4Foam does require all cells to be on one side of the faceZone and not the slaveCells which are probably located on both sides depending on the orientation. Only then the mass flux is correct. The same goes for OpenFoam postprocessing, the flux is only correct if the faceZone has a consistent orientation.

Bernhard should be able to give a better explanation on this one, but two ideas come to mind:

1. The wiki pages might be outdated enough, since the code for swak4Foam might have changed substantially since then. Perhaps something in the README files from each version might shed some more light on this issue.
2. The "beforeFilterSlaveCells" might be for correcting the orientations or for giving the orientations to faceSets or to fix the ones on the faceZones.

Originally Posted by billie

So if the faceZone flipMap is not consistent it needs to be oriented (after renumbering the mesh of course). This is currently the only way which works. Which means there is no bug I just got into the wrong direction. I thought the face Orientations are considered by OpenFOAM and swak4Foam but apparently they are not.

From what I can figure out, the "flipMap" exists precisely because the face orientations of the mesh might be inconsistent in certain mesh scenarios.

Come to think of it, swak4Foam without "flip()" did give you the correct mass flows, wasn't it? Which would mean that it uses the faceZone as a faceSet and only flips the face orientations if a cellSet is given. In other words, by default is does not use "faceZones" the same way as OpenFOAM.

Originally Posted by billie

One question remains. Why not consider the face orientation of the faceZone and sum up all fluxes with positive orientation and add them to the sum of the fluxes with negative orientation to get the correct mass flux? However there is indeed a bug if this is the desired behavior.

Mmm... an example comes to mind: In a zero gravity environment, which way is up?

The faceZone and faceSet are generic concepts. You can a single faceSet or faceZone to have in one of several shapes:

• plane
• box
• sphere
• cylinder
• completely amorphous

Which is probably why orientFaceZones exists: to make all faces on a faceZone aim to the same reference point.

Originally Posted by billie

Regarding orientFaceZone I need to open another bug because in my work flow I renumber after I split the mesh regions for my multi region cases and currently orientFaceZone does not work per region. This is however a trivial change I managed to code myself :-)

Nice! I noticed the report: http://www.openfoam.org/mantisbt/view.php?id=1079


I gotta give a quick test to the multi-region cases that OpenFOAM has got and check the effect that renumberMesh has got on them. This way it'll be easier to ensure that there is a bug or not.

Best regards,
Bruno

[wyldckat]

By the way, I was looking for another post of mine and I happen to stumble upon this code:

Originally Posted by impecca

topoSet -parallel (for local refinement)
setsToZones -noFlipMap -parallel
refineMesh -dict -parallel

Sooo.... any chance you can disable "flipMap" on HyperMesh?

[billie]

Originally Posted by wyldckat

OK... mmm... if I understand you correctly, it would seem that renumberMesh only has problems on multi-region meshes?

Not really, I had the problems with a single region mesh. What I meant is that until now the mesh on each side of the faceZone was meshed in one turn. Now the mesh on both sides was meshed in more than one step. So parts of the mesh having contact to the faceZone were meshed than some on the other side, etc. So probably the cell numbers were more mixed up than before.

Originally Posted by wyldckat

Bernhard should be able to give a better explanation on this one, but two ideas come to mind:

1. The wiki pages might be outdated enough, since the code for swak4Foam might have changed substantially since then. Perhaps something in the README files from each version might shed some more light on this issue.
2. The "beforeFilterSlaveCells" might be for correcting the orientations or for giving the orientations to faceSets or to fix the ones on the faceZones.

From what I can figure out, the "flipMap" exists precisely because the face orientations of the mesh might be inconsistent in certain mesh scenarios.

Come to think of it, swak4Foam without "flip()" did give you the correct mass flows, wasn't it? Which would mean that it uses the faceZone as a faceSet and only flips the face orientations if a cellSet is given. In other words, by default is does not use "faceZones" the same way as OpenFOAM.

I came to the same conclusion. Swak4Foam with the flip option did use the cellSet which was defined incorrect, thus the results were wrong. Without the flip option it did use the information from the flipMap of the faceZone. But this would mean that the postprocessing of OpenFOAM is incorrect.

What I am currently unsure about are the results of the runs without renumbering. Then Swak4Foam with flip should provide correct results because the flipMap is uniform. I need to take another look into this and also check if the created cellSets are different with and without renumbering. If the cellSet remains the same I can understand that both results for Swak4Foam are wrong because the cellSet is wrong and the flipMap (if Hypermesh does not care about the information and sets the flipMap arbitrarily). This is probably the reason because when the cellset is created it does not look up the flipMap but the cell numbers on each side of the mesh. But as I sad I need to check this.

Originally Posted by wyldckat

Mmm... an example comes to mind: In a zero gravity environment, which way is up?

The faceZone and faceSet are generic concepts. You can a single faceSet or faceZone to have in one of several shapes:

• plane
• box
• sphere
• cylinder
• completely amorphous

Which is probably why orientFaceZones exists: to make all faces on a faceZone aim to the same reference point.

I don't see how this is related. In any of these shapes I can measure the flux in one or the other direction of the zone and still consider the face orientation. General directions or coordinate systems do not matter.

Originally Posted by wyldckat

I gotta give a quick test to the multi-region cases that OpenFOAM has got and check the effect that renumberMesh has got on them. This way it'll be easier to ensure that there is a bug or not.

Well I just run renumberMesh on the split mesh because I recognized that the results of renumberMesh are different if the mesh is split. I don't know however what is more efficient, renumber the complete mesh or renumber the individual regions. I think the better option is to run it on the individual regions as they are also solved individual.

[billie]

Originally Posted by wyldckat

Sooo.... any chance you can disable "flipMap" on HyperMesh?

No, there are no export options in Hypermesh at all. It just exports anything that is currently visible and to some degree relies on the naming of the exported parts e.g. when they are starting with starting with wall_* or inte_* etc...

[wyldckat]

I gave one of the tutorials in OpenFOAM a quick spin to try and see if I could see something similar and I didn't manage to seem any problems with it.
Perhaps I was in too much of a hurry, but the tutorial "heatTransfer/chtMultiRegionFoam/snappyMultiRegionHeater" did not give me any problems with using renumberMesh.

Another possibility that comes to mind is that this kind of problem might only occur with tetrahedral meshes.

Originally Posted by billie

I came to the same conclusion. Swak4Foam with the flip option did use the cellSet which was defined incorrect, thus the results were wrong. Without the flip option it did use the information from the flipMap of the faceZone. But this would mean that the postprocessing of OpenFOAM is incorrect.

What I meant to write was that swak4Foam might not use the faceZone flip map by default and use directly the orientation of the faces of the mesh instead.
As for the problem with "flip()" and the cellSets, I thought that the problem was that the cellSets were deduced from the faceZones, therefore the result with "flip()" was as bad as OpenFOAM's calculations (which uses the flip map from the faceZones).

Originally Posted by billie

I don't see how this is related. In any of these shapes I can measure the flux in one or the other direction of the zone and still consider the face orientation. General directions or coordinate systems do not matter.

The idea I was trying to convey is that if the faceZone outlines a complete box, then the mass-flow to be measured would be either the one that goes in vs the one that goes out the box.
...Although... OK, I think I understand your idea: if the surface is contiguous, there are only 2 sides to the faceZone, no matter the shape. Problem is that OpenFOAM allows for faceZones to be non-contiguous, which would require a pre-identification of the faceZone islands and then fixing their flip maps according to the notion of "there can be only 2 sides to a surface".

Originally Posted by billie

Well I just run renumberMesh on the split mesh because I recognized that the results of renumberMesh are different if the mesh is split. I don't know however what is more efficient, renumber the complete mesh or renumber the individual regions. I think the better option is to run it on the individual regions as they are also solved individual.

This will likely depend on the case structure itself and how the regions are distributed among the processors. When in doubt, one should always compare the timings of each strategy. Also because sometimes renumbering only makes it worse.

[billie]

Originally Posted by wyldckat

I gave one of the tutorials in OpenFOAM a quick spin to try and see if I could see something similar and I didn't manage to seem any problems with it.
Perhaps I was in too much of a hurry, but the tutorial "heatTransfer/chtMultiRegionFoam/snappyMultiRegionHeater" did not give me any problems with using renumberMesh.

Another possibility that comes to mind is that this kind of problem might only occur with tetrahedral meshes.

No it occurs with hexaeders as well. It is probably just the different meshing technique used.

Originally Posted by wyldckat

What I meant to write was that swak4Foam might not use the faceZone flip map by default and use directly the orientation of the faces of the mesh instead.
As for the problem with "flip()" and the cellSets, I thought that the problem was that the cellSets were deduced from the faceZones, therefore the result with "flip()" was as bad as OpenFOAM's calculations (which uses the flip map from the faceZones).

I think I understand the behavior of all scenarios and postprocessing methods. First Hypermesh does not care about the orientations and sets everything to 1. I did check this by running topoSet on the unmodified mesh exported from Hypermesh. The created cellSet did look the same way as the one renumbered, which means not all cells are on the same side (topoSet probably does not care about the flipMap and uses the directions calculated from the neighbor cells of each face). This also means renumberMesh is not buggy but instead fixes the orientations.

Now when not renumbering the mesh Swak4Foam provides wrong results because the cellSet is ill-defined. Without flip the results are wrong because it uses the flipMap which is wrong (they would be correct if the orientations are grabbed from the neighbor cells itself).

With renumbering the flipMaps are now correct but the cellSet is still ill-defined and Swak4Foam provides wrong results. Without flip the results are correct as the flipMap is now correct.

Note: The cellset is ill-defined because of me misunderstanding the definition of the cellSet required by the Swak4Foam flip option. If I use a faceSet with all cells of the required cellSet on one side it works in any case. When using a faceZone with Swak4Foam it only works when the mesh is renumbered although the cellset is defined correct. This is something I do not understand until now.

So when not renumbering the mesh or there is a non-contigous faceZone it is better to create a faceSet and a cellSet with all cells on one the desired side(s) of the mesh.

The OpenFOAM postprocessing only works if I use orientFaceZone, but in my opinion it should also work with a correct flipMap, because as you say the reason for the flipMap is because there might be an inconsistent orientation of the faces. This is the bug which I have to report.

Originally Posted by wyldckat

The idea I was trying to convey is that if the faceZone outlines a complete box, then the mass-flow to be measured would be either the one that goes in vs the one that goes out the box.
...Although... OK, I think I understand your idea: if the surface is contiguous, there are only 2 sides to the faceZone, no matter the shape. Problem is that OpenFOAM allows for faceZones to be non-contiguous, which would require a pre-identification of the faceZone islands and then fixing their flip maps according to the notion of "there can be only 2 sides to a surface".

Yes, for non-contigous zones there would be a problem to get the correct direction for all parts of the zone.

Originally Posted by wyldckat

This will likely depend on the case structure itself and how the regions are distributed among the processors. When in doubt, one should always compare the timings of each strategy. Also because sometimes renumbering only makes it worse.

Thanks for the tip, I will compare both methods when doing the next simulations.

[billie]

Originally Posted by billie

The OpenFOAM postprocessing only works if I use orientFaceZone, but in my opinion it should also work with a correct flipMap, because as you say the reason for the flipMap is because there might be an inconsistent orientation of the faces. This is the bug which I have to report.

This is now report #1086. Lets see what happens.

[billie]

Originally Posted by billie

This is now report #1086. Lets see what happens.

I did some more tests and found out that there is only a problem with the mesh export from Hypermesh. With the information I got from the OpenFOAM bug report I was able to give Altair some more informations about what went wrong and now they are working on fixing the OpenFOAM export. I think the main problem is that the flipMap is not exported correctly which confuses OpenFOAM.

Thanks to Bernhard and especially Bruno for spending their time to help me with this issue.