Cisco Blogs

MPI-3 Fortran Community Feedback Needed!

October 23, 2009 - 15 Comments

As many of you know, I’m an active member of the MPI Forum.  We have recently completed MPI-2.2 and have shifted our sights to focus on MPI-3. 

For some inexplicable reason, I’ve become heavily involved in the MPI-3 Fortran working group.  There are some well-known problems with the MPI-2 Fortran 90 interfaces; the short version of the MPI-3 Fortran WG’s mission is to “fix those problems.” 

A great summary of what the Fortran WG is planning for MPI-3 is available on the Forum wiki page; we’d really appreciate feedback from the Fortran MPI developer community on these ideas. 

There is definitely one significant issue that we need feedback from the community before making a decision.  Craig Rasmussen from Los Alamos National Laboratory asked me to post the following “request for information” to the greater Fortran MPI developer community.  Please send feedback either via comments on this blog entry, email to me directly, or to the MPI-3 Fortran working group mailing list.


The Fortran working group has made substantial progress in completing its goal of creating new Fortran bindings for MPI-3 that fix major problems in calling MPI from Fortran.  However, there is still an issue that needs to be resolved — we need community feedback before making a decision.

Currently, MPI-2 integer arguments like source, destination, and tag are default Fortran integers.  Perhaps it is time to revisit the size of integer arguments in light of two issues:

  1. Interoperability with the underlying MPI implementation in C.  While integers are likely to be the same size between Fortran and C, they are not required to be, and therefore it might be wise to provide a finer level of control by specifying the precise size (Fortran kind parameter) in MPI-3 Fortran interfaces.
  2. Some MPI Fortran users change the size of default integers by using nonstandard compiler options that promote all integer declarations to long integers.  Obviously this can cause problems when the MPI library has not been compiled with the same option.

Because this decision could potentially have a large impact on the MPI Fortran community, we would like to get as much feedback from the community as possible.  We have outlined three options below:

1. Retain the status quo and use default integers, e.g.,

integer :: src, dest, tag

  • Pros: No integer kind changes need be made to existing codes to migrate to using the MPI-3 interfaces.  Minimal implementation problems for MPI vendors.
  • Cons: The issue with using nonstandard compiler options that promote integers to long integers remains a problem.

2. Specify a named kind such as “MPI_INT_KIND”, e.g.,

integer(MPI_INT_KIND) :: src, dest, tag

  • Pros: This provides the most specificity and users will have a known way to code that will work under all circumstances, including the use of compiler flags that promote integers.  Vendors can easily provide interfaces that interoperate with C.
  • Cons: MPI_INT_KIND will likely specify default integers and so existing codes will work in most circumstances.  However, to conform to the MPI-3 standard, users would have to modify their code to specifically declare the kind parameter for MPI integers as shown above.

3. Rather than a specific interface, MPI-3 could provide a generic interface so that calls to MPI will take any integer kind.

  • Pros: This option works when integers are promoted and doesn’t break existing codes.
  • Cons: In practice a truly generic interface for all possibly combinations of integer kinds couldn’t be provided.  Likely the best vendors could do would be to provide two generic interfaces, one that uses default integers and one that uses long integers (users can mix integer sizes in one MPI call).

