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

Re: [mpich-discuss] mpich-3.2 34
by Kenneth Raffenetti 05 Jan '16

05 Jan '16

Hi, Do you have a make log from the application you are trying to build that you can share? Separately, did the example cpi application build successfully at the end of the MPICH build? Ken On 01/05/2016 02:44 AM, Professor W P Jones wrote: > Hi > > I have successfully compiled and installed the version suggested. > However when I attempt to to use make to compile and link it fails on > the link step with the message: > > /usr/bin/ld: boffin: hidden symbol `lstat64' in > /usr/lib64/libc_nonshared.a(lstat64.oS) is referenced by DSO > /usr/bin/ld: final link failed: Nonrepresentable section on output > make: [boffin] Error 1 (ignored) > mv: cannot stat `./x86_64/boffin': No such file or directory > make: *** [boffin] Error 1 > > The log files generated in the compiled and install are attached and > the output from mpiexec -info is: > > HYDRA build details: > Version: 3.2 > Release Date: Mon Jan 4 00:00:40 CST 2016 > CC: icc > CXX: icpc > F77: lf95 > F90: lf95 > Configure options: '--disable-option-checking' > '--prefix=/opt/mpich' '--enable-fortran=all' 'FC=lf95' 'F77=lf95' > '--cache-file=/dev/null' '--srcdir=.' 'CC=icc' 'CFLAGS= -O2' 'LDFLAGS=' > 'LIBS=-lpthread ' 'CPPFLAGS= > -I/usr/local/src/mpich-master-v3.2-42-g67631a5c0e9e/src/mpl/include > -I/usr/local/src/mpich-master-v3.2-42-g67631a5c0e9e/src/mpl/include > -I/usr/local/src/mpich-master-v3.2-42-g67631a5c0e9e/src/openpa/src > -I/usr/local/src/mpich-master-v3.2-42-g67631a5c0e9e/src/openpa/src > -D_REENTRANT > -I/usr/local/src/mpich-master-v3.2-42-g67631a5c0e9e/src/mpi/romio/include' > 'MPLLIBNAME=mpl' > Process Manager: pmi > Launchers available: ssh rsh fork slurm ll lsf > sge manual persist > Topology libraries available: hwloc > Resource management kernels available: user slurm ll lsf sge pbs > cobalt > Checkpointing libraries available: > Demux engines available: poll select > > Regards > Bill > > Professor W P Jones > Department of Mechanical Engineering > Imperial College London > Exhibition Road > London SW7 2AZ > Tel: +44 (0)20 7594 7037/7033 > Mobile +44 (0)776 495 9702 > Fax: +44 (0)20 7594 5702 > E-mail: w.jones(a)imperial.ac.uk > web site: http://www.imperial.ac.uk/me > > On 04/01/16 15:55, Kenneth Raffenetti wrote: >> Can you try the latest nightly tarball on the MPICH website? I >> committed a patch last night that I believe addresses the issue. I >> don't have a system with the lf95 compiler to test, so I just went >> from the documentation. >> >> Ken >> >> On 12/27/2015 07:49 PM, Professor W P Jones wrote: >>> Hi Pavan >>> >>> Here are all the existing log files. >>> >>> Regards >>> Bill >>> >>> Professor W P Jones >>> Department of Mechanical Engineering >>> Imperial College London >>> Exhibition Road >>> London SW7 2AZ >>> Tel: +44 (0)20 7594 7037/7033 >>> Mobile +44 (0)776 495 9702 >>> Fax: +44 (0)20 7594 5702 >>> E-mail: w.jones(a)imperial.ac.uk >>> web site: http://www.imperial.ac.uk/me >>> >>> On 28/12/15 00:40, Balaji, Pavan wrote: >>>> Could you send us the log files listed in the README? >>>> >>>> http://git.mpich.org/mpich.git/blob/HEAD:/README.vin#l235 >>>> >>>> -- Pavan >>>> >>>>> On Dec 27, 2015, at 5:34 AM, Professor W P Jones >>>>> <w.jones(a)imperial.ac.uk> wrote: >>>>> >>>>> Hi >>>>> >>>>> I am trying to build MPICH-3.2 34 using Lahey/Fujitsu Linux64 >>>>> Fortran Express Release L8.10b and I obtain the following error: >>>>> >>>>> checking for Fortran 90 module output directory flag... >>>>> configure: error: FCMODOUTFLAG could not be determined but is >>>>> critical for the current Fortran build system >>>>> >>>>> Please can you advise how this can be fixed? >>>>> >>>>> Many thanks >>>>> Bill Jones >>>>> >>>>> -- >>>>> Professor W P Jones >>>>> Department of Mechanical Engineering >>>>> Imperial College London >>>>> Exhibition Road >>>>> London SW7 2AZ >>>>> Tel: +44 (0)20 7594 7037/7033 >>>>> Mobile +44 (0)776 495 9702 >>>>> Fax: +44 (0)20 7594 5702 >>>>> E-mail: w.jones(a)imperial.ac.uk >>>>> web site: http://www.imperial.ac.uk/me >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> _______________________________________________ >> 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] [OMPI users] cleaning up old ROMIO (MPI-IO) drivers
by Gus Correa 05 Jan '16

