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: [email protected] [[email protected]] on behalf of Jim Dinan [[email protected]] Sent: Wednesday, January 30, 2013 5:12 PM To: [email protected] 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: [email protected] [[email protected]] on behalf of Jim Dinan [[email protected]] Sent: Monday, January 28, 2013 11:51 PM To: [email protected] 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: [email protected] [[email protected]] on behalf of Jim Dinan [[email protected]] 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 [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma

Click https://www.mailcontrol.com/sr/cqZpjZJWCcHGX2PQPOmvUsQN7C0BBstkddyjT4P!KFPMx... to report this email as spam.

_______________________________________________ mpi3-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma

_______________________________________________ mpi3-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma

_______________________________________________ mpi3-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma

_______________________________________________ mpi3-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma