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

Bug in HYDT_dbg_setup_procdesc
by Chris January 30 Apr '13

30 Apr '13

Hello, We (Allinea) have noticed a bug introduced in HYDT_dbg_setup_procdesc between 3.0.2 and 3.0.3 caused by this commit: http://trac.mpich.org/projects/mpich/changeset/e04dd4b64ff618f2df58789265b7… When debugging a 4 process job on a 32-core machine using DDT we find that the 4 entries in MPIR_Proctable all have the same pid. Here is how to reproduce the issue outside of DDT: jbray@mic3:31053% gdb --args mpirun -np 4 wave_f.exe GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/jbray/prog/mpich/mpich-3.0.3/mic_gnu/install/bin/mpirun...done. (gdb) break MPIR_Breakpoint Breakpoint 1 at 0x428a70: file ./tools/debugger/debugger.c, line 25. (gdb) r Starting program: /home/jbray/prog/mpich/mpich-3.0.3/mic_gnu/install/bin/mpirun -np 4 wave_f.exe [Thread debugging using libthread_db enabled] Detaching after fork from child process 107606. Breakpoint 1, MPIR_Breakpoint () at ./tools/debugger/debugger.c:25 25 } Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.107.el6.x86_64 libxml2-2.7.6-12.el6_4.1.x86_64 zlib-1.2.3-29.el6.x86_64 (gdb) print *MPIR_proctable@4 $1 = {{host_name = 0x6723f0 "mic3", executable_name = 0x6723d0 "./wave_f.exe", pid = 107847}, {host_name = 0x6723b0 "mic3", executable_name = 0x672390 "./wave_f.exe", pid = 107847}, { host_name = 0x672370 "mic3", executable_name = 0x672350 "./wave_f.exe", pid = 107847}, {host_name = 0x672330 "mic3", executable_name = 0x672310 "./wave_f.exe", pid = 107847}} (gdb) As you can see MPIR_proctable claims each rank has the same pid, when in reality they do not: -bash-4.1$ ps aux | grep 'wave_f.exe' jbray 107841 0.3 0.0 99896 18772 pts/2 S+ 10:57 0:00 gdb --args mpirun -np 4 ./wave_f.exe jbray 107843 0.0 0.0 23144 1288 pts/2 T 10:57 0:00 /home/jbray/prog/mpich/mpich-3.0.3/mic_gnu/install/bin/mpirun -np 4 ./wave_f.exe jbray 107847 0.0 0.0 46488 1504 ? Ss 10:57 0:00 ./wave_f.exe jbray 107848 0.0 0.0 29332 1472 ? Ss 10:57 0:00 ./wave_f.exe jbray 107849 0.0 0.0 29332 1472 ? Ss 10:57 0:00 ./wave_f.exe jbray 107850 0.0 0.0 29332 1472 ? Ss 10:57 0:00 ./wave_f.exe cjanuary 107870 0.0 0.0 103244 864 pts/6 S+ 10:57 0:00 grep ./wave_f.exe Regards, Chris January - VP Engineering - Allinea Software Ltd.

1 0

Re: [mpich-discuss] success and failure report for mpich-3.0.2
by Pavan Balaji 29 Apr '13

29 Apr '13

