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

[Supalov, Alexander]

Thanks. On the C side, the opaque objects are usually pointers to structs (OpenMPI, HP-MPI - please correct me if I'm wrong) or predominantly int handles (MPICH2 and friends, with notable exceptions like MPI_Request and, gee, MPI_File that are again pointers - thanks to ROMIO).

-----Original Message-----
From: mpi3-fortran-bounces at lists.mpi-forum.org [mailto:mpi3-fortran-bounces at lists.mpi-forum.org] On Behalf Of Aleksandar Donev
Sent: Wednesday, June 03, 2009 7:46 PM
To: MPI-3 Fortran working group
Subject: Re: [MPI3 Fortran] Agenda for MPI3 Fortran Working group next week

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/
_______________________________________________
mpi3-fortran mailing list
mpi3-fortran at lists.mpi-forum.org
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran
---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.