<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;"><div><div><div><div>In general, I agree that allowing any argument for datatype if the count is zero makes sense. However, such a change (even if it is just allowing more) can cause backwards compatibility problems: e.g., any PMPI tool or other kind of internal wrapper library can currently have the assumption that it is only passed valid datatypes and hence can use the datatype without having to check. We, for example, use this to implement piggybacking (by creating a new struct datatype that contains the original one and adds a piggyback field). If we allowed arbitrary datatypes, we would brake such codes, unless we then also allowed it for datatype creation.</div><div><br></div><div>If we wanted to change this, we probably need to be very careful and make sure we are consistent across the standard and touch all routines that take datatype arguments. Just adding the exception for P2P, or even for all communication routines, seems insufficient.</div><div><br></div><div>Martin</div><div><br></div><div> </div><div><div style="font-size: medium; font-family: Consolas;">________________________________________________________________________</div></div></div><div><br></div><div><div style="font-family: Consolas; font-size: medium;">________________________________________________________________________</div><div style="font-family: Consolas; font-size: medium;">Martin Schulz, <a href="mailto:schulzm@llnl.gov">schulzm@llnl.gov</a>, <a href="http://scalability.llnl.gov/">http://scalability.llnl.gov/</a></div><div style="font-family: Consolas; font-size: medium;">CASC @ Lawrence Livermore National Laboratory, Livermore, USA</div><div><br></div></div></div></div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span> mpi-forum <<a href="mailto:mpi-forum-bounces@lists.mpi-forum.org">mpi-forum-bounces@lists.mpi-forum.org</a>> on behalf of Jeff Hammond <<a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a>><br><span style="font-weight:bold">Reply-To: </span> Main mailing list <<a href="mailto:mpi-forum@lists.mpi-forum.org">mpi-forum@lists.mpi-forum.org</a>><br><span style="font-weight:bold">Date: </span> Wednesday, January 13, 2016 at 6:24 AM<br><span style="font-weight:bold">To: </span> Main mailing list <<a href="mailto:mpi-forum@lists.mpi-forum.org">mpi-forum@lists.mpi-forum.org</a>><br><span style="font-weight:bold">Subject: </span> Re: [Mpi-forum] MPI_DATATYPE_NULL when count=0<br></div><div><br></div><div><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div><div dir="ltr">That is precisely what I want: when count=0, the buffer and the datatype arguments are ignored. There may be a good reason for MPI_DATATYPE_NULL to be invalid when it is actually relevant, but when count=0, the datatype argument is not relevant,
because there are zero of them.<br><div><br></div><div>We already state explicitly that arguments are ignored for MPI_IN_PLACE and MPI_NO_OP:<br><br>
* The “in place” option for intracommunicators is specified by passing MPI_IN_PLACE as the value of recvbuf at the root. In such a case, recvcount and recvtype are ignored..." <br><br></div><div>* "When MPI_NO_OP is specified as the operation, the origin_addr, origin_count, and origin_datatype arguments are ignored."<br><br>
I see no reason why count=0 is different from these cases.<br><br>
Jeff<br><br>
On Wed, Jan 13, 2016 at 5:47 AM, William Gropp <<a href="mailto:wgropp@illinois.edu">wgropp@illinois.edu</a>> wrote:<br>
><br>
> True, MPI_BOTTOM need not be null, but it might be, so the standard doesn’t prohibit it.<br>
><br>
> A carefully worded exception to the general rule for NULL handles would be ok. I would still make it narrow; for example, just for the use of MPI_DATATYPE_NULL in communication operations with a zero count.<br>
><br>
> Bill<br>
><br>
> William Gropp<br>
> Director, Parallel Computing Institute<br>
> Thomas M. Siebel Chair in Computer Science<br>
> Chief Scientist, NCSA<br>
> University of Illinois Urbana-Champaign<br>
><br>
><br>
><br>
><br>
><br>
> On Jan 12, 2016, at 11:22 PM, Fab Tillier <<a href="mailto:ftillier@microsoft.com">ftillier@microsoft.com</a>> wrote:<br>
><br>
> Don’t datatypes with absolute addresses rely on MPI_BOTTOM, and a portable program can’t assume that MPI_BOTTOM == NULL?<br>
> <br>
> I think from an ease of use perspective, if I have a count of zero, having to pick an arbitrary committed datatype is non-intuitive. If count is zero, there is no buffer or datatype, and there should be no requirement such non-existent datatype be committed.<br>
> <br>
> Cheers,<br>
> -Fab<br>
> <br>
> From: mpi-forum [mailto:<a href="mailto:mpi-forum-bounces@lists.mpi-forum.org">mpi-forum-bounces@lists.mpi-forum.org</a>] On Behalf Of William Gropp<br>
> Sent: Wednesday, 13 January 2016 4:52 p.m.<br>
> To: Main MPI Forum mailing list <<a href="mailto:mpi-forum@lists.mpi-forum.org">mpi-forum@lists.mpi-forum.org</a>><br>
> Subject: Re: [Mpi-forum] MPI_DATATYPE_NULL when count=0<br>
> <br>
> Yes, NULL buffers are valid - they aren’t an MPI object. There is no prohibition about passing them; only if they are used to form an invalid address (note that a datatype with absolute addresses relies on NULL as the buffer address).<br>
> <br>
> Bill<br>
> <br>
><br>
> William Gropp<br>
> Director, Parallel Computing Institute<br>
> Thomas M. Siebel Chair in Computer Science<br>
> Chief Scientist, NCSA<br>
> University of Illinois Urbana-Champaign<br>
><br>
><br>
><br>
> <br>
> On Jan 12, 2016, at 9:49 PM, Jeff Hammond <<a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a>> wrote:<br>
><br>
><br>
> Who wrote Example 4.23 of MPI 3.1?<br>
> <br>
> I propose to add the exception rather than delete that example. I do not want to have to use real datatypes when sending nothing.<br>
> <br>
> Is NULL a valid buffer handle? Can I pass null pointers when count=0?<br>
><br>
> <br>
> Jeff<br>
><br>
><br>
> On Tuesday, January 12, 2016, William Gropp <<a href="mailto:wgropp@illinois.edu">wgropp@illinois.edu</a>> wrote:<br>
><br>
> The standard says that the null handles are invalid for input unless explicitly permitted. There’s no exemption for a datatype argument where the associated count is zero.<br>
> <br>
> Bill<br>
> <br>
><br>
> William Gropp<br>
> Director, Parallel Computing Institute<br>
> Thomas M. Siebel Chair in Computer Science<br>
> Chief Scientist, NCSA<br>
> University of Illinois Urbana-Champaign<br>
><br>
><br>
><br>
> <br>
> On Jan 12, 2016, at 9:26 PM, Jeff Hammond <<a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a>> wrote:<br>
><br>
><br>
> Is it allowed to communicate messages with (buffer=NULL,count=0,type=MPI_DATATYPE_NULL)?<br>
> <br>
> George thinks MPI_DATATYPE_NULL cannot be used even when count=0, which I think is ridiculous, particularly when one makes the analogy to buffer=NULL.<br>
> <br>
> See <a href="http://www.open-mpi.org/community/lists/users/2016/01/28255.php">http://www.open-mpi.org/community/lists/users/2016/01/28255.php</a> for the thread in question.<br>
> <br>
> There is example code in MPI that uses this behavior. George and I agree that example text is non-normative, but I cannot imagine how this example came to exist without the Forum believing it to be valid.<br>
><br>
> Jeff<br>
> <br>
> --<br>
> Jeff Hammond<br>
> <a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a><br>
> <a href="http://jeffhammond.github.io/">http://jeffhammond.github.io/</a><br>
> _______________________________________________<br>
> mpi-forum mailing list<br>
> <a href="mailto:mpi-forum@lists.mpi-forum.org">mpi-forum@lists.mpi-forum.org</a><br>
> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum</a><br>
><br>
> <br>
><br>
><br>
><br>
> --<br>
> Jeff Hammond<br>
> <a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a><br>
> <a href="http://jeffhammond.github.io/">http://jeffhammond.github.io/</a><br>
> _______________________________________________<br>
> mpi-forum mailing list<br>
> <a href="mailto:mpi-forum@lists.mpi-forum.org">mpi-forum@lists.mpi-forum.org</a><br>
> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum</a><br>
><br>
> <br>
> _______________________________________________<br>
> mpi-forum mailing list<br>
> <a href="mailto:mpi-forum@lists.mpi-forum.org">mpi-forum@lists.mpi-forum.org</a><br>
> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> mpi-forum mailing list<br>
> <a href="mailto:mpi-forum@lists.mpi-forum.org">mpi-forum@lists.mpi-forum.org</a><br>
> <a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum</a><br><br><br><br><br>
--<br>
Jeff Hammond<br><a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a><br><a href="http://jeffhammond.github.io/">http://jeffhammond.github.io/</a></div></div></div></div></span></body></html>