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

Re: [mpich-discuss] Error buildingmpich-master-v3.2-88-gbbb40df74d46
by Rob Latham 15 Jan '16

15 Jan '16

On 01/15/2016 06:56 AM, Siegmar Gross wrote: > Hi Rob, > > I had to change "#if" to "#elif", but I still get errors. I've attached the > log files. OK, you can see what I'm trying to do, yes? On my end, everything I've done to re-create your environment works for me. One more favor: send me your src/mpl/include/mplconfig.h Thanks ==rob _______________________________________________ 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] Error buildingmpich-master-v3.2-88-gbbb40df74d46
by Siegmar Gross 15 Jan '16

15 Jan '16

Hi Rob, I had to change "#if" to "#elif", but I still get errors. I've attached the log files. loki bt 111 diff mpl_bt.c* 47,51c47 < /* we need not only the symbols but the header file too (for the cursor and < * context), so tighten up when we take the libunwind path. Thanks < * Siegmar.Gross(a)informatik.hs-fulda.de for the bug report about systems with < * libunwind libraries but no libunwind development headers */ < #elif defined MPL_HAVE_LIBUNWIND && defined(MPL_HAVE_LIBUNWIND_H) --- > #elif defined MPL_HAVE_LIBUNWIND loki bt 112 Best regards Siegmar On 01/14/16 20:00, Rob Latham wrote: > > > On 01/14/2016 10:39 AM, Rob Latham wrote: > >> >> For example, our configure also found the backtrace_symbols and >> backtrace_create_state functions. These are often part of GCC, or maybe >> standalone in the libbacktrace package. On your system (as is common on >> many systems) there is no backtrace.h >> >> I will send you a patch to try out that will only use libunwind if it >> finds both the header file and the symbols. > > Please let me know if the attached patch solves your problem. > > ==rob > > > _______________________________________________ > 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] Error buildingmpich-master-v3.2-88-gbbb40df74d46
by Siegmar Gross 15 Jan '16

15 Jan '16

Hi Halim, hi Rob, I've checked out version 77592165aa3, but at the moment I cannot use it, because we have only libtool-2.4.2 and you need at least libtool-2.4.4 so that autogen.sh failed. Our admin tries to install the latest versions of all necessary tools. I don't know if he succeeds today, because his working hours are over in 45 minutes. I'll try as soon as possible. Best regards Siegmar On 01/14/16 17:33, Halim Amer wrote: > you can check out that version from our git repo: > git clone http://git.mpich.org/mpich.git > cd mpich > git checkout 77592165aa3 > > --Halim > www.mcs.anl.gov/~aamer > > On 1/14/16 9:52 AM, Siegmar Gross wrote: >> Hi, >> >> where can I find "version 77592165aa3"? I have only the following >> archives after the release of mpich-3.2.tar.gz. >> >> loki mpich-3.2.1 113 ls -C1 *.gz >> mpich-master-v3.2-42-g67631a5c0e9e.tar.gz >> mpich-master-v3.2-87-g7150bbc02ec8.tar.gz >> mpich-master-v3.2-88-gbbb40df74d46.tar.gz >> >> I've attached both config.log files from my gcc and cc version. >> >> I've searched for "libunwind tools" for our Linux version. It seems that >> they are available for "Suse Linux Enterprise Server", but I didn't find >> them for "Suse Linux Enterprise Desktop", which we use for most of our >> machines. Shall I ask our Admin to install them? >> >> >> Best regards >> >> Siegmar >> >> >> On 01/14/16 16:25, Rob Latham wrote: >>> >>> >>> On 01/14/2016 07:21 AM, Siegmar Gross wrote: >>>> Hi, >>>> >>>> today I tried to build mpich-master-v3.2-88-gbbb40df74d46 on my machine >>>> (SUSE Linux Enterprise Server 12.0 x86_64) with gcc-5.2.0 and Sun C >>>> 5.13. >>>> I used the following command to build the system for gcc. >>> >>> This looks like the "portable backtrace" functionality I added >>> recently. Maybe I need to work on the "portable" part >>> of that. >>> >>> MPICH thinks your environment has the libunwind tools, and so it is >>> trying to use libunwind to display the backtrace. >>> >>> Unfortunately there's one more complication: a reorganization of the >>> MPL sources (commit 12c912ec6372). >>> >>> If you can provide me with two pieces of information that would be great: >>> >>> - what if you check out MPICH from a few weeks back? I want to rule >>> out the source reorg, and if you check out version >>> 77592165aa3, that will have just my changes and none of the reorg >>> changes. >>> >>> - Can you send me your src/mpl/config.log ? (not the config.log from >>> top-level mpich, but the config.log subconfigure >>> from src/mpl) I would like to see what backtrace libraries configure >>> found in your environment. Then I can reproduce >>> it on my end. >>> >>> ==rob >>> >>>> >>>> mkdir >>>> mpich-master-v3.2-88-gbbb40df74d46-${SYSTEM_ENV}.${MACHINE_ENV}.64_gcc >>>> cd >>>> mpich-master-v3.2-88-gbbb40df74d46-${SYSTEM_ENV}.${MACHINE_ENV}.64_gcc >>>> >>>> ../mpich-master-v3.2-88-gbbb40df74d46/configure \ >>>> --prefix=/usr/local/mpich-3.2.1_64_gcc \ >>>> --libdir=/usr/local/mpich-3.2.1_64_gcc/lib64 \ >>>> --includedir=/usr/local/mpich-3.2.1_64_gcc/include64 \ >>>> CC="gcc" CXX="g++" F77="gfortran" FC="gfortran" \ >>>> CFLAGS="-m64 -z noexecstack" CXXFLAGS="-m64" FFLAGS="-m64" >>>> FCFLAGS="-m64" \ >>>> LDFLAGS="-m64" \ >>>> --enable-fortran=yes --enable-cxx --enable-romio \ >>>> --enable-debuginfo --enable-smpcoll \ >>>> --enable-threads=multiple --with-thread-package=posix \ >>>> --enable-shared \ >>>> |& tee log.configure.$SYSTEM_ENV.$MACHINE_ENV.64_gcc >>>> >>>> make |& tee log.make.$SYSTEM_ENV.$MACHINE_ENV.64_gcc >>>> >>>> >>>> "make" broke with the following error for "cc". >>>> >>>> loki mpich-master-v3.2-88-gbbb40df74d46-Linux.x86_64.64_cc 111 cat >>>> log.make.Linux.x86_64.64_cc >>>> if test ! -h ./src/include/mpio.h ; then \ >>>> rm -f ./src/include/mpio.h ; \ >>>> ( cd ./src/include && \ >>>> ln -s ../mpi/romio/include/mpio.h ) ; \ >>>> fi >>>> make all-recursive >>>> make[1]: Entering directory >>>> '/export2/src/mpich-3.2.1/mpich-master-v3.2-88-gbbb40df74d46-Linux.x86_64.64_cc' >>>> >>>> >>>> Making all in >>>> /export2/src/mpich-3.2.1/mpich-master-v3.2-88-gbbb40df74d46-Linux.x86_64.64_cc/src/mpl >>>> >>>> >>>> make[2]: Entering directory >>>> '/export2/src/mpich-3.2.1/mpich-master-v3.2-88-gbbb40df74d46-Linux.x86_64.64_cc/src/mpl' >>>> >>>> >>>> CC src/bt/mpl_bt.lo >>>> "../../../mpich-master-v3.2-88-gbbb40df74d46/src/mpl/src/bt/mpl_bt.c", >>>> line 50: undefined symbol: unw_cursor_t >>>> "../../../mpich-master-v3.2-88-gbbb40df74d46/src/mpl/src/bt/mpl_bt.c", >>>> line 50: syntax error before or at: cursor >>>> "../../../mpich-master-v3.2-88-gbbb40df74d46/src/mpl/src/bt/mpl_bt.c", >>>> line 51: undefined symbol: unw_context_t >>>> "../../../mpich-master-v3.2-88-gbbb40df74d46/src/mpl/src/bt/mpl_bt.c", >>>> line 52: undefined symbol: unw_word_t >>>> "../../../mpich-master-v3.2-88-gbbb40df74d46/src/mpl/src/bt/mpl_bt.c", >>>> line 57: warning: implicit function declaration: unw_getcontext >>>> "../../../mpich-master-v3.2-88-gbbb40df74d46/src/mpl/src/bt/mpl_bt.c", >>>> line 57: undefined symbol: uc >>>> "../../../mpich-master-v3.2-88-gbbb40df74d46/src/mpl/src/bt/mpl_bt.c", >>>> line 58: warning: implicit function declaration: unw_init_local >>>> "../../../mpich-master-v3.2-88-gbbb40df74d46/src/mpl/src/bt/mpl_bt.c", >>>> line 58: undefined symbol: cursor >>>> "../../../mpich-master-v3.2-88-gbbb40df74d46/src/mpl/src/bt/mpl_bt.c", >>>> line 59: warning: implicit function declaration: unw_step >>>> "../../../mpich-master-v3.2-88-gbbb40df74d46/src/mpl/src/bt/mpl_bt.c", >>>> line 60: warning: implicit function declaration: unw_get_reg >>>> "../../../mpich-master-v3.2-88-gbbb40df74d46/src/mpl/src/bt/mpl_bt.c", >>>> line 60: undefined symbol: UNW_REG_IP >>>> "../../../mpich-master-v3.2-88-gbbb40df74d46/src/mpl/src/bt/mpl_bt.c", >>>> line 60: undefined symbol: ip >>>> "../../../mpich-master-v3.2-88-gbbb40df74d46/src/mpl/src/bt/mpl_bt.c", >>>> line 61: warning: implicit function declaration: unw_get_proc_name >>>> "../../../mpich-master-v3.2-88-gbbb40df74d46/src/mpl/src/bt/mpl_bt.c", >>>> line 62: undefined symbol: offset >>>> cc: acomp failed for >>>> ../../../mpich-master-v3.2-88-gbbb40df74d46/src/mpl/src/bt/mpl_bt.c >>>> Makefile:923: recipe for target 'src/bt/mpl_bt.lo' failed >>>> make[2]: *** [src/bt/mpl_bt.lo] Error 1 >>>> make[2]: Leaving directory >>>> '/export2/src/mpich-3.2.1/mpich-master-v3.2-88-gbbb40df74d46-Linux.x86_64.64_cc/src/mpl' >>>> >>>> >>>> Makefile:38434: recipe for target 'all-recursive' failed >>>> make[1]: *** [all-recursive] Error 1 >>>> make[1]: Leaving directory >>>> '/export2/src/mpich-3.2.1/mpich-master-v3.2-88-gbbb40df74d46-Linux.x86_64.64_cc' >>>> >>>> >>>> Makefile:10304: recipe for target 'all' failed >>>> make: *** [all] Error 2 >>>> loki mpich-master-v3.2-88-gbbb40df74d46-Linux.x86_64.64_cc 112 >>>> >>>> >>>> >>>> "make" broke with the following error for "gcc". >>>> >>>> loki mpich-master-v3.2-88-gbbb40df74d46-Linux.x86_64.64_gcc 114 cat >>>> log.make.Linux.x86_64.64_gcc >>>> if test ! -h ./src/include/mpio.h ; then \ >>>> rm -f ./src/include/mpio.h ; \ >>>> ( cd ./src/include && \ >>>> ln -s ../mpi/romio/include/mpio.h ) ; \ >>>> fi >>>> make all-recursive >>>> make[1]: Entering directory >>>> '/export2/src/mpich-3.2.1/mpich-master-v3.2-88-gbbb40df74d46-Linux.x86_64.64_gcc' >>>> >>>> >>>> Making all in >>>> /export2/src/mpich-3.2.1/mpich-master-v3.2-88-gbbb40df74d46-Linux.x86_64.64_gcc/src/mpl >>>> >>>> >>>> make[2]: Entering directory >>>> '/export2/src/mpich-3.2.1/mpich-master-v3.2-88-gbbb40df74d46-Linux.x86_64.64_gcc/src/mpl' >>>> >>>> >>>> CC src/bt/mpl_bt.lo >>>> ../../../mpich-master-v3.2-88-gbbb40df74d46/src/mpl/src/bt/mpl_bt.c: In >>>> function ‘backtrace_libunwind’: >>>> ../../../mpich-master-v3.2-88-gbbb40df74d46/src/mpl/src/bt/mpl_bt.c:50:5: >>>> error: >>>> unknown type name ‘unw_cursor_t’ >>>> unw_cursor_t cursor; >>>> ^ >>>> ../../../mpich-master-v3.2-88-gbbb40df74d46/src/mpl/src/bt/mpl_bt.c:51:5: >>>> error: >>>> unknown type name ‘unw_context_t’ >>>> unw_context_t uc; >>>> ^ >>>> ../../../mpich-master-v3.2-88-gbbb40df74d46/src/mpl/src/bt/mpl_bt.c:52:5: >>>> error: >>>> unknown type name ‘unw_word_t’ >>>> unw_word_t ip, offset; >>>> ^ >>>> ../../../mpich-master-v3.2-88-gbbb40df74d46/src/mpl/src/bt/mpl_bt.c:57:5: >>>> warning: >>>> implicit declaration of function ‘unw_getcontext’ >>>> [-Wimplicit-function-declaration] >>>> unw_getcontext(&uc); >>>> ^ >>>> ../../../mpich-master-v3.2-88-gbbb40df74d46/src/mpl/src/bt/mpl_bt.c:58:5: >>>> warning: >>>> implicit declaration of function ‘unw_init_local’ >>>> [-Wimplicit-function-declaration] >>>> unw_init_local(&cursor, &uc); >>>> ^ >>>> ../../../mpich-master-v3.2-88-gbbb40df74d46/src/mpl/src/bt/mpl_bt.c:59:12: >>>> >>>> warning: implicit declaration of function ‘unw_step’ >>>> [-Wimplicit-function-declaration] >>>> while (unw_step(&cursor) > 0) { >>>> ^ >>>> ../../../mpich-master-v3.2-88-gbbb40df74d46/src/mpl/src/bt/mpl_bt.c:60:9: >>>> warning: >>>> implicit declaration of function ‘unw_get_reg’ >>>> [-Wimplicit-function-declaration] >>>> unw_get_reg(&cursor, UNW_REG_IP, &ip); >>>> ^ >>>> ../../../mpich-master-v3.2-88-gbbb40df74d46/src/mpl/src/bt/mpl_bt.c:60:30: >>>> >>>> error: ‘UNW_REG_IP’ undeclared (first use in this function) >>>> unw_get_reg(&cursor, UNW_REG_IP, &ip); >>>> ^ >>>> ../../../mpich-master-v3.2-88-gbbb40df74d46/src/mpl/src/bt/mpl_bt.c:60:30: >>>> >>>> note: each undeclared identifier is reported only once for each function >>>> it appears in >>>> ../../../mpich-master-v3.2-88-gbbb40df74d46/src/mpl/src/bt/mpl_bt.c:61:9: >>>> warning: >>>> implicit declaration of function ‘unw_get_proc_name’ >>>> [-Wimplicit-function-declaration] >>>> unw_get_proc_name(&cursor, buffer, >>>> ^ >>>> Makefile:920: recipe for target 'src/bt/mpl_bt.lo' failed >>>> make[2]: *** [src/bt/mpl_bt.lo] Error 1 >>>> make[2]: Leaving directory >>>> '/export2/src/mpich-3.2.1/mpich-master-v3.2-88-gbbb40df74d46-Linux.x86_64.64_gcc/src/mpl' >>>> >>>> >>>> Makefile:38434: recipe for target 'all-recursive' failed >>>> make[1]: *** [all-recursive] Error 1 >>>> make[1]: Leaving directory >>>> '/export2/src/mpich-3.2.1/mpich-master-v3.2-88-gbbb40df74d46-Linux.x86_64.64_gcc' >>>> >>>> >>>> Makefile:10304: recipe for target 'all' failed >>>> make: *** [all] Error 2 >>>> loki mpich-master-v3.2-88-gbbb40df74d46-Linux.x86_64.64_gcc 114 >>>> >>>> >>>> >>>> I would be grateful if somebody can fix the problem. Thank you very >>>> much for any help in advance. >>>> >>>> >>>> Kind regards >>>> >>>> Siegmar >>>> _______________________________________________ >>>> discuss mailing list discuss(a)mpich.org >>>> To manage subscription options or unsubscribe: >>>> https://lists.mpich.org/mailman/listinfo/discuss >>> _______________________________________________ >>> discuss mailing list discuss(a)mpich.org >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/discuss >> >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] MPI_T_pvar interface
by Balaji, Pavan 14 Jan '16

14 Jan '16

Here's the implementation status slide: http://meetings.mpi-forum.org/mpi31-impl-status-Nov15.pdf -- Pavan > On Jan 14, 2016, at 6:34 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > > I recall from the most recent slide deck reporting on the status of MPI implementations (I think Pavan posted it on the MPI Forum list around SC15 timeframe) that Blue Gene/Q MPI has a no-op MPI_T implementation, which is to say, they expose zero pvars. > > Jeff > > On Thu, Jan 14, 2016 at 3:25 PM, Daniel Ibanez <dan.a.ibanez(a)gmail.com> wrote: > Hello, > > I just learned about the performance variable > interface and was hoping to try it out. > However, I've tried a recent MPICH build from > source on a workstation and the older MPI > install on our IBM BlueGene/Q, both of which > show zero performance variables. > In particular, > > MPI_T_pvar_get_num > > returns zero. > Is there something I need to do to get this working > or should I turn to a different source to get such > performance information ? > > Many Thanks, > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > > > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] MPI_T_pvar interface
by Jeff Hammond 14 Jan '16

14 Jan '16

I recall from the most recent slide deck reporting on the status of MPI implementations (I think Pavan posted it on the MPI Forum list around SC15 timeframe) that Blue Gene/Q MPI has a no-op MPI_T implementation, which is to say, they expose zero pvars. Jeff On Thu, Jan 14, 2016 at 3:25 PM, Daniel Ibanez <dan.a.ibanez(a)gmail.com> wrote: > Hello, > > I just learned about the performance variable > interface and was hoping to try it out. > However, I've tried a recent MPICH build from > source on a workstation and the older MPI > install on our IBM BlueGene/Q, both of which > show zero performance variables. > In particular, > > MPI_T_pvar_get_num > > returns zero. > Is there something I need to do to get this working > or should I turn to a different source to get such > performance information ? > > Many Thanks, > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/ _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

MPI_T_pvar interface
by Daniel Ibanez 14 Jan '16

14 Jan '16

Hello, I just learned about the performance variable interface and was hoping to try it out. However, I've tried a recent MPICH build from source on a workstation and the older MPI install on our IBM BlueGene/Q, both of which show zero performance variables. In particular, MPI_T_pvar_get_num returns zero. Is there something I need to do to get this working or should I turn to a different source to get such performance information ? Many Thanks, _______________________________________________ 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] Creating an MPI job using MPI_Comm_connect/accept
by Mohammad Javad Rashti 14 Jan '16

14 Jan '16

Sangmin, MPICH 3.2 worked well and does not seem to have this issue. Thank you On Tue, Jan 5, 2016 at 10:56 AM, Mohammad Javad Rashti <mjrashti(a)gmail.com> wrote: > Thanks Sangmin, sure, I will check it out. > > On Tue, Jan 5, 2016 at 10:47 AM, Seo, Sangmin <sseo(a)anl.gov> wrote: > >> Hi Mohammad, >> >> I was wrong in my answer. The same issue was discussed last year, and the >> problem was fixed after mpich-3.1.3. Please refer >> http://lists.mpich.org/pipermail/discuss/2015-January/003660.html >> >> Can you try your code with a recent version of mpich? >> >> Regards, >> Sangmin >> >> >> On Jan 4, 2016, at 8:09 PM, Seo, Sangmin <sseo(a)anl.gov> wrote: >> >> Hi Mohammad, >> >> It seems the same port name can be used only once, since the MPI 3.1 >> standard (p. 419, line 31) says "A port name may be reused after it is >> freed with MPI_CLOSE_PORT and released by the system.” Can you try close >> the port and open it again to establish a new connection? If it doesn’t >> work, could you send us your actual code (if possible, please send us a >> simplified version of your code)? >> >> Regards, >> Sangmin >> >> >> On Dec 29, 2015, at 11:44 AM, Mohammad Javad Rashti <mjrashti(a)gmail.com> >> wrote: >> >> Hi, >> Using mpich-3.1.2, we are trying to create a multi-process multi-node MPI >> job with the client-server model but we are having issues creating the >> global communicator we need. >> >> We cannot use mpiexec to launch the MPI processes; they are launched by a >> different daemon and we want them to join a group and use MPI after they >> are launched. >> We chose to use a server to publish a name/port and wait on a known >> number of clients to connect. The goal is to create an intracommunicator >> among all the clients and the server, and start normal MPI communication >> (not sure whether there is a better way to accomplish this goal?). >> >> *The problem *is that the first client connects fine, but the subsequent >> clients block. >> >> The *simplified method *that we are using is here: >> >> * ------------------- Server -----------------* >> >> - Call *MPI_Open_port(MPI_INFO_NULL, port_name)* >> >> - Call *MPI_Publish_name(service_name, MPI_INFO_NULL, port_name)* >> >> - clients = 0 >> >> Loop until clients = MAX_CLIENTS: >> >> if ( !clients ) >> - Call >> *MPI_Comm_accept(port_name,MPI_INFO_NULL,0,MPI_COMM_FELF,&new_ircomm)* >> >> else >> - Call >> *MPI_Comm_accept(port_name,MPI_INFO_NULL,0,previous_iacomm,&new_ircomm)* >> >> - Call *MPI_Intercomm_merge(new_ircomm, 0, &new_iacomm)* >> >> - previous_iacomm = new_iacomm >> >> - clients ++ >> >> end Loop >> >> *---------------- Client ---------------* >> >> - Call *MPI_Lookup_name(service_name, MPI_INFO_NULL, port_name)* >> >> - Call *MPI_Comm_connect(port_name, MPI_INFO_NULL, 0, MPI_COMM_SELF, >> &new_ircomm)* >> >> - Call *MPI_Intercomm_merge(new_ircomm, 1 , &new_iacomm)* >> >> - previous_iacomm *= *new_iacomm >> >> Loop for all clients connecting after me: >> >> - Call >> *MPI_Comm_accept(port_name,MPI_INFO_NULL,0,previous_iacomm,&new_ircomm)* >> >> - Call *MPI_Intercomm_merge(new_ircomm, 0, &new_iacomm)* >> >> - previous_iacomm = new_iacomm >> >> end Loop >> >> ---------------------------------- >> >> *Note *that MPI report states that MPI_Comm_accept is collective over >> the calling communicator, that's why we are calling it by the server and >> all previously connected clients. >> >> *The problem we are having *is that the first client connects fine, but >> the subsequent clients block on MPI_Comm_connect. Also the server and >> previously connected clients block on MPI_Comm_accept. >> >> (the server does not block only if we use MPI_COMM_SELF for all accept >> calls, but that does not help us creating the global intracomm that we want. >> >> I suspect that we are missing something in our usage of MPI_Comm_accept. >> Any insight is helpful and appreciated. I can send the actual C code if >> needed. >> >> Thanks >> Mohammad >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> >> >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> > > _______________________________________________ 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] How to run mpi in docker (Jeff Hammond)
by Kenneth Raffenetti 14 Jan '16

14 Jan '16

Yiyong, See info here on MPIEXEC_PORT_RANGE environment setting. https://wiki.mpich.org/mpich/index.php/Using_the_Hydra_Process_Manager#Envi… Ken On 01/05/2016 08:20 PM, Yiyong wrote: > Yes, Docker is like a VM and it has private IP address. > It can use nat to communicate with other host. > I need to map some ports of Docker to that of host machine, > then dockers in different host machines can use the ports to communicate. > > Yiyong > > > _______________________________________________ > 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] Error buildingmpich-master-v3.2-88-gbbb40df74d46
by Rob Latham 14 Jan '16

14 Jan '16

On 01/14/2016 10:39 AM, Rob Latham wrote: > > For example, our configure also found the backtrace_symbols and > backtrace_create_state functions. These are often part of GCC, or maybe > standalone in the libbacktrace package. On your system (as is common on > many systems) there is no backtrace.h > > I will send you a patch to try out that will only use libunwind if it > finds both the header file and the symbols. Please let me know if the attached patch solves your problem. ==rob

1 0

[PATCH] use libunwind only when both header and lib available
by Rob Latham 14 Jan '16

14 Jan '16

libunwind has runtime libraries and compile-time heaers. Some systems might provide libunwind without the corresponding -dev package. Be more careful about when to choose libunwind. --- src/mpl/src/bt/mpl_bt.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/src/mpl/src/bt/mpl_bt.c b/src/mpl/src/bt/mpl_bt.c index 5abd999d..ef10a59a 100644 --- a/src/mpl/src/bt/mpl_bt.c +++ b/src/mpl/src/bt/mpl_bt.c @@ -44,7 +44,11 @@ static inline void backtrace_libback(FILE *output) btstate = backtrace_create_state(NULL, 1, NULL, NULL); backtrace_print(btstate, 0, output); } -#elif defined MPL_HAVE_LIBUNWIND +/* we need not only the symbols but the header file too (for the cursor and + * context), so tighten up when we take the libunwind path. Thanks + * Siegmar.Gross(a)informatik.hs-fulda.de for the bug report about systems with + * libunwind libraries but no libunwind development headers */ +#elif defined MPL_HAVE_LIBUNWIND && defined(MPL_HAVE_LIBUNWIND_H) static inline void backtrace_libunwind(FILE *output) { unw_cursor_t cursor; @@ -118,7 +122,7 @@ void MPL_backtrace_show(FILE *output) { #ifdef MPL_HAVE_LIBBACKTRACE backtrace_libback(output); -#elif defined MPL_HAVE_LIBUNWIND +#elif defined MPL_HAVE_LIBUNWIND && defined(MPL_HAVE_LIBUNWIND_H) /* libunwind is not able to get line numbers without forking off to * addr2line (?)*/ backtrace_libunwind(output); -- 2.5.0 --------------040008040900080701010307 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss --------------040008040900080701010307--

1 0