Sorry, I forget to forward the review and my answer to the whole Fortran group. The mails was only in the group of the currently needed reviewers for these latest changes. Best regards Rolf ----- Forwarded Message ----- From: "Rolf Rabenseifner" <[email protected]> To: "Hubert Ritzdorf" <[email protected]> Cc: "Bill Gropp" <[email protected]>, "Richard Graham" <[email protected]>, "Brian W Barrett" <[email protected]>, "George Bosilca" <[email protected]>, "Martin Schulz" <[email protected]>, "Torsten Hoefler" <[email protected]> Sent: Sunday, October 23, 2011 6:55:08 PM Subject: Re: Formal Reading of the new Fortran bindings in Chicago, Oct. 24, 2011, Ticket #229 Dear Hubert and all others, Hubert: thank you for your detailed review of the whole text. others: please can you check whether the revised version 2011-10-23 is now okay for youa all. I inlined my comments. With one exception, I changed the text according to Huberts advices, see below. Best regards Rolf PS: The reading in Chicago Oct. 2011, is now based on - https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/mpi-repor... - https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/MPI-3.0-F... Slides 8-14. - https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/229/MPI-Fortr... The revised version from Oct. 23, 2011 ----- Original Message -----

From: "Hubert Ritzdorf" <[email protected]> To: "Rolf Rabenseifner" <[email protected]>, "Bill Gropp" <[email protected]>, "Richard Graham" <[email protected]>, "Brian W Barrett" <[email protected]>, "George Bosilca" <[email protected]>, "Martin Schulz" <[email protected]>, "Torsten Hoefler" <[email protected]> Sent: Wednesday, October 12, 2011 1:03:02 PM Subject: RE: Formal Reading of the new Fortran bindings in Chicago, Oct. 24, 2011, Ticket #229 Hi Rolf,

I checked all lines. Here my review:

--------------------------------- Lines 110-113 of file MPI-Fortran-Changes_2011-20-09-1.txt Additional text for Section 3.6:

There are many possibilities to pass a simply contiguous memory region to MPI_BUFFER_ATTACH (and all other MPI functions such as MPI_Send, .....). Therefore, I don't like especially the sentence in Fortran. I would propose to change Lines 110-113

* In C and C++, buffer is the starting address of a memory region. * In Fortran, one can pass the first element of a memory region * or a whole array, which must be simply contiguous * (for simply contiguous, see also Section 16.2.12 on page 576).

into

* buffer is the starting address of a simply contiguous memory region * (for simply contiguous in Fortran, see also Section 16.2.12 on page 576).

No, I do not change the text, because the term "simply contiguous" is defined only in the context of Fortran, and there only in the context of an array. That is the reason, why we must differentiate these three cases.

------------------------------ Lines 468-476 Change of p581:11-29

I think, you want to add a 5th entry to mytype. I think mytype currently has 4 entrys. My view is:

type, BIND(C) :: mytype integer i real x double precision d logical l end type mytype

Yes, on line 469, it must be "fifth" instead of sixth".

To be consistent, we should add a double colon :: before each entry of the derived type.

Yes, I add the ::

Adding the 5th entry doesn't guarantee that the array of structures is contiguous. The special alignment rule of the compiler could .be: align the derived type to 256 bit/8 words (see also the last sentence (Line 474-476), which mentions such a possibility).

Yes, therefore I change "guarantee" in "force in most cases", and I remove the next three lines about "Without such an additional...", and on line 474, "With" --> "Even with", and removing "also". The text is therefore As recommended in the advice to users in Section 4.1.6 on page 106, one should add an additional fifth structure element with one numerical storage unit at the end of this structure to force in most cases that the array of structures is contiguous. Even with such an additional element, one should keep this resizing due to the special alignment rules that can be used by the compiler for structures, as also mentioned in this advice.

----------------------

Line 482-387

it is 482-487

In Annex B

The problem may also occur for other datatype constructors. Example:

type, BIND(C): huhu integer :: huhu_entry(5) end type huhu

type (huhu) :: array(10) integer :: huhu_type

call MPI_Type_contiguous (5, MPI_INTEGER, huhu_type, ierror) call MPI_Type_commit (huhu_type, ierror)

call MPI_Send (array, 10, huhu_type, ....

Therefore, I propose to change

n Using MPI_TYPE_CREATE_STRUCT, it is always recommended that the user applies n additionally MPI_TYPE_CREATE_RESIZED if the datatype handle should be used to communicate n an array of structures.

to

n If an array of structures (in C/C++) or derived types (In Fortran) should be communicated, n it is always recommended that the user creates a portable datatype handle and applies n additionally MPI_TYPE_CREATE_RESIZED to this datatype handle.

Yes, I change it.

-------------------

Line 570-573 p394:45-p395:2

There are many additional possibilities of windows in Fortran (for example a derived type, a single variable): Therefore, I propose to replace

* In C and C++, base is the starting address of a memory region. * In Fortran, one can pass the first element of a memory region * or a whole array, which must be simply contiguous * (for simply contiguous, see also Section 16.2.12 on page 576).

by

* base is the starting address of a simply contiguous memory region * (for simply contiguous in Fortran, see also Section 16.2.12 on page 576).

The same as above: No, I do not change the text, because the term "simply contiguous" is defined only in the context of Fortran, and there only in the context of an array. That is the reason, why we must differentiate these three cases.

Best regards

Hubert

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