March 2014 - discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] Problems with running make
by Ron Palmer 02 Mar '14

02 Mar '14

Gus, Reuti, Rajeev and others, I do have mpif77 and mpif90 in mpi/bin, so I conclude that it has compiled ok. I have checked reuti's suggestions, indicating that the environment is ok. I had added 'PATH=/my/mpi/bin:$PATH' to each of the .bashrc files (for the user I am running on all three) I am using the same username on all three computers - is that ok? I have installed MPI on to a NFS drive, all accessing the same; 'which' confirms. Are there any libraries that needs to be installed elsewhere? do need to run make install as root? I have added the 'LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/my/mpi/lib', though made no difference. (should those "{" and "}" be included? I entered it exactly like I have typed) I have mpicc the cpi program as suggested by Gus and tried it, as well as the originally provided cpi (part of the downloaded mpi) which I called cpi_orig, see the screen shot below. It looks like there is an issue with libgfortran.so.3... Perhaps I have not got the various compilers installed correctly? I would appreciate if someone could give me a suggestion on how to properly remove and re-install these (and select the correct ones). By the way, in the runs of cpi below, I reduced the number of cores to be used on the first pc listed in the machinefile, from 8 to 4, in the case there was an issue with the 9th one. As can be seen, it is the first node (or core) on a remote computer where the problems start to be listed which is node 5 in this case... If I run cpi on only one computer, it works. And yes, hostname works even if all computers are included in the machinefile. Clear as mud, hey? Thanks for your help. Ron On 2/03/2014 05:20, Gustavo Correa wrote: > Hi Ron > > Please, see my comments inline. > > On Mar 1, 2014, at 6:29 AM, Reuti wrote: > >> Hi, >> >> Am 01.03.2014 um 12:18 schrieb Ron Palmer: >> >>> Gus and others, >>> many thanks for your comments and suggestions. I am unsure whether I need fortran included as I am not in control of the software to be run on this linux cluster. I have asked but not yet got a reply... >>> >>> However, I did a yum search gfortran and installed the gcc-gfortran.x86_64 (I hope that was the one you referred to). I followed up with the ./configure ... as per your suggestion. That did not work. I then tried with only ./configure --prefix=/my/bin/folder. That worked so I also did make and make install. >>> > Maybe there was a misspell in the configure command line with > I am not 100% sure about the required gfortran yum RPMs. > It may also need the corresponding "devel" package, if you want to check, > but I am not really sure. Maybe you already installed everything you need for > a functional gfortran. > > As far as I can tell from your c2.txt file, configure seems to have recognized gfortran. > I can't tell for sure if it actually built the MPICH F77 and F90, although chances are that it did. > However, you may check if you have mpif77 and mpif90 in the MPICH bin directory, > which would be a good sign. > > I would not leave the F77 and F90 interfaces out of the game, > because sooner or later somebody will come with a Fortran MPI program > to run on your machine. > >>> I have a machinefile with three linux computers, all sharing the same mpi binaries. Running hostname on all 20 cores works, so I guess I should conclude that mpi works, right? >> Are they using the same binaries /my/bin/folder for a non-interactive startup too, i.e.: >> >> $ ssh sargeant which hydra_pmi_proxy >> >> returns the same as on the master (maybe ~/.bashrc needs to set the $PATH)? >> >> -- Reuti >> > Make sure you check Reuti's suggestions. > > Did you install MPICH in an NFS shared (across all machines) directory, > or did you install on each machine in a local directory? > > As Reuti pointed out, the environment setup is important. > If MPICH is not installed in a directory that Linux searches by default, such as /usr or /usr/local, > you need to add the MPICH bin directory to the PATH, and probably the lib directory to > LD_LIBRARY_PATH (if built with shared libraries). > The simplest way is in the .bashrc/.tcshrc file in the user home directory (which I presume > is shared via NFS across the computers, otherwise you need to edit these files on each > computer) > Say: > > - bash: > > export PATH=${PATH}:/my/mpich/bin > export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/my/mpich/lib > > - tcsh: > > setenv PATH ${PATH}:/my/mpich/bin > setenv LD_LIBRARY_PATH ${LD_LIBRARY_PATH}:/my/mpich/lib > > Also, you can go a long way troubleshooting these problems if you read the MPICH > documentation (Installer's Guide, User's Guide, README file) > > http://www.mpich.org/documentation/guides/ > > If you really could run mpiexec hostname across all computers, I would guess you > don't have any security or network related issues (i.e. passwordless ssh works > across the nodes, there is no firewall blocking, the nodes names are properly > resolved most likely via /etc/hosts, and so on). > > To make sure MPICH works with a simple MPI program, > compile the cpi.c program in the examples directory (comes with the source code tarball), > and run it across all nodes. > > Something like this: > > mpicc -o cpi cpi.c > mpiexec -machinefile all_machines -np 24 ./cpi > > If it runs, then MPICH is alright, and any issues you are having with the other program, > are not an MPICH issue, but a bug or misconfiguration in the other program. > > >>> I then tried the software I am supposed to run on the cluster. It works on all nodes on the master computer, but not if other computers are involved. I have captured the output from such failed attempt to run that software on all available nodes on all available computers in the cluster, see below. I have attached c2.txt and m2.txt (and the output of the failed run) in the attached gzipped file (the failed run in run2.txt and in the image below may not be from the same failed run...). >>> >>> So, is it an issue for the software developers or is it an issue with mpich? >>> > The screenshot you sent MPI ranks 9, 11,12, 14 don't printout their ranks. > This may or may not indicate a programming error, however combined with the fact that > the program fails in MPI_Barrier, which is a collective call, suggests it may be a bug in the program. > One possibility is that the MPI program is wrong, and somehow ranks 9,11,12,14 > did not call MPI_Barrier (collective calls, as the name says, are collective, > must be called by all ranks in the "communicator"). > > Another line of search would be that in both the screenshot and the run2.txt file > complain of "Communication error with rank 8" in the MPI_Barrier. > In each case rank 8 is in a different computer (gainsborough and constable). > It may be that rank 8 never called MPI_Barrier somehow. > For instance, MPI collective calls inside "if" conditionals can cause traps like this, > as the "if" condition may turn out to be true on some ranks and false on others. > > Judging from the small amount of output, the program seems to have failed > very early, which may help search for a possible bug (early in the code). > > However, these are just wild guesses. > > Is this an in-house program, public domain, or commercial software? > Anyway, this may be an issue to bring to that code developers. > > I hope this helps, > Gus Correa >

1 0

Re: [mpich-discuss] Problems with running make
by Ron Palmer 02 Mar '14

02 Mar '14

Rajeev, I have shut down iptables on master computer (sargeant) as it stopped it working. By the way, what is an appropriate iptables command to allow mpi traffic through iptables? I will compile the cpi example and report back. Cheers, Ron On 2/03/2014 02:28, Rajeev Thakur wrote: > Each machine should be able to communicate with every other machine. See if there are any firewall settings preventing that. > > Try to debug it using the cpi example from the examples directory. Run it across 2 machines first. > > On Mar 1, 2014, at 5:18 AM, Ron Palmer <ron.palmer(a)pgcgroup.com.au> wrote: > >> Gus and others, >> many thanks for your comments and suggestions. I am unsure whether I need fortran included as I am not in control of the software to be run on this linux cluster. I have asked but not yet got a reply... >> >> However, I did a yum search gfortran and installed the gcc-gfortran.x86_64 (I hope that was the one you referred to). I followed up with the ./configure ... as per your suggestion. That did not work. I then tried with only ./configure --prefix=/my/bin/folder. That worked so I also did make and make install. >> >> I have a machinefile with three linux computers, all sharing the same mpi binaries. Running hostname on all 20 cores works, so I guess I should conclude that mpi works, right? >> >> I then tried the software I am supposed to run on the cluster. It works on all nodes on the master computer, but not if other computers are involved. I have captured the output from such failed attempt to run that software on all available nodes on all available computers in the cluster, see below. I have attached c2.txt and m2.txt (and the output of the failed run) in the attached gzipped file (the failed run in run2.txt and in the image below may not be from the same failed run...). >> >> So, is it an issue for the software developers or is it an issue with mpich? >> >> I would appreciate if you could let me know if mpich is properly compiled and installed and whether I should follow up with the application developers instead. I now that they are successfully running this code on V1.4.1. >> >> Thanks for your prompt support. >> >> Cheers, >> Ron >> >> >> >> <ghdahehb.png> >>

1 0

Re: [mpich-discuss] Problems with running make
by Ron Palmer 02 Mar '14

02 Mar '14

Reuti, yes, if I ask which hydra_pmi_proxy, they all three point to the same location (accessible via nfs mounted drives). Cheers, Ron On 1/03/2014 21:29, Reuti wrote: > Hi, > > Am 01.03.2014 um 12:18 schrieb Ron Palmer: > >> Gus and others, >> many thanks for your comments and suggestions. I am unsure whether I need fortran included as I am not in control of the software to be run on this linux cluster. I have asked but not yet got a reply... >> >> However, I did a yum search gfortran and installed the gcc-gfortran.x86_64 (I hope that was the one you referred to). I followed up with the ./configure ... as per your suggestion. That did not work. I then tried with only ./configure --prefix=/my/bin/folder. That worked so I also did make and make install. >> >> I have a machinefile with three linux computers, all sharing the same mpi binaries. Running hostname on all 20 cores works, so I guess I should conclude that mpi works, right? > Are they using the same binaries /my/bin/folder for a non-interactive startup too, i.e.: > > $ ssh sargeant which hydra_pmi_proxy > > returns the same as on the master (maybe ~/.bashrc needs to set the $PATH)? > > -- Reuti > >

1 0

Re: [mpich-discuss] MPID_nem_tcp_init(377)... gethostbyname failed, mac (errno 1)
by l.cebamanos 01 Mar '14

01 Mar '14

Well, is not fixed. Its just the one I got here, but it changes. Any ideas of how to fix this? -------- Original message -------- From: Reuti <reuti(a)staff.uni-marburg.de> Date:01/03/2014 17:38 (GMT+00:00) To: discuss(a)mpich.org Subject: Re: [mpich-discuss] MPID_nem_tcp_init(377)... gethostbyname failed, mac (errno 1) Am 01.03.2014 um 17:58 schrieb Luis Cebamanos: > Here it is the output of those commands: > > lcebaman@mac~/$ nslookup localhost > Server: 192.168.1.1 > Address: 192.168.1.1#53 > > Name: localhost > Address: 127.0.0.1 > > lcebaman@mac~/$ nslookup mac > Server: 192.168.1.1 > Address: 192.168.1.1#53 > > Name: mac > Address: 192.168.1.127 Is this a fixed address you get everytime? You could add it to /etc/hosts. Interesting that MPICH throws an error about resolving "mac", although DNS is working. -- Reuti > lcebaman@mac~/$ hostname > mac > > > > > On 28 Feb 2014, at 23:35, Reuti <reuti(a)staff.uni-marburg.de> wrote: > >> Am 28.02.2014 um 14:39 schrieb Luis Cebamanos: >> >>> Hi Pavan, >>> >>> Yes, that is the output: >>> >>> $ cat /etc/hosts >>> ## >>> # Host Database >>> # >>> # localhost is used to configure the loopback interface >>> # when the system is booting. Do not change this entry. >>> ## >>> 127.0.0.1 localhost >>> 255.255.255.255 broadcasthost >>> ::1 localhost >>> fe80::1%lo0 localhost >> >> What is the output of: >> >> $ nslookup localhost >> $ nslookup mac >> $ hostname >> >> AFAICS your machine has no domainname, otherwise it would show up in the MPICH error message after "mac". >> >> -- Reuti >> >> >>> On 28/02/14 13:35, Balaji, Pavan wrote: >>>> $ cat /etc/hosts >>>>>> ## >>>>>> # Host Database >>>>>> # >>>>>> # localhost is used to configure the loopback interface >>>>>> # when the system is booting. Do not change this entry. >>>>>> ## >>>>>> 127.0.0.1 localhost >>>>>> 255.255.255.255 broadcasthost >>>>>> ::1 localhost >>>>>> fe80::1%lo0 localhost >>> >>> >>> -- >>> The University of Edinburgh is a charitable body, registered in >>> Scotland, with registration number SC005336. >>> >>> _______________________________________________ >>> 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 > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > _______________________________________________ > 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 The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: [mpich-discuss] Problems with running make
by Gustavo Correa 01 Mar '14

