[MPI3 Fortran] Deprecate mpif.h?

[Bill Long]

I would certainly not want to see mpif.h or the mpi module go away. As 
noted, there is a lot of legacy code that depends on them existing.

My interpretation of "deprecate" in this context was that the current 
forms of the mpif.h file and mpi module would be retained as the are, 
but that new features that come out of this update would be incorporated 
into the mpi3 module (only).  I think that would be OK.  Someone 
modifying their code to use a new capability can do the USE at the same 
time.

Cheers,
Bill


Hubert Ritzdorf wrote:
> NEC provides a full mpif.h include file and a separate mpi module.
> The module can be used to perform interface checking, the mpif.h
> include file doesn't contain the interfaces.
> 
> MPI modules depend on the Fortran compile time options and linking
> executables might also change when you deprecate mpif.h. Therefore,
> a clear vote against deprecating mpif.h (or using "use mpi") within
> mpif.h; especially for backward compatibility reasons.
> 
> Hubert
> 
> -----Original Message-----
> From: mpi3-fortran-bounces at lists.mpi-forum.org [mailto:mpi3-fortran-bounces at lists.mpi-forum.org] On Behalf Of Jeff Squyres
> Sent: Wednesday, March 03, 2010 3:02 PM
> To: MPI-3 Fortran WG
> Subject: Re: [MPI3 Fortran] Deprecate mpif.h?
> 
> These are good questions; I hope you don't mind, Rolf -- I took the liberty of replying to the MPI3 Fortran list so that the conversation can be shared.
> 
> 
> On Mar 3, 2010, at 5:20 AM, Rolf Rabenseifner wrote:
> 
>> Question Block A:
>>
>> As far as I understand, the MPI standard never defines
>> that mpif.h must not contain prototypes for MPI routines.
> 
> I think you're right, but I think most people would be surprised if their mpif.h started strictly enforcing prototypes.
> 
>> As far as I understand, it is valid that an MPI implementation
>> defines mpif.h with exactly one line:
>>       use mpi
>> because all compilers are Fortran 90 compilers
>> and use mpi is allowed in free and fixed form sources.
> 
> Yes, I think that's right, too.
> 
> So I've been calling them the "implicit interfaces" -- I guess that's wrong, too.  Sigh.  Now I'll have to think of a better name.  :-)
> 
>> As far as I know, IBM and NEC are doing argument checking with
>> "use mpi" and also with "include 'mpif.h'".
> 
> What do you mean -- that they have an mpif.h that just does "use mpi"?
> 
> Question: if you "implicit none", doesn't that change where you can include an mpif.h, depending on whether it has "use mpi" or one that doesn't?  That seems to be unportable to me.
> 
>> Based on this, I expect that you want to deprecate
>> "use mpi" and  "include 'mpif.h'"?
> 
> Yes.  We know that "use mpi" is broken in many ways.  Yes, you can use compiler-specific extensions to make it work, but the fact that we *require* compiler-specific extensions to the language (which not all compilers have, right?) makes it pretty icky.
> 
>> Are there any changes in the API between routine MPI_Xxxxx
>>  - in "use mpi" and  "include 'mpif.h'" 
>>  - and in use mpi3 ?
>>
>> If yes, then pleas explain the details.
>> If now, then I do not understand why we want to introduce
>> "use mpi3".
> 
> Yes -- MPI handles will no longer be required to be INTEGERs.  ierr will also be optional.
> 
>> As far as I understand, the differences can be in handling MPI datatypes.
>> Is there any MPI-2.2 defined usage or well known existing portable
>> meaning of the MPI derived datatypes together with some
>> Fortran memory data specification (such as arrays, contiguous
>> subarrays, non-contiguous subarrays, Fortran derived types with
>> sequence attribute, common blocks, ...) that will work
>> different between "use mpi" and "use mpi3"?
> 
> I'm not sure what you mean here...?
> 
>> If there is a difference between "use mpi" and "use mpi3" for
>> buffer arguments, then argument checking together with "use mpi"
>> must implement the buf arguments as "unchecked" arguments,
>> and not with the new features coming in Fortran 2008.
> 
> I thought that J3 gave us a format to use for un-typed buffers, and even though full F08 compilers won't be available for a while, this feature was likely to start becoming available in the near future...?
> 
>> In this case I would strongly recommend
>>  - not to deprecate "use mpi" nor "include mpif.h", and
>>  - all vendors add the IBM/NEC hack (void arguments) to their
>>    Fortran compiler, and
>>  - they implement mpif.h as "use mpi", and
>>  - they define all mpi routines with Fortran 90 interfaces
>>    and all buffer in their argument list as void.
>>    (i.e. current IBM/NEC quality).
>>  - The new "use mpi3" has a different meaning for the buffers,
>>    nothing else.
>>  - There is no need to deprecate "use mpi" nor "include mpif.h".
> 
> I don't understand this proposal at all; it seems to disregard several months worth of discussion.
> 
>> Question block B:
>>
>> If there are differences, can we handle the new definition on
>> a per-subroutine-basis together with a preprocessor?
>> That would mean, keeping both interfaces is possible.
> 
> I don't quite understand.  Can you provide an example?
> 
> What about Fortran codes that don't use a preprocessor?
> 
>> That would also mean, that inside of one Fortran program block,
>> some MPI routines are using the old interface and some the new one.
> 
> That seems risky to me -- I'm assuming that would be fairly confusing to an end user.
> 
>> In this case, an optional feature would be to have an
>> additional "use mpi3" with the additional feature, that
>> argument checking for all MPI routines is a must.
>>
>> As mentioned in block A, it is still allowed that an
>> implementation has implemented "include mpif.h"
>> as "use mpi" together with fortran 77 compatible
>> interface definitions (i.e., with void buffers).
>>
>> Kind regards
>> Rolf
>>
>> ----- "Jeff Squyres" <jsquyres at cisco.com> schrieb:
>>
>>> Rolf --
>>>
>>> Have you commented yet on the idea of deprecating mpif.h?  I'm
>>> interested to hear your opinion; I don't recall if I've heard you say
>>> anything about it yet.
>>>
>>>   
>>> http://blogs.cisco.com/ciscotalk/performance/comments/...but_what_about_mpif.h/#more
>>>
>>> --
>>> Jeff Squyres
>>> jsquyres at cisco.com
>>> For corporate legal information go to:
>>> http://www.cisco.com/web/about/doing_business/legal/cri/
>> --
>> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner at hlrs.de
>> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530
>> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832
>> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner
>> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)
>>
> 
> 

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