January 2015 - discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] mpich2 1.5: failing tests src/mpe2
by Giordano Lipari 13 Jan '15

13 Jan '15

I do have mpich 3.1.2 installed but I specifically installed mpich2 on request of another application that uses it. The version of mpich2 available from the Ubuntu repository is 1.4.1. I actually downloaded my mpchi2 1-5 from http://www.mpich.org/static/downloads/ in the understanding that this is the most recent available (last modified April 2013). How does this additional information change the picture? From: Wesley Bland <wbland(a)anl.gov> To: Giordano Lipari <giordano_lipari(a)yahoo.co.uk>; "discuss(a)mpich.org" <discuss(a)mpich.org> Sent: Tuesday, 13 January 2015, 20:15 Subject: Re: [mpich-discuss] mpich2 1.5: failing tests src/mpe2 Have you tried updating to the latest version of MPICH? Our current version is 3.1.3. The version you are using is years old so we'll have a hard time helping you fix any issues. Thanks,Wesley On Tue, Jan 13, 2015 at 1:13 PM, Giordano Lipari <giordano_lipari(a)yahoo.co.uk> wrote: I have installed mpchi2-1.5 in my Linux desktop (Ubuntu 12.04 LTS 64-bit) with the standard command sequence sudo ./configure --prefix=$MOUNTDIR sudo make sudo make install sudo make check The following 9 tests of the check in src/mpe2 fail:*** Test C program with the MPI tracing library .......................... No. *** Test C program with the MPI logging library .......................... No. *** Test C program with the MPI and manual logging libraries ............. No. *** Test F77 program with the MPI and manual logging libraries ........... No. *** Test C program with the MPI animation library ........................ No. *** Test C program with the X11 graphics library ......................... No. *** Test F77 program with the X11 graphics library ....................... No. *** Test C program with the MPI collective/datatype checking library ..... No. *** Test F77 program with the MPI collective/datatype checking library ... No. The entire stdout and stderr outputs are enclosed as attachment.My question is whether this is the regular behaviour and, if not, how I fix this.Thanks for helping me out! _______________________________________________ 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] mpich2 1.5: failing tests src/mpe2
by Wesley Bland 13 Jan '15

13 Jan '15

Have you tried updating to the latest version of MPICH? Our current version is 3.1.3. The version you are using is years old so we'll have a hard time helping you fix any issues. Thanks, Wesley On Tue, Jan 13, 2015 at 1:13 PM, Giordano Lipari < giordano_lipari(a)yahoo.co.uk> wrote: > I have installed mpchi2-1.5 in my Linux desktop (Ubuntu 12.04 LTS > 64-bit) with the standard command sequence > > sudo ./configure --prefix=$MOUNTDIR > sudo make > sudo make install > sudo make check > > The following 9 tests of the check in src/mpe2 fail: > *** Test C program with the MPI tracing library .......................... > No. > *** Test C program with the MPI logging library .......................... > No. > *** Test C program with the MPI and manual logging libraries ............. > No. > *** Test F77 program with the MPI and manual logging libraries ........... > No. > *** Test C program with the MPI animation library ........................ > No. > *** Test C program with the X11 graphics library ......................... > No. > *** Test F77 program with the X11 graphics library ....................... > No. > *** Test C program with the MPI collective/datatype checking library ..... > No. > *** Test F77 program with the MPI collective/datatype checking library ... > No. > > The entire stdout and stderr outputs are enclosed as attachment. > My question is whether this is the regular behaviour and, if not, how I > fix this. > Thanks for helping me out! > > _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

mpich2 1.5: failing tests src/mpe2
by Giordano Lipari 13 Jan '15

13 Jan '15

I have installed mpchi2-1.5 in my Linux desktop (Ubuntu 12.04 LTS 64-bit) with the standard command sequence sudo ./configure --prefix=$MOUNTDIR sudo make sudo make install sudo make check The following 9 tests of the check in src/mpe2 fail:*** Test C program with the MPI tracing library .......................... No. *** Test C program with the MPI logging library .......................... No. *** Test C program with the MPI and manual logging libraries ............. No. *** Test F77 program with the MPI and manual logging libraries ........... No. *** Test C program with the MPI animation library ........................ No. *** Test C program with the X11 graphics library ......................... No. *** Test F77 program with the X11 graphics library ....................... No. *** Test C program with the MPI collective/datatype checking library ..... No. *** Test F77 program with the MPI collective/datatype checking library ... No. The entire stdout and stderr outputs are enclosed as attachment.My question is whether this is the regular behaviour and, if not, how I fix this.Thanks for helping me out! _______________________________________________ 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] [OMPI users] OpenMPI 1.8.4rc3, 1.6.5 and 1.6.3: segmentation violation in mca_io_romio_dist_MPI_File_close
by Rob Latham 12 Jan '15

