March 2011 - mpi-forum - mailman3.cels.anl.gov

Re: [Mpi-forum] First reading: MPI_T / Tools Chapter
by Adam T. Moody 16 Mar '11

16 Mar '11

My recommendation here made no sense p 27, line 9-13 Change "The functions will only write up to len elements into the respective array. If the category contains more than len variables or other categories respectively , the function returns an arbitrary subset; if it contains less than len variables or other categories respectively, all will be returned and the remaining array entries will not be modified." to "Starting from array index 0, each function writes up to len elements into the array. If the category contains more than len elements, the function returns an arbitrary subset. If the category contains less than len elements, the set of elements is returned in the first len array entries, and the remaining array entries are not modified." Here is a fixed version "Starting from array index 0, each function writes up to len elements into the array. If the category contains more than len elements, the function returns an arbitrary subset of size len. Otherwise, the entire set of elements is returned in the beginning entries of the array, and any remaining array entries are not modified." Also, do you want to specify anything about the order of items returned by these calls: increasing, decreasing, random? We should probably say something along those lines, even if the order is arbitrary. -Adam

1 0

Re: [Mpi-forum] First reading: MPI_T / Tools Chapter
by Adam T. Moody 16 Mar '11

16 Mar '11

Hi Martin, Here is round two of my review (the second half of the proposal). First, in yesterday's email, I suggested the following change: p 12, line 13 Change "This routine returns, if datatpye represents a valid enumeration datatype, N representing the range of the enumeration 0 to N-1 as well as a string with a name for it." "The arguments name and ..." to "If datatype is a valid enumeration datatype, this routine returns the number of items in the enumeration range and the name of the datatype. If the range runs from 0 to N-1, the value N is returned in num. The arguments name and ..." But now I think a better way to write this is: "If the argument datatype is a valid enumeration datatype, this routine returns the number of items in the enumeration range and the name of the datatype. The number of items, N, is returned in the argument num. If N > 0, then the enumeration range runs from 0 to N-1. If N = 0, then the enumeration range is empty. The arguments name and ..." Maybe we don't need to worry about N=0? Alright, now here are comments for the second half of the document. p 16, line 43 "local to a single MPI process" --> "local to an MPI process" p 16, line 46 "the interface has a cleaner semantics" --> "the interface provides cleaner semantics" p 17, line 2 Extra spaces? "Extra performance ... with a class describing ..." p 17, line 2 "describing its the" --> "describing its" p 17, lines 2-5 Could reword these sentences a bit "Each performance variable is associated with a class describing its the basic semantics. The class of a variable also denes its basic behavior, when and how an MPI implementation can change its value, and what the initial value of this variable is at the time it is either used for the first time or reset. In the following this referred to as the starting value." How about? "Each performance variable is associated with a class that describes its basic semantics, basic behavior, its starting value, and when and how an MPI implementation can changes its value. The starting value is the value the variable assumes when it is used for the first time or whenever it is reset." p 17, line 6 Change "Further, it ... to represent it." to "Further, the class of a variable ... to represent the variable." p 17, line 11 "Variables of thie class are expected to be ..." Can they be something other than an enumeration datatype? If not, I would drop the "expected to be" phrase in this sentence. If so, I would list what other types they may be. p 17, lines 10-45 Change the pattern of "The default starting value is ... (at the time the starting value is set) of the resource." to "The default starting value is ... of the resource at the time the starting value is set." p 17, line 10 - p 18, line 27 Change the pattern of "The default starting value" to just "The starting value" The term "starting value" is well defined in the intro, and adding "default" can be confusing. p 17, line 26 Change "It will be returned as an MPI_T_DOUBLE_DATATYPE" to "It is represented by an MPI_T_DOUBLE datatype." p 18, line 1 Drop "during the execution time of an application". Perhaps, I'm wrong, but I don't think this phrase is necessary. It can be misinterpretted to mean over the duration of the application, which can be wrong since the variable may count events only through some window of execution. p 18, line 3 Do you really need this clause? "by one for each specific event that is observed". If not, I'd suggest dropping it. p 18, line 24 "variables if this class" --> "variables of this class" p 18, line 26 Why only specify the units for double? How does one determine the units for MPI_T_INT and MPI_T_LONG_LONG? p 18 , line 35 Change "of an MPI application when new variables become available through dynamic loading." to "of an MPI application when new variables become available (e.g., through dynamic loading)." A similar statement is made for control variables on p 13, line 11. p 18, line 35 Extra space? "an MPI application when" p 19, line 36 Change "The argument verbosity returns the verbosity level (see Section 1.3.1) assigned by the MPI implementation to the variable." to "The argument verbosity returns the verbosity level of the variable (see Section 1.3.1)." p 19, line 38 Can it be anything other that what's in the list? "in the parameter var_class and can be" If not, I'd make this statement stronger, also break into two sentences. "in the parameter var_class. The class value must be" p 14, line 10 Same as above p 19, line 40 Change "The argument datatype returns the MPI_T datatype in which the value for this performance variable is returned." to "The argument datatype returns the MPI_T datatype that is used to represent the performance variable." p 14, line 12 Same as above p 19, line 42 "control" --> "performance" p 20, line 13 Change "Upon return, the argument readonly will be set to zero if the variable can be written or reset by the user, or one if the variable can only be read." to "Upon return, the argument readonly is set to zero if the variable can be written or reset by the user. It is set to one if the variable can only be read." Maybe change "zero" and "one" to "true" and "false", which is how flags in other MPI functions are described? p 20, line 25-28 Break this into two senences like above. And again, change "will be set" to "is set". p 20, line 27 "automatically active" --> "always active" or "continuously active" p 20, line 27 "can not by" --> "cannot be" p 21, line 6 "existing section, i.e., calls to ... of the freed session" --> "existing session. Calls to ... of a session after it is freed." p 21, line 14 Change "The type of MPI object is returned by a previous call to MPI_T_PVAR_GET_INFO in the bind argument." to "The type of MPI object a variable may be bound to is determined by calling MPI_T_PVAR_GET_INFO." p 21, line 29-36 Apply changes from earlier email about control vars. p 22, line 5 Change "Performance variables that have the continuous flag set during the query operation are continuously operating once a handle has been allocated and can be queried any time. They cannot be stopped or paused by the user." to "Performance variables that have the continuous flag set during the query operation are continuously operating once a handle has been allocated. Such variables may be queried at any time, but they may not be stopped or paused by the user." p 22, line 6 Change "All other variables are in a stopped state after their handle has been allocated; their values are not updated as the program executes, and must be started by the user." to "All other variables are in a stopped state after their handle has been allocated; their values are not updated until they have been started by the user." p 22, line 25 Change "are ignored when used with MPI_T_PVAR_ALL_HANDLES." to "are ignored when MPI_T_PVAR_ALL_HANDLES is specified." p 22, line 40 Same as above p 23, line 13 "size and fits" --> "size to hold" as described in previous email p 23, line 15 and line 35 These statements feel more like rationale. You could simply say: "The constant MPI_T_PVAR_ALL_HANDLES cannot be used as an argument for MPI_T_PVAR_WRITE." p 23, line 46 "sets of the" --> "sets the" p 23, line 47 Extra space? " to its starting" p 24, line 4 Extra space? "Readonly variables are" p 24, line 4 Change "are ignored when used with MPI_T_PVAR_ALL_HANDLES." to "are ignored when MPI_T_PVAR_ALL_HANDLES is specified." p 24, line 18 Same rationale feeling text here. p 24, line 18 Since a user must just call READ and RESET, what is the purpose of this function? Atomicity, convenience, or both? I think some explanation for the user would be useful here. p 24, line 26 "distinguishing" --> "distinguish" p 25, line 4 Dynamic loading again (see comment for p 18, line 35) p 27, line 9-13 Change "The functions will only write up to len elements into the respective array. If the category contains more than len variables or other categories respectively , the function returns an arbitrary subset; if it contains less than len variables or other categories respectively, all will be returned and the remaining array entries will not be modified." to "Starting from array index 0, each function writes up to len elements into the array. If the category contains more than len elements, the function returns an arbitrary subset. If the category contains less than len elements, the set of elements is returned in the first len array entries, and the remaining array entries are not modified." p 27, line 17 Table 1.3.9?? p 27, line 17-19 Change "None of the error codes returned by an MPI_T routine are fatal to the MPI process or invoke an MPI error handler." to "Errors returned by MPI_T routines are not fatal and do not invoke MPI error handlers." p 27, line 21 This seems to contradict the previous statements somewhat. If it's undefined, then an implementation *may* be fatal. So perhaps we should say that errors are not required to be fatal, or they are not fatal so long as the input parameters are valid, or we recommend that implementors avoid making them fatal ... p 27, line 26 Switch "complying" and extra "s" on "implementation" "a complying MPI implemetations" --> "a compliant MPI_T implementation" -Adam Martin Schulz wrote: >In preparation for the first reading at the March MPI forum, >I have updated ticket #266, the proposal for the MPI Tool >Information Interface and the restructuring of the profiling >or tools chapter. > >https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/266 > >Changes compared to the document at the February >meeting are marked in green, changes caused by the >name change requested by the forum are marked in red. > >Martin > > ><https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/269>________________________________________________________________________ >Martin Schulz, schulzm(a)llnl.gov <mailto:[email protected]>, >http://people.llnl.gov/schulzm >CASC @ Lawrence Livermore National Laboratory, Livermore, USA > > > > > >------------------------------------------------------------------------ > >_______________________________________________ >mpi-forum mailing list >mpi-forum(a)lists.mpi-forum.org >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > >

1 0

Re: [Mpi-forum] Maximum limit of MPI identifiers
by Adam T. Moody 15 Mar '11

15 Mar '11

Hi Martin, Nice work by the tools WG for putting this all together. I've reviewed up to 1.3.7. Here are some comments so far: p 5 line 30, change "." to "," "some of the MPI functions. libpmpi.a" --> "some of the MPI functions, libpmpi.a" p 7, line 44 I'm confused by the phrase "relative mesasure of complexity (basic, detailed or all)". I think this refers to the amount of info provided, so perhaps "relative measure of information provided" or "relative measure of level of details" or something like that would be a better phrase. p 8, line 15 "compexity level" --> something more descriptive, can't think of a good replacement right now, ideally would match replacement phrase above p 7, line 45 Table number seems to be off for Table 1.3.1 vs 1.1? p 8 lines 23-24 The following sounds strange: "These variables can apply globally to no specific object ..." in "These variables can apply globally to no specific object or can refer to a particular MPI object such as ..." Reword this to talk about the objects first, and then the global settings. "A variable may refer to a particular MPI object such as ..., or the variable may refer more generally to the MPI environment of the process." Related question: When you say "global", do you mean the MPI environment of a process, the environment of all processes, or both? (Seems to be answered in Table 1.2) p 8, lines 44-48 I'm confused by the rationale. On the one hand, it says MPI should associate a variable with an object, but then is says it can reuse the variable on all objects of the respective type. I probably need to think about it longer, but perhaps it can be reworded to be clearer. p 9, line 12 Change "the size of the buffer as the length argument (n)." to "the size of the buffer (n) as the length argument." In the current wording, it's not clear whether "n" is the size of the buffer, or whether "n" is the name of the length argument. p 9, line 19 "users" --> "user" p 9, line 43-44 Change "It can be one of the four values listed above." to "It can be one of the four values listed in Section ??." p 9, line 47 Some rewording "The MPI specification does not require all MPI processes to exist before the call to MPI_INIT. If MPI_T is used before MPI_INIT has been called, MPI_T_INIT_THREAD must be called on each process that exists." p 10, line 28 Change "(for the concept of Sessions see Section 1.3.7)" to just "(see Section 1.3.7)" p 10, line 33 A rationale on why MPI_T_INIT_THREAD / MPI_T_FINALIZE can be called multiple times might be useful here. Or perhaps this explanation could be placed in the intro at p 9, lie 29. p 11, line 1 Change "datatype class" to just "class" -- lots of datatype words in that sentence. p 11, line 4 and 5 Table reference seems to be off again (Table 1.3.5?) p 11, line 5 What happens if datatype does not represent a valid datatype? Erroneous call I presume. p 12, line 13 Change "This routine returns, if datatpye represents a valid enumeration datatype, N representing the range of the enumeration 0 to N-1 as well as a string with a name for it." "The arguments name and ..." to "If datatype is a valid enumeration datatype, this routine returns the enumeration range and the name of the datatype. If the range runs from 0 to N-1, the value N is returned in num. The arguments name and ..." p 12, line 15 What happens if datatype is not a valid enumeration datatype? p 12, line 34 We should specify that "item" should be an integer in the range of 0 to N-1, where N is the value returned from the call to MPI_T_DATATYPE_ENUM_GET_INFO. p 14, line 25-29 I'd move rationale after the advice to users discussion of the function to p 14, line 47 p 14, line 38 "processor" --> "process" p 14, line 41 Table 1.3.6 ?? p 15, line 14 Capitalize MPI_INIT and MPI_FINALIZE (lang neutral reference). p 15, line 30-32 Reword first two sentences for clarity. How about... "This routine binds the control variable specified by the argument index to the MPI object specified by the argument obj_handle and returns an allocated handle in the argument handle. The value of index should be in the range 0 to N-1, where N is the number of available control variables as determined from a prior call to MPI_T_CVAR_GET_NUM. The value of obj_handle must be the memory address of the object's MPI handle, and the type of MPI handle must be consistent with the type returned in the bind argument in a prior call to MPI_T_CVAR_GET_INFO." p 16, line 13 Change "appropriate size and fits the entire value ..." to "appropriate size to hold the entire value ..." p 16, line 26 Same as above Question: Is there a collective function to set a variable value on all processes at the same time? Or maybe this is what you mean by consistent? I think it would be good to expand upon this. For example, if you increase the eager limit, you really need to make sure that all receivers increase the limit before a sender sends a new message of that size. -Adam Martin Schulz wrote: >On Mar 15, 2011, at 1:59 PM, Adam T. Moody wrote: > > > >>Hi Marin, >>This is from an earlier email I sent. I didn't get a reply, so I wasn't >>sure whether you missed it or not. The page and line numbers are >>relative to MPI 2.2. >> >>That reminds me. In reviewing the intro text for MPI_Count issues, I >>also came across these lines which may need to be tweaked for MPIT. >>- You may want to warn users about "MPIT" and / or "mpit" prefixes on p >>16 lines 28-30, p 17 lines 42-43, p 18 line 16 and p 18 line 38. >>- You may want to mention that MPIT errors are not fatal on p 22 line 46. >> >> > >Thanks - yes, I missed those. I'll update the document in >a third color :). > >Martin > > > > >>These may be minor issues, but I thought I'd double check with you anyway. >>-Adam >> >> >>Adam T. Moody wrote: >> >> >> >>>Hi Martin, >>>Interesting that this limit still applies. >>> >>>That reminds me. In reviewing the intro text for MPI_Count issues, I >>>also came across these lines which may need to be tweaked for MPIT. >>>- You may want to warn users about "MPIT" and / or "mpit" prefixes on p >>>16 lines 28-30, p 17 lines 42-43, p 18 line 16 and p 18 line 38. >>>- You may want to mention that MPIT errors are not fatal on p 22 line 46. >>>-Adam >>> >>>Martin Schulz wrote: >>> >>> >>> >>> >>> >>>>Hi Adam, >>>> >>>>Thanks again for bringing this up - this is actually still >>>>a valid concern (we had a discussion in the tools WG >>>>today), since the official C99 standard only guarantees >>>>identifiers of up to 31 characters. We'll change our >>>>names accordingly. >>>> >>>>Martin >>>> >>>> >>>> >>>>On Feb 8, 2011, at 2:12 PM, Moody, Adam T. wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>Hi Martin, >>>>>Here is the pointer to the lines about the maximum length of MPI identifiers. I guess this applies to function names and predefined constants, etc. This statement should be updated to address MPIT. >>>>> >>>>>Page 10, line 17-19. >>>>>-Adam >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>________________________________________________________________________ >>>>Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm >>>>CASC @ Lawrence Livermore National Laboratory, Livermore, USA >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> > >________________________________________________________________________ >Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm >CASC @ Lawrence Livermore National Laboratory, Livermore, USA > > > > >

1 0

EuroMPI 2011: Call for Papers
by Rolf Rabenseifner 15 Mar '11

15 Mar '11

Dear HLRS User or member of my course-invitation-list, as member of the program committee, I'm sending you the CFP for the EuroMPI 2011. The deadline for full paper and poster abstract submissions is May 8th, 2011. Best regards Rolf Rabenseifner ------------------------------------------------------------ [Our apologies if you receive multiple copies of this CFP] ------------------------------------------------------------ ********************************** * EuroMPI 2011 Call for Papers * * * * Santorini, Greece * * September 18-21, 2011 * * * * www.eurompi2011.org * ********************************** BACKGROUND AND TOPICS EuroMPI is the primary meeting where the users and developers of MPI and other message-passing programming environments can interact. The 18th European MPI Users' Group Meeting will be a forum for the users and developers of MPI, but also welcome hybrid programing models that combine message passing with programming of modern architectures such as multi-core, or accelerators. Through the presentation of contributed papers, poster presentations and invited talks, attendees will have the opportunity to share ideas and experiences to contribute to the improvement and furthering of message-passing and related parallel programming paradigms. Topics of interest for the meeting include, but are not limited to: * Algorithms using the message-passing paradigm * Applications in science and engineering based on message-passing * User experiences in programming heterogeneous systems using MPI * Tools and environments for programming heterogeneous systems using MPI * MPI implementation issues and improvements * Latest extensions to MPI * MPI for high-performance computing, clusters and grid environments * New message-passing and hybrid parallel programming paradigms * Interaction between message-passing software and hardware * Fault tolerance in message-passing programs * Performance evaluation of MPI applications * Tools and environments for MPI Submissions on applications demonstrating both the potential and shortcomings of message passing programming and specifically MPI are particularly welcome. Proposals for co-located workshops are welcome. EuroMPI 2011 will also hold an outstanding papers session, where the best papers selected by the program committee will be presented. ************************************************************ ************************************************************ Important Dates: * Submission of full papers and poster abstracts: May 8th, 2011 * Author Notification: June 12th, 2011 * Camera Ready papers due: July 10th, 2011 * Tutorials: September 18, 2011 * Conference: September 19-21, 2011 ************************************************************ ************************************************************ General chair: Jack Dongarra (University of Tennessee, USA) Program co-chairs: Yiannis Cotronis (University of Athens, Greece) Anthony Danalis (University of Tennessee, USA) Dimitris Nikolopoulos (University of Crete, Greece) Finance chair: Dimitris Nikolopoulos (University of Crete, Greece) Local arangement chair: Yiannis Cotronis (University of Athens, Greece) Program Committee: Richard Barrett Gil Bloch George Bosilca Aurelien Bouteiller Ron Brightwell Yiannis Cotronis Erik D'Hollander Anthony Danalis Bronis De Supinski J.-C. Desplat Frederic Desprez Jack Dongarra Edgar Gabriel Francisco Javier García Blas Markus Geimer Al Geist Brice Goglin Ganesh Gopalakrishnan Sergei Gorlatch Andrzej Goscinski Richard Graham William Gropp Thomas Herault Torsten Hoefler Joshua Hursey Yutaka Ishikawa Tahar Kechadi Rainer Keller Stefan Lankes Alexey Lastovetsky Pierre Lemarinier Ewing Lusk Tomas Margalef Jean-François Mehaut Bernd Mohr Raymond Namyst Christoph Niethammer Dimitrios Nikolopoulos Rolf Rabenseifner Michael Resch Casiano Rodriguez-Leon Robert Ross Frank Schmitz Martin Schulz Jeff Squyres Rajeev Thakur Vinod Tipparaju Carsten Trinitis Jesper Larsson Träff Jan Westerholm Roland Wismüller

