November 2009 - Mpich2-core - mailman3.cels.anl.gov

FW: ANL plan update
by Rajeev Thakur 22 Nov '09

22 Nov '09

_____ From: Mark Pagel [mailto:[email protected]] Sent: Sunday, November 22, 2009 10:42 PM To: Rajeev Thakur Subject: RE: ANL plan update Rajeev, Here is the list we are interested in: BLCR Fault Tolerance Thread safety (fine grain locking) Non-blocking collectives Multiple netmods at same time asynchronous progress support MPICH2 1.3 schedule plans as well as future releases and content -Mark From: mpich2-cray-bounces(a)lists.mcs.anl.gov [mailto:[email protected]] On Behalf Of Mark Pagel Sent: Wednesday, November 18, 2009 10:36 AM To: Rajeev Thakur Cc: mpich2-cray(a)lists.mcs.anl.gov Subject: Re: [mpich2-cray] ANL plan update Rajeev, Yes. Dec 2nd from 3-4pm CT would work for us. We will send you a list of items we are interested or would like more info by Friday of this week. Thanks, -Mark From: Rajeev Thakur [mailto:[email protected]] Sent: Monday, November 16, 2009 3:51 PM To: Mark Pagel Cc: mpich2-cray(a)lists.mcs.anl.gov Subject: RE: ANL plan update Mark, Would Dec 2nd work? Darius will be on vacation on the 3rd. Rajeev _____ From: Mark Pagel [mailto:[email protected]] Sent: Monday, November 16, 2009 1:37 PM To: Rajeev Thakur Subject: ANL plan update Rajeev, I am following up with our tentative plan to get an ANL plan update early in December. For us, Dec 3rd at 3-4 CT would work. Does this work for you? We will send you a list by the end of this week on the specific items we are interested in but would also like to know what you are working on. Thanks, -Mark

1 0

Torsten
by Rajeev Thakur 18 Nov '09

18 Nov '09

Torsten was saying yesterday he is a bit frustrated with the Open MPI guys and wants to work closely with us. I told him he is more than welcome. He also said he is likely to move to NCSA soon to work with Marc and Bill (this may not be public yet). Rajeev

1 0

maint/updatefiles fails
by Anthony Chan 18 Nov '09

18 Nov '09

mpich2's maint/updatefiles failed on surveyor. Any clue what is missing.. ? A.Chan Found ./configure.in; executing make configure target (cd . && autoheader -I ./confdb && \ autoconf -I ./confdb ) running third-party initialization autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal --force -I config -I m4 autoreconf: configure.ac: tracing autoreconf: configure.ac: not using Libtool autoreconf: running: /home/chan/autoconf/2.63/bin/autoconf --force configure.ac:417: error: possibly undefined macro: AC_LIBTOOL_WIN32_DLL If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. autoreconf: /home/chan/autoconf/2.63/bin/autoconf failed with exit status: 1 login3.surveyor:~/mpich_work/mpich2 > which autoconf /home/chan/autoconf/2.63/bin/autoconf login3.surveyor:~/mpich_work/mpich2 > which automake /home/chan/automake/1.11/bin/automake login3.surveyor:~/mpich_work/mpich2 > which libtool /home/chan/libtool/2.2.6b/bin/libtool

2 3

mpich2-1.2.1 release
by Pavan Balaji 18 Nov '09

18 Nov '09

I've moved the new nightly tests to run on the mpich2-1.2.1 branch. If things are working fine, we should release it tomorrow instead of waiting till Thursday. Are there any other pending changes? -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

5 15

performance bug in RC
by Darius Buntinas 13 Nov '09

13 Nov '09

George found a performance bug with large messages in the RC. I was able to verify it. Netmpi numbers: 1.2.1rc1: 147: 134217730 bytes 3 times --> 11117.75 Mbps in 0.092104991 sec 148: 201326588 bytes 3 times --> 11108.94 Mbps in 0.138267001 sec 149: 201326591 bytes 3 times --> 11107.05 Mbps in 0.138290485 sec 150: 201326594 bytes 3 times --> 11116.16 Mbps in 0.138177156 sec "older" version (circa 2007): 147: 134217730 bytes 3 times --> 15962.75 Mbps in 0.064149340 sec 148: 201326588 bytes 3 times --> 15951.12 Mbps in 0.096294165 sec 149: 201326591 bytes 3 times --> 15962.12 Mbps in 0.096227845 sec 150: 201326594 bytes 3 times --> 15962.62 Mbps in 0.096224825 sec 151: 268435452 bytes 3 times --> 15946.49 Mbps in 0.128429532 sec 152: 268435455 bytes 3 times --> 15955.83 Mbps in 0.128354351 sec I'm going to bisect to see when this crept in. -d