12 Jan '15

On 12/17/2014 07:04 PM, Eric Chamberland wrote: > Hi! > > Here is a "poor man's fix" that works for me (the idea is not from me, > thanks to Thomas H.): > > #1- char* lCwd = getcwd(0,0); > #2- chdir(lPathToFile); > #3- MPI_File_open(...,lFileNameWithoutTooLongPath,...); > #4- chdir(lCwd); > #5- ... > > I think there are some limitations but it works very well for our > uses... and until a "real" fix is proposed... A bit of a delay on my part due to the winter break but I have returned to this topic. I have an approach that will at least tell you something went wrong in processing the shared file pointer name: the string is so long it truncates the error message, but it leaves enough to tell you what went wrong. ERROR Returned by MPI: 1006695702 ERROR_string Returned by MPI: Invalid file name, error stack: ADIOI_Shfp_fname(60): Pathname this/is/a_very/long/path/that/contains/a/not/so/long/filename /but/trying/to/collectively/mpi_file_open/it/you/will/have/a/memory/corruption/resulting/of/ invalide/writing/or/reading/past/the/end/of/one/or/some/hidden/strings/in/mpio/Simpimple/use r At least you get "invalid file name" Furthermore, I'm changing that code to use PATH_MAX, not 256, which would have fixed the specific problem you encountered (and might have been sufficient to get us 10 more years, at which point someone might try to create a file with 1000 characters in it) ==rob > > Thanks for helping! > > Eric > > > On 12/15/2014 11:42 PM, Gilles Gouaillardet wrote: >> Eric and all, >> >> That is clearly a limitation in romio, and this is being tracked at >> https://trac.mpich.org/projects/mpich/ticket/2212 >> >> in the mean time, what we can do in OpenMPI is update >> mca_io_romio_file_open() and fails with a user friendly error message >> if strlen(filename) is larger that 225. >> >> Cheers, >> >> Gilles >> >> On 2014/12/16 12:43, Gilles Gouaillardet wrote: >>> Eric, >>> >>> thanks for the simple test program. >>> >>> i think i see what is going wrong and i will make some changes to avoid >>> the memory overflow. >>> >>> that being said, there is a hard coded limit of 256 characters, and your >>> path is bigger than 300 characters. >>> bottom line, and even if there is no more memory overflow, that cannot >>> work as expected. >>> >>> i will report this to the mpich folks, since romio is currently imported >>> from mpich. >>> >>> Cheers, >>> >>> Gilles >>> >>> On 2014/12/16 0:16, Eric Chamberland wrote: >>>> Hi Gilles, >>>> >>>> just created a very simple test case! >>>> >>>> with this setup, you will see the bug with valgrind: >>>> >>>> export >>>> too_long=./this/is/a_very/long/path/that/contains/a/not/so/long/filename/but/trying/to/collectively/mpi_file_open/it/you/will/have/a/memory/corruption/resulting/of/invalide/writing/or/reading/past/the/end/of/one/or/some/hidden/strings/in/mpio/Simple/user/would/like/to/have/the/parameter/checked/and/an/error/returned/or/this/limit/removed >>>> >>>> >>>> mpicc -o bug_MPI_File_open_path_too_long >>>> bug_MPI_File_open_path_too_long.c >>>> >>>> mkdir -p $too_long >>>> echo "header of a text file" > $too_long/toto.txt >>>> >>>> mpirun -np 2 valgrind ./bug_MPI_File_open_path_too_long >>>> $too_long/toto.txt >>>> >>>> and watch the errors! >>>> >>>> unfortunately, the memory corruptions here doesn't seem to segfault >>>> this simple test case, but in my case, it is fatal and with valgrind, >>>> it is reported... >>>> >>>> OpenMPI 1.6.5, 1.8.3rc3 are affected >>>> >>>> MPICH-3.1.3 also have the error! >>>> >>>> thanks, >>>> >>>> Eric >>>> >>> _______________________________________________ >>> users mailing list >>> users(a)open-mpi.org >>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users >>> Link to this post: >>> http://www.open-mpi.org/community/lists/users/2014/12/26005.php >> _______________________________________________ >> users mailing list >> users(a)open-mpi.org >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users >> Link to this post: >> http://www.open-mpi.org/community/lists/users/2014/12/26006.php > -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA _______________________________________________ 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] Fwd: mpiexec.hydra creates unexpectable TCP socket.
by Anatoly G 11 Jan '15

11 Jan '15

Dear Wesley. I asked the developers which saw this strange configuration and they not sure about MPI_Prog processes. These are "calculation processes" which may fail. I need to check it by myself if there is any failure of MPI_Prog processes. I suppose that MPI_Prog processes (created by mpiexec.hydra) didn't fail but failed Main application process which created mpiexec.hydra process. I know that my story looks strange. I suppose, there is no dependencies between Main application and mpiexec.hydra after hydra process created. I'll try to reach more information & details. Regards, Anatoly. On Wed, Jan 7, 2015 at 5:33 PM, Wesley Bland <wbland(a)anl.gov> wrote: > Are all of the processes in your application aborting or just a subset? > > On Wed, Jan 7, 2015 at 5:06 AM, Anatoly G <anatolyrishon(a)gmail.com> wrote: > >> Hello, Wesley. >> I think my previous mail was not clear enough. >> >> The system has following processes: >> >> - Application (Main) - this process executes: >> execvp with parameters mpiexec.hydra -genvall -disable-auto-cleanup >> -f MpiConfigMachines.txt -launcher=ssh -n 3 MPI_Prog >> - MPI_Prog - this program performs calculations. It's instances >> (processes) created by mpiexec.hydra. >> >> After some execution time, code of Application (Main) calls "abort()" >> function and fails without sending SIG_TERM to mpiexec.hydra process. >> >> I understand that this is a bug. It will be fixed by Application >> developers. >> >> But, after wrong Application termination mpiexec.hydra's father becomes >> init process. This is ok. >> >> But then I see via netstat that mpiexec.hydra starts sockets with other >> process (called Controller), which was not part of MPI execution. >> >> Is hydra tries to establish/restore connection with it's father (killed >> Application) process. >> >> I understand that this is an emergency and unexpected mpiexec.hydra >> usage. >> >> I was sure that mpiexec.hydra will not respond to Application fail and >> will behave exactly like Application process still exist. >> >> May be you can explain this strange situation. >> >> Regards, >> >> Anatoly. >> >> >> On Mon, Jan 5, 2015 at 7:09 PM, Wesley Bland <wbland(a)anl.gov> wrote: >> >>> When you pass -disable-auto-cleanup on the command line to mpiexec, >>> you’re telling Hydra not to clean up other processes when one process in >>> your job fails. It’s assumed that those processes will either clean >>> themselves up or complete successfully. >>> >>> It’s not clear to me what your program is trying to do that would be >>> erroneous, but usually when a process crashes, it’s the result of an >>> erroneous program rather than a bug in MPICH. I’m not saying that there’s >>> no bugs in MPICH, but we’d like to be able to narrow down where to look. >>> >>> Thanks, >>> Wesley >>> >>> >>> On Thu, Jan 1, 2015 at 6:35 AM, Anatoly G <anatolyrishon(a)gmail.com> >>> wrote: >>> >>>> Dear MPICH. >>>> I have an additional information. >>>> This "strange configuration" (hydra connected to computer not from the >>>> list) is result of unhandled Main process fail (similar to abort() >>>> call) without killing children process (hydra). >>>> Thus I can see "init" process becomes a father of hydra process. >>>> Can you please refer me to document explaining hydra behavior when >>>> father process is dead (an emergency situation). >>>> I understand that this situation shouldn't happen and this bug will be >>>> fixed, but I'm curious about the hydra logic. >>>> >>>> Regards, >>>> Anatoly. >>>> >>>> ---------- Forwarded message ---------- >>>> From: Anatoly G <anatolyrishon(a)gmail.com> >>>> Date: Wed, Dec 24, 2014 at 1:00 PM >>>> Subject: mpiexec.hydra creates unexpectable TCP socket. >>>> To: discuss(a)mpich.org >>>> >>>> >>>> Dear MPICH. >>>> I'm using mpich 3.1 (hydra+MPI). >>>> I execute main application (Main) which calls mpiexec.hydra in >>>> following way: >>>> >>>> mpiexec.hydra -genvall -disable-auto-cleanup -f MpiConfigMachines. >>>> txt -launcher=ssh -n 3 MPI_Prog >>>> >>>> MpiConfigMachines.txt content: >>>> 10.3.2.100:1 >>>> 10.3.2.101:2 >>>> >>>> Where 10.3.2.100 is a local host. >>>> As result I get >>>> >>>> - Main + single MPI_Prog processes on local computer >>>> - 2 MPI_Prog processes on remote one. >>>> >>>> Main application establish TCP socket with local MPI_Prog. >>>> Main application establish TCP socket with controller on other >>>> computer 10.3.2.170, which is not included in MpiConfigMachines.txt >>>> file. >>>> >>>> After executing some time (hours, sometimes days) I see via netstat >>>> that created new connection from mpiexec.hydra and controller. >>>> >>>> Before executing mpiexec.hydra I set environment variable >>>> >>>> setenv MPIEXEC_PORT_RANGE 50010:65535 >>>> >>>> According to manual this variable limits hydra destination ports to >>>> [50010:65535]. >>>> >>>> >>>> I see that hydra uses these ports with MPI_Prog, but connection with >>>> controller done on port 701 (controller computer). >>>> >>>> >>>> Controller program is a server. It can accept connections only. >>>> >>>> >>>> Can you please advice how to stand with this problem? >>>> >>>> How hydra recognizes controller IP and establish connection with it? >>>> >>>> >>>> Sincerely, >>>> >>>> Anatoly. >>>> >>>> >>>> >>> >>> _______________________________________________ >>> 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] help
by Seo, Sangmin 08 Jan '15

