<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Nils,<div class=""><br class=""></div><div class="">In general, I like the idea of having default/invalid values for these MPI-related user variables.</div><div class=""><br class=""></div><div class="">Would MPI_TAG_NULL be valid for a point-to-point send operation that does NOT use MPI_PROC_NULL but is matched with receive operation at the destination MPI process that uses MPI_ANY_TAG? Or should this be an MPI_ERR_ARG/MPI_ERR_TAG error condition? Commonly, codes that use MPI_ANY_TAG in receive operations must choose an arbitrary valid tag value to use in the send operations at the source MPI process(es). Permitting the use of MPI_TAG_NULL in combination with MPI_ANY_TAG might aid debugging when the matching does not go the way the user expected. However, it would add complexity to the matching rules/implementation. There is an interaction here with INFO key assertions such as `mpi_assert_no_any_tag` — which means the error could be discovered at the sender process -- and `mpi_assert_only_any_tag` (if that one ever gets accepted into MPI).</div><div class=""><br class=""></div><div class="">There is already an MPI constant that is commonly set to `(void*)0` (in C), which is MPI_BOTTOM. Defining MPI_ADDRESS_NULL to be the same value is not a good idea because MPI_BOTTOM is a valid address; although attempting to read/write at that address is likely to cause trouble, using it as a base for a user-defined datatype or a window offset is common/accepted practice. Would it be sufficient for your purposes to use MPI_BOTTOM as your “not valid” value?</div><div class=""><br class=""></div><div class="">IMHO, there would need to be a statement that, “when the comm argument is MPI_COMM_NULL, the only acceptable value for the source/dest argument is MPI_PROC_NULL” because asking for the 3rd item from an empty set (for example) is clearly an error. Your proposal tries to treat MPI_COMM_NULL as if it is a valid MPI intra-communicator that has size zero, or a valid inter-communicator that has a remote group of size zero. I think I would prefer to create MPI_COMM_EMPTY for that purpose, and continue to use MPI_COMM_NULL for situations that call for an invalid communicator, i.e. something that can never be used as a communicator without causing an error condition.</div><div class=""><br class=""></div><div class="">The phrase used elsewhere in the MPI Standard is “XYZ parameter is significant only <when condition>”</div><div class=""><div class="">
<meta charset="UTF-8" class=""><div dir="auto" style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><br class="Apple-interchange-newline">Cheers,</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">Dan.</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">—</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">Dr Daniel Holmes PhD</div>Executive Director<br class="">Chief Technology Officer<br class=""><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">CHI Ltd</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><a href="mailto:danholmes@chi.scot" class="">danholmes@chi.scot</a></div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br class=""></div></div><br class="Apple-interchange-newline">
</div>
<div><br class=""><blockquote type="cite" class=""><div class="">On 21 Oct 2021, at 11:35, Nils Smeds via mpi-comments <<a href="mailto:mpi-comments@lists.mpi-forum.org" class="">mpi-comments@lists.mpi-forum.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_default" style="font-size:small"><div class="gmail_default"><u class="">Summary:</u></div><div class="gmail_default">- Suggestion to introduce MPI_TAG_NULL in the standard with an obviously illegal value (i.e. <0)<br class=""></div><div class="gmail_default">- Explicitly allow Point-to-Point messages to have one of more of: tag MPI_TAG_NULL, datatype MPI_DATATYPE_NULL, invalid buffer addresses (including MPI_ADDRESS_NULL) and communicator MPI_COMM_NULL, if (and only if) the corresponding send or receive argument is MPI_PROC_NULL.</div><div class="gmail_default"><br class=""></div><div class="gmail_default"><u class="">Argument:</u></div><div class="gmail_default">When writing code it is useful if it goes off with a bang when you do something wrong. To catch matching errors in sends and receives I looked for a MPI_TAG_NULL to use as a default value to catch cases where the tag was not set correctly. I found that there was no such item. Referring to the standard I found that tag values are restricted to the values 0...MPI_TAG_UB, where MPI_TAG_UB (>=32767) can be found using the MPI_Comm_get_attr() function. </div><div class="gmail_default"><br class=""></div><div class="gmail_default">So I used my own value for MPI_TAG_NULL as -1 and coded away. However, the MPI implementation I was using blew up when I used it in a MPI_Sendrecv with the remote task being MPI_PROC_NULL throwing an error message "illegal tag value", which was no surprise to me since I had set it to this value explicitly.</div><div class="gmail_default"><br class=""></div><div class="gmail_default">The workaround is of course to put a if( PartnerTask != MPI_PROC_NULL ) { ... } around every point-to-point call, but I find it unnecessary and makes the code look more complex. I think that MPI_PROC_NULL was invented for exactly this purpose, to be a transparent if(...) clause for the operation. Is there really a need to be restrictive on datat ype, tag or any other argument when the P2P operation is with MPI_PROC_NULL?</div><div class="gmail_default"><br class=""></div><div class="gmail_default">I would expect implementations to choose MPI_ADDRESS_NULL be equal to (*) 0 in C and 0_MPI_ADDRESS_KIND in Fortran and MPI_TAG_NULL to be default integer kind -1.</div><div class="gmail_default"><br class=""></div><div class="gmail_default"><u class="">Implementation:</u><br class="">Append to section "3.10 Null processes" text along the lines of:<br class=""></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px" class=""><div class="gmail_default" style="font-size:small"><div class="gmail_default">A call to any point-to-point messaging function with a process argument of MPI_PROC_NULL is allowed to have any value for buffer address, data type, tag and communicator including MPI_ADDRESS_NULL, MPI_DATATYPE_NULL, MPI_TAG_NULL and MPI_COMM_NULL without causing an error condition in the execution.</div></div></blockquote><div class="gmail_default" style="font-size:small"><div class="gmail_default"><br class=""></div><div class="gmail_default">Insert into appendix "A1 Assorted constants"</div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px" class=""><div class="gmail_default" style="font-size:small"><div class="gmail_default">MPI_TAG_NULL and MPI_ADDRESS_NULL</div></div></blockquote><div class="gmail_default" style="font-size:small"><div class="gmail_default"><br class=""></div><div class="gmail_default">Insert into section "9.1.2 Environmental Inquiries" (which is an odd place where Tag values are specified in the standard):</div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px" class=""><div class="gmail_default" style="font-size:small"><div class="gmail_default">(Line 34, end of first paragraph) [... is also a valid value for MPITAG_UB]. The constant MPI_TAG_NULL shall have a value outside of the 0...MPI_TAG_UB range. The value MPI_TAG_NULL is erroneous to use in any communication unless the associated process argument is MPI_PROC_NULL.</div></div></blockquote><div class=""><br class=""></div><div class="gmail_default" style="font-size:small">Add to section "15.3.3 Convention for Returning Strings"</div><div class="gmail_default" style="font-size:small"><blockquote style="margin:0 0 0 40px;border:none;padding:0px" class=""><div class="gmail_default" style="font-size:small">The constant MPI_ADDRESS_NULL can be used as an equivalent to the null pointer.</div></blockquote></div><div class="gmail_default" style="font-size:small"></div><div class="gmail_default" style="font-size:small"></div><div class=""><br class=""></div><br class=""><div class="gmail_default" style="font-size:small"><font color="#888888" class=""><div class="gmail_default"><br class=""></div><div class="gmail_default">/Nils Smeds</div><div class="gmail_default"><br class=""></div></font></div></div>
_______________________________________________<br class="">mpi-comments mailing list<br class=""><a href="mailto:mpi-comments@lists.mpi-forum.org" class="">mpi-comments@lists.mpi-forum.org</a><br class="">https://lists.mpi-forum.org/mailman/listinfo/mpi-comments<br class=""></div></blockquote></div><br class=""></div></body></html>