December 2012 - discuss - mailman3.cels.anl.gov

mpich2-1.5 build error
by Ling Wang 17 Dec '12

17 Dec '12

I am getting this error on my Ubuntu 12.10. (on both of my machines with an AMD and Intel CPUs) mpich2-1.5/src/binding/f90/create_f90_real.c:73:23: error: expected expression before ',' token attached please find c.txt and m.txt files. Please help. Thanks, Ling

1 0

Re: [mpich-discuss] mpich2 make check problems
by Dave Goodell 17 Dec '12

17 Dec '12

Try running "make testing" instead of "make check". -Dave On Dec 17, 2012, at 9:49 PM CST, stephen wrote: > Hi, > > I'm using Ubuntu 12.04 compiling mpich2-1.5. > > During the configure and make steps , there were without any problems ,all > seemed fine . > > However during the make check step, I encountered some errors that I > didn't know why. > > Can you tell me what's wrong with it, and how to solve it? > > The c.txt & m.txt & mc.txt are attached below. > > thx. > > > Stephen > > <c.txt><m.txt><mc.txt>_______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

mpich2 make check problems
by stephen 17 Dec '12

17 Dec '12

Hi, I'm using Ubuntu 12.04 compiling mpich2-1.5. During the configure and make steps , there were without any problems ,all seemed fine . However during the make check step, I encountered some errors that I didn't know why. Can you tell me what's wrong with it, and how to solve it? The c.txt & m.txt & mc.txt are attached below. thx. Stephen

1 0

Re: [mpich-discuss] Questions regarding installation of 32/64bit MPICH2 on 64bit machines (os: win7)
by Jayesh Krishna 17 Dec '12

17 Dec '12

Hi, Good to know MPICH2 is working for you. Regards, Jayesh ----- Original Message ----- From: "Seokho Son" <shsongist(a)gmail.com> To: "Jayesh Krishna" <jayesh(a)mcs.anl.gov> Sent: Monday, December 17, 2012 12:46:16 PM Subject: Re: [mpich-discuss] Questions regarding installation of 32/64bit MPICH2 on 64bit machines (os: win7) Thank you for your prompt reply. We'v installed MPICH2 from an admin command prompt according to the instructions. The reported results in the previous email are based on the instructions. Your response for our inquiries is very informative to us. According to your advice, we'v determined to utilize 64bit-MPICH2 and ignore the error message. Currently, we can execute a 64bit parallel application on two machines with 64bit-MPICH2. Thank you very much. Best regards, Seokho Son. 2012/12/18 Jayesh Krishna < jayesh(a)mcs.anl.gov > Hi, Please make sure that you install MPICH2 on Win7 from an admin command prompt (Please follow instructions in Section 9.4, not 9.1, of the MPICH2 installers guide - http://www.mpich.org/documentation/guides/ - to install MPICH2 on Win7). Uninstall any previous versions of MPICH2 before installing a new one. Ignore the error message from wmpiconfig for 64-bit installations. This is a bug and we haven't had the developer bandwidth to fix this issue. Try running an MPI program with multiple processes to make sure MPICH2 works for you. You can install MPICH2 32-bit on a 64-bit system (However we don't test this configuration often). There shouldn't be any major performance concerns, however if you want to send huge amount of data (in your MPI program) the 64-bit version will make it easier for you. Regards, Jayesh ----- Original Message ----- From: "Seokho Son" < shsongist(a)gmail.com > To: mpich-discuss(a)mcs.anl.gov Sent: Sunday, December 16, 2012 2:00:33 PM Subject: [mpich-discuss] Questions regarding installation of 32/64bit MPICH2 on 64bit machines (os: win7) Hello, we are trying to establish a parallel programming environment using mpich2. [Specification of our environment] OS: Windows 7 (64bit) Two workstations: Intel CPU (64bit) Programming environment: Visual studio 2008 (64bit) We have two questions regarding mpich2 installation. We have tried 64bit mpich2 (version 1.4.1p1, 1.3.2, 1.3, 1.2), but all of them give an error message ("MPICH2 not installed or unable to query the host") in the wmpiconfig program. Also, when we click scan hosts in the wmpiconfig program, the items in the list of hosts are in gray which means error occurred. However, we could successfully execute a parallel program with 64bit mpich2 (version 1.3.2) on the 64bit machine even though this version still shows the error message Q1) So, we hope to know that we may simply ignore the error message. On the other hands, we experienced that most of 32bit mpich2 versions (version 1.4.1p1, 1.3, 1.2) work in our environment without any error message. Q2) Is it fine to use 32bit mpich2 on a 64bit machine? We hope to know if there is any disadvantage on this such as performance degradation. Thank you. Best regards, Seokho Son. _______________________________________________ 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] Questions regarding installation of 32/64bit MPICH2 on 64bit machines (os: win7)
by Jayesh Krishna 17 Dec '12

17 Dec '12

Hi, Please make sure that you install MPICH2 on Win7 from an admin command prompt (Please follow instructions in Section 9.4, not 9.1, of the MPICH2 installers guide - http://www.mpich.org/documentation/guides/ - to install MPICH2 on Win7). Uninstall any previous versions of MPICH2 before installing a new one. Ignore the error message from wmpiconfig for 64-bit installations. This is a bug and we haven't had the developer bandwidth to fix this issue. Try running an MPI program with multiple processes to make sure MPICH2 works for you. You can install MPICH2 32-bit on a 64-bit system (However we don't test this configuration often). There shouldn't be any major performance concerns, however if you want to send huge amount of data (in your MPI program) the 64-bit version will make it easier for you. Regards, Jayesh ----- Original Message ----- From: "Seokho Son" <shsongist(a)gmail.com> To: mpich-discuss(a)mcs.anl.gov Sent: Sunday, December 16, 2012 2:00:33 PM Subject: [mpich-discuss] Questions regarding installation of 32/64bit MPICH2 on 64bit machines (os: win7) Hello, we are trying to establish a parallel programming environment using mpich2. [Specification of our environment] OS: Windows 7 (64bit) Two workstations: Intel CPU (64bit) Programming environment: Visual studio 2008 (64bit) We have two questions regarding mpich2 installation. We have tried 64bit mpich2 (version 1.4.1p1, 1.3.2, 1.3, 1.2), but all of them give an error message ("MPICH2 not installed or unable to query the host") in the wmpiconfig program. Also, when we click scan hosts in the wmpiconfig program, the items in the list of hosts are in gray which means error occurred. However, we could successfully execute a parallel program with 64bit mpich2 (version 1.3.2) on the 64bit machine even though this version still shows the error message Q1) So, we hope to know that we may simply ignore the error message. On the other hands, we experienced that most of 32bit mpich2 versions (version 1.4.1p1, 1.3, 1.2) work in our environment without any error message. Q2) Is it fine to use 32bit mpich2 on a 64bit machine? We hope to know if there is any disadvantage on this such as performance degradation. Thank you. Best regards, Seokho Son. _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Questions regarding installation of 32/64bit MPICH2 on 64bit machines (os: win7)
by Seokho Son 16 Dec '12

16 Dec '12

Hello, we are trying to establish a parallel programming environment using mpich2. [Specification of our environment] OS: Windows 7 (64bit) Two workstations: Intel CPU (64bit) Programming environment: Visual studio 2008 (64bit) We have two questions regarding mpich2 installation. We have tried 64bit mpich2 (version 1.4.1p1, 1.3.2, 1.3, 1.2), but all of them give an error message ("MPICH2 not installed or unable to query the host") in the wmpiconfig program. Also, when we click scan hosts in the wmpiconfig program, the items in the list of hosts are in gray which means error occurred. However, we could successfully execute a parallel program with 64bit mpich2 (version 1.3.2) on the 64bit machine even though this version still shows the error message Q1) So, we hope to know that we may simply ignore the error message. On the other hands, we experienced that most of 32bit mpich2 versions (version 1.4.1p1, 1.3, 1.2) work in our environment without any error message. Q2) Is it fine to use 32bit mpich2 on a 64bit machine? We hope to know if there is any disadvantage on this such as performance degradation. Thank you. Best regards, Seokho Son.

1 0

Re: [mpich-discuss] There is any change between mpich1 and mpich2 which make this error?
by Jim Dinan 14 Dec '12

14 Dec '12

