[mpiwg-p2p] Next meeting: 25th May 2015 11am Central US

[Daniel Holmes]

Hi All,

The next point-to-point teleconference will be today (in 4 and a bit 
hours' time), Monday 25th April 2015 at 11am Central US via webex.

Connection details are on the point-to-point wiki page:
https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/PtpWikiPage

Agenda:
1) "Can INFO keys change the semantic behaviour of MPI?" issue - the 
communicator assertions ticket is ready for Forum feedback, time has 
been requested for an informal reading in June.
2) New communicator INFO keys - it looks like these will be allowed, so 
we should define a few and get a proposal ready for the next 
face-to-face meeting
3) Progress on Arecv and Fsend or ReceiveReduce?
4) Other stuff?

Cheers,
Dan.

On 27/04/2015 15:29, Daniel Holmes wrote:
> Hi All,
>
> I am cancelling the point-to-point teleconference today because I have 
> not had time to progress the work on communicator assertions since 
> last time and I am not aware of any other ongoing work for us to talk 
> about.
>
> Looking forward to figure out when the next meeting will take place, I 
> won't be available for the next two teleconferences due to travelling. 
> This means that the next meeting date would be 25th May, i.e. one week 
> before the face-to-face meeting in Chicago.
>
> I will send out a reminder nearer the time and will communicate any 
> progress in the interim via email.
>
> Cheers,
> Dan.
>
> On 13/04/2015 10:32, Daniel Holmes wrote:
>> Hi All,
>>
>> The next point-to-point teleconference will be today, Monday 13th 
>> April 2015 at 11am Central US via webex.
>>
>> Connection details are on the point-to-point wiki page:
>> https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/PtpWikiPage
>>
>> Agenda:
>> 0) Discuss/agree the to-do list (see below) that covers the next two 
>> agenda items.
>> 1) "Can INFO keys change the semantic behaviour of MPI?" issue - 
>> following the discussion at the face-to-face meeting, we seem to have 
>> a workable way forward on this issue!
>> 2) New communicator INFO keys - it looks like these will be allowed, 
>> so we should define a few and get a proposal ready for the next 
>> face-to-face meeting
>> 3) Progress on Arecv and Fsend or ReceiveReduce?
>> 4) Other stuff?
>>
>> Cheers,
>> Dan.
>>
>>> Hi All,
>>>
>>> At the last telco meeting, Jim asked for a to-do list of the tasks 
>>> needed to move communicator assertions forward. Please find below a 
>>> first draft of such a task list. Could we agree that this is a good 
>>> list? If you see something odd/missing, reply to this email group.
>>>
>>> _To-do list for communicator assertions__
>>> _
>>> 0) Gather evidence to support "no-one will be affected by backwards 
>>> incompatibility".
>>>    (e.g. chase Pavan, who volunteered to do this for major MPICH users)
>>> 1) Change behaviour of MPI_COMM_DUP so that INFO keys are *not* 
>>> propagated to new comm.
>>>    (include AtoU: if you want to dup INFO use 
>>> MPI_COMM_DUP_WITH_INFO, with example)
>>> 2) Discuss whether attributes (plus, anything else?) should be 
>>> propagated by MPI_COMM_DUP.
>>>    (default presumption is yes, they should still be propagated).
>>> 3) Find all occurrence of language in the MPI Standard that suggests 
>>> INFO keys are hints.
>>> a) Change or remove any generic statements like "INFO keys cannot 
>>> change semantics".
>>>    (e.g. change to "cannot change observable semantics" or remove)
>>> b) For each occurrence, determine if it should continue to suggest 
>>> hint status
>>>    (e.g. a particular key, most likely for the I/O keys but maybe 
>>> also some RMA keys)
>>>
>>> A) Convert ticket 381 into "make comm assertions doable" proposal 
>>> (by Jun 2015 - Chicago?)
>>> B) Get "no wildcard" INFO keys proposal ready for formal reading (by 
>>> Jun 2015 - Chicago?)
>>> C) Get "no ordering" INFO key proposal ready for formal reading (by 
>>> Jun 2015 - Chicago?)
>>> D) Get "no cancel" INFO keys proposal ready for formal reading (by 
>>> Jun 2015 - Chicago?)
>>> E) Discuss other INFO key proposals, e.g. "only wildcard", "no 
>>> non-blocking", "no underflow"
>>>
>>> Cheers,
>>> Dan.
>>
>> -- 
>> Dan Holmes
>> Applications Consultant in HPC Research
>> EPCC, The University of Edinburgh
>> James Clerk Maxwell Building
>> The Kings Buildings
>> Peter Guthrie Tait Road
>> Edinburgh
>> EH9 3FD
>> T: +44(0)131 651 3465
>> E:dholmes at epcc.ed.ac.uk
>>
>> *Please consider the environment before printing this email.*
>
> -- 
> Dan Holmes
> Applications Consultant in HPC Research
> EPCC, The University of Edinburgh
> James Clerk Maxwell Building
> The Kings Buildings
> Peter Guthrie Tait Road
> Edinburgh
> EH9 3FD
> T: +44(0)131 651 3465
> E:dholmes at epcc.ed.ac.uk
>
> *Please consider the environment before printing this email.*
>
>
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
>
> _______________________________________________
> mpiwg-p2p mailing list
> mpiwg-p2p at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p
>
>
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.

-- 
Dan Holmes
Applications Consultant in HPC Research
EPCC, The University of Edinburgh
James Clerk Maxwell Building
The Kings Buildings
Peter Guthrie Tait Road
Edinburgh
EH9 3FD
T: +44(0)131 651 3465
E: dholmes at epcc.ed.ac.uk

*Please consider the environment before printing this email.*

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-p2p/attachments/20150525/55d17ece/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-p2p/attachments/20150525/55d17ece/attachment.ksh>