[MPI3 Fortran] Deprecate mpif.h?

[N.M. Maclaren]

Perhaps I should spell out what is likely to become possible with
Fortran 2008 and the TR for choice dummy arguments.  Note I say "is
likely to" - the TR is still being developed, and not everything I
mention is in the current draft, though it has been agreed in principle.

Bill: you might like to see if I have got anything wrong, omitted
anything important or been misleading.


Possibilities
-------------

They will be able to declare a choice dummy argument as assumed-type,
which will eliminate the type checking.  That's it.  The actual type
will still have to be passed separately, and heaven help the programmer
if he gets it wrong.  That will eliminate a breach of standard that
currently causes trouble.

[ TYPE(*) dummy arguments are syntactically and semantically almost
identical to C or C++ void * function parameters. ]

They will be be able to have the ASYNCHRONOUS attribute, which will be
extended to support non-Fortran I/O (such as MPI non-blocking
transfers).  However, to remove the breach of standard and compiler
problems, EVERY declaration for such an array in EVERY procedure that is
'active' between the MPI_Isend and MPI_Wait and declares that array must
use the ASYNCHRONOUS attribute.  If you work it through, this is
essential, and not just Fortran being difficult.  That will eliminate
another breach of standard that currently causes trouble.

[ Incidentally, there are some ghastly ambiguities in the C and C++
standards here, which are 'resolved' by assuming that "but everybody
knows that ...."  They are at the heart of the Great Garbage Collector
debate, if anyone is familiar with that.  But MPI need not worry, as
POSIX has the same problems :-) ]

Even in Fortran 90, they will be able to use INTENT, which will improve
checking, might help with efficiency, and will avoid some obscure
breaches of standard in a few programs (which probably don't cause any
trouble, but ....)  Anyway, it's trivial and obvious.

[ The main comparable problem with C is the lack of 'const' in some
places, which has been fixed in the C++ interface. ]

They will be able to have the ALLOCATABLE dummy argument and the MPI
interface will be able to allocate and deallocate the actual arguments
appropriately.  MPI will need to decide whether it uses this feature or
not, and exactly how it will use it if it does, as it is an important
part of the interface semantics.

[ I don't see how MPI can use it without having a separate set of
interfaces, as my reading of generic resolution doesn't allow for
distinguishing on the ALLOCATABLE attribute (except against POINTER). ]

I don't think that POINTER dummy arguments are relevant to MPI for
choice arguments, though they could well be for MPI_Buffer_attach and
MPI_Buffer_detach.  An implementation could use them for things like
requests, but that's not a specification issue.

Now to the big one.  They will continue to be able to use assumed-size
or explicit-size dummy arguments, as in MPI 2.2, and that will continue to
require a copy-in/copy-out for most implementations if passed an array
section or assumed-shape array.  MPI currently uses assumed-size dummy
arguments.  There's no change here.

But they will also be able to use an assumed-rank dummy argument, which
will take an actual argument of any rank (and even a scalar), and pass a
descriptor that describes its shape.  That will enable (but NOT require)
all known implementations to avoid a copy-in/copy-out for array dummy
arguments, but will NOT accept assumed-size actual arguments.  That's a
significant problem, and MPI will need to consider it.

[ There is an alternative interoperability approach that would allow a
single interface to handle all forms of array and scalar argument, but
that was not accepted. ]


Personal Viewpoint
------------------

1) I don't think that Fortran generic interfaces will help, as they
don't allow generic resolution on the characteristics that MPI needs
to distinguish.

2) I don't think that there are any serious issues to resolve with
TYPE(*), ASYNCHRONOUS and INTENT.  POINTER is probably irrelevant,
except for MPI buffers.

3) MPI will need a set of interfaces using assumed-rank choice
arguments.  This would accept all forms of array EXCEPT for
assumed-size ones, but would ALSO accept scalars, and should not copy
any actual arguments.

4) MPI will need to decide what to do about assumed-size actual
arguments.  There are two options:

  a) Another set of interfaces using assumed-size choice arguments,
much as at present, but with TYPE(*), INTENT and ASYNCHRONOUS for the
non-blocking calls.  This would accept all forms of array, but NOT
scalars, and will usually copy array sections and assumed-shape actual
arguments.

    b) Require the programmer to pass assumed-size arrays as an array
section, but this might be opposed on compatibility grounds.
I.e. replace:
    INTEGER :: array(10,10,*)
    CALL MPI_Bcast(array,1000,...)
by:
    CALL MPI_Bcast(array(:,:,:100),1000,...)

5) If MPI chooses to specify that it will allocate and deallocate
ALLOCATABLE arguments, when necessary, then it will need a separate set
of interfaces for those.

6) MPI will have to decide whether it should require the same
characteristics for all buffers in a call, or to support all
combinations.  I favour the former.

7) One-sided transfers, mutter, mutter, mutter ....


Regards,
Nick Maclaren.