On 2013-12-06 15:07, Jed Brown wrote:
Jan Blechta <[email protected]> writes:
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.
To achieve this it will require some changes in the interface, roughly
sketched:
- MPICommunicator::MPICommunicator()
+ MPICommunicator::MPICommunicator(const MPI_Comm&
comm=MPI_COMM_WORLD)
Just a comment that wrapping communicators is a crappy model for
library
interoperability. What happens when a user creates two objects with
the
same communicator. Do you end up with two distinct MPICommunicator
wrappers actually sharing the same MPI_Comm? (Or you MPI_Dup the
communicator, leading to potentially many duplications, which uses a
lot
of memory at scale with some MPI implementations.) What if you pass an
MPI_Comm to another library and it passes that MPI_Comm back to you?
How do you find the wrapper?
A better model is to pass around a plain MPI_Comm and use attribute
caching for whatever internal stuff you need. See how PETSc uses an
inner and outer comm for one possible implementation.
I agree with this. What I don't know is how it would work at the Python
level with the SWIG wrapping, but I don't expect it to be difficult.
Garth
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics
