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

Re: [mpich-discuss] cpu binding with 1.5 hydra
by Pavan Balaji 23 Dec '12

23 Dec '12

Rohit, Can you try the latest mpich version (3.0.1)? There are some fixes in there that might be related to this. -- Pavan On 11/06/2012 04:34 PM US Central Time, Jain, Rohit wrote: > Thanks John. That does give me list of available binding option. > > > > It seems all binding options donï¿½t work fine. > > > > All l1/l2/l3cache errors out: > > mpiexec -bind-to l3cache -n 1 mytest 200000 -1 : -n 4 mytest 200000 -1 > > [proxy:0:0@gretel] cache_to_cpu_type > (/u/prod/mpich/src/mpich2-1.5/src/pm/hydra/tools/topo/hwloc/topo_hwloc.c:258): > cache level 3 not found > > [proxy:0:0@gretel] obj_type_to_map_str > (/u/prod/mpich/src/mpich2-1.5/src/pm/hydra/tools/topo/hwloc/topo_hwloc.c:313): > error while mapping cache to cpu object > > [mpiexec@gretel] control_cb > (/u/prod/mpich/src/mpich2-1.5/src/pm/hydra/pm/pmiserv/pmiserv_cb.c:201): > assert (!closed) failed > > [mpiexec@gretel] HYDT_dmxu_poll_wait_for_event > (/u/prod/mpich/src/mpich2-1.5/src/pm/hydra/tools/demux/demux_poll.c:77): > callback returned error status > > [mpiexec@gretel] HYD_pmci_wait_for_completion > (/u/prod/mpich/src/mpich2-1.5/src/pm/hydra/pm/pmiserv/pmiserv_pmci.c:196): > error waiting for event > > [mpiexec@gretel] main > (/u/prod/mpich/src/mpich2-1.5/src/pm/hydra/ui/mpich/mpiexec.c:325): > process manager error waiting for completion > > > > > > This hangs and doesnï¿½t even exit after ï¿½ctrl-cï¿½: > > mpiexec -bind-to numa -n 1 mytest 200000 -1 : -n 4 mytest 200000 -1 > > [mpiexec@gretel] Sending Ctrl-C to processes as requested > > [mpiexec@gretel] Press Ctrl-C again to force abort > > Ctrl-C caught... cleaning up processes > > Ctrl-C caught... cleaning up processes > > Ctrl-C caught... cleaning up processes > > Ctrl-C caught... cleaning up processes > > > > Here is machine detail I am running it on: > > Processor name : Intel(R) Xeon(R) CPU X5550 @ > 2.67GHz > > Speed (MHz) : 2660.125 > > Cache size per processor : 8192 KB > > Number of processors : 2 > > Number of cores per processor : 4 > > > > Regards, > > Rohit > > > > *From:*[email protected] > [mailto:[email protected]] *On Behalf Of *John Fettig > *Sent:* Monday, November 05, 2012 6:05 PM > *To:* mpich-discuss > *Subject:* Re: [mpich-discuss] cpu binding with 1.5 hydra > > > > Rohit, > > Did you try > > $ mpirun -bind-to -help > > This dumps all of the options for -bind-to. > > John > > > > On Mon, Nov 5, 2012 at 2:13 PM, Jain, Rohit <Rohit_Jain(a)mentor.com > <mailto:[email protected]>> wrote: > > Hi Pavan, > > Could you please respond to it? > > Regards, > Rohit > > -----Original Message----- > From: mpich-discuss-bounces(a)mcs.anl.gov > <mailto:[email protected]> > [mailto:[email protected] > <mailto:[email protected]>] On Behalf Of Jain, Rohit > Sent: Tuesday, October 30, 2012 4:02 PM > To: Pavan Balaji; mpich-discuss(a)mcs.anl.gov > <mailto:[email protected]> > Subject: Re: [mpich-discuss] cpu binding with 1.5 hydra > > Hi Pavan, > > Where do I find exact names of new binding options arguments? > > Like 'sockets' doesn't work, but 'socket' do. This page is not updated > with correct options: > http://wiki.mcs.anl.gov/mpich2/index.php/Using_the_Hydra_Process_Manager#Pr… > > Regards, > Rohit > > > -----Original Message----- > From: Pavan Balaji [mailto:[email protected] <mailto:[email protected]>] > Sent: Tuesday, October 30, 2012 8:36 AM > To: mpich-discuss(a)mcs.anl.gov <mailto:[email protected]> > Cc: Jain, Rohit > Subject: Re: [mpich-discuss] cpu binding with 1.5 hydra > > > On 10/29/2012 07:13 PM, Jain, Rohit wrote: >> Do you mean '-binding' option is also being deprecated? Is it replaced > with '-bind-to'? > > It's being replaced with the -bind-to option. We might support -binding > as an alias to -bind-to for quite some time, but we'd suggest users move > to the new richer -bind-to interface. > > -- Pvaan > > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji > _______________________________________________ > mpich-discuss mailing list mpich-discuss(a)mcs.anl.gov > <mailto:[email protected]> > To manage subscription options or unsubscribe: > https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss > _______________________________________________ > mpich-discuss mailing list mpich-discuss(a)mcs.anl.gov > <mailto:[email protected]> > To manage subscription options or unsubscribe: > https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss > > > > > > _______________________________________________ > mpich-discuss mailing list mpich-discuss(a)mcs.anl.gov > To manage subscription options or unsubscribe: > https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-discuss] Remote hydra_pmi_proxy
by Pavan Balaji 23 Dec '12

23 Dec '12

Not for the proxy. Such functionality to specify a different directory is only available for the MPI application executables. Sorry. -- Pavan On 10/31/2012 11:59 AM US Central Time, Azamat Mametjanov wrote: > Is it possible to specify a different path to hydra_pmi_proxy on the > remote node? My mpich paths on the local and remote nodes are not the > same and I hope there is something like '--prefix > <path_to_remote_mpich_install>. Thanks. > > > _______________________________________________ > mpich-discuss mailing list mpich-discuss(a)mcs.anl.gov > To manage subscription options or unsubscribe: > https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-discuss] Trouble importing mpich2 library
by Pavan Balaji 23 Dec '12

23 Dec '12

This looks like a problem with Maple Grid Computing. Please contact them for instructions. -- Pavan On 10/05/2012 03:23 PM US Central Time, ï¿½tila Gracco wrote: > Greetings, > > I'm trying to install a program, Maple Grid Computing 16 , that requires > that i install the mpich2 library, after i do that and go to the program > instalation screen, at some point during instalation it asks me to put > the Name of MPI shared lib, and the root location of it, i'm using > Ubuntu 12.04 - 64 bits. I almost forgot to say, i'm kind of newbie in linux. > > -- > Att, > *ï¿½tila Gracco* > Acadï¿½mico do 8ï¿½ perï¿½odo | Engenharia de Computaï¿½ï¿½o UFG > +55 (62) 8126-1016 > Skype: atilagracco > > > _______________________________________________ > mpich-discuss mailing list mpich-discuss(a)mcs.anl.gov > To manage subscription options or unsubscribe: > https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-discuss] Problems with mpirun: cannot find executable
by Pavan Balaji 23 Dec '12

23 Dec '12

Are you sure you are using mpich? The below error message about "mpirun" is not from mpich. -- Pavan On 09/21/2012 03:30 PM US Central Time, Elie M wrote: > Dear All, I have a problem. I am doing parallel computing using the QE > package and while executing an executable ph.x , i get the error: > > "mpirun was unable to launch the specified application as it could not > access > or execute an executable: > > Executable: /home/emoujaes/Elie-Packages/espresso-5.0.1-GPU/bin/ph.x > Node: compute-0-9.local > > while attempting to start process rank 0. > -------------------------------------------------------------------------- > /var/spool/torque/mom_priv/jobs/5002.jlborges.fisica.ufmg.br.SC: line > 91: [General]: command not found > /var/spool/torque/mom_priv/jobs/5002.jlborges.fisica.ufmg.br.SC: line > 92: Backup.zip: command not found > /var/spool/torque/mom_priv/jobs/5002.jlborges.fisica.ufmg.br.SC: line > 130: [CD]: command not found > /var/spool/torque/mom_priv/jobs/5002.jlborges.fisica.ufmg.br.SC: line > 132: [Ftp]: command not found > /var/spool/torque/mom_priv/jobs/5002.jlborges.fisica.ufmg.br.SC: line > 136: [eMail]: command not found > find: logs: No such file or directory > find: of: No such file or directory > find: the: No such file or directory.." > > What might be the problem.... I am not sure if this might be causing it > or not as I am not an expert in programming. The executable ph.x is > found in a Package PHONONS which was a separate one from the Quantum > espresso Pacakge. I unzipped it and compiled the executables which were > put in the bin folder where all other executables are but they were > shaded with different colours...I am not sure if this is causing the > problem or not. Please help. > > Regards > > EElie Moukaes\ > University of Notts > NG7 2RD > UK > > > _______________________________________________ > mpich-discuss mailing list mpich-discuss(a)mcs.anl.gov > To manage subscription options or unsubscribe: > https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-discuss] Error while checkpointing an MPI application
by Pavan Balaji 23 Dec '12

23 Dec '12

