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

Re: [mpich-discuss] MPICH2 version number
by Pavan Balaji 03 Jan '13

03 Jan '13

On 01/02/2013 01:22 PM US Central Time, Guanhua Zhang wrote: > Once I installed MPICH2 under Windows. How can I know which version > installed? I tried "mpiexec -version". It did not work. Did you try mpich2version? -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-discuss] Extensible Clang type annotation
by Jed Brown 02 Jan '13

02 Jan '13

On Wed, Jan 2, 2013 at 1:23 PM, Dmitri Gribenko <gribozavr(a)gmail.com> wrote: > Unfortunately we can not, because user-defined datatypes are > syntactically different from builtin datatypes in MPICH. MPI_INT is a > macro, so what Clang sees is essentially a magic number. With > user-defined datatypes there's an identifier (MyEnumDatatype) that > actually shows up in the AST. There's a separate quirk in Clang for > handling these magic numbers and corresponding 'static const' > variables (not needed for OpenMPI, btw). > Okay, makes sense. > > so that the symbols are guaranteed to only show up once in > > executables (rather than once per compilation unit)? > > A smart enough compiler (and Clang is smart enough) will eliminate > those even at -O0. > Okay, gcc also removes them with optimization. Thanks, Dmitri.

1 0

Re: [mpich-discuss] Hard-coded path to mpiexec.hydra.conf (1.4, 1.5)
by Yauheni Zelenko 02 Jan '13

02 Jan '13

Hi, Pavan! I think this could be solution, but as it looks like also source code and object files should be shipped to customers. Or my be I didn't notice configure option for intermediate build output :-) Solution with environment variable will decrease size of shipped package, since only final binaries and support files will be shipped. It may be more preferable solution when software installation script is not trivial. Eugene. ________________________________________ From: Pavan Balaji [balaji(a)mcs.anl.gov] Sent: Sunday, December 23, 2012 7:00 PM To: mpich-discuss(a)mcs.anl.gov Cc: Yauheni Zelenko Subject: Re: [mpich-discuss] Hard-coded path to mpiexec.hydra.conf (1.4, 1.5) Sorry about the delay in getting around to this. We were tied up with the mpich-3.0 release. I'm still missing the point of this environment variable. Once you have a pre-built mpich installation, you can install mpich in any location of your choosing using: % make install prefix=<foobar> This overrides the --prefix passed to configure. In this case, you should ship the prebuilt mpich to your customers and run the above "make install" command to place it in the right location. Some of our other vendor partners follow the same model as well. -- Pavan On 07/12/2012 12:46 PM US Central Time, Yauheni Zelenko wrote: > Hi, Pavan! > > Thank you for help! > > However will be good idea to disable check of file in install location at all. > > Or there should be way to specify install location in run-time with environment variable or command-line option (OpenMPI uses OPAL_PREFIX and --prefix correspondingly). > > Other files affected are mpi compilation scripts (mpicc, etc), MPE scripts, libtool generated files, packages, makefiles. > > Easy way to check - to compile MPICH2 in your home directory, install it and grep installed files for your login name. > > Eugene. > ________________________________________ > From: Pavan Balaji [balaji(a)mcs.anl.gov] > Sent: Thursday, July 12, 2012 10:26 AM > To: mpich-discuss(a)mcs.anl.gov > Cc: Yauheni Zelenko > Subject: Re: [mpich-discuss] Hard-coded path to mpiexec.hydra.conf (1.4, 1.5) > > Thanks. I've fixed this in r10004. Now the priority order for the > config file: > > 1. Command line > > 2. Environment variable > > 3. Home directory > > 4. Install directory > > -- Pavan > > On 07/11/2012 06:37 PM, Yauheni Zelenko wrote: >> Hi! >> >> Hydra always try to open mpiexec.hydra.conf file in original install path location in HYD_uii_mpx_get_parameters() if such file is not found in user's home directory. >> >> We ship pre-built MPICH2 with our application to customers, where original install path is invalid. >> >> I think will be good idea to rely on environment variable instead of hard-coded path. >> >> Eugene. >> _______________________________________________ >> mpich-discuss mailing list mpich-discuss(a)mcs.anl.gov >> To manage subscription options or unsubscribe: >> https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss >> > > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji > > > _______________________________________________ > mpich-discuss mailing list mpich-discuss(a)mcs.anl.gov > To manage subscription options or unsubscribe: > https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-discuss] Extensible Clang type annotation
by Dmitri Gribenko 02 Jan '13

02 Jan '13

On Wed, Jan 2, 2013 at 9:01 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Wed, Jan 2, 2013 at 12:09 PM, Dmitri Gribenko <gribozavr(a)gmail.com> > wrote: >> >> Sorry if what I wrote was unclear. Here's a complete example: >> >> $ cat t.cc >> #include <mpi.h> >> >> enum MyEnum { Foo }; >> MPI_Datatype MyEnumDatatype MPICH_ATTR_TYPE_TAG(MyEnum); > > > Oh, fantastic. I didn't realize this could be applied to uninitialized > variables (and somehow didn't recognize that you were saying as much in the > first email). In light of this, can mpi.h change all the static declarations > to extern Unfortunately we can not, because user-defined datatypes are syntactically different from builtin datatypes in MPICH. MPI_INT is a macro, so what Clang sees is essentially a magic number. With user-defined datatypes there's an identifier (MyEnumDatatype) that actually shows up in the AST. There's a separate quirk in Clang for handling these magic numbers and corresponding 'static const' variables (not needed for OpenMPI, btw). > so that the symbols are guaranteed to only show up once in > executables (rather than once per compilation unit)? A smart enough compiler (and Clang is smart enough) will eliminate those even at -O0. Dmitri -- main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr(a)gmail.com>*/

1 0

Re: [mpich-discuss] MPICH2 version number
by Guanhua Zhang 02 Jan '13

02 Jan '13

Hi, Once I installed MPICH2 under Windows. How can I know which version installed? I tried "mpiexec -version". It did not work. Thanks, Guanhua ----- Original Message ----- From: "Pavan Balaji" <balaji(a)mcs.anl.gov> To: <discuss(a)mpich.org> Cc: "Átila Gracco" <gracco.atila(a)gmail.com> Sent: Sunday, December 23, 2012 7:17 PM Subject: Re: [mpich-discuss] Trouble importing mpich2 library This looks like a problem with Maple Grid Computing. Please contact them for instructions. -- Pavan On 10/05/2012 03:23 PM US Central Time, Átila Gracco wrote: > Greetings, > > I'm trying to install a program, Maple Grid Computing 16 , that requires > that i install the mpich2 library, after i do that and go to the program > instalation screen, at some point during instalation it asks me to put > the Name of MPI shared lib, and the root location of it, i'm using > Ubuntu 12.04 - 64 bits. I almost forgot to say, i'm kind of newbie in > linux. > > -- > Att, > *Átila Gracco* > Acadêmico do 8º período | Engenharia de Computação UFG > +55 (62) 8126-1016 > Skype: atilagracco > > > _______________________________________________ > mpich-discuss mailing list mpich-discuss(a)mcs.anl.gov > To manage subscription options or unsubscribe: > https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss > -- Pavan Balaji http://www.mcs.anl.gov/~balaji _______________________________________________ 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] Extensible Clang type annotation
by Jed Brown 02 Jan '13

02 Jan '13

On Wed, Jan 2, 2013 at 12:09 PM, Dmitri Gribenko <gribozavr(a)gmail.com>wrote: > Sorry if what I wrote was unclear. Here's a complete example: > > $ cat t.cc > #include <mpi.h> > > enum MyEnum { Foo }; > MPI_Datatype MyEnumDatatype MPICH_ATTR_TYPE_TAG(MyEnum); > Oh, fantastic. I didn't realize this could be applied to uninitialized variables (and somehow didn't recognize that you were saying as much in the first email). In light of this, can mpi.h change all the static declarations to extern so that the symbols are guaranteed to only show up once in executables (rather than once per compilation unit)? And yes, I'm aware of the flexibility the standard gives compiler implementers regarding enum size.

1 0

Re: [mpich-discuss] building mpich2 with open64 compilers is difficult
by Dave Goodell 02 Jan '13

02 Jan '13

We don't use or test with the open64 compilers, so it's not surprising if there are some problems. WRT 1.2.1p1, we don't fix versions which are that old. If it's not a problem in 1.5 or 3.0.1, especially for build system issues, then it's just unfortunate that the old version doesn't work. -Dave On Dec 31, 2012, at 7:16 PM CST, Michael Seman wrote: > I built mpich2 before with gcc and Intel compilers. I tried to compile with open64, > so first tried mpich2-1.2.1p1 which I built with other compilers. > The make proceeds, I see lot of CC commands, then at the first F90, it falls over. > So I added the verbosity option V=1 to the make and tried again. When it got up to > the offending "F90 mpi.f90" stage, I now see this at the tail of the make log: > > date > .libstamp1 > make[4]: Leaving directory `/home/michael/apps/thirdparty/mpich2-1.2.1p1/src/binding/f90' > make[4]: Entering directory `/home/michael/apps/thirdparty/mpich2-1.2.1p1/src/binding/f90' > false -O2 -I. -c mpi.f90 -o _smpi.o > mv -f _smpi.o mpi.lo > make[4]: *** [mpi.lo] Error 1 > make[4]: Leaving directory `/home/michael/apps/thirdparty/mpich2-1.2.1p1/src/binding/f90' > make[3]: *** [all-redirect] Error 1 > make[3]: Leaving directory `/home/michael/apps/thirdparty/mpich2-1.2.1p1/src/binding/f90' > make[2]: *** [all-redirect] Error 1 > make[2]: Leaving directory `/home/michael/apps/thirdparty/mpich2-1.2.1p1/src/binding' > make[1]: *** [all-redirect] Error 2 > make[1]: Leaving directory `/home/michael/apps/thirdparty/mpich2-1.2.1p1/src' > make: *** [all-redirect] Error 2 > > So "F90" has become "false" somewhere along the track. > > Configure variables were for 1.2.1p1: > BUILD_DIR=/usr/local > F90=openf90 > F77=openf90 > CC=opencc > CXX=openCC > CFLAGS="-fPIC -O" > FFLAGS="-fPIC -fno-second-underscore -O" > F90FLAGS="-fPIC -fno-second-underscore -O" > FLAGS="--prefix=${BUILD_DIR} --enable-threads --enable-sharedlibs=gcc \ > --enable-f77 --enable-f90 --enable-cxx" > > Next, I tried version 1.4 of mpich2, which requires changing a few things, such as > F90 to FC and --enable-f90 to --enable-fc and adding --enabled-shared to flags. > I used these configure variables with versions 1.3 to 1.5: > BUILD_DIR=/usr/local > F77=openf90 > FC=openf90 > CC=opencc > CXX=openCC > CFLAGS="-fPIC -O" > FFLAGS="-fPIC -fno-second-underscore -O" > FCFLAGS="-fPIC -fno-second-underscore -O" > F77FLAGS="-fPIC -fno-second-underscore -O" > FLAGS="--prefix=${BUILD_DIR} --enable-threads --enable-sharedlibs=gcc \ > --enable-fc --enable-shared --enable-f77 --enable-cxx" > > > Again this flops when make gets up to mpi.f90. I still see "false" instead of the FC compiler command. > > Only version 1.5 of mpich2 can be built okay with open64 compilers. I used version 4.2.4 of open64 under RHEL 5.8 64-bit. I also tried open64 > version 4.2.1 > > Has anybody found other combinations to build mpich2 using open64? > _______________________________________________ > 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] Extensible Clang type annotation
by Dmitri Gribenko 02 Jan '13

02 Jan '13

On Wed, Jan 2, 2013 at 8:09 PM, Dmitri Gribenko <gribozavr(a)gmail.com> wrote: > On Wed, Jan 2, 2013 at 8:02 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: >> On Wed, Jan 2, 2013 at 11:51 AM, Dmitri Gribenko <gribozavr(a)gmail.com> >> wrote: >>> >>> [resending to the list, sorry for duplicates] >>> >>> On Wed, Jan 2, 2013 at 7:38 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: >>> > Also, could there be a way (maybe in a future clang release) for me to >>> > get >>> > static type checking for my own types, such as __float128 or pair types >>> > like >>> > {long,long} (which are not in the MPI standard)? It can't truly be a >>> > static >>> > value because I have to create the type at run-time, but perhaps there >>> > could >>> > be a way to tell clang "I promise to set this type up like so." >>> >>> Sorry, I did not understand your requirements completely, but you can >>> annotate your own 'MPI_Datatype's (as I described in the previous >>> email). Is that sufficient for your task? >> >> >> I can't annotate mine because they don't have a static value. (Unless there >> is a way that's not in the documentation.) >> >> I'm actually just setting >> >> MPI_Datatype MY_MPI_ENUM = MPI_INT; >> >> in a different compilation unit. > > Sorry if what I wrote was unclear. Here's a complete example: > > $ cat t.cc > #include <mpi.h> > > enum MyEnum { Foo }; > MPI_Datatype MyEnumDatatype MPICH_ATTR_TYPE_TAG(MyEnum); > > void foo(MyEnum e, int i) { > MPI_Send(&e, 1, MyEnumDatatype, 0, 0, MPI_COMM_WORLD); > MPI_Send(&i, 1, MyEnumDatatype, 0, 0, MPI_COMM_WORLD); > MPI_Send(&e, 1, MPI_INT, 0, 0, MPI_COMM_WORLD); > } > > $ clang -fsyntax-only -I mpich2-build/src/include/ t.cc > t.cc:8:12: warning: argument type 'int *' doesn't match specified > 'MPI' type tag that requires 'MyEnum *' [-Wtype-safety] > MPI_Send(&i, 1, MyEnumDatatype, 0, 0, MPI_COMM_WORLD); > ^~ ~~~~~~~~~~~~~~ > t.cc:9:12: warning: argument type 'MyEnum *' doesn't match specified > 'MPI' type tag that requires 'int *' [-Wtype-safety] > MPI_Send(&e, 1, MPI_INT, 0, 0, MPI_COMM_WORLD); > ^~ ~~~~~~~ > 2 warnings generated. Please note that sending values of enumerated types this way might not be a good idea in general, since the underlying type is implementation-defined (C11 6.7.2.2p, C++11 [dcl.enum]p6, except for enumerations with fixed underlying type). So one can not assume that it is always 'int' (unless one uses enumerations with fixed underlying type). It should be OK if you put a static assertion, though. Dmitri -- main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr(a)gmail.com>*/

