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

Re: [Mpi-22] [mpi-forum] Error in RMA examples?
by unknown＠example.com 01 Mar '08

01 Mar '08

I'm sure that p is the number of processes in this example and therefore dividing by p is correct, but j always without +1 (because j is a process number) and k always with +1 (because indix is starting with 1 in Fortran). According to official Postscript version of the standard: Page 117 lines 44-45 division by p instead of m is necessary. Line 44 without +1, Line 45 with +1. Page 118 line 45 with +1. Page 120 lines 33 with +1. About Page 117, lines 47-48, I'm not sure. I propose to put this into MPI 2.2, because this example should be tested before correcting it. Best regards Rolf On Fri, 8 Feb 2008 12:06:26 -0300 "Lisandro Dalcin" <dalcinl_at_[hidden]> wrote: >Can someone take a look at the second example in: > >http://www.mpi-forum.org/docs/mpi-20-html/node124.htm > >and also to the example in: > >http://www.mpi-forum.org/docs/mpi-20-html/node125.htm > >I believe in both cases the lines saying > > j = map(i)/p > k = MOD(map(i),p) > >should read > > j = map(i)/m > k = MOD(map(i),m) > > > >Additionally, in the first example again in: > >http://www.mpi-forum.org/docs/mpi-20-html/node124.htm > >in the part where origin and target indices are computed, there are >two lines reading: > > > oindex(total(j) + count(j)) = i > tindex(total(j) + count(j)) = k > >Should'nt it read like this (for indices being zero-based)? > > oindex(total(j) + count(j)) = i - 1 > tindex(total(j) + count(j)) = k - 1 > > >Regards, > >-- >Lisandro Dalcín >--------------- >Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) >Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) >Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) >PTLC - Güemes 3450, (3000) Santa Fe, Argentina >Tel/Fax: +54-(0)342-451.1594 > >_______________________________________________ >mpi-forum mailing list >mpi-forum_at_[hidden] >http://lists.cs.uiuc.edu/mailman/listinfo/mpi-forum Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)

1 0

Proposal: Correction to one-sided completion semantics, Section 6.7
by unknown＠example.com 08 Feb '08

08 Feb '08

dear All, This is a proposal for correction to the semantics of one-sided communication, Section 6.7 (p. 137ff), where there (in my opinion) is a mistake in need of correction. I propose the corrections below for one of the next ballots (probably for MPI 2.2) best regards Jesper ------------- RATIONALE (not to be put in the standard): the example below - which to my understanding should be correct - will fail as rules 5 and 6 are now. To fix, I propose splitting rule 6 into two parts, and making the change from MPI_WIN_POST to MPI_WIN_WAIT in rule 5 ------------- p. 138, line 21-28 - replace 5. A local update of a location in a private window copy in process memory becomes visible in the public window copy at the latest when an ensuing call to MPI_WIN_WAIT, MPI_WIN_FENCE, or MPI_WIN_UNLOCK is executed on that window by the window owner. 6. With active target communication an update by a put or accumulate call to a public window copy becomes visible in the private copy in process memory at the latest when the exposure epoch ends, that is when an ensuing call to either MPI_WIN_WAIT or MPI_WIN_FENCE is executed on that window by the window owner. 7. With passive target communication an update by a put or accumulate call to a public window copy becomes visible in the private copy in process memory at the latest when the next exposure epoch is started, that is when an ensuing call to either MPI_WIN_POST, MPI_WIN_FENCE or MPI_WIN_LOCK is executed on that window by the window owner. p. 138, after line 41 - add explanation/examples The rules (5,6,7) make it possible to switch between synchronization modes as explained on p. 140, in particular between passive synchronization and synchronization with post-wait. The following example illustrates this: [EXAMPLE] Process A Process B --------- --------- MPI_Win_post(A,B) MPI_Win_start(A) MPI_Win_start(A) local update of x in A MPI_Put(A,y) /* to different location */ MPI_Win_complete MPI_Win_complete MPI_Win_wait local access to y ----------------------- MPI_Barrier ----------------------- MPI_Win_lock(A) MPI_Get(A,x) MPI_Put(A,y) /* to different location */ MPI_Win_unlock(A) ----------------------- MPI_Barrier ----------------------- MPI_Win_Post(A) or MPI_Win_lock(A) local access to y in A MPI_Win_wait or MPI_Win_unlock(A) [END OF EXAMPLE] Since MPI_WIN_WAIT makes process A's local update to x visible in the public window (rule 5), it can be accessed by process B after the first barrier in the access epoch started by MPI_WIN_LOCK. Process B's update to the public window copy of y can be accessed by process A after the second barrier (rule 7). The local access to y after MPI_Win_Wait before the first barrier is guaranteed to access the value put by process B (rule 6). Note that in the following (erroneous) passive target communication example, process A is *not* guaranteed to see the value put by process B. In order for A to access the public copy of y it must enter an exposure epoch by calling either MPI_WIN_LOCK, MPI_WIN_POST, or MPI_WIN_FENCE. [EXAMPLE] Process A Process B --------- --------- ----------------------- MPI_Barrier ----------------------- MPI_Win_lock(A) MPI_Put(A,y) MPI_Win_unlock(A) ----------------------- MPI_Barrier ----------------------- local access to y in A /* unsafe! */ [END OF EXAMPLE]

1 0

Re: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type
by unknown＠example.com 06 Feb '08

06 Feb '08

And the length of these datatypes in external32 representation has to be defined if it should be allowed to read/write these datatypes. Hubert Jeff Squyres wrote: > Don't forget MPI::OFFSET (and MPI::AINT). > > And they should be const. ;-) > > > On Jan 24, 2008, at 12:55 PM, Rajeev Thakur wrote: > > >> Is it an interface change? It would be an addition to the set of >> predefined >> types, such as MPI_INT, MPI_CHAR, so it should just work I think. >> >> >>>> MPI Datatype: MPI_OFFSET >>>> Corresponding C type: long long int >>>> Corresponding Fortran type: INTEGER(KIND=MPI_OFFSET_KIND) >>>> >> The corresponding C type should be "implementation defined". It >> could be int >> for example in an implementation that only supports 32-bit file sizes. >> >> Rajeev >> >> >> >>> -----Original Message----- >>> From: mpi-22-bounces_at_[hidden] >>> [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Richard Graham >>> Sent: Thursday, January 24, 2008 11:48 AM >>> To: mpi-22_at_[hidden] >>> Subject: Re: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type >>> >>> Do you think this should go into 2.2 or 3.0 ? I ask not >>> because the change >>> is large, but because it will change the signature of several >>> interface >>> functions (presumably marking the older functions as deprecated - for >>> removal in X number of years). There is another change that >>> I would like to >>> see added to the standard, which is adding a way to convey >>> information >>> between MPI_Alloc_mem() to the functions using this memory, >>> w/o forcing the >>> implementations to try and use all sorts of non-portable >>> solutions to figure >>> out if this memory can be used "as-is" by the network layer, >>> of if it needs >>> to be "prepared" (pinned, and ?). >>> >>> It seems prudent to combine such interface changes into the >>> smallest number >>> of changes (1 is preferred). >>> >>> What do you think ? >>> Rich >>> >>> >>> On 1/24/08 12:18 PM, "Rajeev Thakur" <thakur_at_[hidden]> wrote: >>> >>> >>>> A similar one is needed for MPI_Aint. >>>> >>>> Rajeev >>>> >>>> >>>>> -----Original Message----- >>>>> From: mpi-22-bounces_at_[hidden] >>>>> [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Richard Graham >>>>> Sent: Thursday, January 24, 2008 11:09 AM >>>>> To: mpi-22_at_[hidden] >>>>> Subject: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type >>>>> >>>>> Moving this to the appropriate list. >>>>> >>>>> Rich >>>>> >>>>> ------ Forwarded Message >>>>> From: Robert Latham <robl_at_[hidden]> >>>>> Reply-To: "Mailing list for discussion of MPI 2.1" >>>>> <mpi-21_at_[hidden]> >>>>> Date: Thu, 24 Jan 2008 10:41:52 -0600 >>>>> To: <mpi-21_at_[hidden]> >>>>> Subject: [mpi-21] Proposal: MPI_OFFSET built-in type >>>>> >>>>> I hope this is less contentious than adding 'const' keywords... >>>>> >>>>> >>>>> I would like to propose a new built-in type MPI_OFFSET, >>>>> >>> defined to be >>> >>>>> a type corresponding to INTEGER(KIND=MPI_OFFSET_KIND) or MPI_Offset >>>>> >>>>> This is a minor addition to the standard, which would have >>>>> >>> no impact >>> >>>>> on existing code while serving to simplify code which >>>>> >>> exchanges file >>> >>>>> offsets among processes. >>>>> >>>>> There is a workaround in the standard: a user can define a >>>>> >>> type from >>> >>>>> MPI_BYTE: >>>>> >>>>> MPI_Type_contiguous(sizeof(MPI_Offset), MPI_BYTE, &offtype); >>>>> >>>>> However, it would clearly be more convienient to operate >>>>> >>> on built-in >>> >>>>> types. >>>>> >>>>> MPI Datatype: MPI_OFFSET >>>>> Corresponding C type: long long int >>>>> Corresponding Fortran type: INTEGER(KIND=MPI_OFFSET_KIND) >>>>> >>>>> >>>>> Thanks >>>>> ==rob >>>>> >>>>> -- >>>>> Rob Latham >>>>> Mathematics and Computer Science Division A215 0178 >>>>> >>> EA2D B059 8CDF >>> >>>>> Argonne National Lab, IL USA B29D F333 >>>>> >>> 664A 4280 315B >>> >>>>> _______________________________________________ >>>>> mpi-21 mailing list >>>>> mpi-21_at_[hidden] >>>>> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 >>>>> >>>>> ------ End of Forwarded Message >>>>> >>>>> _______________________________________________ >>>>> mpi-22 mailing list >>>>> mpi-22_at_[hidden] >>>>> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22 >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> mpi-22 mailing list >>>> mpi-22_at_[hidden] >>>> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22 >>>> >>> _______________________________________________ >>> mpi-22 mailing list >>> mpi-22_at_[hidden] >>> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22 >>> >>> >>> >> _______________________________________________ >> mpi-22 mailing list >> mpi-22_at_[hidden] >> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22 >> > > > *

1 0

Re: [mpi-22] [mpi-21] Ballot 4 - MPI_THREAD_FUNNELED - was Re: Attending, topics, etc
by unknown＠example.com 31 Jan '08

31 Jan '08

