[MPI3 Fortran] Fortran extra_state argument to MPI attribute functions

Aleksandar Donev donev1 at llnl.gov
Mon Jun 1 11:45:11 CDT 2009

Bill Long wrote:

> Instead, a derived type for 
> a communicator, MPI_comm_t, should be defined in the MPI module.  If 
> users want to add information to the communicator, they can define a new 
> type that extends MPI_comm_t by adding the desired components, and an 
> additional interface (and routine, if needed) for the generic binding 
> copy_fn that indicates how to copy these components, and add an 
> interface to the final binding that performs the delete_fn operation.  
> Specify the communicator dummy arguments as class(MPI_comm_t).
While Bill is right that polymorphism (CLASS(...) dummy arguments) is 
the right way to do this kind of stuff, I am not as certain that it is a 
good idea to make the interface too modern. The danger I see is that 
there will be a split in which most people will continue to (mis)use the 
old F77-style interface, and a smaller group that uses the new, creating 
a big mess. The alternative is to keep the old interfaces as closely as 
possible (some things simply have to be thrown out), so that codes will 
require minimal change. I do not think changing from integer 
communicators to derived types falls under such a minimal change.

That said, this is not a decision I (should) have a say in. We can 
advise on the best Fortran, but the range to work in must come from "above".


Aleksandar Donev, Ph.D.
Lawrence Postdoctoral Fellow @ LLNL
High Performance Computational Materials Science and Chemistry
E-mail: donev1 at llnl.gov
Phone: (925) 424-6816  Fax: (925) 423-0785
Address: P.O.Box 808, L-367, Livermore, CA 94551-9900
Web: http://cims.nyu.edu/~donev

More information about the mpiwg-fortran mailing list