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

Re: [Mpi3-rma] Call for errata
by Jim Dinan 25 Feb '13

25 Feb '13

Last call -- if there are any additional errata items from the RMA working group, please send them out ASAP. RMA WG members -- please review the following tickets, which we are putting forward for an errata vote at the next meeting: #347 MPI 3.0 Errata: RMA Info appendices #348 MPI 3.0 Errata: RMA Example 11.21 #350 MPI 3.0 Errata: RMA origin argument ignored with MPI_NO_OP #355 MPI 3.0 Errata: Get_accumulate Datatype Clarification #359 MPI 3.0 Errata: Update RMA progress rationale #361 MPI 3.0 Errata: RMA Target Buffer Wordsmithing #362 MPI 3.0 Errata: RMA same_size info key Cheers, ~Jim. On 2/20/13 10:00 AM, Jim Dinan wrote: > Here is another errata ticket for review: > > #362 MPI 3.0 Errata: RMA same_size info key > > ~Jim. > > On 2/20/13 9:38 AM, Jim Dinan wrote: >> Hi All, >> >> Here is the list of RMA errata tickets I have assembled for the upcoming >> meeting. Please let me know if there are any tickets missing from the >> list and review the proposed changes: >> >> #347 MPI 3.0 Errata: RMA Info appendices >> #348 MPI 3.0 Errata: RMA Example 11.21 >> #350 MPI 3.0 Errata: RMA origin argument ignored with MPI_NO_OP >> #355 MPI 3.0 Errata: Get_accumulate Datatype Clarification >> #359 MPI 3.0 Errata: Update RMA progress rationale >> #361 MPI 3.0 Errata: RMA Target Buffer Wordsmithing >> >> Cheers, >> ~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

1 0

[Mpi3-rma] March meeting items
by Jim Dinan 20 Feb '13

20 Feb '13

Hi All, I would like to submit the following issues for discussion by the RMA working group at the March meeting: #344 - Shared memory window attribute query mechanism https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/344 #349 - RMA Dynamic window target displacement https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349 These items are both in the early stages and need some working group discussion in order to query for support and generate proper proposals. If possible, it might be productive to discuss these items via email or telecon before the March meeting. Cheers, ~Jim.

1 0

Re: [Mpi3-rma] Call for errata
by Jim Dinan 20 Feb '13

20 Feb '13

Here is another errata ticket for review: #362 MPI 3.0 Errata: RMA same_size info key ~Jim. On 2/20/13 9:38 AM, Jim Dinan wrote: > Hi All, > > Here is the list of RMA errata tickets I have assembled for the upcoming > meeting. Please let me know if there are any tickets missing from the > list and review the proposed changes: > > #347 MPI 3.0 Errata: RMA Info appendices > #348 MPI 3.0 Errata: RMA Example 11.21 > #350 MPI 3.0 Errata: RMA origin argument ignored with MPI_NO_OP > #355 MPI 3.0 Errata: Get_accumulate Datatype Clarification > #359 MPI 3.0 Errata: Update RMA progress rationale > #361 MPI 3.0 Errata: RMA Target Buffer Wordsmithing > > Cheers, > ~Jim. > _______________________________________________ > 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 20 Feb '13

20 Feb '13

Hi All, Here is the list of RMA errata tickets I have assembled for the upcoming meeting. Please let me know if there are any tickets missing from the list and review the proposed changes: #347 MPI 3.0 Errata: RMA Info appendices #348 MPI 3.0 Errata: RMA Example 11.21 #350 MPI 3.0 Errata: RMA origin argument ignored with MPI_NO_OP #355 MPI 3.0 Errata: Get_accumulate Datatype Clarification #359 MPI 3.0 Errata: Update RMA progress rationale #361 MPI 3.0 Errata: RMA Target Buffer Wordsmithing Cheers, ~Jim.

1 0

Re: [Mpi3-rma] Call for errata
by Jim Dinan 15 Feb '13

15 Feb '13

