[Mpi3-ft] Updated FT Chapter

[Wesley Bland]

Yes. That's just a problem because the size of the edit is so large. Once
the ticket0 changes go away it looks fine. Unfortunately there's not a lot
I can do to fix that at the moment.

Wesley
On May 10, 2012 11:15 AM, "Supalov, Alexander" <alexander.supalov at intel.com>
wrote:

>  Hi Bland,****
>
> ** **
>
> Thanks. It appears that table 17.1 between pages 545 and 546 ran away from
> Section 17.4 where there’s a colon awaiting it. LaTeX, I suppose.****
>
> ** **
>
> Best regards.****
>
> ** **
>
> Alexander****
>
> ** **
>
> *From:* mpi3-ft-bounces at lists.mpi-forum.org [mailto:
> mpi3-ft-bounces at lists.mpi-forum.org] *On Behalf Of *Wesley Bland
> *Sent:* Wednesday, May 09, 2012 3:20 PM
> *To:* mpi3-ft at lists.mpi-forum.org
> *Subject:* Re: [Mpi3-ft] Updated FT Chapter****
>
> ** **
>
> Clearly the number of changes involved in renaming AGREEMENT to AGREE and
> INVALIDATE to REVOKE was overwhelming and made the document difficult to
> read. I've removed all of those changes and attached another draft which
> should be much simpler to parse.****
>
> ** **
>
> Wesley****
>
> On Tue, May 8, 2012 at 3:56 PM, Wesley Bland <wbland at eecs.utk.edu> 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). ****
>
> ** **
>
> 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.****
>
> - 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.****
>
> ** **
>
> Thanks,****
>
> Wesley Bland****
>
> ** **
>
> --------------------------------------------------------------------------------------
> Intel GmbH
> Dornacher Strasse 1
> 85622 Feldkirchen/Muenchen, Deutschland
> Sitz der Gesellschaft: Feldkirchen bei Muenchen
> Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
> Registergericht: Muenchen HRB 47456
> Ust.-IdNr./VAT Registration No.: DE129385895
> Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052
>
> _______________________________________________
> mpi3-ft mailing list
> mpi3-ft at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-ft/attachments/20120510/b54f322a/attachment-0001.html>