[mpiwg-hybridpm] Hybrid WG telecon tomorrow

Jim Dinan james.dinan at gmail.com
Fri Jul 25 11:12:19 CDT 2014


Comm_create is definitely a separate ticket.  :)


On Thu, Jul 17, 2014 at 3:32 AM, Dan Holmes <dholmes at staffmail.ed.ac.uk>
wrote:

> Hi Jim,
>
> I've just read the MPI_COMM_CREATE text in MPI-3.0 and you are correct
> that the order of statements there is also not ideal.
>
> I'm not certain of where the re-read threshold is - that'll be a Forum
> decision on the day, I guess. Moving a couple of sentences, without
> changing their content, doesn't seem like a big change to me. Especially
> when the consequence of the re-positioning is to achieve syntactically what
> everyone is supposed to assume from the previous ordering. I'll leave it up
> to you! I certainly don't want to make anyone's life difficult or delay the
> approval process for end-points.
>
> I don't suggest that we try to change the text for MPI_COMM_CREATE, either
> as part of this ticket or separately.
>
> Cheers,
> Dan.
>
>
> On 16/07/2014 20:28, Jim Dinan wrote:
>
>> Hi Dan,
>>
>> Thanks for the thorough feedback.  I applied these changes and attached an
>> updated document.  I'm trying to keep the changes we make right now as
>> small as possible so that we can have a first vote in Japan.  The change
>> below is reasonable, but I'm concerned that it might push us over the
>> re-read threshold.
>>
>> On Tue, Jul 1, 2014 at 5:34 AM, Daniel Holmes <dholmes at epcc.ed.ac.uk>
>> wrote:
>>
>>> %%PROBLEM
>>> The statements about cached information, valid values for my_num_ep, and
>>> the condition for the error code/class all apply to the
>>> inter-communicator
>>> case as well as the intra-communicator case. Should this be made clearer
>>> by
>>> moving that text out of the intra-communicator paragraph and after the
>>> inter-communicator paragraph?
>>> %%SUGGESTION
>>> If parent_comm is an intracommunicator ... sum of the values of my_num_ep
>>> on all calling processes. If parent_comm is an intercommunicator ...
>>> MPI_COMM_NULL is returned in all entries of new_comm_handles.
>>> <p>No cached information ... this function will return MPI_ERR_ENDPOINTS
>>> at all processes.
>>>
>>>  What are your thoughts?  I believe that the structure we have for this
>> text
>> was inherited from the MPI_Comm_create text.
>>
>>   ~Jim.
>>
>>
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-hybridpm/attachments/20140725/816f7e58/attachment-0001.html>


More information about the mpiwg-hybridpm mailing list