September 2020 - discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] Spawns without mpirun
by Martín Morales 25 Sep '20

25 Sep '20

Hi Hui. About the "special (or interactive) mode" would be great! In relation to your frontend-backend suggestion that you propose, having a "proxy" process in that way might be an important code restructuring which we just can't do at the moment. Thank you very much anyway. Best regards, Martín <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Fri, Sep 25, 2020 at 12:58 PM Zhou, Hui <zhouh(a)anl.gov> wrote: > Hi Martin, > > > > I see. Yeah, MPICH (or the project manager hydra) will not work with > interactive programs nicely. It might be a potential interest to add a > special mode that project manager do not try to take over the input/output. > For now, is it possible for your ncurse application to spawn a separate > process (via `mpirun -n 1 …`) that can be used to spawn additional > processes? I am thinking that your interactive part can be programmed as > purely a frontend to your actual MPI processes. > > > > -- > Hui Zhou > > > > > > *From: *Martín Morales <martineduardomorales(a)gmail.com> > *Date: *Friday, September 25, 2020 at 9:09 AM > *To: *"discuss(a)mpich.org" <discuss(a)mpich.org>, "Zhou, Hui" <zhouh(a)anl.gov> > *Subject: *Re: [mpich-discuss] Spawns without mpirun > > > > Hi again Hui. My apologies, I overlooked your singleton analogie with > mpirun (*mpirun -n 1 ./prog...* ). Yes, in fact, it was one our first > tries. These program we use is interactive and requires the *ncurses *library > for that. I read some time ago a known problem with Open MPI implementation > and *ncurses*. Unfortunately with MPICH we've experienced the same issue. > > Best regards, > > > > Martín > > > > On Wed, Sep 23, 2020 at 9:28 PM Martín Morales < > martineduardomorales(a)gmail.com> wrote: > > Hi Hui, thank you for your reply. Ok I'll create that issue then. We've a > quite large PVM application. It has processes handling in a singleton > fashion that it allows powerful functionality. We needed to port the PVM > code to MPI in this exact way to preserve that functionality. We've done > this already but with the Open MPI implementation. However we've found some > inconsistencies in it and that's why I'm querying about this feature in > MPICH. > > Best regards > > > > Martín > > > > > > On Wed, Sep 23, 2020 at 8:31 PM Zhou, Hui <zhouh(a)anl.gov> wrote: > > It’s possible but not prioritized. Could you open an issue on github? When > we have enough users requesting the feature (or when we have persistent > user requesting it), the priority may be escalated. 😊 Meanwhile, could > you describe the scenario that you have to use singleton init (vs. `mpirun > -n 1 prog …`)? > > > > -- > Hui Zhou > > > > > > *From: *Martín Morales via discuss <discuss(a)mpich.org> > *Reply-To: *"discuss(a)mpich.org" <discuss(a)mpich.org> > *Date: *Wednesday, September 23, 2020 at 3:49 PM > *To: *"discuss(a)mpich.org" <discuss(a)mpich.org> > *Cc: *Martín Morales <martineduardomorales(a)gmail.com> > *Subject: *[mpich-discuss] Spawns without mpirun > > > > Hi all! > > I asked here some time ago about dynamically spawn processes from a > singleton but the answer was that unfortunately, there was a problem with > that and just It was not possible. I wonder now if this functionality is > available. > > Best regards > > > > Martín > > > > > > > > > > > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> > > Virus-free. www.avast.com > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> > > > >

1 0

Re: [mpich-discuss] Spawns without mpirun
by Zhou, Hui 25 Sep '20

25 Sep '20

Hi Martin, I see. Yeah, MPICH (or the project manager hydra) will not work with interactive programs nicely. It might be a potential interest to add a special mode that project manager do not try to take over the input/output. For now, is it possible for your ncurse application to spawn a separate process (via `mpirun -n 1 …`) that can be used to spawn additional processes? I am thinking that your interactive part can be programmed as purely a frontend to your actual MPI processes. -- Hui Zhou From: Martín Morales <martineduardomorales(a)gmail.com> Date: Friday, September 25, 2020 at 9:09 AM To: "discuss(a)mpich.org" <discuss(a)mpich.org>, "Zhou, Hui" <zhouh(a)anl.gov> Subject: Re: [mpich-discuss] Spawns without mpirun Hi again Hui. My apologies, I overlooked your singleton analogie with mpirun (mpirun -n 1 ./prog... ). Yes, in fact, it was one our first tries. These program we use is interactive and requires the ncurses library for that. I read some time ago a known problem with Open MPI implementation and ncurses. Unfortunately with MPICH we've experienced the same issue. Best regards, Martín On Wed, Sep 23, 2020 at 9:28 PM Martín Morales <martineduardomorales(a)gmail.com<mailto:[email protected]>> wrote: Hi Hui, thank you for your reply. Ok I'll create that issue then. We've a quite large PVM application. It has processes handling in a singleton fashion that it allows powerful functionality. We needed to port the PVM code to MPI in this exact way to preserve that functionality. We've done this already but with the Open MPI implementation. However we've found some inconsistencies in it and that's why I'm querying about this feature in MPICH. Best regards Martín On Wed, Sep 23, 2020 at 8:31 PM Zhou, Hui <zhouh(a)anl.gov<mailto:[email protected]>> wrote: It’s possible but not prioritized. Could you open an issue on github? When we have enough users requesting the feature (or when we have persistent user requesting it), the priority may be escalated. 😊 Meanwhile, could you describe the scenario that you have to use singleton init (vs. `mpirun -n 1 prog …`)? -- Hui Zhou From: Martín Morales via discuss <discuss(a)mpich.org<mailto:[email protected]>> Reply-To: "discuss(a)mpich.org<mailto:[email protected]>" <discuss(a)mpich.org<mailto:[email protected]>> Date: Wednesday, September 23, 2020 at 3:49 PM To: "discuss(a)mpich.org<mailto:[email protected]>" <discuss(a)mpich.org<mailto:[email protected]>> Cc: Martín Morales <martineduardomorales(a)gmail.com<mailto:[email protected]>> Subject: [mpich-discuss] Spawns without mpirun Hi all! I asked here some time ago about dynamically spawn processes from a singleton but the answer was that unfortunately, there was a problem with that and just It was not possible. I wonder now if this functionality is available. Best regards Martín [https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-anima…]<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free. www.avast.com<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…>

1 0

Re: [mpich-discuss] Spawns without mpirun
by Martín Morales 25 Sep '20

25 Sep '20

Hi again Hui. My apologies, I overlooked your singleton analogie with mpirun (*mpirun -n 1 ./prog...* ). Yes, in fact, it was one our first tries. These program we use is interactive and requires the *ncurses *library for that. I read some time ago a known problem with Open MPI implementation and *ncurses*. Unfortunately with MPICH we've experienced the same issue. Best regards, Martín On Wed, Sep 23, 2020 at 9:28 PM Martín Morales < martineduardomorales(a)gmail.com> wrote: > Hi Hui, thank you for your reply. Ok I'll create that issue then. We've a > quite large PVM application. It has processes handling in a singleton > fashion that it allows powerful functionality. We needed to port the PVM > code to MPI in this exact way to preserve that functionality. We've done > this already but with the Open MPI implementation. However we've found some > inconsistencies in it and that's why I'm querying about this feature in > MPICH. > Best regards > > Martín > > > On Wed, Sep 23, 2020 at 8:31 PM Zhou, Hui <zhouh(a)anl.gov> wrote: > >> It’s possible but not prioritized. Could you open an issue on github? >> When we have enough users requesting the feature (or when we have >> persistent user requesting it), the priority may be escalated. 😊 >> Meanwhile, could you describe the scenario that you have to use singleton >> init (vs. `mpirun -n 1 prog …`)? >> >> >> >> -- >> Hui Zhou >> >> >> >> >> >> *From: *Martín Morales via discuss <discuss(a)mpich.org> >> *Reply-To: *"discuss(a)mpich.org" <discuss(a)mpich.org> >> *Date: *Wednesday, September 23, 2020 at 3:49 PM >> *To: *"discuss(a)mpich.org" <discuss(a)mpich.org> >> *Cc: *Martín Morales <martineduardomorales(a)gmail.com> >> *Subject: *[mpich-discuss] Spawns without mpirun >> >> >> >> Hi all! >> >> I asked here some time ago about dynamically spawn processes from a >> singleton but the answer was that unfortunately, there was a problem with >> that and just It was not possible. I wonder now if this functionality is >> available. >> >> Best regards >> >> >> >> Martín >> >> >> >> >> >> >> >> >> >> >> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> >> >> Virus-free. www.avast.com >> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> >> >> >> >

1 0

Re: [mpich-discuss] Problem configuring mpich-3.4a3 and 3.4a2 --with-device=ch4:ucx
by Audet, Martin 23 Sep '20

23 Sep '20

Hello Zhou, Using simply –with-pmix=/usr as you suggested seems to work the same but is shorter and more elegant. I will use this formulation. Thanks for the suggestion, Martin Audet From: Zhou, Hui [mailto:[email protected]] Sent: Wednesday, September 23, 2020 19:25 To: Audet, Martin <Martin.Audet(a)cnrc-nrc.gc.ca>; discuss(a)mpich.org Subject: Re: [mpich-discuss] Problem configuring mpich-3.4a3 and 3.4a2 --with-device=ch4:ucx Hi Martin, Try `--with-pmix=/usr` -- Hui Zhou From: "Audet, Martin" <Martin.Audet(a)cnrc-nrc.gc.ca<mailto:[email protected]>> Date: Wednesday, September 23, 2020 at 4:38 PM To: "discuss(a)mpich.org<mailto:[email protected]>" <discuss(a)mpich.org<mailto:[email protected]>> Cc: "Zhou, Hui" <zhouh(a)anl.gov<mailto:[email protected]>> Subject: RE: [mpich-discuss] Problem configuring mpich-3.4a3 and 3.4a2 --with-device=ch4:ucx Thanks Zhou for your answer. Now when I add the following options: --with-pmix-include=/usr/include --with-pmix-lib=/usr/lib64 to my configuration options (just after --with-pmix) it works as expected (i.e. I am able to use the pmix mechanism in Slurm). However if I don’t provide --with-pmix, even if --with-pmix-include=/usr/include --with-pmix-lib=/usr/lib64 are provided, pmix is not used (and I have to use the pmi2 mechanism in Slurm). Regards, Martin Audet From: Zhou, Hui [mailto:[email protected]] Sent: Wednesday, September 23, 2020 9:47 To: discuss(a)mpich.org<mailto:[email protected]> Cc: Audet, Martin <Martin.Audet(a)cnrc-nrc.gc.ca<mailto:[email protected]>> Subject: Re: [mpich-discuss] Problem configuring mpich-3.4a3 and 3.4a2 --with-device=ch4:ucx > ./configure --with-device=ch4:ucx --with-hcoll=/opt/mellanox/hcoll --with-pmix --prefix=/home/publique/depot/mpi/mpich-ch4_ucx-3.4a3 --enable-fast=all --enable-romio --with-file-system=ufs+nfs --enable-shared --enable-sharedlibs=gcc I believe the offending option is `--with-pmix`, since that defaults to `--with-pmix=yes`. You are supposed to pass in the path to pmix installation, e.g. `--with-pmix=/usr/local`. I admit this is a bit not obvious. -- Hui Zhou From: "Audet, Martin via discuss" <discuss(a)mpich.org<mailto:[email protected]>> Reply-To: "discuss(a)mpich.org<mailto:[email protected]>" <discuss(a)mpich.org<mailto:[email protected]>> Date: Tuesday, September 22, 2020 at 9:41 PM To: "discuss(a)mpich.org<mailto:[email protected]>" <discuss(a)mpich.org<mailto:[email protected]>> Cc: "Audet, Martin" <Martin.Audet(a)cnrc-nrc.gc.ca<mailto:[email protected]>> Subject: [mpich-discuss] Problem configuring mpich-3.4a3 and 3.4a2 --with-device=ch4:ucx Hello MPICH_Developers, I am having trouble running the configure script on two latest mpich release (3.4a2 and 3.4a3) when I use the flag --with-device=ch4:ucx (no such problems with ch3:sock or ch3:nemesis). It seems that the generated Makefile often contains two strange compilation and link flags: -Iyes/include and –Lyes/lib. To be able to compile the library I had to use the following command to remove those strange flags: find . -name Makefile -exec sed -i -e 's/-Iyes\/include\>//g' -e 's/-Lyes\/lib\>//g' {} \; After this step I am able to compile and the resulting library seems ok and appears to performs well (not extensive testing). For your information I call the configure script like this: ./configure --with-device=ch4:ucx --with-hcoll=/opt/mellanox/hcoll --with-pmix --prefix=/home/publique/depot/mpi/mpich-ch4_ucx-3.4a3 --enable-fast=all --enable-romio --with-file-system=ufs+nfs --enable-shared --enable-sharedlibs=gcc I had experienced this problem on the following three configurations: mpich-3.4a2 CentOS 7.6 MOFED 4.7 mpich-3.4a3 CentOS 7.6 MOFED 4.7 mpich-3.4a3 CentOS 7.8 MOFED 4.9 The architecture is x86_64. Could someone take a look at this problem ? Thanks, Martin Audet

