[MPI3 Fortran] What to do with mpif.h in MPI-3?

[Bill Long]

Jeff Squyres wrote:
> A tangled Fortran issue came up at the Atlanta MPI Forum meeting today, in the context of discussing the (contentious) proposal about a new C MPI_Count datatype.  The gist of the proposal is that count parameters are currently int in the C bindings and INTEGER in all Fortran bindings.  The proposal is to have a C type MPI_Count that would allow a C implementation to define the back-end type to be 64 bits in order to allow counts larger than 2^31.
> 
> *** NOTE: There are (many) issues with the proposed C MPI_Count type; let's not go into them here.  I'm asking a Fortran question.
> 
> The proposed MPI-3 explicit bindings can easily accommodate a new MPI_Count type.  So there's no problem there.
> 
> However, there are issues with having a large count type in the implicit interfaces in mpif.h.  INTEGER*8 could be used for the count parameter type because all compilers support it, but it's not part of the language (right?).  Members of the Forum today felt that using KIND parameters would be ugly because these are supposed to be Fortran-77 style bindings (although I believe you have all drummed into me before that all current Fortran compilers, even those that have an executable name with "77" in it, grok KIND typing just fine).
> 

Since no one has bitten, I'll throw out an initial volley...

INTEGER*8 is not part of any Fortran standard - though the * notation is 
popular in old codes and supported by many vendors.  A standard 
alternative would be

   integer(selected_int_kind(18))

The Fortran 2008 standard explicitly requires that at least one integer 
kind support 18 digits.  [Possibly the ultimate example of standardizing 
existing practice.]

I'm sure there is some difference of opinion on what is meant by 
"Fortran 77 style interfaces".    My opinion is that such interfaces are 
free to use more modern syntax and parameterized intrinsic types.  The 
restriction is that only argument passing mechanisms, data types, and 
kinds of arrays that were in f77 should be allowed.  Basically,  derived 
types and  dummy argument declarations that would force the caller to 
have a visible interface are not allowed.


> This discussion led to the question: should we even keep extending the mpif.h implicit interfaces?
> 
> It seems that there is a spectrum of 4 options:
> 
> 1. Deprecate mpif.h and MPI's implicit Fortran interfaces.  This is NOT removing mpif.h support from the spec or any implementation -- deprecating just states that the standard *MAY* remove them sometime in the future.  If we went this route, I'm sure that it would be a LOOOOONG time before mpif.h is removed from the spec because of the millions of lines of existing MPI codes out there that use it.
> 

The Fortran standard has had the concept of deprecated (we call them 
"obsolescent") and deleted features.  In practice, this has been 
something of a flop, especially deleted features.  There are always old 
codes out there that have to be supported, so vendors do not have the 
luxury of actually deleting a feature from the compiler.  So identifying 
a feature as deleted or obsolescent is more of a style statement, with 
no real effect.


> 2. Don't deprecate mpif.h, but do not include any new MPI-3 functionality in it.  This is really only a minor distinction from deprecating; it's just a slightly less-strong statement meant to assure Fortran programmers that we are NOT abandoning mpif.h.  However, the road to all new MPI-3 functionality is via the proposed MPI-3 explicit bindings (i.e., "use mpi3").
> 

I like this better than (1) - it is more honest.  It makes it clear that 
mpif.h will continue to work in legacy codes, which I think is an 
important message.


> 3. Include all new MPI-3 functionality in mpif.h *except* for the "large count" functionality.  This allows mpif.h-using applications to get most of the MPI-3 goodness, with the exception that only INTEGER counts will be supported.  If your app needs larger counts than that, you must "use mpi3".
> 

I suspect there could be more "exceptions" uncovered as work progressed. 
  I think it is simpler to be all one way or the other.


> 4. Include all new MPI-3 functionality in mpif.h, including "large count" functionality.

This one has the potential to break existing programs because of an 
argument kind mismatch.  One could make the argument that this would 
motivate users to migrate to 'use mpi3' more quickly,  but there are 
often barriers to making such changes (code recertification,  too many 
files involved, ...).  Unpleasant visions of geezers with pitch forks 
storming my cubicle....

> 
> What is everyone's opinion on which (1-4) the Forum should go with?
> 

My first choice would be to go with (2).  Stopping updates to mpif.h 
(i.e. rejecting options (3) or (4)) has the advantages  of

  --  Encouraging people to migrate to the module which is superior to 
an include file in many ways (even if there were no new features),

  --  Not disrupting any old codes that might be hard to change, and

  --  Avoids the work, and possible mistakes, of actually changing the 
text of mpif.h.


Anyone writing a new code should be encouraged to use the module. Anyone 
adding usage of a new feature to an existing code already has to edit 
the file involved, so making the include -> use transition at the same 
time is a minimal additional burden.


Cheers,
Bill


-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101