05 Jan '16

Hi Rob Your email says you'll keep PVFS2. However, on your blog PVFS2 is not mentioned (on the "Keep" list). I suppose it will be kept, right? Thank you, Gus Correa On 01/05/2016 12:31 PM, Rob Latham wrote: > I'm itching to discard some of the little-used file system drivers in > ROMIO, an MPI-IO implementation used by, well, everyone. > > I've got more details in this ROMIO blog post: > http://press3.mcs.anl.gov/romio/2016/01/05/cleaning-out-old-romio-file-syst… > > > > Right now the plan is to keep these drivers: > > - Lustre > - GPFS > - UFS > - PVFS2 > - PANFS > - NFS > - TESTFS > - XFS > > Do you use any of the other ROMIO file system drivers? If you don't > know if you do, or don't know what a ROMIO file system driver is, then > it's unlikely you are using one. > > What if you use a driver and it's not on the list? First off, let me > know and I will probably want to visit your site and take a picture of > your system. Then, let me know how much longer you foresee using the > driver and we'll create a "deprecated" list for N more years. > > Thanks > ==rob > >

1 0

cleaning up old ROMIO (MPI-IO) drivers
by Rob Latham 05 Jan '16

05 Jan '16

I'm itching to discard some of the little-used file system drivers in ROMIO, an MPI-IO implementation used by, well, everyone. I've got more details in this ROMIO blog post: http://press3.mcs.anl.gov/romio/2016/01/05/cleaning-out-old-romio-file-syst… Right now the plan is to keep these drivers: - Lustre - GPFS - UFS - PVFS2 - PANFS - NFS - TESTFS - XFS Do you use any of the other ROMIO file system drivers? If you don't know if you do, or don't know what a ROMIO file system driver is, then it's unlikely you are using one. What if you use a driver and it's not on the list? First off, let me know and I will probably want to visit your site and take a picture of your system. Then, let me know how much longer you foresee using the driver and we'll create a "deprecated" list for N more years. Thanks ==rob -- 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] Creating an MPI job using MPI_Comm_connect/accept
by Mohammad Javad Rashti 05 Jan '16

05 Jan '16

