On Oct 25, 2011, at 06:31 , Rolf Rabenseifner wrote:

Hi George,

Thanks for your detailed reviuew. I provide answers and further inquiries about your review, see below.

----- Original Message -----

...

From: "George Bosilca" <[email protected]> To: "William Gropp" <[email protected]> Cc: "Jeff Squyres" <[email protected]>, "Bill Gropp" <[email protected]>, "Brian Barrett" <[email protected]>, "Torsten Hoefler" <[email protected]>, "Rolf Rabenseifner" <[email protected]>, "Craig E Rasmussen" <[email protected]> Sent: Monday, October 24, 2011 5:32:58 PM Subject: Re: [Mpi-forum] Formal Reading of the new Fortran bindings in Chicago, Oct. 24, 2011, Ticket #229 I have some remarks.

============================== - mpi-report-F2008-2011-09-08-changeonlyplustickets.pdf p36:40-42 (=MPI-2.2 p34:3-5) read�

There is no mention on the probe/iprobe about the possibility of passing MPI_STATUS_IGNORE as an argument. I can understand that if the probe is fully named (source and tag), in some cases the status argument is superfluous, one only need the flag. However, as this is not clearly stated on the probe/iprobe I would not consider adding it to p36 a viable option. Moreover, there is __no__ way to link MPI_STATUSES_IGNORE with probe/iprobe.

https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/MPI-Fortr... lines 22-83 is doing all needed changes.

Okay?

OK.

...

============================== Section 3.6 Buffer Allocation and Usage (MPI_BUFFER_ATTACH), INTENT(IN) is added because the routine does not modify the content of the buffer:

The role of this function is to provide a playground for the MPI library to handle buffered operations. Why do we have to restrict how the MPI implementation is handling this memory (by adding the INTENT(IN)) ?

Your question is related to https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/MPI-Fortr... line 97 (as part of lines 84-115).

This question is independent of the rest of 84-115. Yes, we can freely decide. The INTENT(IN) is based on the rules of how much length can be used of such a buffer. With zero content it is zero. Therefore it would be erroneous, if the MPI library writes anything into this buffer. Therefore INTENT(IN) should be technically okay.

Are there known MPI libraries that fill something into the buf as side-effect of MPI_BUFFER_ATTACH?

How should we proceed with this question?

Removing the INTENT(IN) is fine. Thanks.

==============================

...

In general I'm totally confused about the usage of INTENT(IN)/INTENT(OUT) through the document. In the changed proposed you remove INTENT(OUT) from the status argument on the MPI_Probe and friends, because they might not modify the output buffer. Then why do you add it to the MPI_Buffer_detach? Do the MPI library have to modify the entire buffer to qualify as a correct implementation?

Your question is related to https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/MPI-Fortr... - line 41, 60, and 69 (as part of lines 22-83) about the probe variants, - line 130 (as part of lines 116-218) about MPI_BUFFER_DETACH.

In MPI_BUFFER_DETACH, the buf is an OUT argument! Many people missed this, at least the members of the MPI Forum when defining the wrong Fortran binding!

mpi_f08 will have the first time a correct Fortran binding, i.e., correct in the sense that it implements the language independent routine definition.

About MPI_PROBE and others: We decided in Santorini that we want to allow MPI_STATUS_IGNORE (lines 41 and 60), and therefore the INTENT(OUT) must be removed (line 69).

Is it now okay with these explanations?

As the output of the MPI_BUFFER_DETACH is not an array but a pointer to an array, the buffer argument should be marked as OUT. You're right.

==============================

...

Regarding Hubert question, I agree with him. Simply contiguous is not defined in the document, so I don't see how you expect the users to magically understand the subtle difference between contiguous and simply contiguous? Moreover on the paragraph where "simply contiguous" appears for the first time (copied below), I think MPI-2.2 is used instead of MPI-3.0.

...

Advice to users. For an MPI implementation that fully supports nonblocking calls with the ASYNCHRONOUS attribute for choice buffers, an existing MPI-2.2 application may fail to compile even if it compiled and executed with expected results with an MPI-2.2 implementation. One reason may be that the application uses contiguous but not simply contiguous ASYNCHRONOUS arrays as actual arguments for choice buffers of nonblocking routines,

Your question is related to https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/mpi-repor... page 554, lines 33-47.

"Simply contiguous" is a term defined by the Fortran standard. This means, that we are not allowed to redefine it. Therefore I added to examples to show the two main cases where this causes a problem.

I propose to add "See Section 16.2.12 on page 576 for more details." At the end of this advice to users.

Okay?

Sounds good.

==============================

...

While looking at thee changes I read the following statement. I had to go over twice to understand what exactly the meaning was, but I still consider it as very unclear. How this get into the standard? Page 31, lines 11-16.

...

In the case of a message shorter than the receive buffer, MPI is quite strict in that it allows no modification of the other locations. A more lenient statement would allow for some optimizations but this is not allowed. The implementation must be ready to end a copy into the receiver memory exactly at the end of the receive buffer, even if it is an odd address.

This is MPI-2.2 page 31 lines 11-16! This has nothing to do with this Fortran ticket #229.

Therefore no need to do anything in #229 about your question. Sorry.

Okay?

OK. Regards, george.

=================================

...

Thanks, george.

Tanks and best regards Rolf

-- Dr. Rolf Rabenseifner . . . . . . . . . .. email [email protected] 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: Allmandring 30)