Adding discuss(a)mpich.org back to cc. > [proxy:0:1@linpc1] HYDU_create_process > (../../../../mpich-3.0.2/src/pm/hydra/utils/launch/launch.c:74): > execvp error on file date (No such file or directory) This seems to indicate that "date" is not found on linpc1. Try giving the full path to "date". -- Pavan On 04/29/2013 02:40 AM US Central Time, Siegmar Gross wrote: > Hi > >> This is not an architectural problem. You need to have mpich installed >> on all machines. It looks like some of your machines don't have it >> installed. > > It is installed on all machines, but sometimes I have a problem if > I use different operating systems on the same hardware architecture. > I use "date" to exclude any errors in my program. I get an error, > if I try to start my processes from a Solaris machine and everything > works well, if I do the same thing from my Linux machine, so that > it is an architectural problem in my opinion. I have unsubscribed > from the list in the meantime, because I didn't get any response. > Perhaps you can reply to my address directly, if you want to send > a response. I get the following results. > > > sunpc1 fd1026 105 which mpiexec > /usr/local/mpich-3.0.2_64_cc/bin/mpiexec > sunpc1 fd1026 106 ssh linpc1 which mpiexec > /usr/local/mpich-3.0.2_64_cc/bin/mpiexec > sunpc1 fd1026 107 mpiexec -np 2 -host sunpc0,sunpc1 date > Mon Apr 29 09:26:34 CEST 2013 > Mon Apr 29 09:26:35 CEST 2013 > sunpc1 fd1026 108 mpiexec -np 2 -host linpc0,linpc1 date > [proxy:0:1@linpc1] HYDU_create_process (../../../../mpich-3.0.2/src/pm/hydra/utils/launch/launch.c:74): execvp > error on file date (No such file or directory) > > =================================================================================== > = BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES > = EXIT CODE: 255 > = CLEANING UP REMAINING PROCESSES > = YOU CAN IGNORE THE BELOW CLEANUP MESSAGES > =================================================================================== > [proxy:0:0@linpc0] HYDU_create_process (../../../../mpich-3.0.2/src/pm/hydra/utils/launch/launch.c:74): execvp > error on file date (No such file or directory) > > =================================================================================== > = BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES > = EXIT CODE: 255 > = CLEANING UP REMAINING PROCESSES > = YOU CAN IGNORE THE BELOW CLEANUP MESSAGES > =================================================================================== > sunpc1 fd1026 109 ssh linpc1 > linpc1 fd1026 101 mpiexec -np 2 -host linpc0,linpc1 date > Mon Apr 29 09:27:40 CEST 2013 > Mon Apr 29 09:27:41 CEST 2013 > linpc1 fd1026 102 mpiexec -np 2 -host sunpc0,sunpc1 date > Mon Apr 29 09:27:49 CEST 2013 > Mon Apr 29 09:27:49 CEST 2013 > linpc1 fd1026 103 mpiexec -np 2 -host sunpc0,linpc0 date > Mon Apr 29 09:30:55 CEST 2013 > Mon Apr 29 09:30:56 CEST 2013 > linpc1 fd1026 104 linpc1 fd1026 103 > > > As you can see below, I wasn't able to build the packacke on some > machines with GNU C or in 32-bit versions. Thank you very much > for any answer in advance. > > Kind regards > > Siegmar > >> >> -- Pavan >> >> On 03/22/2013 10:22 AM US Central Time, Siegmar Gross wrote: >>> Hi >>> >>> today I tried to install mpich-3.0.2. I could compile and install the >>> package for the following architectures. >>> >>> openSuSE Linux 12.1, x86_64, Sun C 5.12, 64-bit >>> Solaris 10, x86_64, Sun C 5.12, 64-bit >>> Solaris 10, sparc, Sun C 5.12, 32-bit >>> Solaris 10, sparc, Sun C 5.12, 64-bit >>> >>> As described in the RELEASE_NOTES a communication between little-endian >>> and big-endian machines is not possible (broken pipe). Unfortunately >>> you don't even allow different operating systems (it seems that you >>> don't evaluate PATH to find a program). >>> >>> sunpc1 fd1026 103 mpiexec -np 2 -host sunpc0,sunpc1 init_finalize >>> Hello! >>> Hello! >>> >>> sunpc1 fd1026 104 mpiexec -np 2 -host sunpc0,linpc1 init_finalize >>> [proxy:0:1@linpc1] HYDU_create_process >>> (../../../../mpich-3.0.2/src/pm/hydra/utils/launch/launch.c:74): >>> execvp error on file init_finalize (No such file or directory) >>> >>> ======================================================================== >>> = BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES >>> = EXIT CODE: 255 >>> = CLEANING UP REMAINING PROCESSES >>> = YOU CAN IGNORE THE BELOW CLEANUP MESSAGES >>> ======================================================================== >>> [proxy:0:0@sunpc0] HYD_pmcd_pmip_control_cmd_cb >>> (../../../../mpich-3.0.2/src/pm/hydra/pm/pmiserv/pmip_cb.c:886): >>> assert (!closed) failed >>> [proxy:0:0@sunpc0] HYDT_dmxu_poll_wait_for_event >>> (../../../../mpich-3.0.2/src/pm/hydra/tools/demux/demux_poll.c:77): >>> callback returned error status >>> [proxy:0:0@sunpc0] main >>> (../../../../mpich-3.0.2/src/pm/hydra/pm/pmiserv/pmip.c:206): >>> demux engine error waiting for event >>> >>> >>> >>> The programs are available on both machines. >>> >>> sunpc1 fd1026 105 which init_finalize >>> /home/fd1026/SunOS/x86_64/bin/init_finalize >>> sunpc1 fd1026 106 ssh linpc1 which init_finalize >>> /home/fd1026/Linux/x86_64/bin/init_finalize >>> sunpc1 fd1026 107 >>> >>> >>> >>> >>> I wasn't able to build the package on the following architectures. >>> >>> >>> openSuSE Linux 12.1, x86_64, Sun C 5.12, 32-bit >>> openSuSE Linux 12.1, x86_64, GNU C 4.7.1, 32-bit >>> ------------------------------------------------ >>> >>> tyr mpich-3.0.2-Linux.x86_64.32_cc 158 tail log.make.Linux.x86_64.32_cc >>> CC mplstr.lo >>> CC mpltrmem.lo >>> CC mplenv.lo >>> CCLD libmpl.la >>> /usr/lib/libxml2.so: could not read symbols: File in wrong format >>> make[2]: *** [libmpl.la] Error 2 >>> make[2]: Leaving directory `.../src/mpl' >>> make[1]: *** [all-recursive] Error 1 >>> >>> >>> >>> openSuSE Linux 12.1, x86_64, GNU C 4.7.1, 64-bit >>> ------------------------------------------------ >>> >>> tyr mpich-3.0.2-Linux.x86_64.64_gcc 171 tail log.make.Linux.x86_64.64_gcc >>> CC mpltrmem.lo >>> CC mplenv.lo >>> CCLD libmpl.la >>> /usr/local/bin/ld: libmpl.so.1: No such file: No such file or directory >>> collect2: error: ld returned 1 exit status >>> make[2]: *** [libmpl.la] Error 1 >>> make[2]: Leaving directory `.../src/mpl' >>> >>> >>> >>> Solaris 10, x86_64, Sun C 5.12, 32-bit >>> -------------------------------------- >>> >>> hangs >>> >>> >>> >>> Solaris 10, x86_64, GNU C 4.7.1, 32-bit >>> --------------------------------------- >>> >>> tyr mpich-3.0.2-SunOS.x86_64.32_gcc 193 tail -12 log.make.SunOS.x86_64.32_gcc >>> CC src/mpi/coll/barrier_group.lo >>> CC src/mpi/coll/helper_fns.lo >>> Assembler: helper_fns.c >>> "/var/tmp//ccIdXgrh.s", line 912 : Syntax error >>> Near line: "mov $PREFETCHBLOCK/16, %eax" >>> "/var/tmp//ccIdXgrh.s", line 920 : Syntax error >>> Near line: "mov $PREFETCHBLOCK/8, %eax" >>> make[2]: *** [src/mpi/coll/helper_fns.lo] Error 1 >>> >>> >>> >>> Solaris 10, x86_64, GNU C 4.7.1, 64-bit >>> Solaris 10, sparc, GNU C 4.7.1, 32-bit >>> Solaris 10, sparc, GNU C 4.7.1, 64-bit >>> --------------------------------------- >>> >>> tyr mpich-3.0.2-SunOS.x86_64.64_gcc 195 tail log.make.SunOS.x86_64.64_gcc >>> CXX src/binding/cxx/initcxx.lo >>> CXXLD lib/libmpichcxx.la >>> ld: fatal: file libmpichcxx.so.10: open failed: No such file or directory >>> ld: fatal: file processing errors. No output written to >>> lib/.libs/libmpichcxx.so.10.0.2 >>> collect2: error: ld returned 1 exit status >>> make[2]: *** [lib/libmpichcxx.la] Error 1 >>> >>> >>> Kind regards >>> >>> Siegmar >>> >>> _______________________________________________ >>> discuss mailing list discuss(a)mpich.org >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/discuss >>> >> >> -- >> Pavan Balaji >> http://www.mcs.anl.gov/~balaji > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-discuss] get the process rank in the bash script
by Pavan Balaji 29 Apr '13

29 Apr '13

Hello, Adding discuss(a)mpich.org back to cc. There is a second alternative -- PMI_ID -- that you might want to try. If that doesn't work, Cray might be using something different and you'll need to check with them. -- Pavan On 04/29/2013 02:22 AM US Central Time, Kirill Lykov wrote: > Thanks for the reply, I'm working on the Cray machine so the MPICH2 version for cray is defined by the following line: CRAY_MPICH2_VERSION=5.6.0 > > > ________________________________________ > From: Pavan Balaji [balaji(a)mcs.anl.gov] > Sent: Monday, April 29, 2013 12:13 AM > To: discuss(a)mpich.org > Cc: Lykov Kirill > Subject: Re: [mpich-discuss] get the process rank in the bash script > > You can use PMI_RANK. I just tried it and it works as expected. Which > version of MPICH are you using? > > -- Pavan > > On 02/25/2013 10:06 AM US Central Time, Kirill Lykov wrote: >> Dear mpich users, >> >> I'm looking for an environmental variable which can be used in a bash script to identify the process rank. >> I launch a bash script using mpi: >> mpirun ./my-script.sh >> >> In my-script I want to use the rank of the process to identify which input file to use. In OpenMPI, I used OMPI_COMM_WORLD_RANK and my-script.sh looked like the following: >> >> inputName="MyInput_$OMPI_COMM_WORLD_RANK"./myexe $inputName >> >> What can be used in MPICH instead of OMPI_COMM_WORLD_RANK? I found somewhere that $PMI_RANK is the same but I found that it is empty. >> >> Kirill Lykov, Mr. >> >> Doctoral Assistant >> Institute of >> Computational Science >> Faculty of Informatics >> Universitï¿½ della Svizzera italiana, USI >> Via G. Buffi 13 >> CH - 6904 Lugano >> (e) kirill.lykov(a)usi.ch >> (t) +41 (0) 788413392 >> >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> > > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-discuss] Query about MPI_Bsend
by Pavan Balaji 28 Apr '13

28 Apr '13

Vihari, Maybe I'm not fully understanding this, but perhaps you are misunderstanding how MPI_Bsend works. MPI_Bsend only guarantees that it will not block if enough buffering is available. It, however, does not guarantee that it will block if the user buffer is full. For example, the network (TCP/IP in this case) also has some buffering, so the message can be pushed down to TCP/IP to free up the user buffer. -- Pavan On 04/25/2013 08:02 AM US Central Time, Vihari Piratla wrote: > I am trying to implement a logical ring with MPI; where every process > receives a message from process with id one less than that of current > process and forwards to the next process in cyclic fashion. My aim is to > traffic buffer such that it loses some messages or maybe puts them in > out of order. > A cycle of communication will finish when a message dispatched by root > node comes back again to root. > here is the code that I have tried: I am just including relevant parts > of it. > > | if(procId!=root) > { > sleep(100); > while(1) > { > tm = MPI_Wtime(); > MPI_Irecv( &message, STR_LEN, MPI_CHAR, > ((procId-1)>=0?(procId-1):(numProc-1)),RETURN_DATA_TAG, > MPI_COMM_WORLD,&receiveRequest); > > MPI_Wait(&receiveRequest,&status); > printf("%d: Received\n",procId); > > if(!strncmp(message,"STOP",4)&&(procId==(numProc-1))) > break; > > MPI_Ssend( message, STR_LEN, MPI_CHAR, > (procId+1)%numProc, SEND_DATA_TAG, MPI_COMM_WORLD); > if(!strncmp(message,"STOP",4)) > break; > printf("%d: Sent\n",procId); > } > } > else > { > for(iter=0;iter<benchmarkSize;iter++) > { > //Synthesize the message > message[STR_LEN-1] = '\0'; > iErr = MPI_Bsend( message, STR_LEN, MPI_CHAR, > (root+1)%numProc, SEND_DATA_TAG, MPI_COMM_WORLD); > if (iErr != MPI_SUCCESS) { > char error_string[BUFSIZ]; > int length_of_error_string; > MPI_Error_string(iErr, error_string, &length_of_error_string); > fprintf(stderr, "%3d: %s\n", procId, error_string); > } > > tm = MPI_Wtime(); > while(((MPI_Wtime()-tm)*1000)<delay); > printf("Root: Sending\n"); > } > > for(iter=0;iter<benchmarkSize;iter++) > { > MPI_Recv(message,STR_LEN,MPI_CHAR, > (numProc-1),RETURN_DATA_TAG,MPI_COMM_WORLD,&status); > > //We should not wait for the messages to be received but wait for certain amount of time > > //Extract the fields in the message > if(((prevRcvdSeqNum+1)!=atoi(seqNum))&&(prevRcvdSeqNum!=0)) > outOfOrderMsgs++; > prevRcvdSeqNum = atoi(seqNum); > printf("Seq Num: %d\n",atoi(seqNum)); > rcvdMsgs++; > printf("Root: Receiving\n"); > } > MPI_Isend( "STOP", 4, MPI_CHAR, > (root+1)%numProc, SEND_DATA_TAG, MPI_COMM_WORLD,&sendRequest); > MPI_Wait(&sendRequest,&status); > > /*This is to ask all other processes to terminate, when the work is done*/ > }| > > Now, I have these questions: > 1) Why is it that when I inject some sleep in the other processes(I mean > other than root) of the ring; NO receive is taking place? > 2) Even when the buffer size is only one, how is it that root node is > able to dispatch messages through MPI_Bsend without an error? for > example the case when it needs to send total 10 messages at a rate of > 1000 per second and with buffer size of 1. MPI_Bsend is able to dispatch > all the messages without any error of "buffer full"; irrespective of the > presence of sleep() in other processes of the ring! > > In short How on earth is MPI_Bsend is not giving me an error > "Insufficient space in buffer" even if my buffersize is size enough to > accommodate only a single message, MPI_Bsend did not show an error for > 65 of the total 100 messages sent? I intentionally made the receive > buffers to be unavailable by making other processes to sleep before they > start processing receive and send. > > Thanks a ton! > -- > V > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-discuss] MPICH-3.0.2 Compilation error on 32 bit Arch Linux
by Pavan Balaji 28 Apr '13

28 Apr '13

Mark, This is a bit surprising. Before we go chasing this, can you try out the latest release of mpich (3.0.4) to make sure the problem still exists? -- Pavan On 03/28/2013 02:23 PM US Central Time, Mark E. Lee wrote: > To whom it may concern, > > I have failed to compile MPICH-3.0.2 on 32 bit Arch Linux with both > single and multiple make threads. My configure options are : > > ====BEGIN CONFIGURE OPTIONS==== > > ./configure --prefix="/usr" \ > --exec-prefix="/usr/lib" \ > --bindir="/usr/bin" \ > --sbindir="/usr/sbin" \ > --sysconfdir="/etc/mpich" \ > --includedir="/usr/include/mpich" \ > --libdir="/usr/lib/mpich" \ > --enable-shared \ > --enable-fast=all,O3 > > ====END CONFIGURE OPTIONS==== > > See below for the error: > > ====BEGIN ERROR MESSAGE==== > > /home/mark/Downloads/mpich3/src/mpich-3.0.2/src/pm/hydra/tools/topo/hwloc/hwloc/include/private/cpuid.h: Assembler messages: > /home/mark/Downloads/mpich3/src/mpich-3.0.2/src/pm/hydra/tools/topo/hwloc/hwloc/include/private/cpuid.h:39: Error: symbol `Lhwloc1' is already defined > make[5]: *** [topology-x86.lo] Error 1 > make[5]: Leaving directory > `/home/mark/Downloads/mpich3/src/mpich-3.0.2/src/pm/hydra/tools/topo/hwloc/hwloc/src' > make[4]: *** [all-recursive] Error 1 > make[4]: Leaving directory > `/home/mark/Downloads/mpich3/src/mpich-3.0.2/src/pm/hydra/tools/topo/hwloc/hwloc/src' > make[3]: *** [all-recursive] Error 1 > make[3]: Leaving directory > `/home/mark/Downloads/mpich3/src/mpich-3.0.2/src/pm/hydra/tools/topo/hwloc/hwloc' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory > `/home/mark/Downloads/mpich3/src/mpich-3.0.2/src/pm/hydra' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/mark/Downloads/mpich3/src/mpich-3.0.2' > make: *** [all] Error 2 > > ====END ERROR MESSAGE==== > > Thanks, > Mark > > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-discuss] success and failure report for mpich-3.0.2
by Pavan Balaji 28 Apr '13

