On 2/20/13 6:20 PM, Malcolm Cohen wrote:

Bill Long wrote:

...

In terms of the interface, I think I would prefer just making MPI_Init effectively generic, with the allow calls:

integer :: ierror character(:),allocatable :: args(:)

call MPI_Init( ) ! Existing form call MPI_Init (ierror) ! Existing form including optional status

call MPI_Init (args) ! New form

call MPI_Init (args,ierror) ! New form with the optional status argument.

Both arguments are INTENT(OUT). The array arg is allocated inside MPI_Init with a length parameter equal to the maximum length of the arguments or the command. The bounds are 0:nargs. On return arg(0) would be the command text, and arg(i:ubound(arg),1)) would be the arguments. The number of arguments is size(arg)-1. [Redundantly, the number of arguments could be returned as another argument.]

This is reasonable but does not allow the program to detect trailing blanks on an argument. It might be argued that this is not important for the MPI community, but it is a limitation.

True, this simplified interface does result in shorter arguments having trailing blanks. At a minimum, that would need documentation (though it would not be surprising to Fortran programmers).

I would tweak the above suggestion to 2 forms: MPI_INIT( [ ierror ] ) MPI_INIT( args [ , ierror ] ) i.e. allow ierror to be an absent optional dummy argument.

Same effect, but avoids discussion of "generic". This would be a better form for the description.

If we want to be able to handle trailing blanks, then replacing MPI_GET_COMMAND_ARGUMENT with

SUBROUTINE mpi_getarg(n,arg,ierror) INTEGER,INTENT(IN) :: n CHARACTER(:),ALLOCATABLE,INTENT(OUT) :: arg INTEGER,INTENT(OUT),OPTIONAL :: ierror

would be better than just copying the F2003 interface (which took a *very* conservative view - justified at the time, but that was approx a decade ago). Avoids all the arguments about length, handles trailing blanks properly, avoids the user mucking around with allocating stuff himself, avoids the common situation where the programmer decides that (e.g.) 80 characters is long enough and doesn't bother with handling the length properly at all - until several years later when someone else complains that it doesn't work on his system because his filenames are longer.

If that route is taken, I would definitely pick something short like MPI_GETARG for the name: we're not copying the standard's interface so no reason whatsoever to copy the name.

For that matter if we have a separate "nargs" enquiry rather than Bill's suggestion, changing MPI_COMMAND_ARGUMENT_COUNT to MPI_IARGC or similar would be reasonable; the standard names for these are really rather excessively long.

I like the idea of MPI_GETARG and MPI_IARGC, as described above. Users are already familiar with getarg and iargc so these names would be intuitive. And they would reinforce the idea that the Fortran and C users are getting the same information. Furthermore, these could be called from somewhere other than where MPI_INIT is called, so are more flexible. In fact, the C users might like similarly named routines if they cannot rely on getarg and iargc working correctly in an MPI environment. Cheers, Bill

Cheers,

-- Bill Long [email protected] Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101