- Mpi-22 - mailman3.cels.anl.gov

Re: [Mpi-22] #117: Define a new MPI_Count Datatype
by unknown＠example.com 11 Feb '09

11 Feb '09

The current proposal has a typedef instead of #define. Are there any specific reasons for preferring the pre-processor macro approach? Thanx! Kannan -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander Sent: Wednesday, February 11, 2009 6:44 AM To: MPI 2.2 Subject: Re: [Mpi-22] #117: Define a new MPI_Count Datatype Hi, Thanks. I added an offline comment regarding the #define trick for MPI-2.2. Has this been addressed? Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Narasimhan, Kannan Sent: Wednesday, February 11, 2009 12:54 AM To: MPI 2.2 Subject: [Mpi-22] #117: Define a new MPI_Count Datatype I've updated Ticket #117 ( Define a new MPI_Count Datatype ) to address the issues raised at the MPI Forum Meeting. Is there any other concern that is not addressed in this ticket? Thanx! Kannan _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22

1 0

Re: [Mpi-22] #117: Define a new MPI_Count Datatype
by unknown＠example.com 11 Feb '09

11 Feb '09

Hi, Thanks. I added an offline comment regarding the #define trick for MPI-2.2. Has this been addressed? Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Narasimhan, Kannan Sent: Wednesday, February 11, 2009 12:54 AM To: MPI 2.2 Subject: [Mpi-22] #117: Define a new MPI_Count Datatype I've updated Ticket #117 ( Define a new MPI_Count Datatype ) to address the issues raised at the MPI Forum Meeting. Is there any other concern that is not addressed in this ticket? Thanx! Kannan _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

1 0

#117: Define a new MPI_Count Datatype
by unknown＠example.com 10 Feb '09

10 Feb '09

I've updated Ticket #117 ( Define a new MPI_Count Datatype ) to address the issues raised at the MPI Forum Meeting. Is there any other concern that is not addressed in this ticket? Thanx! Kannan

1 0

Fwd: [MPI Forum] #2: MPI_TYPE_GET_ENVELOPE and MPI_TYPE_GET_CONTENTS ambiguities introduced in MPI-2.1
by unknown＠example.com 10 Feb '09

10 Feb '09

FYI -- this contentious ticket has been withdrawn. The reviewers and myself all missed a statement immediately preceding the language neutral bindings of MPI_TYPE_GET_CONTENTS that says: The actual arguments used in the creation call for a datatype can be obtained from the call: Hence, the current text is perfectly clear on what the behavior should be. Begin forwarded message: > From: "MPI Forum" <mpi-22_at_[hidden]> > Date: February 10, 2009 3:43:48 PM PST > Subject: Re: [MPI Forum] #2: MPI_TYPE_GET_ENVELOPE and > MPI_TYPE_GET_CONTENTS ambiguities introduced in MPI-2.1 > > #2: MPI_TYPE_GET_ENVELOPE and MPI_TYPE_GET_CONTENTS ambiguities > introduced in > MPI-2.1 > -------------------------------- > +------------------------------------------- > Reporter: jsquyres | Owner: jsquyres > Type: Text (only) changes | Status: closed > Priority: Waiting for reviews | Milestone: 2009/02/09 San Jose > Version: MPI 2.2 | Resolution: Withdrawn > Keywords: | > -------------------------------- > +------------------------------------------- > Changes (by jsquyres): > > * status: assigned => closed > * resolution: => Withdrawn > > > Old description: > >> == Description == >> >> Sep 8 2008 Straw Vote >> >> || return 0|| don't return 0 || Abstain || >> || 17 || 1 || 9 || >> >> MPI-2.1 introduced an ambiguity in the interpretation of what >> MPI_TYPE_GET_CONTENTS is supposed to return. Specifically: MPI-2.1 >> introduced that user-defined datatypes could be created with zero >> counts >> for datatypes. The ambiguity originates from two sections of text: >> >> * MPI-2.1: p78:18-20 >> Most datatype constructors have replication count or block length >> arguments. Allowed values are nonnegative integers. If the value is >> zero, >> no elements are generated in the type map and there is no effect on >> datatype bounds or extent. >> * MPI-2.1: p107:47-48 >> The datatypes returned in array_of_datatypes are handles to >> datatype >> objects that are equivalent to the datatypes used in the original >> construction call. >> >> If datatype constructors accept 0-count datatype arguments that are >> supposed to have "no elements are generated in the type map" and "no >> effect on datatype bounds or extent", should MPI_TYPE_GET_CONTENTS >> return >> those 0-count datatypes in array_of_datatypes? After all, >> MPI_TYPE_GET_CONTENTS says that array_of_datatypes is supposed to >> contain >> handles to datatype objects that are equivalent to the datatypes >> used in >> the original construction call (which used 0-count datatypes). >> >> A similar problem exists with MPI_TYPE_GET_ENVELOPE; does >> num_datatypes >> contain a count of all the zero-count datatypes specified in the >> constructor? >> >> == History == >> >> Ambiguity was accidentally introduced in MPI-2.1 (verified in July >> 2008 >> Forum meeting). >> >> == Proposed Solution == >> >> Change MPI-2.1 p107:47-48 from: >> >> The datatypes returned in array_of_datatypes are handles to datatype >> objects that are equivalent to the datatypes used in the original >> construction call. >> >> to >> >> The datatypes returned in array_of_datatypes are handles to datatype >> objects that are equivalent to the significant datatypes used in the >> original construction call (datatypes with zero count or zero >> blocklength >> are not considered significant). >> >> == Impact on Implementations == >> >> Implementations that return zero-count or zero-blocklength >> datatypes will >> need to be updated to not return them. >> >> == Impact on Applications / Users == >> >> Applications will need to recognize that zero-count/zero-blocklength >> datatypes will not be returned from MPI_TYPE_CONTENTS. This is not >> expected to be a burden because the the intended consumers of >> MPI_TYPE_CONTENTS are looking for the "significant" datatypes (vs. >> looking for insignificant datatypes that will just be discarded). >> >> == Alternative Solutions == >> >> * Change it so that MPI_TYPE_CONTENTS specifically returns zero- >> count/ >> zero-blocklength datatypes. This does not seem useful to the >> expected >> consumers of MPI_TYPE_CONTENTS. >> * Allow MPI implementations to either return the zero-count >> datatypes or >> not. From the user perspective, this is the same as requiring MPI >> implementations to return the zero-count datatypes because the >> application will need to check for zero-count datatypes in >> array_of_datatypes. >> >> == Entry for the Change Log == >> >> Section 4.1.13 on page 104. Remove ambiguity regarding zero-count >> datatypes with MPI_TYPE_GET_ENVELOPE and MPI_TYPE_GET_CONTENTS. > > New description: > > == Description == > > Sep 8 2008 Straw Vote > > || return 0|| don't return 0 || Abstain || > || 17 || 1 || 9 || > > MPI-2.1 introduced an ambiguity in the interpretation of what > MPI_TYPE_GET_CONTENTS is supposed to return. Specifically: MPI-2.1 > introduced that user-defined datatypes could be created with zero > counts > for datatypes. The ambiguity originates from two sections of text: > > * MPI-2.1: p78:18-20 > Most datatype constructors have replication count or block length > arguments. Allowed values are nonnegative integers. If the value is > zero, > no elements are generated in the type map and there is no effect on > datatype bounds or extent. > * MPI-2.1: p107:47-48 > The datatypes returned in array_of_datatypes are handles to > datatype > objects that are equivalent to the datatypes used in the original > construction call. > > If datatype constructors accept 0-count datatype arguments that are > supposed to have "no elements are generated in the type map" and "no > effect on datatype bounds or extent", should MPI_TYPE_GET_CONTENTS > return > those 0-count datatypes in array_of_datatypes? After all, > MPI_TYPE_GET_CONTENTS says that array_of_datatypes is supposed to > contain > handles to datatype objects that are equivalent to the datatypes > used in > the original construction call (which used 0-count datatypes). > > A similar problem exists with MPI_TYPE_GET_ENVELOPE; does > num_datatypes > contain a count of all the zero-count datatypes specified in the > constructor? > > == History == > > Ambiguity was accidentally introduced in MPI-2.1 (verified in July > 2008 > Forum meeting). > > == Proposed Solution == > > Change MPI-2.1 p107:47-48 from: > > The datatypes returned in array_of_datatypes are handles to datatype > objects that are equivalent to the datatypes used in the original > construction call. > > to > > The datatypes returned in array_of_datatypes are handles to the same > > handles to datatype objects that are identical to the datatypes used > in > the original construction call, including any zero-count datatypes > that > were specified in the original datatype constructor. > > == Impact on Implementations == > > Implementations may need to be updated to save a copy of the datatypes > passed to datatype constructor functions. > > == Impact on Applications / Users == > > Applications will need to handle zero-count datatypes in what they get > back from MPI_TYPE_CONTENTS. This is not expected to be a burden > because > the user created the datatype with a zero-count datatype anyway. > > == Alternative Solutions == > > * Change it so that MPI_TYPE_CONTENTS specifically excludes zero- > count > datatypes. This does not seem to be consistent. > * Allow MPI implementations to either return the zero-count > datatypes or > not. From the user perspective, this is the same as requiring MPI > implementations to return the zero-count datatypes because the > application > will need to check for zero-count datatypes in array_of_datatypes. > > == Entry for the Change Log == > > Section 4.1.13 on page 104. Remove ambiguity regarding zero-count > datatypes with MPI_TYPE_GET_ENVELOPE and MPI_TYPE_GET_CONTENTS. > > -- > > Comment: > > It turns out that all of us missed the following statement MPI-2.1 > p107:1-2: > > The actual arguments used in the creation call for a datatype can be > obtained from the call: > > (followed by the language neutral binding for MPI_TYPE_GET_CONTENTS) > > Hence, I withdraw this ticket -- the current text is perfectly clear > on > exactly what the behavior should be (sorry Dick!). > > -- > Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/2#comment:26 > > > MPI Forum <https://svn.mpi-forum.org/> > MPI Forum -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-22] [MPI Forum] #111: Fix predefined attributes
by unknown＠example.com 10 Feb '09

