checkMesh consistently fails with IOerrors when using -writeSets stl option
I am running checkMesh in v1712 (mesh generated in same version). When using the option "-writeSets stl", I consistently get an IOstream error. checkMesh works fine with every other combination. This happens on dozens of cases; none successfully execute.
Attached is a test case, simply run run_snappy.sh to generate the failure.
I can also submit this case with the run_snappy.sh already executed, the file is 104MB.
Activity
assigned to @mark
Hi Mark,
I think I have found a potential source of the problem: createPatch. If I don't run createPatch, then checkMesh works. So something is generated during createPatch that checkMesh is not happy with.
As a side note, why is the issue now closed?
By Robert on 2018-03-14T08:35:46 (imported from GitLab project)
Edited by Admin
Actually I was doing my testing without createPatch and could also provoke the problem. It worked fine with
stlb(BINARY),vtk,objetc. It not only aborted withstl(ASCII), but also produced enormously large files that had loads of non-ASCII content. This made me trace back to where the stl files where being generated (in this case specifically src/surfMesh/surfaceFormats/stl/STLsurfaceFormat.C and Line 218 was where I located a problem. Eg, doing a print of the zones after that line also created real issues.I believe that that was indeed the cause of the issue. If it works when you leave away createPatch it is probably purely coincidental.
Re issue closing: this is an automatism as part of the commit message containing fixes/closes. I'll reopen it again now, but ask that you also check if your problem persists after commit 36615732984f is included.
Edited by Mark OLESENHi Mark,
Thanks for the explanation! I've recompiled the fix locally on my workstation, and run checkMesh -writeSets stl on a production case, but get the same error. The mesh was however generated a week ago without this fix.
Does the mesh need to be generated with the fix in order for checkMesh to work? If so, I will remesh the case with the fix and report back.
By Robert on 2018-03-14T10:25:18 (imported from GitLab project)
Everything works fine using stlb and vtk. Only stl has the issue.
I ran "wmakeLnIncludeAll" from the installation directory, but the behavior with -writeSets stl is the same. I've attached the log of the recompilation & wmakeLnIncludeAll run.build_ac3d.log
By Robert on 2018-03-14T12:56:04 (imported from GitLab project)
-
Is the output file (stl) reasonably readable (it is supposed to be ascii), or does it appear to have loads of binary rubbish like I'd seen before?
Edited by Mark OLESEN -
No please don't if it has binary noise, this is an indication that some loop is out of control. Could you add in an old school print just after Line 218 in src/surfMesh/surfaceFormats/stl/STLsurfaceFormat.C so we can see what it is actually seeing. Eg,
const surfZoneList zones = ( surf.surfZones().empty() ? surfaceFormatsCore::oneZone(faceLst) : surf.surfZones() ); const bool useFaceMap = (surf.useFaceMap() && zones.size() > 1); Info<< "have " << zones << " surf-zones, using facemap << useFaceMap << endl;In my previous case this was producing rubbish (when I have UList& instead).
Somehow the changes to src/surfMesh/surfaceFormats/stl/STLsurfaceFormat.C weren't updated, I found that out by inserting your print line only to have compilation fail.
Having manually saves STLsurfaceFormat.C and recompiled, I can confirm on multiple test cases that the fix is working here. Thank you!
By Robert on 2018-03-14T15:28:24 (imported from GitLab project)
mentioned in commit ec169b1e
