[lr103476]

Hi everybody,

Here at my university people are also working with Hexpress (by Numeca int.), which also generates unstructured hexa(poly)hedral meshes. Mesh density is regulated by the creation of refinement block. So at those block-interfaces cells are doubled or halved in size.

When I convert such a mesh to Fluent everything is OK, I can fully use the mesh in Fluent for computations and stuff.

Two problems occur:

1) I cannot convert this Fluent mesh to OpenFOAM, a segmentation fault after 'Creating shapes for 3-D cells'.

2) Via starCD format I am able to convert this mesh to OpenFOAM, but strange things occur at the interfaces of the refinement block -> At the 'hanging nodes' tetrahedral cells are generated, which is strange.

The unstructured (hexpress) mesh and close up looks like this:
http://www.aero.lr.tudelft.nl/~frank.../test_full.png
http://www.aero.lr.tudelft.nl/~frank/images/test.png

The conversion (via starToFoam) looks like:
http://www.aero.lr.tudelft.nl/~frank/images/test_OF.png


Any ideas?

Frank

[dmoroian]

What you have here is a mesh with "hanging nodes", in Fluent terminology.
There is a discution on the forum hanging nodes regarding the import of such meshes from fluent.
The suggested solution is what you have done (route through star), because, at least for the moment, fluentMeshToFoam has to be completed in order to be able to import this type of mesh.

Dragos

[lr103476]

Allright.

But in my view, star-CD is capable of handling the interfaces between the refinement blocks. So why are there still pyramid shaped cells at those interfaces?

Frank

[dmoroian]

I am no expert, so I might be wrong, but here is what I understood until now from OpenFOAM: one of the rules regarding the mesh in OpenFOAM, is that one face may belong to maximum 2 cells (one cell on each side of the face, or one cell and nothing on the other side if it's a boundary face).
In your case, the mesh breaks the rule, because at the interface, there are faces belonging to at least 3 cells. If you look at the interface between the coarse and fine mesh, one face on the coarse side is matching 2 faces on the fine mesh (in 2D). What it is needed is to split the face from the coarse side of the mesh in 2, so it will match the fine side faces. Here comes starToFoam (I think) which replaces the big face with two smaller ones. Why it does it in that staggering way, I have no idea.

Dragos

[olesen]

Just a few questions:

* Are the couples created correctly for your Star-CD mesh?

* If you have access to pro-STAR, try using one of the v4 series. In the new version, couples can be used as before, but they are removed via a cptranslate command before the ccm file is saved. There will then be no hanging nodes, but instead the cell faces will be split to create polys, which are just the right thing for OpenFOAM

[lr103476]

What do you mean by couples? How do I check if there are created correctly?

No, we dont have Star-CD or pro-Star here.

Frank

[olesen]

Couples represent either an integral match or an arbitrary match between cells. They used to be in a '.cpl' file, but perhaps your export tool writes them somewhere else (or not at all).

If the format is well documented or easy to decode, you might think about writing your own import routine (not as hard as it may sound).

The brute force solution would be to write out each level of refinement as an individual mesh, convert each to an OpenFOAM mesh and use something like mergeMeshes to join them together.

[jens_klostermann]

@ But in my view, star-CD is capable of handling the interfaces between the refinement blocks. So why are there still pyramid shaped cells at those interfaces?

The pyramid shaped cells has to do with paraview (or maybe the pvReader). This problem was mentioned in one of the discussions earlier.

Jens

[jens_klostermann]

Just do a checkMesh and check what celltypes are present!

Jens

[lr103476]

checkMesh delivers the following results:

Number of cells by type:
hexahedra: 2106
prisms: 0
wedges: 0
pyramids: 0
tet wedges: 0
tetrahedra: 0
polyhedra: 246
Number of regions: 1 (OK).

So in fact there are some polyhedrals present and thus its a conversion issue.

btw, when I switch off the internal mesh in paraview, the mesh looks good. The polyhedrals are created by conversion only in the 3th dimension.

Frank

[jens_klostermann]

So this left cell are your polyhedra (in 3D a decaeder in 2D pentas or so):

+--+--+
|00|00|
|00+--+
|00|00|
+--+--+

(Sorry for the bad draft!)

and everything is fine, is'n it

Jens

[lr103476]

mmm, yes, I guess you're right. Sometimes, in paraFoam thing looks different then they really are. Is foamToTecplot already supporting polyhedrals?

Frank

[lr103476]

Allright, I solved this problem partially by using zipUpMesh to remove the hanging nodes. Very easy!.

Now a second problem arises, when I want to move the mesh. Using checkMesh I got the following warning:

==========================================
--> FOAM Warning :
From function bool primitiveMesh::warnCommonPoints(const label, const Map<label>&, bool&) const
in file meshes/primitiveMesh/primitiveMeshCheck.C at line 1607
Face 11 vertex labels 5(36095 36108 41 50 40) and face 12 vertex labels 6(40 50 41 385 37 36) share 3 vertices.
This mesh should only be used with faceDecomp finiteElement decomposition.
Further face-face warnings will be suppressed.
Face-face connectivity OK.
==========================================

The result is that I can't get this mesh moving using one of my solvers based on icoDyMFoam.

==========================================
==> How do I use faceDecomp finiteElement decomposition ???
==========================================

Regards, Frank