[mpiwg-tools] Ticket #383 -- Final text?

[Schulz, Martin]

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 [jczhang at mcs.anl.gov<mailto:jczhang at mcs.anl.gov>]
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) <jsquyres at cisco.com<mailto:jsquyres at cisco.com>> 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 <kathryn at llnl.gov<mailto:kathryn at llnl.gov>> wrote:

> Jeff,
>
> Is this what you want for the text, attached?
>
> Kathryn
> _________________________________________________________________
> Kathryn Mohror, kathryn at llnl.gov<mailto:kathryn at llnl.gov>, http://scalability.llnl.gov/
> Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA,
> USA
>
>
>
>
>
>
> On 5/19/14, 8:03 AM, "Bronis R. de Supinski" <bronis at llnl.gov<mailto:bronis at llnl.gov>> 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 <schulzm at llnl.gov<mailto:schulzm at llnl.gov>> 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
>>> jsquyres at cisco.com<mailto:jsquyres at cisco.com>
>>> For corporate legal information go to:
>>> http://www.cisco.com/web/about/doing_business/legal/cri/
>>>
>>> _______________________________________________
>>> mpiwg-tools mailing list
>>> mpiwg-tools at lists.mpi-forum.org<mailto:mpiwg-tools at lists.mpi-forum.org>
>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
>
> <tools-3.pdf>_______________________________________________
> mpiwg-tools mailing list
> mpiwg-tools at lists.mpi-forum.org<mailto:mpiwg-tools at lists.mpi-forum.org>
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools


--
Jeff Squyres
jsquyres at cisco.com<mailto:jsquyres at cisco.com>
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-tools/attachments/20140519/8aed29e4/attachment-0001.html>