Note: While option 1 doesn’t directly address the integer promotion problem, there is no reason the vendor couldn’t provide option 3 as part of a “quality of implementation” or deal with integer promotion in some other way.  Since integer promotion is not part of the Fortran standard (there are now better and standard ways in Fortran to accomplish the same thing), should the MPI-3 Fortran standard try to work around something that is non-standard Fortran?

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


  1. My solution has been not to use MPI_INT_KIND nor any of the other default MPI types.Instead, I place MPI_INIT into a wrapper that accepts as dummy arguments the results of KIND(a_real) and KIND(an_int).The wrapper then calls MPI_TYPE_CREATE_F90_INTEGER and MPI_TYPE_CREATE_F90_REAL, which commits new types DEF_INT_TYPE and DEF_REAL_TYPE, which I then use everywhere in the program. This is most similar to option 2; however, I dislike the idea of having to use a type-name with MPI"" in it. When I'm not using MPI (i.e., with preproccesor directives), the values of DEF_INT_TYPE and DEF_REAL_TYPE are set as the result of SELECTED_INT_KIND(9) and KIND(1.0D0), for example."

  2. Commenting on Doublas Guptill's post. I don't really think the question at hand really depends on whether you are using a 32-bit or 64-bit system. Could you be more specific.

  3. I woke up early one morning this week and while tossing and turning came up with about the same idea as Terry Frankcombe posted above. Stephen makes a good argument for preference 1. However preference 1 doesn't really help with those who change the type system with a compiler option (yuk).However, if MPI provides MPI_INT_KIND as a convenience constant that just supplies the kind of a default integer as compiled in the MPI library, then I think everyone is happy.1. Normal users declare MPI tag, src, dst, ... as regular integers requiring no change in coding.2. Those who want to promote integers to something else will have to declare MPI tag, src, dst, ... as integer(MPI_INT_KIND) and then their codes will work fine as well.Only those promoting integers are affected and the MPI-3 standard would provide a standard way for them to write standard compliant programs.

  4. I like #2.We are in the midst of a change from 32-bit systems to 64-bit systems. Experience shows that some will continue to run 32-bit systems for some time into the future, while others will go to 64-bit.

  5. Thinking some more, I think I'm arguing for (1) plus bits of (2). Defining MPI_INT_KIND allows one to code in such a way as to be safe from integer badness on global"" integer promotion, if that's the kind of trick you're going to pull with you app. It shouldn't be *required* if kind(1)==MPI_INT_KIND."

  6. Re-reading my own post above, I realize that I'm not so much arguing for (1) as against (2). However, I do have a residual preference for (1) over (3), as IMHO (3) is a compromise that will entail a good deal of work for little, if any, impact. MPI is already creaking under the weight of compromise.Also, in my second last paragraph, I should have written if MPI3 compliant implementations do not support MPI2 compliant _applications_""."

  7. Option 2 seems most preferable. It could be combined with having multiple versions of MPI3 module files and libraries which support different KINDs for MPI_INT_KIND, so even the case of the user wishing to continue using default integers could be covered provided such usage is consistent.

  8. Stephen -- you're correct about the use of MPI_DOUBLE_PRECISION on the ring example on the MPI Forum Fortran wiki page. I fixed it. Thanks!

  9. I strongly prefer option (1), on the grounds that we're talking about an API for Fortran, and there's nothing about Fortran default integers that make them unfit for the purpose of representing a rank, size or tag.As long as Fortran default integers remain at least 32 bits, there should be no problem in terms of size for src, dest and tag. We'll still be programming for 1 million core machines in MPI, but I doubt we'll be progamming machines with a billion cores with one MPI task per core. Although I've encountered cases where more tags would be convenient, the limitation wasn't the size of a default integer, but the MPI implementation's maximum tag value.I don't buy the argument that interoperability with C here should be an issue, at least from the application programmer's point of view. So what if a particular Fortran has a larger default integer than C? Let any implementation that uses C internally do any required casts.Nor do I buy the argument about the possibility of a Fortran compiler promoting default integers from 32-bit to 64-bit. Such applications do exist, for sure. But merely adding MPI_INT_KIND won't fix the problem, unless ALL applications are required to use it, instead of default integers, all the time. If the owners of such applications won't bite the bullet and fix their integer size problem using standard fortran features, what makes you think they'll bite a bullet of a different flavour?The legacy code-base is so important that any MPI implementation would have to support default integers as well as MPI_INT_KIND during the transition; so it would be making the implementors' job harder, not easier.Likewise, if MPI3 compliant implementations do not support MPI2 compliant implementations out-of-the-box, we'd be in danger of another round of this sort of abomination:#ifdef MPI3 INTEGER(MPI_INT_KIND) :: ...#else INTEGER :: ...#endifBy the way, the ring example on the Fortran Bindings Working Group Wiki Pages is broken, is it not? It should be using MPI_DOUBLE_PRECISION instead of MPI_DOUBLE (which is a predefined constant matching a C double, and has no place in a Fortran program).

  10. Regarding the statement:Some MPI Fortran users change the size of default integers by using nonstandard compiler options that promote all integer declarations to long integers. Obviously this can cause problems when the MPI library has not been compiled with the same option. It's certainly the case that the users can (and likely should) control whether src, dest, tag variables are promoted or not by explicitly specifying their size, no? If that's the case, then it seems like (1) is a valid option, provided we know a priori what size MPI will expect to see. Else, (2) is ok --- but how does this interact with f77?

  11. These are great comments -- keep them coming!

  12. Let's not forget that fudging the default types also breaks interactions with any other library that's linked.I have a bit of a problem with declaring that if MPI_INT_KIND is defined, then any code that doesn't explicitly declare the integers as that kind is not compliant. I can certainly see why one might make that declaration. But if every implementation happens to set MPI_INT_KIND to the default kind for all the compilers that work on the platforms they're targeting? The kind spec becomes something of a no-op, yet all codes that don't do it are non-conforming? That seems a bit silly. (I don't expect all implementations to match defaults for all compilers, but I do expect that to be the norm rather than the exception.)It would be nice to see MPI_INT_KIND implemented. It would also be nice to see it as advisory, and that if the default kind is not MPI_INT_KIND then the code is broken. I guess that means MPI_INT_KIND could not be part of a sourcecode compliance requirement. I could see how this could be unacceptable to the Forum.

  13. Hi,I would prefer option 2. This looks like a clean"" solution. BTW, we successfully use the integer promotion in our quantum chemistry program package (,stefan"

  14. Of course 2 is the correct"" answer from a standarization and modern library usage point-of-view. But this is Fortran, so practicality matters too :-)Why not a combination of 2&3, where a generic interface is encouraged to work for as many kinds as the vendor is willing to put up with, but is at least, guaranteed to work if integers happen to be of kind MPI_INT_KIND.Whether one also guarantees that it works for C_INT and C_LONG kinds, or any other kind, including the mythical ""default"" kind ... that would be up to the vendor."

  15. My vote is for 2""."