September 2007 - Mpich2-core - mailman3.cels.anl.gov

Fwd: BOUNCE [email protected]: Non-member submission from ["Jose Francisco Nanez Gomez" <[email protected]>]
by William Gropp 26 Sep '07

26 Sep '07

It might be time to have a look at the way in which various SMP and process environment (such as limits) are specified, and come up with a unified approach (including a replacement for the old MPIT proposal, which even google can no longer find; it described a way to define the partitioning of threads/processes between MPI and the application). Bill Begin forwarded message: > From: owner-mpi-users(a)mcs.anl.gov > Date: September 26, 2007 9:44:06 AM CDT > To: owner-mpi-users(a)mcs.anl.gov > Subject: BOUNCE mpi-users(a)mcs.anl.gov: Non-member submission > from ["Jose Francisco Nanez Gomez" <jfnanezg(a)bt.unal.edu.co>] > > From owner-mpi-users(a)mcs.anl.gov Wed Sep 26 09:44:04 2007 > Received: from mailgw.mcs.anl.gov (mailgw.mcs.anl.gov [140.221.9.4]) > by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id l8QEi4Z135500 > for <mpi-users(a)mcs.anl.gov>; Wed, 26 Sep 2007 09:44:04 -0500 > Received: from localhost (localhost [127.0.0.1]) > by mailgw.mcs.anl.gov (Postfix) with ESMTP id 6EA54348003 > for <mpi-users(a)mcs.anl.gov>; Wed, 26 Sep 2007 09:44:04 -0500 (CDT) > Received: from fk-out-0910.google.com (fk-out-0910.google.com > [209.85.128.188]) > by mailgw.mcs.anl.gov (Postfix) with ESMTP id 3EAFB348002 > for <mpi-users(a)mcs.anl.gov>; Wed, 26 Sep 2007 09:44:01 -0500 (CDT) > Received: by fk-out-0910.google.com with SMTP id f40so2267494fka > for <mpi-users(a)mcs.anl.gov>; Wed, 26 Sep 2007 07:44:00 > -0700 (PDT) > Received: by 10.82.156.12 with SMTP id d12mr1700842bue.1190817830039; > Wed, 26 Sep 2007 07:43:50 -0700 (PDT) > Received: by 10.82.148.6 with HTTP; Wed, 26 Sep 2007 07:43:49 -0700 > (PDT) > Message-ID: > <3ac2b6ff0709260743l17672124qdf6900d3fe04d191(a)mail.gmail.com> > Date: Wed, 26 Sep 2007 09:43:49 -0500 > From: "Jose Francisco Nanez Gomez" <jfnanezg(a)bt.unal.edu.co> > To: mpi-users(a)mcs.anl.gov, mpich2-maint(a)mcs.anl.gov > Subject: mpiexec: failed to obtain sock from manager > MIME-Version: 1.0 > Content-Type: multipart/alternative; > boundary="----=_Part_6861_28773483.1190817830021" > X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at > mailgw.mcs.anl.gov > X-Spam-Status: No, hits=0.1 tagged_above=-0.1 required=5.5 > tests=BAYES_00, > HTML_00_10, HTML_MESSAGE, RCVD_BY_IP, SARE_MSGID_LONG40 > X-Spam-Level: > X-MCS-Mail-Loop: mpi-users > > ------=_Part_6861_28773483.1190817830021 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > Content-Disposition: inline > > We are trying to run the WRF model in a cluster of two intel > machines (each > one with two dual core procesors x86_64) under linux fedora 6. > We can run succesfully the model in one machine with 4 nodes (two > dual core > 2x processor), Using MPICH2 2-1.0.5p4 > with PGI version 7.0.7. However, when we run the same model in the > cluster= > , > Mpich 2 only recognizes two processors (one per machine) as it is > shown by > the comands: mpdtrace, mpdringtest and mpiexec. > > We machine file this: > > [administrador@cs-room443-d01 ~]$ cat mf > cs-room443-d01:4 > cs-room443-d02:4 > > > [administrador@cs-room443-d01 Paquetes]$ mpdtrace > cs-room443-d01 > cs-room443-d02 > > [administrador@cs-room443-d01 Paquetes]$ mpdringtest > time for 1 loops =3D 0.000850915908813 seconds > > [administrador@cs-room443-d01 Paquetes]$ mpiexec -l -n 1 /bin/hostname > 0: cs-room443-d01 > > [administrador@cs-room443-d01 Paquetes]$ mpiexec -l -n 2 /bin/hostname > 0: cs-room443-d01 > 1: cs-room443-d02 > > [administrador@cs-room443-d01 Paquetes]$ mpiexec -l -n 3 /bin/hostname > mpiexec_cs-room443-d01 (mpiexec 425): mpiexec: failed to obtain > sock from > manager > > > is there any way to configure mpich for our cluster with 8 nodes?. Any > suggestion will be helpful. > > Thanks. > > Joseph =D1a=F1ez > Systems Engineer > National Unversity of Colombia. > > ------=_Part_6861_28773483.1190817830021 > Content-Type: text/html; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > Content-Disposition: inline > > We > are trying to run the WRF model in a cluster of two intel machines > (each one with two dual core procesors x86_64) under linux fedora > 6. We = > can run succesfully the model in one machine with 4 nodes (two dual > core 2x= > processor), Using MPICH2 2-1.0.5p4 with > PGI version 7.0.7.  However, when we run the same model in the > cluster= > , > Mpich 2 only recognizes two processors (one per machine) as it is > shown > by the comands: mpdtrace, mpdringtest and mpiexec. We > machine file t= > his: [administrador@cs-room443-d01 ~]$ cat mf cs-room443- > d01:4 <b= > r>cs-room443-d02:4  [administrador@cs-room443-d01 > Paquetes= > ]$ mpdtrace > cs-room443-d01 cs-room443-d02 [administrador@cs- > room443-d01 P= > aquetes]$ mpdringtest time for 1 loops =3D 0.000850915908813 > seconds = > [administrador@cs-room443-d01 Paquetes]$ mpiexec -l -n 1 /bin/ > hostname > 0: cs-room443-d01 [administrador@cs-room443-d01 Paquetes] > $ mpiex= > ec -l -n 2 /bin/hostname 0: cs-room443-d01 1: cs-room443- > d02 [= > administrador@cs-room443-d01 Paquetes]$ mpiexec -l -n 3 /bin/ > hostname > mpiexec_cs-room443-d01 (mpiexec 425): mpiexec: failed to obtain > sock from m= > anager is there any way to configure mpich for our > cluster with = > 8 nodes?. Any suggestion will be > helpful. Thanks. Joseph =D1a= > =F1ez > Systems Engineer National Unversity of Colombia. > > ------=_Part_6861_28773483.1190817830021-- >

