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

Re: [Mpi-forum] Meeting schedule for 2012
by Jeff Squyres 20 Sep '11

20 Sep '11

On Sep 20, 2011, at 9:27 AM, Jeff Hammond wrote: > I wonder at what point the MPI Forum will support digital attendance. > I guess someone must have looked into this and decided that it was too > much of pain in the arse. That has been the conclusion in the past -- plus, the Forum intentionally wanted to "raise the bar" for participation, trying to ensure that only those who really cared would actually be involved. This prevents (at least) two kinds of lazy participants: - those who only want their organization's name on the MPI roster - those who only attend occasional meetings (or worse, just a session or two here and there) and don't really have a good understanding of the Forum or the issues involved To be clear, Forum participation is open to anyone. But we really only want people who want to actually be *involved* -- not just someone who drops in for an occasional meeting and is (perhaps unintentionally) disruptive due to lack of knowledge/experience on how the Forum works, the body of complex issues that are being worked on, etc. -- 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] Meeting schedule for 2012
by Jeff Hammond 20 Sep '11

20 Sep '11

I wonder at what point the MPI Forum will support digital attendance. I guess someone must have looked into this and decided that it was too much of pain in the arse. Jeff On Tue, Sep 20, 2011 at 8:18 AM, Jeff Squyres <jsquyres(a)cisco.com> wrote: > It does seem fair, but it will likely mean that I will be unable to attend. > > ----- > > Sidenote: Should we start investigating virtual presence technology? ï¿½There would need to be discussion of a) how to attend, and b) what exactly it would mean (voting-wise) to attend virtually. ï¿½E.g., you would only count as having "attended" virtually if you actually attend/participate in over half the sessions, or somesuch. > > > On Sep 19, 2011, at 7:06 AM, Graham, Richard L. wrote: > >> I recently had a request to broaden the meeting site location to include one meeting in the far east - specifically in Japan. ï¿½This request seems reasonable to me, since we have had regular attendance from Japan over the last four years, and as a way to increase involvement from the CS community in east Asia. ï¿½Therefore, I am inclined to move the May, 2012 meeting from the CA bay area to Japan. ï¿½Please let me know what you think. ï¿½I know this will make it more difficult for folks from the US to attend, but it seems only fair to include this geographic area in the meeting schedule. >> >> Rich >> _______________________________________________ >> 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 > -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/index.php/User:Jhammond

1 0

Santorini voting eligibility
by Jeff Squyres 20 Sep '11

20 Sep '11

We have several votes upcoming in the meeting in a few days. I always review voting eligibility before the actual votes, but since I'm (sadly) not in Santorini, I'm going to conduct this eligibility review via email. *** Organizations are responsible for contacting me ASAP if they feel that there is a problem with their eligibility. To be absolutely clear: Rolf Rabenseifner, who will be conducting the votes in Santorini in my absence, will only allow votes from the organizations on the worksheet that I give him. If your eligibility is incorrect, you need to resolve it with me *before* voting starts. Organizations eligible to vote and who will be present in Santorini: - Argonne - Cray - Fujitsu - HLRS - IBM - INRIA - Intel - Livermore - NCSA/UIUC - ORNL - Ohio State U. - Riken ACS - Sandia - U Toyko Organizations eligible to vote but who will NOT be present in Santorini (i.e., they will not be voting): - Cisco - HDF - Indiana U. - Los Alamos - Microsoft - U. Tennessee Please contact me ASAP if there are any mistakes with these lists. Thanks. -- 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] Meeting schedule for 2012
by Jeff Squyres 20 Sep '11

20 Sep '11

It does seem fair, but it will likely mean that I will be unable to attend. ----- Sidenote: Should we start investigating virtual presence technology? There would need to be discussion of a) how to attend, and b) what exactly it would mean (voting-wise) to attend virtually. E.g., you would only count as having "attended" virtually if you actually attend/participate in over half the sessions, or somesuch. On Sep 19, 2011, at 7:06 AM, Graham, Richard L. wrote: > I recently had a request to broaden the meeting site location to include one meeting in the far east - specifically in Japan. This request seems reasonable to me, since we have had regular attendance from Japan over the last four years, and as a way to increase involvement from the CS community in east Asia. Therefore, I am inclined to move the May, 2012 meeting from the CA bay area to Japan. Please let me know what you think. I know this will make it more difficult for folks from the US to attend, but it seems only fair to include this geographic area in the meeting schedule. > > Rich > _______________________________________________ > 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] Meeting schedule for 2012
by Jeff Hammond 20 Sep '11