Thanks Sangmin, sure, I will check it out. On Tue, Jan 5, 2016 at 10:47 AM, Seo, Sangmin <sseo(a)anl.gov> wrote: > Hi Mohammad, > > I was wrong in my answer. The same issue was discussed last year, and the > problem was fixed after mpich-3.1.3. Please refer > http://lists.mpich.org/pipermail/discuss/2015-January/003660.html > > Can you try your code with a recent version of mpich? > > Regards, > Sangmin > > > On Jan 4, 2016, at 8:09 PM, Seo, Sangmin <sseo(a)anl.gov> wrote: > > Hi Mohammad, > > It seems the same port name can be used only once, since the MPI 3.1 > standard (p. 419, line 31) says "A port name may be reused after it is > freed with MPI_CLOSE_PORT and released by the system.” Can you try close > the port and open it again to establish a new connection? If it doesn’t > work, could you send us your actual code (if possible, please send us a > simplified version of your code)? > > Regards, > Sangmin > > > On Dec 29, 2015, at 11:44 AM, Mohammad Javad Rashti <mjrashti(a)gmail.com> > wrote: > > Hi, > Using mpich-3.1.2, we are trying to create a multi-process multi-node MPI > job with the client-server model but we are having issues creating the > global communicator we need. > > We cannot use mpiexec to launch the MPI processes; they are launched by a > different daemon and we want them to join a group and use MPI after they > are launched. > We chose to use a server to publish a name/port and wait on a known number > of clients to connect. The goal is to create an intracommunicator among all > the clients and the server, and start normal MPI communication (not sure > whether there is a better way to accomplish this goal?). > > *The problem *is that the first client connects fine, but the subsequent > clients block. > > The *simplified method *that we are using is here: > > * ------------------- Server -----------------* > > - Call *MPI_Open_port(MPI_INFO_NULL, port_name)* > > - Call *MPI_Publish_name(service_name, MPI_INFO_NULL, port_name)* > > - clients = 0 > > Loop until clients = MAX_CLIENTS: > > if ( !clients ) > - Call > *MPI_Comm_accept(port_name,MPI_INFO_NULL,0,MPI_COMM_FELF,&new_ircomm)* > > else > - Call > *MPI_Comm_accept(port_name,MPI_INFO_NULL,0,previous_iacomm,&new_ircomm)* > > - Call *MPI_Intercomm_merge(new_ircomm, 0, &new_iacomm)* > > - previous_iacomm = new_iacomm > > - clients ++ > > end Loop > > *---------------- Client ---------------* > > - Call *MPI_Lookup_name(service_name, MPI_INFO_NULL, port_name)* > > - Call *MPI_Comm_connect(port_name, MPI_INFO_NULL, 0, MPI_COMM_SELF, > &new_ircomm)* > > - Call *MPI_Intercomm_merge(new_ircomm, 1 , &new_iacomm)* > > - previous_iacomm *= *new_iacomm > > Loop for all clients connecting after me: > > - Call > *MPI_Comm_accept(port_name,MPI_INFO_NULL,0,previous_iacomm,&new_ircomm)* > > - Call *MPI_Intercomm_merge(new_ircomm, 0, &new_iacomm)* > > - previous_iacomm = new_iacomm > > end Loop > > ---------------------------------- > > *Note *that MPI report states that MPI_Comm_accept is collective over the > calling communicator, that's why we are calling it by the server and all > previously connected clients. > > *The problem we are having *is that the first client connects fine, but > the subsequent clients block on MPI_Comm_connect. Also the server and > previously connected clients block on MPI_Comm_accept. > > (the server does not block only if we use MPI_COMM_SELF for all accept > calls, but that does not help us creating the global intracomm that we want. > > I suspect that we are missing something in our usage of MPI_Comm_accept. > Any insight is helpful and appreciated. I can send the actual C code if > needed. > > Thanks > Mohammad > _______________________________________________ > 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 > _______________________________________________ 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] Creating an MPI job using MPI_Comm_connect/accept
by Seo, Sangmin 05 Jan '16

05 Jan '16