It looks like your blcr installation is not functioning correctly. Did you try it outside of the mpich environment to make sure it's installed correctly? -- Pavan On 09/21/2012 05:03 AM US Central Time, Manisha Chauhan wrote: > Hi all > > I mailed you earlier also but didnot get reply for my query. Hoping to > get this time. I installed BLCR tool with MPICH2 and HYDRA module. > > While checkpointing an MPI application i have given this command- > > mpirun -ckpointlib blcr -ckpoint-prefix > /home/superusr/bhavya/b_eff_io/tmp/app.ckpoint -ckpoint-interval 10 -np > 4 ./beff_out1 -MB 2730 -MT 32768 -T 20 -p ../test -f > ../test_out/ser11_9_2012_20sec3 > > [proxy:0:[email protected]] requesting checkpoint > [proxy:0:[email protected]] checkpoint completed > [proxy:0:[email protected]] HYDT_ckpoint_blcr_checkpoint > (./tools/ckpoint/blcr/ckpoint_blcr.c:244): cr_request_checkpoint failed, > Unknown error 2356 > [proxy:0:[email protected]] ckpoint_thread > (./tools/ckpoint/ckpoint.c:72): blcr checkpoint returned error > [proxy:0:[email protected]] requesting checkpoint > [proxy:0:[email protected]] checkpoint completed > [proxy:0:[email protected]] HYDT_ckpoint_blcr_checkpoint > (./tools/ckpoint/blcr/ckpoint_blcr.c:244): cr_request_checkpoint failed, > Unknown error 2356 > [proxy:0:[email protected]] ckpoint_thread > (./tools/ckpoint/ckpoint.c:72): blcr checkpoint returned error > [proxy:0:[email protected]] requesting checkpoint > [proxy:0:[email protected]] checkpoint completed > [proxy:0:[email protected]] HYDT_ckpoint_blcr_checkpoint > (./tools/ckpoint/blcr/ckpoint_blcr.c:244): cr_request_checkpoint failed, > Unknown error 2356 > [proxy:0:[email protected]] ckpoint_thread > (./tools/ckpoint/ckpoint.c:72): blcr checkpoint returned error > [proxy:0:[email protected]] requesting checkpoint > [proxy:0:[email protected]] checkpoint completed > [proxy:0:[email protected]] HYDT_ckpoint_blcr_checkpoint > (./tools/ckpoint/blcr/ckpoint_blcr.c:244): cr_request_checkpoint failed, > Unknown error 2356 > [proxy:0:[email protected]] ckpoint_thread > (./tools/ckpoint/ckpoint.c:72): blcr checkpoint returned error > [proxy:0:[email protected]] requesting checkpoint > [proxy:0:[email protected]] checkpoint completed > [proxy:0:[email protected]] HYDT_ckpoint_blcr_checkpoint > (./tools/ckpoint/blcr/ckpoint_blcr.c:244): cr_request_checkpoint failed, > Unknown error 2356 > [proxy:0:[email protected]] ckpoint_thread > (./tools/ckpoint/ckpoint.c:72): blcr checkpoint returned error > [proxy:0:[email protected]] requesting checkpoint > [proxy:0:[email protected]] checkpoint completed > [proxy:0:[email protected]] HYDT_ckpoint_blcr_checkpoint > (./tools/ckpoint/blcr/ckpoint_blcr.c:244): cr_request_checkpoint failed, > Unknown error 2356 > [proxy:0:[email protected]] ckpoint_thread > (./tools/ckpoint/ckpoint.c:72): blcr checkpoint returned error > [proxy:0:[email protected]] requesting checkpoint > [proxy:0:[email protected]] checkpoint completed > [proxy:0:[email protected]] HYDT_ckpoint_blcr_checkpoint > (./tools/ckpoint/blcr/ckpoint_blcr.c:244): cr_request_checkpoint failed, > Unknown error 2356 > [proxy:0:[email protected]] ckpoint_thread > (./tools/ckpoint/ckpoint.c:72): blcr checkpoint returned error > [proxy:0:[email protected]] requesting checkpoint > [proxy:0:[email protected]] checkpoint completed > [proxy:0:[email protected]] HYDT_ckpoint_blcr_checkpoint > (./tools/ckpoint/blcr/ckpoint_blcr.c:244): cr_request_checkpoint failed, > Unknown error 2356 > [proxy:0:[email protected]] ckpoint_thread > (./tools/ckpoint/ckpoint.c:72): blcr checkpoint returned error > [proxy:0:[email protected]] requesting checkpoint > [proxy:0:[email protected]] checkpoint completed > [proxy:0:[email protected]] HYDT_ckpoint_blcr_checkpoint > (./tools/ckpoint/blcr/ckpoint_blcr.c:244): cr_request_checkpoint failed, > Unknown error 2356 > [proxy:0:[email protected]] ckpoint_thread > (./tools/ckpoint/ckpoint.c:72): blcr checkpoint returned error > [proxy:0:[email protected]] requesting checkpoint > [proxy:0:[email protected]] checkpoint completed > [proxy:0:[email protected]] HYDT_ckpoint_blcr_checkpoint > (./tools/ckpoint/blcr/ckpoint_blcr.c:244): cr_request_checkpoint failed, > Unknown error 2356 > [proxy:0:[email protected]] ckpoint_thread > (./tools/ckpoint/ckpoint.c:72): blcr checkpoint returned error > [proxy:0:[email protected]] requesting checkpoint > [proxy:0:[email protected]] checkpoint completed > [proxy:0:[email protected]] HYDT_ckpoint_blcr_checkpoint > (./tools/ckpoint/blcr/ckpoint_blcr.c:244): cr_request_checkpoint failed, > Unknown error 2356 > [proxy:0:[email protected]] ckpoint_thread > (./tools/ckpoint/ckpoint.c:72): blcr checkpoint returned error > [proxy:0:[email protected]] requesting checkpoint > [proxy:0:[email protected]] checkpoint completed > [proxy:0:[email protected]] HYDT_ckpoint_blcr_checkpoint > (./tools/ckpoint/blcr/ckpoint_blcr.c:244): cr_request_checkpoint failed, > Unknown error 2356 > [proxy:0:[email protected]] ckpoint_thread > (./tools/ckpoint/ckpoint.c:72): blcr checkpoint returned error > > b_eff_io = 611.691 MB/s on 4 processes with 2730 MByte/PE, scheduled > time=0.1 Min, on Linux power1.cdacb.in 2.6.32-279.2.1.el6.x86_64 #1 SMP > Thu Jul 5 21:08:58 EDT 2012 x86_64, NOT VALID (see above) > > I t is showing some error and when i try to restart this application it > shows killed. Please help me. > > Thanks & Regards > Manisha Chauhan > > > > > > > > > _______________________________________________ > mpich-discuss mailing list mpich-discuss(a)mcs.anl.gov > To manage subscription options or unsubscribe: > https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-discuss] (no subject)
by Pavan Balaji 23 Dec '12