1 0

Re: [mpich-discuss] Spawns without mpirun
by Martín Morales 23 Sep '20

23 Sep '20

Hi Hui, thank you for your reply. Ok I'll create that issue then. We've a quite large PVM application. It has processes handling in a singleton fashion that it allows powerful functionality. We needed to port the PVM code to MPI in this exact way to preserve that functionality. We've done this already but with the Open MPI implementation. However we've found some inconsistencies in it and that's why I'm querying about this feature in MPICH. Best regards Martín On Wed, Sep 23, 2020 at 8:31 PM Zhou, Hui <zhouh(a)anl.gov> wrote: > It’s possible but not prioritized. Could you open an issue on github? When > we have enough users requesting the feature (or when we have persistent > user requesting it), the priority may be escalated. 😊 Meanwhile, could > you describe the scenario that you have to use singleton init (vs. `mpirun > -n 1 prog …`)? > > > > -- > Hui Zhou > > > > > > *From: *Martín Morales via discuss <discuss(a)mpich.org> > *Reply-To: *"discuss(a)mpich.org" <discuss(a)mpich.org> > *Date: *Wednesday, September 23, 2020 at 3:49 PM > *To: *"discuss(a)mpich.org" <discuss(a)mpich.org> > *Cc: *Martín Morales <martineduardomorales(a)gmail.com> > *Subject: *[mpich-discuss] Spawns without mpirun > > > > Hi all! > > I asked here some time ago about dynamically spawn processes from a > singleton but the answer was that unfortunately, there was a problem with > that and just It was not possible. I wonder now if this functionality is > available. > > Best regards > > > > Martín > > > > > > > > > > > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> > > Virus-free. www.avast.com > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> > > >

1 0

Re: [mpich-discuss] Spawns without mpirun
by Zhou, Hui 23 Sep '20

23 Sep '20

It’s possible but not prioritized. Could you open an issue on github? When we have enough users requesting the feature (or when we have persistent user requesting it), the priority may be escalated. 😊 Meanwhile, could you describe the scenario that you have to use singleton init (vs. `mpirun -n 1 prog …`)? -- Hui Zhou From: Martín Morales via discuss <discuss(a)mpich.org> Reply-To: "discuss(a)mpich.org" <discuss(a)mpich.org> Date: Wednesday, September 23, 2020 at 3:49 PM To: "discuss(a)mpich.org" <discuss(a)mpich.org> Cc: Martín Morales <martineduardomorales(a)gmail.com> Subject: [mpich-discuss] Spawns without mpirun Hi all! I asked here some time ago about dynamically spawn processes from a singleton but the answer was that unfortunately, there was a problem with that and just It was not possible. I wonder now if this functionality is available. Best regards Martín [https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-anima…]<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free. www.avast.com<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…>

1 0

Re: [mpich-discuss] Problem configuring mpich-3.4a3 and 3.4a2 --with-device=ch4:ucx
by Zhou, Hui 23 Sep '20

23 Sep '20

Hi Martin, Try `--with-pmix=/usr` -- Hui Zhou From: "Audet, Martin" <Martin.Audet(a)cnrc-nrc.gc.ca> Date: Wednesday, September 23, 2020 at 4:38 PM To: "discuss(a)mpich.org" <discuss(a)mpich.org> Cc: "Zhou, Hui" <zhouh(a)anl.gov> Subject: RE: [mpich-discuss] Problem configuring mpich-3.4a3 and 3.4a2 --with-device=ch4:ucx Thanks Zhou for your answer. Now when I add the following options: --with-pmix-include=/usr/include --with-pmix-lib=/usr/lib64 to my configuration options (just after --with-pmix) it works as expected (i.e. I am able to use the pmix mechanism in Slurm). However if I don’t provide --with-pmix, even if --with-pmix-include=/usr/include --with-pmix-lib=/usr/lib64 are provided, pmix is not used (and I have to use the pmi2 mechanism in Slurm). Regards, Martin Audet From: Zhou, Hui [mailto:[email protected]] Sent: Wednesday, September 23, 2020 9:47 To: discuss(a)mpich.org Cc: Audet, Martin <Martin.Audet(a)cnrc-nrc.gc.ca> Subject: Re: [mpich-discuss] Problem configuring mpich-3.4a3 and 3.4a2 --with-device=ch4:ucx > ./configure --with-device=ch4:ucx --with-hcoll=/opt/mellanox/hcoll --with-pmix --prefix=/home/publique/depot/mpi/mpich-ch4_ucx-3.4a3 --enable-fast=all --enable-romio --with-file-system=ufs+nfs --enable-shared --enable-sharedlibs=gcc I believe the offending option is `--with-pmix`, since that defaults to `--with-pmix=yes`. You are supposed to pass in the path to pmix installation, e.g. `--with-pmix=/usr/local`. I admit this is a bit not obvious. -- Hui Zhou From: "Audet, Martin via discuss" <discuss(a)mpich.org<mailto:[email protected]>> Reply-To: "discuss(a)mpich.org<mailto:[email protected]>" <discuss(a)mpich.org<mailto:[email protected]>> Date: Tuesday, September 22, 2020 at 9:41 PM To: "discuss(a)mpich.org<mailto:[email protected]>" <discuss(a)mpich.org<mailto:[email protected]>> Cc: "Audet, Martin" <Martin.Audet(a)cnrc-nrc.gc.ca<mailto:[email protected]>> Subject: [mpich-discuss] Problem configuring mpich-3.4a3 and 3.4a2 --with-device=ch4:ucx Hello MPICH_Developers, I am having trouble running the configure script on two latest mpich release (3.4a2 and 3.4a3) when I use the flag --with-device=ch4:ucx (no such problems with ch3:sock or ch3:nemesis). It seems that the generated Makefile often contains two strange compilation and link flags: -Iyes/include and –Lyes/lib. To be able to compile the library I had to use the following command to remove those strange flags: find . -name Makefile -exec sed -i -e 's/-Iyes\/include\>//g' -e 's/-Lyes\/lib\>//g' {} \; After this step I am able to compile and the resulting library seems ok and appears to performs well (not extensive testing). For your information I call the configure script like this: ./configure --with-device=ch4:ucx --with-hcoll=/opt/mellanox/hcoll --with-pmix --prefix=/home/publique/depot/mpi/mpich-ch4_ucx-3.4a3 --enable-fast=all --enable-romio --with-file-system=ufs+nfs --enable-shared --enable-sharedlibs=gcc I had experienced this problem on the following three configurations: mpich-3.4a2 CentOS 7.6 MOFED 4.7 mpich-3.4a3 CentOS 7.6 MOFED 4.7 mpich-3.4a3 CentOS 7.8 MOFED 4.9 The architecture is x86_64. Could someone take a look at this problem ? Thanks, Martin Audet

1 0

Re: [mpich-discuss] Problem configuring mpich-3.4a3 and 3.4a2 --with-device=ch4:ucx
by Audet, Martin 23 Sep '20

23 Sep '20

Thanks Zhou for your answer. Now when I add the following options: --with-pmix-include=/usr/include --with-pmix-lib=/usr/lib64 to my configuration options (just after --with-pmix) it works as expected (i.e. I am able to use the pmix mechanism in Slurm). However if I don’t provide --with-pmix, even if --with-pmix-include=/usr/include --with-pmix-lib=/usr/lib64 are provided, pmix is not used (and I have to use the pmi2 mechanism in Slurm). Regards, Martin Audet From: Zhou, Hui [mailto:[email protected]] Sent: Wednesday, September 23, 2020 9:47 To: discuss(a)mpich.org Cc: Audet, Martin <Martin.Audet(a)cnrc-nrc.gc.ca> Subject: Re: [mpich-discuss] Problem configuring mpich-3.4a3 and 3.4a2 --with-device=ch4:ucx > ./configure --with-device=ch4:ucx --with-hcoll=/opt/mellanox/hcoll --with-pmix --prefix=/home/publique/depot/mpi/mpich-ch4_ucx-3.4a3 --enable-fast=all --enable-romio --with-file-system=ufs+nfs --enable-shared --enable-sharedlibs=gcc I believe the offending option is `--with-pmix`, since that defaults to `--with-pmix=yes`. You are supposed to pass in the path to pmix installation, e.g. `--with-pmix=/usr/local`. I admit this is a bit not obvious. -- Hui Zhou From: "Audet, Martin via discuss" <discuss(a)mpich.org<mailto:[email protected]>> Reply-To: "discuss(a)mpich.org<mailto:[email protected]>" <discuss(a)mpich.org<mailto:[email protected]>> Date: Tuesday, September 22, 2020 at 9:41 PM To: "discuss(a)mpich.org<mailto:[email protected]>" <discuss(a)mpich.org<mailto:[email protected]>> Cc: "Audet, Martin" <Martin.Audet(a)cnrc-nrc.gc.ca<mailto:[email protected]>> Subject: [mpich-discuss] Problem configuring mpich-3.4a3 and 3.4a2 --with-device=ch4:ucx Hello MPICH_Developers, I am having trouble running the configure script on two latest mpich release (3.4a2 and 3.4a3) when I use the flag --with-device=ch4:ucx (no such problems with ch3:sock or ch3:nemesis). It seems that the generated Makefile often contains two strange compilation and link flags: -Iyes/include and –Lyes/lib. To be able to compile the library I had to use the following command to remove those strange flags: find . -name Makefile -exec sed -i -e 's/-Iyes\/include\>//g' -e 's/-Lyes\/lib\>//g' {} \; After this step I am able to compile and the resulting library seems ok and appears to performs well (not extensive testing). For your information I call the configure script like this: ./configure --with-device=ch4:ucx --with-hcoll=/opt/mellanox/hcoll --with-pmix --prefix=/home/publique/depot/mpi/mpich-ch4_ucx-3.4a3 --enable-fast=all --enable-romio --with-file-system=ufs+nfs --enable-shared --enable-sharedlibs=gcc I had experienced this problem on the following three configurations: mpich-3.4a2 CentOS 7.6 MOFED 4.7 mpich-3.4a3 CentOS 7.6 MOFED 4.7 mpich-3.4a3 CentOS 7.8 MOFED 4.9 The architecture is x86_64. Could someone take a look at this problem ? Thanks, Martin Audet

