[MPI3 Fortran] Agenda for MPI3 Fortran Working group next week
alexander.supalov at intel.com
Wed Jun 3 17:40:00 CDT 2009
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).
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
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
mpi3-fortran mailing list
mpi3-fortran at lists.mpi-forum.org
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.
More information about the mpiwg-fortran