Hi Hubert, I updated the proposed text in the ticket. Thanks for helping to fix this. ~Jim. On 2/15/13 3:24 AM, Hubert Ritzdorf wrote: > Hi Jim, > > This text is ok for me. > > Many thanks > > Hubert > >> -----Original Message----- >> From: mpi3-rma-bounces(a)lists.mpi-forum.org [mailto:mpi3-rma- >> bounces(a)lists.mpi-forum.org] On Behalf Of Jim Dinan >> Sent: Wednesday, February 13, 2013 9:59 PM >> To: mpi3-rma(a)lists.mpi-forum.org >> Subject: Re: [Mpi3-rma] Call for errata >> >> Hi Hubert, >> >> Ok, I think I understand the problem -- I am parsing "fit in" >> incorrectly. Hopefully the following text should correct the >> misinterpretation of "fit in" and also correctly specify what data is >> transferred from target to origin. >> >> p. 428, line 15-17 quoted: >> >> Accumulate origin_count elements of type origin_datatype from the origin >> buffer (origin_addr) to the buffer at offset target_disp, in the target >> window specified by target_rank and win, using the operation op and >> return in the result buffer result_addr the content of the target >> >> OLD LINE 18: >> >> buffer before the accumulation. >> >> NEW LINE 18: >> >> buffer before the accumulation, specified by target_count and >> target_datatype. >> >> p. 428, line 23-24, replace "fit in" with: >> >> target_datatype must not specify overlapping entries, and the target >> buffer must *be contained within* the target window or in attached >> memory in a dynamic window. >> >> Thanks again for your help, >> ~Jim. >> >> On 2/1/13 4:24 AM, Hubert Ritzdorf wrote: >>> Hi Jim, >>> >>> I agree to the semantics below. >>> However, ticket 355 specifies >>> >>> ------- >>> In addition, there appears to be a typo in the current text >> (s/target/origin/). >>> >>> Current text on p. 458, line 23-24: >>> >>> target_datatype must not specify overlapping entries, and the target >> buffer >>> must fit in the target window or in attached memory in a dynamic window. >>> >>> Suggested text: >>> >>> target_datatype must not specify overlapping entries, and the *origin* >> buffer >>> must fit in the target window or in attached memory in a dynamic window. >>> ... >>> ------- >>> >>> I think, that the original text is correct and the suggested text is >> incorrect. >>> The original text corresponds to the text for MPI_GET. The target buffer >>> must fit in the target window since the target data is transferred to >> the origin's >>> result buffer. >>> >>> 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 6:35 PM >>> To: mpi3-rma(a)lists.mpi-forum.org >>> Subject: Re: [Mpi3-rma] Call for errata >>> >>> 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!KFP >> MxAFFaa8ieyScSFKfD4GCvgRNeNI84u45W2BPFL9JFA== 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 >>>> >>> _______________________________________________ >>> 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 15 Feb '13

15 Feb '13