28 Apr '13

This is not an architectural problem. You need to have mpich installed on all machines. It looks like some of your machines don't have it installed. -- Pavan On 03/22/2013 10:22 AM US Central Time, Siegmar Gross wrote: > Hi > > today I tried to install mpich-3.0.2. I could compile and install the > package for the following architectures. > > openSuSE Linux 12.1, x86_64, Sun C 5.12, 64-bit > Solaris 10, x86_64, Sun C 5.12, 64-bit > Solaris 10, sparc, Sun C 5.12, 32-bit > Solaris 10, sparc, Sun C 5.12, 64-bit > > As described in the RELEASE_NOTES a communication between little-endian > and big-endian machines is not possible (broken pipe). Unfortunately > you don't even allow different operating systems (it seems that you > don't evaluate PATH to find a program). > > sunpc1 fd1026 103 mpiexec -np 2 -host sunpc0,sunpc1 init_finalize > Hello! > Hello! > > sunpc1 fd1026 104 mpiexec -np 2 -host sunpc0,linpc1 init_finalize > [proxy:0:1@linpc1] HYDU_create_process > (../../../../mpich-3.0.2/src/pm/hydra/utils/launch/launch.c:74): > execvp error on file init_finalize (No such file or directory) > > ======================================================================== > = BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES > = EXIT CODE: 255 > = CLEANING UP REMAINING PROCESSES > = YOU CAN IGNORE THE BELOW CLEANUP MESSAGES > ======================================================================== > [proxy:0:0@sunpc0] HYD_pmcd_pmip_control_cmd_cb > (../../../../mpich-3.0.2/src/pm/hydra/pm/pmiserv/pmip_cb.c:886): > assert (!closed) failed > [proxy:0:0@sunpc0] HYDT_dmxu_poll_wait_for_event > (../../../../mpich-3.0.2/src/pm/hydra/tools/demux/demux_poll.c:77): > callback returned error status > [proxy:0:0@sunpc0] main > (../../../../mpich-3.0.2/src/pm/hydra/pm/pmiserv/pmip.c:206): > demux engine error waiting for event > > > > The programs are available on both machines. > > sunpc1 fd1026 105 which init_finalize > /home/fd1026/SunOS/x86_64/bin/init_finalize > sunpc1 fd1026 106 ssh linpc1 which init_finalize > /home/fd1026/Linux/x86_64/bin/init_finalize > sunpc1 fd1026 107 > > > > > I wasn't able to build the package on the following architectures. > > > openSuSE Linux 12.1, x86_64, Sun C 5.12, 32-bit > openSuSE Linux 12.1, x86_64, GNU C 4.7.1, 32-bit > ------------------------------------------------ > > tyr mpich-3.0.2-Linux.x86_64.32_cc 158 tail log.make.Linux.x86_64.32_cc > CC mplstr.lo > CC mpltrmem.lo > CC mplenv.lo > CCLD libmpl.la > /usr/lib/libxml2.so: could not read symbols: File in wrong format > make[2]: *** [libmpl.la] Error 2 > make[2]: Leaving directory `.../src/mpl' > make[1]: *** [all-recursive] Error 1 > > > > openSuSE Linux 12.1, x86_64, GNU C 4.7.1, 64-bit > ------------------------------------------------ > > tyr mpich-3.0.2-Linux.x86_64.64_gcc 171 tail log.make.Linux.x86_64.64_gcc > CC mpltrmem.lo > CC mplenv.lo > CCLD libmpl.la > /usr/local/bin/ld: libmpl.so.1: No such file: No such file or directory > collect2: error: ld returned 1 exit status > make[2]: *** [libmpl.la] Error 1 > make[2]: Leaving directory `.../src/mpl' > > > > Solaris 10, x86_64, Sun C 5.12, 32-bit > -------------------------------------- > > hangs > > > > Solaris 10, x86_64, GNU C 4.7.1, 32-bit > --------------------------------------- > > tyr mpich-3.0.2-SunOS.x86_64.32_gcc 193 tail -12 log.make.SunOS.x86_64.32_gcc > CC src/mpi/coll/barrier_group.lo > CC src/mpi/coll/helper_fns.lo > Assembler: helper_fns.c > "/var/tmp//ccIdXgrh.s", line 912 : Syntax error > Near line: "mov $PREFETCHBLOCK/16, %eax" > "/var/tmp//ccIdXgrh.s", line 920 : Syntax error > Near line: "mov $PREFETCHBLOCK/8, %eax" > make[2]: *** [src/mpi/coll/helper_fns.lo] Error 1 > > > > Solaris 10, x86_64, GNU C 4.7.1, 64-bit > Solaris 10, sparc, GNU C 4.7.1, 32-bit > Solaris 10, sparc, GNU C 4.7.1, 64-bit > --------------------------------------- > > tyr mpich-3.0.2-SunOS.x86_64.64_gcc 195 tail log.make.SunOS.x86_64.64_gcc > CXX src/binding/cxx/initcxx.lo > CXXLD lib/libmpichcxx.la > ld: fatal: file libmpichcxx.so.10: open failed: No such file or directory > ld: fatal: file processing errors. No output written to > lib/.libs/libmpichcxx.so.10.0.2 > collect2: error: ld returned 1 exit status > make[2]: *** [lib/libmpichcxx.la] Error 1 > > > Kind regards > > Siegmar > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-discuss] mpich2 support processor affinity by default
by Pavan Balaji 28 Apr '13

28 Apr '13

By default, Hydra does not do process binding to cpu cores. However, you can ask it to do binding using an mpiexec argument. See mpiexec -help for more information. -- Pavan On 03/22/2013 05:23 AM US Central Time, benzhi cao wrote: > > > 2013/3/22 benzhi cao <caobenzhi0915(a)gmail.com > <mailto:[email protected]>> > > Hi~ > when you run a program with multi-threads.(For instance ,you > just type "mpiexec -n 4 ./app" to run an app with four threads.) > ,obviously the processor manager will fork several processes to > execute the app.What I am wondering is the MPICH2 support processor > affinity by default? Does the MPI process manager(MPICH2 hydra) > will bind each forked process to a cpu automatically or just do > nothing after forking the processes and waithing for the os to > dispatch this? > I am appreciate for any reply~Thanks in advance~ > Best~ > > > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-discuss] Hydra fills in the MPIR_proctable[] incorrectly with multiple processes per node
by Pavan Balaji 28 Apr '13

