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/
