July 2012 - Mpich2-core - mailman3.cels.anl.gov

Fwd: Regarding some more advanced aspects of MPI
by Darius Buntinas 07 Aug '12

07 Aug '12

Another satisfied customer! -d Begin forwarded message: > From: <jgrime(a)uchicago.edu> > Subject: Re: Regarding some more advanced aspects of MPI > Date: July 27, 2012 3:34:37 PM CDT > To: "Darius Buntinas" <buntinas(a)mcs.anl.gov> > > Hi Darius, > > Thanks for the response! > >> I'm not sure how OpenMPI works ... > > I came to this conclusion a couple of days ago; after massive frustration in trying to get OpenMPI to recognise me registering error handlers, and not totally dying when I deliberately killed a process, I finally discovered that this behaviour is by design; OpenMPI simply cannot handle one or more processes dying! As such, it's useless to me. > > I did, however, install MPICH2 and it works like a dream! > > I now have a fault tolerant backend broadcast system, which automatically detects failed nodes and informs the rest of the simulation. Some nice side effects of how I've implemented this are: > > 1. If any node fails, all the other nodes are automatically made aware of this in the background. The specific manner in which I implement the "broadcast" messages also uncovers automatically any other nodes which have died without anyone otherwise noticing. Therefore, *any* use of the backend communications channel will automatically reveal to all nodes exactly which other nodes have crashed. I think this will be very useful to me in future! > > 2. All the backend communications should be very scalable, as the broadcasts are split into smaller "block communications", which are sent to the first node in the specified range. This node retransmits the message to the other nodes in that block range. The block messages themselves are subject to re-splitting, down to some specified minimum block size - at which point they are sent directly using point-to-point communications (the actual messages are very small, so can fit into MPI's "eager" send packets). Hopefully, this should scale very well as we're using what amounts to a tree structure to send in parallel. Speaking of which ... > > 3. The parallel broadcast is itself fault tolerant; there's no single point of failure, and any node can die at any time without stopping the background messages getting to every node. As we define ranges over which the block messages operate, we can easily iterate through the block members from the first member, and pass the message onto the next one which is capable of handling it. The broadcast "tree" for these collective communications is dynamic and fault tolerant, in that sense. > >> -disable-auto-cleanup > > That's exactly what I use! :) > > Kudos to you guys for MPICH2 - it's very impressive, and I have now been able to implement pretty much exactly what I needed without having to use multicasts over IPv4/6, ibverbs or whatever I feared I may have to use. With it being plain old MPI v2, I should be able to deploy systems using this approach to the Blue Gene machines, clusters with Gemini interconnects etc using just the provided software on the clusters themselves, while also taking automatic advantage of the tuned MPI libraries for each. > > I'm really happy with how it's turned out, and the fact that I managed to do so in "pure" MPI. It was a fun technical exercise over a few days! > > Cheers, > > J.

5 5

ERRTEST_NULL Out comm/win/etc parameters
by Jim Dinan 01 Aug '12

01 Aug '12

Hi All, I noticed that there are many MPI_ functions where we don't NULL-check out-parameters. Right now, if you pass NULL as the new handle pointer to a communicator or window creation routine, MPICH will seg fault (example attached). Is this an oversight? More specifically, should I not add: MPIR_ERRTEST_ARGNULL(win) to the window creation routines? ~Jim.

2 2

Contributor agreements
by Pavan Balaji 30 Jul '12

30 Jul '12

I've updated the address on the contributors' agreements. Attached new version. I also took this opportunity to change the agreements to say both MPICH and MPICH2, since we are planning to change the project name back to MPICH for the 3.0 release. Do we need to run this by legal again? Do all the organizations that signed the original MPICH2 agreement need to sign this one again? -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

2 2

license agreement address
by Dave Goodell 26 Jul '12

26 Jul '12

Who do we talk to about getting the PDF for the CLA updated on the website? We need a more specific address on it so that people don't inadvertently send more signed CLAs to "/dev/null"... -Dave

3 2

Fwd: [mpich2-cray] Future plans
by Dave Goodell 25 Jul '12

25 Jul '12