Hi, It looks like one of your processes seg. faulted and exited with SIGSEGV (signal 11). You should be able to look at the core file or attach a debugger to get a backtrace and locate the origin of the error. Without more information, it's hard to give much help. MPICH2 1.4.1 is also a slightly older version, you could try upgrading to the latest version of MPICH and see if the seg fault goes away. I don't know of any change from MPICH1 to MPICH2 that would have resulted in a correct MPI-1 program seg faulting. ~Jim. On 12/14/12 6:51 AM, 유경완 wrote: > Hi there > > I upgraded my server computer and I also upgraded mpich program from > mpich1(1.2.7p1) to mpich2(1.4.1). > > And then there were some problems… > > The problem was > > There is no error when I run mpich2(mpiexec) with output file which > compiled at mpich1. > > But there is an error when I run mpich2(mpiexec) with output file which > compiled at mpich2 (there was no error when I compiled at mpich2). > > (All compiling which mentioned above use same code) > > The error message was > > ===================================================================================== > > = BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES > > = EXIT CODE: 11 > > = CLEANING UP REMAINING PROCESSES > > = YOU CAN IGNORE THE BELOW CLEANUP MESSAGES > > ===================================================================================== > > [proxy:0:1@n002] HYD_pmcd_pmip_control_cmd_cb > (/home/octofous2/libraries/mpich2-1.4.1p1/src/pm/hydra/pm/pmiserv/pmip_cb.c:928): > assert (!closed) failed > > [proxy:0:1@n002] HYDT_dmxu_poll_wait_for_event > (/home/octofous2/libraries/mpich2-1.4.1p1/src/pm/hydra/tools/demux/demux_poll.c:77): > callback returned error status > > [proxy:0:1@n002] main > (/home/octofous2/libraries/mpich2-1.4.1p1/src/pm/hydra/pm/pmiserv/pmip.c:276): > demux engine error waiting for event > > [mpiexec(a)octofous2.psl] HYDT_bscu_wait_for_completion > (/home/octofous2/libraries/mpich2-1.4.1p1/src/pm/hydra/tools/bootstrap/utils/bscu_wait.c:70): > one of the processes terminated badly; aborting > > [mpiexec(a)octofous2.psl] HYDT_bsci_wait_for_completion > (/home/octofous2/libraries/mpich2-1.4.1p1/src/pm/hydra/tools/bootstrap/src/bsci_wait.c:23): > launcher returned error waiting for completion > > [mpiexec(a)octofous2.psl] HYD_pmci_wait_for_completion > (/home/octofous2/libraries/mpich2-1.4.1p1/src/pm/hydra/pm/pmiserv/pmiserv_pmci.c:191): > launcher returned error waiting for completion > > [mpiexec(a)octofous2.psl] main > (/home/octofous2/libraries/mpich2-1.4.1p1/src/pm/hydra/ui/mpich/mpiexec.c:405): > process manager error waiting for completion > > 8 cpus > > So.. my quastion was that is there any language change between > mpich1(1.2.7p1) and mpich2(1.4.1) which makes problem like this? > > Or there is any clue to make this problem..? > > Thanks for read > > Best regards > > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss >

1 0

There is any change between mpich1 and mpich2 which make this error?
by 유경완 14 Dec '12

14 Dec '12