Hi Mohammad, I was wrong in my answer. The same issue was discussed last year, and the problem was fixed after mpich-3.1.3. Please refer http://lists.mpich.org/pipermail/discuss/2015-January/003660.html Can you try your code with a recent version of mpich? Regards, Sangmin On Jan 4, 2016, at 8:09 PM, Seo, Sangmin <sseo(a)anl.gov<mailto:[email protected]>> wrote: Hi Mohammad, It seems the same port name can be used only once, since the MPI 3.1 standard (p. 419, line 31) says "A port name may be reused after it is freed with MPI_CLOSE_PORT and released by the system.” Can you try close the port and open it again to establish a new connection? If it doesn’t work, could you send us your actual code (if possible, please send us a simplified version of your code)? Regards, Sangmin On Dec 29, 2015, at 11:44 AM, Mohammad Javad Rashti <mjrashti(a)gmail.com<mailto:[email protected]>> wrote: Hi, Using mpich-3.1.2, we are trying to create a multi-process multi-node MPI job with the client-server model but we are having issues creating the global communicator we need. We cannot use mpiexec to launch the MPI processes; they are launched by a different daemon and we want them to join a group and use MPI after they are launched. We chose to use a server to publish a name/port and wait on a known number of clients to connect. The goal is to create an intracommunicator among all the clients and the server, and start normal MPI communication (not sure whether there is a better way to accomplish this goal?). The problem is that the first client connects fine, but the subsequent clients block. The simplified method that we are using is here: ------------------- Server ----------------- - Call MPI_Open_port(MPI_INFO_NULL, port_name) - Call MPI_Publish_name(service_name, MPI_INFO_NULL, port_name) - clients = 0 Loop until clients = MAX_CLIENTS: if ( !clients ) - Call MPI_Comm_accept(port_name,MPI_INFO_NULL,0,MPI_COMM_FELF,&new_ircomm) else - Call MPI_Comm_accept(port_name,MPI_INFO_NULL,0,previous_iacomm,&new_ircomm) - Call MPI_Intercomm_merge(new_ircomm, 0, &new_iacomm) - previous_iacomm = new_iacomm - clients ++ end Loop ---------------- Client --------------- - Call MPI_Lookup_name(service_name, MPI_INFO_NULL, port_name) - Call MPI_Comm_connect(port_name, MPI_INFO_NULL, 0, MPI_COMM_SELF, &new_ircomm) - Call MPI_Intercomm_merge(new_ircomm, 1 , &new_iacomm) - previous_iacomm = new_iacomm Loop for all clients connecting after me: - Call MPI_Comm_accept(port_name,MPI_INFO_NULL,0,previous_iacomm,&new_ircomm) - Call MPI_Intercomm_merge(new_ircomm, 0, &new_iacomm) - previous_iacomm = new_iacomm end Loop ---------------------------------- Note that MPI report states that MPI_Comm_accept is collective over the calling communicator, that's why we are calling it by the server and all previously connected clients. The problem we are having is that the first client connects fine, but the subsequent clients block on MPI_Comm_connect. Also the server and previously connected clients block on MPI_Comm_accept. (the server does not block only if we use MPI_COMM_SELF for all accept calls, but that does not help us creating the global intracomm that we want. I suspect that we are missing something in our usage of MPI_Comm_accept. Any insight is helpful and appreciated. I can send the actual C code if needed. Thanks Mohammad _______________________________________________ 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<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

Re: [mpich-discuss] mpich-3.2 34
by Professor W P Jones 05 Jan '16

05 Jan '16