Hi Jim, This text is ok for me. Many thanks Hubert > -----Original Message----- > From: mpi3-rma-bounces(a)lists.mpi-forum.org [mailto:mpi3-rma- > bounces(a)lists.mpi-forum.org] On Behalf Of Jim Dinan > Sent: Wednesday, February 13, 2013 9:59 PM > To: mpi3-rma(a)lists.mpi-forum.org > Subject: Re: [Mpi3-rma] Call for errata > > Hi Hubert, > > Ok, I think I understand the problem -- I am parsing "fit in" > incorrectly. Hopefully the following text should correct the > misinterpretation of "fit in" and also correctly specify what data is > transferred from target to origin. > > p. 428, line 15-17 quoted: > > Accumulate origin_count elements of type origin_datatype from the origin > buffer (origin_addr) to the buffer at offset target_disp, in the target > window specified by target_rank and win, using the operation op and > return in the result buffer result_addr the content of the target > > OLD LINE 18: > > buffer before the accumulation. > > NEW LINE 18: > > buffer before the accumulation, specified by target_count and > target_datatype. > > p. 428, line 23-24, replace "fit in" with: > > target_datatype must not specify overlapping entries, and the target > buffer must *be contained within* the target window or in attached > memory in a dynamic window. > > Thanks again for your help, > ~Jim. > > On 2/1/13 4:24 AM, Hubert Ritzdorf wrote: > > Hi Jim, > > > > I agree to the semantics below. > > However, ticket 355 specifies > > > > ------- > > In addition, there appears to be a typo in the current text > (s/target/origin/). > > > > Current text on p. 458, line 23-24: > > > > target_datatype must not specify overlapping entries, and the target > buffer > > must fit in the target window or in attached memory in a dynamic window. > > > > Suggested text: > > > > target_datatype must not specify overlapping entries, and the *origin* > buffer > > must fit in the target window or in attached memory in a dynamic window. > > ... > > ------- > > > > I think, that the original text is correct and the suggested text is > incorrect. > > The original text corresponds to the text for MPI_GET. The target buffer > > must fit in the target window since the target data is transferred to > the origin's > > result buffer. > > > > 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 6:35 PM > > To: mpi3-rma(a)lists.mpi-forum.org > > Subject: Re: [Mpi3-rma] Call for errata > > > > 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!KFP > MxAFFaa8ieyScSFKfD4GCvgRNeNI84u45W2BPFL9JFA== 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 > >> > > _______________________________________________ > > 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 13 Feb '13

13 Feb '13

Hi Hubert, Ok, I think I understand the problem -- I am parsing "fit in" incorrectly. Hopefully the following text should correct the misinterpretation of "fit in" and also correctly specify what data is transferred from target to origin. p. 428, line 15-17 quoted: Accumulate origin_count elements of type origin_datatype from the origin buffer (origin_addr) to the buffer at offset target_disp, in the target window specified by target_rank and win, using the operation op and return in the result buffer result_addr the content of the target OLD LINE 18: buffer before the accumulation. NEW LINE 18: buffer before the accumulation, specified by target_count and target_datatype. p. 428, line 23-24, replace "fit in" with: target_datatype must not specify overlapping entries, and the target buffer must *be contained within* the target window or in attached memory in a dynamic window. Thanks again for your help, ~Jim. On 2/1/13 4:24 AM, Hubert Ritzdorf wrote: > Hi Jim, > > I agree to the semantics below. > However, ticket 355 specifies > > ------- > In addition, there appears to be a typo in the current text (s/target/origin/). > > Current text on p. 458, line 23-24: > > target_datatype must not specify overlapping entries, and the target buffer > must fit in the target window or in attached memory in a dynamic window. > > Suggested text: > > target_datatype must not specify overlapping entries, and the *origin* buffer > must fit in the target window or in attached memory in a dynamic window. > ... > ------- > > I think, that the original text is correct and the suggested text is incorrect. > The original text corresponds to the text for MPI_GET. The target buffer > must fit in the target window since the target data is transferred to the origin's > result buffer. > > 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 6:35 PM > To: mpi3-rma(a)lists.mpi-forum.org > Subject: Re: [Mpi3-rma] Call for errata > > 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 >> > _______________________________________________ > 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 01 Feb '13

01 Feb '13

Hi Jim, I agree to the semantics below. However, ticket 355 specifies ------- In addition, there appears to be a typo in the current text (s/target/origin/). Current text on p. 458, line 23-24: target_datatype must not specify overlapping entries, and the target buffer must fit in the target window or in attached memory in a dynamic window. Suggested text: target_datatype must not specify overlapping entries, and the *origin* buffer must fit in the target window or in attached memory in a dynamic window. ... ------- I think, that the original text is correct and the suggested text is incorrect. The original text corresponds to the text for MPI_GET. The target buffer must fit in the target window since the target data is transferred to the origin's result buffer. 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 6:35 PM To: mpi3-rma(a)lists.mpi-forum.org Subject: Re: [Mpi3-rma] Call for errata 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 > _______________________________________________ mpi3-rma mailing list mpi3-rma(a)lists.mpi-forum.org http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma

1 0