Good catch - it should be "control variables with the same name and performance variables with the same name and class". I think the rest fits, but it would be good to double check (I only have it on my cell right now). Martin Sent with Good (www.good.com) -----Original Message----- From: Junchao Zhang [[email protected]<mailto:[email protected]>] Sent: Monday, May 19, 2014 09:04 AM Pacific Standard Time To: Subject: Re: [mpiwg-tools] Ticket #383 -- Final text? I just browsed this ticket. I remember the standard allows the same pvar name for pvars of different classes. I'm not sure if this ticket is still fine on that. --Junchao Zhang On Mon, May 19, 2014 at 10:38 AM, Jeff Squyres (jsquyres) <[email protected]<mailto:[email protected]>> wrote: Yes. What do others think about this? NOTE: We have about 3.5 hours to get this right/done/sent to the mpi-forum list. (or defer to the next meeting). I.e., T-2 weeks to the meeting is at 2pm US Central time today. The only thing I might change is from "...return the same string OUT parameters..." to "...return the same string valued OUT parameters..." This is the canonical issue that we don't care what the value of the (char*) pointer is; we care that the *string value* itself is what is the same. On May 19, 2014, at 11:30 AM, Kathryn Mohror <[email protected]<mailto:[email protected]>> wrote:

Jeff,

Is this what you want for the text, attached?

Kathryn _________________________________________________________________ Kathryn Mohror, [email protected]<mailto:[email protected]>, http://scalability.llnl.gov/ Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA

On 5/19/14, 8:03 AM, "Bronis R. de Supinski" <[email protected]<mailto:[email protected]>> wrote:

...

"sufficiently long enough" is redundant; "sufficiently long" is sufficient.

On Mon, 19 May 2014, Jeff Squyres (jsquyres) wrote:

...

On May 18, 2014, at 2:35 AM, Martin Schulz <[email protected]<mailto:[email protected]>> wrote:

...

Hi Kathryn, all,

A few comments: - "Adhere to the same definition from the MPI implementation.² - not sure what we meant with this anymore. Perhaps we should just drop this part.

What I meant by that is that each MPI implementation will create a definition for each cvar/pvar/etc. The implementation must adhere to that same definition in all connected processes. I.e., it can't change the definition of exactly what that variable is in different processes (e.g., bytes_in = bytes received from TCP in one process, but bytes received across shared memory in another process).

...

- "OUT index values² is not correct, since index values are IN parameters to the get_info calls. Perhaps just drop OUT?

Good catch; missed that. Yes, this whole clause can go.

...

- The mandate of equal OUT/INPUT values is also not quite right - for the strings, it¹s OK to return substrings of the size argument is too small. I know that¹s a technicality, but I am not sure if this causes problems later down the road.

Mmm. Good point. So the current text is:

* Return the same INOUT and OUT values from the relevant MPI_T_*_GET_INFO function.

(I took the liberty of dropping the index value clause)

I notice that we actually return 3 kinds of things from GET_INFO functions: integers/enums, strings, and MPI handles (i.e., MPI_Datatype). So how about this:

* Return the same INOUT and OUT integer and enum values from the relevant MPI_T_*_GET_INFO function. * If sufficiently long enough string length IN parameters are supplied, return the same string OUT parameters from the relevant MPI_T_*_GET_INFO function. * Return a handle to an equivalent MPI object from the relevant MPI_T_*_GET_INFO function.

-- Jeff Squyres [email protected]<mailto:[email protected]> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

_______________________________________________ mpiwg-tools mailing list [email protected]<mailto:[email protected]> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

<tools-3.pdf>_______________________________________________ mpiwg-tools mailing list [email protected]<mailto:[email protected]> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

-- Jeff Squyres [email protected]<mailto:[email protected]> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ _______________________________________________ mpiwg-tools mailing list [email protected]<mailto:[email protected]> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools