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

non-blocking communication and subarray data type
by burlen 22 Apr '13

22 Apr '13

Can anyone clarify about using subarray datatype with irecv, When is ok to free the subarray data type? Can I do so immediately after calling irecv? or must I wait until the recv really finishes? I didn't see any specific language about this in the documentation , but I'm experiencing segfaults when MPI accesses previously free'd memory in the datatype. Thanks Burlen

1 0

Re: [mpich-discuss] MPICH3 library inconsistencies
by Markus Geimer 22 Apr '13

22 Apr '13

Hi Dave, > It looks like weak symbol detection on clang is broken/missing. If > you can, please send the config.log from your configure step (and > ideally the c.txt file mentioned in the README as well). Please find the requested files (for MPICH 3.0.3) attached. The few warnings in 'm.txt' might be of interest as well (I compiled MPICH inside a 32-bit chroot environment we are using to find potential portability issues in our software). If you need something else, or have a patch for me to try out, please let me know. Thanks, Markus -- Dr. Markus Geimer Juelich Supercomputing Centre Institute for Advanced Simulation Forschungszentrum Juelich GmbH 52425 Juelich, Germany Phone: +49-2461-61-1773 Fax: +49-2461-61-6656 E-Mail: m.geimer(a)fz-juelich.de WWW: http://www.fz-juelich.de/ias/jsc ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------

1 0

Re: [mpich-discuss] MPICH3 library inconsistencies
by Dmitri Gribenko 22 Apr '13

22 Apr '13

On Mon, Apr 22, 2013 at 3:44 PM, Dave Goodell <goodell(a)mcs.anl.gov> wrote: > It looks like weak symbol detection on clang is broken/missing. If you can, please send the config.log from your configure step (and ideally the c.txt file mentioned in the README as well). I have found the same bug a few days ago: http://llvm.org/bugs/show_bug.cgi?id=15695 Clang does support other (more common) forms of pragma weak. 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] MPICH3 library inconsistencies
by Dave Goodell 22 Apr '13

22 Apr '13

On Apr 22, 2013, at 2:41 AM CDT, Markus Geimer <m.geimer(a)fz-juelich.de> wrote: > While experimenting with MPICH 3.0.2 and various compilers, > I found an inconsistency which probably isn't intended. > > When configuring MPICH an a Linux system for GNU or Intel > compilers with [snip] > However, when configuring for Clang 3.2 (with GNU Fortran) using > > ./configure --prefix=... --enable-debuginfo \ > CC=clang CXX=clang++ F77=gfortran F90=gfortran [snip] > Obviously, there is an additional library 'libpmpich.a'. > Further investigation reveals that the distribution of > symbols across these libraries is somewhat weird, too: [snip] > My assumption is that something's going wrong during configure > which subsequently messes up the build. Maybe something to > investigate for the next bugfix release... It looks like weak symbol detection on clang is broken/missing. If you can, please send the config.log from your configure step (and ideally the c.txt file mentioned in the README as well). Thanks for letting us know. Many of us use OS X instead of Linux for daily development, which simply does not support weak symbols (in the usual sense), so this is harder for us to notice by accident. -Dave

1 0

MPICH3 library inconsistencies
by Markus Geimer 22 Apr '13

22 Apr '13

Dear MPICH developers, While experimenting with MPICH 3.0.2 and various compilers, I found an inconsistency which probably isn't intended. When configuring MPICH an a Linux system for GNU or Intel compilers with ./configure --prefix=... --enable-debuginfo \ CC=gcc CXX=g++ F77=gfortran F90=gfortran or ./configure --prefix=... --enable-debuginfo \ CC=icc CXX=icpc F77=ifort F90=ifort respectively, the following libraries are built (ignoring the shared libs here for simplicity): ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- $ cd <prefix_{gnu,intel}>/lib $ ls *.a libfmpich.a libmpichcxx.a libmpl.a libtvmpich.a libmpich.a libmpichf90.a libopa.a ----- >8 ----- >8 ----- >8 ----- >8 ----- >8 ----- >8 ----- However, when configuring for Clang 3.2 (with GNU Fortran) using ./configure --prefix=... --enable-debuginfo \ CC=clang CXX=clang++ F77=gfortran F90=gfortran results in ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- $ cd <prefix_clang>/lib $ ls *.a libfmpich.a libmpichcxx.a libmpl.a libpmpich.a libmpich.a libmpichf90.a libopa.a libtvmpich.a ----- >8 ----- >8 ----- >8 ----- >8 ----- >8 ----- >8 ----- Obviously, there is an additional library 'libpmpich.a'. Further investigation reveals that the distribution of symbols across these libraries is somewhat weird, too: ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- $ cd <prefix_clang>/lib $ nm libmpich.a | grep 'T PMPI_Recv' 00000000 T PMPI_Recv 00000000 T PMPI_Recv_init $ nm libpmpich.a | grep 'T PMPI_Recv' $ nm libmpich.a | grep 'T MPI_Recv' $ nm libpmpich.a | grep 'T MPI_Recv' 00000000 T MPI_Recv 00000000 T MPI_Recv_init $ $ nm libmpich.a | grep 'T MPI_File_open' 00000000 T MPI_File_open $ nm libpmpich.a | grep 'T MPI_File_open' 00000000 T MPI_File_open $ nm libmpich.a | grep 'T PMPI_File_open' 00000000 T PMPI_File_open $ nm libpmpich.a | grep 'T PMPI_File_open' 00000000 T PMPI_File_open ----- >8 ----- >8 ----- >8 ----- >8 ----- >8 ----- >8 ----- My assumption is that something's going wrong during configure which subsequently messes up the build. Maybe something to investigate for the next bugfix release... Thanks, Markus -- Dr. Markus Geimer Juelich Supercomputing Centre Institute for Advanced Simulation Forschungszentrum Juelich GmbH 52425 Juelich, Germany Phone: +49-2461-61-1773 Fax: +49-2461-61-6656 E-mail: m.geimer(a)fz-juelich.de WWW: http://www.fz-juelich.de/jsc/ ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------

