[MPI3 Fortran] [Mpi-forum] Formal Reading of the new Fortran bindings in Chicago, Oct. 24, 2011, Ticket #229

Tue Oct 25 12:48:33 CDT 2011

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" <bosilca at eecs.utk.edu>
>> To: "William Gropp" <wgropp at illinois.edu>
>> Cc: "Jeff Squyres" <jsquyres at cisco.com>, "Bill Gropp" <wgropp at uiuc.edu>, "Brian Barrett" <bwbarre at sandia.gov>,
>> "Torsten Hoefler" <htor at illinois.edu>, "Rolf Rabenseifner" <rabenseifner at hlrs.de>, "Craig E Rasmussen"
>> <rasmussn at lanl.gov>
>> 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-Fortran-Changes_2011-10-23.txt
> 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-Fortran-Changes_2011-10-23.txt
> 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-Fortran-Changes_2011-10-23.txt
> - 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-report-F2008-2011-09-08-changeonlyplustickets.pdf
> 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 rabenseifner at 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: Allmandring 30)