- discuss - mailman3.cels.anl.gov

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

Re: [mpich-discuss] Non-zero exit codes in Hydra (1.5b2)
by Pavan Balaji 23 Dec '12

23 Dec '12

On 07/16/2012 08:19 PM US Central Time, Yauheni Zelenko wrote: > Looks like Hydra again always treat non-zero exit codes as errors in > contrast with 1.4 (pmiserv_cb.c). > > Our application non-zero exit code as flag to further > post-processing. > > It definitely should be good reason to change code in current state. > > However I think will be good idea to have command line argument to > specify way of non-zero exit codes handling. Hmm. Good point. We had this discussion with our Open MPI friends; I'm not sure what we decided in the end. Cc'ing Jeff Squyres from the OMPI team. Jeff: what do you guys do with non-zero exit codes? -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-discuss] Hard-coded path to mpiexec.hydra.conf (1.4, 1.5)
by Pavan Balaji 23 Dec '12

23 Dec '12

Sorry about the delay in getting around to this. We were tied up with the mpich-3.0 release. I'm still missing the point of this environment variable. Once you have a pre-built mpich installation, you can install mpich in any location of your choosing using: % make install prefix=<foobar> This overrides the --prefix passed to configure. In this case, you should ship the prebuilt mpich to your customers and run the above "make install" command to place it in the right location. Some of our other vendor partners follow the same model as well. -- Pavan On 07/12/2012 12:46 PM US Central Time, Yauheni Zelenko wrote: > Hi, Pavan! > > Thank you for help! > > However will be good idea to disable check of file in install location at all. > > Or there should be way to specify install location in run-time with environment variable or command-line option (OpenMPI uses OPAL_PREFIX and --prefix correspondingly). > > Other files affected are mpi compilation scripts (mpicc, etc), MPE scripts, libtool generated files, packages, makefiles. > > Easy way to check - to compile MPICH2 in your home directory, install it and grep installed files for your login name. > > Eugene. > ________________________________________ > From: Pavan Balaji [balaji(a)mcs.anl.gov] > Sent: Thursday, July 12, 2012 10:26 AM > To: mpich-discuss(a)mcs.anl.gov > Cc: Yauheni Zelenko > Subject: Re: [mpich-discuss] Hard-coded path to mpiexec.hydra.conf (1.4, 1.5) > > Thanks. I've fixed this in r10004. Now the priority order for the > config file: > > 1. Command line > > 2. Environment variable > > 3. Home directory > > 4. Install directory > > -- Pavan > > On 07/11/2012 06:37 PM, Yauheni Zelenko wrote: >> Hi! >> >> Hydra always try to open mpiexec.hydra.conf file in original install path location in HYD_uii_mpx_get_parameters() if such file is not found in user's home directory. >> >> We ship pre-built MPICH2 with our application to customers, where original install path is invalid. >> >> I think will be good idea to rely on environment variable instead of hard-coded path. >> >> Eugene. >> _______________________________________________ >> 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 > > > _______________________________________________ > 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

help
by behzad moradi 23 Dec '12

23 Dec '12

behzad_moradi(a)yahoo.com

1 0