[gschaider]

Originally Posted by billie

I did check this and none of the faces of the faceZone seems to be on the processor boundary. The numbers of the faceZone range with gaps from 0 to 1992 and the lowest processor boundary starts at 4630.

Then it is fine. Pity. That would have been a bug I would have understood

Originally Posted by billie

While checking this I recognized that sometimes the startFaces of the inter processor boundaries are not the same. I think they should be same as they share the same faces. So I have procBoundary0to1 -> startFace 15775 and procBoundary1to0 -> startFace 15571.

Start-face doesn't have to be the same. What is important is that the number of faces is the same

Originally Posted by billie

What is strange that I get no other errors. Anyway I think there is a problem with the Hypermesh mesh export. I will take a look at this and report back here.

[billie]

I have reported the Hypermesh to OpenFoam export issue to Altair. Lets see what happens.

[billie]

Originally Posted by billie

I have reported the Hypermesh to OpenFoam export issue to Altair. Lets see what happens.

Today I received an email from the Altair support. The issues I have reported will be fixed in the next Update. Lets see if this improves direct export to OpenFOAM from Hyperworks.

Exporting from Hypermesh to Fluent format and using fluent3dMeshToFoam worked well with the last meshes I have created. Which means the swakExpression and the openFoam faceSource report the correct mass flux. fluent3DMeshToFoam creates a flipMap for the faceZones, probably the openFoam faceSource takes this into account.