January 2013 - mpiwg-rma - mailman3.cels.anl.gov

Re: [Mpi3-rma] Call for errata
by Jim Dinan 30 Jan '13

30 Jan '13

Hi Hubert, It's no bother; I appreciate your help in ensuring that we get this right. I didn't fully follow your description below (maybe this is just terminology). The semantics that we mean to convey are: * The origin data (specified by origin buffer parameters) must fit in the target buffer. * The target data (specified by target buffer parameters) must fit in the origin's result buffer. Cheers, ~Jim. On 1/30/13 11:26 AM, Hubert Ritzdorf wrote: > Hi Jim, > > this is really hard to understand from the description. > > Nevertheless, the target buffer must fit into the target window (such as in MPI_GET), > not the origin buffer. And the origin buffer must fit into the target buffer. > > Sorry to bother you > > Hubert > ________________________________________ > From: mpi3-rma-bounces(a)lists.mpi-forum.org [mpi3-rma-bounces(a)lists.mpi-forum.org] on behalf of Jim Dinan [dinan(a)mcs.anl.gov] > Sent: Wednesday, January 30, 2013 5:12 PM > To: mpi3-rma(a)lists.mpi-forum.org > Subject: Re: [Mpi3-rma] Call for errata > > Hi Hubert, > > For Get_accumulate, the origin buffer parameters specify how much data > is accumulated at the target, and the target buffer parameters specify > how much data will be received into the result buffer. These semantics > do not change, based on which operation is used. This is what we are > trying to clarify with the new text in #355. > > ~Jim. > > On 1/29/13 2:24 PM, Hubert Ritzdorf wrote: >> Hi Jim, >> >> you are right. Datatypes created by MPI_TYPE_CREATE_F90_{INTEGER,REAL,COMPLEX} >> are defined as predefined nevertheless they are handles. MPI_WCHAR was only a joke to >> a previous discussion. >> >> I think ticket 355 doesn't clarify this. It doesn't specify that target_count items of target_datatype >> are transferred if MPI_NO_OP is specified. It says only something about (minimal/maximal) size of buffers >> nothing about the items transferred and is independent of MPI_NO_OP. >> You could interpret it that always target_count items of target_datatype are returned to >> the result buffer independent on origin_count and origin datatype (even if op is not MPI_NO_OP). >> >> I think that it is much more clear for the reader if ticket 250 specifies: >> >> When MPI_NO_OP is specified as the operation, the origin buffer arguments are ignored >> and target_count elements of type target_datatype are returned from the buffer at offset target_disp >> to result buffer result_addr. >> >> Best regards >> >> Hubert >> >> ________________________________________ >> From: mpi3-rma-bounces(a)lists.mpi-forum.org [mpi3-rma-bounces(a)lists.mpi-forum.org] on behalf of Jim Dinan [dinan(a)mcs.anl.gov] >> Sent: Monday, January 28, 2013 11:51 PM >> To: mpi3-rma(a)lists.mpi-forum.org >> Subject: Re: [Mpi3-rma] Call for errata >> >> Hi Hubert, >> >> Please correct me if I'm wrong, but as far as I can tell, every type >> that is internal to the MPI implementation (including Fortran and pair >> types) are "predefined". >> >> The F90 types are described as predefined in the standard (pg. 617-618). >> >> MPI_WCHAR is also predefined (pg. 665). >> >> Tables 3.x say "predefined" in the table caption. >> >> This wording was copied from the original MPI_Accumulate text in MPI >> 2.2, so if predefined is not all-encompassing, we may not be able to fix >> this as an erratum. >> >> Re: Ticket 350 -- I think we fixed this with ticket 355. Could you take >> a look at that ticket and see if this clears up your concerns? >> >> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/355 >> >> Thanks for your detailed feedback! >> ~Jim. >> >> On 1/28/13 1:04 PM, Hubert Ritzdorf wrote: >>> Hi, >>> >>> Page 429, Line 41-42 specifies for MPI_Fetch_and_op: >>> >>> The datatype argument must be a predefined datatype. >>> >>> I think it should be: >>> >>> The datatype argument must be a predefined or MPI basic datatype (cf. Section 5.9.2 on page 176). >>> >>> Reasons: >>> >>> (*) This would be consistent to the reduce functions and MPI_Compare_and_swap >>> and would allow handles returned by MPI_TYPE_CREATE_F90_INTEGER, >>> MPI_TYPE_CREATE_F90_REAL, or MPI_TYPE_F90_COMPLEX. >>> (which are currently excluded since they are not predefined). >>> >>> (*) MPI_Compare_and_swap accepts handles created by >>> MPI_TYPE_CREATE_F90_INTEGER (they are contained in Fortran integer category). >>> >>> (*) This proposed change support also atomic gets of MPI_WCHAR. >>> >>> >>> Additionally, on Page 430, Line 39: >>> predefined datatypes >>> should be replaced by >>> basic datatypes >>> since Section 5.9.2 defines the MPI basic datatypes and not the predefined >>> datatypes (which are defined in Tables 3.x). >>> >>> Ticket 350 (MPI_NO_OP in new accumulate functions, origin buffer arguments are ignored) should also >>> state that the number of entries transferred is defined by target_count >>> >>> Hubert >>> >>> ________________________________________ >>> From: mpi3-rma-bounces(a)lists.mpi-forum.org [mpi3-rma-bounces(a)lists.mpi-forum.org] on behalf of Jim Dinan [dinan(a)mcs.anl.gov] >>> Sent: Monday, January 28, 2013 4:54 PM >>> To: MPI 3.0 Remote Memory Access working group >>> Subject: [Mpi3-rma] Call for errata >>> >>> Hi All, >>> >>> We are assembling the list of RMA errata to be voted on at the March >>> meeting. Currently, we have tickets #347, #348, #350, and #355 (I'm >>> working on official wording for these changes and will circulate it soon). >>> >>> Are there any other errata items that should be included on the agenda >>> for the upcoming meeting? >>> >>> Thanks, >>> ~Jim. >>> _______________________________________________ >>> mpi3-rma mailing list >>> mpi3-rma(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >>> >>> >>> Click https://www.mailcontrol.com/sr/cqZpjZJWCcHGX2PQPOmvUsQN7C0BBstkddyjT4P!KFPM… to report this email as spam. >>> >>> _______________________________________________ >>> mpi3-rma mailing list >>> mpi3-rma(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >>> >> _______________________________________________ >> mpi3-rma mailing list >> mpi3-rma(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >> >> _______________________________________________ >> mpi3-rma mailing list >> mpi3-rma(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >> > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >

1 0

Re: [Mpi3-rma] Call for errata
by Hubert Ritzdorf 30 Jan '13

30 Jan '13

Hi Jim, this is really hard to understand from the description. Nevertheless, the target buffer must fit into the target window (such as in MPI_GET), not the origin buffer. And the origin buffer must fit into the target buffer. Sorry to bother you Hubert ________________________________________ From: mpi3-rma-bounces(a)lists.mpi-forum.org [mpi3-rma-bounces(a)lists.mpi-forum.org] on behalf of Jim Dinan [dinan(a)mcs.anl.gov] Sent: Wednesday, January 30, 2013 5:12 PM To: mpi3-rma(a)lists.mpi-forum.org Subject: Re: [Mpi3-rma] Call for errata Hi Hubert, For Get_accumulate, the origin buffer parameters specify how much data is accumulated at the target, and the target buffer parameters specify how much data will be received into the result buffer. These semantics do not change, based on which operation is used. This is what we are trying to clarify with the new text in #355. ~Jim. On 1/29/13 2:24 PM, Hubert Ritzdorf wrote: > Hi Jim, > > you are right. Datatypes created by MPI_TYPE_CREATE_F90_{INTEGER,REAL,COMPLEX} > are defined as predefined nevertheless they are handles. MPI_WCHAR was only a joke to > a previous discussion. > > I think ticket 355 doesn't clarify this. It doesn't specify that target_count items of target_datatype > are transferred if MPI_NO_OP is specified. It says only something about (minimal/maximal) size of buffers > nothing about the items transferred and is independent of MPI_NO_OP. > You could interpret it that always target_count items of target_datatype are returned to > the result buffer independent on origin_count and origin datatype (even if op is not MPI_NO_OP). > > I think that it is much more clear for the reader if ticket 250 specifies: > > When MPI_NO_OP is specified as the operation, the origin buffer arguments are ignored > and target_count elements of type target_datatype are returned from the buffer at offset target_disp > to result buffer result_addr. > > Best regards > > Hubert > > ________________________________________ > From: mpi3-rma-bounces(a)lists.mpi-forum.org [mpi3-rma-bounces(a)lists.mpi-forum.org] on behalf of Jim Dinan [dinan(a)mcs.anl.gov] > Sent: Monday, January 28, 2013 11:51 PM > To: mpi3-rma(a)lists.mpi-forum.org > Subject: Re: [Mpi3-rma] Call for errata > > Hi Hubert, > > Please correct me if I'm wrong, but as far as I can tell, every type > that is internal to the MPI implementation (including Fortran and pair > types) are "predefined". > > The F90 types are described as predefined in the standard (pg. 617-618). > > MPI_WCHAR is also predefined (pg. 665). > > Tables 3.x say "predefined" in the table caption. > > This wording was copied from the original MPI_Accumulate text in MPI > 2.2, so if predefined is not all-encompassing, we may not be able to fix > this as an erratum. > > Re: Ticket 350 -- I think we fixed this with ticket 355. Could you take > a look at that ticket and see if this clears up your concerns? > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/355 > > Thanks for your detailed feedback! > ~Jim. > > On 1/28/13 1:04 PM, Hubert Ritzdorf wrote: >> Hi, >> >> Page 429, Line 41-42 specifies for MPI_Fetch_and_op: >> >> The datatype argument must be a predefined datatype. >> >> I think it should be: >> >> The datatype argument must be a predefined or MPI basic datatype (cf. Section 5.9.2 on page 176). >> >> Reasons: >> >> (*) This would be consistent to the reduce functions and MPI_Compare_and_swap >> and would allow handles returned by MPI_TYPE_CREATE_F90_INTEGER, >> MPI_TYPE_CREATE_F90_REAL, or MPI_TYPE_F90_COMPLEX. >> (which are currently excluded since they are not predefined). >> >> (*) MPI_Compare_and_swap accepts handles created by >> MPI_TYPE_CREATE_F90_INTEGER (they are contained in Fortran integer category). >> >> (*) This proposed change support also atomic gets of MPI_WCHAR. >> >> >> Additionally, on Page 430, Line 39: >> predefined datatypes >> should be replaced by >> basic datatypes >> since Section 5.9.2 defines the MPI basic datatypes and not the predefined >> datatypes (which are defined in Tables 3.x). >> >> Ticket 350 (MPI_NO_OP in new accumulate functions, origin buffer arguments are ignored) should also >> state that the number of entries transferred is defined by target_count >> >> Hubert >> >> ________________________________________ >> From: mpi3-rma-bounces(a)lists.mpi-forum.org [mpi3-rma-bounces(a)lists.mpi-forum.org] on behalf of Jim Dinan [dinan(a)mcs.anl.gov] >> Sent: Monday, January 28, 2013 4:54 PM >> To: MPI 3.0 Remote Memory Access working group >> Subject: [Mpi3-rma] Call for errata >> >> Hi All, >> >> We are assembling the list of RMA errata to be voted on at the March >> meeting. Currently, we have tickets #347, #348, #350, and #355 (I'm >> working on official wording for these changes and will circulate it soon). >> >> Are there any other errata items that should be included on the agenda >> for the upcoming meeting? >> >> Thanks, >> ~Jim. >> _______________________________________________ >> mpi3-rma mailing list >> mpi3-rma(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >> >> >> Click https://www.mailcontrol.com/sr/cqZpjZJWCcHGX2PQPOmvUsQN7C0BBstkddyjT4P!KFPM… to report this email as spam. >> >> _______________________________________________ >> mpi3-rma mailing list >> mpi3-rma(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >> > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > _______________________________________________ mpi3-rma mailing list mpi3-rma(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma

1 0

Re: [Mpi3-rma] Call for errata
by Jim Dinan 30 Jan '13

30 Jan '13

Hi Hubert, Your example below is an erroneous call to MPI_Get_accumulate. This operation was not intended to change its buffer semantics based on the MPI_Op argument. It should always follow the semantic in ticket #355. ~Jim. On 1/30/13 8:19 AM, Hubert Ritzdorf wrote: > Hi Jim > > I think that the ticket 355 is not correct: > > (*) The original text was correct: > The target buffer must fit into the target window. > > (*) The second part of ticket 355 is not correct. > A call > > MPI_Get_accumulate (origin_addr, 1, MPI_INT, > result_addr, 1, MPI_INT, > target_rank, target_disp, 1000, MPI_INT, > MPI_SUM, win) > > would violate > > and the *target* buffer must fit in the result buffer without truncation. > > This is part of 2nd part of Ticket 355. > The size of the target buffer is 1000 int's, the origin and result buffer 1 int. > > My proposal for the text would be: > > The target buffer must fit in the target window or in attached memory in a dynamic window. > target_datatype and result_datatype must not specify overlapping entries. > The origin buffer must fit in target buffer and result buffer without truncation, if op is not equal to MPI_NO_OP.. > Otherwise, the target buffer must fit in the result buffer without truncation. > > Hubert. > ________________________________________ > From: mpi3-rma-bounces(a)lists.mpi-forum.org [mpi3-rma-bounces(a)lists.mpi-forum.org] on behalf of Hubert Ritzdorf [Hubert.Ritzdorf(a)emea.nec.com] > Sent: Tuesday, January 29, 2013 9:24 PM > To: MPI 3.0 Remote Memory Access working group > Subject: Re: [Mpi3-rma] Call for errata > > Hi Jim, > > you are right. Datatypes created by MPI_TYPE_CREATE_F90_{INTEGER,REAL,COMPLEX} > are defined as predefined nevertheless they are handles. MPI_WCHAR was only a joke to > a previous discussion. > > I think ticket 355 doesn't clarify this. It doesn't specify that target_count items of target_datatype > are transferred if MPI_NO_OP is specified. It says only something about (minimal/maximal) size of buffers > nothing about the items transferred and is independent of MPI_NO_OP. > You could interpret it that always target_count items of target_datatype are returned to > the result buffer independent on origin_count and origin datatype (even if op is not MPI_NO_OP). > > I think that it is much more clear for the reader if ticket 250 specifies: > > When MPI_NO_OP is specified as the operation, the origin buffer arguments are ignored > and target_count elements of type target_datatype are returned from the buffer at offset target_disp > to result buffer result_addr. > > Best regards > > Hubert > > ________________________________________ > From: mpi3-rma-bounces(a)lists.mpi-forum.org [mpi3-rma-bounces(a)lists.mpi-forum.org] on behalf of Jim Dinan [dinan(a)mcs.anl.gov] > Sent: Monday, January 28, 2013 11:51 PM > To: mpi3-rma(a)lists.mpi-forum.org > Subject: Re: [Mpi3-rma] Call for errata > > Hi Hubert, > > Please correct me if I'm wrong, but as far as I can tell, every type > that is internal to the MPI implementation (including Fortran and pair > types) are "predefined". > > The F90 types are described as predefined in the standard (pg. 617-618). > > MPI_WCHAR is also predefined (pg. 665). > > Tables 3.x say "predefined" in the table caption. > > This wording was copied from the original MPI_Accumulate text in MPI > 2.2, so if predefined is not all-encompassing, we may not be able to fix > this as an erratum. > > Re: Ticket 350 -- I think we fixed this with ticket 355. Could you take > a look at that ticket and see if this clears up your concerns? > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/355 > > Thanks for your detailed feedback! > ~Jim. > > On 1/28/13 1:04 PM, Hubert Ritzdorf wrote: >> Hi, >> >> Page 429, Line 41-42 specifies for MPI_Fetch_and_op: >> >> The datatype argument must be a predefined datatype. >> >> I think it should be: >> >> The datatype argument must be a predefined or MPI basic datatype (cf. Section 5.9.2 on page 176). >> >> Reasons: >> >> (*) This would be consistent to the reduce functions and MPI_Compare_and_swap >> and would allow handles returned by MPI_TYPE_CREATE_F90_INTEGER, >> MPI_TYPE_CREATE_F90_REAL, or MPI_TYPE_F90_COMPLEX. >> (which are currently excluded since they are not predefined). >> >> (*) MPI_Compare_and_swap accepts handles created by >> MPI_TYPE_CREATE_F90_INTEGER (they are contained in Fortran integer category). >> >> (*) This proposed change support also atomic gets of MPI_WCHAR. >> >> >> Additionally, on Page 430, Line 39: >> predefined datatypes >> should be replaced by >> basic datatypes >> since Section 5.9.2 defines the MPI basic datatypes and not the predefined >> datatypes (which are defined in Tables 3.x). >> >> Ticket 350 (MPI_NO_OP in new accumulate functions, origin buffer arguments are ignored) should also >> state that the number of entries transferred is defined by target_count >> >> Hubert >> >> ________________________________________ >> From: mpi3-rma-bounces(a)lists.mpi-forum.org [mpi3-rma-bounces(a)lists.mpi-forum.org] on behalf of Jim Dinan [dinan(a)mcs.anl.gov] >> Sent: Monday, January 28, 2013 4:54 PM >> To: MPI 3.0 Remote Memory Access working group >> Subject: [Mpi3-rma] Call for errata >> >> Hi All, >> >> We are assembling the list of RMA errata to be voted on at the March >> meeting. Currently, we have tickets #347, #348, #350, and #355 (I'm >> working on official wording for these changes and will circulate it soon). >> >> Are there any other errata items that should be included on the agenda >> for the upcoming meeting? >> >> Thanks, >> ~Jim. >> _______________________________________________ >> mpi3-rma mailing list >> mpi3-rma(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >> >> >> Click https://www.mailcontrol.com/sr/cqZpjZJWCcHGX2PQPOmvUsQN7C0BBstkddyjT4P!KFPM… to report this email as spam. >> >> _______________________________________________ >> mpi3-rma mailing list >> mpi3-rma(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >> > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >

1 0

Re: [Mpi3-rma] Call for errata
by Jim Dinan 30 Jan '13

30 Jan '13

Hi Hubert, For Get_accumulate, the origin buffer parameters specify how much data is accumulated at the target, and the target buffer parameters specify how much data will be received into the result buffer. These semantics do not change, based on which operation is used. This is what we are trying to clarify with the new text in #355. ~Jim. On 1/29/13 2:24 PM, Hubert Ritzdorf wrote: > Hi Jim, > > you are right. Datatypes created by MPI_TYPE_CREATE_F90_{INTEGER,REAL,COMPLEX} > are defined as predefined nevertheless they are handles. MPI_WCHAR was only a joke to > a previous discussion. > > I think ticket 355 doesn't clarify this. It doesn't specify that target_count items of target_datatype > are transferred if MPI_NO_OP is specified. It says only something about (minimal/maximal) size of buffers > nothing about the items transferred and is independent of MPI_NO_OP. > You could interpret it that always target_count items of target_datatype are returned to > the result buffer independent on origin_count and origin datatype (even if op is not MPI_NO_OP). > > I think that it is much more clear for the reader if ticket 250 specifies: > > When MPI_NO_OP is specified as the operation, the origin buffer arguments are ignored > and target_count elements of type target_datatype are returned from the buffer at offset target_disp > to result buffer result_addr. > > Best regards > > Hubert > > ________________________________________ > From: mpi3-rma-bounces(a)lists.mpi-forum.org [mpi3-rma-bounces(a)lists.mpi-forum.org] on behalf of Jim Dinan [dinan(a)mcs.anl.gov] > Sent: Monday, January 28, 2013 11:51 PM > To: mpi3-rma(a)lists.mpi-forum.org > Subject: Re: [Mpi3-rma] Call for errata > > Hi Hubert, > > Please correct me if I'm wrong, but as far as I can tell, every type > that is internal to the MPI implementation (including Fortran and pair > types) are "predefined". > > The F90 types are described as predefined in the standard (pg. 617-618). > > MPI_WCHAR is also predefined (pg. 665). > > Tables 3.x say "predefined" in the table caption. > > This wording was copied from the original MPI_Accumulate text in MPI > 2.2, so if predefined is not all-encompassing, we may not be able to fix > this as an erratum. > > Re: Ticket 350 -- I think we fixed this with ticket 355. Could you take > a look at that ticket and see if this clears up your concerns? > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/355 > > Thanks for your detailed feedback! > ~Jim. > > On 1/28/13 1:04 PM, Hubert Ritzdorf wrote: >> Hi, >> >> Page 429, Line 41-42 specifies for MPI_Fetch_and_op: >> >> The datatype argument must be a predefined datatype. >> >> I think it should be: >> >> The datatype argument must be a predefined or MPI basic datatype (cf. Section 5.9.2 on page 176). >> >> Reasons: >> >> (*) This would be consistent to the reduce functions and MPI_Compare_and_swap >> and would allow handles returned by MPI_TYPE_CREATE_F90_INTEGER, >> MPI_TYPE_CREATE_F90_REAL, or MPI_TYPE_F90_COMPLEX. >> (which are currently excluded since they are not predefined). >> >> (*) MPI_Compare_and_swap accepts handles created by >> MPI_TYPE_CREATE_F90_INTEGER (they are contained in Fortran integer category). >> >> (*) This proposed change support also atomic gets of MPI_WCHAR. >> >> >> Additionally, on Page 430, Line 39: >> predefined datatypes >> should be replaced by >> basic datatypes >> since Section 5.9.2 defines the MPI basic datatypes and not the predefined >> datatypes (which are defined in Tables 3.x). >> >> Ticket 350 (MPI_NO_OP in new accumulate functions, origin buffer arguments are ignored) should also >> state that the number of entries transferred is defined by target_count >> >> Hubert >> >> ________________________________________ >> From: mpi3-rma-bounces(a)lists.mpi-forum.org [mpi3-rma-bounces(a)lists.mpi-forum.org] on behalf of Jim Dinan [dinan(a)mcs.anl.gov] >> Sent: Monday, January 28, 2013 4:54 PM >> To: MPI 3.0 Remote Memory Access working group >> Subject: [Mpi3-rma] Call for errata >> >> Hi All, >> >> We are assembling the list of RMA errata to be voted on at the March >> meeting. Currently, we have tickets #347, #348, #350, and #355 (I'm >> working on official wording for these changes and will circulate it soon). >> >> Are there any other errata items that should be included on the agenda >> for the upcoming meeting? >> >> Thanks, >> ~Jim. >> _______________________________________________ >> mpi3-rma mailing list >> mpi3-rma(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >> >> >> Click https://www.mailcontrol.com/sr/cqZpjZJWCcHGX2PQPOmvUsQN7C0BBstkddyjT4P!KFPM… to report this email as spam. >> >> _______________________________________________ >> mpi3-rma mailing list >> mpi3-rma(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >> > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >

1 0

Re: [Mpi3-rma] Call for errata
by Hubert Ritzdorf 30 Jan '13

30 Jan '13

Hi Jim I think that the ticket 355 is not correct: (*) The original text was correct: The target buffer must fit into the target window. (*) The second part of ticket 355 is not correct. A call MPI_Get_accumulate (origin_addr, 1, MPI_INT, result_addr, 1, MPI_INT, target_rank, target_disp, 1000, MPI_INT, MPI_SUM, win) would violate and the *target* buffer must fit in the result buffer without truncation. This is part of 2nd part of Ticket 355. The size of the target buffer is 1000 int's, the origin and result buffer 1 int. My proposal for the text would be: The target buffer must fit in the target window or in attached memory in a dynamic window. target_datatype and result_datatype must not specify overlapping entries. The origin buffer must fit in target buffer and result buffer without truncation, if op is not equal to MPI_NO_OP.. Otherwise, the target buffer must fit in the result buffer without truncation. Hubert. ________________________________________ From: mpi3-rma-bounces(a)lists.mpi-forum.org [mpi3-rma-bounces(a)lists.mpi-forum.org] on behalf of Hubert Ritzdorf [Hubert.Ritzdorf(a)emea.nec.com] Sent: Tuesday, January 29, 2013 9:24 PM To: MPI 3.0 Remote Memory Access working group Subject: Re: [Mpi3-rma] Call for errata Hi Jim, you are right. Datatypes created by MPI_TYPE_CREATE_F90_{INTEGER,REAL,COMPLEX} are defined as predefined nevertheless they are handles. MPI_WCHAR was only a joke to a previous discussion. I think ticket 355 doesn't clarify this. It doesn't specify that target_count items of target_datatype are transferred if MPI_NO_OP is specified. It says only something about (minimal/maximal) size of buffers nothing about the items transferred and is independent of MPI_NO_OP. You could interpret it that always target_count items of target_datatype are returned to the result buffer independent on origin_count and origin datatype (even if op is not MPI_NO_OP). I think that it is much more clear for the reader if ticket 250 specifies: When MPI_NO_OP is specified as the operation, the origin buffer arguments are ignored and target_count elements of type target_datatype are returned from the buffer at offset target_disp to result buffer result_addr. Best regards Hubert ________________________________________ From: mpi3-rma-bounces(a)lists.mpi-forum.org [mpi3-rma-bounces(a)lists.mpi-forum.org] on behalf of Jim Dinan [dinan(a)mcs.anl.gov] Sent: Monday, January 28, 2013 11:51 PM To: mpi3-rma(a)lists.mpi-forum.org Subject: Re: [Mpi3-rma] Call for errata Hi Hubert, Please correct me if I'm wrong, but as far as I can tell, every type that is internal to the MPI implementation (including Fortran and pair types) are "predefined". The F90 types are described as predefined in the standard (pg. 617-618). MPI_WCHAR is also predefined (pg. 665). Tables 3.x say "predefined" in the table caption. This wording was copied from the original MPI_Accumulate text in MPI 2.2, so if predefined is not all-encompassing, we may not be able to fix this as an erratum. Re: Ticket 350 -- I think we fixed this with ticket 355. Could you take a look at that ticket and see if this clears up your concerns? https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/355 Thanks for your detailed feedback! ~Jim. On 1/28/13 1:04 PM, Hubert Ritzdorf wrote: > Hi, > > Page 429, Line 41-42 specifies for MPI_Fetch_and_op: > > The datatype argument must be a predefined datatype. > > I think it should be: > > The datatype argument must be a predefined or MPI basic datatype (cf. Section 5.9.2 on page 176). > > Reasons: > > (*) This would be consistent to the reduce functions and MPI_Compare_and_swap > and would allow handles returned by MPI_TYPE_CREATE_F90_INTEGER, > MPI_TYPE_CREATE_F90_REAL, or MPI_TYPE_F90_COMPLEX. > (which are currently excluded since they are not predefined). > > (*) MPI_Compare_and_swap accepts handles created by > MPI_TYPE_CREATE_F90_INTEGER (they are contained in Fortran integer category). > > (*) This proposed change support also atomic gets of MPI_WCHAR. > > > Additionally, on Page 430, Line 39: > predefined datatypes > should be replaced by > basic datatypes > since Section 5.9.2 defines the MPI basic datatypes and not the predefined > datatypes (which are defined in Tables 3.x). > > Ticket 350 (MPI_NO_OP in new accumulate functions, origin buffer arguments are ignored) should also > state that the number of entries transferred is defined by target_count > > Hubert > > ________________________________________ > From: mpi3-rma-bounces(a)lists.mpi-forum.org [mpi3-rma-bounces(a)lists.mpi-forum.org] on behalf of Jim Dinan [dinan(a)mcs.anl.gov] > Sent: Monday, January 28, 2013 4:54 PM > To: MPI 3.0 Remote Memory Access working group > Subject: [Mpi3-rma] Call for errata > > Hi All, > > We are assembling the list of RMA errata to be voted on at the March > meeting. Currently, we have tickets #347, #348, #350, and #355 (I'm > working on official wording for these changes and will circulate it soon). > > Are there any other errata items that should be included on the agenda > for the upcoming meeting? > > Thanks, > ~Jim. > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > > > Click https://www.mailcontrol.com/sr/cqZpjZJWCcHGX2PQPOmvUsQN7C0BBstkddyjT4P!KFPM… to report this email as spam. > > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > _______________________________________________ mpi3-rma mailing list mpi3-rma(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma _______________________________________________ mpi3-rma mailing list mpi3-rma(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma

1 0

Re: [Mpi3-rma] [EXTERNAL] Re: Call for errata
by Rolf Rabenseifner 30 Jan '13

30 Jan '13

Brian, in principle, you are right. Everybody can chose the title text as he/she wants. I only take it as a useful hint. And each errata proposer can do this additional hint or not. I'm not sure whether you scanned all current tickets to detect, which one may be an errata, and I talked to the ticket authors. I didn't want that errata are something of the last minutes before MPI-next comes out. Please feel free to write your title as you want when you have to propose an erratum. Best regards Rolf ----- Original Message ----- > From: "Brian W Barrett" <bwbarre(a)sandia.gov> > To: "MPI 3.0 Remote Memory Access working group" <mpi3-rma(a)lists.mpi-forum.org> > Sent: Tuesday, January 29, 2013 10:07:45 PM > Subject: Re: [Mpi3-rma] [EXTERNAL] Re: Call for errata > Rolf, > > On 1/29/13 3:34 AM, "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> wrote: > > >For MPI-next, errata should be noticed through two marks: > > <snip> > > >I hope that this will work fine for the future and > >with a minimum of overhead. > > Where did this proposal come from? It certainly wasn't from the main > Forum body or from the architecture review board. I doubt it came from > the steering committee as a whole. There's absolutely no reason to use > prefixes in the title rather than versions (one now exists for MPI-3.0 > errata). We should use the tools to their full effect, rather than > doing > error-prone things like prefixes. And we should all agree on policies > and > procedures, rather than one person coming up with something and > stating it > as fact. > > Brian > > -- > Brian W. Barrett > Scalable System Software Group > Sandia National Laboratories > > > > > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)

1 0

Re: [Mpi3-rma] [EXTERNAL] Re: Call for errata
by Barrett, Brian W 29 Jan '13

29 Jan '13

Rolf, On 1/29/13 3:34 AM, "Rolf Rabenseifner" <rabenseifner(a)hlrs.de> wrote: >For MPI-next, errata should be noticed through two marks: <snip> >I hope that this will work fine for the future and >with a minimum of overhead. Where did this proposal come from? It certainly wasn't from the main Forum body or from the architecture review board. I doubt it came from the steering committee as a whole. There's absolutely no reason to use prefixes in the title rather than versions (one now exists for MPI-3.0 errata). We should use the tools to their full effect, rather than doing error-prone things like prefixes. And we should all agree on policies and procedures, rather than one person coming up with something and stating it as fact. Brian -- Brian W. Barrett Scalable System Software Group Sandia National Laboratories

1 0

Re: [Mpi3-rma] Call for errata
by Hubert Ritzdorf 29 Jan '13

29 Jan '13

