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

Re: [mpich-discuss] Man pages no longer installed
by Ken Raffenetti 14 Nov '13

14 Nov '13

To clarify, there are pre-built manpages included in the release tarball for 3.1rc1. They are installed as part of 'make install'. Are you sure your MANPATH includes the location of your install? Ken ----- Original Message ----- > From: "Wesley Bland" <wbland(a)mcs.anl.gov> > To: discuss(a)mpich.org > Sent: Thursday, November 14, 2013 11:23:39 AM > Subject: Re: [mpich-discuss] Man pages no longer installed > > > I don’t know when the decision was made to turn off the manages by > default, but it makes sense as they require a special tool that > won’t be commonly installed. As the wiki page says, you have to > install the “sowing” tool first before you can build the man pages. > If we make that a requirement for the regular `make install`, that > would be more a burden for most users. > > > Thanks, > Wesley > > > > > On Nov 14, 2013, at 11:17 AM, Junchao Zhang < jczhang(a)mcs.anl.gov > > wrote: > > > > Hi, Markus, > I installed my manpages according to instructions at > https://wiki.mpich.org/mpich/index.php/Creating_MPICH_Manpages > It needs a customized tool. > But whether it is the reason mandoc is not installed by default, I > would let more experienced mpich developers to answer you. > > > > --Junchao Zhang > > > On Thu, Nov 14, 2013 at 4:03 AM, Markus Geimer < > m.geimer(a)fz-juelich.de > wrote: > > > Hi! > > Is it intended that MPICH 3.1rc1 no longer installs man pages > during 'make install'? This seems to be a regression compared > to MPICH2. > > 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 > ------------------------------------------------------------------------------------------------ > ------------------------------------------------------------------------------------------------ > > _______________________________________________ > 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] Man pages no longer installed
by Wesley Bland 14 Nov '13

14 Nov '13

I don’t know when the decision was made to turn off the manages by default, but it makes sense as they require a special tool that won’t be commonly installed. As the wiki page says, you have to install the “sowing” tool first before you can build the man pages. If we make that a requirement for the regular `make install`, that would be more a burden for most users. Thanks, Wesley On Nov 14, 2013, at 11:17 AM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: > Hi, Markus, > I installed my manpages according to instructions at https://wiki.mpich.org/mpich/index.php/Creating_MPICH_Manpages > It needs a customized tool. > But whether it is the reason mandoc is not installed by default, I would let more experienced mpich developers to answer you. > > --Junchao Zhang > > > On Thu, Nov 14, 2013 at 4:03 AM, Markus Geimer <m.geimer(a)fz-juelich.de> wrote: > Hi! > > Is it intended that MPICH 3.1rc1 no longer installs man pages > during 'make install'? This seems to be a regression compared > to MPICH2. > > 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 > ------------------------------------------------------------------------------------------------ > ------------------------------------------------------------------------------------------------ > > _______________________________________________ > 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] Man pages no longer installed
by Junchao Zhang 14 Nov '13

14 Nov '13

Hi, Markus, I installed my manpages according to instructions at https://wiki.mpich.org/mpich/index.php/Creating_MPICH_Manpages It needs a customized tool. But whether it is the reason mandoc is not installed by default, I would let more experienced mpich developers to answer you. --Junchao Zhang On Thu, Nov 14, 2013 at 4:03 AM, Markus Geimer <m.geimer(a)fz-juelich.de>wrote: > Hi! > > Is it intended that MPICH 3.1rc1 no longer installs man pages > during 'make install'? This seems to be a regression compared > to MPICH2. > > 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 > > ------------------------------------------------------------------------------------------------ > > ------------------------------------------------------------------------------------------------ > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss >

1 0

Man pages no longer installed
by Markus Geimer 14 Nov '13

14 Nov '13

Hi! Is it intended that MPICH 3.1rc1 no longer installs man pages during 'make install'? This seems to be a regression compared to MPICH2. 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] Compilation error of mpich-3.0.4 with Lustre 2.4.0
by Huiwei Lu 11 Nov '13

11 Nov '13

