[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