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

Configuration issues for mpich2-1.5b2
by Bharath Ramesh 28 Jan '13

28 Jan '13

I hit an error while trying to build mvapich2-1.9a2 which I can reproduce with mpich2-1.5b2. When I try configuring mpich2 or mvapich2 hwloc isnt configured properly and configure ends up detecting the sizes incorrectly which results in a build failure when compiling. I reported this issue with mvapich2 mailing list[1]. The error I am noticing for mpich2-1.5b2 is as follows: ### ### Configuring hwloc core ### checking hwloc building mode... embedded configure: hwloc builddir: /home/bramesh/ARC/apps/build/mpich2-1.5b2/src/pm/hydra/tools/topo/hwloc/hwloc configure: hwloc srcdir: /home/bramesh/ARC/apps/build/mpich2-1.5b2/src/pm/hydra/tools/topo/hwloc/hwloc checking if want hwloc maintainer support... disabled (embedded mode) checking for hwloc directory prefix... tools/topo/hwloc/hwloc/ checking for hwloc symbol prefix... hwloc_ checking size of void *... 0 checking which OS support to include... Linux checking which CPU support to include... unknown -- assuming x86_64 checking size of unsigned long... (cached) 8 checking size of unsigned int... 0 checking for the C compiler vendor... gnu configure line: ./configure --prefix=/home/bramesh/apps/mpich2 --enable-shared --with-pbs=/opt/torque/torque The error I am noticing for mvapich2 is as follows: ### ### Configuring hwloc core ### checking hwloc building mode... embedded configure: hwloc builddir: /home/bramesh/ARC/apps/build/mvapich2-1.9a2/src/pm/hydra/tools/topo/hwloc/hwloc configure: hwloc srcdir: /home/bramesh/ARC/apps/build/mvapich2-1.9a2/src/pm/hydra/tools/topo/hwloc/hwloc checking if want hwloc maintainer support... disabled (embedded mode) checking for hwloc directory prefix... tools/topo/hwloc/hwloc/ checking for hwloc symbol prefix... hwloc_ checking size of void *... 0 checking which OS support to include... Linux checking which CPU support to include... unknown -- assuming x86_64 checking size of unsigned long... (cached) 8 checking size of unsigned int... 0 checking for the C compiler vendor... gnu configure line: ./configure --prefix=$HOME/apps/mvapich2 --enable-shared --with-ib-include=/opt/ofed/ofed/include --with-ib-libpath=/opt/ofed/ofed/lib64 --with-pbs=/opt/torque/torque If I built hwloc-1.5 or hwloc-1.6 separately in embedded mode I dont see the error. I was wondering what is the way to fix this issue so that I can build mvapich2 to use in our IB cluster. I am not subscribed to the list so would appreciate it if I am copied on the replies. [1] http://mail.cse.ohio-state.edu/pipermail/mvapich-discuss/2013-January/00420… -- Bharath

1 0

Weird thing -- MPICH2 on domain
by Qiguo Jing 25 Jan '13

25 Jan '13

All, I have been encountering a weird thing, which draw me crazy. I hope someone here can help me. I have two computers, a laptop (Windows 7 64 bit) and a desktop (Window 7 32 bit). Both are in company domain, and I use the some information to login. So the MPICH2 registration information are the same for both computers. I developed a parallel FORTRAN program using my laptop. 1. If I connect the internet cable on laptop. --> Program works. Results are good. 2. If I disconnect the internet cable on laptop. --> Program fails, saying Program Exception - access violation 3. If I connect the internet cable on Desktop. --> Program runs and finishes, but the results are wrong. Slave processors and master processor do not communicate, so that results on slave processor can not be passed to main processor. 4. If I disconnect the internet cable on Desktop. -> Program works. Results are good. Can someone help? 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 Jed Brown 24 Jan '13

24 Jan '13

Dave, thanks for taking care of this. I've put the configure tests (detect ch3:sock using MPIDI_CH3I_sock_set and the fix with MPIDI_CH3I_sock_fixed_nbc_progress) into PETSc and all is well using the Issend/Ibarrier algorithm by default for all bug-free configurations. On Wed, Jan 23, 2013 at 3:52 PM, Dave Goodell <goodell(a)mcs.anl.gov> wrote: > 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 > > > > _______________________________________________ > 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 Nicolas Rosner 24 Jan '13

24 Jan '13

Thanks for the prompt response. Nicolás On Thu, Jan 24, 2013 at 5:59 PM, Dave Goodell <goodell(a)mcs.anl.gov> wrote: > 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 > > _______________________________________________ > 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] mpich-3.0.1 LLONG_MAX undeclared in status_set_elements_x.c
by Dave Goodell 24 Jan '13

24 Jan '13

This has been fixed in git but we have not yet cut a release for it: http://trac.mpich.org/projects/mpich/ticket/1776 http://git.mpich.org/mpich.git/commitdiff/465ca32 We will likely cut a 3.0.2 release soon, after a few other pending bugs have been fixed as well. -Dave On Jan 24, 2013, at 4:56 PM CST, Bodony, Daniel J wrote: > 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 > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

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