<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</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>HI Tony,</div>
<div><br>
</div>
<div>Responses interweaved below:</div>
<div><br>
</div>
<div>
<div>
<div>-- </div>
<div>Howard Pritchard</div>
</div>
<div>HPC-DES</div>
<div>Los Alamos National Laboratory</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><<a href="mailto:mpiwg-sessions-bounces@lists.mpi-forum.org">mpiwg-sessions-bounces@lists.mpi-forum.org</a>> on behalf of Dan Holmes <<a href="mailto:dholmes@epcc.ed.ac.uk">dholmes@epcc.ed.ac.uk</a>><br>
<span style="font-weight:bold">Reply-To: </span>MPI Sessions working group <<a href="mailto:mpiwg-sessions@lists.mpi-forum.org">mpiwg-sessions@lists.mpi-forum.org</a>><br>
<span style="font-weight:bold">Date: </span>Friday, January 27, 2017 at 7:07 AM<br>
<span style="font-weight:bold">To: </span>MPI Sessions working group <<a href="mailto:mpiwg-sessions@lists.mpi-forum.org">mpiwg-sessions@lists.mpi-forum.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [mpiwg-sessions] MPI sessions and MPI T<br>
</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
Hi Howard,
<div class=""><br class="">
</div>
<div class="">Thanks - that looks like a manageably short list. Here’s my initial thoughts.</div>
<div class=""><br class="">
</div>
<div class="">1) terminology: I’m torn on this - it wouldn’t be the first naming clash in MPI (e.g. MPI_WAIT vs MPI_WIN_WAIT) but that’s no excuse to add another. The name MPI Sessions has achieved some useful brand awareness, which we shouldn’t give up lightly.</div>
<div class=""><br class="">
</div>
<div class="">2a) For MPI_T_CVAR_GET_INFO, I’m not seeing the conflict. The parameters are {int,string,int,int,MPI_Datatype,} so there is nowhere to pass MPI_COMM_WORLD *as a communicator, i.e. MPI_COMM*. Of course, MCW is a link-time constant handle, so its
value can be used pretty much anywhere with suitable casting. I would not expect int george = (int)MPI_COMM_WORLD; to need the communicator represented by the symbol to exist.</div>
</div>
</div>
</blockquote>
</span>
<div><br>
</div>
<div>You’re correct about MPI_T_CVAR_GET_INFO. I overlooked the table 14.2 in section 14.3.2 that describes values returned in the bind out argument. We’ll need to extend this table to include a session handle type.</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class=""><br class="">
</div>
<div class="">2b) For MPI_T_CVAR_HANDLE_ALLOC, I like your option of a “not now” error. Alternatively, see (3b) below.</div>
<div class=""><br class="">
</div>
<div class="">3a) For MPI_T_PVAR_GET_INFO, I’m not seeing the conflict (as for CVAR in (2a) above).</div>
</div>
</div>
</blockquote>
</span>
<div><br>
</div>
<div>Agreed same as above in my response.</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class=""><br class="">
</div>
<div class="">3b) For MPI_T_PVAR_HANDLE_ALLOC, would it be possible to attach the pvar to a skeleton mcw and always return dummy/default values (e.g. all counters would stick at zero) when queried? How much of mcw would need to exist (my assumption - none of
it)? If some future action causes MCW to be created properly, i.e. MPI_INIT is called, then the pvar would be attached to it during that creation and start giving non-dummy/default answers. This change could be made irrespective of MPI Sessions.</div>
<div class="">MPI_T_INIT();</div>
<div class="">MPI_T_PVAR_HANDLE_ALLOC(…MCW…);</div>
<div class="">MPI_INIT();</div>
<div class="">// MCW already has PVAR attached</div>
</div>
</div>
</blockquote>
</span>
<div><br>
</div>
<div>This sounds like a reasonable approach to me. </div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class=""><br class="">
</div>
<div class="">4) We should allow the session handle to be passed as the obj_handle so that CVARs and PVARs can be attached to MPI Sessions.</div>
</div>
</div>
</blockquote>
</span>
<div><br>
</div>
<div>Yep, at a minimum we should extend the table 14.2</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class=""><br class="">
</div>
<div class="">Cheers,</div>
<div class="">Dan.</div>
<div class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On 27 Jan 2017, at 00:17, Pritchard Jr., Howard <<a href="mailto:howardp@lanl.gov" class="">howardp@lanl.gov</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div style="font-family: Calibri, sans-serif; font-size: 14px;" class="">Hi Folks,</div>
<div style="font-family: Calibri, sans-serif; font-size: 14px;" class=""><br class="">
</div>
<div style="font-family: Calibri, sans-serif; font-size: 14px;" class="">I finally got around to a to-do item for the MPI sessions WG. I’d said</div>
<div style="font-family: Calibri, sans-serif; font-size: 14px;" class="">I’d look through the MPI_T portion of the tools chapter of the standard</div>
<div style="font-family: Calibri, sans-serif; font-size: 14px;" class="">and see what consequences the MPI Sessions concept would have on that</div>
<div style="font-family: Calibri, sans-serif; font-size: 14px;" class="">section.</div>
<div style="font-family: Calibri, sans-serif; font-size: 14px;" class=""><br class="">
</div>
<div style="font-family: Calibri, sans-serif; font-size: 14px;" class="">I came up with the following short list:</div>
<ul class="">
<li class=""><font face="Calibri,sans-serif" class="">terminology collision. For performance variables, there is an
</font><font color="#454545" face="Helvetica" class=""><span style="font-size: 12px;" class="">MPI_T_pvar_session construct. However, it seems to me this is sufficiently distinct from what we’re proposing for sessions that there should not be an issue.</span></font></li><li class=""><span style="color: rgb(69, 69, 69); font-family: Helvetica; font-size: 12px;" class="">MPI_T_CVAR_GET_INFO </span><span style="color: rgb(69, 69, 69); font-family: Helvetica; font-size: 12px;" class="">
</span><font color="#454545" face="Helvetica" class=""><span style="font-size: 12px;" class="">and MPI_T_CVAR_HANDLE_ALLOC. These have a handle to a MPI object argument. It is legal to pass MPI COMM WORLD/COMM SELF in as the argument. So we’d need to figure
out how to handle these cases in the context of an application that doesn’t explicitly call MPI_INIT or one of the other MPI functions that, according to our proposal, has the side effect of creating MPI_COMM_WORLD/SELF. One option might be to return </span></font><span style="color: rgb(69, 69, 69); font-family: Helvetica; font-size: 12px;" class="">MPI_
T_ ERR_ CVAR_ SET_ NOT_ NOW error code.</span></li><li class=""><span style="color: rgb(69, 69, 69); font-family: Helvetica; font-size: 12px; font-style: normal; font-weight: normal; text-decoration: none;" class="">A similar problem exists for </span><span style="color: rgb(69, 69, 69); font-family: Helvetica; font-size: 12px;" class="">MPI_T_PVAR_GET_INFO
and MPI_T_PVAR_HANDLE_ALLOC.</span><span style="color: rgb(69, 69, 69); font-family: Helvetica; font-size: 12px;" class=""> Curiously, there is no analogous </span><span style="color: rgb(69, 69, 69); font-family: Helvetica; font-size: 12px;" class="">MPI_T_ERR_PVAR_SET_NOT_NOW
error code.</span></li></ul>
<div style="font-family: Calibri, sans-serif; font-size: 14px;" class="">
<div class="">
<div class="">That’s what I came up with for first order items that would be impacted by Sessions, beyond minor languages changes in the text to indicate, for instance, that a Session handle could be passed to MPI_T_CVAR_HANDLE_ALLOC, etc.</div>
<div class=""><br class="">
</div>
<div class="">Howard</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">-- </div>
<div class="">Howard Pritchard</div>
</div>
<div class="">HPC-DES</div>
<div class="">Los Alamos National Laboratory</div>
<div class=""><br class="">
</div>
</div>
</div>
_______________________________________________<br class="">
mpiwg-sessions mailing list<br class="">
<a href="mailto:mpiwg-sessions@lists.mpi-forum.org" class="">mpiwg-sessions@lists.mpi-forum.org</a><br class="">
<a href="https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions" class="">https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions</a></div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
</blockquote>
</span>
</body>
</html>