[MPI3 Fortran] Fortran extra_state argument to MPI attribute functions
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
More information about the mpiwg-fortran