On Sun, 08 Dec 2013 14:38:44 +0000 "Garth N. Wells" <[email protected]> wrote:
> On 2013-12-07 17:13, Jan Blechta wrote: > > On Fri, 06 Dec 2013 17:13:12 +0000 > > "Garth N. Wells" <[email protected]> wrote: > > > >> On 2013-12-06 13:54, Jan Blechta wrote: > >> > I'd like to introduce support for communicator being supplied by > >> > user, stored within mesh and used by other objects based on the > >> > mesh. There are few applications of this. Mikael has one being > >> > rather non-trivial, I > >> > think. > >> > > >> > >> Any object that requires an MPI communicator should take the > >> communicator as an argument. Our present design is way too simple, > >> and is flawed. > > > > Can you explain me, for example, what should be comm stored within > > FunctionSpace instance (different from comm of underlying Mesh) > > useful for? > > > > A FunctionSpace probably doesn't require a communicator. Ok, now I see it - there may be other objects that require a communicator but are not based on Mesh. For example linear algebra objects. Jan > > Garth > > > Jan > > > >> > >> > To achieve this it will require some changes in the interface, > >> > roughly sketched: > >> > > >> > - MPICommunicator::MPICommunicator() > >> > + MPICommunicator::MPICommunicator(const MPI_Comm& > >> > comm=MPI_COMM_WORLD) > >> > > >> > + MPICommunicator::MPICommunicator(const MPICommunicator& comm) > >> > > >> > merging classes MPI, MPINonbocking into MPICommunicator > >> > > >> > + Mesh::Mesh(..., shared_ptr<MPICommunicator> > >> > comm=MPICommunicator()) > >> > > >> > + UnitIntervalMesh(..., comm), ... > >> > > >> > >> Seems a bit complicated to me. > >> > >> As a starting point, I would suggest changing the interface to all > >> the utility functions in dolfin/common/MPI.h to accept an MPI > >> communicator. The next stage is to propagate this upwards. For > >> simplicity and backwards compatibility we should have two > >> interfaces at the top level interfaces - one that assumes the > >> default communicator, and one that takes the communicator as an > >> argument. > >> > >> Garth > >> > >> > Importat question is which type of comm to reaveal to user in C++ > >> > DOLFIN, pyDOLFIN to make it as much as possibly compatible with > >> > other libraries, like boost, PETSc, mpi4py, petsc4py. > >> > > >> > Jan > >> > _______________________________________________ > >> > fenics mailing list > >> > [email protected] > >> > http://fenicsproject.org/mailman/listinfo/fenics > >> _______________________________________________ > >> fenics mailing list > >> [email protected] > >> http://fenicsproject.org/mailman/listinfo/fenics > _______________________________________________ > fenics mailing list > [email protected] > http://fenicsproject.org/mailman/listinfo/fenics _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