Dick: Re: > For some time IBM MPI offered a User Space communication mode in which > certain adapter resources are mapped into process space. The mapping > happens at MPI_Init and once it is done, MPI communication calls can > manipulate the adapter to send/recv without a need to switch into the > kernel. The ability to access the adapter is actually managed by AIX on a > per thread basis. That means that on return from MPI_Init, the thread that > called MPI_Init can manipulate the adapter to send/recv but other threads > in the process cannot (yet). Yes, this makes sense to me. What I had intended was something I should have looked up first. Following your reference to MPI_IS_MAIN_THREAD, I see the definition is consistent with what I would consider reasonable. Any thread can call MPI_Init or MPI_Init_thread; all subsequent calls must be funneled through that thread if MPI_THREAD_FUNNELED is the level of support. I was mistakenly taken the main thread to refer to the initial thread created by the OS, which would be overly restrictive. So, I withdraw my suggestion. Bronis > If an appplication thread that did not go through MPI_Init tries to do > send/recv we recognize that it is not yet registered and register it on the > fly. We do this because we added thread support before the MPI Forum > defined MPI_INIT_THREAD with MPI_THREAD_FUNNELED. By the time the Forum > defined MPI_INIT_THREAD we were offering MPI_THREAD_MULTIPLE so stuck with > that even when MPI_THREAD_FUNNELED is requested. > > If we had been starting from scratch we might have decided the for > MPI_THREAD_FUNNELED we would not try to do registration on the fly but for > MPI_THREAD_MULTIPLE we would. > > Dick > > Dick Treumann - MPI Team/TCEM > IBM Systems & Technology Group > Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 > Tele (845) 433-7846 Fax (845) 433-8363 > > > mpi-22-bounces_at_[hidden] wrote on 01/31/2008 12:57:59 PM: > > > > > Jim and Rich: > > > > Then I suggest that fixing this broken semantic decision is > > something that we should consider for MPI 2.2. It should not > > break any existing programs and might even make some existing > > ones standards conforming. > > > > Although I can imagine ways for the MPI implementation to detect > > that the one thread is not the main thread it is not at all clear > > to me how it would matter to the implementation. > > > > Bronis > > > > > > On Thu, 31 Jan 2008, Cownie, James H wrote: > > > > > Because that's how it's always been. We're not adding a restriction > with > > > the change, merely clarifying the existing restriction. > > > > > > -- Jim > > > > > > James Cownie <james.h.cownie_at_[hidden]> > > > SSG/DPD/PAT > > > Tel: +44 117 9071438 > > > > > > ________________________________ > > > > > > From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]] On > > > Behalf Of Richard Graham > > > Sent: 31 January 2008 15:51 > > > To: Mailing list for discussion of MPI 2.1 > > > Subject: Re: [mpi-21] Ballot 4 - MPI_THREAD_FUNNELED - was Re: > > > Attending, topics, etc > > > > > > > > > > > > Why restrict this to a standard specified thread (main thread), why not > > > word it > > > as a singe thread, and let the app decide what thread this is, based > on > > > what > > > ever criteria it wants to use to select this thread ? > > > > > > Rich > > > > > > > > > On 1/31/08 10:27 AM, "Richard Treumann" <treumann_at_[hidden]> wrote: > > > > > > How about:: > > > MPI_THREAD_FUNNELED The process may be multi-threaded, but the > > > application > > > must insure that only the main thread makes MPI calls. > > > > > > > > > Dick Treumann - MPI Team/TCEM > > > IBM Systems & Technology Group > > > Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 > > > Tele (845) 433-7846 Fax (845) 433-8363 > > > > > > > > > mpi-21-bounces_at_[hidden] wrote on 01/31/2008 09:44:08 AM: > > > > > > > A simpler change which would seem to achieve the desired > clarification > > > > would be :- > > > > > > > > MPI_THREAD_FUNNELED The process may be multi-threaded, but only > the > > > > main > > > > thread is allowed to make MPI calls. > > > > > > > > (and you could add > > > > If other threads make MPI calls the behavior is undefined. > > > > if you want to be verbose about it). > > > > > > > > -- Jim > > > > > > > > James Cownie <james.h.cownie_at_[hidden]> > > > > SSG/DPD/PAT > > > > Tel: +44 117 9071438 > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: mpi-21-bounces_at_[hidden] > [mailto:mpi-21-bounces_at_[hidden]] > > > <mailto:mpi-21-bounces_at_[hidden]%5d> > > > > On > > > > > Behalf Of Rolf Rabenseifner > > > > > Sent: 31 January 2008 14:31 > > > > > To: mpi-21_at_[hidden] > > > > > Subject: [mpi-21] Ballot 4 - MPI_THREAD_FUNNELED - was Re: > > > Attending, > > > > > topics, etc > > > > > > > > > > This is a proposal for MPI 2.1, Ballot 4. > > > > > > > > > > I'm asking especially > > > > > Greg Lindahl, > > > > > the participants of the email-discussion in 2007, to review this > > > > proposal. > > > > > > > > > > This is a follow up to: > > > > > Which thread is the funneled thread? > > > > > in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > > > > > errata/index.html > > > > > with mail discussion in > > > > > http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > > > > > errata/discuss/funneled/ > > > > > ___________________________________ > > > > > > > > > > Proposal: > > > > > MPI-2.0 Sect. 8.7.3, MPI_Init_thread, page 196, lines 25-26 read: > > > > > > > > > > MPI_THREAD_FUNNELED The process may be multi-threaded, but only > > > > > the main thread will make MPI calls (all MPI calls are "funneled" > > > > > to the main thread). > > > > > > > > > > but should read: > > > > > > > > > > MPI_THREAD_FUNNELED The process may be multi-threaded, but only > > > > > the main thread will make MPI calls (all MPI calls are "funneled" > > > > > to the main thread, e.g., by using the OpenMP directive "master" > > > > > in the application program). > > > > > ___________________________________ > > > > > Rationale for this clarification from the email from Greg Lindahl: > > > > > The existing document doesn't make it clear that > > > > > the MPI user has to funnel the calls to the main thread; > > > > > it's not the job of the MPI library. I have seen multiple > > > > > MPI users confused by this issue, and when I first read > > > > > this section, I was confused by it, too. > > > > > ___________________________________ > > > > > > > > > > > > > > > Best regards > > > > > Rolf > > > > > > > > > > > > > > > > > > > > > > > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email > > > rabenseifner_at_[hidden] > > > > > High Performance Computing Center (HLRS) . phone > > > ++49(0)711/685-65530 > > > > > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / > > > 685-65832 > > > > > Head of Dpmt Parallel Computing . . . > > > www.hlrs.de/people/rabenseifner > > > > > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > > > > > _______________________________________________ > > > > > mpi-21 mailing list > > > > > mpi-21_at_[hidden] > > > > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > > > --------------------------------------------------------------------- > > > > Intel Corporation (UK) Limited > > > > Registered No. 1134945 (England) > > > > Registered Office: Pipers Way, Swindon SN3 1RJ > > > > VAT No: 860 2173 47 > > > > > > > > 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-21 mailing list > > > > mpi-21_at_[hidden] > > > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > > > > > ________________________________ > > > > > > _______________________________________________ > > > mpi-21 mailing list > > > mpi-21_at_[hidden] > > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > > > > > > > > > > > --------------------------------------------------------------------- > > > Intel Corporation (UK) Limited > > > Registered No. 1134945 (England) > > > Registered Office: Pipers Way, Swindon SN3 1RJ > > > VAT No: 860 2173 47 > > > > > > 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.cs.uiuc.edu/mailman/listinfo/mpi-22

