Hi Wesley,

Overall, this is going in a great direction. Thanks for all of the effort you and others have been putting into the presentation.

Slide 4: "Only requirement is that failure are eventually reported to all processes which communicate with the failed process." I am wondering if this statement, to be precise, applies only to point-to-point communication? Is it possible for me to never find out about a failure of another process with whom I make collective calls?

Slide 5: I haven't heard the term "algorithm completion" before. Would it be better to call this something like fault tolerant consensus?

Slide 11: You should point out that we have no way to free a communicator, if it is not valid at all correct processes. Processes that noticed the failure wouldn't be able to call revoke, since they don't have a valid handle to the communicator.

Slide 12: Should you clean up the communicator somehow, if the creation failed? Do you revoke or free it? Is this semantic defined -- seems like the same issue as on slide 11?

~Jim.

On Fri, Aug 16, 2013 at 1:17 PM, Wesley Bland <wbland@mcs.anl.gov> wrote:

I've put together a first draft of some slides that give an overview of ULFM for the forum meeting in Madrid for Rich to present. I think I captured most of the discussion we had on the last call relating to rationale, but if I missed something, feel free to add that to this deck or send me edits.

I think the plan of action, as I understand it from Rich and Geoffroy, is to iterate on these slides until the next call on Tuesday and then we'll go over them as a group to make sure we're all on the same page. Rich, will you be able to attend the call this week (Tuesday, 3:00 PM EST)? If not, we can adjust it this week to make sure you can be there.

Just to be clear, the goal of this presentation is to provide an overview of ULFM for the European crown that can't usually attend the forum meetings. This will probably be a review for many of the people who attend regularly, but there is some new rationale that we haven't included in the past when we've been putting these presentations together. I'd imagine that this meeting will have some confusion from the attendees where they might remember parts of the previous proposals and mix them, but if we can tell them to do a memory wipe ahead of time, that would help.

Let me know what I've missed.

Thanks,
Wesley

_______________________________________________
mpi3-ft mailing list
mpi3-ft@lists.mpi-forum.org
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft