[NablaDyn]

Dear FOAMers,

I've been searching the forum and the web now for hours but did not find a solution to my problem. Hopefully you can help me:

I need to stitch two planar, perfectly aligned patches (<auto5> and <auto14>). By 'perfectly', I mean 'perfectly'. They share identical coordinates at all of their nodes (see images).

For no obvious or understandable reason, stitchMesh always crashes when I try to stitch the patches, throwing the following message:

/*---------------------------------------------------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  4.1                                   |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
Build  : 4.1
Exec   : stitchMesh -overwrite auto5 auto14
Date   : Jan 16 2018
Time   : 15:51:51
Host   : "thinkpadYoga"
PID    : 3267
Case   : /home/lichtmes/Desktop/bloomyboxxExamples/MegaCadsMesh/mesh
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Allowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create mesh for time = 0

Coupling patches auto5 and auto14
Resulting (internal) faces will be in faceZone auto5auto14CutFaceZone

Note: the overall area covered by both patches should be identical ("integral" interface).
If this is not the case use the -partial option

Adding pointZone auto5auto14CutPointZone at index 0
Adding faceZone auto5auto14MasterZone at index 0
Adding faceZone auto5auto14SlaveZone at index 1
Adding faceZone auto5auto14CutFaceZone at index 2
Sliding interface parameters:
pointMergeTol            : 0.05
edgeMergeTol             : 0.01
nFacesPerSlaveEdge       : 5
edgeFaceEscapeLimit      : 10
integralAdjTol           : 0.05
edgeMasterCatchFraction  : 0.4
edgeCoPlanarTol          : 0.8
edgeEndCutoffTol         : 0.0001
Reading all current volfields
#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::sigFpe::sigHandler(int) at ??:?
#2  ? in "/lib/x86_64-linux-gnu/libc.so.6"
#3  Foam::slidingInterface::projectPoints() const at ??:?
#4  Foam::slidingInterface::changeTopology() const at ??:?
#5  Foam::polyTopoChanger::changeTopology() const at ??:?
#6  Foam::polyTopoChanger::changeMesh(bool, bool, bool, bool) at ??:?
#7  ? at ??:?
#8  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#9  ? at ??:?
Floating point exception (core dumped)

Don't mind the integral match. I've tried also -perfect and -partial, even in different mesh configurations. For instance, I set the same volume mesh up in a way that the first patch was way larger than the second. No change here. Thus, I assume it has to do with the singularity of the patches. The volume mesh, that these patches belong to, has been generated by revolving a 2D base mesh.

I'm pretty sure, there is no easy way to workaround stitchMesh's inability to perform as intended. Any help or suggestions would be appreciated, anyway.

Kind regards and thanks in advance,

Martin

[NablaDyn]

After a deeper review of the issue, I found out that the problem was due to degenerate edges in the faces. This means, The triangles around the singularity were defined as quads with each of them having two coincident nodes. Maybe the info is helpful to others.


I corrected the faces and stitchMesh now operates as wished.

[gian93]

Hi NablaDyn , I have the same issue.. could you explain in a more detailed way how you solved the problem? thanks

[olesen]

Originally Posted by gian93

Hi NablaDyn , I have the same issue.. could you explain in a more detailed way how you solved the problem? thanks

You should definitely mention which version of stitchMesh you are using. Some changes went into OpenFOAM-v1712 to support a dictionary-driven version, but also fixed a few addressing bugs. Not sure if you would still have issues with OpenFOAM-v1912, v2006 etc, but would be good to know.

[NablaDyn]

Originally Posted by gian93

Hi NablaDyn , I have the same issue.. could you explain in a more detailed way how you solved the problem? thanks

Hi,
In my case, the problem was related to how the individual faces of the patch were compiled by a custom software I wrote. The patch you see in the images has a singularity at its centre, whereby those faces connected to the singularity need to be triangular instead of quadrilateral. But, in an older version, my software was coded to compile any tri face as a degenerate quad, however with two collapsed vertices - simply out of 'coding convenience'. Thus, also any tri in my mesh consisted of four nodes and stitchMesh could not handle it. After fixing my software such that degenerate quads are now described - more consistently - as tris, stitchMesh behaves as expected.