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" 
<fried...@gmail.com<mailto:fried...@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?

Derek


On Thu, Apr 4, 2013 at 3:28 PM, Derek Gaston 
<fried...@gmail.com<mailto:fried...@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 ;-)

Derek


On Thu, Apr 4, 2013 at 3:17 PM, Roy Stogner 
<royst...@ices.utexas.edu<mailto:royst...@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...
---
Roy


------------------------------------------------------------------------------
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
http://www.cisco.com/web/learning/employer_resources/index.html
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net<mailto:Libmesh-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
------------------------------------------------------------------------------
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
http://www.cisco.com/web/learning/employer_resources/index.html
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel

Reply via email to