20 Sep '11

I support the idea here but the only way this is practical for me is if it works to double-dip with IPDPS. It is just crazy to fly to Asia and back twice in the same month and I highly doubt DOE would pay for me to do it even if I wanted to. Jeff On Mon, Sep 19, 2011 at 6:06 AM, Graham, Richard L. <rlgraham(a)ornl.gov> wrote: > I recently had a request to broaden the meeting site location to include one meeting in the far east - specifically in Japan. ï¿½This request seems reasonable to me, since we have had regular attendance from Japan over the last four years, and as a way to increase involvement from the CS community in east Asia. ï¿½Therefore, I am inclined to move the May, 2012 meeting from the CA bay area to Japan. ï¿½Please let me know what you think. ï¿½I know this will make it more difficult for folks from the US to attend, but it seems only fair to include this geographic area in the meeting schedule. > > Rich > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/index.php/User:Jhammond

1 0

Meeting schedule for 2012
by Graham, Richard L. 19 Sep '11

19 Sep '11

I recently had a request to broaden the meeting site location to include one meeting in the far east - specifically in Japan. This request seems reasonable to me, since we have had regular attendance from Japan over the last four years, and as a way to increase involvement from the CS community in east Asia. Therefore, I am inclined to move the May, 2012 meeting from the CA bay area to Japan. Please let me know what you think. I know this will make it more difficult for folks from the US to attend, but it seems only fair to include this geographic area in the meeting schedule. Rich

1 0

Ticket #78 (Glossary) draft for comments
by Jones, Terry R. 09 Sep '11

09 Sep '11

Hello all, I have uploaded a new version of the Glossary Annex (ticket #78); this version is intended for comments and is on the agenda for the Greece meeting. I will not be attending Santorini, but Rich Graham and Rolf Rabenseifner have agreed to cover the glossary actions. If you have not looked over the glossary recently, I would like to encourage you to do so. Thanks, -Terry ________________________________ Terry R. Jones Oak Ridge National Laboratory PO BOX 2008 MS6164 OAK RIDGE TN 37831-6164 voice: 865-241-5764 fax: 865-241-4811 email: trj(a)ornl.gov www: http://www.csm.ornl.gov/~trj ________________________________

1 0

Re: [Mpi-forum] Review/Reading versions of #204 and #266
by Fab Tillier 09 Sep '11

09 Sep '11

Martin Schulz wrote on Fri, 9 Sep 2011 at 09:58:46 > Hi Fab, > > On Sep 9, 2011, at 9:42 AM, Fab Tillier wrote: > >> Hi Martin, >> >> As I won't be at the Greece meeting, I thought I would give you >> feedback now. >> >> I see that the string length handling is consistent with the silly precedent >> set with functions like MPI_COMM_GET_NAME, where the buffer length on >> input is assumed. This is just bad software design, and I feel very >> strongly that we should from this pattern and have the string length >> specified on input by making the parameter INOUT just like you did for >> the MPI_T interfaces. > > Thanks for the feedback - I fully agree with you that the new type > of string returns that we have adopted in MPI_T is much cleaner > and I do prefer it as well. > > However, this ticket was only intended as a minor addition since > there was a common need and the forum liked the idea when I > presented it last time. Changing the interface would mean larger > changes by moving the interface descriptions up from MPI_T > into the general document (since this shouldn't be twice in the > document)and making it clear where it applies and where not > (Which of the existing routines would we change, which not? > Would we add double interfaces for existing routines?). I've been thinking for a while now about how to handle the string lengths for the existing functions. Changing the resultlen parameter to INOUT causes all sorts of pain from a backward compatibility perspective, so there really is no alternative than to have a new function. This of course opens up the whole "suffix" discussion again, and I'd propose _s, just because that's the suffix Microsoft uses for the more secure versions of the C library functions like strcpy. For example, strcpy_s takes an extra parameter specifying the destination string length. > I would be happy to propose this as a separate ticket, but I would > like to hear from the rest of the forum first on how they feel about > this and what they think is the best way to do this. I am hesitant > to make such a larger proposal without knowing in which > direction this should go. I would personally prefer to see the paragraph from the MPI_T chapter moved up. Are you up for working on a ticket together? We can move forward with the existing ticket, though it would likely change to follow whatever our follow up ticket would propose. Does that seem reasonable? -Fab > > Martin > > >> >> Cheers, >> -Fab >> >> Martin Schulz wrote on Fri, 9 Sep 2011 at 00:11:40 >> >>> Hi all, >>> >>> I uploaded new versions of the proposals >>> >>> #204: MPI_Get_library_version >>> (also contains two suggested ticket 0 changes for the >>> MPI Environmental Management chapter) >>> #266: The MPI tool information interface >>> >>> for comments and as the versions intended for the formal >>> readings in Greece. >>> >>> Please let me know if you have any questions or comments. >>> >>> Thanks! >>> >>> Martin >>> >>> >>> PS: Rich - could you please add a reading for #204 to the >>> MPI_T reading time slot? This should only take 10min and >>> I was planning to do this either right before or after the >>> MPI_T reading. Thanks! >>> >>> >>> __________________________________________________________ >>> ______________ Martin Schulz, schulzm(a)llnl.gov, >>> 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 > > __________________________________________________________ > ______________ Martin Schulz, schulzm(a)llnl.gov, > http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National > Laboratory, Livermore, USA > > >

