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

Re: [mpich-discuss] start MPD daemons on 2 different subnets
by Pavan Balaji 17 Jan '13

17 Jan '13

Hello, You should be able to ssh to the nodes from each other. It looks like you cannot ssh between the nodes using the below IP addresses. -- Pavan On 01/17/2013 06:08 PM US Central Time, Na Zhang wrote: > Hello Dave, > > Thanks for your reply. > We followed your advice and installed Hydra on each node. > > We specify ip address in hosts file. For example: > > shell $ mpiexec ï¿½f hosts ï¿½np 2 ./app > shell $ cat hosts > 192.168.0.1 > 192.168.1.1 > > (The two node IP belongs to 2 different subnets: for example, > subnet #1 192.168.0.0/24 <http://192.168.0.0/24> and subnet #2: > 192.168.1.0/24 <http://192.168.1.0/24>) > > The error out put is > ï¿½ssh connect to host 192.168.1.1 port 22: connection time outï¿½. > > So is there a option for Hydra to solve this problem? > > Thank you! > > Sincerely, > Na Zhang > > On Fri, Jan 11, 2013 at 5:20 PM, <discuss-request(a)mpich.org > <mailto:[email protected]>> wrote: > > Send discuss mailing list submissions to > discuss(a)mpich.org <mailto:[email protected]> > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.mpich.org/mailman/listinfo/discuss > or, via email, send a message with subject or body 'help' to > discuss-request(a)mpich.org <mailto:[email protected]> > > You can reach the person managing the list at > discuss-owner(a)mpich.org <mailto:[email protected]> > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of discuss digest..." > > > Today's Topics: > > 1. Re: [PATCH] Use attribute layout_compatible for pair types > (Jed Brown) > 2. Re: [PATCH] Use attribute layout_compatible for pair types > (Dmitri Gribenko) > 3. start MPD daemons on 2 different subnets (Na Zhang) > 4. Re: start MPD daemons on 2 different subnets (Dave Goodell) > 5. Fatal error in PMPI_Reduce (Michael Colonno) > 6. Re: Fatal error in PMPI_Reduce (Pavan Balaji) > 7. Re: Fatal error in PMPI_Reduce (Pavan Balaji) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 9 Jan 2013 14:00:50 -0600 > From: Jed Brown <jedbrown(a)mcs.anl.gov <mailto:[email protected]>> > To: discuss(a)mpich.org <mailto:[email protected]> > Subject: Re: [mpich-discuss] [PATCH] Use attribute layout_compatible > for pair types > Message-ID: > > <CAM9tzSnqJHaj6wbKBdAWp5YveG+UW_OWiA768GRb1spHjn+TZw(a)mail.gmail.com > <mailto:CAM9tzSnqJHaj6wbKBdAWp5YveG%2BUW_OWiA768GRb1spHjn%[email protected]>> > Content-Type: text/plain; charset="utf-8" > > On Jan 9, 2013 12:56 PM, "Dmitri Gribenko" <gribozavr(a)gmail.com > <mailto:[email protected]>> wrote: > > > On Wed, Jan 9, 2013 at 8:19 PM, Dave Goodell <goodell(a)mcs.anl.gov > <mailto:[email protected]>> wrote: > > > Both implemented and pushed as d440abb and ac15f7a. Thanks. > > > > > > -Dave > > > > > > On Jan 1, 2013, at 11:14 PM CST, Jed Brown wrote: > > > > > >> In addition, I suggest guarding these definitions. Leaving these in > > increases the total number of symbols in an example executable linking > > PETSc by a factor of 2. (They're all read-only, but they're still > there.) > > Clang is smart enough to remove these, presumably because it > understands > > the special attributes. > > > > No, LLVM removes these not because of the attributes, but because > > these are unused. And when they are used, most of the time they don't > > have their address taken, so their value is propagated to the point > > where they are read and the constants again become unused. > > > > I don't think GCC isn't smart enough to do the same. Do you compile > > with optimization? > > > > Dmitri, as discussed in the other thread, it's smart enough, but > only when > optimization is turned on. There's no reason to needlessly make debug > builds heavier than necessary. This is not a big deal either way. >

1 0

Re: [mpich-discuss] start MPD daemons on 2 different subnets
by Na Zhang 17 Jan '13

17 Jan '13

Hello Dave, Thanks for your reply. We followed your advice and installed Hydra on each node. We specify ip address in hosts file. For example: shell $ mpiexec –f hosts –np 2 ./app shell $ cat hosts 192.168.0.1 192.168.1.1 (The two node IP belongs to 2 different subnets: for example, subnet #1 192.168.0.0/24 and subnet #2: 192.168.1.0/24) The error out put is “ssh connect to host 192.168.1.1 port 22: connection time out”. So is there a option for Hydra to solve this problem? Thank you! Sincerely, Na Zhang On Fri, Jan 11, 2013 at 5:20 PM, <discuss-request(a)mpich.org> wrote: > Send discuss mailing list submissions to > discuss(a)mpich.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.mpich.org/mailman/listinfo/discuss > or, via email, send a message with subject or body 'help' to > discuss-request(a)mpich.org > > You can reach the person managing the list at > discuss-owner(a)mpich.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of discuss digest..." > > > Today's Topics: > > 1. Re: [PATCH] Use attribute layout_compatible for pair types > (Jed Brown) > 2. Re: [PATCH] Use attribute layout_compatible for pair types > (Dmitri Gribenko) > 3. start MPD daemons on 2 different subnets (Na Zhang) > 4. Re: start MPD daemons on 2 different subnets (Dave Goodell) > 5. Fatal error in PMPI_Reduce (Michael Colonno) > 6. Re: Fatal error in PMPI_Reduce (Pavan Balaji) > 7. Re: Fatal error in PMPI_Reduce (Pavan Balaji) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 9 Jan 2013 14:00:50 -0600 > From: Jed Brown <jedbrown(a)mcs.anl.gov> > To: discuss(a)mpich.org > Subject: Re: [mpich-discuss] [PATCH] Use attribute layout_compatible > for pair types > Message-ID: > < > CAM9tzSnqJHaj6wbKBdAWp5YveG+UW_OWiA768GRb1spHjn+TZw(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Jan 9, 2013 12:56 PM, "Dmitri Gribenko" <gribozavr(a)gmail.com> wrote: > > > On Wed, Jan 9, 2013 at 8:19 PM, Dave Goodell <goodell(a)mcs.anl.gov> > wrote: > > > Both implemented and pushed as d440abb and ac15f7a. Thanks. > > > > > > -Dave > > > > > > On Jan 1, 2013, at 11:14 PM CST, Jed Brown wrote: > > > > > >> In addition, I suggest guarding these definitions. Leaving these in > > increases the total number of symbols in an example executable linking > > PETSc by a factor of 2. (They're all read-only, but they're still there.) > > Clang is smart enough to remove these, presumably because it understands > > the special attributes. > > > > No, LLVM removes these not because of the attributes, but because > > these are unused. And when they are used, most of the time they don't > > have their address taken, so their value is propagated to the point > > where they are read and the constants again become unused. > > > > I don't think GCC isn't smart enough to do the same. Do you compile > > with optimization? > > > > Dmitri, as discussed in the other thread, it's smart enough, but only when > optimization is turned on. There's no reason to needlessly make debug > builds heavier than necessary. This is not a big deal either way. >

1 0

Fwd: [Systems Announce] Noon outage of SVN, trac, other websites listed
by Dave Goodell 17 Jan '13

17 Jan '13

FYI, this will affect trac.mpich.org as well as the old (read-only) SVN server. Times given are US CST (UTC-6:00). -Dave Begin forwarded message: > From: Dan Olson <dolson(a)mcs.anl.gov> > Subject: [Systems Announce] Noon outage of SVN, trac, other websites listed > Date: January 17, 2013 10:42:37 AM CST > To: cels-systems-announce(a)lists.anl.gov > > > > Hi all, > > We will be performing emergency maintenance between 12:00 noon and 12:30pm today, the following services will be unavailable: > > login3.mcs.anl.gov > login4.mcs.anl.gov > reports.alcf.anl.gov > cgm.mcs.anl.gov > lasso.mcs.anl.gov > meshkit.mcs.anl.gov > svn.alcf.anl.gov > svn.mcs.anl.gov > trac.alcf.anl.gov > trac.kbase.us > trac.mcs.anl.gov > trac.mpich.org > > Thank you for your patience. > > ---- > Daniel Murphy-Olson > Systems Administrator > Mathematics & Computer Science Division > Argonne National Laboratory > 630-252-0055 > > > > _______________________________________________ > CELS-Systems-Announce mailing list > CELS-Systems-Announce(a)lists.anl.gov > https://lists.anl.gov/mailman/listinfo/cels-systems-announce

1 0

Re: [mpich-discuss] Problem - Step 6. Build MPICH2
by Dave Goodell 15 Jan '13

15 Jan '13

Those warnings are harmless (and nearly impossible for us to eliminate, unfortunately). Are you having an actual problem compiling/running MPI applications? -Dave On Jan 15, 2013, at 5:20 PM CST, N D wrote: > Hi, > > I have a problem at the step 6 of the install guide. > The error message I get is: > ld: warning: directory not found for option '-L./src/mpl' > ld: warning: directory not found for option '-L./src/openpa/src' > > I hence ran make VERBOSE=1 2>&1 | tee m.txt and attached the c and m files created in this email. Could you please explain me what I can do to solve this? > > Thanks & Regards! > Nicolas > <c.txt><m.txt>_______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

Problem - Step 6. Build MPICH2
by N D 15 Jan '13

15 Jan '13

Hi, I have a problem at the step 6 of the install guide.The error message I get is:ld: warning: directory not found for option '-L./src/mpl'ld: warning: directory not found for option '-L./src/openpa/src' I hence ran make VERBOSE=1 2>&1 | tee m.txt and attached the c and m files created in this email. Could you please explain me what I can do to solve this? Thanks & Regards!Nicolas

1 0

Re: [mpich-discuss] MPI_Accumulate with MAXLOC does not error for incompatible types
by Jed Brown 14 Jan '13

14 Jan '13

Thanks, Dave. On Mon, Jan 14, 2013 at 6:39 PM, Dave Goodell <goodell(a)mcs.anl.gov> wrote: > Fixed by http://git.mpich.org/mpich.git/commitdiff/ba2e444 > > It looks like I accidentally put the wrong URL into the commit message for > some reason. The correct mailing list URL should be: > http://lists.mpich.org/pipermail/discuss/2013-January/000227.html > > -Dave > > On Jan 1, 2013, at 1:09 PM CST, Jed Brown wrote: > > > With MPI_Reduce, we get a nice helpful error message: > > > > Fatal error in PMPI_Reduce: Invalid MPI_Op, error stack: > > PMPI_Reduce(1217)...........: MPI_Reduce(sbuf=0x7fff3e39fa50, > rbuf=0x7fff3e39fa40, count=1, dtype=USER<contig>, MPI_MAXLOC, root=0, > MPI_COMM_WORLD) failed > > MPIR_MAXLOC_check_dtype(151): MPI_Op MPI_MAXLOC operation not defined > for this datatype > > > > > > With MPI_Accumulate, we just get wrong results. See attached code using > a user-defined contiguous results. > > > > I care about this because I'm stuck [1] dispatching into alternative > mechanisms for type combinations that are not directly supported by MPI > (e.g., struct {int u; long long k;} and __float128). I missed a spot and > had a confusing bug that I think MPICH should be catching. > > > > > > [1] As usual, the crud would evaporate if only MPI_Accumulate were > extensible over datatypes. > > <maxloc.c>_______________________________________________ > > 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_Accumulate with MAXLOC does not error for incompatible types
by Dave Goodell 14 Jan '13

14 Jan '13

Fixed by http://git.mpich.org/mpich.git/commitdiff/ba2e444 It looks like I accidentally put the wrong URL into the commit message for some reason. The correct mailing list URL should be: http://lists.mpich.org/pipermail/discuss/2013-January/000227.html -Dave On Jan 1, 2013, at 1:09 PM CST, Jed Brown wrote: > With MPI_Reduce, we get a nice helpful error message: > > Fatal error in PMPI_Reduce: Invalid MPI_Op, error stack: > PMPI_Reduce(1217)...........: MPI_Reduce(sbuf=0x7fff3e39fa50, rbuf=0x7fff3e39fa40, count=1, dtype=USER<contig>, MPI_MAXLOC, root=0, MPI_COMM_WORLD) failed > MPIR_MAXLOC_check_dtype(151): MPI_Op MPI_MAXLOC operation not defined for this datatype > > > With MPI_Accumulate, we just get wrong results. See attached code using a user-defined contiguous results. > > I care about this because I'm stuck [1] dispatching into alternative mechanisms for type combinations that are not directly supported by MPI (e.g., struct {int u; long long k;} and __float128). I missed a spot and had a confusing bug that I think MPICH should be catching. > > > [1] As usual, the crud would evaporate if only MPI_Accumulate were extensible over datatypes. > <maxloc.c>_______________________________________________ > 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] Problem with MPICH 3.0 rc1 compilation on RHEL 5
by Dave Goodell 14 Jan '13

14 Jan '13

Thanks for letting us know. This is a known issue related to our recent switch to git. We're working the kinks out of our nightly crons still. -Dave On Jan 14, 2013, at 12:02 PM CST, Yauheni Zelenko wrote: > Hi, Dave! > > Thank you for notice! > > Somehow latest nightly build listed on http://www.mpich.org/static/tarballs/nightly/trunk/ is from January 4. > > Eugene. > ________________________________________ > From: discuss-bounces(a)mpich.org [discuss-bounces(a)mpich.org] On Behalf Of Dave Goodell [goodell(a)mcs.anl.gov] > Sent: Friday, January 11, 2013 3:50 PM > To: discuss(a)mpich.org > Subject: Re: [mpich-discuss] Problem with MPICH 3.0 rc1 compilation on RHEL 5 > > FYI, the LLONG_MAX issue was resolved recently: http://git.mpich.org/mpich.git/commitdiff/465ca32 > > Expect to see this in an upcoming MPICH bug release, likely named v3.0.2. > > -Dave > > On Nov 14, 2012, at 4:46 PM CST, Dave Goodell wrote: > >> 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

1 0

Re: [mpich-discuss] Problem with MPICH 3.0 rc1 compilation on RHEL 5
by Yauheni Zelenko 14 Jan '13

14 Jan '13

Hi, Dave! Thank you for notice! Somehow latest nightly build listed on http://www.mpich.org/static/tarballs/nightly/trunk/ is from January 4. Eugene. ________________________________________ From: discuss-bounces(a)mpich.org [discuss-bounces(a)mpich.org] On Behalf Of Dave Goodell [goodell(a)mcs.anl.gov] Sent: Friday, January 11, 2013 3:50 PM To: discuss(a)mpich.org Subject: Re: [mpich-discuss] Problem with MPICH 3.0 rc1 compilation on RHEL 5 FYI, the LLONG_MAX issue was resolved recently: http://git.mpich.org/mpich.git/commitdiff/465ca32 Expect to see this in an upcoming MPICH bug release, likely named v3.0.2. -Dave On Nov 14, 2012, at 4:46 PM CST, Dave Goodell wrote: > 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

1 0

Re: [mpich-discuss] Fatal error in PMPI_Reduce
by Pavan Balaji 12 Jan '13

12 Jan '13

On 01/12/2013 02:51 PM US Central Time, Michael Colonno wrote: > I'm only using two hosts in this test. cxxcpi works successfully on > any one host (n <= 16) but fails on any two hosts (n > 16). So > whatever the issue is it's systematic to all the systems (which I > suppose makes sense). FWIW, you can pass -ppn 1 to mpiexec to ask it to pretend that each host has only one core. That way, you should be able to reproduce this with just n == 2. > All these systems have firewalls disabled so I can confirm that > firewall is not an issue. The only thing that's not completely > standard is they use a bond of several eth devices for communication > and some fancier load-balancing network equipment. Hmm.. Interesting. Is it possible that the hostname provided by slurm matches an eth device that does not have full connectivity? Can you try passing -disable-hostname-propagation to mpiexec to see if that helps? -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0