I agree with that - didn't read far enough.
On Apr 4, 2013, at 6:18 PM, "Roy Stogner" wrote:
>
> On Thu, 4 Apr 2013, Kirk, Benjamin (JSC-EG311) wrote:
>
>> It's the right thing to do so you don't get clashes with e.g. message tags.
>
> That's why we dupe communicators when copying Communica
On Thu, 4 Apr 2013, Kirk, Benjamin (JSC-EG311) wrote:
It's the right thing to do so you don't get clashes with e.g. message tags.
That's why we dupe communicators when copying Communicator objects.
There's probably no reason to do a dupe when loading a raw MPI
communicator into a new Communi
On Thu, 4 Apr 2013, Derek Gaston 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?
Assigning it directly is what I'm doing now in the
roystgnr/communi
K - just double checking ;-)
On Thu, Apr 4, 2013 at 4:33 PM, Kirk, Benjamin (JSC-EG311) <
[email protected]> 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" wrote:
>
> Why do we even dup the incom
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"
mailto:[email protected]>> 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
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 wrote:
> Well... it has to do with the craziness of me swa
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
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 communicatio
Can anyone see the problem here (from libmesh.C line ~370):
// Duplicate the input communicator for internal use
MPI_Comm_dup (COMM_WORLD_IN, &libMesh::COMM_WORLD);
// And get a Parallel::Communicator copy too, to use
// as a default for that API
Parallel::Communicat