Are we still having a BoF, given the SC travel restrictions? -Dave Begin forwarded message: > From: Pavan Balaji <balaji(a)mcs.anl.gov> > Subject: Re: [mpich2-cray] Future plans > Date: July 25, 2012 10:15:58 AM CDT > To: Steve Oyanagi <sko(a)cray.com> > Cc: "<mpich2-cray(a)mcs.anl.gov>" <mpich2-cray(a)mcs.anl.gov> > > Hi Steve, > > The roadmap page on the mpich2 trac site should have the major feature list planned for 1.5. This release will be out mid next month. RMA is not planned for this release, though some bits might appear in there. > > The next major release will be mpich-3.0 (renamed from mpich2-1.6). This will be a full MPI-3 release. A pre-release for this is planned for our SC BoF. The full release of mpich-3.0 will be early Q1 2013. > > We'll schedule telecons with all our vendor partners (separately), once 1.5 is out next month. > > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji > > On Jul 25, 2012, at 9:06 AM, Steve Oyanagi <sko(a)cray.com> wrote: > >> Hi, >> >> Could someone at ANL give some rough indications of when MPI-3 >> features would appear in MPICH2, and in general what features >> would be be in MPICH2 1.5 and 1.6? Also, is there a projected >> release date for MPICH2 1.6? >> >> We are in particular interested in: >> >> 1. When MPI-3 RMA will appear. I know this feature is not a >> gating feature for MPICH2 1.5, but I also note that some of the >> MPI-3 RMA changes was checked into trunk recently. >> >> 2. If ANL is planning on doing any more work on fine grain locking >> for thread multiple thread safety. This should not be construed >> as a request for support, we are trying to determine if we will >> need to do more work in this area in the future. >> >> Thanks, >> - Steve >> _______________________________________________ >> mpich2-cray mailing list >> mpich2-cray(a)lists.mcs.anl.gov >> https://lists.mcs.anl.gov/mailman/listinfo/mpich2-cray > _______________________________________________ > mpich2-cray mailing list > mpich2-cray(a)lists.mcs.anl.gov > https://lists.mcs.anl.gov/mailman/listinfo/mpich2-cray

5 5

nightly test failures
by Rajeev Thakur 25 Jul '12

25 Jul '12

The build with shared libraries failed last night but worked the night before. All builds with ch3:sock failed last night but worked the night before. http://www.mcs.anl.gov/research/projects/mpich2/nightly/old/

2 1

Re: [mpich2-core] MPICH2 Fortran bindings for MIC
by Anthony Chan 25 Jul '12

25 Jul '12

Pavan, I added a script (configure) that runs on the MIC frontend (knight.mcs.anl.gov)to generate a MPICH2 cross file for all Fortran related tests (The mechanism should be general enough to extend to C++ if it has any runtime tests). The code is in mpich2/maint/fcrosscompile cd mpich2/maint/fcrosscompile ./autogen.sh ./run_configure The autogen.sh generates a modified configure script. The trivial run_configure launches configure with icc/ifort + "-mmic" option. The modified configure will generate a "cross_values.txt" which can be used with mpich2's configure option --with-cross. I tested the cross file as follows on knight.mcs.anl.gov ../mpich2/configure 'CC=icc -mmic' 'F77=ifort -mmic' 'FC=ifort -mmic' '--disable-cxx' --disable-weak-symbols cross_compiling=yes --with-cross=../mpich2/maint/fcrosscompile/cross_values.txt '--prefix=/home/chan/mpich2_work/install_cross' To extend to other platforms, one needs to modify cross_run script on launching an executable on the backend. So far thing seems to work, I was able to run MIC executable cpi/fpi/pi3f90. I have yet figured how to run the test/mpi suite in this cross-compilation env. Since the cross-compiled mpiexec.hydra built can't be run on frontend, but the backend has no make so I can just do "make testing" on the backend. I suppose I need a mpiexec.hydra built for frontend and used it on runtest. Anyway, let me know if there is any documentation on launching hydra in such cross-compilation env. PS. I cc'ed this to mpich2-core just in case someone else may find the scripts useful for other platform. A.Chan ----- Original Message ----- > Hey, > > Any update on the MPICH2 Fortran bindings for MIC? We should try to > fix > it up soon. > > -- Pavan > > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji

3 4

