[MPI3 Fortran] MPI_INIT issues
Bill Long
longb at cray.com
Thu Feb 21 07:54:46 CST 2013
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 longb at cray.com
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
More information about the mpiwg-fortran
mailing list