[Mpi3-rma] Call for errata

Wed Jan 30 10:17:17 CST 2013

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 at lists.mpi-forum.org [mpi3-rma-bounces at lists.mpi-forum.org] on behalf of Hubert Ritzdorf [Hubert.Ritzdorf at 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 at lists.mpi-forum.org [mpi3-rma-bounces at lists.mpi-forum.org] on behalf of Jim Dinan [dinan at mcs.anl.gov]
> Sent: Monday, January 28, 2013 11:51 PM
> To: mpi3-rma at 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 at lists.mpi-forum.org [mpi3-rma-bounces at lists.mpi-forum.org] on behalf of Jim Dinan [dinan at 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 at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
>>
>>
>>    Click https://www.mailcontrol.com/sr/cqZpjZJWCcHGX2PQPOmvUsQN7C0BBstkddyjT4P!KFPMxAFFaa8ieyScSFKfD4GCvgRNeNI84u45W2BPFL9JFA==  to report this email as spam.
>>
>> _______________________________________________
>> mpi3-rma mailing list
>> mpi3-rma at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
>>
> _______________________________________________
> mpi3-rma mailing list
> mpi3-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
>
> _______________________________________________
> mpi3-rma mailing list
> mpi3-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
>
> _______________________________________________
> mpi3-rma mailing list
> mpi3-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
>