Hi, Jerome and Yan, Thanks for reporting the bug. I have piled a ticket #1973 to track this bug in http://trac.mpich.org/projects/mpich/ticket/1973. We will let you know when we fixed it. I think the line of "#define _XOPEN_SOURCE 600” is used for compilation portability on Mac. But I don’t know why it causes an error in quota.h. -- Huiwei Lu http://www.mcs.anl.gov/~huiweilu/ On Nov 11, 2013, at 4:14 PM, Jerome Vienne <viennej(a)tacc.utexas.edu> wrote: > Hi, > > I would like to report a similar issue with mpich-3.1rc1 on Stampede cluster which is using Lustre 2.4 on login nodes. > > Configure used: > ./configure --enable-romio --with-file-system=lustre > > Result: > make[3]: Entering directory `/work/01538/viennej/MPI/mpich-3.1rc1/src/mpi/romio' > CC adio/ad_lustre/ad_lustre_rwcontig.lo > /usr/include/sys/quota.h(221): error: identifier "caddr_t" is undefined > caddr_t __addr) __THROW; > > Thanks, > Jerome > > -- > Jerome Vienne, Ph.D > HPC Software Tools Group > Texas Advanced Computing Center (TACC) > viennej(a)tacc.utexas.edu | Phone: (512) 475-9322 > Office: ROC 1.455B | Fax: (512) 475-9445 > > > On Wed, Oct 23, 2013 at 6:28 PM, Yan Li <yanli(a)ucsc.edu> wrote: > Hello, > > I'm trying to compile mpich-3.0.4 on CentOS 6.4 x86-64 running Lustre 2.4.0, which was installed by using RPMs from http://zfsonlinux.org/lustre.html > > Configure command used: > ./configure --prefix=/share/ --with-file-system=ufs+lustre > > There's a compilation error: > > ~~~~ [snip] ~~~~ > CC adio/ad_lustre/ad_lustre_open.lo > CC adio/ad_lustre/ad_lustre_rwcontig.lo > In file included from /usr/include/linux/lustre_user.h:46, > from /usr/include/lustre/lustre_user.h:54, > from adio/ad_lustre/ad_lustre.h:30, > from adio/ad_lustre/ad_lustre_rwcontig.c:14: > /usr/include/sys/quota.h:221: error: expected declaration specifiers or '...' before 'caddr_t' > ~~~~ [snip] ~~~~ > > As you can see that the file ad_lustre_open.c compiles OK. The difference between it and ad_lustre_rwcontig.c is that the latter includes this line: > #define _XOPEN_SOURCE 600 > before including the lustre header file. > > It seems to me that defining _XOPEN_SOURCE to 600 on Linux implies that caddr_t is defined somewhere else, suppressing the definition of caddr_t in <sys/types.h>, thus leads to the compilation error of <sys/quota.h>. > > Removing the definition of _XOPEN_SOURCE from ad_lustre_rwcontig.c seems fixed this problem, but I want to know why the definition was put there in the first place and whether removing it can cause any potential problem. > > Thanks for your help in advance. > > Yan Li > Graduate Student Researcher, > Storage Systems Research Center, > Computer Science, University of California, Santa Cruz > > _______________________________________________ > 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] Compilation error of mpich-3.0.4 with Lustre 2.4.0
by Jerome Vienne 11 Nov '13

11 Nov '13