1 0

MPID_Atomic functions
by Dave Goodell 16 Sep '07

16 Sep '07

I'm currently working on the "Generic and portable atomics" bullet for the mpich2 1.1 release. Since this exposes a new API to our users, it seems best to run this change by all of you mpich-core@ folks who have quite a bit more mpich context than I do. Nemesis currently contains several routines for performing atomic operations on a limited set of platforms. They are defined in "src/mpid/ch3/channels/nemesis/nemesis/include/mpid_nem-atomics.h". Their function signatures are given below: static inline void *MPID_NEM_SWAP (volatile void *ptr, void *val) static inline void *MPID_NEM_CAS (volatile void *ptr, void *oldv, void *newv) static inline int MPID_NEM_CAS_INT (volatile int *ptr, int oldv, int newv) static inline int MPID_NEM_FETCH_AND_ADD (volatile int *ptr, int val) static inline void MPID_NEM_ATOMIC_ADD (int *ptr, int val) static inline int MPID_NEM_FETCH_AND_INC (volatile int *ptr) static inline int MPID_NEM_FETCH_AND_DEC (volatile int *ptr) static inline void MPID_NEM_ATOMIC_INC (volatile int *ptr) static inline void MPID_NEM_ATOMIC_DEC (volatile int *ptr) The following similarly named routines already exist in mpich2: % grep -ri mpi._atomic_ /sandbox/mpi/src/mpich2/src | perl -ne 's/^.*(mpi._atomic\w+).*$/$1/i and print' | sort | uniq MPID_Atomic_decr_flag MPID_Atomic_fetch_and_incr MPID_Atomic_incr MPID_ATOMIC_SET_IF_ZERO MPID_Atomic_write_barrier I propose that we extend the Nemesis functions to provide implementations for additional platforms as well as a slower fallback implemented via locking. We would then make these improved functions available to the rest of MPI as the following routines: static inline void *MPID_Atomic_swap (volatile void *ptr, void *val) static inline void *MPID_Atomic_cas (volatile void *ptr, void *oldv, void *newv) static inline int MPID_Atomic_cas_int (volatile int *ptr, int oldv, int newv) static inline int MPID_Atomic_fetch_and_add (volatile int *ptr, int val) static inline void MPID_Atomic_add (int *ptr, int val) + static inline int MPID_Atomic_fetch_and_incr (volatile int *ptr) static inline int MPID_Atomic_fetch_and_decr (volatile int *ptr) + static inline void MPID_Atomic_incr (volatile int *ptr) static inline void MPID_Atomic_decr (volatile int *ptr) The functions prepended with a '+' already exist as cpp macros and will be replaced by the Nemesis versions. The two existing uses of MPID_Atomic_fetch_and_decr will be altered to take the old value as a normal return value instead of as a "parameter return" value. Question: do we have any reason to believe that any MPICH derivatives might be using this macro as it currently exists? And if so, do we need to maintain backwards compatibility? These functions would all be defined in "src/include/mpiatomic.h" in order to make them available to the entirety of the mpich code. The original Nemesis versions would eventually be removed and all uses would be replaced by the new routines. I would appreciate any comments you might have, since I am not very familiar with the history of the existing MPID_Atomic_* routines. Thanks, -Dave

5 12

1.0.6 release tarball
by Rajeev Thakur 14 Sep '07

14 Sep '07

Has been created in ftp://ftp.mcs.anl.gov/pub/mpi/mpich2-1.0.6.tar.gz . If you have a chance please test it out. We plan to release it this weekend. Jayesh, you can create the Windows binaries from this tarball. Rajeev

4 16

creating release tarball
by Rajeev Thakur 14 Sep '07

14 Sep '07

I am in the process of creating a 1.0.6 tarball so that Jayesh can create the Windows binaries from it. We will let the nightly tests run one more night before releasing because there was a small bug even last night, which has been fixed. The plan is to release over the weekend. Rajeev

2 1

dtrace/mpi demo
by Narayan Desai 07 Sep '07

07 Sep '07

This is for openMPI, but it should work with any MPI implementation. It is solaris specific though. http://developers.sun.com/solaris/articles/dtrace_article.html -nld

1 0

MPICH2 SVN
by Pavan Balaji 06 Sep '07

06 Sep '07

Hi all, I was working on moving the MPICH2 CVS to SVN and ran into some problems. The primary one relates to a bug in very old versions of CVS which keeps a copy of a file in the original directory (together with the Attic directory) in cases where its deleted in the trunk but is retained in one or more branches. It looks like the MPICH2 CVS, at some point in the past, used this buggy version which has created such files. There are no clean workarounds for this. Trying to manually edit the head of the trunk and the 50 existing branches is painfully time consuming and has no guarantee on the correctness of the different branches unless someone manually verifies each of them. Instead of having to deal with all these problems, I was thinking that we might want to consider dropping the history of the trunk and the branches while moving the data to SVN. Also, we can probably just move the active branches and tags instead of all of them. Given how rarely people refer to older versions of the stack, I doubt we'll miss the history after working on the SVN for a month or so. Also, if someone needs an even older version, the CVS repository will still be available for read-only checkouts. Is this acceptable? Bill? Rajeev? -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

5 7

[Fwd: RE: SVN]
by Darius Buntinas 06 Sep '07

06 Sep '07

-------- Original Message -------- Subject: RE: SVN Date: Thu, 6 Sep 2007 12:45:54 -0500 From: Brian R. Toonen <toonen(a)mcs.anl.gov> To: 'Darius Buntinas' <buntinas(a)mcs.anl.gov> CC: 'Brian R. Toonen' <toonen(a)mcs.anl.gov> References: <46E01543.8060507(a)mcs.anl.gov> No, I'm not. Thanks for sending the messages. Would it be possible to have me added to the discussion? I need to know when the cutover is going to take place because I have code to commit to a branch. I'm expecting to commit that code today assuming testing goes well. Thanks again, --brian |-----Original Message----- |From: Darius Buntinas [mailto:[email protected]] |Sent: Thursday, September 06, 2007 09:57 |To: Brian R. Toonen |Subject: SVN | |Hey Brian, | |I don't know whether you're in the loop on this. We're working on |moving the MPICH2 repo from cvs to svn. I'll forward the latest |discussion on to you. | |-d

1 0

Fwd: Development Unit Testing Framework for MPI
by William Gropp 06 Sep '07

06 Sep '07

This might be interesting. Bill Begin forwarded message: > From: midmind(a)mail.goo.ne.jp > Date: September 2, 2007 11:52:58 AM CDT > To: gropp(a)mcs.anl.gov > Subject: Development Unit Testing Framework for MPI > > > Dear MPICH Developers > > I developed MPIUnit. > MPIUnit is a Unit Testing Framework for MPI Programs. > This framework supports making and execution of the unit test > of MPI programs. > > Please, see the following web site. > There is source codes and documents of MPIUnit. > > https://sourceforge.jp/projects/mpiunit/ > > Sincerely > > ---------------------------------------------- > > Shinya Abe > Graduate School of Engineering, Iwate University, Japan > > Email : midmind(a)mail.goo.ne.jp >

5 5