K - just double checking ;-)

On Thu, Apr 4, 2013 at 4:33 PM, Kirk, Benjamin (JSC-EG311) <benjamin.kirk-1@nasa.gov> wrote:
It's the right thing to do so you don't get clashes with e.g. message tags. 

On Apr 4, 2013, at 5:18 PM, "Derek Gaston" <friedmud@gmail.com> wrote:

Why do we even dup the incoming communicator?  Why not just assign it directly to COMM_WORLD and CommWorld?

Is it just the "right" thing to do?  Or is there really some reason for it?


On Thu, Apr 4, 2013 at 3:28 PM, Derek Gaston <friedmud@gmail.com> wrote:
Well... it has to do with the craziness of me swapping and unswapping MPI communicators to get libMesh to work on sub-communicators ;-)

When I swap on one processor it sets both COMM_WORLD and CommWorld to the sub-communicator.  When I swap back it sets them both to what COMM_WORLD was before the swap... so on any processor that swapped and swapped back COMM_WORLD would match CommWorld.

If any processor didn't do any sub-solve then it won't swap at all... and so it has a mismatched COMM_WORLD and CommWorld.... so now the CommWorlds on processors that swapped won't match the CommWorlds on processors that don't swap..... and the next thing done using CommWorld will hang.

Thoroughly confused?  This is exactly why Ben's branch is so damn important ;-)


On Thu, Apr 4, 2013 at 3:17 PM, Roy Stogner <roystgnr@ices.utexas.edu> wrote:

On Thu, 4 Apr 2013, Derek Gaston wrote:

This has actually caused a bug that I've been trying to track down... just switching that last line to:

      Parallel::Communicator_World = libMesh::COMM_WORLD;

How'd that bug manifest?  You had some processors trying to
participate in a communication via COMM_WORLD and others trying to
participate in the same communication via CommWorld?

Go ahead and commit that fix to master...

Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire
the most talented Cisco Certified professionals. Visit the
Employer Resources Portal
Libmesh-devel mailing list