Hi, I would like to report a similar issue with mpich-3.1rc1 on Stampede cluster which is using Lustre 2.4 on login nodes. Configure used: *./configure --enable-romio --with-file-system=lustre* Result: *make[3]: Entering directory `/work/01538/viennej/MPI/mpich-3.1rc1/src/mpi/romio'* * CC adio/ad_lustre/ad_lustre_rwcontig.lo* */usr/include/sys/quota.h(221): error: identifier "caddr_t" is undefined* * caddr_t __addr) __THROW;* Thanks, Jerome -- Jerome Vienne, Ph.D HPC Software Tools Group Texas Advanced Computing Center (TACC) viennej(a)tacc.utexas.edu | Phone: (512) 475-9322 Office: ROC 1.455B | Fax: (512) 475-9445 On Wed, Oct 23, 2013 at 6:28 PM, Yan Li <yanli(a)ucsc.edu> wrote: > Hello, > > I'm trying to compile mpich-3.0.4 on CentOS 6.4 x86-64 running Lustre > 2.4.0, which was installed by using RPMs from > http://zfsonlinux.org/lustre.html > > Configure command used: > ./configure --prefix=/share/ --with-file-system=ufs+lustre > > There's a compilation error: > > ~~~~ [snip] ~~~~ > CC adio/ad_lustre/ad_lustre_open.lo > CC adio/ad_lustre/ad_lustre_rwcontig.lo > In file included from /usr/include/linux/lustre_user.h:46, > from /usr/include/lustre/lustre_user.h:54, > from adio/ad_lustre/ad_lustre.h:30, > from adio/ad_lustre/ad_lustre_rwcontig.c:14: > /usr/include/sys/quota.h:221: error: expected declaration specifiers or > '...' before 'caddr_t' > ~~~~ [snip] ~~~~ > > As you can see that the file ad_lustre_open.c compiles OK. The difference > between it and ad_lustre_rwcontig.c is that the latter includes this line: > #define _XOPEN_SOURCE 600 > before including the lustre header file. > > It seems to me that defining _XOPEN_SOURCE to 600 on Linux implies that > caddr_t is defined somewhere else, suppressing the definition of caddr_t in > <sys/types.h>, thus leads to the compilation error of <sys/quota.h>. > > Removing the definition of _XOPEN_SOURCE from ad_lustre_rwcontig.c seems > fixed this problem, but I want to know why the definition was put there in > the first place and whether removing it can cause any potential problem. > > Thanks for your help in advance. > > Yan Li > Graduate Student Researcher, > Storage Systems Research Center, > Computer Science, University of California, Santa Cruz > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss >

1 0

Re: [mpich-discuss] Error when building MPI with --enbale-shared
by Lokman Rahmani 10 Nov '13

10 Nov '13

Yes, the v3.1rc1 works! Thank you Antonio Lokman ----- Mail original ----- > De: "Antonio J. Peña" <apenya(a)mcs.anl.gov> > À: discuss(a)mpich.org > Envoyé: Vendredi 8 Novembre 2013 18:32:00 > Objet: Re: [mpich-discuss] Error when building MPI with > --enbale-shared > A quick test I may suggest is trying our latest release (rc1). > --enable-shared is the default, and we fixed a few things there. > Antonio > On Friday, November 08, 2013 06:26:09 PM Lokman Rahmani wrote: > Hello, > When building MPICH3 with the option --enable-shared the build fails > with the error : > /usr/bin/ld: > /home/hpc/build/mpich-3.0.4/src/mpl/.libs/libmpl.a(mpltrmem.o): > relocation R_X86_64_32 against `.rodata' can not be used when making > a shared object; recompile with -fPIC > /home/hpc/build/mpich-3.0.4/src/mpl/.libs/libmpl.a: could not read > symbols: Bad value > About this error message, I found this (old) discussion in the > mailing list archive : > https://lists.mcs.anl.gov/mailman/htdig/mpich-discuss/2011-January/008727.h… > What i understood from this message is that I have to use > --disable-rpath (wich become --disable-wrapper-rpath for the newer > versions), but i still have the same problem. > (I also set the CXXFLAGS and CFLAGS to -fPIC) > Anyone can give me hints about the reasons of this error and how to > overcome it? > Thank you > Lokman > _______________________________________________ > 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] double free error after MPI run finished
by John Bray 09 Nov '13

09 Nov '13

