[MPI3 Fortran] Deprecate mpif.h?
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
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
> > 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?
jsquyres at cisco.com
For corporate legal information go to:
More information about the mpiwg-fortran