View Issue Details

IDProjectCategoryView StatusLast Update
0000088OpenFOAM[All Projects] Bugpublic2012-07-23 14:22
ReporterbgschaidAssigned Touser4 
Status resolvedResolutionfixed 
PlatformAll tested platformsOSOtherOS Version(please specify)
Product Version 
Fixed in Version 
Summary0000088: snappyHexMesh compiled with Debug-options crashes when run in parallel
DescriptionWhen snappyHexMesh is run in parallel and a Debug version is used it crashes right after "Feature refinement iteration 0" with an Index error ("size x out of range 0 ... y")
Same geometry and decomposition work without problem with an Opt-version

(don't know if this is critical but in my opinion if the Debug-version fails it usually is by good luck that Opt never saw a problem)
Steps To Reproduce* Get the iglooWithFridges-tutorial and blockMesh
* decompose it hierarchical for two or more processors
* run snappy in parallel
Additional InformationThis also happens for 1.6.x and 1.5
TagsNo tags attached.



2010-11-24 10:55


I've just run under valgrind (17x, 3x2x1 hierarchical decomposition) and don't see any problems. Do you maybe have a case setup and a traceback?


2010-11-24 22:00


snappyHexMesh.parallelFail.logfile (8,821 bytes)


2010-11-24 22:00


decomposeParDict (235 bytes)
// * * * * * * * * * //
	version 0.5;
	format ascii;
	root "ROOT";
	case "CASE";
	class dictionary;
	object nix;
  delta 0.0001;
  n (2 1 1);
  order xyz;
method hierarchical;
numberOfSubdomains 2;
decomposeParDict (235 bytes)


2010-11-24 22:15

reporter   ~0000137

I just uploaded a logfile from a failing run. This one is from the standard iglooWithFridges from the tutorials (decomposeParDict also provided)

To be sure I pulled the latest git and recompiled it. Doesn't change a thing

The dump is from MacOS but the same failure happens on Linux too

With Debug-Version I meant "compiled with -DFULLDEBUG". I guess valgrind doesn't find anything because it sees the SubList as some kind of aliasing


2010-11-25 09:45


I think I stumbled across this issue a while before and didn't see it as a serious problem since the face data is not referenced in 'normal' operation, only when the range checking is on does it actually use it. From what I remember the construction order of the patches is such that the polyPatches first get constructed and only later are the starts and sizes reset to fit so temporarily the range will be incorrect and this gets picked up by the SubList constructor.


2010-12-01 20:00

reporter   ~0000152

I guess it doesn't hurt in normal operation (havn't seen that yet). I just stumbled accross it when trying out something in Debug mode and I thought "Stuff that is reported only in Debug-mode usually hints at a bug that will show up 3 months later" but if you say that this is midway through a reorganization then I guess it is OK


2012-07-23 14:22


commit a41115f0953bdb166ca5c09ac4b15638fe3aa75b.

Changed the way of constructing polyPatches.

Issue History

Date Modified Username Field Change
2010-11-24 10:18 bgschaid New Issue
2010-11-24 10:55 user4 Note Added: 0000136
2010-11-24 22:00 bgschaid File Added: snappyHexMesh.parallelFail.logfile
2010-11-24 22:00 bgschaid File Added: decomposeParDict
2010-11-24 22:15 bgschaid Note Added: 0000137
2010-11-25 09:45 user4 Note Added: 0000138
2010-12-01 20:00 bgschaid Note Added: 0000152
2011-07-28 15:41 user2 Status new => closed
2011-07-28 15:41 user2 Assigned To => user2
2011-07-28 15:41 user2 Resolution open => fixed
2012-07-23 14:22 user4 Note Added: 0001492
2012-07-23 14:22 user4 Assigned To user2 => user4
2012-07-23 14:22 user4 Status closed => resolved
2012-07-23 14:22 user4 Fixed in Version => 2.1.x