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

[Jeff Squyres (jsquyres)]

I think it looks good.  Ship it.


On May 19, 2014, at 5:30 PM, Kathryn Mohror <kathryn at llnl.gov> wrote:

> Okay, here’s another try. Please let me know if this is now correct.  (Sorry for the delay — I am at IPDPS and the wifi is not so good)
> 
> Kathryn
> 
> _________________________________________________________________
> Kathryn Mohror, kathryn at llnl.gov, http://scalability.llnl.gov/
> Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA, USA
> 
> From: <Schulz>, Martin <schulz6 at llnl.gov>
> Reply-To: "mpiwg-tools at lists.mpi-forum.org" <mpiwg-tools at lists.mpi-forum.org>
> Date: Monday, May 19, 2014 at 9:37 AM
> To: "'mpiwg-tools at lists.mpi-forum.org'" <mpiwg-tools at lists.mpi-forum.org>, "'<mpiwg-tools at lists.mpi-forum.org>'" <mpiwg-tools at lists.mpi-forum.org>
> Subject: Re: [mpiwg-tools] Ticket #383 -- Final text?
> 
> Either option is fine with me - I can see the argument either way
> 
> Martin
> 
> 
> 
> Sent with Good (www.good.com)
> 
> 
> -----Original Message-----
> From: Jeff Squyres (jsquyres) [jsquyres at cisco.com]
> Sent: Monday, May 19, 2014 09:25 AM Pacific Standard Time
> To: 
> Subject: Re: [mpiwg-tools] Ticket #383 -- Final text?
> 
> Good point.  I like INOUT, but wont' fight too hard if people want to drop it.
> 
> On May 19, 2014, at 12:08 PM, "Schulz, Martin" <schulz6 at llnl.gov>
>  wrote:
> 
> > Looks mostly good to me, but length arguments are INOUT, so that may be confusing - perhaps just drop the IN?
> >
> > Martin
> >
> >
> >
> > Sent with Good (www.good.com)
> >
> >
> > -----Original Message-----
> > From: Kathryn Mohror [kathryn at llnl.gov]
> > Sent: Monday, May 19, 2014 08:31 AM Pacific Standard Time
> > To: Bronis R. de Supinski; mpiwg-tools at lists.mpi-forum.org
> > Subject: Re: [mpiwg-tools] Ticket #383 -- Final text?
> >
> > Jeff,
> >
> > Is this what you want for the text, attached?
> >
> > Kathryn
> > _________________________________________________________________
> > Kathryn Mohror, 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> 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> 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
> > >> 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
> > >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
> >
> >
> > _______________________________________________
> > mpiwg-tools mailing list
> > mpiwg-tools at lists.mpi-forum.org
> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
> 
> 
> --
> Jeff Squyres
> 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
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
> <tools-3.pdf>_______________________________________________
> mpiwg-tools mailing list
> mpiwg-tools at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools


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