August 2013 - mpiwg-tools - mailman3.cels.anl.gov

Re: [mpiwg-tools] Tools WG webex tomorrow!
by Kathryn Mohror 27 Aug '13

27 Aug '13

For the reset case, how about this text addition: (even if there are no valid handles or all are read-only) Kathryn On Aug 27, 2013, at 1:23 PM, Kathryn Mohror <kathryn(a)llnl.gov> wrote: > Okay, I'll update the text on the ticket. I like this wording better. > > Kathryn > > On Aug 27, 2013, at 1:18 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > >> I have a better suggestion (sorry... this is what happens at the last second...): >> >> Current from Kathryn's PDF: >> >> If the constant MPI_T_PVAR_ALL_HANDLES is passed in handle, the MPI implementation attempts to start all variables within the session identified by the parameter session for which handles have been allocated. In this case, the routine returns MPI_SUCCESS if all variables are started successfully, otherwise MPI_T_ERR_PVAR_NO_STARTSTOP is returned. MPI_SUCCESS is also returned if MPI_T_PVAR_ALL_HANDLES is passed in handles and if no handles are valid for session or all valid handles represent continuous variables. Continuous variables and variables that are already started are ignored when MPI_T_PVAR_ALL_HANDLES is specified. >> >> Jeff's suggestion (delete the new sentence and add the text in ***): >> >> If the constant MPI_T_PVAR_ALL_HANDLES is passed in handle, the MPI implementation attempts to start all variables within the session identified by the parameter session for which handles have been allocated. In this case, the routine returns MPI_SUCCESS if all variables are started successfully (even if there are no non-continuous variables to be started), otherwise MPI_T_ERR_PVAR_NO_STARTSTOP is returned. Continuous variables and variables that are already started are ignored when MPI_T_PVAR_ALL_HANDLES is specified. >> >> >> >> >> On Aug 27, 2013, at 12:09 PM, Kathryn Mohror <kathryn(a)llnl.gov> wrote: >> >>> I made a ticket for this (#391) and uploaded a pdf with the proposed changes (also attached). >>> >>> Is anyone opposed to putting this up for a reading as errata? >>> >>> Kathryn >>> >>> >>> On Aug 27, 2013, at 5:14 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: >>> >>>> On Aug 26, 2013, at 7:23 PM, "Schulz, Martin" <schulz6(a)llnl.gov> wrote: >>>> >>>>>> I am now on the SUCCESS side of the fence. Does it need to be clarified as an errata? I would suggest (from 3.0 clean doc): >>>> >>>> Just to be totally clear: I don't really care which way it goes. I just saw this issue as an ambiguity that should be resolved. >>>> >>>>>> page 580, line 41: >>>>>> In this case, the routine returns MPI_SUCCESS if all variables are started successfully, otherwise MPI_T_ERR_PVAR_NO_STARTSTOP is returned. MPI_SUCCESS is also returned if no handles are valid for session and MPI_T_PVAR_ALL_HANDLES is passed in handle. >>>>> >>>>> Hmm - I fear we would have to be even more explicit: MPI_SUCCESS is also returned if MPI_T_PVAR_ALL_HANDLES is passed in handles and if no handles are valid for session or all valid handles represent continuous (read only for reset) variables. >>>> >>>> +1. >>>> >>>> -- >>>> Jeff Squyres >>>> jsquyres(a)cisco.com >>>> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ >>>> >>>> _______________________________________________ >>>> mpiwg-tools mailing list >>>> mpiwg-tools(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >>> >>> ______________________________________________________________ >>> Kathryn Mohror, kathryn(a)llnl.gov, http://people.llnl.gov/mohror1 >>> CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA >>> >>> >>> >>> >>> <tools-3.pdf> >> >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> _______________________________________________ >> mpiwg-tools mailing list >> mpiwg-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > > ______________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov, http://people.llnl.gov/mohror1 > CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA > > > > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools ______________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://people.llnl.gov/mohror1 CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0

Re: [mpiwg-tools] Tools WG webex tomorrow!
by Kathryn Mohror 27 Aug '13

27 Aug '13

Okay, I'll update the text on the ticket. I like this wording better. Kathryn On Aug 27, 2013, at 1:18 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > I have a better suggestion (sorry... this is what happens at the last second...): > > Current from Kathryn's PDF: > > If the constant MPI_T_PVAR_ALL_HANDLES is passed in handle, the MPI implementation attempts to start all variables within the session identified by the parameter session for which handles have been allocated. In this case, the routine returns MPI_SUCCESS if all variables are started successfully, otherwise MPI_T_ERR_PVAR_NO_STARTSTOP is returned. MPI_SUCCESS is also returned if MPI_T_PVAR_ALL_HANDLES is passed in handles and if no handles are valid for session or all valid handles represent continuous variables. Continuous variables and variables that are already started are ignored when MPI_T_PVAR_ALL_HANDLES is specified. > > Jeff's suggestion (delete the new sentence and add the text in ***): > > If the constant MPI_T_PVAR_ALL_HANDLES is passed in handle, the MPI implementation attempts to start all variables within the session identified by the parameter session for which handles have been allocated. In this case, the routine returns MPI_SUCCESS if all variables are started successfully (even if there are no non-continuous variables to be started), otherwise MPI_T_ERR_PVAR_NO_STARTSTOP is returned. Continuous variables and variables that are already started are ignored when MPI_T_PVAR_ALL_HANDLES is specified. > > > > > On Aug 27, 2013, at 12:09 PM, Kathryn Mohror <kathryn(a)llnl.gov> wrote: > >> I made a ticket for this (#391) and uploaded a pdf with the proposed changes (also attached). >> >> Is anyone opposed to putting this up for a reading as errata? >> >> Kathryn >> >> >> On Aug 27, 2013, at 5:14 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: >> >>> On Aug 26, 2013, at 7:23 PM, "Schulz, Martin" <schulz6(a)llnl.gov> wrote: >>> >>>>> I am now on the SUCCESS side of the fence. Does it need to be clarified as an errata? I would suggest (from 3.0 clean doc): >>> >>> Just to be totally clear: I don't really care which way it goes. I just saw this issue as an ambiguity that should be resolved. >>> >>>>> page 580, line 41: >>>>> In this case, the routine returns MPI_SUCCESS if all variables are started successfully, otherwise MPI_T_ERR_PVAR_NO_STARTSTOP is returned. MPI_SUCCESS is also returned if no handles are valid for session and MPI_T_PVAR_ALL_HANDLES is passed in handle. >>>> >>>> Hmm - I fear we would have to be even more explicit: MPI_SUCCESS is also returned if MPI_T_PVAR_ALL_HANDLES is passed in handles and if no handles are valid for session or all valid handles represent continuous (read only for reset) variables. >>> >>> +1. >>> >>> -- >>> Jeff Squyres >>> jsquyres(a)cisco.com >>> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ >>> >>> _______________________________________________ >>> mpiwg-tools mailing list >>> mpiwg-tools(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >> >> ______________________________________________________________ >> Kathryn Mohror, kathryn(a)llnl.gov, http://people.llnl.gov/mohror1 >> CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA >> >> >> >> >> <tools-3.pdf> > > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools ______________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://people.llnl.gov/mohror1 CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0

Re: [mpiwg-tools] Tools WG webex tomorrow!
by Jeff Squyres (jsquyres) 27 Aug '13

27 Aug '13

On Aug 27, 2013, at 4:18 PM, "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> wrote: > Jeff's suggestion (delete the new sentence and add the text in ***): Hah -- I forgot to mark the new text with ***. Here it is: > If the constant MPI_T_PVAR_ALL_HANDLES is passed in handle, the MPI implementation attempts to start all variables within the session identified by the parameter session for which handles have been allocated. In this case, the routine returns MPI_SUCCESS if all variables are started successfully ***(even if there are no non-continuous variables to be started)***, otherwise MPI_T_ERR_PVAR_NO_STARTSTOP is returned. Continuous variables and variables that are already started are ignored when MPI_T_PVAR_ALL_HANDLES is specified. -- 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: [mpiwg-tools] Tools WG webex tomorrow!
by Jeff Squyres (jsquyres) 27 Aug '13

27 Aug '13

I have a better suggestion (sorry... this is what happens at the last second...): Current from Kathryn's PDF: If the constant MPI_T_PVAR_ALL_HANDLES is passed in handle, the MPI implementation attempts to start all variables within the session identified by the parameter session for which handles have been allocated. In this case, the routine returns MPI_SUCCESS if all variables are started successfully, otherwise MPI_T_ERR_PVAR_NO_STARTSTOP is returned. MPI_SUCCESS is also returned if MPI_T_PVAR_ALL_HANDLES is passed in handles and if no handles are valid for session or all valid handles represent continuous variables. Continuous variables and variables that are already started are ignored when MPI_T_PVAR_ALL_HANDLES is specified. Jeff's suggestion (delete the new sentence and add the text in ***): If the constant MPI_T_PVAR_ALL_HANDLES is passed in handle, the MPI implementation attempts to start all variables within the session identified by the parameter session for which handles have been allocated. In this case, the routine returns MPI_SUCCESS if all variables are started successfully (even if there are no non-continuous variables to be started), otherwise MPI_T_ERR_PVAR_NO_STARTSTOP is returned. Continuous variables and variables that are already started are ignored when MPI_T_PVAR_ALL_HANDLES is specified. On Aug 27, 2013, at 12:09 PM, Kathryn Mohror <kathryn(a)llnl.gov> wrote: > I made a ticket for this (#391) and uploaded a pdf with the proposed changes (also attached). > > Is anyone opposed to putting this up for a reading as errata? > > Kathryn > > > On Aug 27, 2013, at 5:14 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > >> On Aug 26, 2013, at 7:23 PM, "Schulz, Martin" <schulz6(a)llnl.gov> wrote: >> >>>> I am now on the SUCCESS side of the fence. Does it need to be clarified as an errata? I would suggest (from 3.0 clean doc): >> >> Just to be totally clear: I don't really care which way it goes. I just saw this issue as an ambiguity that should be resolved. >> >>>> page 580, line 41: >>>> In this case, the routine returns MPI_SUCCESS if all variables are started successfully, otherwise MPI_T_ERR_PVAR_NO_STARTSTOP is returned. MPI_SUCCESS is also returned if no handles are valid for session and MPI_T_PVAR_ALL_HANDLES is passed in handle. >>> >>> Hmm - I fear we would have to be even more explicit: MPI_SUCCESS is also returned if MPI_T_PVAR_ALL_HANDLES is passed in handles and if no handles are valid for session or all valid handles represent continuous (read only for reset) variables. >> >> +1. >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> _______________________________________________ >> mpiwg-tools mailing list >> mpiwg-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > > ______________________________________________________________ > Kathryn Mohror, kathryn(a)llnl.gov, http://people.llnl.gov/mohror1 > CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA > > > > > <tools-3.pdf> -- 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: [mpiwg-tools] Tools WG webex tomorrow!
by Kathryn Mohror 27 Aug '13

27 Aug '13

I made a ticket for this (#391) and uploaded a pdf with the proposed changes (also attached). Is anyone opposed to putting this up for a reading as errata? Kathryn On Aug 27, 2013, at 5:14 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > On Aug 26, 2013, at 7:23 PM, "Schulz, Martin" <schulz6(a)llnl.gov> wrote: > >>> I am now on the SUCCESS side of the fence. Does it need to be clarified as an errata? I would suggest (from 3.0 clean doc): > > Just to be totally clear: I don't really care which way it goes. I just saw this issue as an ambiguity that should be resolved. > >>> page 580, line 41: >>> In this case, the routine returns MPI_SUCCESS if all variables are started successfully, otherwise MPI_T_ERR_PVAR_NO_STARTSTOP is returned. MPI_SUCCESS is also returned if no handles are valid for session and MPI_T_PVAR_ALL_HANDLES is passed in handle. >> >> Hmm - I fear we would have to be even more explicit: MPI_SUCCESS is also returned if MPI_T_PVAR_ALL_HANDLES is passed in handles and if no handles are valid for session or all valid handles represent continuous (read only for reset) variables. > > +1. > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools ______________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://people.llnl.gov/mohror1 CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0

Re: [mpiwg-tools] Tools WG webex tomorrow!
by Jeff Squyres (jsquyres) 27 Aug '13

27 Aug '13

On Aug 26, 2013, at 7:23 PM, "Schulz, Martin" <schulz6(a)llnl.gov> wrote: >> I am now on the SUCCESS side of the fence. Does it need to be clarified as an errata? I would suggest (from 3.0 clean doc): Just to be totally clear: I don't really care which way it goes. I just saw this issue as an ambiguity that should be resolved. >> page 580, line 41: >> In this case, the routine returns MPI_SUCCESS if all variables are started successfully, otherwise MPI_T_ERR_PVAR_NO_STARTSTOP is returned. MPI_SUCCESS is also returned if no handles are valid for session and MPI_T_PVAR_ALL_HANDLES is passed in handle. > > Hmm - I fear we would have to be even more explicit: MPI_SUCCESS is also returned if MPI_T_PVAR_ALL_HANDLES is passed in handles and if no handles are valid for session or all valid handles represent continuous (read only for reset) variables. +1. -- 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: [mpiwg-tools] Tools WG webex tomorrow!
by Schulz, Martin 26 Aug '13

26 Aug '13

On Aug 27, 2013, at 1:09 AM, Kathryn Mohror <kathryn(a)llnl.gov<mailto:[email protected]>> wrote: Also for PVAR start, what if there are no handles associated with a session and MPI_T_PVAR_ALL_HANDLES is used? Do we return SUCCESS or ERR_PVAR_NO_STARTSTOP? Hm. I think this is a separate ticket, yes? And I would think returning the error code would be more helpful than success. However, I can see the other side too, that success makes sense, since nothing erroneous actually happened. Here is what the text says: If the constant MPI_T_PVAR_ALL_HANDLES is passed in handle, the MPI implementation attempts to start all variables within the session identified by the parameter session for which handles have been allocated. For me this reads as returning SUCCESS since all variables, which had handles allocated, have been reset. Granted, we could be more explicit. (the same applies to stop and reset as well) I am now on the SUCCESS side of the fence. Does it need to be clarified as an errata? I would suggest (from 3.0 clean doc): page 580, line 41: In this case, the routine returns MPI_SUCCESS if all variables are started successfully, otherwise MPI_T_ERR_PVAR_NO_STARTSTOP is returned. MPI_SUCCESS is also returned if no handles are valid for session and MPI_T_PVAR_ALL_HANDLES is passed in handle. Hmm - I fear we would have to be even more explicit: MPI_SUCCESS is also returned if MPI_T_PVAR_ALL_HANDLES is passed in handles and if no handles are valid for session or all valid handles represent continuous (read only for reset) variables. Martin Same for 581, line 13 and page 582, line 25. Martin and 387 Looks good. :-) due to lack of time (I blame Fortran!) Long live Fortran 2028! :-) Kathryn -- Jeff Squyres jsquyres(a)cisco.com<mailto:[email protected]> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ _______________________________________________ mpiwg-tools mailing list mpiwg-tools(a)lists.mpi-forum.org<mailto:[email protected]> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools ______________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov<mailto:[email protected]>, http://people.llnl.gov/mohror1 CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA _______________________________________________ mpiwg-tools mailing list mpiwg-tools(a)lists.mpi-forum.org<mailto:[email protected]> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools _______________________________________________ mpiwg-tools mailing list mpiwg-tools(a)lists.mpi-forum.org<mailto:[email protected]> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools ______________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov<mailto:[email protected]>, http://people.llnl.gov/mohror1 CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA _______________________________________________ mpiwg-tools mailing list mpiwg-tools(a)lists.mpi-forum.org<mailto:[email protected]> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

1 0

Re: [mpiwg-tools] Tools WG webex tomorrow!
by Kathryn Mohror 26 Aug '13

26 Aug '13

> >> For 378: >> >> "If any OUT parameter to MPI_T_CVAR_GET_INFO" >> >> OUT is in the wrong font. Same for PVAR and CATEGORY. > > Do you know what the proper markup for OUT is? I looked around but didn't find an example yet. Putting in \OUT doesn't seem to do the right thing. I found the answer in the datatypes chapter. \OUT\ I also found that the font was not correct in the 'strings conventions' section so I fixed those as ticket 0. Kathryn ______________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://people.llnl.gov/mohror1 CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0

Re: [mpiwg-tools] Tools WG webex tomorrow!
by Kathryn Mohror 26 Aug '13

26 Aug '13

>>> >>> Also for PVAR start, what if there are no handles associated with a session and MPI_T_PVAR_ALL_HANDLES is used? Do we return SUCCESS or ERR_PVAR_NO_STARTSTOP? >> >> Hm. I think this is a separate ticket, yes? And I would think returning the error code would be more helpful than success. However, I can see the other side too, that success makes sense, since nothing erroneous actually happened. > > Here is what the text says: > > If the constant MPI_T_PVAR_ALL_HANDLES is passed in handle, the MPI implementation attempts to start all variables within the session identified by the parameter session for which handles have been allocated. > > For me this reads as returning SUCCESS since all variables, which had handles allocated, have been reset. Granted, we could be more explicit. > > (the same applies to stop and reset as well) I am now on the SUCCESS side of the fence. Does it need to be clarified as an errata? I would suggest (from 3.0 clean doc): page 580, line 41: In this case, the routine returns MPI_SUCCESS if all variables are started successfully, otherwise MPI_T_ERR_PVAR_NO_STARTSTOP is returned. MPI_SUCCESS is also returned if no handles are valid for session and MPI_T_PVAR_ALL_HANDLES is passed in handle. Same for 581, line 13 and page 582, line 25. > > Martin > > > > >> >>> >>>> and 387 >>> >>> Looks good. :-) >>> >>>> due to lack of time (I blame Fortran!) >>> >>> Long live Fortran 2028! >> >> :-) >> >> Kathryn >> >>> >>> -- >>> Jeff Squyres >>> jsquyres(a)cisco.com >>> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ >>> >>> _______________________________________________ >>> mpiwg-tools mailing list >>> mpiwg-tools(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools >> >> ______________________________________________________________ >> Kathryn Mohror, kathryn(a)llnl.gov, http://people.llnl.gov/mohror1 >> CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA >> >> >> >> >> _______________________________________________ >> mpiwg-tools mailing list >> mpiwg-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools ______________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://people.llnl.gov/mohror1 CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0

Re: [mpiwg-tools] Tools WG webex tomorrow!
by Kathryn Mohror 26 Aug '13

26 Aug '13

>>>> >>>> What about MPI_T_PVAR_HANDLE_FREE? That takes a (session, handle) tuple, but doesn't have the text about MPI_T_ERR_INVALID_HANDLE. >>> >>> I will add this to the handle_free text. Alternatively, I could put this text right after the handle_alloc text: >>> >>> For any routine that takes both handle and session arguments, if the handle argument passed in is not associated with the session argument, MPI_T_ERR_INVALID_HANDLE is returned. >> >> Actually, I don't think that is specific enough. How about: >> >> For all routines in the rest of this section that take both handle and session arguments, if the handle argument passed in is not associated with the session argument, MPI_T_ERR_INVALID_HANDLE is returned. > > Not to be nit-picky, but the alloc routines also has a handle and a session argument and doesn't apply there. I think we have to say "take both handle and session arguments as IN arguments". Your text is more specific and likely clearer, and if routines get added at some point, we'll be less likely to make an error regarding this. So, now it's: For all routines in the rest of this section that take both handle and session as IN arguments, if the handle argument passed in is not associated with the session argument, MPI_T_ERR_INVALID_HANDLE is returned. I don't know the markup for IN though. If someone does, that will help me. Kathryn > > Martin > > >> >> Kathryn >> >> ______________________________________________________________ >> Kathryn Mohror, kathryn(a)llnl.gov, http://people.llnl.gov/mohror1 >> CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA >> >> >> >> >> _______________________________________________ >> mpiwg-tools mailing list >> mpiwg-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools ______________________________________________________________ Kathryn Mohror, kathryn(a)llnl.gov, http://people.llnl.gov/mohror1 CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA

1 0