- discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] Problem with MPICH 3.0 rc1 compilation on RHEL 5
by Yauheni Zelenko 27 Nov '12

27 Nov '12

Hi, Dave! I played with preprocessor output aand it looks like this is problem of RHEL 5.5. _FILE_OFFSET_BITS=64 forces to redirect stat/fstat to their 64 bit counterparts (with __asm__) . _LARGEFILE64_SOURCE defines stat/fstat/stat64/fstat64. So combination of both will cause redefinition of stat64/fstat64. BTW _LARGEFILE64_SOURCE and _FILE_OFFSET_BITS=64 appear twice in compiler command line. Eugene. ________________________________________ From: discuss-bounces(a)mpich.org [discuss-bounces(a)mpich.org] On Behalf Of Dave Goodell [goodell(a)mcs.anl.gov] Sent: Wednesday, November 21, 2012 10:38 AM To: discuss(a)mpich.org Subject: Re: [mpich-discuss] Problem with MPICH 3.0 rc1 compilation on RHEL 5 Hi Eugene, I was not able to reproduce this behavior on RHEL 5.8 with gcc-4.1 or gcc-4.6 (though I was able to reproduce the earlier LLONG_MAX issue). Would you please dig in here and debug a bit for us? It seems that there is something very specific about your environment and/or compiler that is causing a problem here. -Dave On Nov 20, 2012, at 7:07 PM CST, Yauheni Zelenko wrote: > Your guess is correct. Compilation is fine when only one of defines left in command line. > > You could try to install CentOS which is copy of RHEL. > > Alternatively, I could send files in questions. > > Eugene. > ________________________________________ > From: discuss-bounces(a)mpich.org [discuss-bounces(a)mpich.org] On Behalf Of Dave Goodell [goodell(a)mcs.anl.gov] > Sent: Tuesday, November 20, 2012 4:57 PM > To: discuss(a)mpich.org > Subject: Re: [mpich-discuss] Problem with MPICH 3.0 rc1 compilation on RHEL 5 > > My suspicion is that it is more likely related to the following arguments: > > ----8<---- > -D_LARGEFILE64_SOURCE > -D_FILE_OFFSET_BITS=64 > ----8<---- > > Can you try running that same gcc command from the build directory's "src/mpi/romio" directory but with omitting various combinations of the two above options? > > Reading the source of feature.h and/or stat.h would probably also help, although I do not have a RHEL5/6 system handy. > > -Dave > > On Nov 20, 2012, at 6:09 PM CST, Yauheni Zelenko wrote: > >> Hi, Dave! >> >> See attached files for make output in verbose mode and generated assembler code. >> >> Eugene. >> ________________________________________ >> From: discuss-bounces(a)mpich.org [discuss-bounces(a)mpich.org] On Behalf Of Dave Goodell [goodell(a)mcs.anl.gov] >> Sent: Tuesday, November 20, 2012 3:18 PM >> To: discuss(a)mpich.org >> Subject: Re: [mpich-discuss] Problem with MPICH 3.0 rc1 compilation on RHEL 5 >> >> It seems unlikely to me that the headers distributed in RHEL5/RHEL6 are incompatible with GCC being in C99 mode. Can you give me a little more information about what's failing? Perhaps run "make V=1 2>&1 | tee m.txt" and send m.txt as an attachment? >> >> -Dave >> >> On Nov 20, 2012, at 5:08 PM CST, Yauheni Zelenko wrote: >> >>> Hi, Dave! >>> >>> I think this is result of inlining in C99 mode. >>> >>> Eugene. >>> ________________________________________ >>> From: discuss-bounces(a)mpich.org [discuss-bounces(a)mpich.org] On Behalf Of Dave Goodell [goodell(a)mcs.anl.gov] >>> Sent: Tuesday, November 20, 2012 3:06 PM >>> To: discuss(a)mpich.org >>> Subject: Re: [mpich-discuss] Problem with MPICH 3.0 rc1 compilation on RHEL 5 >>> >>> I'm not sure I follow you on the fstat64/stat64 double-definition issue. Is this just some sort of bug in the RHEL6 headers? Is there something that we (MPICH) are doing incorrectly w.r.t. this? >>> >>> -Dave >>> >>> On Nov 14, 2012, at 5:39 PM CST, Yauheni Zelenko wrote: >>> >>>> Hi, Dave! >>>> >>>> Build failed on first compilation because fstat64 and stat64 defined twice. Likely because of these functions inlining in /usr/include/sys/stat.h. >>>> >>>> Also GCC 4.7.2 warnings on Red Hat Enterprise Linux 6: >>>> >>>> src/mpltrmem.c: In function 'MPL_trdump': >>>> src/mpltrmem.c:536:14: warning: variable 'old_head' set but not used [-Wunused-but-set-variable] >>>> src/mpi/coll/opminloc.c: In function 'MPIR_MINLOC': >>>> src/mpi/coll/opminloc.c:85:24: warning: variable 'flen' set but not used [-Wunused-but-set-variable] >>>> src/mpi/coll/opmaxloc.c: In function 'MPIR_MAXLOC': >>>> src/mpi/coll/opmaxloc.c:86:24: warning: variable 'flen' set but not used [-Wunused-but-set-variable] >>>> src/mpid/ch3/src/ch3u_rma_sync.c: In function 'MPIDI_CH3I_Recv_rma_msg': >>>> src/mpid/ch3/src/ch3u_rma_sync.c:1251:5: warning: 'mpiu_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>> src/mpid/ch3/src/mpidi_pg.c: In function 'connToString': >>>> src/mpid/ch3/src/mpidi_pg.c:972:5: warning: 'mpiu_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>> src/mpid/ch3/channels/nemesis/src/ch3_progress.c: In function 'MPIDI_CH3I_Progress': >>>> src/mpid/ch3/channels/nemesis/src/ch3_progress.c:394:21: warning: comparison between 'MPIDI_CH3_Pkt_type_t' and 'enum MPID_nem_pkt_type' [-Wenum-compare] >>>> src/mpid/ch3/channels/nemesis/src/ch3_progress.c: In function 'MPID_nem_handle_pkt': >>>> src/mpid/ch3/channels/nemesis/src/ch3_progress.c:636:17: warning: comparison between 'MPIDI_CH3_Pkt_type_t' and 'enum MPID_nem_pkt_type' [-Wenum-compare] >>>> src/mpid/ch3/channels/nemesis/src/ch3_progress.c:684:13: warning: comparison between 'MPIDI_CH3_Pkt_type_t' and 'enum MPID_nem_pkt_type' [-Wenum-compare] >>>> src/mpid/ch3/channels/nemesis/netmod/tcp/socksm.c: In function 'alloc_sc_plfd_tbls': >>>> src/mpid/ch3/channels/nemesis/netmod/tcp/socksm.c:183:5: warning: the comparison will always evaluate as 'true' for the address of 'MPID_nem_tcp_g_lstn_sc' will never be NULL [-Waddress] >>>> src/mpid/ch3/channels/nemesis/netmod/tcp/socksm.c:184:5: warning: the comparison will always evaluate as 'true' for the address of 'MPID_nem_tcp_g_lstn_plfd' will never be NULL [-Waddress] >>>> src/mpid/common/datatype/mpid_type_debug.c: In function 'MPIDI_Datatype_printf': >>>> src/mpid/common/datatype/mpid_type_debug.c:238:59: warning: variable 'sticky_ub' set but not used [-Wunused-but-set-variable] >>>> src/mpid/common/datatype/mpid_type_debug.c:238:48: warning: variable 'sticky_lb' set but not used [-Wunused-but-set-variable] >>>> src/mpid/common/datatype/mpid_type_debug.c:238:44: warning: variable 'ub' set but not used [-Wunused-but-set-variable] >>>> src/mpid/common/datatype/mpid_type_debug.c:238:31: warning: variable 'true_ub' set but not used [-Wunused-but-set-variable] >>>> src/mpid/common/datatype/mpid_type_debug.c:236:11: warning: variable 'string' set but not used [-Wunused-but-set-variable] >>>> src/mpi/coll/iallgather.c: In function 'MPIR_Iallgather_bruck': >>>> src/mpi/coll/iallgather.c:329:5: warning: 'mpir_sched_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>> src/mpi/coll/iallgather.c: In function 'MPIR_Iallgather_inter': >>>> src/mpi/coll/iallgather.c:580:5: warning: 'mpir_sched_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>> src/mpi/coll/iallgatherv.c: In function 'MPIR_Iallgatherv_rec_dbl': >>>> src/mpi/coll/iallgatherv.c:259:5: warning: 'mpir_sched_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>> src/mpi/coll/iallgatherv.c: In function 'MPIR_Iallgatherv_bruck': >>>> src/mpi/coll/iallgatherv.c:398:5: warning: 'mpir_sched_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>> src/mpi/coll/iallreduce.c: In function 'MPIR_Iallreduce_redscat_allgather': >>>> src/mpi/coll/iallreduce.c:282:5: warning: 'mpir_sched_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>> src/mpi/coll/iallreduce.c: In function 'MPIR_Iallreduce_rec_dbl': >>>> src/mpi/coll/iallreduce.c:425:5: warning: 'mpir_sched_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>> src/mpi/coll/ired_scat_block.c: In function 'MPIR_Ireduce_scatter_block_inter': >>>> src/mpi/coll/ired_scat_block.c:899:5: warning: 'mpir_sched_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>> src/mpi/coll/ireduce.c: In function 'MPIR_Ireduce_SMP': >>>> src/mpi/coll/ireduce.c:677:5: warning: 'mpir_sched_chkpmem_stk_[0]' may be used uninitialized in this function [-Wmaybe-uninitialized] >>>> >>>> Eugene. >>>> ________________________________________ >>>> From: discuss-bounces(a)mpich.org [discuss-bounces(a)mpich.org] On Behalf Of Dave Goodell [goodell(a)mcs.anl.gov] >>>> Sent: Wednesday, November 14, 2012 2:46 PM >>>> To: discuss(a)mpich.org >>>> Subject: Re: [mpich-discuss] Problem with MPICH 3.0 rc1 compilation on RHEL 5 >>>> >>>> This is because you have selected a bare "--enable-strict" option to configure, which defaults to c89. I'll see if there's a more pleasant way around this, but in the meantime is it acceptable for you to pass "--enable-strict=c99" instead? >>>> >>>> The problem occurs because your compiler still responds to the "long long" type but disables the "LLONG_MAX" constant when asked for c89 mode. >>>> >>>> -Dave >>>> >>>> On Nov 14, 2012, at 4:14 PM CST, Yauheni Zelenko wrote: >>>> >>>>> Hi! >>>>> >>>>> I'm trying to compile MPICH 3.0 rc1 on Red Hat Enterprise Linux 5 and compilation failed because of undefined LLONG_MAX. >>>>> >>>>> LLONG_MAX definition in /usr/include/limits.h is depend on C99 condition. -std=c89 is passed to GCC. >>>>> >>>>> My configure options: >>>>> >>>>> ./configure --prefix=${InstallDir} \ >>>>> --with-pm=hydra --with-device=ch3:nemesis \ >>>>> --disable-chekpointing \ >>>>> --enable-strict --enable-fast=O3 \ >>>>> --disable-f77 --disable-fc \ >>>>> CC=/grid/common/pkgs/gcc/v4.4.5/bin/gcc CFLAGS="-m32 -fPIC" \ >>>>> CPP=/grid/common/pkgs/gcc/v4.4.5/bin/cpp \ >>>>> CXX=/grid/common/pkgs/gcc/v4.4.5/bin/g++ CXXFLAGS="-m32 -fPIC" \ >>>>> CXXCPP=/grid/common/pkgs/gcc/v4.4.5/bin/cpp >>>>> >>>>> GCC 4.4.5 is also produce next warnings: >>>>> >>>>> mpi-io/write.c: In function 'MPIOI_File_write': >>>>> mpi-io/write.c:126: warning: passing argument 1 of 'MPIU_external32_buffer_setup' discards qualifiers from pointer target type >>>>> ./adio/include/mpiu_external32.h:20: note: expected 'void *' but argument is of type 'const void *' >>>>> mpi-io/write_all.c: In function 'MPIOI_File_write_all': >>>>> mpi-io/write_all.c:109: warning: passing argument 1 of 'MPIU_external32_buffer_setup' discards qualifiers from pointer target type >>>>> ./adio/include/mpiu_external32.h:20: note: expected 'void *' but argument is of type 'const void *' >>>>> mpi-io/write_allb.c: In function 'MPIOI_File_write_all_begin': >>>>> mpi-io/write_allb.c:105: warning: passing argument 1 of 'MPIU_external32_buffer_setup' discards qualifiers from pointer target type >>>>> ./adio/include/mpiu_external32.h:20: note: expected 'void *' but argument is of type 'const void *' >>>>> mpi-io/write_ord.c: In function 'PMPI_File_write_ordered': >>>>> mpi-io/write_ord.c:98: warning: assignment discards qualifiers from pointer target type >>>>> mpi-io/write_ord.c:100: warning: passing argument 1 of 'MPIU_external32_buffer_setup' discards qualifiers from pointer target type >>>>> ./adio/include/mpiu_external32.h:20: note: expected 'void *' but argument is of type 'const void *' >>>>> mpi-io/write_ordb.c: In function 'PMPI_File_write_ordered_begin': >>>>> mpi-io/write_ordb.c:104: warning: assignment discards qualifiers from pointer target type >>>>> mpi-io/write_ordb.c:106: warning: passing argument 1 of 'MPIU_external32_buffer_setup' discards qualifiers from pointer target type >>>>> ./adio/include/mpiu_external32.h:20: note: expected 'void *' but argument is of type 'const void *' >>>>> mpi-io/write_sh.c: In function 'PMPI_File_write_shared': >>>>> mpi-io/write_sh.c:100: warning: assignment discards qualifiers from pointer target type >>>>> mpi-io/write_sh.c:102: warning: passing argument 1 of 'MPIU_external32_buffer_setup' discards qualifiers from pointer target type >>>>> ./adio/include/mpiu_external32.h:20: note: expected 'void *' but argument is of type 'const void *' >>>>> mpi-io/mpiu_external32.c: In function 'MPIU_write_external32_conversion_fn': >>>>> mpi-io/mpiu_external32.c:24: warning: implicit declaration of function 'MPIR_Datatype_iscontig' >>>>> mpi-io/mpiu_external32.c:24: warning: nested extern declaration of 'MPIR_Datatype_iscontig' >>>>> mpi-io/mpiu_external32.c: In function 'MPIU_datatype_full_size': >>>>> mpi-io/mpiu_external32.c:123: warning: unused variable 'extent' >>>>> ./pm/pmiserv/pmip_cb.c: In function 'parse_exec_params': >>>>> ./pm/pmiserv/pmip_cb.c:808: warning: null argument where non-null required (argument 1) >>>>> ./pm/pmiserv/pmip_cb.c:808: warning: null argument where non-null required (argument 1) >>>>> ./pm/pmiserv/pmip_cb.c:808: warning: null argument where non-null required (argument 2) >>>>> ./pm/pmiserv/pmip_cb.c:808: warning: null argument where non-null required (argument 2) >>>>> src/mpi/datatype/status_set_elements.c: In function 'PMPI_Status_set_elements': >>>>> src/mpi/datatype/status_set_elements.c:54: warning: unused variable 'size' >>>>> src/mpi/datatype/status_set_elements_x.c: In function 'MPIR_Status_set_elements_x_impl': >>>>> src/mpi/datatype/status_set_elements_x.c:41: error: 'LLONG_MAX' undeclared (first use in this function) >>>>> src/mpi/datatype/status_set_elements_x.c:41: error: (Each undeclared identifier is reported only once >>>>> src/mpi/datatype/status_set_elements_x.c:41: error: for each function it appears in.) >>>>> >>>>> Eugene. >>>>> _______________________________________________ >>>>> 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 >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> <make><close.s>_______________________________________________ >> 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] MPICH2 for Win: Topology functions
by Alejandro Allievi 27 Nov '12

27 Nov '12

Hi Rajeev, Thanks for the reply. Found the culprit: a function declaration within "main". Program works fine when I move it out of main, don't know why though. Alejandro On Tue, Nov 27, 2012 at 4:01 PM, Rajeev Thakur <thakur(a)mcs.anl.gov> wrote: > Can you send us a small standalone test program that demonstrates the error? > > Rajeev > > On Nov 27, 2012, at 7:27 AM, Alejandro Allievi wrote: > >> Hi, >> >> I'm setting up a grid topology and associated communicator using the >> function Setup_grid below. It works fine for process zero but throws: >> >> Fatal error in PMPI_Comm_rank: Invalid communicator, error stack: >> PMPI_Comm_rank(109): MPI_Comm_rank(MPI_COMM_NULL, rank=000000000022FE4C) failed >> PMPI_Comm_rank(66).: Null communicator >> >> Does MPICH2 for Win7 support topology functions??? >> >> Thanks for any help. >> >> Alejandro >> >> ************CODE BELOW*************************** >> void Setup_grid(GRID_INFO_T* grid /* out */) { >> int old_rank; >> int dimensions[2]; >> int wrap_around[2]; >> int coordinates[2]; >> int free_coords[2]; >> >> >> /* Set up Global Grid Information */ >> MPI_Comm_size(MPI_COMM_WORLD, &(grid->p)); >> MPI_Comm_rank(MPI_COMM_WORLD, &old_rank); >> >> printf("Process %d of %d inside Setup_Grid\n", old_rank, grid->p); >> >> /* We assume p is a perfect square */ >> grid->q = (int) sqrt((double) grid->p); >> dimensions[0] = dimensions[1] = grid->q; >> >> /* We want a circular shift in second dimension. */ >> /* Don't care about first */ >> wrap_around[0] = wrap_around[1] = 1; >> MPI_Cart_create(MPI_COMM_WORLD, 2, dimensions, >> wrap_around, 1, &(grid->comm)); >> >> MPI_Comm_rank(grid->comm, &(grid->my_rank)); >> MPI_Cart_coords(grid->comm, grid->my_rank, 2, coordinates); >> grid->my_row = coordinates[0]; >> grid->my_col = coordinates[1]; >> >> /* Set up row communicators */ >> free_coords[0] = 0; >> free_coords[1] = 1; >> MPI_Cart_sub(grid->comm, free_coords, &(grid->row_comm)); >> >> /* Set up column communicators */ >> free_coords[0] = 1; >> free_coords[1] = 0; >> MPI_Cart_sub(grid->comm, free_coords, &(grid->col_comm)); >> >> printf("Process %d leaving Setup_Grid\n", old_rank); >> >> } /* Setup_grid */ >> >> -- >> Alejandro Allievi >> http://www.ace-net.ca/wiki/Alejandro_Allievi >> >> "Tenez, mon ami, si vous y pensez bien, vous trouverez qu'en tout, >> notre véritable sentiment n'est pas celui dans lequel nous n'avons >> jamais vacillé; mais celui auquel nous sommes le plus habituellement >> revenus". Denis Diderot. >> >> Este e-mail esta consignado sólo para el destinatario designado en el >> mismo y puede contener información confidencial y privilegiada. Su >> distribución o copiado está prohibido. Si Usted no fuera el >> destinatario designado, por favor notifíquenos de inmediato y destruya >> este e-mail en forma permanente así como todas las copias del mismo. >> Ce courriel peut renfermer des renseignements confidentiels et >> privilégiés et s'adresse au destinataire désigné seulement. La >> distribution ou la copie de ce courriel est interdit. Si vous n'êtes >> pas le destinataire désigné, veuillez nous en aviser immédiatement et >> détruire de façon permanente ce courriel ainsi que toute copie de >> celui-ci. This e-mail may contain confidential information, and is >> intended only for the named recipient and may be privileged. >> Distribution or copying of this email is prohibited. If you are not >> the named recipient, please notify us immediately and permanently >> destroy this email and all copies of it. >> _______________________________________________ >> 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 -- Alejandro Allievi http://www.ace-net.ca/wiki/Alejandro_Allievi "Tenez, mon ami, si vous y pensez bien, vous trouverez qu'en tout, notre véritable sentiment n'est pas celui dans lequel nous n'avons jamais vacillé; mais celui auquel nous sommes le plus habituellement revenus". Denis Diderot. Este e-mail esta consignado sólo para el destinatario designado en el mismo y puede contener información confidencial y privilegiada. Su distribución o copiado está prohibido. Si Usted no fuera el destinatario designado, por favor notifíquenos de inmediato y destruya este e-mail en forma permanente así como todas las copias del mismo. Ce courriel peut renfermer des renseignements confidentiels et privilégiés et s'adresse au destinataire désigné seulement. La distribution ou la copie de ce courriel est interdit. Si vous n'êtes pas le destinataire désigné, veuillez nous en aviser immédiatement et détruire de façon permanente ce courriel ainsi que toute copie de celui-ci. This e-mail may contain confidential information, and is intended only for the named recipient and may be privileged. Distribution or copying of this email is prohibited. If you are not the named recipient, please notify us immediately and permanently destroy this email and all copies of it.

1 0

Re: [mpich-discuss] MPICH2 for Win: Topology functions
by Rajeev Thakur 27 Nov '12

27 Nov '12

Can you send us a small standalone test program that demonstrates the error? Rajeev On Nov 27, 2012, at 7:27 AM, Alejandro Allievi wrote: > Hi, > > I'm setting up a grid topology and associated communicator using the > function Setup_grid below. It works fine for process zero but throws: > > Fatal error in PMPI_Comm_rank: Invalid communicator, error stack: > PMPI_Comm_rank(109): MPI_Comm_rank(MPI_COMM_NULL, rank=000000000022FE4C) failed > PMPI_Comm_rank(66).: Null communicator > > Does MPICH2 for Win7 support topology functions??? > > Thanks for any help. > > Alejandro > > ************CODE BELOW*************************** > void Setup_grid(GRID_INFO_T* grid /* out */) { > int old_rank; > int dimensions[2]; > int wrap_around[2]; > int coordinates[2]; > int free_coords[2]; > > > /* Set up Global Grid Information */ > MPI_Comm_size(MPI_COMM_WORLD, &(grid->p)); > MPI_Comm_rank(MPI_COMM_WORLD, &old_rank); > > printf("Process %d of %d inside Setup_Grid\n", old_rank, grid->p); > > /* We assume p is a perfect square */ > grid->q = (int) sqrt((double) grid->p); > dimensions[0] = dimensions[1] = grid->q; > > /* We want a circular shift in second dimension. */ > /* Don't care about first */ > wrap_around[0] = wrap_around[1] = 1; > MPI_Cart_create(MPI_COMM_WORLD, 2, dimensions, > wrap_around, 1, &(grid->comm)); > > MPI_Comm_rank(grid->comm, &(grid->my_rank)); > MPI_Cart_coords(grid->comm, grid->my_rank, 2, coordinates); > grid->my_row = coordinates[0]; > grid->my_col = coordinates[1]; > > /* Set up row communicators */ > free_coords[0] = 0; > free_coords[1] = 1; > MPI_Cart_sub(grid->comm, free_coords, &(grid->row_comm)); > > /* Set up column communicators */ > free_coords[0] = 1; > free_coords[1] = 0; > MPI_Cart_sub(grid->comm, free_coords, &(grid->col_comm)); > > printf("Process %d leaving Setup_Grid\n", old_rank); > > } /* Setup_grid */ > > -- > Alejandro Allievi > http://www.ace-net.ca/wiki/Alejandro_Allievi > > "Tenez, mon ami, si vous y pensez bien, vous trouverez qu'en tout, > notre véritable sentiment n'est pas celui dans lequel nous n'avons > jamais vacillé; mais celui auquel nous sommes le plus habituellement > revenus". Denis Diderot. > > Este e-mail esta consignado sólo para el destinatario designado en el > mismo y puede contener información confidencial y privilegiada. Su > distribución o copiado está prohibido. Si Usted no fuera el > destinatario designado, por favor notifíquenos de inmediato y destruya > este e-mail en forma permanente así como todas las copias del mismo. > Ce courriel peut renfermer des renseignements confidentiels et > privilégiés et s'adresse au destinataire désigné seulement. La > distribution ou la copie de ce courriel est interdit. Si vous n'êtes > pas le destinataire désigné, veuillez nous en aviser immédiatement et > détruire de façon permanente ce courriel ainsi que toute copie de > celui-ci. This e-mail may contain confidential information, and is > intended only for the named recipient and may be privileged. > Distribution or copying of this email is prohibited. If you are not > the named recipient, please notify us immediately and permanently > destroy this email and all copies of it. > _______________________________________________ > 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] Mpich2's behavior when too many messages are sent
by Matthieu Dorier 27 Nov '12

27 Nov '12

Thank you both for your answer! Matthieu ----- Mail original ----- > De: "Darius Buntinas" <buntinas(a)mcs.anl.gov> > À: discuss(a)mpich.org > Envoyé: Mardi 27 Novembre 2012 15:49:15 > Objet: Re: [mpich-discuss] Mpich2's behavior when too many messages are sent > > The MPI standard allows an implementation to run out of resources, so > MPICH is compliant here :-). As Jeff mentioned it is a "quality of > implementation" issue and some implementations might be able to > handle it better than others. Simply queuing the sends on the > sender side can lead to deadlocks, so something trickier is needed > (imagine that the receiver posts a blocking receive with tag A > followed by a million receives with tag B, and the sender sends a > million messages with tag B then one message with tag A. If we > queue the messages at the sender, the receiver will never receive > the message with tag A and the program deadlocks). > > We've seen such "flow-control" problems before (some in out test > suite), and generally the solution is to add some sort of > synchronization in the application, e.g., to an Ssend (or Issend so > long as you wait on the requests often enough) once in a while to > let the receiver catch up. > > -d > > On Nov 27, 2012, at 2:50 AM, Matthieu Dorier wrote: > > > Hello, > > > > I have a program that include two processes, one is doing a lot of > > MPI_Isend, the other one loops, receives the messages using > > MPI_Irecv and treats them. > > I'd like to know what the MPI-2 standard says, and what Mpich2 > > does, if the first process is too fast and the second process > > cannot keep up with the number of messages sent. Is the first > > process supposed to eventually block, waiting for the messages to > > be received, or will the application crashes? > > > > Thanks > > > > Matthieu Dorier > > PhD student at ENS Cachan Brittany and IRISA > > http://people.irisa.fr/Matthieu.Dorier > > _______________________________________________ > > 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] Mpich2's behavior when too many messages are sent
by Darius Buntinas 27 Nov '12

