March 2014 - mpiwg-fortran - mailman3.cels.anl.gov

Questions about MPI_Comm_spawn
by Junchao Zhang 25 Mar '14

25 Mar '14

Hello, Fortran experts, p.377 of MPI3 defines prototype of MPI_Comm_spawn. MPI_Comm_spawn(command, argv, maxprocs, info, root, comm, intercomm, array_of_errcodes, ierror) CHARACTER(LEN=*), INTENT(IN) :: command, argv(*) ... I can understand that command is a variable-length character. I fetch its length by len(command). The Fortran compiler needs to pass in data of command, as well as length of command. But I can't understand argv(*). I interpret it as an assumed-size array of variable-length characters. Does that imply each argv(i) could have different lengths, e.g., len(argv(1)) may be different from len(argv(2))? I think it is unreasonable, since if that, the compiler has to pass in length of every element of argv(*). Thank you --Junchao Zhang

3 4

Fortran hints on pages 52, 78, 103, 465, 507
by Rolf Rabenseifner 21 Mar '14

21 Mar '14

The titles are cited in a shortened and summarizing form. There seems to be nothing outdated or wrong. The cited sections are the most relevant for further reading. And it would be good if the process would include that the relevant authors are informed when errors are detected, in this case the Fortran WG together with the chapter committee. The hints are based on reported experience that users of Fortran often fail to handle these issues in a correct way. Rolf ----- Original Message ----- > From: "William Gropp" <wgropp(a)illinois.edu> > To: "Jim Dinan" <james.dinan(a)gmail.com> > Cc: "Jeff Hammond" <jeff.science(a)gmail.com>, "Rolf Rabenseifner" <rabenseifner(a)hlrs.de>, "David Solt" > <dsolt(a)us.ibm.com>, "Jeff Squyres" <jsquyres(a)cisco.com>, "Bill Gropp" <wgropp(a)uiuc.edu>, "Martin Schulz" > <schulzm(a)llnl.gov>, "George Bosilca" <bosilca(a)icl.utk.edu>, chap-terms(a)lists.mpi-forum.org > Sent: Friday, March 21, 2014 5:42:54 PM > Subject: Re: MPI-Terms - 06 - Addresses and displacements > > Here's the reason. The text was incorrect, in large part because it > included out of date (read *wrong*) and totally unnecessary section > titles. The source files have the explanation; from the first > occurrence of the incorrect text in the point-to-point chapter: > > > > %% Note that a previous version of this included what it hoped were the > %% titles of the sections. That hope was misplaced, as the section > %% titles had been changed. Another example of the folly in trying to > %% keep multiple references manually synchronized. The titles are really > %% not necessary here, as the first sentance covers the general issues. > %% Attempting to enumerate them all is also a mistake, as it leaves out > %% some that are also important. > > If there is a better update, let me know. There was no intent to > change the meaning of the text, only correct errors. > > Bill > > William Gropp > Director, Parallel Computing Institute Thomas M. Siebel Chair in > Computer Science > > University of Illinois Urbana-Champaign > > > On Mar 21, 2014, at 10:34 AM, Jim Dinan wrote: > > According to SVN, this passage was commented out by gropp in r1711, > which has the following log entry: > > > > ------------------------------------------------------------------------ > r1711 | gropp | 2013-10-28 13:17:38 -0400 (Mon, 28 Oct 2013) | 1 line > Changed paths: > M /approved/MPI-3.1/MAKE-APPLANG > M /approved/MPI-3.1/chap-binding/binding-2.tex > M /approved/MPI-3.1/chap-coll/coll.tex > M /approved/MPI-3.1/chap-context/context.tex > M /approved/MPI-3.1/chap-datatypes/datatypes.tex > M /approved/MPI-3.1/chap-dynamic/dynamic-2.tex > M /approved/MPI-3.1/chap-frontm/abstract-cpy.tex > M /approved/MPI-3.1/chap-frontm/history.tex > M /approved/MPI-3.1/chap-intro/intro.tex > M /approved/MPI-3.1/chap-io/io-2.tex > M /approved/MPI-3.1/chap-one-side/one-side-2.tex > M /approved/MPI-3.1/chap-pt2pt/pt2pt.tex > M /approved/MPI-3.1/chap-topol/topol.tex > M /approved/MPI-3.1/getlatex > > > More updates > ------------------------------------------------------------------------ > > > Looking over the history, this appears to be part of a series of > LaTeX-related updates, and may have been unintentional. > > > ~Jim. > > > > On Fri, Mar 21, 2014 at 9:15 AM, Jeff Hammond < > jeff.science(a)gmail.com > wrote: > > > You can run SVN log/blame to see who removed the text. I have no idea > about this so I cannot discuss the process by which it came to pass. > > Jeff > > Sent from my iPhone > > > > > On Mar 21, 2014, at 5:48 AM, Rolf Rabenseifner < > > rabenseifner(a)hlrs.de > wrote: > > > > Hi Jim and all, > > > > a really negative surprise was that Fortran related text > > was removed from the approved svn without > > discussing this together with the Fortran working group. > > > > This is the fastest way to get additional inconsistencies > > into the MPI standard. > > > > George and Jeff H. as Chap.4 committee, > > please can you check the process and tell me what went wrong. > > This will be also an input for the discussion how to keep > > or get the document consistent. > > The probably lost text portion is MPI-3.0 p103:42-46. > > ... -- 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)

