View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000088 | OpenFOAM | Bug | public | 2010-11-24 10:18 | 2012-07-23 14:22 |
| Reporter | bgschaid | Assigned To | |||
| Priority | normal | Severity | crash | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | All tested platforms | OS | Other | OS Version | (please specify) |
| Summary | 0000088: snappyHexMesh compiled with Debug-options crashes when run in parallel | ||||
| Description | When 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 Information | This also happens for 1.6.x and 1.5 | ||||
| Tags | No tags attached. | ||||
|
|
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? |
|
|
|
|
|
decomposeParDict (235 bytes)
// * * * * * * * * * //
FoamFile
{
version 0.5;
format ascii;
root "ROOT";
case "CASE";
class dictionary;
object nix;
}
hierarchicalCoeffs
{
delta 0.0001;
n (2 1 1);
order xyz;
}
method hierarchical;
numberOfSubdomains 2;
|
|
|
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 |
|
|
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. |
|
|
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 |
|
|
commit a41115f0953bdb166ca5c09ac4b15638fe3aa75b. Changed the way of constructing polyPatches. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-11-24 10:18 | bgschaid | New Issue | |
| 2010-11-24 10:55 |
|
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 |
|
Note Added: 0000138 | |
| 2010-12-01 20:00 | bgschaid | Note Added: 0000152 | |
| 2011-07-28 15:41 |
|
Status | new => closed |
| 2011-07-28 15:41 |
|
Assigned To | => user2 |
| 2011-07-28 15:41 |
|
Resolution | open => fixed |
| 2012-07-23 14:22 |
|
Note Added: 0001492 | |
| 2012-07-23 14:22 |
|
Assigned To | user2 => user4 |
| 2012-07-23 14:22 |
|
Status | closed => resolved |
| 2012-07-23 14:22 |
|
Fixed in Version | => 2.1.x |
