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

Re: [mpich-discuss] A few inconveniences with MPICH 3.3 build
by Martin Cuma 12 Feb '19

12 Feb '19

Thanks Brice for the tip, after some digging I found the appropriate spot to put these two options (enable_gl=no, enable_opencl=no) to src/pm/hydra/configure. MPICH developers - any chance this can be wrapped around the --without-x configure option, or hardcoded? Any takers on the SLURM question? Thanks, MC -- Martin Cuma Center for High Performance Computing Department of Geology and Geophysics University of Utah

1 0

Re: [mpich-discuss] A few inconveniences with MPICH 3.3 build
by Brice Goglin 12 Feb '19

12 Feb '19

Hello This might be caused by hwloc. hwloc links with libXNVCtrl when available (because some people wants hwloc to expose the locality a NVIDIA X11 displays). OpenMPI disables some hwloc backends by passing things like enable_gl=no before invoking hwloc's configury: https://github.com/open-mpi/ompi/blob/master/opal/mca/hwloc/hwloc201/config… enable_gl=no is the one that matters here, but others could be disabled in MPICH unless the corresponding objects are explicitly used in MPICH. Brice Le 12/02/2019 à 22:36, Martin Cuma via discuss a écrit : > Hi everyone, > > I was wondering if someone could give me a feedback on a couple of > quirks I found with MPICH 3.3, that I did not observe with 3.2.1. > > 1. If CUDA is found on a machine where MPICH is built, > /lib64/libXNVCtrl.so.0 gets included in the MPICH library (libmpi.so). > I tried the --without-x or --with-x=no options but it does not affect > this. If I build on a machine that does not have CUDA, > /lib64/libXNVCtrl.so.0 is not included and the library seems to work > the same (on typical MPI applications). > > This is annoying if we want to have a common MPICH for machines with > and without CUDA installed, e.g. compute node with and without GPUs. > > 2. It seems that MPICH now requires the --with-slurm option to pick up > the SLURM hostlist (= run w/o the -machinefile option). This was not > the case with 3.2.1, where mpich picked up the SLURM hostlist without > needing to be built with --with-slurm. The path to SLURM also gets > encoded in the RPATH of mpirun and friends. I'd rather control that > myself if possible. > > This is an inconvenience for us as well since we have different > clusters with SLURMs on different file systems/paths, and I'd like to > also use the same MPICH build on desktops that don't have SLURM at > all. I could put $ORIGIN to RPATH and stick that libslurm.so to the > MPICH bin directory, since we tend to run the same SLURM version on > all the clusters, but, still, it's clunky. > > Again, appreciate if someone could put some light to this or give some > good workarounds. > > Thanks, > MC >

1 0

A few inconveniences with MPICH 3.3 build
by Martin Cuma 12 Feb '19

12 Feb '19

Hi everyone, I was wondering if someone could give me a feedback on a couple of quirks I found with MPICH 3.3, that I did not observe with 3.2.1. 1. If CUDA is found on a machine where MPICH is built, /lib64/libXNVCtrl.so.0 gets included in the MPICH library (libmpi.so). I tried the --without-x or --with-x=no options but it does not affect this. If I build on a machine that does not have CUDA, /lib64/libXNVCtrl.so.0 is not included and the library seems to work the same (on typical MPI applications). This is annoying if we want to have a common MPICH for machines with and without CUDA installed, e.g. compute node with and without GPUs. 2. It seems that MPICH now requires the --with-slurm option to pick up the SLURM hostlist (= run w/o the -machinefile option). This was not the case with 3.2.1, where mpich picked up the SLURM hostlist without needing to be built with --with-slurm. The path to SLURM also gets encoded in the RPATH of mpirun and friends. I'd rather control that myself if possible. This is an inconvenience for us as well since we have different clusters with SLURMs on different file systems/paths, and I'd like to also use the same MPICH build on desktops that don't have SLURM at all. I could put $ORIGIN to RPATH and stick that libslurm.so to the MPICH bin directory, since we tend to run the same SLURM version on all the clusters, but, still, it's clunky. Again, appreciate if someone could put some light to this or give some good workarounds. Thanks, MC -- Martin Cuma Center for High Performance Computing Department of Geology and Geophysics University of Utah

1 0

Re: [mpich-discuss] Enabling X11 apps with MPICH
by Saurabh T 06 Feb '19

06 Feb '19

Uhh, never mind, a minute after hitting Send I realized I was using an older MPICH by mistake. This doesnt work in 3.0.x but works in 3.3. The HYDRA_LAUNCHER_EXTRA_ARGS is not needed either. saurabh From: Saurabh T Sent: Wednesday, February 6, 2019 1:44 PM To: discuss(a)mpich.org Subject: Enabling X11 apps with MPICH Hi, I am unable to get executables that open a GUI window working with MPICH. OpenMPI works fine: orterun --mca plm_rsh_agent "ssh -X -n" -np 3 xcalc brings up 3 xcalc windows. In MPICH (latest stable version 3.3), I tried HYDRA_LAUNCHER_EXTRA_ARGS="-X -n" mpiexec -np 3 xcalc but this fails with: X11 connection rejected because of wrong authentication. Error: Can't open display: localhost:10.0 Note: default hosts in both cases are the same and not the current machine. Does MPICH not allow X apps? saurabh

1 0