2 1

Type of MPI_Status
by Junchao Zhang 18 Mar '14

18 Mar '14

Hello, p30 of MPI3 says "In Fortran with USE mpi or INCLUDE 'mpif.h', status is an array of INTEGERs of size MPI_STATUS_SIZE. ..., With Fortran USE mpi_f08, status is defined as the Fortran BIND(C) derived type TYPE(MPI_Status) containing three public fields named MPI_SOURCE, MPI_TAG, and MPI_ERROR" In other words, it does't say type of the three public fields must be INTEGER. So, in mpi_f08, can I declare MPI_Status as TYPE, BIND(C) :: MPI_Status INTEGER(C_INT) :: MPI_SOURCE, MPI_TAG, MPI_ERROR ... ! other fields END TYPE MPI_Status I find it makes MPI_Status binding easier. Since this type is interoperable with C, I do not need to allocate temp variables to do type conversion when INTEGER is not a C_INT. --Junchao Zhang

7 37

Question about an argument of MPI_Testall
by Junchao Zhang 12 Mar '14

12 Mar '14

Hello, P60 of MPI3 reads: MPI_Testall(count, array_of_requests, flag, array_of_statuses, ierror) INTEGER, INTENT(IN) :: count TYPE(MPI_Request), INTENT(INOUT) :: array_of_requests(count) LOGICAL, INTENT(OUT) :: flag TYPE(MPI_Status) :: array_of_statuses(*) INTEGER, OPTIONAL, INTENT(OUT) :: ierror Should array_of_statuses be declared as TYPE(MPI_Status) :: array_of_statuses(count)? Thanks --Junchao Zhang

7 11

Assumed-size array in MPI3
by Junchao Zhang 10 Mar '14

10 Mar '14

Hello, I read a Fortran textbook, which says "Assumed-size dummy arrays are a holdover from earlier versions of Fortran. They should never be used in any new programs". But I find MPI3 has interfaces like MPI_Alltoallv(sendbuf, sendcounts, sdispls, sendtype, recvbuf, recvcounts, rdispls, recvtype, comm, ierror) ... INTEGER, INTENT(IN) :: sendcounts(*), sdispls(*), recvcounts(*), rdispls(*) ... I was wondering why MPI3 still uses it. Thanks. --Junchao Zhang

4 3

Reading of #408: deprecating mpif.h/freezing mpi module
by Jeff Squyres (jsquyres) 05 Mar '14

05 Mar '14

Due to scheduling, I ended up reading #408 today (instead of tomorrow): Please see the results: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/408#comment:5 -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

2 1

Questions on the F08 subarray format
by Balaji, Pavan 02 Mar '14

02 Mar '14

Folks, I had a few questions on the MPI-3 F08 bindings, which I couldn’t find answers to in the standard. Can someone point me to the place where these are defined? 1. How does the subarray format work for functions that have a void* argument, but no datatype to describe them (e.g., MPI_WIN_CREATE)? In this case, What C function will MPI_WIN_CREATE_F08TS call? Do we need to create an separate internal MPIR_WIN_CREATE_NEW function in our implementation that takes a datatype argument? Does this mean that now MPI_WIN_CREATE can allow for noncontiguous buffers on each process? 2. How does the subarray format work for functions that have a datatype argument, but no void* corresponding to that datatype? For example, the target buffer in MPI_PUT is described using an MPI_AINT (offset), rather than a void*. 3. How does the subarray format work for functions that have two void* arguments corresponding to the same datatype (e.g., MPI_REDUCE)? Thanks, — Pavan

3 6