1 0

Re: [mpi-22] [mpi-21] Ballot 4 - MPI_THREAD_FUNNELED - was Re: Attending, topics, etc
by unknown＠example.com 31 Jan '08

31 Jan '08

Hi Bronis For some time IBM MPI offered a User Space communication mode in which certain adapter resources are mapped into process space. The mapping happens at MPI_Init and once it is done, MPI communication calls can manipulate the adapter to send/recv without a need to switch into the kernel. The ability to access the adapter is actually managed by AIX on a per thread basis. That means that on return from MPI_Init, the thread that called MPI_Init can manipulate the adapter to send/recv but other threads in the process cannot (yet). If an appplication thread that did not go through MPI_Init tries to do send/recv we recognize that it is not yet registered and register it on the fly. We do this because we added thread support before the MPI Forum defined MPI_INIT_THREAD with MPI_THREAD_FUNNELED. By the time the Forum defined MPI_INIT_THREAD we were offering MPI_THREAD_MULTIPLE so stuck with that even when MPI_THREAD_FUNNELED is requested. If we had been starting from scratch we might have decided the for MPI_THREAD_FUNNELED we would not try to do registration on the fly but for MPI_THREAD_MULTIPLE we would. Dick Dick Treumann - MPI Team/TCEM IBM Systems & Technology Group Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 mpi-22-bounces_at_[hidden] wrote on 01/31/2008 12:57:59 PM: > > Jim and Rich: > > Then I suggest that fixing this broken semantic decision is > something that we should consider for MPI 2.2. It should not > break any existing programs and might even make some existing > ones standards conforming. > > Although I can imagine ways for the MPI implementation to detect > that the one thread is not the main thread it is not at all clear > to me how it would matter to the implementation. > > Bronis > > > On Thu, 31 Jan 2008, Cownie, James H wrote: > > > Because that's how it's always been. We're not adding a restriction with > > the change, merely clarifying the existing restriction. > > > > -- Jim > > > > James Cownie <james.h.cownie_at_[hidden]> > > SSG/DPD/PAT > > Tel: +44 117 9071438 > > > > ________________________________ > > > > From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]] On > > Behalf Of Richard Graham > > Sent: 31 January 2008 15:51 > > To: Mailing list for discussion of MPI 2.1 > > Subject: Re: [mpi-21] Ballot 4 - MPI_THREAD_FUNNELED - was Re: > > Attending, topics, etc > > > > > > > > Why restrict this to a standard specified thread (main thread), why not > > word it > > as a singe thread, and let the app decide what thread this is, based on > > what > > ever criteria it wants to use to select this thread ? > > > > Rich > > > > > > On 1/31/08 10:27 AM, "Richard Treumann" <treumann_at_[hidden]> wrote: > > > > How about:: > > MPI_THREAD_FUNNELED The process may be multi-threaded, but the > > application > > must insure that only the main thread makes MPI calls. > > > > > > Dick Treumann - MPI Team/TCEM > > IBM Systems & Technology Group > > Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 > > Tele (845) 433-7846 Fax (845) 433-8363 > > > > > > mpi-21-bounces_at_[hidden] wrote on 01/31/2008 09:44:08 AM: > > > > > A simpler change which would seem to achieve the desired clarification > > > would be :- > > > > > > MPI_THREAD_FUNNELED The process may be multi-threaded, but only the > > > main > > > thread is allowed to make MPI calls. > > > > > > (and you could add > > > If other threads make MPI calls the behavior is undefined. > > > if you want to be verbose about it). > > > > > > -- Jim > > > > > > James Cownie <james.h.cownie_at_[hidden]> > > > SSG/DPD/PAT > > > Tel: +44 117 9071438 > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]] > > <mailto:mpi-21-bounces_at_[hidden]%5d> > > > On > > > > Behalf Of Rolf Rabenseifner > > > > Sent: 31 January 2008 14:31 > > > > To: mpi-21_at_[hidden] > > > > Subject: [mpi-21] Ballot 4 - MPI_THREAD_FUNNELED - was Re: > > Attending, > > > > topics, etc > > > > > > > > This is a proposal for MPI 2.1, Ballot 4. > > > > > > > > I'm asking especially > > > > Greg Lindahl, > > > > the participants of the email-discussion in 2007, to review this > > > proposal. > > > > > > > > This is a follow up to: > > > > Which thread is the funneled thread? > > > > in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > > > > errata/index.html > > > > with mail discussion in > > > > http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > > > > errata/discuss/funneled/ > > > > ___________________________________ > > > > > > > > Proposal: > > > > MPI-2.0 Sect. 8.7.3, MPI_Init_thread, page 196, lines 25-26 read: > > > > > > > > MPI_THREAD_FUNNELED The process may be multi-threaded, but only > > > > the main thread will make MPI calls (all MPI calls are "funneled" > > > > to the main thread). > > > > > > > > but should read: > > > > > > > > MPI_THREAD_FUNNELED The process may be multi-threaded, but only > > > > the main thread will make MPI calls (all MPI calls are "funneled" > > > > to the main thread, e.g., by using the OpenMP directive "master" > > > > in the application program). > > > > ___________________________________ > > > > Rationale for this clarification from the email from Greg Lindahl: > > > > The existing document doesn't make it clear that > > > > the MPI user has to funnel the calls to the main thread; > > > > it's not the job of the MPI library. I have seen multiple > > > > MPI users confused by this issue, and when I first read > > > > this section, I was confused by it, too. > > > > ___________________________________ > > > > > > > > > > > > Best regards > > > > Rolf > > > > > > > > > > > > > > > > > > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email > > rabenseifner_at_[hidden] > > > > High Performance Computing Center (HLRS) . phone > > ++49(0)711/685-65530 > > > > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / > > 685-65832 > > > > Head of Dpmt Parallel Computing . . . > > www.hlrs.de/people/rabenseifner > > > > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > > > > _______________________________________________ > > > > mpi-21 mailing list > > > > mpi-21_at_[hidden] > > > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > > --------------------------------------------------------------------- > > > Intel Corporation (UK) Limited > > > Registered No. 1134945 (England) > > > Registered Office: Pipers Way, Swindon SN3 1RJ > > > VAT No: 860 2173 47 > > > > > > 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-21 mailing list > > > mpi-21_at_[hidden] > > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > > > ________________________________ > > > > _______________________________________________ > > mpi-21 mailing list > > mpi-21_at_[hidden] > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > > > > > > > --------------------------------------------------------------------- > > Intel Corporation (UK) Limited > > Registered No. 1134945 (England) > > Registered Office: Pipers Way, Swindon SN3 1RJ > > VAT No: 860 2173 47 > > > > 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.cs.uiuc.edu/mailman/listinfo/mpi-22 *

1 0

Re: [mpi-22] [mpi-21] Ballot 4 - MPI_THREAD_FUNNELED - was Re: Attending, topics, etc
by unknown＠example.com 31 Jan '08

31 Jan '08

Jim and Rich: Then I suggest that fixing this broken semantic decision is something that we should consider for MPI 2.2. It should not break any existing programs and might even make some existing ones standards conforming. Although I can imagine ways for the MPI implementation to detect that the one thread is not the main thread it is not at all clear to me how it would matter to the implementation. Bronis On Thu, 31 Jan 2008, Cownie, James H wrote: > Because that's how it's always been. We're not adding a restriction with > the change, merely clarifying the existing restriction. > > -- Jim > > James Cownie <james.h.cownie_at_[hidden]> > SSG/DPD/PAT > Tel: +44 117 9071438 > > ________________________________ > > From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]] On > Behalf Of Richard Graham > Sent: 31 January 2008 15:51 > To: Mailing list for discussion of MPI 2.1 > Subject: Re: [mpi-21] Ballot 4 - MPI_THREAD_FUNNELED - was Re: > Attending, topics, etc > > > > Why restrict this to a standard specified thread (main thread), why not > word it > as a singe thread, and let the app decide what thread this is, based on > what > ever criteria it wants to use to select this thread ? > > Rich > > > On 1/31/08 10:27 AM, "Richard Treumann" <treumann_at_[hidden]> wrote: > > How about:: > MPI_THREAD_FUNNELED The process may be multi-threaded, but the > application > must insure that only the main thread makes MPI calls. > > > Dick Treumann - MPI Team/TCEM > IBM Systems & Technology Group > Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 > Tele (845) 433-7846 Fax (845) 433-8363 > > > mpi-21-bounces_at_[hidden] wrote on 01/31/2008 09:44:08 AM: > > > A simpler change which would seem to achieve the desired clarification > > would be :- > > > > MPI_THREAD_FUNNELED The process may be multi-threaded, but only the > > main > > thread is allowed to make MPI calls. > > > > (and you could add > > If other threads make MPI calls the behavior is undefined. > > if you want to be verbose about it). > > > > -- Jim > > > > James Cownie <james.h.cownie_at_[hidden]> > > SSG/DPD/PAT > > Tel: +44 117 9071438 > > > > > > > > > > > -----Original Message----- > > > From: mpi-21-bounces_at_[hidden] [mailto:mpi-21-bounces_at_[hidden]] > <mailto:mpi-21-bounces_at_[hidden]%5d> > > On > > > Behalf Of Rolf Rabenseifner > > > Sent: 31 January 2008 14:31 > > > To: mpi-21_at_[hidden] > > > Subject: [mpi-21] Ballot 4 - MPI_THREAD_FUNNELED - was Re: > Attending, > > > topics, etc > > > > > > This is a proposal for MPI 2.1, Ballot 4. > > > > > > I'm asking especially > > > Greg Lindahl, > > > the participants of the email-discussion in 2007, to review this > > proposal. > > > > > > This is a follow up to: > > > Which thread is the funneled thread? > > > in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > > > errata/index.html > > > with mail discussion in > > > http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi- > > > errata/discuss/funneled/ > > > ___________________________________ > > > > > > Proposal: > > > MPI-2.0 Sect. 8.7.3, MPI_Init_thread, page 196, lines 25-26 read: > > > > > > MPI_THREAD_FUNNELED The process may be multi-threaded, but only > > > the main thread will make MPI calls (all MPI calls are "funneled" > > > to the main thread). > > > > > > but should read: > > > > > > MPI_THREAD_FUNNELED The process may be multi-threaded, but only > > > the main thread will make MPI calls (all MPI calls are "funneled" > > > to the main thread, e.g., by using the OpenMP directive "master" > > > in the application program). > > > ___________________________________ > > > Rationale for this clarification from the email from Greg Lindahl: > > > The existing document doesn't make it clear that > > > the MPI user has to funnel the calls to the main thread; > > > it's not the job of the MPI library. I have seen multiple > > > MPI users confused by this issue, and when I first read > > > this section, I was confused by it, too. > > > ___________________________________ > > > > > > > > > Best regards > > > Rolf > > > > > > > > > > > > > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email > rabenseifner_at_[hidden] > > > High Performance Computing Center (HLRS) . phone > ++49(0)711/685-65530 > > > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / > 685-65832 > > > Head of Dpmt Parallel Computing . . . > www.hlrs.de/people/rabenseifner > > > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > > > _______________________________________________ > > > mpi-21 mailing list > > > mpi-21_at_[hidden] > > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > --------------------------------------------------------------------- > > Intel Corporation (UK) Limited > > Registered No. 1134945 (England) > > Registered Office: Pipers Way, Swindon SN3 1RJ > > VAT No: 860 2173 47 > > > > 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-21 mailing list > > mpi-21_at_[hidden] > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > ________________________________ > > _______________________________________________ > mpi-21 mailing list > mpi-21_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > > > --------------------------------------------------------------------- > Intel Corporation (UK) Limited > Registered No. 1134945 (England) > Registered Office: Pipers Way, Swindon SN3 1RJ > VAT No: 860 2173 47 > > 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

