[mpiwg-p2p] Next meeting: 13th April 2015 11am Central US

[Jeff Hammond]

i am working on SC15 papers and will not attend.

On Mon, Apr 13, 2015 at 2:32 AM, Daniel Holmes <dholmes at epcc.ed.ac.uk> 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.*
>
>
> 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



-- 
Jeff Hammond
jeff.science at gmail.com
http://jeffhammond.github.io/