08 Jan '15

Dear Asal, I don’t see your problem when I build MPICH 3.1.3. Can you try to rebuild it from the clean copy of MPICH 3.1.3? Then, if you run into the same issue again, please send us m.txt, c.txt, and config.log. Thanks, Sangmin On Jan 8, 2015, at 5:17 AM, asal lili <asallili22(a)yahoo.com<mailto:[email protected]>> wrote: Dear Sir/Madam, I have a problem regarding installing MPICH package in the "make" step as "https://lists.mpich.org/mailman/listinfo/discuss". I attach the txt files as well. I appreciate if you can help me with this issue. Thanks, Best, Asal <m.txt><c.txt>_______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> 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

help
by asal lili 08 Jan '15

08 Jan '15

Dear Sir/Madam,I have a problem regarding installing MPICH package in the "make" step as "https://lists.mpich.org/mailman/listinfo/discuss".I attach the txt files as well. I appreciate if you can help me with this issue. Thanks,Best,Asal _______________________________________________ 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] Fwd: mpiexec.hydra creates unexpectable TCP socket.
by Wesley Bland 07 Jan '15

07 Jan '15

Are all of the processes in your application aborting or just a subset? On Wed, Jan 7, 2015 at 5:06 AM, Anatoly G <anatolyrishon(a)gmail.com> wrote: > Hello, Wesley. > I think my previous mail was not clear enough. > > The system has following processes: > > - Application (Main) - this process executes: > execvp with parameters mpiexec.hydra -genvall -disable-auto-cleanup > -f MpiConfigMachines.txt -launcher=ssh -n 3 MPI_Prog > - MPI_Prog - this program performs calculations. It's instances > (processes) created by mpiexec.hydra. > > After some execution time, code of Application (Main) calls "abort()" > function and fails without sending SIG_TERM to mpiexec.hydra process. > > I understand that this is a bug. It will be fixed by Application > developers. > > But, after wrong Application termination mpiexec.hydra's father becomes > init process. This is ok. > > But then I see via netstat that mpiexec.hydra starts sockets with other > process (called Controller), which was not part of MPI execution. > > Is hydra tries to establish/restore connection with it's father (killed > Application) process. > > I understand that this is an emergency and unexpected mpiexec.hydra > usage. > > I was sure that mpiexec.hydra will not respond to Application fail and > will behave exactly like Application process still exist. > > May be you can explain this strange situation. > > Regards, > > Anatoly. > > > On Mon, Jan 5, 2015 at 7:09 PM, Wesley Bland <wbland(a)anl.gov> wrote: > >> When you pass -disable-auto-cleanup on the command line to mpiexec, >> you’re telling Hydra not to clean up other processes when one process in >> your job fails. It’s assumed that those processes will either clean >> themselves up or complete successfully. >> >> It’s not clear to me what your program is trying to do that would be >> erroneous, but usually when a process crashes, it’s the result of an >> erroneous program rather than a bug in MPICH. I’m not saying that there’s >> no bugs in MPICH, but we’d like to be able to narrow down where to look. >> >> Thanks, >> Wesley >> >> >> On Thu, Jan 1, 2015 at 6:35 AM, Anatoly G <anatolyrishon(a)gmail.com> >> wrote: >> >>> Dear MPICH. >>> I have an additional information. >>> This "strange configuration" (hydra connected to computer not from the >>> list) is result of unhandled Main process fail (similar to abort() >>> call) without killing children process (hydra). >>> Thus I can see "init" process becomes a father of hydra process. >>> Can you please refer me to document explaining hydra behavior when >>> father process is dead (an emergency situation). >>> I understand that this situation shouldn't happen and this bug will be >>> fixed, but I'm curious about the hydra logic. >>> >>> Regards, >>> Anatoly. >>> >>> ---------- Forwarded message ---------- >>> From: Anatoly G <anatolyrishon(a)gmail.com> >>> Date: Wed, Dec 24, 2014 at 1:00 PM >>> Subject: mpiexec.hydra creates unexpectable TCP socket. >>> To: discuss(a)mpich.org >>> >>> >>> Dear MPICH. >>> I'm using mpich 3.1 (hydra+MPI). >>> I execute main application (Main) which calls mpiexec.hydra in >>> following way: >>> >>> mpiexec.hydra -genvall -disable-auto-cleanup -f MpiConfigMachines.txt >>> -launcher=ssh -n 3 MPI_Prog >>> >>> MpiConfigMachines.txt content: >>> 10.3.2.100:1 >>> 10.3.2.101:2 >>> >>> Where 10.3.2.100 is a local host. >>> As result I get >>> >>> - Main + single MPI_Prog processes on local computer >>> - 2 MPI_Prog processes on remote one. >>> >>> Main application establish TCP socket with local MPI_Prog. >>> Main application establish TCP socket with controller on other >>> computer 10.3.2.170, which is not included in MpiConfigMachines.txt >>> file. >>> >>> After executing some time (hours, sometimes days) I see via netstat >>> that created new connection from mpiexec.hydra and controller. >>> >>> Before executing mpiexec.hydra I set environment variable >>> >>> setenv MPIEXEC_PORT_RANGE 50010:65535 >>> >>> According to manual this variable limits hydra destination ports to >>> [50010:65535]. >>> >>> >>> I see that hydra uses these ports with MPI_Prog, but connection with >>> controller done on port 701 (controller computer). >>> >>> >>> Controller program is a server. It can accept connections only. >>> >>> >>> Can you please advice how to stand with this problem? >>> >>> How hydra recognizes controller IP and establish connection with it? >>> >>> >>> Sincerely, >>> >>> Anatoly. >>> >>> >>> >> >> _______________________________________________ >> 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] Fwd: mpiexec.hydra creates unexpectable TCP socket.
by Anatoly G 07 Jan '15

