undefined (#2241)

I have attached the blockMesh faces file from OpenFOAM 5.x and of OpenFOAM v2012. As you can see the 5.x version generates faces with three points whereas the OpenFOAM v2012 version generates faces that loop back to the original base point

Initial test: v1912 generates prisms, v2006 does not

Is this with point merging or topology merge on the blockMesh?

Workaround is to switch back to the geometric point merging: add to blockMeshDict:

mergeType points;   // Wedge geometry - Merge points instead of topology

or use the command-line option (-merge-points).

We've switched to topological merging by default since it has many advantages. The underlying problem is still under investigation. https://develop.openfoam.com/Development/openfoam/-/wikis/upgrade/v2006-User-Upgrade-Guide#blockmesh

The internals have a mix of cellShape and fixed code assuming hex-only. If you have anything other than 'hex' for the shape-type, none of the internal accounting works at all.

Does this mean, that the tet decomposition only works for hex cells? What happens when I use refineMesh, I have then similar issues, does a similar option as mergeType points exist?

Does this mean, that the tet decomposition only works for hex cells?

Not not at all. It is just that if you use the newer/better/quicker topology merge instead of point merge with wedge-type of blockMesh geometries you will hit this problem. Imagine the 2D case of the same thing. Assume we define a triangle as a collapsed quad:

d ---- c
|      |
|      |  
a ---- b

With 2 divisions per edge, so 3x3 points = 9 points.

Collapse this into a triangle by having c == d  (same as your wedge geometry):

   (c,d)
  /   |
 /    |
a --- b

Topologically this is still a quad and edge c-d has 3 points on it! If you now attempt to triangulate this quad, you will most see that the result is indeed nonsense.

This is where the point merging comes into play (for these specific geometries). With a geometric point merge, the points c, d and all of the intermediate points on the edge c-d are combined as a single point and you have a result of topological triangle and everything will be OK.

Summary: if you have wedge blockMesh geometries, use point merge!

@mark can you tell me where in the code, e.g. which file this occurs? I could have a look at it and maybe find a solution for my case I am currently investigating. If it is a general solution I can also post it here or create a merge request.

can you tell me where in the code, e.g. which file this occurs? I could have a look at it and maybe find a solution for my case I am currently investigating. If it is a general solution I can also post it here or create a merge request.

This is a nice offer, but you will need quite a bit of time for this (various files under src/mesh/blockMesh). The basic issue being that the blockMesh actually seems to build things by using a hex description for its larger blocks. Internally it uses 12 edges for the grading (corresponding to hex edges) etc.

When performing the topological merge, the number of points needed by each block is (nx, ny, nz). After matching up the faces, you then know how many final points are needed etc and which points match up on each block. So you can merge the points based on their topological information only. With collapsed edges, this doesn't yet work.

In the meantime I think that we would probably need do everything internally as hex blocks, even if they degenerate to wedges. I can't see any other simple means of specifying how the mesh points should be distributed anyhow. To handle collapsed edges topologically ould need a rework of the blockMeshCreate.C (and other places).

... looks a bit like a large hole to be digging, thus I opted for the simpler solution of simply using point merging for wedge geometries. This should solve things until someone starts making extremely high aspect ratio wedges.

Thank you for this explanation, it seems to be a bigger problem. I will use then point merge.

Also just saw your comment above. I will investigate then why this happens for me with a refined mesh using the refineMesh tool and the calcRadius option described here: http://bugs.openfoam.org/view.php?id=2004

Tet decomposition should work, unless the cells are bad with extreme concavity (think of the old Pacman game), have centres outside of the cell or really weird concave faces.

Activity