Ah, ok -- yes, you are correct. Sorry for the misunderstanding on my end. The output buffer must be greater or equal to the size of the input buffer in RMA calls (same semantic as send/recv); thus in accumulate calls, the basic datatype count in the result buffer can be larger than in the input buffer. Coming back to Hubert's original question, I don't think this is adequately covered by the spec. The target buffer parameters should dictate the data that will be placed into the result buffer. And this datatype is allowed to be larger than the origin datatype. I created a ticket for this issue with suggested text to correct it: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/355 Thanks, ~Jim. On 12/7/12 1:40 PM, Jeff Hammond wrote:
Are we talking about the same thing? I am asserting that it is not required that the size of the input and output buffers - regardless of how they are represented with datatypes - do not have to be the same size, but only need to satisfy the requirement that no buffer overrun occurs on either end.
Are you disagreeing with this or are you saying something else?
Jeff
On Fri, Dec 7, 2012 at 1:29 PM, Jim Dinan <[email protected]> wrote:
This restriction on derived datatypes does not apply to get or put. It only applies to accumulate operations, and is stated in the 3.0 spec in the first paragraph of page 426 for accumulate, and again in the second paragraph on page 428 for get_accumulate:
"Each datatype argument must be a prede fined datatype or a derived datatype, where all basic components are of the same predefined datatype. Both datatype arguments must be constructed from the same predefined datatype."
~Jim.
On 12/7/12 1:13 PM, Jeff Hammond wrote:
Which count variable defines the number of basic elements to be returned? (result_count, result_type) or (target_count, target_type) ?
result_addr is the buffer that is written at the origin so I believe the answer is (result_count, result_type).
The number of basic elements needs to be the same across all <count, dtype> pairs. The count and datatype for the result buffer determine where these elements will be in the origin process' memory.
This is not what the MPI standard says for MPI_GET and MPI_ACCUMULATE, as I previously noted, or MPI_PUT, as noted here. If we're going to change the semantics in this respect, it needs to be considered carefully, as it will break backwards compatibility with codes that assume the same behavior as MPI_RECV, as is stipulated in 11.3.1 (MPI_PUT):
"The communication must satisfy the same constraints as for a similar message-passing communication. The target_datatype may not specify overlapping entries in the target buffer. The message sent must fit, without truncation, in the target buffer. Furthermore, the target buffer must fit in the target window or in attached memory in a dynamic window."
"Fitting without truncation" is weaker than "needs to be the same".
Best,
Jeff
_______________________________________________ mpi3-rma mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma