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

MPI-2.2 implementation and reviews
by Dave Goodell 20 Aug '09

20 Aug '09

I have implemented six of the MPI-2.2 tickets in my local git repository: #7, #137, #6, #66, #71, and #94 (see bottom of mail for ticket links). I should finish up the implementation of #24 and #27 sometime this week. After that only two tickets will remain: #31 (Add MPI_IN_PLACE option to Alltoall) and #33 (new scalable graph topology interface). Both of those are too large to know yet how long they will take to implement, but hopefully we can get them done before the MPI Forum meeting in Helsinki. I also need to double check that we are correctly implementing ticket #64 (optional Fortran types in reduction operations), but I think we already are. And I need to implement the trivial ticket #101 which flips the MPI_SUBVERSION number to 2, but I want to wait until we actually implement all of MPI-2.2. Since everyone is so busy right now and the amount of changes is large enough I think it would be cruel to dump the reviews for these on a single victim like I usually do for batch code reviews. Can I get volunteers to review the attached patches for both general code correctness and correctness w.r.t the draft MPI Standard? It would be a shame for us to release something that erroneously claims to be MPI-2.2 compatible and I'm unfortunately imperfect, so reviews are important. Some of them are pretty simple, but #66 could use some close code review and they all need to be checked against the upcoming MPI Standard. Thanks, -Dave Implemented ticket links: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/7 https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/137 https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/6 https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/66 https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/71 https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/94 Overall diff stat for the changes: src/binding/cxx/buildiface | 113 +++-- src/binding/f90/buildiface | 6 +- src/include/mpi.h.in | 23 +- src/mpi/attr/comm_set_attr.c | 24 +- src/mpi/coll/exscan.c | 144 ++---- src/mpi/comm/comm_create.c | 725 ++++++++++++++++++ +------------ src/mpi/errhan/comm_create_errhandler.c | 2 +- src/mpi/pt2pt/request_get_status.c | 13 +- src/util/multichannel/mpi.c | 42 +- test/mpi/attr/Makefile.sm | 1 + test/mpi/attr/attrend2.c | 128 ++++++ test/mpi/attr/testlist | 2 + test/mpi/coll/exscan.c | 27 ++ test/mpi/comm/commcreate1.c | 28 +- test/mpi/comm/iccreate.c | 21 +- test/mpi/pt2pt/rqstatus.c | 28 ++- test/mpi/util/mtest.c | 121 +++++- 17 files changed, 928 insertions(+), 520 deletions(-)

2 3

mpiexec extensions
by William Gropp 18 Aug '09

18 Aug '09

I'd like to discuss two extensions for mpiexec to better support SMP clusters. These aren't things I'd propose for the standard. I'm using the first one, and it has made life much easier for me. The first option specifies the number of processes per node. I'm using -pn <n>, as in -pn 8. On our POWER5 system, with 16 processors be node, I can run tests with bpmpiexec.pl -n 128 pn 4 ./halocompare (bpmpiexec.pl is a perl script that submits a LoadLeveler job using the IBM MPI that I put together). The other option would control whether successive ranks are on the same node of the "next" node. This would be nice to have, though not all systems might support it. That option would be similar in spirit to the BG mapping option, though perhaps only for simple layouts. Comments? Bill William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

4 4

blocking SVN clients < v1.5
by Dave Goodell 17 Aug '09

17 Aug '09

Hi all, The SVN server here at Argonne was recently upgraded to v1.5.something, which means that we have two major new features that we didn't have before. We now have SVN's merge tracking support and relative path svn:externals. If you aren't already aware of it you can read about the merge tracking feature here [1]. Basically, it all relies on clients manipulating a new "svn:mergeinfo" property whenever someone runs "svn merge ...". We've already started using this feature and it's been very useful so far. The relative path externals feature is described here [2]. We already use externals for the confdb, mpl, and openpa portions of the MPICH2 repository, so externals in and of themselves won't be anything new in 1.5 for us. However moving to the new relative path format will help with branching and avoid those annoying and easy to forget svn:externals changes when working on the confdb. The main point of this mail is that in order to safely and correctly use these two features we should really prevent SVN clients that are pre-1.5 from committing to the repository [3]. Since we can't easily ban pre-1.4 clients from reading they will likely have problems with the relative path externals when checking out. I don't have a firm timeline yet for when this switch will happen, but I wanted to give everyone a heads up so that they could check their client versions and make sure that they won't be surprised by the change. Sometime early next week is a likely timeframe for the switch. FYI the default version of SVN in Mac OS X 10.5 (/usr/bin/svn) is 1.4.4. SVN-1.6.4 is available via fink and MacPorts. It looks like v1.5.1 is available as a backport to Ubuntu Hardy and is standard starting with Ubuntu Intrepid. As always, you can install one from source or a separate binary package as appropriate. "svn --version" will tell you what you currently are using. If this will be a real problem for anyone please speak up now so that we don't leave you in the lurch. -Dave [1] http://svnbook.red-bean.com/en/1.5/svn.branchmerge.basicmerging.html#svn.br… [2] http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html [3] http://svnbook.red-bean.com/en/1.5/svn.branchmerge.advanced.html#svn.branch…

1 1

Temporarily unsubscribed everyone from mpich2-maint
by Rajeev Thakur 16 Aug '09

16 Aug '09

I have temporarily unsubscribed everyone from the mpich2-maint mailing list (mpich2-bugs), so you won't receive any emails until the problem is fixed. Those mails will still get entered into Trac. Rajeev Unsubscribed the following. * balaji(a)mcs.anl.gov * buntinas(a)mcs.anl.gov * chan(a)mcs.anl.gov * goodell(a)mcs.anl.gov * jayesh(a)mcs.anl.gov * kmm(a)cray.com * lusk(a)mcs.anl.gov * mercierg(a)mcs.anl.gov * penoff(a)mcs.anl.gov * rbutler(a)mtsu.edu * rross(a)mcs.anl.gov * thakur(a)mcs.anl.gov * wgropp(a)illinois.edu

1 1

Re: [mpich2-core] [mcs-systems #33027] Temporarily unsubscribed everyone from mpich2-maint
by Rick Bradshaw 16 Aug '09

16 Aug '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think this is now fixed. I have restarted mail on the trac server and I haven't seen this message come through for the last 15 minutes. I will double check on this later tonight, and then again tomorrow morning. I am very sorry about this problem, but there are certain things that seem to sneak through our setup and cause this issue. Rick Rajeev Thakur wrote: > I have temporarily unsubscribed everyone from the mpich2-maint mailing > list (mpich2-bugs), so you won't receive any emails until the problem is > fixed. Those mails will still get entered into Trac. > > Rajeev > > Unsubscribed the following. > > * balaji(a)mcs.anl.gov > * buntinas(a)mcs.anl.gov > * chan(a)mcs.anl.gov > * goodell(a)mcs.anl.gov > * jayesh(a)mcs.anl.gov > * kmm(a)cray.com > * lusk(a)mcs.anl.gov > * mercierg(a)mcs.anl.gov > * penoff(a)mcs.anl.gov > * rbutler(a)mtsu.edu > * rross(a)mcs.anl.gov > * thakur(a)mcs.anl.gov > * wgropp(a)illinois.edu > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqIhiMACgkQdavihOKkCCGAfACfeoCqBRzsP/scmvqnwlqZZVeq Mh8An3IZZ2BBfq+Ggq8VE0gwoxIDMoY5 =AN8o -----END PGP SIGNATURE-----

1 0

FW: [mpich2-maint] #1030: No valid command found
by Rajeev Thakur 16 Aug '09

16 Aug '09

Is there a way to stop these mails? We got hundreds of them overnight. Rajeev -----Original Message----- From: mpich2-bugs-bounces(a)mcs.anl.gov [mailto:[email protected]] On Behalf Of mpich2 Sent: Sunday, August 16, 2009 9:47 AM To: undisclosed-recipients: Subject: [mpich2-maint] #1030: No valid command found #1030: No valid command found --------------------------------------+--------------------------------- --------------------------------------+---- Reporter: MDaemon@ | Owner: Type: defect | Status: new Priority: major | Milestone: Component: mpich2 | Keywords: --------------------------------------+--------------------------------- --------------------------------------+---- {{{ Âàøå ñîîáùåíèå äëÿ íå ñîäåðæèò âåðíîé êîìàíäû äëÿ îáðàáîòêè ýòèì ïî÷òîâûì ñåðâåðîì. Íèêàêèõ äåéñòâèé ïðåäïðèíÿòî íå áûëî. Äëÿ ïîëó÷åíèÿ èíôîðìàöèè ïî âåðíûì êîìàíäàì, îòïðàâüòå email äëÿ ñ íåçàïîëíåííîé Òåìîé è ñëîâîì "ÏÎÌÎÙÜ" â òåëå ïèñüìà. (Âû òàêæå èîæåòå ñîçäàòü ýòîò email, íàæàâ íà <mailto:?Body=HELP>) ID-Ñîîáùåíèÿ: <083.84e4119fa5bb80275a00b31a63b5d651(a)mcs.anl.gov> Îò : mpich2-maint(a)mcs.anl.gov Êîìó : undisclosed-recipients: ; Äàòà: Sun, 16 Aug 2009 14:42:01 -0000 Òåìà: [mpich2-maint] #1029: No valid command found (Âàøå îðèãèíàëüíîå ñîîáùåíèå ïðèëîæåíî) : Ñîîáùåíèå ñîäåðæèò [1] ôàéëîâ ïðèëîæåíèé }}} [attachment:"untitled-part.obj"] -- Ticket URL: <http://trac.mcs.anl.gov/projects/mpich2/ticket/1030> mpich2 <http://www.mcs.anl.gov/research/projects/mpich2> How to edit this ticket: http://wiki.mcs.anl.gov/mpich2/index.php/Creating_New_Bug_Tickets

2 1

Re: [mpich2-core] f77 binding objects in libmpich.a
by chan＠mcs.anl.gov 14 Aug '09

14 Aug '09

----- "Dave Goodell" <goodell(a)mcs.anl.gov> wrote: > Is there a good technical reason why we put the object files for the > f77 binding into both libmpich.a and libfmpich.a? We currently don't > use the libfmpich.a version in the mpif77 wrapper script, although > Rajeev suspects that it might be used somewhere in MPE. Would there > be a _technical_ problem with removing those objects from libmpich.a > and adding -lfmpich to the link-line of the mpif77 wrapper script? MPE has its own version of libfmpich.a, called libmpe_f2cmpi.a, which is meant to be a more portable version. But once in a while when libmpe_f2cmpi.a has bug, MPE will use libfmpich.a (which is actually more complete than libmpe_f2cmpi.a). Also, some profiling tool does not have its fortran to C wrapper, it relies on the implemention to provide one and that is the reason for libfmpich.a's existence, e.g. fpmpi. AFAIK, the duplicated fortran object files in libmpich.a is for convenience. There are still users who do not like (or is not able) to use mpif77 and prefer to link the library themselve, link with one library, -lmpich, for fortran application is convenient for them. If I remember correctly, some older MPICH-1's mpif77 links with -lfmpich as well. > The backstory here is that one of our students this summer, Kumud, is > implementing parallel make. Part of those changes involve separating > ROMIO files out into a separate mpio.a that is added to the various > mpiXX wrappers. When the f77 bindings are included in libmpich.a this > causes a problem because they are to the right of -lmpio on the link > line and thus can't find most of the MPI-I/O symbols. > > Current mpif77 link line: $F77 $user_args -lmpich -lopa > Proposed mpif77 link line: $F77 $user_args -lfmpich -lmpio -lmpich > -lopa Besides the order issue that you mentioned, some applications out there depend on all MPI related object files to be in libmpich.a. Separating ROMIO object files into libmpio.a will likely break those applications' Makefile. I am OK with the idea separateing -lmpich as -lfmpich -lmpio -lmpich. BTW, if we do decide on breaking up libmpich.a, should libmpio be called libmpichio or libiompich just to be consistent with the existing naming convention. > The alternative is to repeat -lmpio/-lmpich as many times as are > needed to make the linker happy. I think this is quite a bit uglier > and would prefer the clear separation of the f77 binding library. Agreed. repeating multiple times of -lmpio/-lmpich is too ugly. If we cannot keep all MPI object files in -lmpich, separating them into -lfmpich -lmpio -lmpich seems to be only reasonable option. What is the reason that parallel make build needs to separate romio objects into -lmpio ? A.Chan

4 4

float == warnings
by Darius Buntinas 14 Aug '09

14 Aug '09

I'm looking at the best way to eliminate the warnings like: warning: comparing floating point with == or != is unsafe We see these in some of the reduce ops like opland (logical and) in the code for float datatypes. The standard doesn't define these ops for float, but we've been supporting them. So in order to get rid of these warnings we have several options: 1. Remove float datatypes for these ops. 2. Remove the compiler options that generates these warnings 3. Squash these warnings for those files only using: #pragma GCC diagnostic ignored "-Wfloat-equal" I'm in favor of option 1, but I wanted to check with others before doing this, since we could, potentially, be breaking user code. I doubt anyone is really using this, and if they are, they're outside the standard, and really shouldn't be doing this anyway (so we might be doing them a favor by removing it). Any comments? -d

6 9

Fwd: [alcf-support #32792] please install svn client v1.5+ on ALCF systems
by Dave Goodell 13 Aug '09

13 Aug '09

FYI, svn 1.5+ is now available on surveyor and intrepid at least. I'll poke them again about gadzooks/eurkea. -Dave Begin forwarded message: > From: Cory Lueninghoener <lueningh(a)mcs.anl.gov> > Date: August 13, 2009 Aug 13 11:01:21 AM CDT > To: Dave Goodell <goodell(a)mcs.anl.gov> > Cc: support(a)alcf.anl.gov > Subject: Re: [alcf-support #32792] please install svn client v1.5+ > on ALCF systems > > Dave, > > You should now be able to use svn 1.5.7 with the softenv key > +subversion-1.5.7 on both surveyor and intrepid. There were some > strange problems when compiling 1.6.4, so I'm putting that off for > now, but I'll probably give it a shot again sometime so that we have > a full set of versions to select from. > > On 08/12/2009 10:48 AM, Dave Goodell wrote: >> I think it should be fine. I've been personally using a 1.6 client >> with >> our 1.5 server without any problems so far. It looks like a lot of >> the >> issues related to 1.6 client with 1.5 server are when you are using >> the >> file:// access method, not svn:// or http(s):// as we will. >> >> If you want to be super paranoid and safe, I suppose you could >> install >> both and make them available via softenv for whoever wants to pick a >> particular one. >> >> -Dave >> >> On Aug 12, 2009, at 10:20 AM, Tisha Stacey wrote: >> >>> Or maybe that's overly cautious. It would probably be okay ... >>> >>> - Tisha >>> >>> Tisha Stacey wrote: >>> | From stuff on this page >>> | >>> | http://subversion.tigris.org/svn_1.6_releasenotes.html >>> | >>> | it looks like going with a 1.5 client if the server is running 1.5 >>> | would be the safest -- especially if some other client machines >>> will >>> | still be running <1.6. >>> | >>> | - Tisha >>> | >>> | Cory Lueninghoener wrote: >>> | | Dave, >>> | | >>> | | It looks like 1.4 is indeed the newest version of svn we have >>> | | anywhere on the systems. I'll see about getting newer clients >>> | | installed everywhere and let you know when they're ready for >>> use. >>> | | Will 1.6 work fine, or does it introduce other >>> incompatibilities? >>> | | >>> | | On 08/11/2009 05:57 PM, Dave Goodell wrote: >>> | |> User info for goodell(a)mcs.anl.gov >>> | |> ================================= >>> | |> Username: goodell >>> | |> Full Name: Dave Goodell >>> | |> Projects: pilot-goodell,radix >>> | |> ('*' denotes INCITE projects) >>> | |> ================================= >>> | |> >>> | |> >>> | |> The MCS subversion server recently was recently upgraded to >>> version >>> | |> 1.5+, which includes several new features. In order to safely >>> use >>> | |> two of those features (merge tracking and relative path >>> | |> svn:externals), we are planning on banning pre-1.5 SVN >>> clients from >>> | |> committing to our repository via a start-commit hook. >>> | |> Unfortunately, no v1.5+ clients seem to be installed on >>> surveyor, >>> | |> intrepid, gadzooks, and eureka. >>> | |> >>> | |> We (the MPICH2 team) would greatly appreciate it if you could >>> | |> install a version 1.5+ SVN client on these systems, or point me >>> | |> towards them if they are already installed somewhere out of the >>> | |> ordinary. >>> | |> >>> | |> Thanks, >>> | |> -Dave >>> | |> >>> | | >>> | >> > > -- > Cory Lueninghoener > LCF Systems Group

1 0

Re: [mpich2-core] blocking SVN clients < v1.5
by chan＠mcs.anl.gov 11 Aug '09

11 Aug '09

Hmm.... Intrepid (or most likely surveyor) still has an old svn, 1.3.1. My T41 has diskspace problem (besides heat related problem) that I feel I better not mess with it too much.... Oh well.... A.Chan ----- "Dave Goodell" <goodell(a)mcs.anl.gov> wrote: > On Aug 11, 2009, at 3:43 PM, chan(a)mcs.anl.gov wrote: > > > FC9's svn client is version 1.4.6. Is that OK for old svn client > > to read/commit to mpe2 or slog2sdk that does not use externals and > > other new svn features ? > > Short answer: No. > > The long answer is that in order to be certain that the svn:mergeinfo > > property isn't corrupted by a pre-1.5 client we need to prevent all > pre-1.5 clients from committing. So you would be able to read > (checkout) with svn-1.4.6 but you would not be able to write (commit) > > with it. I wish that there was a better way to do this but I don't > believe that there is. > > The good news is that I doubt upgrading your FC9 installation will be > > very difficult. I think you can do it with: > > % yum install --enablerepo=updates-testing subversion > > -Dave

3 2