10 Feb '09

Does Cray return a pointer to an int in the C case and the value of a INTEGER in the Fortran case, using different storage for the two values? If so, then we'll have to make the predefined attributes a special case. Bill On Feb 9, 2009, at 7:54 PM, MPI Forum wrote: > #111: Fix predefined attributes > ------------------------------------- > +-------------------------------------- > Reporter: jsquyres | Owner: jsquyres > Type: Correction to standard | Status: new > Priority: Forum feedback requested | Milestone: 2009/02/09 San > Jose > Version: MPI 2.2 | Resolution: > Keywords: | > ------------------------------------- > +-------------------------------------- > > Comment(by jsquyres): > > Cray cites that they have 2 versions of their library -- one that > supports > 32 bit INTEGERs and one that supports 64 bit INTEGERs. However, > both have > 32 bit int's. So changing the "int" to "MPI_Fint" will break user > apps, > and therefore this is problematic for MPI-2.2. > > Need further discussion on what to do here. > > -- > Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/111#comment:4 > > > MPI Forum <https://svn.mpi-forum.org/> > MPI Forum William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

1 0

Preparing for MPI Forum Meeting
by unknown＠example.com 06 Feb '09

06 Feb '09

I've gone through all of the MPI 2.2 tickets (or at least I tried, using the "next ticket" button); tickets that I believe are ready for discussion now are set to Milestone San Jose. Please have a look at these (you can use the custom query to select the MPI 2.2 version and the San Jose Milestone. There are many tickets that are waiting for reviews - please have a look at these. Authors, please make sure that you have the necessary 4 reviews - this will be a prerequisite for discussion next week. Thanks and see you Monday! Bill William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

1 0

Re: [Mpi-22] Please review tickets
by unknown＠example.com 29 Jan '09

