July 2014 - mpiwg-hybridpm - mailman3.cels.anl.gov

Call on Monday: cancelled
by Balaji, Pavan 25 Jul '14

25 Jul '14

Folks, Jim is going to be out of office on Monday. Since the only item on the agenda is endpoints, let’s cancel the call. Thanks, — Pavan -- Pavan Balaji ✉️ http://www.mcs.anl.gov/~balaji

1 0

Re: [mpiwg-hybridpm] Hybrid WG telecon tomorrow
by Jim Dinan 25 Jul '14

25 Jul '14

Comm_create is definitely a separate ticket. :) On Thu, Jul 17, 2014 at 3:32 AM, Dan Holmes <dholmes(a)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(a)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. > >

1 0

Re: [mpiwg-hybridpm] Hybrid WG telecon tomorrow
by Dan Holmes 17 Jul '14

17 Jul '14

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(a)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.

1 0

Re: [mpiwg-hybridpm] Hybrid WG telecon tomorrow
by Jim Dinan 16 Jul '14

16 Jul '14

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(a)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.

1 0

Re: [mpiwg-hybridpm] Telecon today?
by Balaji, Pavan 14 Jul '14

14 Jul '14

Dan and I are on the call. — Pavan On Jul 14, 2014, at 10:56 AM, Steven Oyanagi <sko(a)cray.com> wrote: > Hi, > > Just wondering - the schedule says there is a Telecon today, but I have > not seen a reminder or an agenda? > - Steve > > _______________________________________________ > mpiwg-hybridpm mailing list > mpiwg-hybridpm(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm

1 0

Telecon today?
by Steven Oyanagi 14 Jul '14

14 Jul '14

Hi, Just wondering - the schedule says there is a Telecon today, but I have not seen a reminder or an agenda? - Steve

1 0

Re: [mpiwg-hybridpm] Hybrid WG telecon tomorrow
by Jim Dinan 01 Jul '14

01 Jul '14

Done. On Mon, Jun 30, 2014 at 8:52 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: > > Here’s a draft of the minutes: > > > https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Hybrid/notes-2014-06-… > > Jim: can you add notes for the endpoints discussion? > > — Pavan > > On Jun 29, 2014, at 1:40 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: > > > All, > > > > This is a reminder that we’ll have our hybrid WG telecon tomorrow > (06/30) at 11am central time. > > > > I’ve made the promised corrections to ticket 411 and uploaded a new > draft. > > > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/411 > > > > We can discuss this tomorrow, together with the remaining tickets. > > > > Thanks, > > > > — Pavan > > > > _______________________________________________ > > mpiwg-hybridpm mailing list > > mpiwg-hybridpm(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm > > _______________________________________________ > mpiwg-hybridpm mailing list > mpiwg-hybridpm(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm >

1 0

Re: [mpiwg-hybridpm] Hybrid WG telecon tomorrow
by Daniel Holmes 01 Jul '14

01 Jul '14

Hi Jim, General comment: the word "process" in the MPI Standard is not well-defined. IMHO, it should always be short-hand for "MPI process" but it is often taken to mean "OS process". Adding a new implicit meaning, i.e. "endpoint", is not helpful. There is a one-to-many relationship between OS process and MPI process. There is a one-to-many relationship between MPI process and endpoint. The term "process" is used to refer to the child, the parent, or the grandparent in this hierarchy with the context (hopefully) determining which meaning is intended. I've re-read all of the new text looking for process/rank wording issues. There are some inconsistencies where "rank" in the parent communicator is still used. Page 244, lines 36-37 %%CURRENT associated with a single calling rank in parent_comm. %%SUGGESTION associated with a single calling process in parent_comm. Page 244, line 39 %%CURRENT at the corresponding rank in parent_comm. %%SUGGESTION at the corresponding process in parent_comm. Page 244, lines 39-40 %%CURRENT Ranks associated with a process in parent_comm are numbered contiguously in the output communicator, and %%PROBLEM "process in parent_comm" is intended to refer to "rank in parent_comm". Example: create an endpoints communicator, use split to re-order the ranks then create another endpoints communicator. The ranks associated with an OS process may not be contiguous - they may consist of several sub-groups (each of which is internally contiguous), one per local rank in parent_comm. %%SUGGESTION1 Ranks in new_comm_handles are numbered contiguously in the output communicator and %%SUGGESTION2 (preferred) Ranks in new_comm_handles are numbered contiguously and Page 244, lines 40-41 %%CURRENT and the starting rank is defined by the order of the associated rank in the parent communicator. %%PROBLEM "associated rank" is intended to refer to "calling process" %%SUGGESTION and the starting rank is defined by the order of the calling process in parent_comm. Other comments: %%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. Page 245 line 20 %%CURRENT Some operations, such as collective operations, cannot be used %%PROBLEM A single thread can perform a non-blocking collective even when there are multiple local endpoints. This would only require MPI_THREAD_SINGLE. %%SUGGESTION Some operations, such as blocking collective operations, cannot be used Cheers, Dan. On 01/07/2014 01:45, Jim Dinan wrote: > All, > > Below are two options for the endpoints error text: > > %% OLD: > If the MPI implementation is not able to create a new communicator because > of the \mpiarg{my\_num\_ep} argument given by any process, this function > will > return \error{MPI\_ERR\_ENDPOINTS}. > > %% Option 2 (Suggested by Pavan): > If a process provides a valid \mpiarg{my\_num\_ep} argument, but the MPI > implementation is not able to create a new communicator because of the > \mpiarg{my\_num\_ep} argument at this process, this function will return > \error{MPI\_ERR\_ENDPOINTS} at all processes. > > %% Option 1 (Smallest delta from old text): > If the MPI implementation is not able to create a new communicator because a > valid \mpiarg{my\_num\_ep} argument given by any process, this function will > return \error{MPI\_ERR\_ENDPOINTS} at all processes. > > Opinions or suggestions for improvement? > > I have attached an updated review document (with option 2 above, but this > is still open for discussion). Please review page 245, lines 7-15. I > removed the use of "endpoint" and replaced it with "rank". I also replaced > instances where we talk about "rank" in the parent communicator with > "process". I think it's clearer now; interested to hear feedback. > > Cheers, > ~Jim. > > > On Mon, Jun 30, 2014 at 11:43 AM, Jim Dinan <james.dinan(a)gmail.com> wrote: > >> I can attend, but will be 10 minutes late. Attached is an updated copy of >> the endpoints proposal with feedback from the Chicago meeting. Let's >> review these changes, and we also have an item to discuss from that meeting >> with regard to how errors are returned from MPI_Comm_create_endpoints. >> >> >> On Sun, Jun 29, 2014 at 2:40 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >> >>> All, >>> >>> This is a reminder that we'll have our hybrid WG telecon tomorrow (06/30) >>> at 11am central time. >>> >>> I've made the promised corrections to ticket 411 and uploaded a new draft. >>> >>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/411 >>> >>> We can discuss this tomorrow, together with the remaining tickets. >>> >>> Thanks, >>> >>> --- Pavan >>> >>> _______________________________________________ >>> mpiwg-hybridpm mailing list >>> mpiwg-hybridpm(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm >>> >> > > > _______________________________________________ > mpiwg-hybridpm mailing list > mpiwg-hybridpm(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm -- Dan Holmes Applications Consultant in HPC Research EPCC, The University of Edinburgh James Clerk Maxwell Building The Kings Buildings Mayfield Road Edinburgh, UK EH9 3JZ T: +44(0)131 651 3465 E: dholmes(a)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.

1 0

Re: [mpiwg-hybridpm] Hybrid WG telecon tomorrow
by Balaji, Pavan 30 Jun '14

30 Jun '14

Here’s a draft of the minutes: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Hybrid/notes-2014-06-… Jim: can you add notes for the endpoints discussion? — Pavan On Jun 29, 2014, at 1:40 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: > All, > > This is a reminder that we’ll have our hybrid WG telecon tomorrow (06/30) at 11am central time. > > I’ve made the promised corrections to ticket 411 and uploaded a new draft. > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/411 > > We can discuss this tomorrow, together with the remaining tickets. > > Thanks, > > — Pavan > > _______________________________________________ > mpiwg-hybridpm mailing list > mpiwg-hybridpm(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm

1 0

Re: [mpiwg-hybridpm] Hybrid WG telecon tomorrow
by Jim Dinan 30 Jun '14

30 Jun '14

All, Below are two options for the endpoints error text: %% OLD: If the MPI implementation is not able to create a new communicator because of the \mpiarg{my\_num\_ep} argument given by any process, this function will return \error{MPI\_ERR\_ENDPOINTS}. %% Option 2 (Suggested by Pavan): If a process provides a valid \mpiarg{my\_num\_ep} argument, but the MPI implementation is not able to create a new communicator because of the \mpiarg{my\_num\_ep} argument at this process, this function will return \error{MPI\_ERR\_ENDPOINTS} at all processes. %% Option 1 (Smallest delta from old text): If the MPI implementation is not able to create a new communicator because a valid \mpiarg{my\_num\_ep} argument given by any process, this function will return \error{MPI\_ERR\_ENDPOINTS} at all processes. Opinions or suggestions for improvement? I have attached an updated review document (with option 2 above, but this is still open for discussion). Please review page 245, lines 7-15. I removed the use of "endpoint" and replaced it with "rank". I also replaced instances where we talk about "rank" in the parent communicator with "process". I think it's clearer now; interested to hear feedback. Cheers, ~Jim. On Mon, Jun 30, 2014 at 11:43 AM, Jim Dinan <james.dinan(a)gmail.com> wrote: > I can attend, but will be 10 minutes late. Attached is an updated copy of > the endpoints proposal with feedback from the Chicago meeting. Let's > review these changes, and we also have an item to discuss from that meeting > with regard to how errors are returned from MPI_Comm_create_endpoints. > > > On Sun, Jun 29, 2014 at 2:40 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: > >> All, >> >> This is a reminder that we’ll have our hybrid WG telecon tomorrow (06/30) >> at 11am central time. >> >> I’ve made the promised corrections to ticket 411 and uploaded a new draft. >> >> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/411 >> >> We can discuss this tomorrow, together with the remaining tickets. >> >> Thanks, >> >> — Pavan >> >> _______________________________________________ >> mpiwg-hybridpm mailing list >> mpiwg-hybridpm(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-hybridpm >> > >

1 0