BUG: redistributePar hangs with develop-pre-release

steps to reproduce:

Case - motorbike

after snappyHexMesh is completed, try redistributing mesh using 6 CPUs

works in develop.

@mark @Mattijs

changed the description

In redistributePar, findTimes is only called on the master, but inside of fileOperation it calls lookupProcessorsPath, which contains a returnReduce.

If I switch off Pstream::parRun inside the Pstream::master() condition (which seems logical) it still caches the procsDirs_ on the master which means that it still hangs the next time it does do findTimes in parallel.

• there is no problem with the caching per se inside lookupProcessorsPath
• it is just the returnReduce which should not be done (for uncollatedFileOperation)
• this does mean that the cached info can evolve differently on different processors

mentioned in commit 285a837ce423fcb27fd337bdec9245b76629d9d3

Made the lookupProcessorsPath virtual so uncollated could override it with a non-parallel version.

closed