Hi I have successfully compiled and installed the version suggested. However when I attempt to to use make to compile and link it fails on the link step with the message: /usr/bin/ld: boffin: hidden symbol `lstat64' in /usr/lib64/libc_nonshared.a(lstat64.oS) is referenced by DSO /usr/bin/ld: final link failed: Nonrepresentable section on output make: [boffin] Error 1 (ignored) mv: cannot stat `./x86_64/boffin': No such file or directory make: *** [boffin] Error 1 The log files generated in the compiled and install are attached and the output from mpiexec -info is: HYDRA build details: Version: 3.2 Release Date: Mon Jan 4 00:00:40 CST 2016 CC: icc CXX: icpc F77: lf95 F90: lf95 Configure options: '--disable-option-checking' '--prefix=/opt/mpich' '--enable-fortran=all' 'FC=lf95' 'F77=lf95' '--cache-file=/dev/null' '--srcdir=.' 'CC=icc' 'CFLAGS= -O2' 'LDFLAGS=' 'LIBS=-lpthread ' 'CPPFLAGS= -I/usr/local/src/mpich-master-v3.2-42-g67631a5c0e9e/src/mpl/include -I/usr/local/src/mpich-master-v3.2-42-g67631a5c0e9e/src/mpl/include -I/usr/local/src/mpich-master-v3.2-42-g67631a5c0e9e/src/openpa/src -I/usr/local/src/mpich-master-v3.2-42-g67631a5c0e9e/src/openpa/src -D_REENTRANT -I/usr/local/src/mpich-master-v3.2-42-g67631a5c0e9e/src/mpi/romio/include' 'MPLLIBNAME=mpl' Process Manager: pmi Launchers available: ssh rsh fork slurm ll lsf sge manual persist Topology libraries available: hwloc Resource management kernels available: user slurm ll lsf sge pbs cobalt Checkpointing libraries available: Demux engines available: poll select Regards Bill Professor W P Jones Department of Mechanical Engineering Imperial College London Exhibition Road London SW7 2AZ Tel: +44 (0)20 7594 7037/7033 Mobile +44 (0)776 495 9702 Fax: +44 (0)20 7594 5702 E-mail: w.jones(a)imperial.ac.uk web site: http://www.imperial.ac.uk/me On 04/01/16 15:55, Kenneth Raffenetti wrote: > Can you try the latest nightly tarball on the MPICH website? I > committed a patch last night that I believe addresses the issue. I > don't have a system with the lf95 compiler to test, so I just went > from the documentation. > > Ken > > On 12/27/2015 07:49 PM, Professor W P Jones wrote: >> Hi Pavan >> >> Here are all the existing log files. >> >> Regards >> Bill >> >> Professor W P Jones >> Department of Mechanical Engineering >> Imperial College London >> Exhibition Road >> London SW7 2AZ >> Tel: +44 (0)20 7594 7037/7033 >> Mobile +44 (0)776 495 9702 >> Fax: +44 (0)20 7594 5702 >> E-mail: w.jones(a)imperial.ac.uk >> web site: http://www.imperial.ac.uk/me >> >> On 28/12/15 00:40, Balaji, Pavan wrote: >>> Could you send us the log files listed in the README? >>> >>> http://git.mpich.org/mpich.git/blob/HEAD:/README.vin#l235 >>> >>> -- Pavan >>> >>>> On Dec 27, 2015, at 5:34 AM, Professor W P Jones >>>> <w.jones(a)imperial.ac.uk> wrote: >>>> >>>> Hi >>>> >>>> I am trying to build MPICH-3.2 34 using Lahey/Fujitsu Linux64 >>>> Fortran Express Release L8.10b and I obtain the following error: >>>> >>>> checking for Fortran 90 module output directory flag... >>>> configure: error: FCMODOUTFLAG could not be determined but is >>>> critical for the current Fortran build system >>>> >>>> Please can you advise how this can be fixed? >>>> >>>> Many thanks >>>> Bill Jones >>>> >>>> -- >>>> Professor W P Jones >>>> Department of Mechanical Engineering >>>> Imperial College London >>>> Exhibition Road >>>> London SW7 2AZ >>>> Tel: +44 (0)20 7594 7037/7033 >>>> Mobile +44 (0)776 495 9702 >>>> Fax: +44 (0)20 7594 5702 >>>> E-mail: w.jones(a)imperial.ac.uk >>>> web site: http://www.imperial.ac.uk/me >>>> >>>> _______________________________________________ >>>> 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 >> > _______________________________________________ > 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] Creating an MPI job using MPI_Comm_connect/accept
by Seo, Sangmin 04 Jan '16

04 Jan '16

