View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001914 | OpenFOAM | Bug | public | 2015-11-13 13:55 | 2015-11-21 18:54 |
| Reporter | petebachant | Assigned To | wyldckat | ||
| Priority | normal | Severity | major | Reproducibility | sometimes |
| Status | closed | Resolution | unable to reproduce | ||
| Platform | GNU/Linux | OS | Ubuntu | OS Version | 14.04 |
| Summary | 0001914: meshSearch::findCellWalk sometimes fails in parallel | ||||
| Description | On a mesh that is Scotch-decomposed, meshSearch::findCell(position, 0) sometimes will not find a cell on any processors, where polyMesh::findCell and meshSearch::findCell(position, -1) succeed. This is unfortunate since the walking search is so much faster. Is this a trade-off of the algorithm? | ||||
| Tags | No tags attached. | ||||
|
|
Hi Pete, I'm not familiar enough with the algorithm, therefore a test case that reproduces this problem would come in handy! Best regards, Bruno |
|
|
Hi Bruno, This is a tough one. If you check out commit 3c9148b74fe752c from https://github.com/turbinesFoam/turbinesFoam then run ./Alltest test_cftal:test_parallel the test should fail. Note that this test depends on the Nose Python package. The solver log will be located in `tests/crossFlowTurbineALSource/log.pimpleFoam`. You can also run the test in serial with ./Alltest test_cftal:test_serial It's possible to change the number of processors in `tutorials/crossFlowTurbineAL/system/decomposeParDict` (the test copies the file from there). The parallel test will pass with 2-4 processors. Thanks for your help! |
|
|
Strangely enough the parallel test is passing on 2.4.0, but failing on my machine's 2.4.x: https://travis-ci.org/turbinesFoam/turbinesFoam/builds/90964147 |
|
|
I just tested with OpenFOAM recompiled from the `version-2.4.0` tag on the Git repo and unfortunately the issue remains. |
|
|
Hi Pete, I've finally managed to take a look into this and this feels like the test case you've provided is like looking for a needle in a haystack :( Nonetheless, I've got a feeling that you've tripped over a bug that has already been fixed in OpenFOAM 3.0 and OpenFOAM-dev: https://github.com/OpenFOAM/OpenFOAM-dev/commit/de2c2fb007c4c6f0936c036270e5cf633d775d71 Please try with OpenFOAM 3.0 or dev and let us know. Or please provide a much simpler/easier case to diagnose, because your test case is rather cumbersome to test with, when taking into account the additional source code that has to be built. At the very least, a utility that tests the call to "findCell" with the desired points would make things a lot easier to diagnose! As for why you're triggering this with some builds of 2.4.0 but not others, it might have to do with how the mesh is generated with each build, since the smallest numerical change in the calculation of a point (e.g. a difference of 1e-5) can be enough to make the mesh slightly different. Same goes for the mesh decomposition. Best regards, Bruno |
|
|
I apologize for the bad test case, though I did improve the logging a little. I ended up getting some failures on a hierarchically decomposed case, where the error appears to occur when the cell face is on a processor boundary: https://travis-ci.org/turbinesFoam/turbinesFoam/builds/91410707. Note that this error does not occur on my 2.4.x build. I will try to isolate the issue a little better by refining the tests. I have been trying every permutation of meshSearch::findCell args with no luck. I have decided to stick with polyMesh::findCell until I have 3.0.x or dev setup. |
|
|
OK, if it's already fixed in 2.4.x, then please check if you already have this commit in your build: https://github.com/OpenFOAM/OpenFOAM-2.4.x/commit/1da3d4aa6f9572bf43d027b54830317fd9189d1c Because this specific commit fixes a bug in "Foam::polyMesh::findCell" for running in parallel, related to cell decomposition, which is why your run is crashing, i.e. a flaw in the tet cell decomposition work-flow. |
|
|
Hi Pete, I've installed "python-pandas" and "python-nose" in my Ubuntu 12.04. Tested the old commit 3c9148b74fe752c from https://github.com/turbinesFoam/turbinesFoam - ran ./Allwmake and then I ran: ./Alltest test_cftal:test_parallel This failed for both 2.4.0 and latest 2.4.x. The issue seems to be related to a specific scotch decomposition for the mesh in question or is related to your code not contemplating some specific search scenario. I'm closing this issue for now as "unable to reproduce", although this feels related to issue #1792, which is already fixed. Either way, if you're able to reproduce this error with a specific mesh decomposition and with a simpler test code, please re-open this bug report. Best regards, Bruno |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-11-13 13:55 | petebachant | New Issue | |
| 2015-11-13 14:36 | wyldckat | Note Added: 0005611 | |
| 2015-11-13 15:47 | petebachant | Note Added: 0005612 | |
| 2015-11-13 15:56 | petebachant | Note Added: 0005613 | |
| 2015-11-13 19:47 | petebachant | Note Edited: 0005612 | |
| 2015-11-13 19:49 | petebachant | Note Added: 0005614 | |
| 2015-11-16 19:34 | wyldckat | Note Added: 0005620 | |
| 2015-11-16 19:56 | petebachant | Note Added: 0005621 | |
| 2015-11-16 20:16 | wyldckat | Note Added: 0005622 | |
| 2015-11-21 18:38 | wyldckat | Relationship added | related to 0001792 |
| 2015-11-21 18:54 | wyldckat | Note Added: 0005651 | |
| 2015-11-21 18:54 | wyldckat | Status | new => closed |
| 2015-11-21 18:54 | wyldckat | Assigned To | => wyldckat |
| 2015-11-21 18:54 | wyldckat | Resolution | open => unable to reproduce |
| 2015-11-21 18:54 | wyldckat | Fixed in Version | => 2.4.x |
