[Mpi3-ft] Updated FT Chapter

[Schulz, Martin]

Hi all,

Unfortunately, I won't make it tomorrow due to another conflicting call, but I wanted to raise a few issues:

On May 8, 2012, at 12:56 PM, Wesley Bland wrote:

> We've completed the new draft of the FT chapter. I've attached just the FT chapter to this email. The rest of the document can be found on the ticket (https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/323).

I think this document is a bit hard to read - since the changes that are marked "ticket 0" (I assume those are all new changes) are mixed into existing changes for the main ticket, it is very hard to read what has actually been changed and what not. There is even one place where there is a ticket 0 in a ticket 0 change. Would it be possible to generate a cleaned-up ticket with just the changes?

In general, though, it strikes me that some of those are non ticket 0 changes. In particular, on page 538 and 539, the new document replaces half a page of text. I think this has to be re-read, despite the obvious consequences. In addition, there are other changes that touch the semantics that make me a bit concerned.

> 
> In this new version, we've clarified many of the points raised at the forum meetings and on the recent conference calls. Here's a list:
> 
> - MPI_COMM_INVALIDATE is now MPI_COMM_REVOKE due to naming conflicts (along with the RMA and I/O versions)
> - MPI_COMM_AGREEMENT is now MPI_COMM_AGREE to follow naming conventions
> - A paragraph was added to 17.1 (Introduction) to clarify that FT is optional, but implementing the new FT functions is not.
> - Section 17.2.2 (Point-to-Point and Collective Communication) has been reworked to try to make it more clean when to return MPI_ERR_PENDING and MPI_ERR_PROC_FAILED.
> - The non-rooted collective discussion in the advice to users in Section 17.2.2 has been changed to make it more clear when collective operations might have non-uniform return values.

what is exactly meant with "in which all processes contribute to the result and all processes receive the result" - what is "the result"? This doesn't really describe an alltoall, since any process only receives part of a "result". Perhaps this should be reformulated to "in which all processes contribute data and all processes receive data"? This probably doesn't catch MPI_Scan, though.


> - The definition of MPI_COMM_REVOKE has been clarified to further define that the function is not collective and does not have a matching call on remote processes.
> 
> If you see more changes that you think would be helpful, please let us know either on this list or on the conference call tomorrow.

Martin


> 
> Thanks,
> Wesley Bland
> <ftchapter.pdf>_______________________________________________
> mpi3-ft mailing list
> mpi3-ft at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft

________________________________________________________________________
Martin Schulz, schulzm at llnl.gov, http://people.llnl.gov/schulzm
CASC @ Lawrence Livermore National Laboratory, Livermore, USA