01 Mar '14

Hi Ron Please, see my comments inline. On Mar 1, 2014, at 6:29 AM, Reuti wrote: > Hi, > > Am 01.03.2014 um 12:18 schrieb Ron Palmer: > >> Gus and others, >> many thanks for your comments and suggestions. I am unsure whether I need fortran included as I am not in control of the software to be run on this linux cluster. I have asked but not yet got a reply... >> >> However, I did a yum search gfortran and installed the gcc-gfortran.x86_64 (I hope that was the one you referred to). I followed up with the ./configure ... as per your suggestion. That did not work. I then tried with only ./configure --prefix=/my/bin/folder. That worked so I also did make and make install. >> Maybe there was a misspell in the configure command line with I am not 100% sure about the required gfortran yum RPMs. It may also need the corresponding "devel" package, if you want to check, but I am not really sure. Maybe you already installed everything you need for a functional gfortran. As far as I can tell from your c2.txt file, configure seems to have recognized gfortran. I can't tell for sure if it actually built the MPICH F77 and F90, although chances are that it did. However, you may check if you have mpif77 and mpif90 in the MPICH bin directory, which would be a good sign. I would not leave the F77 and F90 interfaces out of the game, because sooner or later somebody will come with a Fortran MPI program to run on your machine. >> I have a machinefile with three linux computers, all sharing the same mpi binaries. Running hostname on all 20 cores works, so I guess I should conclude that mpi works, right? > > Are they using the same binaries /my/bin/folder for a non-interactive startup too, i.e.: > > $ ssh sargeant which hydra_pmi_proxy > > returns the same as on the master (maybe ~/.bashrc needs to set the $PATH)? > > -- Reuti > Make sure you check Reuti's suggestions. Did you install MPICH in an NFS shared (across all machines) directory, or did you install on each machine in a local directory? As Reuti pointed out, the environment setup is important. If MPICH is not installed in a directory that Linux searches by default, such as /usr or /usr/local, you need to add the MPICH bin directory to the PATH, and probably the lib directory to LD_LIBRARY_PATH (if built with shared libraries). The simplest way is in the .bashrc/.tcshrc file in the user home directory (which I presume is shared via NFS across the computers, otherwise you need to edit these files on each computer) Say: - bash: export PATH=${PATH}:/my/mpich/bin export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/my/mpich/lib - tcsh: setenv PATH ${PATH}:/my/mpich/bin setenv LD_LIBRARY_PATH ${LD_LIBRARY_PATH}:/my/mpich/lib Also, you can go a long way troubleshooting these problems if you read the MPICH documentation (Installer's Guide, User's Guide, README file) http://www.mpich.org/documentation/guides/ If you really could run mpiexec hostname across all computers, I would guess you don't have any security or network related issues (i.e. passwordless ssh works across the nodes, there is no firewall blocking, the nodes names are properly resolved most likely via /etc/hosts, and so on). To make sure MPICH works with a simple MPI program, compile the cpi.c program in the examples directory (comes with the source code tarball), and run it across all nodes. Something like this: mpicc -o cpi cpi.c mpiexec -machinefile all_machines -np 24 ./cpi If it runs, then MPICH is alright, and any issues you are having with the other program, are not an MPICH issue, but a bug or misconfiguration in the other program. >> I then tried the software I am supposed to run on the cluster. It works on all nodes on the master computer, but not if other computers are involved. I have captured the output from such failed attempt to run that software on all available nodes on all available computers in the cluster, see below. I have attached c2.txt and m2.txt (and the output of the failed run) in the attached gzipped file (the failed run in run2.txt and in the image below may not be from the same failed run...). >> >> So, is it an issue for the software developers or is it an issue with mpich? >> The screenshot you sent MPI ranks 9, 11,12, 14 don't printout their ranks. This may or may not indicate a programming error, however combined with the fact that the program fails in MPI_Barrier, which is a collective call, suggests it may be a bug in the program. One possibility is that the MPI program is wrong, and somehow ranks 9,11,12,14 did not call MPI_Barrier (collective calls, as the name says, are collective, must be called by all ranks in the "communicator"). Another line of search would be that in both the screenshot and the run2.txt file complain of "Communication error with rank 8" in the MPI_Barrier. In each case rank 8 is in a different computer (gainsborough and constable). It may be that rank 8 never called MPI_Barrier somehow. For instance, MPI collective calls inside "if" conditionals can cause traps like this, as the "if" condition may turn out to be true on some ranks and false on others. Judging from the small amount of output, the program seems to have failed very early, which may help search for a possible bug (early in the code). However, these are just wild guesses. Is this an in-house program, public domain, or commercial software? Anyway, this may be an issue to bring to that code developers. I hope this helps, Gus Correa > >> I would appreciate if you could let me know if mpich is properly compiled and installed and whether I should follow up with the application developers instead. I now that they are successfully running this code on V1.4.1. >> >> Thanks for your prompt support. >> >> Cheers, >> Ron >> >> >> >> <ghdahehb.png> >> >> >> >> On 1/03/2014 08:19, Gus Correa wrote: >>> Hi Ron >>> >>> Your config.log shows that configure is picking up Gnu >>> /usr/bin/f77 as the Fortran compiler. >>> See an excerpt of config.log below. >>> >>> The Gnu f77/g77, which cannot compile Fortran-90 and later code. >>> >>> You may want to install gfortran. >>> Configure didn't find gfortran. >>> However, you can install it easily from RPM through yum. >>> >>> Once you install gfortran, to avoid picking up wrong compilers, >>> you can also point configure to the compilers. >>> Assuming you want to use all Gnu compilers, this would do it: >>> >>> ./configure CC=gcc, CXX=g++, F77=gfortran, FC=gfortran, --prefix=/wherever/you/want ... >>> >>> Another possibility is follow Reuti's suggestion of >>> not compiling the MPICH Fortran-90 interface. >>> >>> I hope this helps, >>> Gus Correa >>> >>> ******* from your config.log ********* >>> ... >>> configure:17977: result: no >>> configure:17947: checking for gfortran >>> configure:17977: result: no >>> configure:17947: checking for f77 >>> configure:17963: found /usr/bin/f77 >>> configure:17974: result: f77 >>> configure:18000: checking for Fortran 77 compiler version >>> configure:18009: f77 --version >&5 >>> GNU Fortran (GCC) 3.4.6 20060404 (Red Hat 3.4.6-19.el6) >>> ... >>> ***************************************** >>> >>> On 02/28/2014 05:02 AM, Reuti wrote: >>>> Hi, >>>> >>>> Am 28.02.2014 um 09:22 schrieb Ron Palmer: >>>> >>>>> I am struggling with running make on MPICH, V3.1. I believe that ./configure went well but I do not understand what caused the errors in make. I thought it may be associated with the fortran compile but I have F77 installed (though somewhat confused whether fortran 90 is also installed). The README file suggested that I send an email to this list with nominated four text files attached. >>>> >>>> You can try to skip f90: >>>> >>>> $ ./configure --disable-fc ... >>>> >>>> -- Reuti >>>> >>>> >>>>> The end of the m.txt file is included here for easy access, full details are attached... >>>>> >>>>> CC src/mpi/topo/nhb_alltoallw.lo >>>>> CC src/binding/f90/create_f90_int.lo >>>>> CC src/binding/f90/create_f90_real.lo >>>>> src/binding/f90/create_f90_real.c: In function 'PMPI_Type_create_f90_real': >>>>> src/binding/f90/create_f90_real.c:73: error: expected expression before ',' token >>>>> src/binding/f90/create_f90_real.c:74: error: expected expression before ',' token >>>>> make[2]: *** [src/binding/f90/create_f90_real.lo] Error 1 >>>>> make[2]: Leaving directory `/inv/mpich-3.1' >>>>> make[1]: *** [all-recursive] Error 1 >>>>> make[1]: Leaving directory `/inv/mpich-3.1' >>>>> make: *** [all] Error 2 >>>>> >>>>> I look forward to any suggestions any of you may have. >>>>> Regards, Ron >>>>> >>>>> >>>>> <mpi_logs.tar.gz>_______________________________________________ >>>>> 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 >> >> >> >> <run2.tar.gz>_______________________________________________ >> 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] MPID_nem_tcp_init(377)... gethostbyname failed, mac (errno 1)
by Reuti 01 Mar '14

