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.
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