Re: [mpi-22] C++ MPI constants
by unknown＠example.com 29 Jan '08

29 Jan '08

This is a follow up to: MPI C++ Constants conflict with stdio in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/index.… with mail discussion in http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… ___________________________________ I want to add the following first part of a mail in another track to this track because it mentions that the C++ problem with SEEK_SET, SEEK_CUR, and SEEK_END does not only exist with stdio.h but also with fcntl.h . ------- ___________________________________ forwarded mail: (From Shared File Pointers, http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-errata/discus… ) Date: Thu, 21 Dec 2000 14:53:30 -0500 (EST) From: Leonard Wisniewski - Sun High Performance Computing <lenbo_at_XXXXXXXXXXXXXXXXXXX> Subject: Two MPI I/O questions To: mpi-comments_at_XXXXXXXXXXXXX Cc: thakur_at_XXXXXXXXXXX I have two MPI I/O questions and I was hoping somebody on this alias would know one or both answers. 1) The MPI C++ bindings for SEEK_SET, SEEK_CUR, and SEEK_END will conflict when used in a source file in which /usr/include/fcntl.h is #include'd. I recall seeing some discussion on this topic, but I don't recall the resolution. 2) ... [this topic is not part of the SEEK_SET, SEEK_CUR, and SEEK_END problem, therefore removed for this mail track] ___________________________________ Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)

1 0

Re: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type
by unknown＠example.com 28 Jan '08

28 Jan '08

