View Issue Details

IDProjectCategoryView StatusLast Update
0001914OpenFOAMBugpublic2015-11-21 18:54
Reporterpetebachant Assigned Towyldckat  
PrioritynormalSeveritymajorReproducibilitysometimes
Status closedResolutionunable to reproduce 
PlatformGNU/LinuxOSUbuntuOS Version14.04
Summary0001914: meshSearch::findCellWalk sometimes fails in parallel
DescriptionOn 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?
TagsNo tags attached.

Relationships

related to 0001792 resolvedhenry dgraphFold2 IOstream meshing error non-axis aligned pipe 

Activities

wyldckat

2015-11-13 14:36

updater   ~0005611

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

petebachant

2015-11-13 15:47

reporter   ~0005612

Last edited: 2015-11-13 19:47

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!

petebachant

2015-11-13 15:56

reporter   ~0005613

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

petebachant

2015-11-13 19:49

reporter   ~0005614

I just tested with OpenFOAM recompiled from the `version-2.4.0` tag on the Git repo and unfortunately the issue remains.

wyldckat

2015-11-16 19:34

updater   ~0005620

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

petebachant

2015-11-16 19:56

reporter   ~0005621

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.

wyldckat

2015-11-16 20:16

updater   ~0005622

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.

wyldckat

2015-11-21 18:54

updater   ~0005651

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

Issue History

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