07 Jan '15

Hello, Wesley. I think my previous mail was not clear enough. The system has following processes: - Application (Main) - this process executes: execvp with parameters mpiexec.hydra -genvall -disable-auto-cleanup -f MpiConfigMachines.txt -launcher=ssh -n 3 MPI_Prog - MPI_Prog - this program performs calculations. It's instances (processes) created by mpiexec.hydra. After some execution time, code of Application (Main) calls "abort()" function and fails without sending SIG_TERM to mpiexec.hydra process. I understand that this is a bug. It will be fixed by Application developers. But, after wrong Application termination mpiexec.hydra's father becomes init process. This is ok. But then I see via netstat that mpiexec.hydra starts sockets with other process (called Controller), which was not part of MPI execution. Is hydra tries to establish/restore connection with it's father (killed Application) process. I understand that this is an emergency and unexpected mpiexec.hydra usage. I was sure that mpiexec.hydra will not respond to Application fail and will behave exactly like Application process still exist. May be you can explain this strange situation. Regards, Anatoly. On Mon, Jan 5, 2015 at 7:09 PM, Wesley Bland <wbland(a)anl.gov> wrote: > When you pass -disable-auto-cleanup on the command line to mpiexec, > you’re telling Hydra not to clean up other processes when one process in > your job fails. It’s assumed that those processes will either clean > themselves up or complete successfully. > > It’s not clear to me what your program is trying to do that would be > erroneous, but usually when a process crashes, it’s the result of an > erroneous program rather than a bug in MPICH. I’m not saying that there’s > no bugs in MPICH, but we’d like to be able to narrow down where to look. > > Thanks, > Wesley > > > On Thu, Jan 1, 2015 at 6:35 AM, Anatoly G <anatolyrishon(a)gmail.com> wrote: > >> Dear MPICH. >> I have an additional information. >> This "strange configuration" (hydra connected to computer not from the >> list) is result of unhandled Main process fail (similar to abort() call) >> without killing children process (hydra). >> Thus I can see "init" process becomes a father of hydra process. >> Can you please refer me to document explaining hydra behavior when father >> process is dead (an emergency situation). >> I understand that this situation shouldn't happen and this bug will be >> fixed, but I'm curious about the hydra logic. >> >> Regards, >> Anatoly. >> >> ---------- Forwarded message ---------- >> From: Anatoly G <anatolyrishon(a)gmail.com> >> Date: Wed, Dec 24, 2014 at 1:00 PM >> Subject: mpiexec.hydra creates unexpectable TCP socket. >> To: discuss(a)mpich.org >> >> >> Dear MPICH. >> I'm using mpich 3.1 (hydra+MPI). >> I execute main application (Main) which calls mpiexec.hydra in following >> way: >> >> mpiexec.hydra -genvall -disable-auto-cleanup -f MpiConfigMachines.txt >> -launcher=ssh -n 3 MPI_Prog >> >> MpiConfigMachines.txt content: >> 10.3.2.100:1 >> 10.3.2.101:2 >> >> Where 10.3.2.100 is a local host. >> As result I get >> >> - Main + single MPI_Prog processes on local computer >> - 2 MPI_Prog processes on remote one. >> >> Main application establish TCP socket with local MPI_Prog. >> Main application establish TCP socket with controller on other computer >> 10.3.2.170, which is not included in MpiConfigMachines.txt file. >> >> After executing some time (hours, sometimes days) I see via netstat >> that created new connection from mpiexec.hydra and controller. >> >> Before executing mpiexec.hydra I set environment variable >> >> setenv MPIEXEC_PORT_RANGE 50010:65535 >> >> According to manual this variable limits hydra destination ports to >> [50010:65535]. >> >> >> I see that hydra uses these ports with MPI_Prog, but connection with >> controller done on port 701 (controller computer). >> >> >> Controller program is a server. It can accept connections only. >> >> >> Can you please advice how to stand with this problem? >> >> How hydra recognizes controller IP and establish connection with it? >> >> >> Sincerely, >> >> Anatoly. >> >> >> > > _______________________________________________ > 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] required MPICH2 of ANL
by Aamir Faraz 06 Jan '15

06 Jan '15

Thanks Technical specialist for Virtual Testing and engineering -----Original Message----- From: Lu, Huiwei [mailto:[email protected]] Sent: Monday, January 05, 2015 4:10 PM To: discuss(a)mpich.org Subject: Re: [mpich-discuss] required MPICH2 of ANL Hi Aamir, Due to lack of developer resources, MPICH no longer supports the Windows platform. Please refer to our FAQ for more information: http://wiki.mpich.org/mpich/index.php/Frequently_Asked_Questions#Q:_Why_can… We recommend you use Microsoft MPI, which can be found here: http://msdn.microsoft.com/en-us/library/bb524831(v=vs.85).aspx — Huiwei Lu Postdoc Appointee Mathematics and Computer Science Division, Argonne National Laboratory http://www.mcs.anl.gov/~huiweilu/ > On Jan 5, 2015, at 4:06 PM, Aamir Faraz <AamirF(a)TechneDesignStudio.com> wrote: > > Hello, > > We would be installing LS-Dyna on our machines and require MPICH2 for > that. Can you please send us the files so that we can run our files > using MPI for our jobs as MPP. It’s a windows XP that we have here. > Thanks > > > Technical specialist for Virtual Testing and engineering > > _______________________________________________ > 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