23 Dec '12

Not at this time. We do have plans to integrate gdb support into Hydra, but we haven't gotten to it yet. -- Pavan On 09/12/2012 07:09 AM US Central Time, Anton Prikazchikov wrote: > Hello, > > I want to ask if "the parallel debugger'' MPIGDB enters into a MPICH2 > package now? > If yes, where I can find instraction how to use it? > If not what a good alternative You can advice me? And where it is > possible to find MPIGDB? > > Regards, Anton > > > _______________________________________________ > mpich-discuss mailing list mpich-discuss(a)mcs.anl.gov > To manage subscription options or unsubscribe: > https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-discuss] hydra_pmi_proxy: error while loading shared libraries: libimf.so: cannot open shared object file: No such file or directory
by Pavan Balaji 23 Dec '12

23 Dec '12

Can you try mpiexec env | grep LD_LIBRARY_PATH? As Reuti suggested, this looks like a problem with your .bashrc (or equivalent) setup. -- Pavan On 09/06/2012 01:27 PM US Central Time, Marcelo C. R. Melo wrote: > Following your investigation, > > #!/bin/sh > echo $LD_LIBRARY_PATH > ldd /path/to/your/application > > returned the correct value for the environment variable: > > > /usr/local/gromos/md++/lib/:/usr/local/gromos/lib/:/usr/local/boost/lib/:/usr/local/openmm/lib/:/opt/intel/composerxe-2011.3.174/compiler/lib/intel64:/opt/intel/composerxe-2011.3.174/ipp/../compiler/lib/intel64:/opt/intel/composerxe-2011.3.174/ipp/lib/intel64:/opt/intel/composerxe-2011.3.174/compiler/lib/intel64:/opt/intel/composerxe-2011.3.174/mkl/lib/intel64:/opt/intel/composerxe-2011.3.174/tbb/lib/intel64//cc4.1.0_libc2.4_kernel2.6.16.21:/opt/intel/composerxe-2011.3.174/mpirt/lib/intel64:/usr/local/mpich2.shared.exec/lib/ > > and ldd returned: > > linux-vdso.so.1 => (0x00007fff0e2fd000) > libboost_program_options.so.1.42.0 => > /usr/local/boost/lib/libboost_program_options.so.1.42.0 (0x00007f6c29f42000) > libboost_filesystem.so.1.42.0 => > /usr/local/boost/lib/libboost_filesystem.so.1.42.0 (0x00007f6c29d2c000) > libboost_thread.so.1.42.0 => > /usr/local/boost/lib/libboost_thread.so.1.42.0 (0x00007f6c29b17000) > libmpichcxx.so.3 => > /usr/local/mpich2.shared.exec/lib/libmpichcxx.so.3 (0x00007f6c298f5000) > libpmpich.so.3 => > /usr/local/mpich2.shared.exec/lib/libpmpich.so.3 (0x00007f6c294b8000) > libopa.so.1 => /usr/local/mpich2.shared.exec/lib/libopa.so.1 > (0x00007f6c292b7000) > libmpl.so.1 => /usr/local/mpich2.shared.exec/lib/libmpl.so.1 > (0x00007f6c290b2000) > librt.so.1 => /lib/librt.so.1 (0x00007f6c28e8f000) > libpthread.so.0 => /lib/libpthread.so.0 (0x00007f6c28c72000) > libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f6c2895e000) > libm.so.6 => /lib/libm.so.6 (0x00007f6c286da000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f6c284c3000) > libc.so.6 => /lib/libc.so.6 (0x00007f6c28140000) > libboost_system.so.1.42.0 => > /usr/local/boost/lib/libboost_system.so.1.42.0 (0x00007f6c27f3b000) > libimf.so => > /opt/intel/composerxe-2011.3.174/compiler/lib/intel64/libimf.so > (0x00007f6c27b56000) > libsvml.so => > /opt/intel/composerxe-2011.3.174/compiler/lib/intel64/libsvml.so > (0x00007f6c274a2000) > libintlc.so.5 => > /opt/intel/composerxe-2011.3.174/compiler/lib/intel64/libintlc.so.5 > (0x00007f6c27352000) > libdl.so.2 => /lib/libdl.so.2 (0x00007f6c2714e000) > /lib64/ld-linux-x86-64.so.2 (0x00007f6c2a19e000) > > which seems correct to me. > > As for the > > mpiexec echo \$LD_LIBRARY_PATH > > it didn't work here. I only got > > $LD_LIBRARY_PATH > > I tested > > mpiexec "echo \$LD_LIBRARY_PATH" >> $log_file 2>&1 > , > mpiexec echo "\$LD_LIBRARY_PATH" >> $log_file 2>&1 > > and > > mpiexec echo \$LD_LIBRARY_PATH >> $log_file 2>&1 > > but got the same result every time. > I am not sure how the substitution of environment variables works when > mpiexec is called but it looks like there is no substitution at all, > since I didn't get a blank line, as if the variable was empty or not > set, I got its name. > > > ------------------------------ > > > Message: 4 > Date: Tue, 4 Sep 2012 22:28:56 +0200 > From: Reuti <reuti(a)staff.uni-marburg.de <javascript:;>> > To: mpich-discuss(a)mcs.anl.gov <javascript:;> > Subject: Re: [mpich-discuss] hydra_pmi_proxy: error while loading > shared libraries: libimf.so: cannot open shared object > file: No such > file or directory (Reuti) > Message-ID: > <1935634D-C475-4A7C-8110-200976C5DDB9(a)staff.uni-marburg.de > <javascript:;>> > Content-Type: text/plain; charset=us-ascii > > Am 04.09.2012 um 22:09 schrieb Marcelo C. R. Melo: > > > Yes Reuti, the LD_LIBRARY_PATH is configured correctly. > > I can use the software normally when logged into any node. > > The environment will be different when started by a queuing system, > at least for SGE I know this for sure and I think also for > Torque/PBS. To investigate, can you please submit a job with: > > #!/bin/sh > echo $LD_LIBRARY_PATH > ldd /path/to/your/application > > If we know this, we have to check the processes on the slave nodes > of the parallel job. Usually they are not started by an `ssh`, but > some builtin mechanism inside the queuingsystem. So, submitting a > job with this should show it: > > #!/bin/sh > mpiexec echo \$LD_LIBRARY_PATH > > It's necessary to escape the $, as we want to get the result from > the slave, not where the jobscript is executed. > > -- Reuti > > > > The problem is that when I Spawn another executable from my > initial launcher program, the spawned executable does not see the > environment that the launcher received. > > > > Is there any portable way to pass the environment variables to > Spawned processes? > > > > I posted this question on stack overflow a few days ago: > http://stackoverflow.com/questions/12252490/why-cant-and-environment-variab… > > > > Best regards, > > Marcelo > > > > _______________________________________________ > mpich-discuss mailing list mpich-discuss(a)mcs.anl.gov > To manage subscription options or unsubscribe: > https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-discuss] Paramesh with MPICH2 anyone?
by Pavan Balaji 23 Dec '12