1 0

Re: [mpich-discuss] Extensible Clang type annotation
by Dmitri Gribenko 02 Jan '13

02 Jan '13

On Wed, Jan 2, 2013 at 8:02 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > On Wed, Jan 2, 2013 at 11:51 AM, Dmitri Gribenko <gribozavr(a)gmail.com> > wrote: >> >> [resending to the list, sorry for duplicates] >> >> On Wed, Jan 2, 2013 at 7:38 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: >> > Also, could there be a way (maybe in a future clang release) for me to >> > get >> > static type checking for my own types, such as __float128 or pair types >> > like >> > {long,long} (which are not in the MPI standard)? It can't truly be a >> > static >> > value because I have to create the type at run-time, but perhaps there >> > could >> > be a way to tell clang "I promise to set this type up like so." >> >> Sorry, I did not understand your requirements completely, but you can >> annotate your own 'MPI_Datatype's (as I described in the previous >> email). Is that sufficient for your task? > > > I can't annotate mine because they don't have a static value. (Unless there > is a way that's not in the documentation.) > > I'm actually just setting > > MPI_Datatype MY_MPI_ENUM = MPI_INT; > > in a different compilation unit. Sorry if what I wrote was unclear. Here's a complete example: $ cat t.cc #include <mpi.h> enum MyEnum { Foo }; MPI_Datatype MyEnumDatatype MPICH_ATTR_TYPE_TAG(MyEnum); void foo(MyEnum e, int i) { MPI_Send(&e, 1, MyEnumDatatype, 0, 0, MPI_COMM_WORLD); MPI_Send(&i, 1, MyEnumDatatype, 0, 0, MPI_COMM_WORLD); MPI_Send(&e, 1, MPI_INT, 0, 0, MPI_COMM_WORLD); } $ clang -fsyntax-only -I mpich2-build/src/include/ t.cc t.cc:8:12: warning: argument type 'int *' doesn't match specified 'MPI' type tag that requires 'MyEnum *' [-Wtype-safety] MPI_Send(&i, 1, MyEnumDatatype, 0, 0, MPI_COMM_WORLD); ^~ ~~~~~~~~~~~~~~ t.cc:9:12: warning: argument type 'MyEnum *' doesn't match specified 'MPI' type tag that requires 'int *' [-Wtype-safety] MPI_Send(&e, 1, MPI_INT, 0, 0, MPI_COMM_WORLD); ^~ ~~~~~~~ 2 warnings generated. Dmitri -- main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr(a)gmail.com>*/

1 0

Re: [mpich-discuss] Extensible Clang type annotation
by Jed Brown 02 Jan '13

02 Jan '13

On Wed, Jan 2, 2013 at 11:51 AM, Dmitri Gribenko <gribozavr(a)gmail.com>wrote: > [resending to the list, sorry for duplicates] > > On Wed, Jan 2, 2013 at 7:38 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > > Also, could there be a way (maybe in a future clang release) for me to > get > > static type checking for my own types, such as __float128 or pair types > like > > {long,long} (which are not in the MPI standard)? It can't truly be a > static > > value because I have to create the type at run-time, but perhaps there > could > > be a way to tell clang "I promise to set this type up like so." > > Sorry, I did not understand your requirements completely, but you can > annotate your own 'MPI_Datatype's (as I described in the previous > email). Is that sufficient for your task? > I can't annotate mine because they don't have a static value. (Unless there is a way that's not in the documentation.) I'm actually just setting MPI_Datatype MY_MPI_ENUM = MPI_INT; in a different compilation unit. > > Dmitri > > -- > main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if > (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr(a)gmail.com>*/ > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss >

1 0