Happy to validate any fix when its ready, not only for this test case, but with our full DDT test suite. John On 8 November 2013 19:44, Antonio J. Peña <apenya(a)mcs.anl.gov> wrote: > > Hi John, > > You seem to describe a known bug: > > https://trac.mpich.org/projects/mpich/ticket/1932 > > We've addressed it and the fix is waiting for review before going to the master > branch. It would be nice if you could validate it once it's in master. May I > contact you then to see if that addresses your problem? > > Antonio > > > On Friday, November 08, 2013 05:43:29 PM John Bray wrote: >> I've got some sample code that I'm using to test our debugger DDT. It >> works on openmpi and intelmpi, but with all the MPICH series from >> MPICH2 onwards to 3.1rc1, I get an error after MPI_FINALIZE. Our >> memory debugging library claims its at >> >> SendqFreePool (dbginit.c:386) trying to free previously freed pointer >> >> with a stacktrrace >> auditmpi >> pmpi_finalize__ >> PMPI__finalize >> MPIR_Call_finalize_callbacks >> sendqFreePool (dbginit.c) >> >> Run from a raw mpirun command outside DDT >> >> *** glibc detected *** ./auditmpibad_f_debug.exe: double free or >> corruption (fasttop): 0x1032a5c8 *** >> *** glibc detected *** ./auditmpibad_f_debug.exe: double free or >> corruption (fasttop): 0x104da5c8 *** >> ======= Backtrace: ========= >> ======= Backtrace: ========= >> /lib/libc.so.6(+0xfe750e4)[0xf78e50e4] >> /home/jbray/prog/mpich/mpich-3.1rc1/rhel-6-ppc64_ibm/install/lib/libmpich.so >> .11(+0x1a8b1c)[0xfec8b1c] /lib/libc.so.6(+0xfe750e4)[0xf76c50e4] >> /home/jbray/prog/mpich/mpich-3.1rc1/rhel-6-ppc64_ibm/install/lib/libmpich.so >> .11(+0x1a8b1c)[0xfec8b1c] ... and so on >> >> I've configured with >> >> ./configure --prefix=$PWD/install --enable-shared --enable-fast=all >> --enable-debuginfo >> >> and compile with >> >> mpif90 -o auditmpibad_f_debug.exe auditmpibad.F90 -O0 -g >> >> Its works with the ALLTOALLV only called once. >> >> Is this a bug or a misunderstanding on my part. The code is >> >> program auditmpi >> >> use mpi, only : & >> MPI_COMM_WORLD, & >> MPI_REAL, & >> MPI_STATUS_SIZE, & >> MPI_BSEND_OVERHEAD, & >> MPI_SUM, & >> MPI_UNDEFINED >> >> implicit none >> >> integer, parameter :: repeats=2 >> >> integer :: rank, nproc,ierr,rpt >> real :: input(100000),output(100000) >> integer :: status (MPI_STATUS_SIZE) >> integer :: statuses (MPI_STATUS_SIZE,repeats) >> integer :: request >> logical :: odd >> integer, allocatable :: recvcounts(:),sendcounts(:),displs(:) >> >> call MPI_INIT(ierr) >> >> call MPI_COMM_RANK(MPI_COMM_WORLD, rank, ierr) >> call MPI_COMM_SIZE(MPI_COMM_WORLD, nproc, ierr) >> >> if (rank == 0) print *,"auditmpi start" >> >> if (mod(rank,2) == 0) then >> odd=.false. >> else >> odd=.true. >> end if >> >> allocate (recvcounts(nproc)) >> recvcounts(:) = 100000/nproc >> >> allocate (sendcounts(nproc)) >> sendcounts(:) = 100000/nproc >> >> allocate (displs(nproc)) >> displs(:)=0 ! don't care if we overlap >> >> if ( .NOT. odd) then >> call MPI_IRECV(output,size(output),MPI_REAL,rank+1,1,MPI_COMM_WORLD, >> request, ierr) >> end if >> call MPI_BARRIER(MPI_COMM_WORLD,ierr) >> if (odd) then >> call >> MPI_IRSEND(input,size(input),MPI_REAL,rank-1,1,MPI_COMM_WORLD,request,ierr) >> end if >> call MPI_WAIT(request,status,ierr) >> >> do rpt=1,2 >> call >> MPI_ALLTOALLV(input,sendcounts,displs,MPI_REAL,output,recvcounts,displs,MPI >> _REAL,MPI_COMM_WORLD,ierr) end do >> >> call MPI_BARRIER(MPI_COMM_WORLD,ierr) >> >> deallocate (recvcounts) >> deallocate (sendcounts) >> deallocate (displs) >> >> if (rank == 0) print *,"auditmpi finished" >> >> call MPI_FINALIZE(ierr) >> >> end program auditmpi >> >> John >> _______________________________________________ >> 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

Tools for testing MPI programs
by Jiri Simsa 08 Nov '13

08 Nov '13