Hi Mohammad, It seems the same port name can be used only once, since the MPI 3.1 standard (p. 419, line 31) says "A port name may be reused after it is freed with MPI_CLOSE_PORT and released by the system.” Can you try close the port and open it again to establish a new connection? If it doesn’t work, could you send us your actual code (if possible, please send us a simplified version of your code)? Regards, Sangmin On Dec 29, 2015, at 11:44 AM, Mohammad Javad Rashti <mjrashti(a)gmail.com<mailto:[email protected]>> wrote: Hi, Using mpich-3.1.2, we are trying to create a multi-process multi-node MPI job with the client-server model but we are having issues creating the global communicator we need. We cannot use mpiexec to launch the MPI processes; they are launched by a different daemon and we want them to join a group and use MPI after they are launched. We chose to use a server to publish a name/port and wait on a known number of clients to connect. The goal is to create an intracommunicator among all the clients and the server, and start normal MPI communication (not sure whether there is a better way to accomplish this goal?). The problem is that the first client connects fine, but the subsequent clients block. The simplified method that we are using is here: ------------------- Server ----------------- - Call MPI_Open_port(MPI_INFO_NULL, port_name) - Call MPI_Publish_name(service_name, MPI_INFO_NULL, port_name) - clients = 0 Loop until clients = MAX_CLIENTS: if ( !clients ) - Call MPI_Comm_accept(port_name,MPI_INFO_NULL,0,MPI_COMM_FELF,&new_ircomm) else - Call MPI_Comm_accept(port_name,MPI_INFO_NULL,0,previous_iacomm,&new_ircomm) - Call MPI_Intercomm_merge(new_ircomm, 0, &new_iacomm) - previous_iacomm = new_iacomm - clients ++ end Loop ---------------- Client --------------- - Call MPI_Lookup_name(service_name, MPI_INFO_NULL, port_name) - Call MPI_Comm_connect(port_name, MPI_INFO_NULL, 0, MPI_COMM_SELF, &new_ircomm) - Call MPI_Intercomm_merge(new_ircomm, 1 , &new_iacomm) - previous_iacomm = new_iacomm Loop for all clients connecting after me: - Call MPI_Comm_accept(port_name,MPI_INFO_NULL,0,previous_iacomm,&new_ircomm) - Call MPI_Intercomm_merge(new_ircomm, 0, &new_iacomm) - previous_iacomm = new_iacomm end Loop ---------------------------------- Note that MPI report states that MPI_Comm_accept is collective over the calling communicator, that's why we are calling it by the server and all previously connected clients. The problem we are having is that the first client connects fine, but the subsequent clients block on MPI_Comm_connect. Also the server and previously connected clients block on MPI_Comm_accept. (the server does not block only if we use MPI_COMM_SELF for all accept calls, but that does not help us creating the global intracomm that we want. I suspect that we are missing something in our usage of MPI_Comm_accept. Any insight is helpful and appreciated. I can send the actual C code if needed. Thanks Mohammad _______________________________________________ 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

Re: [mpich-discuss] mpich-3.2 34
by Kenneth Raffenetti 04 Jan '16

04 Jan '16

Can you try the latest nightly tarball on the MPICH website? I committed a patch last night that I believe addresses the issue. I don't have a system with the lf95 compiler to test, so I just went from the documentation. Ken On 12/27/2015 07:49 PM, Professor W P Jones wrote: > Hi Pavan > > Here are all the existing log files. > > Regards > Bill > > Professor W P Jones > Department of Mechanical Engineering > Imperial College London > Exhibition Road > London SW7 2AZ > Tel: +44 (0)20 7594 7037/7033 > Mobile +44 (0)776 495 9702 > Fax: +44 (0)20 7594 5702 > E-mail: w.jones(a)imperial.ac.uk > web site: http://www.imperial.ac.uk/me > > On 28/12/15 00:40, Balaji, Pavan wrote: >> Could you send us the log files listed in the README? >> >> http://git.mpich.org/mpich.git/blob/HEAD:/README.vin#l235 >> >> -- Pavan >> >>> On Dec 27, 2015, at 5:34 AM, Professor W P Jones >>> <w.jones(a)imperial.ac.uk> wrote: >>> >>> Hi >>> >>> I am trying to build MPICH-3.2 34 using Lahey/Fujitsu Linux64 >>> Fortran Express Release L8.10b and I obtain the following error: >>> >>> checking for Fortran 90 module output directory flag... >>> configure: error: FCMODOUTFLAG could not be determined but is >>> critical for the current Fortran build system >>> >>> Please can you advise how this can be fixed? >>> >>> Many thanks >>> Bill Jones >>> >>> -- >>> Professor W P Jones >>> Department of Mechanical Engineering >>> Imperial College London >>> Exhibition Road >>> London SW7 2AZ >>> Tel: +44 (0)20 7594 7037/7033 >>> Mobile +44 (0)776 495 9702 >>> Fax: +44 (0)20 7594 5702 >>> E-mail: w.jones(a)imperial.ac.uk >>> web site: http://www.imperial.ac.uk/me >>> >>> _______________________________________________ >>> 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 > _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0