[MPI3 Fortran] Agenda for MPI3 Fortran Working group next week

[Aleksandar Donev]

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 
against it...

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 :-)

Best,
Aleks

-- 
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
Web: http://cims.nyu.edu/~donev/