01 Mar '14

Am 01.03.2014 um 17:58 schrieb Luis Cebamanos: > Here it is the output of those commands: > > lcebaman@mac~/$ nslookup localhost > Server: 192.168.1.1 > Address: 192.168.1.1#53 > > Name: localhost > Address: 127.0.0.1 > > lcebaman@mac~/$ nslookup mac > Server: 192.168.1.1 > Address: 192.168.1.1#53 > > Name: mac > Address: 192.168.1.127 Is this a fixed address you get everytime? You could add it to /etc/hosts. Interesting that MPICH throws an error about resolving "mac", although DNS is working. -- Reuti > lcebaman@mac~/$ hostname > mac > > > > > On 28 Feb 2014, at 23:35, Reuti <reuti(a)staff.uni-marburg.de> wrote: > >> Am 28.02.2014 um 14:39 schrieb Luis Cebamanos: >> >>> Hi Pavan, >>> >>> Yes, that is the output: >>> >>> $ cat /etc/hosts >>> ## >>> # Host Database >>> # >>> # localhost is used to configure the loopback interface >>> # when the system is booting. Do not change this entry. >>> ## >>> 127.0.0.1 localhost >>> 255.255.255.255 broadcasthost >>> ::1 localhost >>> fe80::1%lo0 localhost >> >> What is the output of: >> >> $ nslookup localhost >> $ nslookup mac >> $ hostname >> >> AFAICS your machine has no domainname, otherwise it would show up in the MPICH error message after "mac". >> >> -- Reuti >> >> >>> On 28/02/14 13:35, Balaji, Pavan wrote: >>>> $ cat /etc/hosts >>>>>> ## >>>>>> # Host Database >>>>>> # >>>>>> # localhost is used to configure the loopback interface >>>>>> # when the system is booting. Do not change this entry. >>>>>> ## >>>>>> 127.0.0.1 localhost >>>>>> 255.255.255.255 broadcasthost >>>>>> ::1 localhost >>>>>> fe80::1%lo0 localhost >>> >>> >>> -- >>> The University of Edinburgh is a charitable body, registered in >>> Scotland, with registration number SC005336. >>> >>> _______________________________________________ >>> 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 > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > _______________________________________________ > 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] MPID_nem_tcp_init(377)... gethostbyname failed, mac (errno 1)
by Luis Cebamanos 01 Mar '14