Hi there I upgraded my server computer and I also upgraded mpich program from mpich1(1.2.7p1) to mpich2(1.4.1). And then there were some problems… The problem was There is no error when I run mpich2(mpiexec) with output file which compiled at mpich1. But there is an error when I run mpich2(mpiexec) with output file which compiled at mpich2 (there was no error when I compiled at mpich2). (All compiling which mentioned above use same code) The error message was ============================================================================ ========= = BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES = EXIT CODE: 11 = CLEANING UP REMAINING PROCESSES = YOU CAN IGNORE THE BELOW CLEANUP MESSAGES ============================================================================ ========= [proxy:0:1@n002] HYD_pmcd_pmip_control_cmd_cb (/home/octofous2/libraries/mpich2- 1.4.1p1/src/pm/hydra/pm/pmiserv/pmip_cb.c:928): assert (!closed) failed [proxy:0:1@n002] HYDT_dmxu_poll_wait_for_event (/home/octofous2/libraries/mpich2- 1.4.1p1/src/pm/hydra/tools/demux/demux_poll.c:77): callback returned error status [proxy:0:1@n002] main (/home/octofous2/libraries/mpich2- 1.4.1p1/src/pm/hydra/pm/pmiserv/pmip.c:276): demux engine error waiting for event [mpiexec(a)octofous2.psl] HYDT_bscu_wait_for_completion (/home/octofous2/libraries/mpich2- 1.4.1p1/src/pm/hydra/tools/bootstrap/utils/bscu_wait.c:70): one of the processes terminated badly; aborting [mpiexec(a)octofous2.psl] HYDT_bsci_wait_for_completion (/home/octofous2/libraries/mpich2- 1.4.1p1/src/pm/hydra/tools/bootstrap/src/bsci_wait.c:23): launcher returned error waiting for completion [mpiexec(a)octofous2.psl] HYD_pmci_wait_for_completion (/home/octofous2/libraries/mpich2- 1.4.1p1/src/pm/hydra/pm/pmiserv/pmiserv_pmci.c:191): launcher returned error waiting for completion [mpiexec(a)octofous2.psl] main (/home/octofous2/libraries/mpich2- 1.4.1p1/src/pm/hydra/ui/mpich/mpiexec.c:405): process manager error waiting for completion 8 cpus So.. my quastion was that is there any language change between mpich1(1.2.7p1) and mpich2(1.4.1) which makes problem like this? Or there is any clue to make this problem..? Thanks for read Best regards

1 0

Re: [mpich-discuss] too many communicators
by Jim Dinan 13 Dec '12

13 Dec '12

How many communicators are created by the loops containing these statements? Could it be more than the limit? > psymbfact.c: MPI_Comm_dup ((*symb_comm), &(commLvls[i])); > psymbfact.c: MPI_Comm_split ((*symb_comm), col, key, &(commLvls[ind]) ); ~Jim. On 12/13/12 12:19 PM, Jeff Hammond wrote: > It's far from conclusive, but I went through the SuperLU_dist source > and it seems there is proper symmetry between communicator creation > and destruction. > > $ for f in create dup split free ; do grep MPI_Comm_$f *.c ; done > superlu_grid.c: MPI_Comm_create( Bcomm, superlu_grp, &grid->comm ); > psymbfact.c: MPI_Comm_dup ((*symb_comm), &(commLvls[i])); > pdgssvx.c: MPI_Comm_split (grid->comm, col, key, &symb_comm ); > psymbfact.c: MPI_Comm_split ((*symb_comm), col, key, &(commLvls[ind]) ); > pzgssvx.c: MPI_Comm_split (grid->comm, col, key, &symb_comm ); > superlu_grid.c: MPI_Comm_split(grid->comm, myrow, mycol, &(grid->rscp.comm)); > superlu_grid.c: MPI_Comm_split(grid->comm, mycol, myrow, &(grid->cscp.comm)); > pdgssvx.c: MPI_Comm_free (&symb_comm); > psymbfact.c: MPI_Comm_free (&(commLvls[i])); > psymbfact.c: MPI_Comm_free ( &(commLvls[ind]) ); > pzgssvx.c: MPI_Comm_free (&symb_comm); > superlu_grid.c: MPI_Comm_free( &grid->rscp.comm ); > superlu_grid.c: MPI_Comm_free( &grid->cscp.comm ); > superlu_grid.c: MPI_Comm_free( &grid->comm ); > > Jeff > > On Thu, Dec 13, 2012 at 9:40 AM, Jim Dinan <dinan(a)mcs.anl.gov> wrote: >> Hi Jack, >> >> It sounds like your application, or maybe the solver, is leaking >> communicators somewhere. If you configure with --enable-g=handlealloc (or >> --enable-g=all), MPICH will issue warnings about leaked MPI objects when >> your program exits. >> >> ~Jim. >> >> >> On 12/12/12 6:47 PM, Dave Goodell wrote: >>> >>> On Dec 13, 2012, at 5:23 AM GMT+09:00, Jack Lee wrote: >>> >>>> What I'd like to determine first is whether fault is on my side (e.g. >>>> perhaps I'm not calling the clean-up routines properly). Is there a way to >>>> find out how many context id's are in use at a given point? >>> >>> >>> If your MPICH was configured with "--enable-g=log" (or a superset thereof, >>> such as "=all"), then you can add the following prototype into your >>> application and invoke this function to get a string showing the current >>> bit-vector state on a given process: >>> >>> ----8<---- >>> static char *MPIR_ContextMaskToStr(void); >>> ----8<---- >>> >>> see src/mpi/comm/commutil.c for more insight into how this works and what >>> it's actually telling you. This wiki node also has some useful (and only >>> slightly stale) information: >>> >>> http://wiki.mpich.org/mpich/index.php/Communicators_and_Context_IDs >>> >>> I wish I had a better option for you, but without just rolling up your >>> sleeves and hacking on the MPICH code, this is about as good as you're >>> likely to get. >>> >>> The next best approach would probably be to trap all the communicator >>> creation/destruction calls that you can think of (see the MPI-2.2 standard, >>> chapter 6) via the PMPI_ profiling interface and log the invocations to look >>> for a mismatch. >>> >>> -Dave >>> >>> _______________________________________________ >>> 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] too many communicators
by Jeff Hammond 13 Dec '12