29 Jan '09

I think the best way might be to search for your Trac ID and/or email address using the "search" box. On the result page of the search, if you turn up more info than you need, you can limit the search to just tickets. On Jan 29, 2009, at 2:33 PM, Richard Treumann wrote: > Jeff - Do you know of a way for a Forum member to pull a list of > tickets he is obliged to review? > > Dick Treumann - MPI Team > IBM Systems & Technology Group > Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 > Tele (845) 433-7846 Fax (845) 433-8363 > > > mpi-22-bounces_at_[hidden] wrote on 01/29/2009 12:57:39 PM: > > > [image removed] > > > > [Mpi-22] Please review tickets > > > > Jeff Squyres > > > > to: > > > > MPI 2.2 > > > > 01/29/2009 01:01 PM > > > > Sent by: > > > > mpi-22-bounces_at_[hidden] > > > > Please respond to "MPI 2.2" > > > > Hi all. Don't forget that we are about 1.5 weeks away from the San > > Jose meeting. > > > > If you are a reviewer, please review your MPI-2.2 tickets so that we > > can discuss them at the meeting. > > > > Thanks! > > > > -- > > Jeff Squyres > > Cisco Systems > > > > _______________________________________________ > > mpi-22 mailing list > > mpi-22_at_[hidden] > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-22] Please review tickets
by unknown＠example.com 29 Jan '09

29 Jan '09

Jeff - Do you know of a way for a Forum member to pull a list of tickets he is obliged to review? Dick Treumann - MPI Team IBM Systems & Technology Group Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 mpi-22-bounces_at_[hidden] wrote on 01/29/2009 12:57:39 PM: > [image removed] > > [Mpi-22] Please review tickets > > Jeff Squyres > > to: > > MPI 2.2 > > 01/29/2009 01:01 PM > > Sent by: > > mpi-22-bounces_at_[hidden] > > Please respond to "MPI 2.2" > > Hi all. Don't forget that we are about 1.5 weeks away from the San > Jose meeting. > > If you are a reviewer, please review your MPI-2.2 tickets so that we > can discuss them at the meeting. > > Thanks! > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 *

1 0

Please review tickets
by unknown＠example.com 29 Jan '09

29 Jan '09

Hi all. Don't forget that we are about 1.5 weeks away from the San Jose meeting. If you are a reviewer, please review your MPI-2.2 tickets so that we can discuss them at the meeting. Thanks! -- Jeff Squyres Cisco Systems

1 0

Re: [Mpi-22] [MPI Forum] #55: MPI-2.1 Cross-language attribute example is wrong
by unknown＠example.com 27 Jan '09

27 Jan '09

Probably the least damaging thing to do now is to make them MPI_Fints - this (probably) will have no affect in any current implementation, and is consistent with most of the text. I agree that it would be good to deprecate these values, even if we don't replace them in 2.2 . Bill On Jan 27, 2009, at 5:08 PM, Jeff Squyres wrote: > On Jan 27, 2009, at 5:56 PM, William Gropp wrote: > >> Eek! Not for 2.2 ! Maybe a historical advice to users .... > > There are two issues: > > 1. The current text about the C type for predefined attributes is > erroneous. > > p487:46 through 488-3 says that predefined attributes were set by "a > Fortran call" (it doesn't say which Fortran call), but then says the > result in C is of type int. There is no Fortran attribute call that > sets an attribute value that is exactly equivalent to a C int. That's > why MPI-2 created MPI_Fint, right? > > So I think that we must do *something* about this issue. > > 2. Deprecating the old attribute names now (as you suggested) is not a > Bad Thing. Right now, we have a discontinuity of deprecations: some > functions are deprecated, but values that are supposedly set by those > functions are *not* deprecated. If we deprecate those values now and > provide replacements, it opens the door in MPI-3 (or later) to > actually whack them from the spec and only use the new names. > Specifically: deprecating the old names doesn't mean that we have to > break user apps for MPI-2.2. > > -- > Jeff Squyres > Cisco Systems > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

1 0