01 Mar '14

Here it is the output of those commands: lcebaman@mac~/$ nslookup localhost Server: 192.168.1.1 Address: 192.168.1.1#53 Name: localhost Address: 127.0.0.1 lcebaman@mac~/$ nslookup mac Server: 192.168.1.1 Address: 192.168.1.1#53 Name: mac Address: 192.168.1.127 lcebaman@mac~/$ hostname mac On 28 Feb 2014, at 23:35, Reuti <reuti(a)staff.uni-marburg.de> wrote: > Am 28.02.2014 um 14:39 schrieb Luis Cebamanos: > >> Hi Pavan, >> >> Yes, that is the output: >> >> $ cat /etc/hosts >> ## >> # Host Database >> # >> # localhost is used to configure the loopback interface >> # when the system is booting. Do not change this entry. >> ## >> 127.0.0.1 localhost >> 255.255.255.255 broadcasthost >> ::1 localhost >> fe80::1%lo0 localhost > > What is the output of: > > $ nslookup localhost > $ nslookup mac > $ hostname > > AFAICS your machine has no domainname, otherwise it would show up in the MPICH error message after "mac". > > -- Reuti > > >> On 28/02/14 13:35, Balaji, Pavan wrote: >>> $ cat /etc/hosts >>>>> ## >>>>> # Host Database >>>>> # >>>>> # localhost is used to configure the loopback interface >>>>> # when the system is booting. Do not change this entry. >>>>> ## >>>>> 127.0.0.1 localhost >>>>> 255.255.255.255 broadcasthost >>>>> ::1 localhost >>>>> fe80::1%lo0 localhost >> >> >> -- >> The University of Edinburgh is a charitable body, registered in >> Scotland, with registration number SC005336. >> >> _______________________________________________ >> 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 The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: [mpich-discuss] Problems with running make
by Rajeev Thakur 01 Mar '14