1 0

First reading: MPI_T / Tools Chapter
by Martin Schulz 15 Mar '11

15 Mar '11

In preparation for the first reading at the March MPI forum, I have updated ticket #266, the proposal for the MPI Tool Information Interface and the restructuring of the profiling or tools chapter. https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/266 Changes compared to the document at the February meeting are marked in green, changes caused by the name change requested by the forum are marked in red. Martin ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

Re: [Mpi-forum] First reading: MPI_Count
by Barrett, Brian W 14 Mar '11

14 Mar '11

That makes sense, although it seems like once a ticket has been merged into /approved, it should no longer have it's ticket macros enabled to highlight the changes. I'm not sure whether they should still be marked up in the latex; that seems like an unsustainable path forward, but I have no strong feelings against it. Brian On 3/14/11 3:26 PM, "Jeff Squyres" <jsquyres(a)cisco.com> wrote: >Actually, I just checked. Dave copied the latex from the latest >/approved HEAD -- meaning that all those markups for old tickets are >still there. > >(see http://lists.mpi-forum.org/mpi-forum/2011/01/0884.php for an >explanation of our SVN -- I had to find this earlier today so that I >could remember where things were in SVN :-) ) > >:-\ > >Search for "ticket265" and "ticket269" to find all the changes. > >There's a bunch of places where the coloring mis-behaved, too. So trust >the "ticket265" and "ticket269" annotations more than the colors. :-( > > > >On Mar 14, 2011, at 5:20 PM, Jeff Squyres wrote: > >> On Mar 14, 2011, at 5:14 PM, Barrett, Brian W wrote: >> >>> Why do both documents have both the changes proposed and the >>>non-blocking >>> collectives both marked as changes? It makes it a tad bit harder to >>> determine where there are changes to the document for each proposal :). >> >> Dave (Solt) copied from /approved. >> >> I wonder if he copied from a while ago, though... >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > >-- >Jeff Squyres >jsquyres(a)cisco.com >For corporate legal information go to: >http://www.cisco.com/web/about/doing_business/legal/cri/ > > >_______________________________________________ >mpi-forum mailing list >mpi-forum(a)lists.mpi-forum.org >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > > -- Brian W. Barrett Dept. 1423: Scalable System Software Sandia National Laboratories

1 0

Re: [Mpi-forum] First reading: MPI_Count
by Jeff Squyres 14 Mar '11

14 Mar '11

Actually, I just checked. Dave copied the latex from the latest /approved HEAD -- meaning that all those markups for old tickets are still there. (see http://lists.mpi-forum.org/mpi-forum/2011/01/0884.php for an explanation of our SVN -- I had to find this earlier today so that I could remember where things were in SVN :-) ) :-\ Search for "ticket265" and "ticket269" to find all the changes. There's a bunch of places where the coloring mis-behaved, too. So trust the "ticket265" and "ticket269" annotations more than the colors. :-( On Mar 14, 2011, at 5:20 PM, Jeff Squyres wrote: > On Mar 14, 2011, at 5:14 PM, Barrett, Brian W wrote: > >> Why do both documents have both the changes proposed and the non-blocking >> collectives both marked as changes? It makes it a tad bit harder to >> determine where there are changes to the document for each proposal :). > > Dave (Solt) copied from /approved. > > I wonder if he copied from a while ago, though... > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [Mpi-forum] First reading: MPI_Count
by Jeff Squyres 14 Mar '11

14 Mar '11

On Mar 14, 2011, at 5:14 PM, Barrett, Brian W wrote: > Why do both documents have both the changes proposed and the non-blocking > collectives both marked as changes? It makes it a tad bit harder to > determine where there are changes to the document for each proposal :). Dave (Solt) copied from /approved. I wonder if he copied from a while ago, though... -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [Mpi-forum] First reading: MPI_Count
by Barrett, Brian W 14 Mar '11

14 Mar '11

On 3/14/11 2:57 PM, "Jeff Squyres" <jsquyres(a)cisco.com> wrote: >PDFs have been attached to the 2 MPI_Count tickets for a formal reading >at the Chicago Forum meeting in 2 weeks: > >- General MPI_Count ticket > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 >- "W" versions of some collectives > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/269 > >Remember that the solution we're proposing here is the "minimal" >MPI_Count approach: adding a small number of new functions that take >MPI_Count arguments so that MPI can claim to fully support >arbitrary-sized counts. > >Enjoy your light reading. :-) Why do both documents have both the changes proposed and the non-blocking collectives both marked as changes? It makes it a tad bit harder to determine where there are changes to the document for each proposal :). Brian -- Brian W. Barrett Dept. 1423: Scalable System Software Sandia National Laboratories

1 0

First reading: MPI_Count
by Jeff Squyres 14 Mar '11

14 Mar '11

PDFs have been attached to the 2 MPI_Count tickets for a formal reading at the Chicago Forum meeting in 2 weeks: - General MPI_Count ticket https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265 - "W" versions of some collectives https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/269 Remember that the solution we're proposing here is the "minimal" MPI_Count approach: adding a small number of new functions that take MPI_Count arguments so that MPI can claim to fully support arbitrary-sized counts. Enjoy your light reading. :-) -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0