MPI-3 RMA Interface
by Jim Dinan 24 Jul '12

24 Jul '12

Hi All, Heads up -- I just committed the MPI-3 RMA interface to the trunk. Right now, all of the new functionality is implemented down to the ADI layer; over the next couple months, I'll be filling in the ch3 implementation. Some things are already implemented, including window flavor attributes, MPI_Win_allocate, and bits of shared memory window support. ~Jim.

1 0

Fwd: 10 mpich-discuss moderator request(s) waiting
by Dave Goodell 16 Jul '12

16 Jul '12

Why do we have the list set for any moderation? Why not just automatically send bounce responses so that we don't have to deal with these reminders and so that we don't get stale emails like Marcelo's today. Does anyone object if I change the moderation settings to the option with a lower maintenance burden? -Dave Begin forwarded message: > From: mpich-discuss-bounces(a)mcs.anl.gov > Subject: 10 mpich-discuss moderator request(s) waiting > Date: July 14, 2012 8:00:17 AM CDT > To: mpich-discuss-owner(a)mcs.anl.gov > > The mpich-discuss(a)mcs.anl.gov mailing list has 10 request(s) waiting > for your consideration at: > > https://lists.mcs.anl.gov/mailman/admindb/mpich-discuss > > Please attend to this at your earliest convenience. This notice of > pending requests, if any, will be sent out daily. > > > Pending posts: > From: junior_santoss(a)hotmail.com on Sat Jul 7 01:37:50 2012 > Subject: Curriculum Vitae URGENTE > Cause: Post by non-member to a members-only list > > From: ohladitel(a)msmtp.com.ua on Sat Jul 7 02:53:13 2012 > Subject: ?????????? ????????? ??????? NV-100 > Cause: Post by non-member to a members-only list > > From: truong.tam(a)dongchau.net on Mon Jul 9 04:14:04 2012 > Subject: Lap cam ket BVMT, Danh gia tac dong moi truong, Xin Giay phep xa thai, Dang ky chu nguon CTNH, TRam lap gieng khoan > Cause: Post by non-member to a members-only list > > From: tamgv(a)yahoo.com on Mon Jul 9 07:23:08 2012 > Subject: Tui loc cat long, binh loc, loi loc, Giay loc phong som, khung loc khi, tui loc bui, vai loc bui, Vai loc chat long, luoi inox > Cause: Post by non-member to a members-only list > > From: angelv(a)iac.es on Tue Jul 10 04:49:28 2012 > Subject: Launch MPI jobs with niceness 19? > Cause: Post by non-member to a members-only list > > From: tho(a)galaxystar.com.vn on Tue Jul 10 21:06:13 2012 > Subject: CUNG C?P SU?T ?N C?NG NGHI?P > Cause: Post by non-member to a members-only list > > From: soares.souza(a)gmail.com on Wed Jul 11 13:14:54 2012 > Subject: mpich2 1.5b2 Ubuntu and Debian packages (x86 and amd64) > Cause: Post by non-member to a members-only list > > From: rassylka100(a)ukr.net on Wed Jul 11 14:37:47 2012 > Subject: ???????? ??????? ?? ????? ????? ????????? > Cause: Post by non-member to a members-only list > > From: contact(a)bits77.com on Wed Jul 11 17:12:54 2012 > Subject: Giai phap tang doanh so ban hang danh cho Doanh Nghiep/Ca Nhan chi phi re nhat > Cause: Post by non-member to a members-only list > > From: tabu1989(a)yahoo.co.in on Thu Jul 12 00:47:57 2012 > Subject: Problems with installation of mpich2 > Cause: Post by non-member to a members-only list

4 8

Planning for 1.5rc1
by Pavan Balaji 09 Jul '12

09 Jul '12

I'll let Dave point out the time line for 1.5rc1, but here's the list of things remaining (apart from bug fixes): Pavan: - MPI-3: Hindexed_block (coded but buggy) - MPI-3: MPI_Comm_split_type and hindexed_block fortran tests - Topology improvements contributed by Queen's Darius: - Portals4 implementation Dave: - MPI-3: Neighborhood collectives - MPI-3: Get_library_version - BG/Q code integration Robl: - External32 Please add other items that I missed out above. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

2 2