On Mon, Jan 28, 2008 at 10:55:17AM -0600, Rajeev Thakur wrote: > MPI_Aint is also used for extent of a datatype and size of a window, which > one may want to communicate. > One does want to communicate those things. Having an MPI_AINT would be the easiest solution, but not the cleanest or most correct... If new types were introduced, the interfaces should be changed correspondingly (eg. MPI_Count for count arguments), and that would be a big change... I don't want to push the point, though. Jesper > Rajeev > > > > -----Original Message----- > > From: mpi-22-bounces_at_[hidden] > > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jesper Larsson Traeff > > Sent: Monday, January 28, 2008 7:48 AM > > To: Discussion of MPI Standard version 2.2 > > Subject: Re: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type > > > > On Thu, Jan 24, 2008 at 11:18:52AM -0600, Rajeev Thakur wrote: > > > A similar one is needed for MPI_Aint. > > > > > yes, it is needed... but maybe it was really not intended in > > MPI-1 that > > addresses be sent around, and therefore there was no MPI_AINT? > > > > A cleaner (overly puristic?) solution would be to introduce > > more types > > with MPI types only for those really intended to be > > communicable, e.g. > > MPI_COUNT (MPI type for new MPI_Count type), MPI_OFFSET (for > > MPI_Offset), ... > > Unfortunately, introducing new types would/could have large > > consequences > > for the interface... > > > > Related concerns for MPI-3.0 discussion: can MPI_Op's be sent (useful > > when writing MPI correctness checking software)? can MPI_Datatypes be > > sent (currently not - but would be very useful in combination > > with more > > functionality for manipulating datatypes)? > > > > Jesper > > > > > Rajeev > > > > > > > -----Original Message----- > > > > From: mpi-22-bounces_at_[hidden] > > > > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Richard Graham > > > > Sent: Thursday, January 24, 2008 11:09 AM > > > > To: mpi-22_at_[hidden] > > > > Subject: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type > > > > > > > > Moving this to the appropriate list. > > > > > > > > Rich > > > > > > > > ------ Forwarded Message > > > > From: Robert Latham <robl_at_[hidden]> > > > > Reply-To: "Mailing list for discussion of MPI 2.1" > > > > <mpi-21_at_[hidden]> > > > > Date: Thu, 24 Jan 2008 10:41:52 -0600 > > > > To: <mpi-21_at_[hidden]> > > > > Subject: [mpi-21] Proposal: MPI_OFFSET built-in type > > > > > > > > I hope this is less contentious than adding 'const' keywords... > > > > > > > > > > > > I would like to propose a new built-in type MPI_OFFSET, > > defined to be > > > > a type corresponding to INTEGER(KIND=MPI_OFFSET_KIND) or > > MPI_Offset > > > > > > > > This is a minor addition to the standard, which would > > have no impact > > > > on existing code while serving to simplify code which > > exchanges file > > > > offsets among processes. > > > > > > > > There is a workaround in the standard: a user can define > > a type from > > > > MPI_BYTE: > > > > > > > > MPI_Type_contiguous(sizeof(MPI_Offset), MPI_BYTE, &offtype); > > > > > > > > However, it would clearly be more convienient to operate > > on built-in > > > > types. > > > > > > > > MPI Datatype: MPI_OFFSET > > > > Corresponding C type: long long int > > > > Corresponding Fortran type: INTEGER(KIND=MPI_OFFSET_KIND) > > > > > > > > > > > > Thanks > > > > ==rob > > > > > > > > -- > > > > Rob Latham > > > > Mathematics and Computer Science Division A215 0178 > > EA2D B059 8CDF > > > > Argonne National Lab, IL USA B29D F333 > > 664A 4280 315B > > > > _______________________________________________ > > > > mpi-21 mailing list > > > > mpi-21_at_[hidden] > > > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > > > > > > > ------ End of Forwarded Message > > > > > > > > _______________________________________________ > > > > mpi-22 mailing list > > > > mpi-22_at_[hidden] > > > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22 > > > > > > > > > > > > > > _______________________________________________ > > > mpi-22 mailing list > > > mpi-22_at_[hidden] > > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22 > > _______________________________________________ > > mpi-22 mailing list > > mpi-22_at_[hidden] > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22 > > > > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22

1 0

Re: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type
by unknown＠example.com 28 Jan '08

28 Jan '08

> Unfortunately, introducing new types would/could have large > consequences for the interface... Will it change the interface much? It just adds to the list of predefined types. Rajeev > -----Original Message----- > From: mpi-22-bounces_at_[hidden] > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jesper Larsson Traeff > Sent: Monday, January 28, 2008 7:48 AM > To: Discussion of MPI Standard version 2.2 > Subject: Re: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type > > On Thu, Jan 24, 2008 at 11:18:52AM -0600, Rajeev Thakur wrote: > > A similar one is needed for MPI_Aint. > > > yes, it is needed... but maybe it was really not intended in > MPI-1 that > addresses be sent around, and therefore there was no MPI_AINT? > > A cleaner (overly puristic?) solution would be to introduce > more types > with MPI types only for those really intended to be > communicable, e.g. > MPI_COUNT (MPI type for new MPI_Count type), MPI_OFFSET (for > MPI_Offset), ... > Unfortunately, introducing new types would/could have large > consequences > for the interface... > > Related concerns for MPI-3.0 discussion: can MPI_Op's be sent (useful > when writing MPI correctness checking software)? can MPI_Datatypes be > sent (currently not - but would be very useful in combination > with more > functionality for manipulating datatypes)? > > Jesper > > > Rajeev > > > > > -----Original Message----- > > > From: mpi-22-bounces_at_[hidden] > > > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Richard Graham > > > Sent: Thursday, January 24, 2008 11:09 AM > > > To: mpi-22_at_[hidden] > > > Subject: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type > > > > > > Moving this to the appropriate list. > > > > > > Rich > > > > > > ------ Forwarded Message > > > From: Robert Latham <robl_at_[hidden]> > > > Reply-To: "Mailing list for discussion of MPI 2.1" > > > <mpi-21_at_[hidden]> > > > Date: Thu, 24 Jan 2008 10:41:52 -0600 > > > To: <mpi-21_at_[hidden]> > > > Subject: [mpi-21] Proposal: MPI_OFFSET built-in type > > > > > > I hope this is less contentious than adding 'const' keywords... > > > > > > > > > I would like to propose a new built-in type MPI_OFFSET, > defined to be > > > a type corresponding to INTEGER(KIND=MPI_OFFSET_KIND) or > MPI_Offset > > > > > > This is a minor addition to the standard, which would > have no impact > > > on existing code while serving to simplify code which > exchanges file > > > offsets among processes. > > > > > > There is a workaround in the standard: a user can define > a type from > > > MPI_BYTE: > > > > > > MPI_Type_contiguous(sizeof(MPI_Offset), MPI_BYTE, &offtype); > > > > > > However, it would clearly be more convienient to operate > on built-in > > > types. > > > > > > MPI Datatype: MPI_OFFSET > > > Corresponding C type: long long int > > > Corresponding Fortran type: INTEGER(KIND=MPI_OFFSET_KIND) > > > > > > > > > Thanks > > > ==rob > > > > > > -- > > > Rob Latham > > > Mathematics and Computer Science Division A215 0178 > EA2D B059 8CDF > > > Argonne National Lab, IL USA B29D F333 > 664A 4280 315B > > > _______________________________________________ > > > mpi-21 mailing list > > > mpi-21_at_[hidden] > > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > > > > > ------ End of Forwarded Message > > > > > > _______________________________________________ > > > mpi-22 mailing list > > > mpi-22_at_[hidden] > > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22 > > > > > > > > > > _______________________________________________ > > mpi-22 mailing list > > mpi-22_at_[hidden] > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22 > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22 > >