01 Mar '14

Each machine should be able to communicate with every other machine. See if there are any firewall settings preventing that. Try to debug it using the cpi example from the examples directory. Run it across 2 machines first. On Mar 1, 2014, at 5:18 AM, Ron Palmer <ron.palmer(a)pgcgroup.com.au> wrote: > Gus and others, > many thanks for your comments and suggestions. I am unsure whether I need fortran included as I am not in control of the software to be run on this linux cluster. I have asked but not yet got a reply... > > However, I did a yum search gfortran and installed the gcc-gfortran.x86_64 (I hope that was the one you referred to). I followed up with the ./configure ... as per your suggestion. That did not work. I then tried with only ./configure --prefix=/my/bin/folder. That worked so I also did make and make install. > > I have a machinefile with three linux computers, all sharing the same mpi binaries. Running hostname on all 20 cores works, so I guess I should conclude that mpi works, right? > > I then tried the software I am supposed to run on the cluster. It works on all nodes on the master computer, but not if other computers are involved. I have captured the output from such failed attempt to run that software on all available nodes on all available computers in the cluster, see below. I have attached c2.txt and m2.txt (and the output of the failed run) in the attached gzipped file (the failed run in run2.txt and in the image below may not be from the same failed run...). > > So, is it an issue for the software developers or is it an issue with mpich? > > I would appreciate if you could let me know if mpich is properly compiled and installed and whether I should follow up with the application developers instead. I now that they are successfully running this code on V1.4.1. > > Thanks for your prompt support. > > Cheers, > Ron > > > > <ghdahehb.png> > > > > On 1/03/2014 08:19, Gus Correa wrote: >> Hi Ron >> >> Your config.log shows that configure is picking up Gnu >> /usr/bin/f77 as the Fortran compiler. >> See an excerpt of config.log below. >> >> The Gnu f77/g77, which cannot compile Fortran-90 and later code. >> >> You may want to install gfortran. >> Configure didn't find gfortran. >> However, you can install it easily from RPM through yum. >> >> Once you install gfortran, to avoid picking up wrong compilers, >> you can also point configure to the compilers. >> Assuming you want to use all Gnu compilers, this would do it: >> >> ./configure CC=gcc, CXX=g++, F77=gfortran, FC=gfortran, --prefix=/wherever/you/want ... >> >> Another possibility is follow Reuti's suggestion of >> not compiling the MPICH Fortran-90 interface. >> >> I hope this helps, >> Gus Correa >> >> ******* from your config.log ********* >> ... >> configure:17977: result: no >> configure:17947: checking for gfortran >> configure:17977: result: no >> configure:17947: checking for f77 >> configure:17963: found /usr/bin/f77 >> configure:17974: result: f77 >> configure:18000: checking for Fortran 77 compiler version >> configure:18009: f77 --version >&5 >> GNU Fortran (GCC) 3.4.6 20060404 (Red Hat 3.4.6-19.el6) >> ... >> ***************************************** >> >> On 02/28/2014 05:02 AM, Reuti wrote: >>> Hi, >>> >>> Am 28.02.2014 um 09:22 schrieb Ron Palmer: >>> >>>> I am struggling with running make on MPICH, V3.1. I believe that ./configure went well but I do not understand what caused the errors in make. I thought it may be associated with the fortran compile but I have F77 installed (though somewhat confused whether fortran 90 is also installed). The README file suggested that I send an email to this list with nominated four text files attached. >>> >>> You can try to skip f90: >>> >>> $ ./configure --disable-fc ... >>> >>> -- Reuti >>> >>> >>>> The end of the m.txt file is included here for easy access, full details are attached... >>>> >>>> CC src/mpi/topo/nhb_alltoallw.lo >>>> CC src/binding/f90/create_f90_int.lo >>>> CC src/binding/f90/create_f90_real.lo >>>> src/binding/f90/create_f90_real.c: In function 'PMPI_Type_create_f90_real': >>>> src/binding/f90/create_f90_real.c:73: error: expected expression before ',' token >>>> src/binding/f90/create_f90_real.c:74: error: expected expression before ',' token >>>> make[2]: *** [src/binding/f90/create_f90_real.lo] Error 1 >>>> make[2]: Leaving directory `/inv/mpich-3.1' >>>> make[1]: *** [all-recursive] Error 1 >>>> make[1]: Leaving directory `/inv/mpich-3.1' >>>> make: *** [all] Error 2 >>>> >>>> I look forward to any suggestions any of you may have. >>>> Regards, Ron >>>> >>>> >>>> <mpi_logs.tar.gz>_______________________________________________ >>>> 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 > > > > <run2.tar.gz>_______________________________________________ > 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] Checks for buffer aliasing in coll ops?
by Rajeev Thakur 01 Mar '14

