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

[Dorian Krause]

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 embedded and charset-unspecified text was scrubbed...
Name: MpiCommDataPatch.txt
Url: https://software.sandia.gov/pipermail/trilinos-users/attachments/20090915/600b3900/attachment.txt