Dear Mr. Squyres,
I agree fully with omitting the explicit interfaces from mpif.h . It is an
important resort for legacy codes.
But, in the mpi and mpi_f08 module explicit interfaces are required for
all(!) MPI-routines.
So far, this is not fulfilled in MPI-versions I know.
I want to point out here, that this has a negative consequence for the
Ftn-coding:
'If someone uses the mpi (or mpi_f08) module, then he cannot put the name of
an MPI-routine in the "only"-list of the mpi module'.
I explain that now:
The following stmt is an example of a desirable stmt, because the programmer
sees at a glance, which quantities are used from this module in his subroutine,
and this stmt limits the quantities in the mpi module only to those actually
needed in the subroutine:
use MPI, only: MPI_COMM_WORLD, MPI_IN_PLACE, MPI_REDUCE
However this stmt will work only, if the explicit interface for MPI_REDUCE
is actually present in the mpi module.
Unfortunately the explicit interfaces are not complete in the MPI
distributions I know,
so the programmer must use instead: a) use MPI, only: MPI_COMM_WORLD,
MPI_IN_PLACE
This has the drawback, that always the implicit interface for MPI_REDUCE will
be used,
i.e. there is no control of the parameter list by the explicit interface,
even if there exists an explicit interface in the mpi module
or : b)
use MPI
Here the explicit interface will be used if present in the module, otherwise
the implicit interface will be used,
this is o.k., but the drawback is now, that the whole MPI world is (silently)
present in the subroutine,
and the programmer cannot see at a glance, what quantities are really used from
the module in the sbr.
Greetings
Michael Rachner
-----Ursprüngliche Nachricht-----
Von: users [mailto:users-boun...@open-mpi.org] Im Auftrag von Jeff Squyres
(jsquyres)
Gesendet: Donnerstag, 6. November 2014 12:42
An: Open MPI User's List
Betreff: Re: [OMPI users] OPENMPI-1.8.3: missing fortran bindings for MPI_SIZEOF
On Nov 6, 2014, at 5:37 AM, <michael.rach...@dlr.de> <michael.rach...@dlr.de>
wrote:
> a) When looking in your mpi_sizeof_mpifh.f90 test program I found a little
> thing: You may (but need not) change the name of the integer variable size
> to e.g. isize , because size is just an intrinsic function in
> Fortran (you may see it already, if you have an editor with
> Fortran-highlighting).
> Although your type declaration overrides the intrinsic function, a renaming
> would make the coding unambiguous.
Good catch. I'll do that.
> b) My idea was, that OPENMPI should provide always an declaration
> (interface) for each MPI-routine
> (and that's what the MPI-3.0 Standard document (Sept.21, 2012) prescribes
> (p. 599+601+603)),
Note that MPI-3 p603 says (about mpif.h):
"For each MPI routine, an implementation can choose to use an implicit or
explicit interface..."
I.e., it is *not* mandated that MPI implementations have explicit interfaces
for mpif.h (although, obviously, it *is* mandated for the mpi and mpi_f08
modules).
There are several reasons why MPI implementations have not added explicit
interfaces to their mpif.h files, mostly boiling down to: they may/will break
real world MPI programs.
1. All modern compilers have ignore-TKR syntax, so it's at least not a problem
for subroutines like MPI_SEND (with a choice buffer). However: a) this was not
true at the time when MPI-3 was written, and b) it's not standard fortran.
2. There are (very) likely real-world programs out there that aren't quite
right (i.e., would fail to compile with explicit interfaces), but still work
fine. On the one hand, it's terrible that we implementers continue to allow
people to run "incorrect" programs. But on the other hand, users *have* very
simple option to run their codes through explicit interfaces (the mpi module),
and can do so if they choose to. Hence, the MPI Forum has decided that
backwards compatibility is important enough for legacy codes -- some of which
are tens of thousands of lines long (and more!), and there are no maintainers
for them any more (!) -- to allow the "good enough" to keep going.
3. But #1 and #2 are mostly trumped by: the goal is to deprecate mpif.h, anyway
(perhaps in MPI-4?) -- so why bother spending any more time on it than we have
to? Ultimately, we'd like to get rid of the mpi module too (maybe in MPI-5?)
-- the mpi_f08 module is the True Way Forward.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
_______________________________________________
users mailing list
us...@open-mpi.org
Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
Link to this post:
http://www.open-mpi.org/community/lists/users/2014/11/25697.php