01 Mar '14

I have created a ticket for it. http://trac.mpich.org/projects/mpich/ticket/2049 Rajeev On Feb 28, 2014, at 8:13 AM, Carsten Clauss <c.clauss(a)fz-juelich.de> wrote: > Constantly, our users step into the common trap of aliasing send and receive buffers e.g. in (All)Gather(v) instead of using MPI_IN_PLACE. > > Although these cases are frequently caught by lower-level memcpy() checks within MPICH, I wonder if it would be feasible to do so already in the upper MPI layer, e.g. by using MPIR_ERRTEST_ALIAS_COLL() in a more comprehensive manner. > > IMHO it would be nice to extend the check e.g. in MPI_(All)Gather() from > > /* catch common aliasing cases */ > if (recvbuf != MPI_IN_PLACE && sendtype == recvtype && sendcount == recvcount && sendcount != 0) > MPIR_ERRTEST_ALIAS_COLL(sendbuf,recvbuf,mpi_errno); > > -- that would only take effect for root=0 -- to let's say: > > /* catch common aliasing cases */ > MPID_Datatype_get_size_macro(recvtype, recvtype_size); > if (recvbuf != MPI_IN_PLACE && sendtype == recvtype && sendcount == recvcount && sendcount != 0) > MPIR_ERRTEST_ALIAS_COLL(sendbuf, (char*)recvbuf + comm_ptr->rank*recvcount*recvtype_size, mpi_errno); > > And the same for MPI_(All)Gatherv() (which currently do not check for aliasing at all): > > /* catch common aliasing cases */ > MPID_Datatype_get_size_macro(recvtype, recvtype_size); > if (sendbuf != MPI_IN_PLACE && sendtype == recvtype && recvcounts[comm_ptr->rank] != 0 && sendcount != 0) > MPIR_ERRTEST_ALIAS_COLL(sendbuf, (char*)recvbuf + displs[comm_ptr->rank]*recvtype_size, mpi_errno); > > I think this would lead to much more understandable error messages ("PMPI_Gatherv(363): Buffers must not be aliased" vs. "memcpy argument memory ranges overlap") -- or is there something that speaks against this kind of checks? > > With kind regards, > C. Clauss > > -- > Carsten Clauss > Possartstrasse 20 > D-81679 Muenchen > www.par-tec.com > _____________________________________ > ParTec Cluster Competence Center GmbH > > Geschäftsführer RA. Dipl.-Ing. Bernhard Frohwitter Eingetragen beim > Amtsgericht München HRB 151545 Steuer-Nr. 08/32305, Ust-ID DE235527064 > > _______________________________________________ > 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] Error "hydra requires VA_ARGS support", RHEL 5.10, icc
by Balaji, Pavan 01 Mar '14

01 Mar '14

That patch has a bug in it, so it disables the warnings check too aggressively. It works for you as, in your case, you want to disable the warnings check anyway. Go ahead and use it. I’ll try to see if I can get a better fix in in the meanwhile. — Pavan On Mar 1, 2014, at 2:45 AM, Бакиров, Медер <bakirov(a)almetico.com> wrote: > On Fri, Feb 28, 2014 at 7:33 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >> That's surprising, given that it's incorrect. :-) I have a corrected patch pending. > > Is it this commit, which fixes the bug?: > http://git.mpich.org/mpich.git/commit/de80ec8704071f3b9c810509fb8acee345865… > > I downloaded the corresponding nightly snapshot release from here: > http://www.mpich.org/static/downloads/nightly/master/mpich/ > > With the best regards, > Meder Bakirov > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0