13 Dec '12

It's far from conclusive, but I went through the SuperLU_dist source and it seems there is proper symmetry between communicator creation and destruction. $ for f in create dup split free ; do grep MPI_Comm_$f *.c ; done superlu_grid.c: MPI_Comm_create( Bcomm, superlu_grp, &grid->comm ); psymbfact.c: MPI_Comm_dup ((*symb_comm), &(commLvls[i])); pdgssvx.c: MPI_Comm_split (grid->comm, col, key, &symb_comm ); psymbfact.c: MPI_Comm_split ((*symb_comm), col, key, &(commLvls[ind]) ); pzgssvx.c: MPI_Comm_split (grid->comm, col, key, &symb_comm ); superlu_grid.c: MPI_Comm_split(grid->comm, myrow, mycol, &(grid->rscp.comm)); superlu_grid.c: MPI_Comm_split(grid->comm, mycol, myrow, &(grid->cscp.comm)); pdgssvx.c: MPI_Comm_free (&symb_comm); psymbfact.c: MPI_Comm_free (&(commLvls[i])); psymbfact.c: MPI_Comm_free ( &(commLvls[ind]) ); pzgssvx.c: MPI_Comm_free (&symb_comm); superlu_grid.c: MPI_Comm_free( &grid->rscp.comm ); superlu_grid.c: MPI_Comm_free( &grid->cscp.comm ); superlu_grid.c: MPI_Comm_free( &grid->comm ); Jeff On Thu, Dec 13, 2012 at 9:40 AM, Jim Dinan <dinan(a)mcs.anl.gov> wrote: > Hi Jack, > > It sounds like your application, or maybe the solver, is leaking > communicators somewhere. If you configure with --enable-g=handlealloc (or > --enable-g=all), MPICH will issue warnings about leaked MPI objects when > your program exits. > > ~Jim. > > > On 12/12/12 6:47 PM, Dave Goodell wrote: >> >> On Dec 13, 2012, at 5:23 AM GMT+09:00, Jack Lee wrote: >> >>> What I'd like to determine first is whether fault is on my side (e.g. >>> perhaps I'm not calling the clean-up routines properly). Is there a way to >>> find out how many context id's are in use at a given point? >> >> >> If your MPICH was configured with "--enable-g=log" (or a superset thereof, >> such as "=all"), then you can add the following prototype into your >> application and invoke this function to get a string showing the current >> bit-vector state on a given process: >> >> ----8<---- >> static char *MPIR_ContextMaskToStr(void); >> ----8<---- >> >> see src/mpi/comm/commutil.c for more insight into how this works and what >> it's actually telling you. This wiki node also has some useful (and only >> slightly stale) information: >> >> http://wiki.mpich.org/mpich/index.php/Communicators_and_Context_IDs >> >> I wish I had a better option for you, but without just rolling up your >> sleeves and hacking on the MPICH code, this is about as good as you're >> likely to get. >> >> The next best approach would probably be to trap all the communicator >> creation/destruction calls that you can think of (see the MPI-2.2 standard, >> chapter 6) via the PMPI_ profiling interface and log the invocations to look >> for a mismatch. >> >> -Dave >> >> _______________________________________________ >> 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 -- 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