[MPI3 Fortran] Teleconference Wednesday, Sept. 17: Summary

Jeff Squyres jsquyres at cisco.com
Wed Sep 17 11:07:42 CDT 2008


On Sep 17, 2008, at 11:17 AM, Craig Rasmussen wrote:

>> 2. What KIND parameter to use for integer arguments.
>
> This topic took up most of the discussion.
>
> There are two sides to this:
> 1. From a users perspective it would be very convenient to use  
> default integers, especially for constants.
> 2. However from an implementation perspective, this becomes tricky  
> because it would require many more interfaces to be defined to  
> handle all of the different potential kind values.
>
> I think the resolution of this needs wider participation.  I was  
> persuaded that we should explicitly specify a kind value, C_INT, in  
> most cases.  This will work in most cases for default integer actual  
> arguments unless the user specifies compiler options to change the  
> default size.  When the user does this he/she should expect some  
> things to break and take the steps to correct the problem.
>
> Some arguments, for example, the count argument in MPI_Send should  
> require a kind large enough to store a pointer.

I'm not sure what this comment means ^^.

There is some debate in the MPI Forum to allow counts larger than a C  
int in MPI-3.0, but that discussion is very preliminary (there's some  
resistance to it because you can get arbitrarily large counts by  
composing MPI datatypes).

>> 5. Optional arguments?
>
> Yes, the error status parameter should be optional.  If other  
> parameters were made optional (e.g. MPI_COMM) the user may be  
> required to supply the argument name in the call, depending on what  
> arguments were left out.
>
> The decision was that ONLY the error status be optional.  However,  
> is it a bad think to allow the user to drop some arguments and  
> specify others by name?


It might be good to take a cue from the C++ bindings here.  We made a  
small number of arguments be optional -- such as those that have  
"IGNORE"-like constants (MPI_STATUS_IGNORE, MPI_ARGV_IGNORE, etc.).   
In fact, those arguments became somewhat of a PITA for the C++  
bindings -- it might very well be better to have multiple bindings for  
functions that allow IGNORE (or IN_PLACE) constants.  Perhaps  
something like this:

MPI_RECV(buf, count, type, src, tag, comm, status)
MPI_RECV(buf, count, type, src, tag, comm)
  --> ie., leave off the status argument altogether instead of passing  
MPI_STATUS_IGNORE

MPI_GATHER(sendbuf, sendcount, sendtype, recvbuf, recvcount, recvtype,  
root, comm)
MPI_GATHER(sendcount, sendtype, recvbuf, recvcount, recvtype, root,  
comm)
  --> i.e., leave off the sendbuf argument instead of passing  
MPI_IN_PLACE

Both of these examples should be pretty easy to match via overloading  
the functions.  The first one could probably be an optional argument  
since "status" is the last argument.  But I don't think the spec  
should mandate which way it is implemented -- I think the spec should  
only indicate which bindings should be available to user applications.

There's a few other obvious MPI API functions like this.

-- 
Jeff Squyres
Cisco Systems




More information about the mpiwg-fortran mailing list