January 2013 - discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] How can one test C\C++ code which uses MPI calls: is there any set of mock functions, that I can use?
by Jeff Hammond 24 Jan '13

24 Jan '13

I recall that both LAMMPS and PETSc have a stub MPI implementation, although I've only read the latter. I doubt either is complete but rather contains only a set of necessary MPI-1 routines. Jeff On Thu, Jan 24, 2013 at 7:17 AM, Anton Daneyko <self(a)mezhaka.com> wrote: > Here's an example: > > #include <mpi.h> > double f() { > double timer = MPI_Wtime(); > return timer; > } > > What I am searching for is some set of mock MPI functions, so I can #include > <mpi_mocks.h> instead of mpi.h and get it compiled without linking to MPI > library. It could also be something like #define MOCK which will trigger > this behavior in mpi.h. It feels, like I've stumbled on something like this, > but I cannot find it right now. > > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond

1 0

Re: [mpich-discuss] bug when used with valgrind
by Dave Goodell 24 Jan '13

24 Jan '13

On Jan 24, 2013, at 7:52 AM CST, Evren Yurtesen IB wrote: > On Wed, 23 Jan 2013, Dave Goodell wrote: > >> On Jan 23, 2013, at 12:22 PM CST, Evren Yurtesen IB wrote: >> >>> https://bugs.launchpad.net/ubuntu/+source/mpich2/+bug/1045326 >> >> Pavan Balaji, who commented 2012-09-03, represents "us" on this matter. > > Oh ok, but should I create a bug report as he suggested? I don't personally think that's necessary. There's nothing that we can really do about the problem, and there's already enough google-bait on the issue on both that launchpad bug and on the mailing list archives for this list. Thanks for following up with us. >> Based on what Paul said in that link and some cursory googling, it sounds like that issue was never upstreamed to the Valgrind folks. > > I will try to poke valgrind developers also :) OK. I monitor their lists and I'll keep an eye on the thread you started. For anyone who is reading this in our list archives, here's the thread: http://thread.gmane.org/gmane.comp.debugging.valgrind.devel/21882 >> I agree with you that the easiest way to resolve the Launchpad bug is to just omit the checkpointing arguments, although this has the downside of disabling this functionality. A more involved fix would be to patch the BLCR library in the fashion mentioned in the lbl.gov link above. > > I think it is already non-functional for Ubuntu 12.04+ versions. There is also a bug report about BLCR because it does not work with 3.x kernels anymore and all 12.* Ubuntu versions use 3.x kernels: > https://bugs.launchpad.net/ubuntu/+source/blcr/+bug/804943 > > Also checkpoint homepage confirms this (last version supports up to kernel 2.6.38): > https://ftg.lbl.gov/projects/CheckpointRestart/ > > So, I think it may be possible to convince Ubuntu package makers to remove checkpoint options which are not useful anyway. But I am not sure who to inform about this problem at this point. It does sound like disabling BLCR makes the most sense on modern Ubuntu versions. Hopefully enough comments to that effect on the ticket will cause someone to wakeup an pay attention. -Dave

1 0

Re: [mpich-discuss] bug when used with valgrind
by Evren Yurtesen IB 24 Jan '13

24 Jan '13

On Wed, 23 Jan 2013, Dave Goodell wrote: > On Jan 23, 2013, at 12:22 PM CST, Evren Yurtesen IB wrote: > >> It appears there are problems with mpich2 packages provided by ubuntu 12.04/12.10 etc. I think the problem is the compile time arguments they use when building them. >> >> I made a bug report to ubuntu launchpad but they suggested I should contact you also. Can somebody please have a look and comment on the bug report? >> >> https://bugs.launchpad.net/ubuntu/+source/mpich2/+bug/1045326 > > Pavan Balaji, who commented 2012-09-03, represents "us" on this matter. Oh ok, but should I create a bug report as he suggested? > To me the problem just looks like a fundamental disagreement/incompatibility between BLCR and Valgrind (at least for certain versions of each package). See this BLCR thread: https://hpcrdm.lbl.gov/pipermail/checkpoint/2011-September/000311.html > > Based on what Paul said in that link and some cursory googling, it sounds like that issue was never upstreamed to the Valgrind folks. I will try to poke valgrind developers also :) > I agree with you that the easiest way to resolve the Launchpad bug is to just omit the checkpointing arguments, although this has the downside of disabling this functionality. A more involved fix would be to patch the BLCR library in the fashion mentioned in the lbl.gov link above. I think it is already non-functional for Ubuntu 12.04+ versions. There is also a bug report about BLCR because it does not work with 3.x kernels anymore and all 12.* Ubuntu versions use 3.x kernels: https://bugs.launchpad.net/ubuntu/+source/blcr/+bug/804943 Also checkpoint homepage confirms this (last version supports up to kernel 2.6.38): https://ftg.lbl.gov/projects/CheckpointRestart/ So, I think it may be possible to convince Ubuntu package makers to remove checkpoint options which are not useful anyway. But I am not sure who to inform about this problem at this point. Thanks, Evren

1 0

How can one test C\C++ code which uses MPI calls: is there any set of mock functions, that I can use?
by Anton Daneyko 24 Jan '13

24 Jan '13

Here's an example: #include <mpi.h>double f() { double timer = MPI_Wtime(); return timer;} What I am searching for is some set of mock MPI functions, so I can #include <mpi_mocks.h> instead of mpi.h and get it compiled without linking to MPI library. It could also be something like #define MOCK which will trigger this behavior in mpi.h. It feels, like I've stumbled on something like this, but I cannot find it right now.

1 0

Writing files
by Qiguo Jing 23 Jan '13

23 Jan '13

Hi All, I have a FORTRAN program, which needs to open a new file and write information to it. I only want the main processor to do the writing, so I did this: IF (IMRANK .EQ. 0) THEN OPEN (IDRUNT(IDEM),FILE=DIRFIL(IDEM), & ACCESS='DIRECT',RECL=LREC_DIR) END IF However, no matter how many processors I specified for the program, after the parallel program finishes, the file (121M) generated by the main processor is different from the one (30M) generated without paralleling. Can someone provide any insights? Thanks. _________________________________________________________________________ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you Received this in error, please contact the sender and delete the material from any computer. _________________________________________________________________________

1 0

Re: [mpich-discuss] Deadlock in MPI_Ibarrier over ch3:sock
by Dave Goodell 23 Jan '13

23 Jan '13

On Jan 23, 2013, at 3:46 PM CST, Jed Brown wrote: > > On Wed, Jan 23, 2013 at 3:42 PM, Dave Goodell <goodell(a)mcs.anl.gov> wrote: > I think checking of the "MPIDI_CH3I_sock_errno_to_mpi_errno" symbol should be unique enough to detect ch3:sock. > > Thanks, I'll add this test and combine it with a version check (unless there's something better) once the bug is fixed. I can add a special "MPIDI_CH3I_sock_with_fixed_nbc_progress" symbol (or whatever) for you as soon as it's fixed. -Dave

1 0

Re: [mpich-discuss] Deadlock in MPI_Ibarrier over ch3:sock
by Jed Brown 23 Jan '13

23 Jan '13

On Wed, Jan 23, 2013 at 3:42 PM, Dave Goodell <goodell(a)mcs.anl.gov> wrote: > I think checking of the "MPIDI_CH3I_sock_errno_to_mpi_errno" symbol should > be unique enough to detect ch3:sock. > Thanks, I'll add this test and combine it with a version check (unless there's something better) once the bug is fixed.

1 0

Re: [mpich-discuss] Deadlock in MPI_Ibarrier over ch3:sock
by Dave Goodell 23 Jan '13

23 Jan '13

On Jan 23, 2013, at 3:35 PM CST, Jed Brown wrote: > > On Wed, Jan 23, 2013 at 2:44 PM, Dave Goodell <goodell(a)mcs.anl.gov> wrote: >> A run-time test that doesn't require looking at which symbols are compiled into the app? I can't think of one off the top of my head, although I suppose we could add one in the future via either MPI_T or the new MPI_Get_library_version routine. >> > A configure-time test is fine. I can look for symbols in libmpich.a, for example. Is something exported that would be proof-positive of ch3:sock? We would like to avoid _running_ MPI code at configure time because many machines prevent anything that links MPI from running on an interactive node. I think checking of the "MPIDI_CH3I_sock_errno_to_mpi_errno" symbol should be unique enough to detect ch3:sock. -Dave

1 0

Re: [mpich-discuss] Deadlock in MPI_Ibarrier over ch3:sock
by Jeff Hammond 23 Jan '13

23 Jan '13

>> How is this not a no-op implementation for MPI_COMM_SELF? All you >> need to support is load-store on local memory, no? > > We also need to support all of the RMA communication and synchronization > operations. This is not an overly complex or large task, it's just > currently lower priority that others. That said, if shared memory window > support in ch3:sock is something that would prevent you or anyone else from > using MPI 3.0 RMA, please speak up and I'll make it higher priority. I recant my previous statement on account of ignorance and because I don't use ch3:sock and prefer you not worry about this. It's not like PETSc is using MPI_WIN_ALLOCATE_SHARED right now anyways. Jeff -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond

1 0

Re: [mpich-discuss] Deadlock in MPI_Ibarrier over ch3:sock
by Jed Brown 23 Jan '13

23 Jan '13

On Wed, Jan 23, 2013 at 2:44 PM, Dave Goodell <goodell(a)mcs.anl.gov> wrote: > A run-time test that doesn't require looking at which symbols are compiled > into the app? I can't think of one off the top of my head, although I > suppose we could add one in the future via either MPI_T or the new > MPI_Get_library_version routine. > A configure-time test is fine. I can look for symbols in libmpich.a, for example. Is something exported that would be proof-positive of ch3:sock? We would like to avoid _running_ MPI code at configure time because many machines prevent anything that links MPI from running on an interactive node.

1 0