June 2014 - mpiwg-fortran - mailman3.cels.anl.gov

Re: [MPIWG Fortran] MPI_SIZEOF: redux
by N.M. Maclaren 12 Jun '14

12 Jun '14

On Jun 6 2014, Malcolm Cohen wrote: > >>Lots of user codes are using mpif.h > > So what has that got to do with deprecating MPI_SIZEOF? Nothing > whatsoever. Agreed. > Not to mention that not a single one of those people using the so-called > F77 binding are using a mere FORTRAN 77 compiler. Even the INCLUDE > "mpi.h" line is a Fortran 90 feature that is not present in FORTRAN 77. Sorry but, in practice, it isn't. It's a 'Fortran IV' extension to Fortran 66 (sometimes with syntactic differences) and 77, that has been nearly ubiquitous since the early 1970s. I agree that it didn't reach the standard until Fortran 90. It's explicitly one of the required extensions to Fortran 77 (see MPI 1.3, 2.5.1, lines 34-36). > But since STORAGE_SIZE is far from universally available, this falls at > the very first hurdle. (And alternative ways of computing sizeof in e.g. > pure Fortran 90 are, although easy to write, not particularly convenient > to use, so those fall at the second hurdle.) Are they? I can't think of any that are entirely portable, though I can think of several that will probably work on all current systems. I agree that such tricks are not something that anyone should be teaching or encouraging. Regards, Nick Maclaren.

1 0

Re: [MPIWG Fortran] MPI_SIZEOF: Errata required (was: Another MPI_SIZEOF question)
by Bill Long 11 Jun '14

11 Jun '14

On Jun 11, 2014, at 3:18 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > On Jun 11, 2014, at 4:07 PM, "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> wrote: > >> I open to suggestions. >> >> 1. One obvious possibility is to re-instate "extended Fortran support"-like language, a la MPI-2.2. This does not make it possible to have MPI_SIZEOF in mpif.h, however, so I don't think it really solves the problem. >> >> 2. Another possibility is to say that MPI_SIZEOF is only available in the mpi and mpi_f08 modules (e.g., add an exception in MPI-3.x 17.1.4 saying that MPI_SIZEOF support is excluded from mpif.h). Per Bill Gropp's email (http://lists.mpi-forum.org/mpiwg-fortran/2014/06/1572.php) we'll actually have to add exceptions / remove references to overloading for all mpif.h cases -- not just MPI_SIZEOF. > > > I accidentally hit "send" before adding: > > 3. Bill Gropp's suggestion (http://lists.mpi-forum.org/mpiwg-fortran/2014/06/1592.php) of removing "Fortran 77" support entirely. > > I'm not a big fan of effectively removing support for older Fortran compilers in a point release of MPI (i.e., 3.1 -- 4.0 might be a better candidate for this). But I acknowledge Bill's warning (the "As an alternative..." paragraph is the above-cited email) about selectively editing the text to allow "Fortran 77" compilers. > > Indeed, the problem is more insidious than we initially thought -- because it's not just "Fortran 77" codes that are affected, but any source.f code, because it will likely invoke compiler defaults that will preclude using INTERFACE blocks and other modern Fortran constructs. I’m not aware of any compiler like that, but I suppose it is possible. But, in general this seems like a pointless / silly convention to impose. A compiler switch to change the source form default is reasonable (and common). But why would you remove parts of the language? > > Hence, mpif.h really is stuck in the past. It is possible that the only reasonable solution is to make mpif.h safe for source.f-like behavior, and then deprecate mpif.h in MPI-4.0. > The idea of include files in Fortran of any sort is “stuck in the past”. Cheers, Bill > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran Bill Long longb(a)cray.com Fortran Technical Suport & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101

1 0

Re: [MPIWG Fortran] MPI_SIZEOF: Errata required (was: Another MPI_SIZEOF question)
by Bill Long 11 Jun '14

11 Jun '14