1 0

Re: [Mpi-forum] Review/Reading versions of #204 and #266
by Martin Schulz 09 Sep '11

09 Sep '11

Hi Fab, On Sep 9, 2011, at 9:42 AM, Fab Tillier wrote: > Hi Martin, > > As I won't be at the Greece meeting, I thought I would give you feedback now. > > I see that the string length handling is consistent with the silly precedent set with functions like MPI_COMM_GET_NAME, where the buffer length on input is assumed. This is just bad software design, and I feel very strongly that we should from this pattern and have the string length specified on input by making the parameter INOUT just like you did for the MPI_T interfaces. Thanks for the feedback - I fully agree with you that the new type of string returns that we have adopted in MPI_T is much cleaner and I do prefer it as well. However, this ticket was only intended as a minor addition since there was a common need and the forum liked the idea when I presented it last time. Changing the interface would mean larger changes by moving the interface descriptions up from MPI_T into the general document (since this shouldn't be twice in the document)and making it clear where it applies and where not (Which of the existing routines would we change, which not? Would we add double interfaces for existing routines?). I would be happy to propose this as a separate ticket, but I would like to hear from the rest of the forum first on how they feel about this and what they think is the best way to do this. I am hesitant to make such a larger proposal without knowing in which direction this should go. Martin > > Cheers, > -Fab > > Martin Schulz wrote on Fri, 9 Sep 2011 at 00:11:40 > >> Hi all, >> >> I uploaded new versions of the proposals >> >> #204: MPI_Get_library_version >> (also contains two suggested ticket 0 changes for the >> MPI Environmental Management chapter) >> #266: The MPI tool information interface >> >> for comments and as the versions intended for the formal >> readings in Greece. >> >> Please let me know if you have any questions or comments. >> >> Thanks! >> >> Martin >> >> >> PS: Rich - could you please add a reading for #204 to the >> MPI_T reading time slot? This should only take 10min and >> I was planning to do this either right before or after the >> MPI_T reading. Thanks! >> >> __________________________________________________________ >> ______________ Martin Schulz, schulzm(a)llnl.gov, >> 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 ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

Re: [Mpi-forum] Review/Reading versions of #204 and #266
by Fab Tillier 09 Sep '11

09 Sep '11

Hi Martin, As I won't be at the Greece meeting, I thought I would give you feedback now. I see that the string length handling is consistent with the silly precedent set with functions like MPI_COMM_GET_NAME, where the buffer length on input is assumed. This is just bad software design, and I feel very strongly that we should from this pattern and have the string length specified on input by making the parameter INOUT just like you did for the MPI_T interfaces. Cheers, -Fab Martin Schulz wrote on Fri, 9 Sep 2011 at 00:11:40 > Hi all, > > I uploaded new versions of the proposals > > #204: MPI_Get_library_version > (also contains two suggested ticket 0 changes for the > MPI Environmental Management chapter) > #266: The MPI tool information interface > > for comments and as the versions intended for the formal > readings in Greece. > > Please let me know if you have any questions or comments. > > Thanks! > > Martin > > > PS: Rich - could you please add a reading for #204 to the > MPI_T reading time slot? This should only take 10min and > I was planning to do this either right before or after the > MPI_T reading. Thanks! > > __________________________________________________________ > ______________ Martin Schulz, schulzm(a)llnl.gov, > 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