- discuss - mailman3.cels.anl.gov

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

Re: [mpich-discuss] attribute value of MPI_TAG_UB
by Wesley Bland 29 Apr '19

29 Apr '19

There’s been a lot of churn on the TAG_UB code in the last year or two, but I think it finally stabilized last October with this pull request: https://github.com/pmodels/mpich/pull/3111 <https://github.com/pmodels/mpich/pull/3111> Jeff was right. The value of TAG_UB will depend on a lot of things, but if you use the exact same configuration, hardware, and environment variables from run to run, it should be the same value every time. As long as your application is querying the value instead of assuming a static value, you’ll be fine. > On Apr 27, 2019, at 11:20 AM, Jeff Hammond via discuss <discuss(a)mpich.org> wrote: > > > > On Fri, Apr 26, 2019 at 12:18 PM Wei-keng Liao via discuss <discuss(a)mpich.org <mailto:[email protected]>> 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? > > I would expect it to be the same when running with the same options. It is possible that it will change for different numbers of processes. It is also possible that it changes based upon the network or which back-end is used (eg libfabric provider). > > > 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 don’t think that’s the value but the key used to query it. You need to call get_attr rather than look at this value. The key is meaningless by itself. > > Jeff > > > 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 <mailto:[email protected]> > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss <https://lists.mpich.org/mailman/listinfo/discuss> > -- > Jeff Hammond > jeff.science(a)gmail.com <mailto:[email protected]> > http://jeffhammond.github.io/ <http://jeffhammond.github.io/>_______________________________________________ > 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 snow cluster in R
by Benson Muite 27 Apr '19

27 Apr '19

Hi, Example linux and OpenMPI for pbdR (https://pbdr.org/) that you might be able to adapt is here: https://github.com/Digitaalhumanitaaria/biohpc May want to check with pbdR Regards, Benson On 4/27/19 8:44 PM, Mark Sale via discuss wrote: > > Anyone have any (Windows)ï¿½experience they can share on setting up a > cluster in Rï¿½(using Rmpi, or other Rï¿½package) and the snow package, > then using parallel? > > > thanks > > > > > Mark Sale M.D. > > Senior Vice President, Pharmacometrics > > Nuventra Inc. > 2525 Meridian Parkway, Suite 200 > Durham, NC 27713 > > Phone (919)-973-0383 > > msale(a)nuventra.com <msale(a)kinetigen.com> > > // > > CONFIDENTIALITY NOTICE The information in this transmittal (including > attachments, if any) may be privileged and confidential and is > intended only for the recipient(s) listed above. Any review, use, > disclosure, distribution or copying of this transmittal, in any form, > is prohibited except by or on behalf of the intended recipient(s). If > you have received this transmittal in error, please notify me > immediately by reply email and destroy all copies of the transmittal. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

MPI snow cluster in R
by Mark Sale 27 Apr '19

27 Apr '19

Anyone have any (Windows) experience they can share on setting up a cluster in R (using Rmpi, or other R package) and the snow package, then using parallel? thanks Mark Sale M.D. Senior Vice President, Pharmacometrics Nuventra Inc. 2525 Meridian Parkway, Suite 200 Durham, NC 27713 Phone (919)-973-0383 msale(a)nuventra.com<msale(a)kinetigen.com> CONFIDENTIALITY NOTICE The information in this transmittal (including attachments, if any) may be privileged and confidential and is intended only for the recipient(s) listed above. Any review, use, disclosure, distribution or copying of this transmittal, in any form, is prohibited except by or on behalf of the intended recipient(s). If you have received this transmittal in error, please notify me immediately by reply email and destroy all copies of the transmittal. ________________________________ From: Jeff Hammond via discuss <discuss(a)mpich.org> Sent: Saturday, April 27, 2019 9:20 AM To: discuss(a)mpich.org Cc: Jeff Hammond Subject: Re: [mpich-discuss] attribute value of MPI_TAG_UB WARNING: This email originated from outside of the company. Do not click links or open attachments unless you recognize the sender and are expecting the message. On Fri, Apr 26, 2019 at 12:18 PM Wei-keng Liao via discuss <discuss(a)mpich.org<mailto:[email protected]>> 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? I would expect it to be the same when running with the same options. It is possible that it will change for different numbers of processes. It is also possible that it changes based upon the network or which back-end is used (eg libfabric provider). 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 don’t think that’s the value but the key used to query it. You need to call get_attr rather than look at this value. The key is meaningless by itself. Jeff 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<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss -- Jeff Hammond jeff.science(a)gmail.com<mailto:[email protected]> http://jeffhammond.github.io/

1 0

Re: [mpich-discuss] attribute value of MPI_TAG_UB
by Jeff Hammond 27 Apr '19

27 Apr '19

On Fri, Apr 26, 2019 at 12: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? I would expect it to be the same when running with the same options. It is possible that it will change for different numbers of processes. It is also possible that it changes based upon the network or which back-end is used (eg libfabric provider). > 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 don’t think that’s the value but the key used to query it. You need to call get_attr rather than look at this value. The key is meaningless by itself. Jeff > 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 > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0