Skip to content

BlockMesh fails when attempting to merge wedge blocks with mergePatchPairs

Summary

BlockMesh fails to run when attempting to merge a wedge block with a another block using mergePatchPairs. This occurs when merging a wedge to a wedge or a wedge to a quadrilateral block. This issue will not necessarily be something that comes up with wedge type mesh arrangements only.

This issue seems related to Issue #1862 (closed). Unlike issue #1862 (closed) this issue occurs when attempting to merge the three vertex end faces (patches) of a wedge (as opposed to the radial faces between outer radial wedge blocks.)

This issue goes away when including the "mergeType points;" directive in the blockMeshDict.

Before identifying the solution of mergeType I was attempting to solve this issue by using two vertices at the wedge origin located at a very small distance apart i.e. effectively at the same point so the first cells from the origin would in fact be hexahedron instead of prisms. This approach did infact allowed blockMesh to run. This suggests to me that the default merge algorithm is unable to handle the triangular cell faces of the prism cells on the patches.

Oddly enough when I run blockMesh on the rodFoamCase from Issue #1862 (closed) it runs with either the "mergeType points;" directive set or left to the default setting? Maybe there has been changes that already addressed #1862 (closed)?

Steps to reproduce

Within blockMeshDict create two wedge blocks or a wedge block and a quadrilateral block that share a common plane. If using two wedge blocks of the same included angle the wedge faces must not share all vertices on the common plane (like if one of the wedges is longer in the radial direction.) The grading on either side of the plane can be shared or different. Create patches on either side of plane associated with the blocks. blockMesh will run successfully if you do not attempt to merge the blocks. Set the patches to be merged with mergePatchPairs and run blockMesh again. It will fail and give the error shown below.

Example case

I am including a couple of .tar.xz files that provide two cases of this error. One is for wedge blocks being merged together and one is for a wedge block being merged to a quadrilateral block. Just extract the cases and try running blockMesh. They will fail. Open the cases and uncomment the "mergeType points;" directive and try again. blockMesh will then successfully complete. PatchMergeWedgeToWedge.tar.xz PatchMergeWedgeToBlock.tar.xz

What is the current bug behaviour?

BlockMesh only partially runs, outputs an error message and aborts.

What is the expected correct behavior?

Ideally the default blockMesh meshing algorithm should be able to successfully mesh this geometry without requiring a directive to revert to the older meshing algorithm by using 'mergeType points;' in blockMeshDict or blockMesh -merge-points. It seems like it is something that it should be able to do without having to revert to an older meshing method via directive.

Relevant logs and/or images

The error that blockMesh outputs is:

"Adding point and face zones Creating attachPolyTopoChanger

--> FOAM FATAL ERROR: (openfoam-2106) Bad points:(2 0 0) (2 0 0) (3 0 0)

From void Foam::plane::calcFromEmbeddedPoints(const point&, const point&, const point&, const char*) in file meshes/primitiveShapes/plane/plane.C at line 108.

FOAM aborting

#0 Foam::error::printStack(Foam::Ostream&) at ??:? #1 (closed) Foam::error::exitOrAbort(int, bool) at ??:? #2 (closed) Foam::plane::calcFromEmbeddedPoints(Foam::Vector const&, Foam::Vector const&, Foam::Vector const&, char const*) at ??:? #3 (closed) Foam::slidingInterface::coupleInterface(Foam::polyTopoChange&) const at ??:? #4 (closed) Foam::slidingInterface::setRefinement(Foam::polyTopoChange&) const at ??:? #5 (closed) Foam::polyTopoChanger::topoChangeRequest() const at ??:? #6 (closed) Foam::polyTopoChanger::changeMesh(bool, bool, bool, bool) at ??:? #7 (closed) Foam::attachPolyTopoChanger::attach(bool) at ??:? #8 (closed) ? in ~/OpenFOAM/OpenFOAM-v2106/platforms/linux64GccDPInt32Opt/bin/blockMesh #9 (closed) __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6 #10 (closed) ? in ~/OpenFOAM/OpenFOAM-v2106/platforms/linux64GccDPInt32Opt/bin/blockMesh Aborted"

Environment information

  • OpenFOAM version : v2106
  • Operating system : Debian Bullseye (11)
  • Hardware info : AMD Ryzen 9 5950X 16-Core Processor, MemTotal: 65831088 kB
  • Compiler : gcc version 10.2.1 20210110 (Debian 10.2.1-6)

Possible fixes

If someone comes up with a fix I will gladly help test. I will look at the code to see if I can spot the issue. Kind regards. Mark.

Edited by Mark Yobb