[MPI3 Fortran] Deprecate mpif.h?

Jeff Squyres jsquyres at cisco.com
Mon Mar 8 10:42:57 CST 2010

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  

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  

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

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

More information about the mpiwg-fortran mailing list