Hello, I recently came the ISP tool ( http://www.cs.utah.edu/formal_verification/ISP-release/) for dynamic verification of MPI programs. I wonder if anyone is aware of similar (research) tools that can be used for systematic testing of MPI programs. Thanks! --Jiri Simsa

1 0

Re: [mpich-discuss] double free error after MPI run finished
by Antonio J. Peña 08 Nov '13

08 Nov '13

Hi John, You seem to describe a known bug: https://trac.mpich.org/projects/mpich/ticket/1932 We've addressed it and the fix is waiting for review before going to the master branch. It would be nice if you could validate it once it's in master. May I contact you then to see if that addresses your problem? Antonio On Friday, November 08, 2013 05:43:29 PM John Bray wrote: > I've got some sample code that I'm using to test our debugger DDT. It > works on openmpi and intelmpi, but with all the MPICH series from > MPICH2 onwards to 3.1rc1, I get an error after MPI_FINALIZE. Our > memory debugging library claims its at > > SendqFreePool (dbginit.c:386) trying to free previously freed pointer > > with a stacktrrace > auditmpi > pmpi_finalize__ > PMPI__finalize > MPIR_Call_finalize_callbacks > sendqFreePool (dbginit.c) > > Run from a raw mpirun command outside DDT > > *** glibc detected *** ./auditmpibad_f_debug.exe: double free or > corruption (fasttop): 0x1032a5c8 *** > *** glibc detected *** ./auditmpibad_f_debug.exe: double free or > corruption (fasttop): 0x104da5c8 *** > ======= Backtrace: ========= > ======= Backtrace: ========= > /lib/libc.so.6(+0xfe750e4)[0xf78e50e4] > /home/jbray/prog/mpich/mpich-3.1rc1/rhel-6-ppc64_ibm/install/lib/libmpich.so > .11(+0x1a8b1c)[0xfec8b1c] /lib/libc.so.6(+0xfe750e4)[0xf76c50e4] > /home/jbray/prog/mpich/mpich-3.1rc1/rhel-6-ppc64_ibm/install/lib/libmpich.so > .11(+0x1a8b1c)[0xfec8b1c] ... and so on > > I've configured with > > ./configure --prefix=$PWD/install --enable-shared --enable-fast=all > --enable-debuginfo > > and compile with > > mpif90 -o auditmpibad_f_debug.exe auditmpibad.F90 -O0 -g > > Its works with the ALLTOALLV only called once. > > Is this a bug or a misunderstanding on my part. The code is > > program auditmpi > > use mpi, only : & > MPI_COMM_WORLD, & > MPI_REAL, & > MPI_STATUS_SIZE, & > MPI_BSEND_OVERHEAD, & > MPI_SUM, & > MPI_UNDEFINED > > implicit none > > integer, parameter :: repeats=2 > > integer :: rank, nproc,ierr,rpt > real :: input(100000),output(100000) > integer :: status (MPI_STATUS_SIZE) > integer :: statuses (MPI_STATUS_SIZE,repeats) > integer :: request > logical :: odd > integer, allocatable :: recvcounts(:),sendcounts(:),displs(:) > > call MPI_INIT(ierr) > > call MPI_COMM_RANK(MPI_COMM_WORLD, rank, ierr) > call MPI_COMM_SIZE(MPI_COMM_WORLD, nproc, ierr) > > if (rank == 0) print *,"auditmpi start" > > if (mod(rank,2) == 0) then > odd=.false. > else > odd=.true. > end if > > allocate (recvcounts(nproc)) > recvcounts(:) = 100000/nproc > > allocate (sendcounts(nproc)) > sendcounts(:) = 100000/nproc > > allocate (displs(nproc)) > displs(:)=0 ! don't care if we overlap > > if ( .NOT. odd) then > call MPI_IRECV(output,size(output),MPI_REAL,rank+1,1,MPI_COMM_WORLD, > request, ierr) > end if > call MPI_BARRIER(MPI_COMM_WORLD,ierr) > if (odd) then > call > MPI_IRSEND(input,size(input),MPI_REAL,rank-1,1,MPI_COMM_WORLD,request,ierr) > end if > call MPI_WAIT(request,status,ierr) > > do rpt=1,2 > call > MPI_ALLTOALLV(input,sendcounts,displs,MPI_REAL,output,recvcounts,displs,MPI > _REAL,MPI_COMM_WORLD,ierr) end do > > call MPI_BARRIER(MPI_COMM_WORLD,ierr) > > deallocate (recvcounts) > deallocate (sendcounts) > deallocate (displs) > > if (rank == 0) print *,"auditmpi finished" > > call MPI_FINALIZE(ierr) > > end program auditmpi > > John > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0