Hi Jim, you are right. Datatypes created by MPI_TYPE_CREATE_F90_{INTEGER,REAL,COMPLEX} are defined as predefined nevertheless they are handles. MPI_WCHAR was only a joke to a previous discussion. I think ticket 355 doesn't clarify this. It doesn't specify that target_count items of target_datatype are transferred if MPI_NO_OP is specified. It says only something about (minimal/maximal) size of buffers nothing about the items transferred and is independent of MPI_NO_OP. You could interpret it that always target_count items of target_datatype are returned to the result buffer independent on origin_count and origin datatype (even if op is not MPI_NO_OP). I think that it is much more clear for the reader if ticket 250 specifies: When MPI_NO_OP is specified as the operation, the origin buffer arguments are ignored and target_count elements of type target_datatype are returned from the buffer at offset target_disp to result buffer result_addr. Best regards Hubert ________________________________________ From: mpi3-rma-bounces(a)lists.mpi-forum.org [mpi3-rma-bounces(a)lists.mpi-forum.org] on behalf of Jim Dinan [dinan(a)mcs.anl.gov] Sent: Monday, January 28, 2013 11:51 PM To: mpi3-rma(a)lists.mpi-forum.org Subject: Re: [Mpi3-rma] Call for errata Hi Hubert, Please correct me if I'm wrong, but as far as I can tell, every type that is internal to the MPI implementation (including Fortran and pair types) are "predefined". The F90 types are described as predefined in the standard (pg. 617-618). MPI_WCHAR is also predefined (pg. 665). Tables 3.x say "predefined" in the table caption. This wording was copied from the original MPI_Accumulate text in MPI 2.2, so if predefined is not all-encompassing, we may not be able to fix this as an erratum. Re: Ticket 350 -- I think we fixed this with ticket 355. Could you take a look at that ticket and see if this clears up your concerns? https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/355 Thanks for your detailed feedback! ~Jim. On 1/28/13 1:04 PM, Hubert Ritzdorf wrote: > Hi, > > Page 429, Line 41-42 specifies for MPI_Fetch_and_op: > > The datatype argument must be a predefined datatype. > > I think it should be: > > The datatype argument must be a predefined or MPI basic datatype (cf. Section 5.9.2 on page 176). > > Reasons: > > (*) This would be consistent to the reduce functions and MPI_Compare_and_swap > and would allow handles returned by MPI_TYPE_CREATE_F90_INTEGER, > MPI_TYPE_CREATE_F90_REAL, or MPI_TYPE_F90_COMPLEX. > (which are currently excluded since they are not predefined). > > (*) MPI_Compare_and_swap accepts handles created by > MPI_TYPE_CREATE_F90_INTEGER (they are contained in Fortran integer category). > > (*) This proposed change support also atomic gets of MPI_WCHAR. > > > Additionally, on Page 430, Line 39: > predefined datatypes > should be replaced by > basic datatypes > since Section 5.9.2 defines the MPI basic datatypes and not the predefined > datatypes (which are defined in Tables 3.x). > > Ticket 350 (MPI_NO_OP in new accumulate functions, origin buffer arguments are ignored) should also > state that the number of entries transferred is defined by target_count > > Hubert > > ________________________________________ > From: mpi3-rma-bounces(a)lists.mpi-forum.org [mpi3-rma-bounces(a)lists.mpi-forum.org] on behalf of Jim Dinan [dinan(a)mcs.anl.gov] > Sent: Monday, January 28, 2013 4:54 PM > To: MPI 3.0 Remote Memory Access working group > Subject: [Mpi3-rma] Call for errata > > Hi All, > > We are assembling the list of RMA errata to be voted on at the March > meeting. Currently, we have tickets #347, #348, #350, and #355 (I'm > working on official wording for these changes and will circulate it soon). > > Are there any other errata items that should be included on the agenda > for the upcoming meeting? > > Thanks, > ~Jim. > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > > > Click https://www.mailcontrol.com/sr/cqZpjZJWCcHGX2PQPOmvUsQN7C0BBstkddyjT4P!KFPM… to report this email as spam. > > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > _______________________________________________ mpi3-rma mailing list mpi3-rma(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma

1 0

Re: [Mpi3-rma] [EXTERNAL] Re: Call for errata
by Rolf Rabenseifner 29 Jan '13

29 Jan '13

