May 2019 - discuss - mailman3.cels.anl.gov

mpi_shared memory
by Arash sharify 24 May '19

24 May '19

Hello all my name is Arash Hajisharifi and I am a phd student in computational fluid dynamics, Iam working on a code which has been parallelizaed with MPI. I need to improve the parallelisation to reach better performance. I have a 3D domain which has decomposed as 2D domain decomposition and each rank has a stencil of the domain. In my case I have a large 3D array for example Array_total(nx,ny,nz), after decomposition each rank has a part this array:#0 : array_partial(nx,ny/4,nz/4) in rank 0#1 :array_partial(nx,ny/4,nz/4) in rank 1 ... #15 :array_partial(nx,ny/4,nz/4) in rank 15 After some operation, each rank should see Array_partial of every rank, I could not use allgather for each rank because Array_total is so large (about 10 GIG) to gather it inside the local buffer of each rank and can not fit inside and the only way is mpi_shared memory by which each rank shared its part . I know the idea of mpi_shared memory to creat a window among the processes, this idea could be feasible for the processes in one node which the ranks have a shared memory, but it is also possible to creat a window for the processes between 2 nodes? I mean creating one window among all the processes in node 1 and node 2? Unfortunately I am searching for an easy example or a good documentation specially in Fortran for 2 weeks but there is nothing,i don't know how is it possible to not find any thing for one mpi functinlaity which has released 3 years ago and it is not new anymore. May I ask you kindly to guid me or send me some simple example to understand the idea? looking forward to hearing from you, Best Regards,Arash Hajisharifi

1 0

Re: [mpich-discuss] uninstall by removing the install directory?
by Zhou, Hui 22 May '19

22 May '19

If you installed to a separate folder — via `—prefix=…`, then you can simply delete that folder. MPICH does not install files outside the `prefix`. — Hui Zhou T: 630-252-3430 On May 22, 2019, at 4:39 PM, Jonathan Skipp via discuss <discuss(a)mpich.org<mailto:[email protected]>> wrote: Hello all, A few months ago someone had to install mpich-3.3 on my laptop (Mac OS 10.14.4) in a hurry. I'm now trying to compile some other code that uses mpich and believe that mpich (and another library) aren't installed properly. Checking my installation, I can only find my mpich install directory (containing the directories bin/, include/, lib/, and share/). The build directory is nowhere to be found. I guess we deleted it. So all the makefiles are missing so I cannot make clean. Also there are no c.txt, m.txt or mi.txt to attach to this help request. I now want to remove the old installation and then make a new installation myself. I am concerned that if I just remove the install directory I might miss some files that might be located elsewhere on my filesystem, or some configurations somewhere. My question is: is it safe to just rm the old install directory? Or do I need to download again and configure it with a prefix pointing to the old install directory? Thanks! _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

uninstall by removing the install directory?
by Jonathan Skipp 22 May '19

22 May '19

Hello all, A few months ago someone had to install mpich-3.3 on my laptop (Mac OS 10.14.4) in a hurry. I'm now trying to compile some other code that uses mpich and believe that mpich (and another library) aren't installed properly. Checking my installation, I can only find my mpich install directory (containing the directories bin/, include/, lib/, and share/). The build directory is nowhere to be found. I guess we deleted it. So all the makefiles are missing so I cannot make clean. Also there are no c.txt, m.txt or mi.txt to attach to this help request. I now want to remove the old installation and then make a new installation myself. I am concerned that if I just remove the install directory I might miss some files that might be located elsewhere on my filesystem, or some configurations somewhere. My question is: is it safe to just rm the old install directory? Or do I need to download again and configure it with a prefix pointing to the old install directory? Thanks!

1 0

Re: [mpich-discuss] Mpif90 bug report
by Zhou, Hui 17 May '19

17 May '19