On Jun 11, 2014, at 3:07 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > On Jun 9, 2014, at 8:31 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > >> Yeah, I kinda came to that same conclusion over the weekend (that OMPI's MPI_SIZEOF support in mpif.h would have to depend on which Fortran compiler is used). Urrrgh... > > > Actually, this doesn't work, either. If you have an mpif.h that contains an "INTERFACE MPI_Sizeof", the compiler will treat it differently depending on whether it is included from source.f or source.f90 (and probably other variants, too). Gaahhh! Not sure why you say this. Unless the lines get too long because of long names, you can write an include file so that it works for both fixed and free source forms. The assumed source form is the only distinction to the compiler between source files that end in .f and .f90. > > This means that it is not possible -- and has never been possible -- to have an MPI-3.0 compliant MPI_SIZEOF interface in mpif.h. An errata is therefore required. > > I open to suggestions. > > 1. One obvious possibility is to re-instate "extended Fortran support"-like language, a la MPI-2.2. This does not make it possible to have MPI_SIZEOF in mpif.h, however, so I don't think it really solves the problem. > > 2. Another possibility is to say that MPI_SIZEOF is only available in the mpi and mpi_f08 modules (e.g., add an exception in MPI-3.x 17.1.4 saying that MPI_SIZEOF support is excluded from mpif.h). Per Bill Gropp's email (http://lists.mpi-forum.org/mpiwg-fortran/2014/06/1572.php) we'll actually have to add exceptions / remove references to overloading for all mpif.h cases -- not just MPI_SIZEOF. As you might recall from earlier conference calls, I prefer that nothing be added to mpif.h that was not there before. None of the new functions or constants. It should be frozen at MPI 2.2 for compatibility with legacy codes. If programmers want to use new features, they have to modify their sources anyway, and should change to using a module at the same time. Cheers, Bill P.S. For benefit of JH: My family ancestry is 25% each of Dutch, Danish, English, and, yes, GERMAN ! :) > > Thoughts? > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran Bill Long longb(a)cray.com Fortran Technical Suport & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101

1 0

Re: [MPIWG Fortran] MPI_SIZEOF: Errata required (was: Another MPI_SIZEOF question)
by Jeff Squyres (jsquyres) 11 Jun '14

11 Jun '14

On Jun 11, 2014, at 4:07 PM, "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> wrote: > I open to suggestions. > > 1. One obvious possibility is to re-instate "extended Fortran support"-like language, a la MPI-2.2. This does not make it possible to have MPI_SIZEOF in mpif.h, however, so I don't think it really solves the problem. > > 2. Another possibility is to say that MPI_SIZEOF is only available in the mpi and mpi_f08 modules (e.g., add an exception in MPI-3.x 17.1.4 saying that MPI_SIZEOF support is excluded from mpif.h). Per Bill Gropp's email (http://lists.mpi-forum.org/mpiwg-fortran/2014/06/1572.php) we'll actually have to add exceptions / remove references to overloading for all mpif.h cases -- not just MPI_SIZEOF. I accidentally hit "send" before adding: 3. Bill Gropp's suggestion (http://lists.mpi-forum.org/mpiwg-fortran/2014/06/1592.php) of removing "Fortran 77" support entirely. I'm not a big fan of effectively removing support for older Fortran compilers in a point release of MPI (i.e., 3.1 -- 4.0 might be a better candidate for this). But I acknowledge Bill's warning (the "As an alternative..." paragraph is the above-cited email) about selectively editing the text to allow "Fortran 77" compilers. Indeed, the problem is more insidious than we initially thought -- because it's not just "Fortran 77" codes that are affected, but any source.f code, because it will likely invoke compiler defaults that will preclude using INTERFACE blocks and other modern Fortran constructs. Hence, mpif.h really is stuck in the past. It is possible that the only reasonable solution is to make mpif.h safe for source.f-like behavior, and then deprecate mpif.h in MPI-4.0. -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

MPI_SIZEOF: Errata required (was: Another MPI_SIZEOF question)
by Jeff Squyres (jsquyres) 11 Jun '14

11 Jun '14

On Jun 9, 2014, at 8:31 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > Yeah, I kinda came to that same conclusion over the weekend (that OMPI's MPI_SIZEOF support in mpif.h would have to depend on which Fortran compiler is used). Urrrgh... Actually, this doesn't work, either. If you have an mpif.h that contains an "INTERFACE MPI_Sizeof", the compiler will treat it differently depending on whether it is included from source.f or source.f90 (and probably other variants, too). Gaahhh! This means that it is not possible -- and has never been possible -- to have an MPI-3.0 compliant MPI_SIZEOF interface in mpif.h. An errata is therefore required. I open to suggestions. 1. One obvious possibility is to re-instate "extended Fortran support"-like language, a la MPI-2.2. This does not make it possible to have MPI_SIZEOF in mpif.h, however, so I don't think it really solves the problem. 2. Another possibility is to say that MPI_SIZEOF is only available in the mpi and mpi_f08 modules (e.g., add an exception in MPI-3.x 17.1.4 saying that MPI_SIZEOF support is excluded from mpif.h). Per Bill Gropp's email (http://lists.mpi-forum.org/mpiwg-fortran/2014/06/1572.php) we'll actually have to add exceptions / remove references to overloading for all mpif.h cases -- not just MPI_SIZEOF. Thoughts? -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [MPIWG Fortran] Another MPI_SIZEOF question
by Bill Long 10 Jun '14

10 Jun '14

On Jun 10, 2014, at 3:55 PM, William Gropp <wgropp(a)illinois.edu> wrote: > On SIZEOF, the language in the standard for the argument is > > a Fortran variable of numeric intrinsic type (choice) > > I read this as different from "a *scalar* Fortran variable of numeric intrinsic type (choice)", but I may be interpreting the language too broadly. My reading is probably intended, however, because the Advice to users says: My assumption is that arrays are acceptable arguments. The problem with treating the argument to MPI_SIZEOF the same was as a choice buffer (using directives like IGNORE_TKR) is that the routine does need to know the TYPE of the argument. > > > If you want an errata, I'd consider this: > I’d be generally in favor of avoiding mention of “Fortran 77”. The operational issues are only whether mpif.h is still supported, and if it is, whether it is compatible with fixed source form. As a practical matter, I don’t know of any vendor that supplies a “Fortran 77” compiler that does not also supply a more modern Fortran compiler - at least F95. In practice, the “F77” compiler, if it exists at all, is the same compiler as the modern one, except with different default options (for source form, for example). > > Page 616, line 32. The following is suspicious: "MPI provides named datatypes corresponding to standard Fortran 77 numeric types:". Is there a way to describe this that does not refer to Fortran 77? Just delete the “77”. The list of intrinsic numeric types is the same in F08 as it was in F77. Cheers, Bill > > There are a few other places where Fortran 77 is mentioned, but I think they're ok, if dated. But as long as mpif.h must contain, for example, any interface blocks, then MPI-3 cannot be used with Fortran 77 and it is incorrect and misleading to suggest otherwise. > > An alternative is to remove all of the functions that were not present in the "basic" Fortran support from the mpif.h module, at least as a requirement. This route, however, will require a very careful search through the document for other places where there may be requirements that make it impossible to implement against standard-practice Fortran 77 compilers (and given the MPI-3 standard's endorsement of the use of non-standard extensions to permit the newer interfaces to be compiled, lets not argue about whether only fully and strictly Fortran 77 should be considered). Given both the age and the complexity of the task, I believe a more robust solution is to explicitly drop support for Fortran 77. It may *also* be necessary to weaken the requirement for MPI_SIZEOF in order to permit any but the most recent Fortran compilers to be used. > > Bill > > William Gropp > Director, Parallel Computing Institute > Thomas M. Siebel Chair in Computer Science > University of Illinois Urbana-Champaign > > > > > > On Jun 10, 2014, at 4:41 PM, Jeff Squyres (jsquyres) wrote: > >> On Jun 10, 2014, at 10:10 AM, William Gropp <wgropp(a)illinois.edu> wrote: >> >>> Jeff, as I noted before, in MPI-2, MPI_SIZEOF was not required for the Fortran "basic" support, thus MPI-2 did not break the existing practice with Fortran 77 compilers and the mpif.h include file (see the beginning of section 10.2.5 in MPI-2). >> >> Sorry, you're right -- you even said this earlier in the thread. My mistake. >> >>> The issue is deciding that mpif.h is not a way to compile MPI programs with a Fortran compiler that is for Fortran before 2008 + TS29113 but simply a different interface to the one true and only Fortran interface - which isn't even yet standard (since it requires TS29113). >> >> Same question as I asked before: Is 2003 or 2008+TS29113 required for SIZEOF? I have no knowledge of when INTERFACE blocks were added to Fortran. >> >> I'm asking this because DIMENSION(..) is *useful* to implement MPI_SIZEOF succinctly/easily, but it is not *required*. >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> _______________________________________________ >> mpiwg-fortran mailing list >> mpiwg-fortran(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran Bill Long longb(a)cray.com Fortran Technical Suport & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101

1 0

Re: [MPIWG Fortran] Another MPI_SIZEOF question
by William Gropp 10 Jun '14

10 Jun '14

On SIZEOF, the language in the standard for the argument is a Fortran variable of numeric intrinsic type (choice) I read this as different from "a *scalar* Fortran variable of numeric intrinsic type (choice)", but I may be interpreting the language too broadly. My reading is probably intended, however, because the Advice to users says: If given an array argument, it returns the size of the base element, not the size of the whole array. Thus, the argument must be acceptable as an array (and note that the same language is present in MPI-2.0, and the Fortran 2008+TS29113 binding includes DIMENSION(..) Thus, I believe that MPI_SIZEOF has the same choice parameter requirements of the communication routines such as MPI_SEND. If not, then this part of the advice to users is bogus, and the parameter should clearly be labeled as scalar only. And while not technically impossible to implement without DIMENSION(..), it is, as I said before, agreed to be impractical. And it cannot be done in Fortran 77 (and is hard to do in anything less than F08+TS29113). So that fact remains that in MPI-2, the "basic" support was setup to permit the use of Fortran 77 compilers, under the near universal extension that (and I will use the shorthand here) different types of variables could be passed to the same argument position in a routine. With MPI-3.0, this is no longer possible; at least F90 is required, and a *practical* full implementation requires much more than F90. If you want an errata, I'd consider this: Strike the sentence "MPI can still be used with most Fortran 77 compilers, as noted below." on page 81 line 47. It is untrue; it will be hard to be perfectly compliant without the full F08+TS29113. Page 85, line 26ff, strike the sentence that starts "On Fortran 77 systems" Page 103, lines 7-14. Strike this entire advice to users - its from MPI-2.0, when there was MPI_Address and MPI_Get_address. Page 451, lines 29-30. Delete "Fortran 77 users can use (non- portably) bit vector IOR on systems that support it." Page 492, lines 45-46. Delete "Fortran 77 users can use (nonportably) bit vector IOR on systems that support it." Page 497, Example 13.1. Either delete the entire example or change it to Fortran 9x or above. Page 545, lines 16-17. Delete "In Fortran 77 environments that do not support KIND parameters, MPI_Offset arguments should be declared as an INTEGER of suitable size." Page 605, lines 8-9. Delete "To support Fortran 77 as well as Fortran 90 and later, it may be necessary to eliminate all comments from mpif.h. " Page 616, line 32. The following is suspicious: "MPI provides named datatypes corresponding to standard Fortran 77 numeric types:". Is there a way to describe this that does not refer to Fortran 77? There are a few other places where Fortran 77 is mentioned, but I think they're ok, if dated. But as long as mpif.h must contain, for example, any interface blocks, then MPI-3 cannot be used with Fortran 77 and it is incorrect and misleading to suggest otherwise. An alternative is to remove all of the functions that were not present in the "basic" Fortran support from the mpif.h module, at least as a requirement. This route, however, will require a very careful search through the document for other places where there may be requirements that make it impossible to implement against standard-practice Fortran 77 compilers (and given the MPI-3 standard's endorsement of the use of non-standard extensions to permit the newer interfaces to be compiled, lets not argue about whether only fully and strictly Fortran 77 should be considered). Given both the age and the complexity of the task, I believe a more robust solution is to explicitly drop support for Fortran 77. It may *also* be necessary to weaken the requirement for MPI_SIZEOF in order to permit any but the most recent Fortran compilers to be used. Bill William Gropp Director, Parallel Computing Institute Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign On Jun 10, 2014, at 4:41 PM, Jeff Squyres (jsquyres) wrote: > On Jun 10, 2014, at 10:10 AM, William Gropp <wgropp(a)illinois.edu> wrote: > >> Jeff, as I noted before, in MPI-2, MPI_SIZEOF was not required for the Fortran "basic" support, thus MPI-2 did not break the existing practice with Fortran 77 compilers and the mpif.h include file (see the beginning of section 10.2.5 in MPI-2). > > Sorry, you're right -- you even said this earlier in the thread. My mistake. > >> The issue is deciding that mpif.h is not a way to compile MPI programs with a Fortran compiler that is for Fortran before 2008 + TS29113 but simply a different interface to the one true and only Fortran interface - which isn't even yet standard (since it requires TS29113). > > Same question as I asked before: Is 2003 or 2008+TS29113 required for SIZEOF? I have no knowledge of when INTERFACE blocks were added to Fortran. > > I'm asking this because DIMENSION(..) is *useful* to implement MPI_SIZEOF succinctly/easily, but it is not *required*. > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran

1 0

Re: [MPIWG Fortran] Another MPI_SIZEOF question
by Bill Long 10 Jun '14

10 Jun '14

On Jun 10, 2014, at 9:41 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > > Same question as I asked before: Is 2003 or 2008+TS29113 required for SIZEOF? I have no knowledge of when INTERFACE blocks were added to Fortran. Interface blocks were added in F90. > > I'm asking this because DIMENSION(..) is *useful* to implement MPI_SIZEOF succinctly/easily, but it is not *required*. MPI_SIZEOF is most easily written with the new features, but it is possible (tedious) to write a version without. Cheers, Bill Bill Long longb(a)cray.com Fortran Technical Suport & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101

1 0

Re: [MPIWG Fortran] Another MPI_SIZEOF question
by Jeff Squyres (jsquyres) 10 Jun '14

10 Jun '14

On Jun 10, 2014, at 10:10 AM, William Gropp <wgropp(a)illinois.edu> wrote: > Jeff, as I noted before, in MPI-2, MPI_SIZEOF was not required for the Fortran "basic" support, thus MPI-2 did not break the existing practice with Fortran 77 compilers and the mpif.h include file (see the beginning of section 10.2.5 in MPI-2). Sorry, you're right -- you even said this earlier in the thread. My mistake. > The issue is deciding that mpif.h is not a way to compile MPI programs with a Fortran compiler that is for Fortran before 2008 + TS29113 but simply a different interface to the one true and only Fortran interface - which isn't even yet standard (since it requires TS29113). Same question as I asked before: Is 2003 or 2008+TS29113 required for SIZEOF? I have no knowledge of when INTERFACE blocks were added to Fortran. I'm asking this because DIMENSION(..) is *useful* to implement MPI_SIZEOF succinctly/easily, but it is not *required*. -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [MPIWG Fortran] Another MPI_SIZEOF question
by William Gropp 10 Jun '14

10 Jun '14

Rolf, The problem is that the standard also requires MPI_SIZEOF to be supported by every version of the Fortran interfaces, even mpif.h. This was *not* the case in MPI-2. The standard even acknowledges that MPI_SIZEOF requires overloading, and that overloading definition is required in mpif.h . Thus, mpif.h cannot be implemented in a way that supports a Fortran 77 compiler. Jeff, as I noted before, in MPI-2, MPI_SIZEOF was not required for the Fortran "basic" support, thus MPI-2 did not break the existing practice with Fortran 77 compilers and the mpif.h include file (see the beginning of section 10.2.5 in MPI-2). And yes, as has been noted for a long time, the MPI-2 definition of Fortran interfaces for the "Extended" Fortran support were impractical within standard Fortran. So MPI has been working around limitations in the Fortran since the very beginning. I think all of us are happy to see Fortran evolving to the point where it is possible to implement a library that can move data (this could be a single-core I/O library; it need not be MPI). That's not the issue. The issue is deciding that mpif.h is not a way to compile MPI programs with a Fortran compiler that is for Fortran before 2008 + TS29113 but simply a different interface to the one true and only Fortran interface - which isn't even yet standard (since it requires TS29113). Bill William Gropp Director, Parallel Computing Institute Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign On Jun 10, 2014, at 3:48 PM, Rolf Rabenseifner wrote: >> As far as I can tell from the >> requirement that MPI_SIZEOF be supported, mpif.h also requires >> Fortran 2008 + TS29113, meaning that many legacy MPI programs cannot >> be compiled with a standard conforming MPI implementation and a >> Fortran compiler that implements only, say, Fortran 2008 (but not >> the TS29113, which is *not* part of the standard) or Fortran 2003. > > Section 17.1.6 on page 609 "MPI for Different Fortran Standard Versions" > tries to define the rules for standard compliant MPI-3.0 with > a Fortran 77, 90, 95, 2003, and 2003/2008+TS29113 compiler, > i.e., MPI-3.0 can be implemented with the restrictions, > e.g., MPI_SUBARRAYS_SUPPORTED needs to be set to .FALSE.. > > Rolf > > > > ----- Original Message ----- >> From: "William Gropp" <wgropp(a)illinois.edu> >> To: "MPI-WG Fortran working group" <mpiwg-fortran(a)lists.mpi-forum.org> >> Sent: Tuesday, June 10, 2014 3:06:08 PM >> Subject: Re: [MPIWG Fortran] Another MPI_SIZEOF question >> >> >> This naming corresponds to MPI-3 but not to the use in MPI-1 nor to >> what some users may still want, which is what Jeff is talking about. >> >> >> >> And note: When the original MPI Fortran interface was defined, it was >> known not to be standard conformant - in fact, I raised that issue >> and raised a straw man alternative that was not accepted by the MPI >> Forum. The fact at the time was that it was widely recognized that >> Fortran's (meaning Fortran 77) strict rules with the absence of any >> escape combined with no real general data mechanism, needed by many >> different libraries, not just MPI, made the type checking rules >> impractical, and virtually no compiler of the time implemented this >> check (the only one I knew of was WATFOR, and you could turn it >> off). >> >> >> Despite this, many applications were written using Fortran. Those >> applications in practice, despite not conforming to the letter of >> the standard, were portable and contributed to the success of MPI. >> I don't find comments about "MPI never supported Fortran" to be >> useful, even if they are technically true. >> >> >> In my opinion, the use of "mpif.h" should have been to support >> existing programs in their existing compilation environments. That >> might be fixed-format early Fortran, either Fortran 77 or perhaps >> Fortran 90 or Fortran 95. The goal of MPI-3 should have been to >> ensure that new programs used the mpi or mpi_f08 modules and that >> existing programs could continue to be used. That is *not* the >> situation that we have now. As far as I can tell from the >> requirement that MPI_SIZEOF be supported, mpif.h also requires >> Fortran 2008 + TS29113, meaning that many legacy MPI programs cannot >> be compiled with a standard conforming MPI implementation and a >> Fortran compiler that implements only, say, Fortran 2008 (but not >> the TS29113, which is *not* part of the standard) or Fortran 2003. >> >> >> Bill >> >> >> >> >> >> >> William Gropp >> Director, Parallel Computing Institute Thomas M. Siebel Chair in >> Computer Science >> >> >> University of Illinois Urbana-Champaign >> >> >> >> >> >> >> >> On Jun 10, 2014, at 2:44 PM, Jeff Squyres (jsquyres) wrote: >> >> >> >> On Jun 10, 2014, at 8:35 AM, Jeff Hammond < jeff.science(a)gmail.com > >> wrote: >> >> >> >> What shorthand will you permit for what is meant when Bill and I >> refer >> >> >> to Fortran 77 support in MPI that distinguishes it from F90 and F08 >> >> >> module support? >> >> I usually say "the mpif.h interface", "the (Fortran) mpi module", and >> "the mpi_f08 module". Indeed, I have renamed the "ompi/mpi/f77" and >> "ompi/mpi/f90" directories from previous versions of OMPI to >> "ompi/mpi/fortran/mpifh" and "ompi/mpi/fortran/use-mpi". >> >> Meaning: I have seen the error of my ways and corrected myself. You >> can, too. :-) >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> _______________________________________________ >> mpiwg-fortran mailing list >> mpiwg-fortran(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran >> >> >> _______________________________________________ >> mpiwg-fortran mailing list >> mpiwg-fortran(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran > > -- > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-fortran

1 0