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

[N.M. Maclaren]

On Jan 22 2010, Bill Long wrote:
>
>INTEGER*8 is not part of any Fortran standard - though the * notation is 
>popular in old codes and supported by many vendors.

With a variety of different meanings!  I have seen all of word count,
byte count, and a simple sequence from 1 upwards.

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

Yes, I agree.

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

Again, I agree.  The reason to preserve the old interfaces is for old code.
There's no need to be dogmatic about this, and trivial extensions could be
added where necessary, but the general rule would be that they wouldn't be.

Also, I think that this will be by far the least hassle.

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

Non-blocking buffer attributes, to name just one.


Regards,
Nick Maclaren.