- discuss - mailman3.cels.anl.gov

mpich-3.0.1 LLONG_MAX undeclared in status_set_elements_x.c
by Bodony, Daniel J 24 Jan '13

24 Jan '13

MPICH Friends, A fresh version of mpich-3.0.1 fails to compile due to LLONG_MAX being undeclared in status_set_elements_x.c. (I see in the mpich-devel mailing list this was identified about a month ago, too.) My information: bodony@acoustics-0:~/mpich2-1.4.1p1$ uname -a Linux acoustics-0 2.6.28-19-generic #61-Ubuntu SMP Wed May 26 23:35:15 UTC 2010 i686 GNU/Linux bodony@acoustics-0:~/mpich2-1.4.1p1$ icc -V Intel(R) C Compiler XE for applications running on IA-32, Version 13.0.1.117 Build 20121010 mpich-3.0.1 configure line: ./configure --enable-fc --enable-cxx --enable-f77 For now I'll back off to mpich2-1.4.1p1. Cheers, Dan -- Daniel J. Bodony Assistant Professor of Aerospace Engineering Affiliate Professor of Mechanical Science & Engineering University of Illinois at Urbana-Champaign

1 0

Re: [mpich-discuss] MPI_THREAD_MULTIPLE support on ch3:sock?
by Dave Goodell 24 Jan '13

24 Jan '13

Fixed by http://git.mpich.org/mpich.git/commit/29393b Expect to see this in the upcoming 3.0.2 release. -Dave On Jan 24, 2013, at 2:09 PM CST, Dave Goodell wrote: > FWIW, usually you want to leave the default in place, which is "runtime". > > I can reproduce your problem. I've filed a ticket for it: https://trac.mpich.org/projects/mpich/ticket/1787 > > -Dave > > On Jan 24, 2013, at 1:34 PM CST, Nicolas Rosner wrote: > >> Hello, >> >> I'm trying to configure MPICH2 1.5 with the sock device and MULTIPLE >> thread support level. >> >> At first I configured without specifying anything about threads (since >> on my MPICH2 1.4.x machines, using just --with-device=ch3:sock does >> seem to build with MULTIPLE support by default). But all I obtained >> was SINGLE. >> >> So I tried to reconfigure the 1.5 release, now explicitly specifying >> --enable-threads=multiple, and got: >> >> error: The device ch3:sock does not support MPI_THREAD_MULTIPLE >> >> Yet on the README for the 1.5 release, I see: >> >> --enable-threads - Build MPICH2 with support for multi-threaded >> applications. Only the sock and nemesis channels >> support MPI_THREAD_MULTIPLE. >> >> Should this work? Any differences between 1.4 and 1.5 on this? >> >> Thanks, >> Nicolás >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] MPI_THREAD_MULTIPLE support on ch3:sock?
by Dave Goodell 24 Jan '13

24 Jan '13

FWIW, usually you want to leave the default in place, which is "runtime". I can reproduce your problem. I've filed a ticket for it: https://trac.mpich.org/projects/mpich/ticket/1787 -Dave On Jan 24, 2013, at 1:34 PM CST, Nicolas Rosner wrote: > Hello, > > I'm trying to configure MPICH2 1.5 with the sock device and MULTIPLE > thread support level. > > At first I configured without specifying anything about threads (since > on my MPICH2 1.4.x machines, using just --with-device=ch3:sock does > seem to build with MULTIPLE support by default). But all I obtained > was SINGLE. > > So I tried to reconfigure the 1.5 release, now explicitly specifying > --enable-threads=multiple, and got: > > error: The device ch3:sock does not support MPI_THREAD_MULTIPLE > > Yet on the README for the 1.5 release, I see: > > --enable-threads - Build MPICH2 with support for multi-threaded > applications. Only the sock and nemesis channels > support MPI_THREAD_MULTIPLE. > > Should this work? Any differences between 1.4 and 1.5 on this? > > Thanks, > Nicolás > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

MPI_THREAD_MULTIPLE support on ch3:sock?
by Nicolas Rosner 24 Jan '13

24 Jan '13

Hello, I'm trying to configure MPICH2 1.5 with the sock device and MULTIPLE thread support level. At first I configured without specifying anything about threads (since on my MPICH2 1.4.x machines, using just --with-device=ch3:sock does seem to build with MULTIPLE support by default). But all I obtained was SINGLE. So I tried to reconfigure the 1.5 release, now explicitly specifying --enable-threads=multiple, and got: error: The device ch3:sock does not support MPI_THREAD_MULTIPLE Yet on the README for the 1.5 release, I see: --enable-threads - Build MPICH2 with support for multi-threaded applications. Only the sock and nemesis channels support MPI_THREAD_MULTIPLE. Should this work? Any differences between 1.4 and 1.5 on this? Thanks, Nicolás

1 0

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 Rajeev Thakur 24 Jan '13

24 Jan '13

I found this with a Google search. http://people.sc.fsu.edu/~jburkardt/classes/acs2_2008/mpi/mpi_stubs/mpi_stu… On Jan 24, 2013, at 7:17 AM, Anton Daneyko 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

1 0

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