1 0

Re: [mpich-discuss] building MPICH-3.0.3 for Windows
by Jim Dinan 21 Apr '13

21 Apr '13

We are currently not able to support a windows because of limited time. Unfortunately, as of right now, there is no plan for a future windows release. ~Jim. On 04/20/2013 02:22 PM, Иващук Роман wrote: > > > Having spent much time for building MPICH-3.0.3 it would be nice to know if you are going to make Windows release? > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss >

1 0

building MPICH-3.0.3 for Windows
by Иващук Роман 20 Apr '13

20 Apr '13

Having spent much time for building MPICH-3.0.3 it would be nice to know if you are going to make Windows release?

1 0

Re: [mpich-discuss] (no subject)
by Dave Goodell 19 Apr '13

19 Apr '13

MPICH2 >=1.5a1 and MPICH >=3.0 are simply unsupported on Windows at this time. Please use an older version which is supported, such as 1.4.1p1. -Dave On Apr 19, 2013, at 3:28 AM CDT, Иващук Роман <newtrad(a)yandex.ru> wrote: > > > Hello all. I am trying to run the latest MPICH-3.0.3 on Linux and Windows. There are no > problems with building MPICH on Linux. Some difficulties with running are not so important. > But building on Windows became a great deal problem (I use Windows 7, MS VS 2010, Visual Fortran XE 2011) . > Direct implementation the instructions > from the user guide gave no results. The script winconfigure.wsf prints the messages like > > ERROR: 67 definitions n > (156 instances of unhan > Unhandled @foo@'s: > @MPI_COUNT_DATATYPE@, > > Invalid format in mpich Version file. Expected: "MPICH_VERSION_NAME MPICH_VERSIO > N" format > Unhandled definitions > PACKAGE > PACKAGE_URL > ROMIO_BG > > Some header files like glue_romio.h are absent in the directory /mpich-3.0.3. They are to be > downloaded from the internet. > The file mpi.h generated by the script has simbols like "@" which are not recognized by the VS. > Some header files do not have the correct end of file. > > What is the reason of such situation? Please help. > > _______________________________________________ > 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] Hydra torque support issues
by Pavan Balaji 19 Apr '13

19 Apr '13

On 04/19/2013 03:38 AM US Central Time, Reuti wrote: > Isn't it more an issue of Torque? IMO it should either disallow a > local TM invocation and return an error, or do correct accounting of > it. You could see it as such, but we'll need a workaround in the short-term till they fix it anyway. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-discuss] Hydra torque support issues
by Pavan Balaji 19 Apr '13

19 Apr '13

On 04/19/2013 07:36 AM US Central Time, Bharath Ramesh wrote: > On 4/19/2013 3:10 AM, Pavan Balaji wrote: >> https://trac.mpich.org/projects/mpich/ticket/1812 >> > Not a problem. I understand using tm_spawn to launch proxies on the > sister moms. To launch proxy on the mother superior one doesnt need to > use tm_spawn, i.e., mpiexec can fork it on mother superior. I havent > looked through the code to see if this is the issue. Correct. The part that complicates this issue is that with some processes launched with tm_spawn and some with fork, we'll need to do a combination of waitpid and tm_poll to wait for their completion -- which is a bit of pain when we have to keep the timeout period in mind that the user can specify. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0