These warnings are directly from gfortran. You should be able to reproduce the warnings with `gfortran -Wall -c mpif90_bug_report.f`. `mpif90` is just a wrapper around `gfortran`, you can verify that by `mpif90 -show`. The `-Wall` flag is probably added by the config option during mpich configure. — Hui Zhou T: 630-252-3430 On May 16, 2019, at 9:06 PM, Jonathan Ravens via discuss <discuss(a)mpich.org<mailto:[email protected]>> wrote: Dear MPIf90 maintainers, I appear to have found a bug with mpif90, running under Centos 7. Essentially any assignment to a byte variable gives a warning or an error. The errors are fatal, and the warnings are too numerous to ignore (I'm getting one warning for each byte that is initialised in a DATA statement, so that can be many thousands of warnings). We have used code like this since 1982 without any problems. When mpif90 is used to compile a simple Fortran source with the -fno-range-check option, any byte assignment in code or data statement will give a warning, eg : mpif90_bug_report.f:30.13: b1 = 6 1 Warning: Possible change of value in conversion from INTEGER(4) to INTEGER(1) at (1) This only happens with 'mpif90 -c -fno-range-check'; there is no warning when using gfortran. However, without -fno-range-check, we get other, fatal, errors, so that's even worse : mpif90_bug_report.f:28.24: byte b2 / '89'X/ 1 Error: Arithmetic overflow converting INTEGER(16) to INTEGER(1) at (1). This check can be disabled with the option -fno-range-check I've attached a simple program to replicate the problem (mpif90_bug_report.f) The environment details are : > more /etc/redhat-release CentOS Linux release 7.6.1810 (Core) > uname -a Linux ... 3.10.0-957.5.1.el7.x86_64 #1 SMP Fri Feb 1 14:54:57 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux > mpif90 -v mpif90 for MPICH version 3.0.4 Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux Thread model: posix gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC) Please don't hestitate to let me know if any further details are needed. Many thanks, Jonathan Ravens <mpif90_bug_report.f>_______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Mpif90 bug report
by Jonathan Ravens 16 May '19

16 May '19

Dear MPIf90 maintainers, I appear to have found a bug with mpif90, running under Centos 7. Essentially any assignment to a byte variable gives a warning or an error. The errors are fatal, and the warnings are too numerous to ignore (I'm getting one warning for each byte that is initialised in a DATA statement, so that can be many thousands of warnings). We have used code like this since 1982 without any problems. When mpif90 is used to compile a simple Fortran source with the -fno-range-check option, any byte assignment in code or data statement will give a warning, eg : *mpif90_bug_report.f:30.13: b1 = 6 1 Warning: Possible change of value in conversion from INTEGER(4) to INTEGER(1) at (1)* This only happens with 'mpif90 -c -fno-range-check'; there is no warning when using gfortran. However, without -fno-range-check, we get other, fatal, errors, so that's even worse : * mpif90_bug_report.f:28.24: byte b2 / '89'X/ 1* * Error: Arithmetic overflow converting INTEGER(16) to INTEGER(1) at (1). This check can be disabled with the option -fno-range-check * I've attached a simple program to replicate the problem (mpif90_bug_report.f) The environment details are : > more /etc/redhat-release CentOS Linux release 7.6.1810 (Core) > uname -a Linux ... 3.10.0-957.5.1.el7.x86_64 #1 SMP Fri Feb 1 14:54:57 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux > mpif90 -v mpif90 for MPICH version 3.0.4 Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux Thread model: posix gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC) Please don't hestitate to let me know if any further details are needed. Many thanks, Jonathan Ravens

1 0

Re: [mpich-discuss] attribute value of MPI_TAG_UB
by Wei-keng Liao 02 May '19

02 May '19

Hi Pavan You are right. The example shows me the right way to call MPI_Comm_get_attr(). I am now getting a consistent value of 268435455 from MPICH 3.3 and 2147483647 from OpenMPI 4.0.1 when running on a Redhat box. Thanks, Wei-keng > On May 2, 2019, at 7:43 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: > > > Attributes have these weird point-to-integer casting semantics. Make sure you are using it correctly. > > See https://github.com/pmodels/mpich/blob/master/test/mpi/attr/baseattr2.c#L30 > > Basically, even though the parameter is "void *", it really needs to be treated as "int **" in this case. > > -- Pavan > >> On Apr 26, 2019, at 2:18 PM, Wei-keng Liao via discuss <discuss(a)mpich.org> wrote: >> >> According to MPI 3.1, Section 8.1.2, the attribute value of >> MPI_TAG_UB attached to MPI_COMM_WORLD can be inquired by function >> MPI_Comm_get_attr(). It has the same value on all processes of >> MPI_COMM_WORLD. >> >> My first question is should this value be the same across different runs? >> A small test program using MPICH 3.3 shows they are not the same across >> runs and across processes. But when compiled with the latest master branch, >> they are the same. So, can I assume the answer to my question is YES and >> MPICH has fixed this in the master branch? >> >> My second question is that I notice MPI_TAG_UB is defined as a constant >> of 0x64400001 (=1681915905) in mpi.h. That value is not the one returned >> by MPI_Comm_get_attr(), which is 10345120. Is this intended? >> >> I also tested OpenMPI 4.0.0. The inconsistency occurs across different >> runs, as well as different processes. I can see OpenMPI defines >> MPI_TAG_UB as an enum type, rather than a constant. >> >> Wei-keng >> >> _______________________________________________ >> 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] attribute value of MPI_TAG_UB
by Balaji, Pavan 02 May '19

02 May '19

Attributes have these weird point-to-integer casting semantics. Make sure you are using it correctly. See https://github.com/pmodels/mpich/blob/master/test/mpi/attr/baseattr2.c#L30 Basically, even though the parameter is "void *", it really needs to be treated as "int **" in this case. -- Pavan > On Apr 26, 2019, at 2:18 PM, Wei-keng Liao via discuss <discuss(a)mpich.org> wrote: > > According to MPI 3.1, Section 8.1.2, the attribute value of > MPI_TAG_UB attached to MPI_COMM_WORLD can be inquired by function > MPI_Comm_get_attr(). It has the same value on all processes of > MPI_COMM_WORLD. > > My first question is should this value be the same across different runs? > A small test program using MPICH 3.3 shows they are not the same across > runs and across processes. But when compiled with the latest master branch, > they are the same. So, can I assume the answer to my question is YES and > MPICH has fixed this in the master branch? > > My second question is that I notice MPI_TAG_UB is defined as a constant > of 0x64400001 (=1681915905) in mpi.h. That value is not the one returned > by MPI_Comm_get_attr(), which is 10345120. Is this intended? > > I also tested OpenMPI 4.0.0. The inconsistency occurs across different > runs, as well as different processes. I can see OpenMPI defines > MPI_TAG_UB as an enum type, rather than a constant. > > Wei-keng > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0