2 4

OpenSHMEM BoF
by Rajeev Thakur 12 Nov '09

12 Nov '09

FYI... http://sc08.supercomputing.org/scyourway/conference/view/bof140.html

4 7

Re: [mpich2-core] bug reporting
by chan＠mcs.anl.gov 12 Nov '09

12 Nov '09

Why not just make mpich2-maint same as mpich-discuss ? A.Chan ----- "Darius Buntinas" <buntinas(a)mcs.anl.gov> wrote: > The idea is that people send their issues (bug, help requests, etc) > to > mpich2-discuss. Then if we decide that it's a real bug, we create a > ticket for it. Users who are sufficiently sophisticated to determine > that it's a bug and know how to use trac, can create tickets > themselves, > but they need not. > > Sending email to mpich2-maint no longer creates a trac ticket. > > -d > > On 11/12/2009 11:14 AM, chan(a)mcs.anl.gov wrote: > > I am confused as why some mpich2-maint bug report goes through ? > > e.g. this guy from france about time command on mpich2 vs intel > MPI. > > I see his mpich2-maint email but can't find his bug report in TRAC. > > Since his bug report comes through, should we answer his question > > or ask him to file a bug report ? (Answering his question right > away > > seems to encourage him to do it again.) > > > > Also, it seems some users are refusing to file a bug report on > TRAC: > > e.g. the guy tried to do cross-compile nemesis on an alpha chip. > > I guess I will file a bug report for him.... > > > > Our bug-report system seems confusing to some users (like old MPI > > users who ain't really up to all the technology or non CS newbies), > > e.g. our reply message from mpich2-maint assumes user know the > problem > > he/she has is bug or not. Also the reply message does not > explicitly > > contain the link. > > > > http://wiki.mcs.anl.gov/mpich2/index.php/Creating_New_Bug_Tickets > > > > Since filing a bug report with TRAC isn't easy, I can see some user > will > > just gives up.... Are we stuck with this system ? > > > > A.Chan

2 1

bug reporting
by chan＠mcs.anl.gov 12 Nov '09

12 Nov '09

I am confused as why some mpich2-maint bug report goes through ? e.g. this guy from france about time command on mpich2 vs intel MPI. I see his mpich2-maint email but can't find his bug report in TRAC. Since his bug report comes through, should we answer his question or ask him to file a bug report ? (Answering his question right away seems to encourage him to do it again.) Also, it seems some users are refusing to file a bug report on TRAC: e.g. the guy tried to do cross-compile nemesis on an alpha chip. I guess I will file a bug report for him.... Our bug-report system seems confusing to some users (like old MPI users who ain't really up to all the technology or non CS newbies), e.g. our reply message from mpich2-maint assumes user know the problem he/she has is bug or not. Also the reply message does not explicitly contain the link. http://wiki.mcs.anl.gov/mpich2/index.php/Creating_New_Bug_Tickets Since filing a bug report with TRAC isn't easy, I can see some user will just gives up.... Are we stuck with this system ? A.Chan

2 1

Code freeze for mpich2-1.2.1rc1
by Pavan Balaji 10 Nov '09

10 Nov '09

All, The MPICH2 trunk is now frozen for any more commits, except for Jayesh who is testing out the newly committed stuff on Windows. We will be running a final set of tests before releasing 1.2.1rc1 either today or tomorrow. Thanks, -- Pavan PS: I have not made the trunk RO since Jayesh might need to commit some stuff in. -- Pavan Balaji http://www.mcs.anl.gov/~balaji

5 14

Communicator comparison
by Pavan Balaji 09 Nov '09

09 Nov '09

We had the discussion on the lunch table about how to compare two communicators in a portable manner. Schemes with Fortran voodoo and memcmp in cases of structure packing and all sorts of other nonsense. Just discovered this function in the MPI standard: int MPI_Comm_compare(MPI_Comm comm1, MPI_Comm comm2, int *result) D'oh! -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0