For MPI-next, errata should be noticed through two marks: - The ticket type is "Correction to the standard (for upcoming release + errata)" (this is the selector), and - the title of the ticket starts with "MPI-3.0 Errata:" (this is only for better visibility, hopefully not to much overhead) E-mails are necessary only when a ticket has to go to the agenda of a forum meeting (independent on whether it is errata or not). Compared to MPI-3.0, we changed this errata-handling because - all errata tickets are at the same time full MPI-next tickets, and - errata should be filed only for corrections, and not for the other types ("Trivial text changes", "Text (only) changes", "new routine(s)", "enhancement to the standard"). All MPI-3.0 errata are visible through https://svn.mpi-forum.org/trac/mpi-forum-web/query?status=accepted&status=a… I hope that this will work fine for the future and with a minimum of overhead. Best regards Rolf ----- Original Message ----- > From: "Brian W Barrett" <bwbarre(a)sandia.gov> > To: "MPI 3.0 Remote Memory Access working group" <mpi3-rma(a)lists.mpi-forum.org> > Sent: Monday, January 28, 2013 10:37:15 PM > Subject: Re: [Mpi3-rma] [EXTERNAL] Re: Call for errata > I'm well aware. I was mostly suggesting that we not do something > that's a > total waste because Rolf suggested it. If the right thing is to add > the > Version, sending an e-mail to Jeff Squyres isn't that hard. Doing > silly > things to work around such an e-mail is, well, silly. > > Brian > > On 1/28/13 2:30 PM, "Jeff Hammond" <jhammond(a)alcf.anl.gov> wrote: > > >There is a reason and it is that there is no option for "MPI 3.0 > >Errata" in the drop-down "Version" box. Obviously this is a fixable > >problem but outside the scope of this WG. > > > >Jeff > > > >On Tue, Jan 29, 2013 at 6:26 AM, Barrett, Brian W > ><bwbarre(a)sandia.gov> > >wrote: > >> Rolf might like that, but there's really no reason for the title to > >> include MPI-3.0 errata. If we want another selector, that makes > >> sense, > >> but having it in the title just burns good screen real estateŠ > >> > >> Brian > >> > >> On 1/28/13 2:23 PM, "Jim Dinan" <dinan(a)mcs.anl.gov> wrote: > >> > >>>Hi Pavan, > >>> > >>>Could you please log these as tickets, so we don't lose any items. > >>>Please include the exact change, if it's ready. Also, Rolf would > >>>like > >>>us to use the the following formatting for title/ticket type: > >>> > >>>Title: MPI-3.0 errata: xxxxxxxxxxx > >>>Type: Correction to standard (for upcoming release + errata) > >>> > >>>Thanks, > >>> ~Jim. > >>> > >>>On 1/28/13 2:33 PM, Pavan Balaji wrote: > >>>> Jim, > >>>> > >>>> We talked about a few things in the last Forum. Slides are online > >>>> on > >>>> the Forum page. I also sent an email about it after the Forum; I > >>>> can > >>>> try to dig it up if you can't find it. > >>>> > >>>> -- Pavan > >>>> > >>>> On 01/28/2013 09:54 AM US Central Time, Jim Dinan wrote: > >>>>> Hi All, > >>>>> > >>>>> We are assembling the list of RMA errata to be voted on at the > >>>>> March > >>>>> meeting. Currently, we have tickets #347, #348, #350, and #355 > >>>>> (I'm > >>>>> working on official wording for these changes and will circulate > >>>>> it > >>>>>soon). > >>>>> > >>>>> Are there any other errata items that should be included on the > >>>>>agenda > >>>>> for the upcoming meeting? > >>>>> > >>>>> Thanks, > >>>>> ~Jim. > >>>>> _______________________________________________ > >>>>> mpi3-rma mailing list > >>>>> mpi3-rma(a)lists.mpi-forum.org > >>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > >>>> > >>>_______________________________________________ > >>>mpi3-rma mailing list > >>>mpi3-rma(a)lists.mpi-forum.org > >>>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > >>> > >>> > >> > >> > >> -- > >> Brian W. Barrett > >> Scalable System Software Group > >> Sandia National Laboratories > >> > >> > >> > >> > >> > >> _______________________________________________ > >> mpi3-rma mailing list > >> mpi3-rma(a)lists.mpi-forum.org > >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > > > > > > > >-- > >Jeff Hammond > >Argonne Leadership Computing Facility > >University of Chicago Computation Institute > >jhammond(a)alcf.anl.gov / (630) 252-5381 > >http://www.linkedin.com/in/jeffhammond > >https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond > > > > > -- > Brian W. Barrett > Scalable System Software Group > Sandia National Laboratories > > > > > > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307)

1 0

Re: [Mpi3-rma] Call for errata
by Jim Dinan 28 Jan '13

28 Jan '13

Hi Hubert, Please correct me if I'm wrong, but as far as I can tell, every type that is internal to the MPI implementation (including Fortran and pair types) are "predefined". The F90 types are described as predefined in the standard (pg. 617-618). MPI_WCHAR is also predefined (pg. 665). Tables 3.x say "predefined" in the table caption. This wording was copied from the original MPI_Accumulate text in MPI 2.2, so if predefined is not all-encompassing, we may not be able to fix this as an erratum. Re: Ticket 350 -- I think we fixed this with ticket 355. Could you take a look at that ticket and see if this clears up your concerns? https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/355 Thanks for your detailed feedback! ~Jim. On 1/28/13 1:04 PM, Hubert Ritzdorf wrote: > Hi, > > Page 429, Line 41-42 specifies for MPI_Fetch_and_op: > > The datatype argument must be a predefined datatype. > > I think it should be: > > The datatype argument must be a predefined or MPI basic datatype (cf. Section 5.9.2 on page 176). > > Reasons: > > (*) This would be consistent to the reduce functions and MPI_Compare_and_swap > and would allow handles returned by MPI_TYPE_CREATE_F90_INTEGER, > MPI_TYPE_CREATE_F90_REAL, or MPI_TYPE_F90_COMPLEX. > (which are currently excluded since they are not predefined). > > (*) MPI_Compare_and_swap accepts handles created by > MPI_TYPE_CREATE_F90_INTEGER (they are contained in Fortran integer category). > > (*) This proposed change support also atomic gets of MPI_WCHAR. > > > Additionally, on Page 430, Line 39: > predefined datatypes > should be replaced by > basic datatypes > since Section 5.9.2 defines the MPI basic datatypes and not the predefined > datatypes (which are defined in Tables 3.x). > > Ticket 350 (MPI_NO_OP in new accumulate functions, origin buffer arguments are ignored) should also > state that the number of entries transferred is defined by target_count > > Hubert > > ________________________________________ > From: mpi3-rma-bounces(a)lists.mpi-forum.org [mpi3-rma-bounces(a)lists.mpi-forum.org] on behalf of Jim Dinan [dinan(a)mcs.anl.gov] > Sent: Monday, January 28, 2013 4:54 PM > To: MPI 3.0 Remote Memory Access working group > Subject: [Mpi3-rma] Call for errata > > Hi All, > > We are assembling the list of RMA errata to be voted on at the March > meeting. Currently, we have tickets #347, #348, #350, and #355 (I'm > working on official wording for these changes and will circulate it soon). > > Are there any other errata items that should be included on the agenda > for the upcoming meeting? > > Thanks, > ~Jim. > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > > > Click https://www.mailcontrol.com/sr/cqZpjZJWCcHGX2PQPOmvUsQN7C0BBstkddyjT4P!KFPM… to report this email as spam. > > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >

1 0