23 Dec '12

There should not be any difference in which MPI is used for any high-level library. Did you try running MPICH with simpler programs? Does that work correctly? -- Pavan On 08/30/2012 02:41 AM US Central Time, Angel de Vicente wrote: > Hi, > > last days I have been trying Paramesh > (http://www.physics.drexel.edu/~olson/paramesh-doc/Users_manual/amr.html) I'm > using version 4.1, and I managed to make it work with one of the newest > Intel compilers and OpenMPI, but with the latest MPICH2 version, the > code works OK only if I run it in one processor, giving bogus results or > aborting whenever I try to run it with more processors. > > By any chance, anyone here has any experience with Paramesh+MPICH2? > > Thanks, > > > > _______________________________________________ > mpich-discuss mailing list mpich-discuss(a)mcs.anl.gov > To manage subscription options or unsubscribe: > https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-discuss] Error: assert (!closed) failed
by Pavan Balaji 23 Dec '12

23 Dec '12

One of the proxy processes died suddenly causing everything else to fall apart. Try using the latest version of hydra (3.0.1), and also try running the proxy processes with a debugger (set the environment variable HYDRA_USE_DDD=1). -- Pavan On 08/20/2012 03:46 AM US Central Time, Yann RADENAC wrote: > Hi, > > I'm developing MPI support for XtreemOS (www.xtreemos.eu) so that an MPI > program is managed as a single XtreemOS job. > To manage all processes as a single XtreemOS job, I've developed the > program xos-createProcess that plays the role of the launcher (replacing > ssh/rsh) to start a process on a remote machine that is part of the ones > reserved for the current job. > > I'm running a simple hello world MPI program where each processes sends > a string to the process 0 that itself prints them on standard output. > > When using MPICH2 with ssh, this program works perfectly on several > machines. > > When using MPICH2 with my launcher xos-createProcess, it works with an > MPI program of 2 processes on 2 different machines. > > However I cannot pass through the following error that happens when > running an MPI program of 3 processes on 3 different machines (or any n > processes on n different machines with n >= 3). Everything terminates > almost immediately with these error messages: > > > Process 0 ends with error code 7 and its standard error output is : > > [mpiexec(a)paradent-2.rennes.grid5000.fr] cmd_response > (./pm/pmiserv/pmiserv_pmi_v1.c:29): assert (!closed) failed > [mpiexec(a)paradent-2.rennes.grid5000.fr] fn_barrier_in > (./pm/pmiserv/pmiserv_pmi_v1.c:70): error writing PMI line > [mpiexec(a)paradent-2.rennes.grid5000.fr] handle_pmi_cmd > (./pm/pmiserv/pmiserv_cb.c:44): PMI handler returned error > [mpiexec(a)paradent-2.rennes.grid5000.fr] control_cb > (./pm/pmiserv/pmiserv_cb.c:289): unable to process PMI command > [mpiexec(a)paradent-2.rennes.grid5000.fr] HYDT_dmxu_poll_wait_for_event > (./tools/demux/demux_poll.c:77): callback returned error status > [mpiexec(a)paradent-2.rennes.grid5000.fr] HYD_pmci_wait_for_completion > (./pm/pmiserv/pmiserv_pmci.c:181): error waiting for event > [mpiexec(a)paradent-2.rennes.grid5000.fr] main (./ui/mpich/mpiexec.c:405): > process manager error waiting for completion > > > On *only* one of the other processes, the standard error output is: > > [proxy:0:[email protected]] HYD_pmcd_pmip_control_cmd_cb > (./pm/pmiserv/pmip_cb.c:928): assert (!closed) failed > [proxy:0:[email protected]] HYDT_dmxu_poll_wait_for_event > (./tools/demux/demux_poll.c:77): callback returned error status > [proxy:0:[email protected]] main > (./pm/pmiserv/pmip.c:226): demux engine error waiting for event > > > > The run command is: > > -bash -c '(mpiexec -launcher-exec /usr/bin/xos-createProcess -np 3 > -host `xreservation -a $XOS_RSVID` ./mpi/hello_world_MPI < /dev/null > > mpiexec.out) >& mpiexec.err' > > > > Can anyone explain me what this error means ? > > I'm using MPICH2 1.4.1p1 > > > Thanks for your help. > > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-discuss] Problems with terminal-IO and mpiexec
by Pavan Balaji 23 Dec '12

