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

duplicate dataloop directory
by Dave Goodell 09 Sep '08

09 Sep '08

What would it take to be able to get rid of one of the two copies of the dataloop code that we have in the mpich2 source tree? My understanding is that we use the src/mpid/common copy and the src/mpi/ romio/common copy is unused except by others like OpenMPI that use our MPI-IO implementation separately. The two copies have diverged over time through developer error and this has the potential to cause some pretty frustrating errors down the road. Possible solutions: 1) Use the svn:externals feature to cause the code to be checked out into the ROMIO directory automatically. Unfortunately this svn feature seems a bit fragile and I'm not sure how we would make it play nicely with the two different build systems. 2) Delete the copy in the romio dir. Add a "make romio-export" target or similar that copies the code into the romio tree that is used whenever someone is trying to incorporate ROMIO into their non- mpich2 codebase. 3) Delete the copy in the romio dir outright and just make anyone who is trying to use ROMIO separately copy it by hand. 4) Make the romio dir code the canonical code and get rid of the mpid/ common code. I like this because ROMIO will almost always be present in MPICH2. It has problems wrt what happens if someone configures with --disable-romio and probably something else that I'm not thinking of. 5) Pull ROMIO out into a separate library of some sort and make MPICH2 depend on it in a more traditional fashion, rather than building it into the library. This could work well for folks like OpenMPI as well, since they might have less work to do to incorporate it into their build system. OTOH, this is probably harder than it appears to me at first glance. 6) Change to some revision control system that can handle hard-links within the repository. This would be a high-effort change and I don't know off the top of my head whether there even are any systems that handle hard-links properly. I favor something like #2, although I'm not exactly familiar with all of the issues here. Thoughts? -Dave

5 5

mpich2-1.0.8 release status
by Pavan Balaji 07 Sep '08

07 Sep '08

Hi all, It looks like most of the nightly tests are passing from the 1.0.x branch. The OSU multi-threaded test is still failing, but I believe the plan is to leave this open for 1.1. Apart from these, here are a few more failures: ========================================================================== 1. threads/pt2pt/alltoall (why is there an all2all in pt2pt?) is failing in the following combination: --with-pm=smpd --with-pmi=smpd --with-device=ch3:sock CC=gcc CXX=g++ F77=g77 F90=gfortran --enable-strict=posix 2. NAS MG is failing in the following combination: --with-pm=mpd --with-device=ch3:nemesis CC=gcc CXX=g++ F77=g77 F90=gfortran --enable-nemesis-dbg-localoddeven ========================================================================== Is there any other bug we should try to fix for this release? You might see two more failures on breadboard with the Intel compilers, but you can ignore them -- we only have 10 licenses for MCS; so depending on who else is running nightly tests, we might not get a license. These failures are an artifact of the limited licenses. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

2 4

MPICH2 and BLCR
by Rajeev Thakur 29 Aug '08

29 Aug '08

Hi Paul and Eric, We have been thinking about adding support for BLCR in MPICH2, and Intel also recently expressed interest in it for Intel MPI, which is based on MPICH2. Do you have an estimate for how much effort is involved in doing that? Is there any document or web page we can look at for more information on what needs to be done? Thanks, Rajeev

2 2

BLCR
by Rajeev Thakur 26 Aug '08

26 Aug '08

Does anyone know how much effort it would be to add support for BLCR (Berkeley lab checkpoint/restart library) in MPICH2? It came up in the phone call with Intel yesterday morning. Also, do users care about it? MVAPICH2 and Open MPI have it. Rajeev

4 4

error code docs
by Dave Goodell 26 Aug '08

26 Aug '08

I've written up some documentation about how to return error codes in MPICH2 functions here: http://wiki.mcs.anl.gov/mpich2/index.php/ Coding_Standards#Returning_Error_Codes It's a little bit rough, but at least it's something that we can refer to and clean up as we go along. Up until now there haven't been any docs about this stuff where we can point someone for a simple explanation of what they should do wrt error codes. If you see any problems, please either fix them or let me know so that I can fix them. Thanks, -Dave

2 1

can't view changesets in trac as anonymous
by Dave Goodell 25 Aug '08

25 Aug '08

The MPICH2 trac site has a permissions quirk wrt viewing changesets and browsing source as the anonymous user. I've filed a bug about it here: https://trac.mcs.anl.gov/projects/mpich2/ticket/107 Unfortunately, I don't think anyone on the MPICH2 team knows enough about trac to figure out the problem. Could someone from systems take a look? Thanks, -Dave

1 0

MPICH2 web page access
by Rajeev Thakur 25 Aug '08

25 Aug '08

The results of MPICH2 nightly tests are stored at http://www-unix.mcs.anl.gov/mpi/mpich1/micronotes/mpich2-status/#mpd-ch3:soc k . None of the links on that page work today. For example, if I click on http://www.mcs.anl.gov/research/projects/mpich2/todo/runs/IA32-Linux-GNU-mpd -ch3:sock-make-2008-08-22-22-00.htm, I get "Forbidden You don't have permission to access /research/projects/mpich2/todo/runs/IA32-Linux-GNU-mpd-ch3:sock-make-2008-08 -22-22-00.htm on this server. Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request." Rajeev

1 0

Nightly tests results unavailable
by William Gropp 25 Aug '08

25 Aug '08

I get You don't have permission to access /research/projects/mpich2/todo/ runs/x86_64-Linux-Intel-mpd-ch3:sock-2008-08-24-22-00.xml on this server. Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request. when I try to access the results of the nightly tests. Bill William Gropp Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

1 0

WFH today
by Jayesh Krishna 20 Aug '08

20 Aug '08

Hi, My wife had a doctor's appt today and it went longer than we expected, so I will be working from home today. I am available via email/mpich2-core jabber room/cell (571-451-7378). Regards, Jayesh

2 2

MPID_Segment_pack() behavior
by David Gingold 18 Aug '08

18 Aug '08

MPICH2 folks -- I've a question about MPID_Segment_pack(): In the particular bug I'm working on, I have a datatype build with MPI_Type_indexed(), with the underlying type MPI_LONG_DOUBLE (which is 16 bytes for us). I'm calling MPID_Segment_pack() to pack the first 88 bytes of that into a buffer. MPID_Segment_pack() responds by packing the first 80 bytes. It refuses to break up the 11th long double element, only half of which would fit into my 88-byte buffer. Is this in fact by design? If I am using MPID_Segment_pack() with arbitrary datatypes, do I need to be prepared for it to stop packing at some boundary that is smaller than my buffer size? Is there a limit to how much smaller that will be? -dg

3 5