28 Apr '13

John, I've created a ticket for this so we don't forget it: https://trac.mpich.org/projects/mpich/ticket/1821 However, there's currently no ETA for this work. -- Pavan On 03/18/2013 02:23 PM US Central Time, John DelSignore wrote: > Pavan Balaji wrote: >> On 03/18/2013 11:56 AM US Central Time, John DelSignore wrote: >>> But the bigger win is that tool would have to read only 513 separate >>> strings using ptrace() or /proc, which represents a big time >>> savings. >> >> Doesn't the tool still have to read all the strings? > > No. > >> Or are you >> planning to compare pointers to check if they are the same and not read >> the string again if they are the same? > > It could be done by comparing pointers, but the way TotalView implements it is through a "target address space data cache". Before TV reads from the target address space for the process (in any target read situation, not just MPIR), it looks in a data cache associated with the target address space, and if the data is already in the cache, there is no reason to reread it from the target address space using ptrace() or /proc. > > Cheers, John D. > >> >> -- Pavan >> -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-discuss] suspend/resume an MPI process using SIGSTOP and SIGCONT
by Pavan Balaji 28 Apr '13

28 Apr '13

Not that we know of. All signals that Hydra doesn't trap are forwarded directly to the MPI processes. -- Pavan On 02/26/2013 03:15 PM US Central Time, Ali Bouaricha wrote: > Hello, > > > > I wanted to suspend a process in MPICH2 by using kill(procid, SIGSTOP) > > > > But it seems that when I do that, the whole run gets suspended. > > > > Is there any implication of kill(procid,SIGSTOP) on the remainder of > > processes? > > > > Please help. > > > > Thank you and Regards, > > > > Ali Bouaricha > > > > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-discuss] get the process rank in the bash script
by Pavan Balaji 28 Apr '13

28 Apr '13

You can use PMI_RANK. I just tried it and it works as expected. Which version of MPICH are you using? -- Pavan On 02/25/2013 10:06 AM US Central Time, Kirill Lykov wrote: > Dear mpich users, > > I'm looking for an environmental variable which can be used in a bash script to identify the process rank. > I launch a bash script using mpi: > mpirun ./my-script.sh > > In my-script I want to use the rank of the process to identify which input file to use. In OpenMPI, I used OMPI_COMM_WORLD_RANK and my-script.sh looked like the following: > > inputName="MyInput_$OMPI_COMM_WORLD_RANK"./myexe $inputName > > What can be used in MPICH instead of OMPI_COMM_WORLD_RANK? I found somewhere that $PMI_RANK is the same but I found that it is empty. > > Kirill Lykov, Mr. > > Doctoral Assistant > Institute of > Computational Science > Faculty of Informatics > Universitï¿½ della Svizzera italiana, USI > Via G. Buffi 13 > CH - 6904 Lugano > (e) kirill.lykov(a)usi.ch > (t) +41 (0) 788413392 > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0