23 Dec '12

Using stdin in MPI is a terrible idea. Please don't do that. There are some improvements in mpich-3.0.1 to stdin management. See if that helps. If it doesn't, we'll look into it, but the priority to solve this will be really really low. Don't use stdin. Bad idea. -- Pavan On 07/31/2012 09:26 AM US Central Time, Dr. Wilfried Jakob (IAI) wrote: > Hi, > > I would appreciate if someone can help me with the following problem: > > I want to have a communication on the root process (rank=0) in such a > way that single characters are read from the terminal. > This is achieved in plain C by using termios.h and the functions > tcgetattr() and tcsetattr() as shown in the attached test program. With > gcc and Debian Linux this works fine. > > I translated the program with mpicc without any problems and started it > directly from the command line: it works well. > Then I started it with > mpiexec -f nodes -n 2 tioTestMPI > and received the following: > > Waiting for input ... > error with cbreak > Waiting for input ... > error with cbreak > > A more detailed analysis shows that the call to "tcgetattr" yields the > error "Invalid argument". This was obtained by a subsequent call to perror. > > A version including prior calls to > MPI_Init(&argc, &argv); > MPI_Comm_rank(MPI_COMM_WORLD, &rank); > MPI_Comm_size(MPI_COMM_WORLD, &size); > is given by the second program. It yields the same results: > Waiting for input ... > error with cbreak > lazy slave > > Thanks in advance > Wilfried Jakob > > Here is the source code of the test program 1: > ================================================= > #include <stdio.h> > #include <stdlib.h> > #include <termios.h> > #include <unistd.h> > > static struct termios new_io; > static struct termios old_io; > > int cbreak(int fd) { > /* save old terminal settings */ > if((tcgetattr(fd, &old_io)) == -1) > return -1; > new_io = old_io; > /* change terminal settings */ > new_io.c_lflag = new_io.c_lflag & ~(ECHO|ICANON); > new_io.c_cc[VMIN] = 1; > new_io.c_cc[VTIME]= 0; > > /* set new settings */ > if((tcsetattr(fd, TCSAFLUSH, &new_io)) == -1) > return -1; > return 1; > } > > > int getch(void) { > int c; > > if(cbreak(STDIN_FILENO) == -1) { > printf(" error with cbreak \n"); > exit(EXIT_FAILURE); > } > c = getchar(); > /* restore old terminal settings */ > tcsetattr(STDIN_FILENO, TCSANOW, &old_io); > return c; > } > > > int main (int argc, char** argv) > { > int ii; > > printf ("Waiting for input ...\n"); > ii = getch (); > printf (" read: \"%c\" = %d\n", (char)ii, ii); > > printf ("Waiting for input ...\n"); > ii = getch (); > printf (" read: \"%c\" = %d\n", (char)ii, ii); > > printf ("\nfinished!\n"); > return 0; > } > ================================================= > > Here is the source code of the test program 2: > ================================================= > #include <stdio.h> > #include <stdlib.h> > #include <termios.h> > #include <unistd.h> > > #include "mpi.h" > > static struct termios new_io; > static struct termios old_io; > > > int cbreak(int fd) { > /* save old terminal settings */ > if((tcgetattr(fd, &old_io)) == -1) > return -1; > new_io = old_io; > /* change terminal settings */ > new_io.c_lflag = new_io.c_lflag & ~(ECHO|ICANON); > new_io.c_cc[VMIN] = 1; > new_io.c_cc[VTIME]= 0; > > /* set new settings */ > if((tcsetattr(fd, TCSAFLUSH, &new_io)) == -1) > return -1; > return 1; > } > > > int getch(void) { > int c; > > if(cbreak(STDIN_FILENO) == -1) { > printf(" error with cbreak\n"); > exit(EXIT_FAILURE); > } > c = getchar(); > /* restore old terminal settings */ > tcsetattr(STDIN_FILENO, TCSANOW, &old_io); > return c; > } > > > int main (int argc, char** argv) > { > int ii, rank, size; > > MPI_Init(&argc, &argv); > MPI_Comm_rank(MPI_COMM_WORLD, &rank); > MPI_Comm_size(MPI_COMM_WORLD, &size); > > if (rank == 0) { /* master */ > printf ("Waiting for input ...\n"); > ii = getch (); > printf (" read: \"%c\" = %d\n", (char)ii, ii); > > printf ("Waiting for input ...\n"); > ii = getch (); > printf (" read: \"%c\" = %d\n", (char)ii, ii); > > printf ("\nfinished!\n"); > } /* master */ > else > printf ("lazy slave\n"); > > MPI_Finalize(); > return 0; > } > ================================================= > > > > _______________________________________________ > mpich-discuss mailing list mpich-discuss(a)mcs.anl.gov > To manage subscription options or unsubscribe: > https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0