<div dir="ltr">Hi George,<div><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>
<div class="im"><blockquote type="cite"><div dir="ltr"><div>Re: comm_create and friends -- I'd be interested in hearing the result of the F2F discussion.  I've been the person complaining about this, so if it would be helpful for me to join you guys over the phone next Friday, let me know.</div>
</div></blockquote><div><br></div></div><div>I did not have the opportunity to hear your complaint about this. Can you please summarize it here on the mailing list to make sure 1) that we are all at the same level of understanding; 2) the complaint reach all the interested audience and 3) we have the opportunity to address it as accurately as possible.</div>
</div></div></blockquote><div><br></div><div style>I'm concerned that the current spec is missing a few features that are needed for the usage model where users continue to use a communicator with "holes" in it.  In order for this model to work well, users must be able to query which processes are known to have failed in a given communicator.  Given the current interface, users are not able to query the set of failed processes without creating a new communicator and translating ranks, via  MPI_Comm_shrink.  This requires the user to first revoke the parent communicator, which is something we want to avoid.</div>
<div style><br></div><div style>Along these same lines, we should also ensure that MPI_Comm_create_group will work as expected when a communicator with holes is used, provided the output group excludes failed processes (i.e., the operation is not collective over any failed processes).  This might not require any text changes, unless we want to allow this operation on revoked communicators.</div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="im"><div></div><blockquote type="cite"><div dir="ltr">

<div>Re: Roadmap -- Before a reading, it might be helpful to give a brief presentation to the Forum again giving the high level ideas and justifications for each new addition to the FT proposal.  I think it's been long enough that people have forgotten the details and this might help them feel more comfortable that the proposal is complete and self-consistent.</div>
</div></blockquote><div><br></div></div><div>There was at least one [more or less] "brief" presentation of the FT proposal at every meeting for the last two years. I would even emphasize the fact that over the last year no major modification of the proposal has been put forward, fact that might indicate a certain level of completeness and self-consistency. </div>
</div></div></blockquote><div><br></div><div style>I'm just trying to convey the temperature in the room, as I felt it.  I think a 15 minute, very high level warm-up immediately before the reading on the usage models, big ideas, and conventions would go a long way toward prepping the audience.</div>
<div style><br></div><div style> ~Jim.</div></div></div></div></div>