February 2013 - mpiwg-fortran - mailman3.cels.anl.gov

Re: [MPI3 Fortran] Fwd: [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by N.M. Maclaren 26 Feb '13

26 Feb '13

On Feb 26 2013, Jeff Squyres (jsquyres) wrote: >> From: Tobias Burnus <burnus(a)net-b.de> >> >> Digest version: The Fortran 2008 interface should use >> "LOGICAL(kind=C_BOOL)" instead of "LOGICAL". >> >> Hence, I strongly suggest to change in all BIND(C) procedures LOGICAL >> to LOGICAL(C_Bool). ... This is a catastrophic idea. Let's ignore the minor detail that _Bool was attempt to mimic C++'s bool, but is not necessarily compatible with it. Yes, really. Many people on WG14 opposed it (including the UK, formally, if I recall) and a lot of people still disrecommend it on those grounds. This would force ALL users who need those calls to start using C types, and the need for that may well be removed in the next standard. Far worse, a Fortran compiler need not support C_BOOL in any case, so MPI would cease being fully portable in Fortran. But the REALLY bad problem is that this is a code-breaking change, unless the authors of the modules, include file and header make heroic efforts to avoid it. From page 598 (17.1 Fortran Support): "In a single application, it must be possible to link together routines which USE mpi_f08, USE mpi, and INCLUDE 'mpif.h'." To actually get it right would mean that the MPI_F08 module invokes a different copy of all of the test functions to the ones invoked by the MPI one and the included file 'mpif.h'. So why put the ability to use the same function for the MPI_F08 module and the header 'mpi.h' above that of doing so for the MPI_F08 module and the MPI module and the included file 'mpif.h'? That's unnatural. I don't understand the objections to (theoretical) interface functions; a particular MPI implementation can always optimise them out. While I can understand the desire of people to put those BIND(C) specifiers on, I think that it was a mistake. It should be dropped for these functions. On Feb 26 2013, Bill Long wrote: > >In particular, the C function is not using _Bool. It would seem to be >more consistent for the Fortran interface to specify the argument as > >INTEGER :: FLAG > >or, better > >INTEGER(c_int) :: FLAG. Yes, but my points apply as much to C_INT as they do for C_BOOL, except for the specific reason to avoid C_BOOL. Regards, Nick Maclaren.

1 0

Re: [MPI3 Fortran] Fwd: [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by Bill Long 26 Feb '13

26 Feb '13

On 2/26/13 8:46 AM, Jeff Squyres (jsquyres) wrote: > MPI Fortran group -- > > The report below came in from Tobias Burnus / Pathscale because of an issue that arose in the Open MPI implementation of the MPI F08 bindings. > > What should we do about this? There are always hazards and defects associated with the use of default types in the Fortran interfaces. Especially when interoperating with C. Many of us had hoped this would finally have been abolished with MPI 3, but, alas, the ancient forms were preserved. However, in this particular example, in the C version of the same function the formal parameter corresponding to the Fortran argument LOGICAL :: FLAG is int *flag In particular, the C function is not using _Bool. It would seem to be more consistent for the Fortran interface to specify the argument as INTEGER :: FLAG or, better INTEGER(c_int) :: FLAG. Cheers, Bill > > > Begin forwarded message: > >> From: Tobias Burnus <burnus(a)net-b.de> >> Subject: [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind >> Date: February 26, 2013 7:19:07 AM EST >> To: <mpi-comments(a)lists.mpi-forum.org> >> Reply-To: Comments on the MPI Standard <mpi-comments(a)lists.mpi-forum.org> >> >> Dear all, >> >> Digest version: The Fortran 2008 interface should use "LOGICAL(kind=C_BOOL)" instead of "LOGICAL". >> >> >> MPI 3 [1] adds a new Fortran 2008 interface (or rather one using Fortran 2008 [2] plus TS 29113 [3]), which uses C binding ("bind(C)"). For instance the following (from "6.7.2 Communicators"): >> >> ABSTRACT INTERFACE >> SUBROUTINE MPI_Comm_copy_attr_function(oldcomm, comm_keyval, extra_state, >> attribute_val_in, attribute_val_out, flag, ierror) BIND(C) >> TYPE(MPI_Comm) :: oldcomm >> INTEGER :: comm_keyval, ierror >> INTEGER(KIND=MPI_ADDRESS_KIND) :: extra_state, attribute_val_in, >> attribute_val_out >> LOGICAL :: flag >> >> >> The code assumes that the default-kind INTEGER and LOGICAL are interoperable. It is very likely that default-kind integers are interoperable, given that C supports many integer types (signed char, short, int, long, long long) and that Fortran's default-kind integer typically matches "int". >> >> >> However, for LOGICAL this is not necessarily the case. Fortran's default-kind LOGICAL is always [5] as wide as the default-kind INTEGER ("LOGICAL(kind=4)"). However, C99's [4] _Bool is on nearly all systems (one exception is 32bit Darwin) only one byte wide (sizeof(_Bool) == 1) [6]. The Fortran standard only defines interoperability with this logical kind: >> >> >> Fortran 2008, "15.2.2 Named constants and derived types in the module": "The value of C_BOOL shall be a valid value for a logical kind parameter on the processor or shall be -1." >> >> Fortran 2008, "Table 15.2: Interoperability between Fortran and C types": >> "Fortran type / Named constant from the ISO C BINDING module (kind type parameter if value is positive) / C type" >> ... >> "LOGICAL / C_BOOL / _Bool" >> >> >> Hence, a conforming compiler might only accept a single interoperable LOGICAL kind, namely: C_BOOL. That's actually the case for the PathScale/pathf95 compiler ï¿½ and also GCC/gfortran (version >= 4.8) with -std=f2003/f2008/f2008ts only accepts LOGICAL(C_BOOL) but not LOGICAL [7]. >> >> >> Note an additional potential issue: C99's _Bool only allows two values, 0 and 1; see C99's "6.3.1.2 Boolean type": "When any scalar value is converted to _Bool, the result is 0 if the value compares equal to 0; otherwise, the result is 1." >> >> At least the GCC makes use of this restriction and sets TYPE_PRECISION to 1 for C99/C++'s _Bool/bool and Fortran's LOGICAL (for all KIND= values). As the hardware typically supports instructions of the form "jump if zero" or "jump if not zero", also other values work in "if (bool_var)". However, for negation (C/C++: "!", Fortran: ".not."), GCC only flips one bit. Hence, for C99's _Bool, C++'s bool and Fortran's LOGICAL (any kind), negating "-2" leads to "-1". >> >> Example: If you have in one file: >> "signed char bool_var = -2; sub(bool_var)" >> and in the other file either: >> void sub(_Bool bool_var) >> or >> subroutine sub(bool_var) bind(C) >> logical(kind=C_Bool), value :: bool_var >> both "bool_var" and "!bool_var"/".not.bool_var" evaluate to true/.true. >> >> In that sense, Fortran's "LOGICAL :: v" is not interoperable with C's "int v" unless the value is restricted to 0 and 1. >> >> Note regarding C99: If you assign or cast to _Bool, the compiler ensures that only the value 0 and 1 is used. Additionally, many operations in C99 return an "int", for instance "&&" or "||" do (see C99, "6.5.13 Logical AND operator" and 6.5.14). Thus, in pure C code one does not easily run into this issue. Nor in pure Fortran code as one there typically doesn't mix LOGICAL with INTEGER. But when mixing C and Fortran (or mixes code compiled iwth different compilers [8]), this can lead to wrong code. >> >> >> Hence, I strongly suggest to change in all BIND(C) procedures LOGICAL to LOGICAL(C_Bool). For the three reasons above: (a) the standard only defines interop with kind=C_Bool; (b) pathf95 [and gfortran with -std=f2008ts] only support C_Bool kind logicals with Bind(C); (c) at least with GCC, using default-kind LOGICAL might lead to wrong results if the value is not 0 or 1. >> >> >> Tobias >> >> PS: The issue came up with Open MPI's bug report https://svn.open-mpi.org/trac/ompi/ticket/3523 >> >> >> [1] MPI 3: http://www.mpi-forum.org/docs/mpi-3.0/mpi30-report.pdf; erratum http://www.mpi-forum.org/docs/errata-30.pdf >> [2] Fortran 2008 (FDIS): ftp://ftp.nag.co.uk/sc22wg5/N1801-N1850/N1830.pdf ; corrigenda 1 & 2: ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1903.pdf , ftp://ftp.nag.co.uk/sc22wg5/N1951-N2000/N1958.pdf >> [3] TS 29113 (FDIS): ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1942.pdf >> [4] C99+TC1,TC2,TC3: http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf >> [5] That's required in Fortran 2008's "16.5.3.2 Storage sequence": "a nonpointer scalar object that is default integer, default real, or default logical occupies a single numeric storage unit," >> [6] That _Bool has is one byte wide is implied by C99's "The rank of _Bool shall be less than the rank of all other standard integer types." (6.3.1.1), but in my reading it does not formally demand it. With GCC, one can force this width for 32bit Darwin via -mone-byte-bool. >> [7] Currently, GCC still accepts LOGICAL / LOGICAL(4) with default options (-std=gnu); however, that might change. See discussion at http://gcc.gnu.org/ml/fortran/2013-01/msg00090.html and http://gcc.gnu.org/PR55758 >> [8] In particular, Intel's Fortran compiler uses "-1" for .true., independent of logical kind and bind(C); for the reasons outlined above, it thus interacts badly with GCC/gfortran. >> _______________________________________________ >> mpi-comments mailing list >> mpi-comments(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments > > -- Bill Long longb(a)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

1 0

[MPI3 Fortran] Fwd: [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind
by Jeff Squyres (jsquyres) 26 Feb '13

26 Feb '13

MPI Fortran group -- The report below came in from Tobias Burnus / Pathscale because of an issue that arose in the Open MPI implementation of the MPI F08 bindings. What should we do about this? Begin forwarded message: > From: Tobias Burnus <burnus(a)net-b.de> > Subject: [Mpi-comments] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind > Date: February 26, 2013 7:19:07 AM EST > To: <mpi-comments(a)lists.mpi-forum.org> > Reply-To: Comments on the MPI Standard <mpi-comments(a)lists.mpi-forum.org> > > Dear all, > > Digest version: The Fortran 2008 interface should use "LOGICAL(kind=C_BOOL)" instead of "LOGICAL". > > > MPI 3 [1] adds a new Fortran 2008 interface (or rather one using Fortran 2008 [2] plus TS 29113 [3]), which uses C binding ("bind(C)"). For instance the following (from "6.7.2 Communicators"): > > ABSTRACT INTERFACE > SUBROUTINE MPI_Comm_copy_attr_function(oldcomm, comm_keyval, extra_state, > attribute_val_in, attribute_val_out, flag, ierror) BIND(C) > TYPE(MPI_Comm) :: oldcomm > INTEGER :: comm_keyval, ierror > INTEGER(KIND=MPI_ADDRESS_KIND) :: extra_state, attribute_val_in, > attribute_val_out > LOGICAL :: flag > > > The code assumes that the default-kind INTEGER and LOGICAL are interoperable. It is very likely that default-kind integers are interoperable, given that C supports many integer types (signed char, short, int, long, long long) and that Fortran's default-kind integer typically matches "int". > > > However, for LOGICAL this is not necessarily the case. Fortran's default-kind LOGICAL is always [5] as wide as the default-kind INTEGER ("LOGICAL(kind=4)"). However, C99's [4] _Bool is on nearly all systems (one exception is 32bit Darwin) only one byte wide (sizeof(_Bool) == 1) [6]. The Fortran standard only defines interoperability with this logical kind: > > > Fortran 2008, "15.2.2 Named constants and derived types in the module": "The value of C_BOOL shall be a valid value for a logical kind parameter on the processor or shall be -1." > > Fortran 2008, "Table 15.2: Interoperability between Fortran and C types": > "Fortran type / Named constant from the ISO C BINDING module (kind type parameter if value is positive) / C type" > ... > "LOGICAL / C_BOOL / _Bool" > > > Hence, a conforming compiler might only accept a single interoperable LOGICAL kind, namely: C_BOOL. That's actually the case for the PathScale/pathf95 compiler ï¿½ and also GCC/gfortran (version >= 4.8) with -std=f2003/f2008/f2008ts only accepts LOGICAL(C_BOOL) but not LOGICAL [7]. > > > Note an additional potential issue: C99's _Bool only allows two values, 0 and 1; see C99's "6.3.1.2 Boolean type": "When any scalar value is converted to _Bool, the result is 0 if the value compares equal to 0; otherwise, the result is 1." > > At least the GCC makes use of this restriction and sets TYPE_PRECISION to 1 for C99/C++'s _Bool/bool and Fortran's LOGICAL (for all KIND= values). As the hardware typically supports instructions of the form "jump if zero" or "jump if not zero", also other values work in "if (bool_var)". However, for negation (C/C++: "!", Fortran: ".not."), GCC only flips one bit. Hence, for C99's _Bool, C++'s bool and Fortran's LOGICAL (any kind), negating "-2" leads to "-1". > > Example: If you have in one file: > "signed char bool_var = -2; sub(bool_var)" > and in the other file either: > void sub(_Bool bool_var) > or > subroutine sub(bool_var) bind(C) > logical(kind=C_Bool), value :: bool_var > both "bool_var" and "!bool_var"/".not.bool_var" evaluate to true/.true. > > In that sense, Fortran's "LOGICAL :: v" is not interoperable with C's "int v" unless the value is restricted to 0 and 1. > > Note regarding C99: If you assign or cast to _Bool, the compiler ensures that only the value 0 and 1 is used. Additionally, many operations in C99 return an "int", for instance "&&" or "||" do (see C99, "6.5.13 Logical AND operator" and 6.5.14). Thus, in pure C code one does not easily run into this issue. Nor in pure Fortran code as one there typically doesn't mix LOGICAL with INTEGER. But when mixing C and Fortran (or mixes code compiled iwth different compilers [8]), this can lead to wrong code. > > > Hence, I strongly suggest to change in all BIND(C) procedures LOGICAL to LOGICAL(C_Bool). For the three reasons above: (a) the standard only defines interop with kind=C_Bool; (b) pathf95 [and gfortran with -std=f2008ts] only support C_Bool kind logicals with Bind(C); (c) at least with GCC, using default-kind LOGICAL might lead to wrong results if the value is not 0 or 1. > > > Tobias > > PS: The issue came up with Open MPI's bug report https://svn.open-mpi.org/trac/ompi/ticket/3523 > > > [1] MPI 3: http://www.mpi-forum.org/docs/mpi-3.0/mpi30-report.pdf; erratum http://www.mpi-forum.org/docs/errata-30.pdf > [2] Fortran 2008 (FDIS): ftp://ftp.nag.co.uk/sc22wg5/N1801-N1850/N1830.pdf ; corrigenda 1 & 2: ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1903.pdf , ftp://ftp.nag.co.uk/sc22wg5/N1951-N2000/N1958.pdf > [3] TS 29113 (FDIS): ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1942.pdf > [4] C99+TC1,TC2,TC3: http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf > [5] That's required in Fortran 2008's "16.5.3.2 Storage sequence": "a nonpointer scalar object that is default integer, default real, or default logical occupies a single numeric storage unit," > [6] That _Bool has is one byte wide is implied by C99's "The rank of _Bool shall be less than the rank of all other standard integer types." (6.3.1.1), but in my reading it does not formally demand it. With GCC, one can force this width for 32bit Darwin via -mone-byte-bool. > [7] Currently, GCC still accepts LOGICAL / LOGICAL(4) with default options (-std=gnu); however, that might change. See discussion at http://gcc.gnu.org/ml/fortran/2013-01/msg00090.html and http://gcc.gnu.org/PR55758 > [8] In particular, Intel's Fortran compiler uses "-1" for .true., independent of logical kind and bind(C); for the reasons outlined above, it thus interacts badly with GCC/gfortran. > _______________________________________________ > mpi-comments mailing list > mpi-comments(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [MPI3 Fortran] MPI_INIT issues
by Bill Long 21 Feb '13

21 Feb '13

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(a)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

1 0

Re: [MPI3 Fortran] MPI_INIT issues
by N.M. Maclaren 21 Feb '13

21 Feb '13

On Feb 21 2013, Rolf Rabenseifner wrote: > >Then, I would expect, this ticket is simple and a self-explaining >good and ***necessary*** extension for MPI-next. > >Exactly this rational is the basis that all C programming Forum >members will see the necessity. Eh? I assuredly count as one of them, and I don't see the necessity. Over a decade ago, I decided that it was a mistake for MPI to pass arguments to MPI_Init in C, and it was done only to make life easier for some rather PVM-like implementations. I would have preferred MPI to say "Tough. Implementations must pass MPI's options in some way that does not affect the user's argument list." The MPI 2.0 C++ interface people seemed to think the same. Regards, Nick Maclaren.

1 0

Re: [MPI3 Fortran] MPI_INIT issues
by Rolf Rabenseifner 21 Feb '13

21 Feb '13

Dear Jeff, yes, I'll be not at the meeting, and if Craig is also not coming, any straw votes are guaranteed to be 100% :-) We should discuss this directly on the ticket https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/351 Please add the Fortran functionality on the ticket as background info. And also the wording for the MPI routines. And perhaps a rationale to explain the relation between the Fortran and the MPI routines. Then, I would expect, this ticket is simple and a self-explaining good and ***necessary*** extension for MPI-next. Exactly this rational is the basis that all C programming Forum members will see the necessity. Best regards Rolf ----- Original Message ----- > From: "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> > To: "MPI-3 Fortran working group" <mpi3-fortran(a)lists.mpi-forum.org> > Sent: Wednesday, February 20, 2013 6:32:13 PM > Subject: Re: [MPI3 Fortran] MPI_INIT issues > This is a WG meeting, not a plenary. > > Rolf -- are you not going to be there? Because if I'm going to be the > only WG member at the meeting, it'll be a pretty darn quick meeting. > :-) > > > > On Feb 20, 2013, at 12:21 PM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> > wrote: > > > As fas as I see, > > the MPI routines guarantee to work on all MPI processes, > > whereas the Fortran routines are guaranteed only in a > > sequential program. > > > > If you are doing slides, then please show the Fortran routine > > functionality (e.g., the INOUT quality of a length argument) > > and compare it to the proposed MPI routine. > > They should be identical (i.e. least surprise). > > This would help the audience to see that the interface is okay. > > > > Best regards > > Rolf > > > > ----- Original Message ----- > >> From: "Bill Long" <longb(a)cray.com> > >> To: mpi3-fortran(a)lists.mpi-forum.org > >> Sent: Wednesday, February 20, 2013 6:17:46 PM > >> Subject: Re: [MPI3 Fortran] MPI_INIT issues > >> I found the proposed solution confusing. If the Fortran user wants > >> to > >> call COMMAND_ARGUMENT_COUNT or GET_COMMAND_ARGUMENT, why not just > >> do > >> that directly? I don't see a point to creating new functions > >> starting > >> with MPI_ . > >> > >> Cheers, > >> Bill > >> > >> > >> > >> On 2/20/13 11:02 AM, Jeff Squyres (jsquyres) wrote: > >>> I see that Martin put us on the agenda to discuss the MPI_INIT > >>> Fortran issues (see > >>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/351) 9-10am > >>> US > >>> Central on Tuesday morning. > >>> > >>> Do we have any slides to discuss, or a plan, or ...? > >>> > >>> Who will be there? (I will) > >>> > >> > >> -- > >> Bill Long longb(a)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 > >> > >> > >> _______________________________________________ > >> mpi3-fortran mailing list > >> mpi3-fortran(a)lists.mpi-forum.org > >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran > > > > -- > > Dr. Rolf Rabenseifner . . . . . . . . . .. email > > rabenseifner(a)hlrs.de > > High Performance Computing Center (HLRS) . phone > > ++49(0)711/685-65530 > > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / > > 685-65832 > > Head of Dpmt Parallel Computing . . . > > www.hlrs.de/people/rabenseifner > > Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room > > 1.307) > > _______________________________________________ > > mpi3-fortran mailing list > > mpi3-fortran(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran > > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)

1 0

Re: [MPI3 Fortran] MPI_INIT issues
by Malcolm Cohen 20 Feb '13

20 Feb '13

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. 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. 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. Cheers, -- ................................Malcolm Cohen, Nihon NAG, Tokyo.

1 0

Re: [MPI3 Fortran] MPI_INIT issues
by N.M. Maclaren 20 Feb '13

20 Feb '13

On Feb 20 2013, Bill Long wrote: > >Nick typically has access to crappier implementations than I, so I'll >defer to his unfortunate experience. No longer - but the memory remains! >In terms of the interface, I think I would prefer just making MPI_Init >effectively generic, with the allow calls: > >I'm less keen on the versions in the ticket because: Yes. Why upgrade from Fortran 77 to Fortran 90 in 2013? Relying on Fortran 2008 might be premature, but your solution needs only Fortran 2003. Regards, Nick Maclaren.

1 0

Re: [MPI3 Fortran] MPI_INIT issues
by Bill Long 20 Feb '13

20 Feb '13

Nick typically has access to crappier implementations than I, so I'll defer to his unfortunate experience. 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.] Just my gut feeling that this would be more intuitive to the MPI users. I'm less keen on the versions in the ticket because: 1) They look too much like wrappers to the Fortran intrinsics, prompting the obvious question of why not just call the intrinsics directly, and 2) The caller needs to determine either the maximum command/argument length somehow, or settle for an upper bound on the length, since the length of the character variable has to be known in the caller. Cheers, Bill On 2/20/13 12:17 PM, N.M. Maclaren wrote: > On Feb 20 2013, Bill Long wrote: >> >> I would expect the same output whether the parallelism was native or >> MPI. So, it seems like it might be a solution in search of a problem. > > I wouldn't. I have used a couple of MPIs where the arguments got through > to only the local (to mpiexec) or first process; I can't remember if I > ever experimented where there was no local MPI process and such MPIs. > On at least one, they didn't get through at all. > > If I can guess the issue, the usual solution is (in any language) to > read the command arguments (or unpick environment variables) on process > zero and broadcast them. If that doesn't get them, at least all > processes get the same ones and some other kludge can be tried. That's > really all that is needed. > > > Regards, > Nick Maclaren. > > > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran -- Bill Long longb(a)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

1 0

Re: [MPI3 Fortran] MPI_INIT issues
by N.M. Maclaren 20 Feb '13

20 Feb '13

On Feb 20 2013, Jeff Squyres (jsquyres) wrote: > >Perhaps your mail client is including ) in the URL? Right in one! Thanks. Regards, Nick Maclaren.

1 0