If you are gonna add a swap to the libmesh API, perhaps a do_once warning and
definitely a mpi barrier in there are in order...
On Feb 7, 2013, at 1:26 PM, "Roy Stogner" wrote:
>
> On Thu, 7 Feb 2013, Derek Gaston wrote:
>
>> I'm honestly not sure if it's worth bastardizing the rest of the
On Thu, 7 Feb 2013, Derek Gaston wrote:
> I'm honestly not sure if it's worth bastardizing the rest of the
> libMesh interface to handle this one case when it can be handled
> pretty simply by just providing a libMesh::swap_communicator()
> function.
It's not so much "this one case" as "a bunch
On Thu, Feb 7, 2013 at 1:17 PM, Derek Gaston wrote:
> I'm honestly not sure if it's worth bastardizing the rest of the libMesh
> interface to handle this one case when it can be handled pretty simply by
> just providing a libMesh::swap_communicator() function. I mean... it's
> worked this way fo
Ok - I was able to swap out the communicator and get it all working. I
just created a Parallel::Communicator and assigned it to libMesh::CommWorld
(in addition to doing the other things I mentioned before). This works
fine. I am able to swap the communicator back and forth and get the job
done.
On Thu, Feb 7, 2013 at 11:27 AM, Roy Stogner wrote:
> But there's nothing stopping you from swapping that out too. Go ahead
> and add a Communicator::swap() method.
Ok - I'll give it a whirl.
> That's effectively going to be the final design, I'm afraid - either a
> new optional constructor a
On Thu, 7 Feb 2013, Derek Gaston wrote:
I thought it would be as easy as swapping out libMesh::COMM_WORLD
(and setting libMesh::libMeshPrivateData::_n_processors and
_processor_id)... but there is this Parallel::Communicator CommWorld
thing that doesn't use libMesh::COMM_WORLD that is kind of s