1 0

Re: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type
by unknown＠example.com 28 Jan '08

28 Jan '08

MPI_Aint is also used for extent of a datatype and size of a window, which one may want to communicate. Rajeev > -----Original Message----- > From: mpi-22-bounces_at_[hidden] > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jesper Larsson Traeff > Sent: Monday, January 28, 2008 7:48 AM > To: Discussion of MPI Standard version 2.2 > Subject: Re: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type > > On Thu, Jan 24, 2008 at 11:18:52AM -0600, Rajeev Thakur wrote: > > A similar one is needed for MPI_Aint. > > > yes, it is needed... but maybe it was really not intended in > MPI-1 that > addresses be sent around, and therefore there was no MPI_AINT? > > A cleaner (overly puristic?) solution would be to introduce > more types > with MPI types only for those really intended to be > communicable, e.g. > MPI_COUNT (MPI type for new MPI_Count type), MPI_OFFSET (for > MPI_Offset), ... > Unfortunately, introducing new types would/could have large > consequences > for the interface... > > Related concerns for MPI-3.0 discussion: can MPI_Op's be sent (useful > when writing MPI correctness checking software)? can MPI_Datatypes be > sent (currently not - but would be very useful in combination > with more > functionality for manipulating datatypes)? > > Jesper > > > Rajeev > > > > > -----Original Message----- > > > From: mpi-22-bounces_at_[hidden] > > > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Richard Graham > > > Sent: Thursday, January 24, 2008 11:09 AM > > > To: mpi-22_at_[hidden] > > > Subject: [mpi-22] FW: [mpi-21] Proposal: MPI_OFFSET built-in type > > > > > > Moving this to the appropriate list. > > > > > > Rich > > > > > > ------ Forwarded Message > > > From: Robert Latham <robl_at_[hidden]> > > > Reply-To: "Mailing list for discussion of MPI 2.1" > > > <mpi-21_at_[hidden]> > > > Date: Thu, 24 Jan 2008 10:41:52 -0600 > > > To: <mpi-21_at_[hidden]> > > > Subject: [mpi-21] Proposal: MPI_OFFSET built-in type > > > > > > I hope this is less contentious than adding 'const' keywords... > > > > > > > > > I would like to propose a new built-in type MPI_OFFSET, > defined to be > > > a type corresponding to INTEGER(KIND=MPI_OFFSET_KIND) or > MPI_Offset > > > > > > This is a minor addition to the standard, which would > have no impact > > > on existing code while serving to simplify code which > exchanges file > > > offsets among processes. > > > > > > There is a workaround in the standard: a user can define > a type from > > > MPI_BYTE: > > > > > > MPI_Type_contiguous(sizeof(MPI_Offset), MPI_BYTE, &offtype); > > > > > > However, it would clearly be more convienient to operate > on built-in > > > types. > > > > > > MPI Datatype: MPI_OFFSET > > > Corresponding C type: long long int > > > Corresponding Fortran type: INTEGER(KIND=MPI_OFFSET_KIND) > > > > > > > > > Thanks > > > ==rob > > > > > > -- > > > Rob Latham > > > Mathematics and Computer Science Division A215 0178 > EA2D B059 8CDF > > > Argonne National Lab, IL USA B29D F333 > 664A 4280 315B > > > _______________________________________________ > > > mpi-21 mailing list > > > mpi-21_at_[hidden] > > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21 > > > > > > ------ End of Forwarded Message > > > > > > _______________________________________________ > > > mpi-22 mailing list > > > mpi-22_at_[hidden] > > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22 > > > > > > > > > > _______________________________________________ > > mpi-22 mailing list > > mpi-22_at_[hidden] > > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22 > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-22 > >

1 0