1 0

Spawns without mpirun
by Martín Morales 23 Sep '20

23 Sep '20

Hi all! I asked here some time ago about dynamically spawn processes from a singleton but the answer was that unfortunately, there was a problem with that and just It was not possible. I wonder now if this functionality is available. Best regards Martín <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

1 0

Re: [mpich-discuss] Problem configuring mpich-3.4a3 and 3.4a2 --with-device=ch4:ucx
by Zhou, Hui 23 Sep '20

23 Sep '20

> ./configure --with-device=ch4:ucx --with-hcoll=/opt/mellanox/hcoll --with-pmix --prefix=/home/publique/depot/mpi/mpich-ch4_ucx-3.4a3 --enable-fast=all --enable-romio --with-file-system=ufs+nfs --enable-shared --enable-sharedlibs=gcc I believe the offending option is `--with-pmix`, since that defaults to `--with-pmix=yes`. You are supposed to pass in the path to pmix installation, e.g. `--with-pmix=/usr/local`. I admit this is a bit not obvious. -- Hui Zhou From: "Audet, Martin via discuss" <discuss(a)mpich.org> Reply-To: "discuss(a)mpich.org" <discuss(a)mpich.org> Date: Tuesday, September 22, 2020 at 9:41 PM To: "discuss(a)mpich.org" <discuss(a)mpich.org> Cc: "Audet, Martin" <Martin.Audet(a)cnrc-nrc.gc.ca> Subject: [mpich-discuss] Problem configuring mpich-3.4a3 and 3.4a2 --with-device=ch4:ucx Hello MPICH_Developers, I am having trouble running the configure script on two latest mpich release (3.4a2 and 3.4a3) when I use the flag --with-device=ch4:ucx (no such problems with ch3:sock or ch3:nemesis). It seems that the generated Makefile often contains two strange compilation and link flags: -Iyes/include and –Lyes/lib. To be able to compile the library I had to use the following command to remove those strange flags: find . -name Makefile -exec sed -i -e 's/-Iyes\/include\>//g' -e 's/-Lyes\/lib\>//g' {} \; After this step I am able to compile and the resulting library seems ok and appears to performs well (not extensive testing). For your information I call the configure script like this: ./configure --with-device=ch4:ucx --with-hcoll=/opt/mellanox/hcoll --with-pmix --prefix=/home/publique/depot/mpi/mpich-ch4_ucx-3.4a3 --enable-fast=all --enable-romio --with-file-system=ufs+nfs --enable-shared --enable-sharedlibs=gcc I had experienced this problem on the following three configurations: mpich-3.4a2 CentOS 7.6 MOFED 4.7 mpich-3.4a3 CentOS 7.6 MOFED 4.7 mpich-3.4a3 CentOS 7.8 MOFED 4.9 The architecture is x86_64. Could someone take a look at this problem ? Thanks, Martin Audet

1 0