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

Tue Oct 25 06:31:56 CDT 2011

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?

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

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

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

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

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