[MPI3 Fortran] Agenda for MPI3 Fortran Working group next week
donev1 at llnl.gov
Wed Jun 3 12:46:11 CDT 2009
Another Fortran guy talking:
On Wednesday 03 June 2009 04:35, Supalov, Alexander wrote:
> There's certain beauty in the integer handle approach of the current
> Fortran interface. It specifies pretty clearly that the meat of the
> object lives outside of the application.
There is a certain truth to this in the sense that when one allows
handles to be more general derived types one has to be a bit more
specific and careful. We went through this exercise recently when
working out how to add opaque handles for "teams" in coarrays, a task
very similar to communicators.
Essential issues become how these types get "copied". With integers it
is clear, but for derived types not so, since the standard does very
complex things for types with allocatable and pointer components, and
type extensions. Also, the MPI3 module could in principle provide a
defined assignment for MPI communicators, thus overriding the intrinsic
assignment, but only for explicit assignments (passing things as
arguments, for example, still uses the default "copy the value" rather
than "assign the original to the copy"...and what "value" means is
complex for pointer and allocatable components).
I am not sure the C binding resolves any of these issues...but correct
me if I am wrong. Also, typealiases do not provide type safety (since
they do not provide subtyping, as is needed, and this was the reason J3
(unforunately) rejected TYPEALIAS from Fortran 2003).
One way to resolve these issues is to specify that the
TYPE(MPI_Communicator) "is an interoperable type", or "does not have
pointer and allocatable components", or "does not have allocatable
components", etc. One has to decide what to do here. Again, using what
we did for TEAMs in coarrays might be useful (but here following the C
binding closely might be a better guiding principle).
> With the derived type,
> implementors might be tempted to put more than a handle into the
> application space, and then we may have issues with tools,
> compatibility between different MPI versions, etc.
Yes, I agree, which is why guidance is needed beyond just slapping
an "opaque" label. If Fortran had "handles" or at least "value types"
in the language, we would use that. C has some sort of "incomplete
type" concept which is what I would have used but there may be reasons
On Wednesday 03 June 2009 07:37, Supalov, Alexander wrote:
> One of those virtues was an essential ABI compatibility by design
> within the Fortran interface of any particular MPI.
Again, how is this handled with C. Why not follow the lead? Even if it
is a crappy lead :-)
Aleksandar Donev, Ph.D.
Lawrence Postdoctoral Fellow @ Lawrence Livermore National Laboratory
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