View Issue Details

IDProjectCategoryView StatusLast Update
0001767OpenFOAM[All Projects] Bugpublic2015-09-09 19:57
ReporterTimm SeverinAssigned Tohenry 
Status resolvedResolutionfixed 
PlatformGNU/LinuxOSUbuntuOS Version14.04
Product Version 
Fixed in Version 
Summary0001767: stitchMesh fails when using writeFormat binary
DescriptionFor a "modular" case I create two meshes, which I then merge and stitch together.

The patches that have to be stitched match perfectly, but are not of equal area, thus the -perfect option does not work. However, the -partial options does its job fine, as long as the write format is set to ascii.
However, since I wanted to save time and hard drive capacity, I switched to binary, and suddenly the stitchMesh fails with the message:

Zero length edge detected. Probable projection error: slave patch probably does not project onto master. Please switch on enriched patch debug for more info"
Steps To ReproduceDownload the case, cd to stitchMeshBug and run ./createMesh

The stitchMesh.submesh is the mesh that is being merged into the main case.
Additional InformationThe case is probably not able to run in any solver, since I stripped all boundary information.

It seems to be irrelevant whether the submesh is in binary or ascii format (in this case), only the main case option shows any influence on the result.

This might be related to, though it does seem to be a bit different here, especially since for me the -partial option works in ascii mode.


Timm Severin

2015-06-29 16:36

reporter (38,742 bytes)


2015-09-06 00:36

updater   ~0005336

I probably won't be able to figure this out in a single go, but here's what I've found from your test case: if you set both cases to binary mode ("stitchMeshBug.submesh" is set to "ascii" in your test package) then it will work as intended.

By the way, it's best to split the "mainInlets" patch into two separate patches, to avoid any accidental mesh operations...

But while analysing your test case, it's really odd how the stitching is being made when one case is "ascii" and the other is "binary"... it seems that 2 or 3 points per patch pair are either being misread or there is a buggy tolerance check somewhere... I'll try to continue to diagnose this.


2015-09-06 21:20


stitchMesh.C (14,622 bytes)


2015-09-06 21:24

updater   ~0005338

Last edited: 2015-09-06 21:26

View 2 revisions

Sigh... this is one of those issues that occur due to incomplete documentation for the user :(

Did you know that the "-partial" and "-perfect" options are both optional? And that if we omit both options, the integral matching is used? And that the reported issue is fixed if we omit both options?
Well, I did know this one or two years ago, but I ended up forgetting about this :(

@Henry: Attached is the updated "stitchMesh.C" file (for OpenFOAM-dev), which updates the notes section that is outputted when "-help" is used, along with explicit indication that "-partial" and "-perfect" options are optional.


2015-09-09 19:57

manager   ~0005349

Thanks Bruno.

Resolved by commit 7c87973b0561275c6d785eb8c3cb26d9f8c71b75

Issue History

Date Modified Username Field Change
2015-06-29 16:36 Timm Severin New Issue
2015-06-29 16:36 Timm Severin File Added:
2015-08-17 00:50 wyldckat Tag Attached: stitchMesh
2015-09-06 00:36 wyldckat Note Added: 0005336
2015-09-06 21:20 wyldckat File Added: stitchMesh.C
2015-09-06 21:24 wyldckat Note Added: 0005338
2015-09-06 21:25 wyldckat Assigned To => henry
2015-09-06 21:25 wyldckat Status new => assigned
2015-09-06 21:26 wyldckat Note Edited: 0005338 View Revisions
2015-09-09 19:57 henry Note Added: 0005349
2015-09-09 19:57 henry Status assigned => resolved
2015-09-09 19:57 henry Resolution open => fixed