[Trilinos-Users] Managing MPI Communicator Handle in Epetra_MpiCommData - patch

[Heroux, Michael A]

Dorian,

You make a very valid point.  We have made the assumption that the user will retain the MPI communicator, but have never documented this fact!

We will have to think about whether or not duplicating it is a good idea.  The specific concern is whether or not it will break existing code.  I am not sure.

In the meantime, we can make it explicit that we expect the user to maintain the integrity of the communicator.

Thanks for your comments.


On 9/15/09 3:31 PM, "Dorian Krause" <dorian.krause at lu.unisi.ch> wrote:

Hi all,

my mail is related to the usage of the MPI communicator handle in the
Epetra_MpiCommData class. In my trilinos 9.0.3 version, the class member
Comm_ is initialized by Comm.
IMHO, there are several problems associated with this approach:

* You *implicitely* assume that the communicator handle is valid for the
lifetime of the class. This is not necessary the case (I came to take a
look at the this because of segfaults in the MPI library caused by
exactly this problem) and it's the users duty to take care of this (this
is like storing a pointer but more hidden since the handles are opaque).
* Epetra messages might interfer with user messages. The MPI
communicator concept (as I get it) was introduced essential to give
libraries (such as epetra) the ability to have their own seperate
communication universe.

I think the best option is to use MPI_Comm_dup in the Epetra_MpiCommData
constructor to create a copy of the input communicator for use in
Trilinos. I have attached the (very small) patch to implement this (Note
that this is untested, but I can surely test if you are interested). The
only disadvantage of this is, that the call to the constructor of
Epetra_MpiComm is now a collective operation but I guess thats no
problem at all?!

Please let me know what you think. If you want to stay with the current
code, I would say that we should clearly document the users
responsiblities ...

Thanks,
Dorian Krause


-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://software.sandia.gov/pipermail/trilinos-users/attachments/20090915/0105a814/attachment.html