[MPI3 Fortran] Deprecate mpif.h?

[Jeff Squyres]

On Mar 5, 2010, at 2:38 AM, Supalov, Alexander wrote:

> It appears to me that you don't want to do this in the name of the  
> Forum as a whole, so, let me ask our partners what they think about  
> deprecating the mpif.h/mpi module, and introducing a backward  
> incompatible mpi3 module that will make them recheck (possibly  
> rewrite)/rebuild/revalidate/recertify their mission critical  
> applications.
>

Alexander -- you're still missing the point entirely.  Yes, I object  
to you asking customers this question because you still apparently  
don't seem to understand it.

The addition of a new mpi3 module does NOT imply anything about the  
continued existence of mpif.h and the mpi module.  When you phrase the  
question like you did above, it implies:

- that the Forum will remove mpif.h and the *ONLY* mechanism available  
will be the new mpi3 module.
- the new mpi3 module is the cause of recertification of their  
application.

That's just wrong.  If I were a customer and had no context for your  
question other than what you said, *of course* I would think a  
backwards incompatible mpi3 module would be a bad idea.

As has been said repeatedly, deprecating != removing.  We, as a Forum,  
would be criminally stupid to remove mpif.h or use mpi any time in the  
near future.

> > 2. Saying that the mpi3 module is only for Fortran 2008 compilers  
> is incorrect.  IIRC, the Open MPI prototype implementation of "use  
> mpi3" has been usable with the Intel Fortran compiler since  
> v10.something, for example (it's up to v11.1.something these days).
>
> I'm afraid you miss my point. As soon as I just say "use mpi3" in an  
> application that used "include mpif.h" or "use mpi" before, I have  
> to recheck, possibly rewrite, rebuild, revalidate, and recertify my  
> application on all OS, platforms, compilers even if I don't change  
> anything else, including the compiler. This is a huge hit that seems  
> to be ignored on this thread.
>

But by your own example, you're going to have to do that anyway  
because you're adding some new functionality into the code.  THAT's  
what causes the re-certification.  Whether that new functionality uses  
mpi3 or not is irrelevant.  Recertification is going to happen  
regardless of whether they use the new mpi3 module or not.

To be clear: you seem to be implying that to compile an existing  
legacy MPI application against an MPI-3 implementation, you *have* to  
"use mpi3" and convert all your code.  This is simply not true.  Per  
the survey data (which you cited in a later email), users strongly  
want to be able to upgrade to an MPI-3 implementation and not have to  
make any source code changes.  Hence, mpif.h and use mpi will still  
function exactly as they did before.

The point: new application functionality -- which you were going to do  
anyway -- causes re-certification.  That new functionality may or may  
not "use mpi3".  Implying that all changes require converting to mpi3  
and *therefore* it's mpi3's fault that you have to recertify is just  
FUD.

Another point: upgrading to an MPI-3 implementation, regardless of  
whether you change any code or not -- will also require re- 
certification.

> > 3. Painting a picture that only advanced / bleeding edge  
> developers will be able to use mpi3 without major disruption is  
> incorrect.  One of the reasons that the conversion functions exist  
> is for exactly this purpose: you can extend legacy Fortran MPI  
> applications with new MPI3 functionality.
>
> I most respectfully disagree. If I have to use conversion functions  
> in my old code, I have to basically rescan all of my application -  
> several million lines of code.
>

Right, and that would be pretty dumb.  Why not use the conversion  
functions in the new subroutines that use mpi3?

--
Jeff Squyres
jsquyres at cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/