27 Nov '12

The MPI standard allows an implementation to run out of resources, so MPICH is compliant here :-). As Jeff mentioned it is a "quality of implementation" issue and some implementations might be able to handle it better than others. Simply queuing the sends on the sender side can lead to deadlocks, so something trickier is needed (imagine that the receiver posts a blocking receive with tag A followed by a million receives with tag B, and the sender sends a million messages with tag B then one message with tag A. If we queue the messages at the sender, the receiver will never receive the message with tag A and the program deadlocks). We've seen such "flow-control" problems before (some in out test suite), and generally the solution is to add some sort of synchronization in the application, e.g., to an Ssend (or Issend so long as you wait on the requests often enough) once in a while to let the receiver catch up. -d On Nov 27, 2012, at 2:50 AM, Matthieu Dorier wrote: > Hello, > > I have a program that include two processes, one is doing a lot of MPI_Isend, the other one loops, receives the messages using MPI_Irecv and treats them. > I'd like to know what the MPI-2 standard says, and what Mpich2 does, if the first process is too fast and the second process cannot keep up with the number of messages sent. Is the first process supposed to eventually block, waiting for the messages to be received, or will the application crashes? > > Thanks > > Matthieu Dorier > PhD student at ENS Cachan Brittany and IRISA > http://people.irisa.fr/Matthieu.Dorier > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

MPICH2 for Win: Topology functions
by Alejandro Allievi 27 Nov '12

27 Nov '12

Hi, I'm setting up a grid topology and associated communicator using the function Setup_grid below. It works fine for process zero but throws: Fatal error in PMPI_Comm_rank: Invalid communicator, error stack: PMPI_Comm_rank(109): MPI_Comm_rank(MPI_COMM_NULL, rank=000000000022FE4C) failed PMPI_Comm_rank(66).: Null communicator Does MPICH2 for Win7 support topology functions??? Thanks for any help. Alejandro ************CODE BELOW*************************** void Setup_grid(GRID_INFO_T* grid /* out */) { int old_rank; int dimensions[2]; int wrap_around[2]; int coordinates[2]; int free_coords[2]; /* Set up Global Grid Information */ MPI_Comm_size(MPI_COMM_WORLD, &(grid->p)); MPI_Comm_rank(MPI_COMM_WORLD, &old_rank); printf("Process %d of %d inside Setup_Grid\n", old_rank, grid->p); /* We assume p is a perfect square */ grid->q = (int) sqrt((double) grid->p); dimensions[0] = dimensions[1] = grid->q; /* We want a circular shift in second dimension. */ /* Don't care about first */ wrap_around[0] = wrap_around[1] = 1; MPI_Cart_create(MPI_COMM_WORLD, 2, dimensions, wrap_around, 1, &(grid->comm)); MPI_Comm_rank(grid->comm, &(grid->my_rank)); MPI_Cart_coords(grid->comm, grid->my_rank, 2, coordinates); grid->my_row = coordinates[0]; grid->my_col = coordinates[1]; /* Set up row communicators */ free_coords[0] = 0; free_coords[1] = 1; MPI_Cart_sub(grid->comm, free_coords, &(grid->row_comm)); /* Set up column communicators */ free_coords[0] = 1; free_coords[1] = 0; MPI_Cart_sub(grid->comm, free_coords, &(grid->col_comm)); printf("Process %d leaving Setup_Grid\n", old_rank); } /* Setup_grid */ -- Alejandro Allievi http://www.ace-net.ca/wiki/Alejandro_Allievi "Tenez, mon ami, si vous y pensez bien, vous trouverez qu'en tout, notre véritable sentiment n'est pas celui dans lequel nous n'avons jamais vacillé; mais celui auquel nous sommes le plus habituellement revenus". Denis Diderot. Este e-mail esta consignado sólo para el destinatario designado en el mismo y puede contener información confidencial y privilegiada. Su distribución o copiado está prohibido. Si Usted no fuera el destinatario designado, por favor notifíquenos de inmediato y destruya este e-mail en forma permanente así como todas las copias del mismo. Ce courriel peut renfermer des renseignements confidentiels et privilégiés et s'adresse au destinataire désigné seulement. La distribution ou la copie de ce courriel est interdit. Si vous n'êtes pas le destinataire désigné, veuillez nous en aviser immédiatement et détruire de façon permanente ce courriel ainsi que toute copie de celui-ci. This e-mail may contain confidential information, and is intended only for the named recipient and may be privileged. Distribution or copying of this email is prohibited. If you are not the named recipient, please notify us immediately and permanently destroy this email and all copies of it.

1 0

Re: [mpich-discuss] Mpich2's behavior when too many messages are sent
by Jeff Hammond 27 Nov '12

27 Nov '12

This is a quality of implementation issue that lies outside the MPI standard. There is no requirement that an arbitrarily large number of nonblocking messages be allowed to be outstanding at one time since this is not possible with finite resources, but obviously a high-quality implementation will strive to make the allowed number as large as possible. I suspect that MPICH will let you enqueue nonblocking sends and receives until you reach resource exhaustion, i.e. run out of memory for internal state. I ran a simple test (see below) that shows you can post at least 1M messages (true for MPICH 3.0rc1 on my Macbook Pro) without any problems (although at 1M it gets a bit slow). Best, Jeff $ mpichversion MPICH Version: 3.0rc1 MPICH Release date: Mon Nov 12 10:31:40 CST 2012 MPICH Device: ch3:nemesis MPICH configure: --prefix=/opt/local --disable-dependency-tracking --disable-f77 --disable-fc --disable-silent-rules --enable-base-cache --enable-cache --enable-cxx --enable-fast=O2 --enable-shared --enable-smpcoll --includedir=/opt/local/include/mpich --with-device=ch3:nemesis --with-pm=hydra --with-thread-package=posix F90FLAGS= F90= MPICHLIB_CPPFLAGS=-I/opt/local/include --enable-timer-type=mach_absolute_time MPICH CC: /usr/bin/clang -pipe -arch x86_64 MPICH CXX: /usr/bin/clang++ -pipe -arch x86_64 -O2 MPICH F77: -pipe -m64 MPICH FC: -pipe -m64 compile with: mpicc -g -O2 -Wall outstanding.c -o outstanding.x execute with: mpiexec -n 2 ./outstanding.x 1000000 $ cat outstanding.c =========================== #include <stdio.h> #include <stdlib.h> #include <mpi.h> int main(int argc, char* argv[]) { int rank, size; MPI_Init(&argc, &argv); MPI_Comm_rank(MPI_COMM_WORLD, &rank); MPI_Comm_size(MPI_COMM_WORLD, &size); if (size<2) { printf("run on 2 or more ranks! \n"); MPI_Abort(MPI_COMM_WORLD, 1); } int n = (argc>1) ? atoi(argv[1]) : 1e6; if (rank==0) printf("attempting to call MPI_I{send,recv} %d times before completing any of them \n", n); MPI_Request * reqs = (MPI_Request*) malloc(n*sizeof(MPI_Request)); if (reqs==NULL) { printf("malloc of %ld bytes failed! \n", (long)n*sizeof(MPI_Request)); MPI_Abort(MPI_COMM_WORLD, 1); } if (rank==0) for (int i=0; i<n; i++) MPI_Irecv(NULL, 0, MPI_BYTE, 1, i, MPI_COMM_WORLD, &(reqs[i]) ); else if (rank==1) for (int i=0; i<n; i++) MPI_Isend(NULL, 0, MPI_BYTE, 0, i, MPI_COMM_WORLD, &(reqs[i]) ); if (rank==0) printf("all MPI_I{send,recv} have been posted \n"); MPI_Barrier(MPI_COMM_WORLD); MPI_Waitall(n, reqs, MPI_STATUSES_IGNORE); if (rank==0) printf("all MPI_I{send,recv} have been completed \n"); free(reqs); if (rank==0) printf("SUCCESS \n"); MPI_Finalize(); return 0; } =========================== $ mpiexec -n 2 ./outstanding.x 100 attempting to call MPI_I{send,recv} 100 times before completing any of them all MPI_I{send,recv} have been posted all MPI_I{send,recv} have been completed SUCCESS $ mpiexec -n 2 ./outstanding.x 1000 attempting to call MPI_I{send,recv} 1000 times before completing any of them all MPI_I{send,recv} have been posted all MPI_I{send,recv} have been completed SUCCESS $ mpiexec -n 2 ./outstanding.x 10000 attempting to call MPI_I{send,recv} 10000 times before completing any of them all MPI_I{send,recv} have been posted all MPI_I{send,recv} have been completed SUCCESS $ mpiexec -n 2 ./outstanding.x 100000 attempting to call MPI_I{send,recv} 100000 times before completing any of them all MPI_I{send,recv} have been posted all MPI_I{send,recv} have been completed SUCCESS $ mpiexec -n 2 ./outstanding.x 1000000 attempting to call MPI_I{send,recv} 1000000 times before completing any of them all MPI_I{send,recv} have been posted all MPI_I{send,recv} have been completed SUCCESS On Tue, Nov 27, 2012 at 3:50 AM, Matthieu Dorier <matthieu.dorier(a)irisa.fr> wrote: > Hello, > > I have a program that include two processes, one is doing a lot of > MPI_Isend, the other one loops, receives the messages using MPI_Irecv and > treats them. > I'd like to know what the MPI-2 standard says, and what Mpich2 does, if the > first process is too fast and the second process cannot keep up with the > number of messages sent. Is the first process supposed to eventually block, > waiting for the messages to be received, or will the application crashes? > > Thanks > > Matthieu Dorier > PhD student at ENS Cachan Brittany and IRISA > http://people.irisa.fr/Matthieu.Dorier > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond

1 0

Mpich2's behavior when too many messages are sent
by Matthieu Dorier 27 Nov '12

27 Nov '12

Hello, I have a program that include two processes, one is doing a lot of MPI_Isend, the other one loops, receives the messages using MPI_Irecv and treats them. I'd like to know what the MPI-2 standard says, and what Mpich2 does, if the first process is too fast and the second process cannot keep up with the number of messages sent. Is the first process supposed to eventually block, waiting for the messages to be received, or will the application crashes? Thanks Matthieu Dorier PhD student at ENS Cachan Brittany and IRISA http://people.irisa.fr/Matthieu.Dorier

1 0

Re: [mpich-discuss] Fwd: Windows and mpicc
by Jayesh Krishna 26 Nov '12

26 Nov '12

Hi, The LANG setting might be related to the unrecognized characters in the makefile. Looks like the build system is not able to find the definition for sighandler_t (usually found in signal.h). This should have been handled at configure time. You should be able to find MPICH2 configure options in the MPICH2 installers guide (http://www.mpich.org/documentation/guides/) Regards, Jayesh ----- Original Message ----- From: "John Mole" <j.mole(a)imperial.ac.uk> To: "Jayesh Krishna" <jayesh(a)mcs.anl.gov> Sent: Monday, November 26, 2012 8:54:42 AM Subject: RE: [mpich-discuss] Fwd: Windows and mpicc Hi Jayesh, The LANG environment variable refers to localisation, so is not relevant. On looking closely at the code, I found some bugs in dbxerr.c.in. I made the following changes to get it to compile: Line 406: #define SIG_HANDLER_PROTOTYPE sighandler_t Changed to: #define SIG_HANDLER_PROTOTYPE int Line 409: int sig Changed to: int sig; I am still trying to resolve the Win32 memory issue. Meanwhile, can you let me have a full list of the mpich config options please? Regards, John Mole -----Original Message----- From: Jayesh Krishna [mailto:[email protected]] Sent: 20 November 2012 14:42 To: Mole, John Cc: mpich-discuss(a)mcs.anl.gov Subject: Re: [mpich-discuss] Fwd: Windows and mpicc Hi, A google search suggests that your setting for LANG environment variable may be incorrect. Can you check what it is (Can you set it to say "LANG=C" and see if it works)? Regards, Jayesh ----- Original Message ----- From: "John Mole" <j.mole(a)imperial.ac.uk> To: "Jayesh Krishna" <jayesh(a)mcs.anl.gov> Sent: Monday, November 19, 2012 9:37:49 AM Subject: RE: [mpich-discuss] Fwd: Windows and mpicc Hi Jayesh, I have checked dbxerr.c in hex and there are no DOS characters - make output attached. I don't want to disable MPE so I need to solve this problem somehow. I will post on the Cygwin forum about the memory issue as you suggested. Regards, John Mole -----Original Message----- From: Jayesh Krishna [mailto:[email protected]] Sent: 12 November 2012 16:32 To: mpich-discuss(a)mcs.anl.gov Cc: Mole, John Subject: Re: [mpich-discuss] Fwd: Windows and mpicc Hi, Looks like you have compile time errors for mpe because of DOS characters. If you are not planning to use MPE you can disable it (Specify "--disable-mpe" during configure time). The error that stopped the build looks like a Cygwin error (Unable to allocate enough memory for the linker). I have seen these errors when packages are updated (A "rebase" sometimes solves the problem). I would recommend posting your issue on a Cygwin forum. Can you try running the build again (after disabling MPE at compile time) after you fix the Cygwin issue? Regards, Jayesh ----- Original Message ----- From: "Jayesh Krishna" <jayesh(a)mcs.anl.gov> To: mpich-discuss(a)mcs.anl.gov Sent: Friday, November 9, 2012 2:58:06 PM Subject: [mpich-discuss] Fwd: Windows and mpicc FYI ----- Forwarded Message ----- From: "John Mole" <j.mole(a)imperial.ac.uk> To: "Jayesh Krishna" <jayesh(a)mcs.anl.gov> Sent: Friday, November 9, 2012 10:25:19 AM Subject: RE: [mpich-discuss] Windows and mpicc Hi Jayesh, Thanks. I did as you suggested. On the configure stage, I had to convert all the configure-related files to change the end of line characters to UNIX rather than DOS. The Cygwin version of BASH seems to be very picky about this. Eventually I managed to persuade the ./configure to work (output attached). However, the make stage failed with various errors (output attached). I have also included a list of the environmental variables, which may be relevant. Any advice on how to proceed would be much appreciated. Regards, John Mole -----Original Message----- From: Jayesh Krishna [mailto:[email protected]] Sent: 07 November 2012 15:50 To: Mole, John Cc: mpich-discuss(a)mcs.anl.gov Subject: Re: [mpich-discuss] Windows and mpicc Hi, There are two ways to install MPICH2 on Windows - (1) Using the Windows installers (2) Downloading MPICH2 source and compiling it under Cygwin. If you install MPICH2 using the Windows msi installers mpicc is not installed (Users typically compile their programs using Visual Studio, Intel Windows compilers etc). Since you are working in the Cygwin environment please uninstall MPICH2 and download the MPICH2 source from the link below and install (configure/make/make install - like you would install software on a unix-like/cygwin system) it. Regards, Jayesh ----- Original Message ----- From: "John Mole" <j.mole(a)imperial.ac.uk> To: "Jayesh Krishna" <jayesh(a)mcs.anl.gov> Sent: Wednesday, November 7, 2012 6:49:59 AM Subject: RE: [mpich-discuss] Windows and mpicc Hi Jayesh, I have already downloaded and installed the Windows version but there is no sign of mpicc (or the Fortran equivalent) in the /bin folder hence my original query. Regards, John Mole -----Original Message----- From: Jayesh Krishna [mailto:[email protected]] Sent: 06 November 2012 15:27 To: mpich-discuss(a)mcs.anl.gov Cc: Mole, John Subject: Re: [mpich-discuss] Windows and mpicc Hi, mpicc is the compiler wrapper that is installed with MPICH2 (or an MPI library suite). You can download the source and install MPICH2 from the MPICH2 website (http://www.mcs.anl.gov/research/projects/mpich2/downloads/index.php?s=downl…) Regards, Jayesh ----- Original Message ----- From: "John Mole" <j.mole(a)imperial.ac.uk> To: mpich-discuss(a)mcs.anl.gov Sent: Monday, November 5, 2012 4:40:58 PM Subject: [mpich-discuss] Windows and mpicc I am currently porting a mathematical modelling application from Ubuntu to Windows. I am fairly new to Linux. I am mostly working in Cygwin which emulates the Linux environment in Windows. I have installed MPICH2 on Windows and have set the necessary paths. In trying to make Parmetis in Cygwin I get the error ‘mpicc not found’. So I am trying to track down mpicc. I don’t know where it comes from. Is it from GNU or MPICH or where? How do I get hold of it? I would be most grateful if someone could provide guidance. Thanks, John Mole _______________________________________________ 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 _______________________________________________ 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

1 0

Re: [mpich-discuss] FW: MPICH2 matters
by Jayesh Krishna 26 Nov '12

26 Nov '12

Hi, Do you have multiple versions of MPICH2 installed in your (user) system? MPICH2 implementation on Windows does not support installing multiple versions of the suite in the same system. Regards, Jayesh ----- Original Message ----- From: "Robert Bauer" <Robert.Bauer(a)iconplc.com> To: discuss(a)mpich.org Sent: Monday, November 26, 2012 1:20:15 AM Subject: [mpich-discuss] FW: MPICH2 matters Dear sirs: I find that in the windows environment some of the users of our software that uses MPICH2 may have more than one version of MPICH2 installed on their system. Therefore I am not aware of where the smpd.exe that is presently loaded comes from. If my software launches the incorrect mpiexec, then a version mismatch notice is given. Is there a way to enquire which version of smpd.exe is loaded at any time? smpd -version only gives the version that is closest in the PATH environment variable, and is not necessarily the one that is loaded. Robert J. Bauer, Ph.D. Vice President, Pharmacometrics, R&D ICON Development Solutions 7740 Milestone Parkway Suite 150 Hanover, MD 21076 Tel: (215) 616-6428 Mob: (925) 286-0769 Email: Robert.Bauer(a)iconplc.com Web: www.iconplc.com ICON plc made the following annotations. ------------------------------------------------------------------------------ This e-mail transmission may contain confidential or legally privileged information that is intended only for the individual or entity named in the e-mail address. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or reliance upon the contents of this e-mail is strictly prohibited. If you have received this e-mail transmission in error, please reply to the sender, so that ICON plc can arrange for proper delivery, and then please delete the message. Thank You, ICON plc South County Business Park Leopardstown Dublin 18 Ireland Registered number: 145835 _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0