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

[George Bosilca]

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?

No, it's not addressing the issue I raised. MPI_Probe and MPI_Iprobe don't mention that MPI_STATUS_IGNORE is a valid value to be passed on. Second, the way your sentence read it indicates that MPI_STATUSES_IGNORE is a valid value for probe, which is not.

>> ==============================
>> 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.

With a zero length I hope the MPI library complains. What's the point of providing a zero length buffer there?

> 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?

The purpose of this function is to give away this "simply contiguous" memory to the MPI library. Without any strings attached.

> How should we proceed with this question?

Remove the INTENT(IN) seems like the right approach.

> ==============================
>> 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!

Last time we talked about this you said INTENT(OUT) should only be used if the entire buffer is modified by the call. There is no guarantee that the entire attached buffer will be written by the MPI library (it will depends on the application anyway). Thus, to insure F08 correctness, a valid MPI library will have to overwrite the attached buffer on MPI_BUFFER_DETACH.

> 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).

Then similar wording should be added to the C part of the MPI_Probe/MPI_Iprobe.

> Is it now okay with these explanations?
> 
> 
>> ==============================
>> 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.

We should not mandate the reading of the Fortran standard in order to understand the MPI standard. If we use a term to depict MPI requirements, this term has to be defined, even if it's a citation from 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?
> 
> 
>> ==============================
>> 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.

No it doesn't …

  george.

> 
> Therefore no need to do anything in #229 about your question. Sorry.
> 
> Okay?
> 
> 
> =================================
>> 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)