Enabling X11 apps with MPICH
by Saurabh T 06 Feb '19

06 Feb '19

Hi, I am unable to get executables that open a GUI window working with MPICH. OpenMPI works fine: orterun --mca plm_rsh_agent "ssh -X -n" -np 3 xcalc brings up 3 xcalc windows. In MPICH (latest stable version 3.3), I tried HYDRA_LAUNCHER_EXTRA_ARGS="-X -n" mpiexec -np 3 xcalc but this fails with: X11 connection rejected because of wrong authentication. Error: Can't open display: localhost:10.0 Note: default hosts in both cases are the same and not the current machine. Does MPICH not allow X apps? saurabh

1 0

Re: [mpich-discuss] finding the rank of processes from their environment?
by Raffenetti, Kenneth J. 04 Feb '19

04 Feb '19

We have discussed officially supporting exposing this information in the past here: https://github.com/pmodels/mpich/issues/2360. However, it is not actively being worked on. Your use case if helpful to confirm its need. Ken On 2/3/19 10:42 PM, Jeff Hammond via discuss wrote: > PMI_RANK and PMI_SIZE look to me like what you want and one of my Intel > colleagues had the same answer in response to a similar question > regarding Intel MPI, which also uses Hydra > (https://software.intel.com/en-us/forums/intel-clusters-and-hpc-technology/t…) > > I'm sure you know that all of this is non-standard and relying on it is > inherently non-portable. > > Jeff > > On Sun, Feb 3, 2019 at 1:40 PM Brice Goglin via discuss > <discuss(a)mpich.org <mailto:[email protected]>> wrote: > > Hello > > Is there a way to find out the rank of a process (in COMM_WORLD) by > looking at its environment? We use this feature in OpenMPI and srun for > displaying the placement of ranks in hwloc tools. By default, we display > the PID, but displaying the commworld rank is more useful. Looking in > /proc/<pid>/environ is an easy way to find environment variables, but I > could not find a clear solution for MPICH. > > I tried on several machines with different mpich installations. In one > case, I found a MPI_LOCALRANKID (which isn't exactly what I want but > could be sufficient). There's also PMI_RANK, which may be identical to > the commworld rank? > > Thanks for the help > > Brice > > > > _______________________________________________ > 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/ > > _______________________________________________ > 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] finding the rank of processes from their environment?
by Jeff Hammond 03 Feb '19

03 Feb '19

PMI_RANK and PMI_SIZE look to me like what you want and one of my Intel colleagues had the same answer in response to a similar question regarding Intel MPI, which also uses Hydra ( https://software.intel.com/en-us/forums/intel-clusters-and-hpc-technology/t… ). I'm sure you know that all of this is non-standard and relying on it is inherently non-portable. Jeff On Sun, Feb 3, 2019 at 1:40 PM Brice Goglin via discuss <discuss(a)mpich.org> wrote: > Hello > > Is there a way to find out the rank of a process (in COMM_WORLD) by > looking at its environment? We use this feature in OpenMPI and srun for > displaying the placement of ranks in hwloc tools. By default, we display > the PID, but displaying the commworld rank is more useful. Looking in > /proc/<pid>/environ is an easy way to find environment variables, but I > could not find a clear solution for MPICH. > > I tried on several machines with different mpich installations. In one > case, I found a MPI_LOCALRANKID (which isn't exactly what I want but > could be sufficient). There's also PMI_RANK, which may be identical to > the commworld rank? > > Thanks for the help > > Brice > > > > _______________________________________________ > 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

finding the rank of processes from their environment?
by Brice Goglin 03 Feb '19

03 Feb '19

Hello Is there a way to find out the rank of a process (in COMM_WORLD) by looking at its environment? We use this feature in OpenMPI and srun for displaying the placement of ranks in hwloc tools. By default, we display the PID, but displaying the commworld rank is more useful. Looking in /proc/<pid>/environ is an easy way to find environment variables, but I could not find a clear solution for MPICH. I tried on several machines with different mpich installations. In one case, I found a MPI_LOCALRANKID (which isn't exactly what I want but could be sufficient). There's also PMI_RANK, which may be identical to the commworld rank? Thanks for the help Brice

1 0

Re: [mpich-discuss] Another integer overflow
by Jeff Hammond 01 Feb '19

01 Feb '19

Thanks for reporting this. I'll file a bug report against Intel MPI 2019. Jeff On Thu, Jan 31, 2019 at 10:41 AM Joachim Protze via discuss < discuss(a)mpich.org> wrote: > Hi all, > > we found another integer overflow when using MPI_Sendrecv_replace, see > attached file. > When the buffer size exceeds MAX_INT, a segmentation fault occurs. > I could reproduce this with the MPICH 3.3a2 installation on my Ubuntu > desktop. > > @Jeff: I could reproduce the segfault as well as with IntelMPI 2018 > IntelMPI 2019 detects a message truncation > > > Best > Joachim > -- > Dipl.-Inf. Joachim Protze > > IT Center > Group: High Performance Computing > Division: Computational Science and Engineering > RWTH Aachen University > Seffenter Weg 23 > D 52074 Aachen (Germany) > Tel: +49 241 80- 24765 > Fax: +49 241 80-624765 > protze(a)itc.rwth-aachen.de > www.itc.rwth-aachen.de > _______________________________________________ > 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