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

Re: [mpich-discuss] process failing...
by "Antonio J. Peña" 24 May '14

24 May '14

Oh! true, thanks for the correction. On 05/24/2014 07:50 PM, Balaji, Pavan wrote: > Actually, the below example will not cause any unexpected messages since you are doing an ANY_SOURCE receive. To get unexpected messages you need to be making progress on the receive side, but the incoming messages should be messages you donï¿½t have a receive buffer for. Hereï¿½s a modified example: > > Host A: > for(int i=0; i<n; i++) { > MPI_Isend(..to C..); > MPI_Send(..to B..); > } > > Host B: > for(int i=0; i<n; i++) { > MPI_Recv(..from A..); > MPI_Isend(..to C..); > } > > Host C: > for(int i=0; i<n; i++) { > MPI_Recv(..from B..); > } > for(int i=0; i<n; i++) { > MPI_Recv(..from A..); > } > > ï¿½ Pavan > > On May 24, 2014, at 7:19 PM, Antonio J. Peï¿½a <apenya(a)mcs.anl.gov> wrote: > >> Hi Ron, >> >> Depending on how the algorithm is structured, I may well be that the faster computers are generating messages faster than the slow computer is able to process them. As the problem size increases, the amount of data in unprocessed messages may get too high for that computer. In a very simple example (but note that there are many other possible situations): >> >> Hosts A and B: >> for(int i=0; i<n; i++) { >> MPI_Send(buf, count, MPI_INT, host_c, 0, MPI_COMM_WORLD); >> buf += count; >> } >> >> Host C: >> for(int i=0; i<2*n; i++) { >> MPI_Recv(buf, count, MPI_INT, MPI_ANY_SOURCE, 0, MPI_COMM_WORLD, &status); >> process_data(buf); >> } >> >> In that case the senders keep sending data to host_c faster than it's calling MPI_Recv, and get received by MPICH as unexpected messages (MPICH doesn't know where to place that data, and uses temporary internal buffers). Note that this situation is not necessarily caused by different processing speeds, since the culprit may well be the used algorithm itself. A very simple solution to avoid the prior potential problem could be: >> >> Host A and B: >> MPI_Barrier(MPI_COMM_WORLD); >> for(int i=0; i<n; i++) { >> MPI_Send(buf, count, MPI_INT, host_c, 0, MPI_COMM_WORLD); >> buf += n; >> } >> >> Host C: >> for(int i=0; i<2*n; i++) { >> MPI_Irecv(buf, count, MPI_INT, MPI_ANY_SOURCE, 0, MPI_COMM_WORLD, &requests[i]); >> buf += count; >> } >> MPI_Barrier(MPI_COMM_WORLD); >> for(int i=0; i<2*n; i++) { >> MPI_Waitany(2*n, requests, &idx, &status); >> process_data(buf+idx*count); >> } >> >> Now the data is placed on its final destination, since it's guaranteed that the MPI implementation knows its destination before receiving it. That solution would assume that there is enough memory for preallocating all receiving buffers, which may not be true and may require, for example, implementing a high-level protocol (such as based on credits) to synchronize the sends and receives to make sure that there is room on the receiver for them. >> >> I hope this helps. >> >> Best, >> Antonio >> >> >> On 05/24/2014 02:00 AM, Ron Palmer wrote: >>> Antonio, Rajeev and others, >>> thanks for your replies and comments on possible causes for the error messages and failure, I have passed them on to the programmers of the underlying application. I must admit I do not understand what unexpected messages are (I am but a mere user), could you perhaps give examples of typical causes of them? Eg, the cluster it runs on consists of 3 dual xeon computers with varying cpu clock rating - could these error messages be due to getting out of synch, expecting results but not getting them from the slower computer? I have re-started the process but excluded the slowest computer (2.27GHz, the other two are running at 2.87 and 3.2) as I was running out of ideas. >>> >>> For your information, this runs well on smaller problems (few computations). >>> >>> Thanks, >>> Ron >>> >>> On 24/05/2014 3:10 AM, Rajeev Thakur wrote: >>>> Yes. The message below says some process has received 261,895 messages for which no matching receives have been posted yet. >>>> >>>> <Mail Attachment> >>>> >>>> Rajeev >>>> >>>> >>>>> It looks like at least one of your processes is receiving too many unexpected messages, leading to get out of memory. Unexpected messages are those not matching a posted receive on the receiver side. You may check with the application developers to make them review the algorithm or look for any possible bug. >>>>> >>>>> Antonio >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> -- >> Antonio J. Peï¿½a >> Postdoctoral Appointee >> Mathematics and Computer Science Division >> Argonne National Laboratory >> 9700 South Cass Avenue, Bldg. 240, Of. 3148 >> Argonne, IL 60439-4847 >> >> apenya(a)mcs.anl.gov >> www.mcs.anl.gov/~apenya >> _______________________________________________ >> 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 -- Antonio J. Peï¿½a Postdoctoral Appointee Mathematics and Computer Science Division Argonne National Laboratory 9700 South Cass Avenue, Bldg. 240, Of. 3148 Argonne, IL 60439-4847 apenya(a)mcs.anl.gov www.mcs.anl.gov/~apenya

1 0

Re: [mpich-discuss] process failing...
by Balaji, Pavan 24 May '14

24 May '14

Actually, the below example will not cause any unexpected messages since you are doing an ANY_SOURCE receive. To get unexpected messages you need to be making progress on the receive side, but the incoming messages should be messages you don’t have a receive buffer for. Here’s a modified example: Host A: for(int i=0; i<n; i++) { MPI_Isend(..to C..); MPI_Send(..to B..); } Host B: for(int i=0; i<n; i++) { MPI_Recv(..from A..); MPI_Isend(..to C..); } Host C: for(int i=0; i<n; i++) { MPI_Recv(..from B..); } for(int i=0; i<n; i++) { MPI_Recv(..from A..); } — Pavan On May 24, 2014, at 7:19 PM, Antonio J. Peña <apenya(a)mcs.anl.gov> wrote: > > Hi Ron, > > Depending on how the algorithm is structured, I may well be that the faster computers are generating messages faster than the slow computer is able to process them. As the problem size increases, the amount of data in unprocessed messages may get too high for that computer. In a very simple example (but note that there are many other possible situations): > > Hosts A and B: > for(int i=0; i<n; i++) { > MPI_Send(buf, count, MPI_INT, host_c, 0, MPI_COMM_WORLD); > buf += count; > } > > Host C: > for(int i=0; i<2*n; i++) { > MPI_Recv(buf, count, MPI_INT, MPI_ANY_SOURCE, 0, MPI_COMM_WORLD, &status); > process_data(buf); > } > > In that case the senders keep sending data to host_c faster than it's calling MPI_Recv, and get received by MPICH as unexpected messages (MPICH doesn't know where to place that data, and uses temporary internal buffers). Note that this situation is not necessarily caused by different processing speeds, since the culprit may well be the used algorithm itself. A very simple solution to avoid the prior potential problem could be: > > Host A and B: > MPI_Barrier(MPI_COMM_WORLD); > for(int i=0; i<n; i++) { > MPI_Send(buf, count, MPI_INT, host_c, 0, MPI_COMM_WORLD); > buf += n; > } > > Host C: > for(int i=0; i<2*n; i++) { > MPI_Irecv(buf, count, MPI_INT, MPI_ANY_SOURCE, 0, MPI_COMM_WORLD, &requests[i]); > buf += count; > } > MPI_Barrier(MPI_COMM_WORLD); > for(int i=0; i<2*n; i++) { > MPI_Waitany(2*n, requests, &idx, &status); > process_data(buf+idx*count); > } > > Now the data is placed on its final destination, since it's guaranteed that the MPI implementation knows its destination before receiving it. That solution would assume that there is enough memory for preallocating all receiving buffers, which may not be true and may require, for example, implementing a high-level protocol (such as based on credits) to synchronize the sends and receives to make sure that there is room on the receiver for them. > > I hope this helps. > > Best, > Antonio > > > On 05/24/2014 02:00 AM, Ron Palmer wrote: >> Antonio, Rajeev and others, >> thanks for your replies and comments on possible causes for the error messages and failure, I have passed them on to the programmers of the underlying application. I must admit I do not understand what unexpected messages are (I am but a mere user), could you perhaps give examples of typical causes of them? Eg, the cluster it runs on consists of 3 dual xeon computers with varying cpu clock rating - could these error messages be due to getting out of synch, expecting results but not getting them from the slower computer? I have re-started the process but excluded the slowest computer (2.27GHz, the other two are running at 2.87 and 3.2) as I was running out of ideas. >> >> For your information, this runs well on smaller problems (few computations). >> >> Thanks, >> Ron >> >> On 24/05/2014 3:10 AM, Rajeev Thakur wrote: >>> Yes. The message below says some process has received 261,895 messages for which no matching receives have been posted yet. >>> >>> <Mail Attachment> >>> >>> Rajeev >>> >>> >>>> It looks like at least one of your processes is receiving too many unexpected messages, leading to get out of memory. Unexpected messages are those not matching a posted receive on the receiver side. You may check with the application developers to make them review the algorithm or look for any possible bug. >>>> >>>> Antonio >>> >>> >>> >>> _______________________________________________ >>> 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 > > > -- > Antonio J. Peña > Postdoctoral Appointee > Mathematics and Computer Science Division > Argonne National Laboratory > 9700 South Cass Avenue, Bldg. 240, Of. 3148 > Argonne, IL 60439-4847 > > apenya(a)mcs.anl.gov > www.mcs.anl.gov/~apenya > _______________________________________________ > 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] process failing...
by "Antonio J. Peña" 24 May '14

24 May '14

Hi Ron, Depending on how the algorithm is structured, I may well be that the faster computers are generating messages faster than the slow computer is able to process them. As the problem size increases, the amount of data in unprocessed messages may get too high for that computer. In a very simple example (but note that there are many other possible situations): Hosts A and B: for(int i=0; i<n; i++) { MPI_Send(buf, count, MPI_INT, host_c, 0, MPI_COMM_WORLD); buf += count; } Host C: for(int i=0; i<2*n; i++) { MPI_Recv(buf, count, MPI_INT, MPI_ANY_SOURCE, 0, MPI_COMM_WORLD, &status); process_data(buf); } In that case the senders keep sending data to host_c faster than it's calling MPI_Recv, and get received by MPICH as unexpected messages (MPICH doesn't know where to place that data, and uses temporary internal buffers). Note that this situation is not necessarily caused by different processing speeds, since the culprit may well be the used algorithm itself. A very simple solution to avoid the prior potential problem could be: Host A and B: MPI_Barrier(MPI_COMM_WORLD); for(int i=0; i<n; i++) { MPI_Send(buf, count, MPI_INT, host_c, 0, MPI_COMM_WORLD); buf += n; } Host C: for(int i=0; i<2*n; i++) { MPI_Irecv(buf, count, MPI_INT, MPI_ANY_SOURCE, 0, MPI_COMM_WORLD, &requests[i]); buf += count; } MPI_Barrier(MPI_COMM_WORLD); for(int i=0; i<2*n; i++) { MPI_Waitany(2*n, requests, &idx, &status); process_data(buf+idx*count); } Now the data is placed on its final destination, since it's guaranteed that the MPI implementation knows its destination before receiving it. That solution would assume that there is enough memory for preallocating all receiving buffers, which may not be true and may require, for example, implementing a high-level protocol (such as based on credits) to synchronize the sends and receives to make sure that there is room on the receiver for them. I hope this helps. Best, Antonio On 05/24/2014 02:00 AM, Ron Palmer wrote: > Antonio, Rajeev and others, > thanks for your replies and comments on possible causes for the error > messages and failure, I have passed them on to the programmers of the > underlying application. I must admit I do not understand what > unexpected messages are (I am but a mere user), could you perhaps give > examples of typical causes of them? Eg, the cluster it runs on > consists of 3 dual xeon computers with varying cpu clock rating - > could these error messages be due to getting out of synch, expecting > results but not getting them from the slower computer? I have > re-started the process but excluded the slowest computer (2.27GHz, the > other two are running at 2.87 and 3.2) as I was running out of ideas. > > For your information, this runs well on smaller problems (few > computations). > > Thanks, > Ron > > On 24/05/2014 3:10 AM, Rajeev Thakur wrote: >> Yes. The message below says some process has received 261,895 >> messages for which no matching receives have been posted yet. >> >> >> >> Rajeev >> >> >>> It looks like at least one of your processes is receiving too >>> many unexpected messages, leading to get out of >>> memory. Unexpected messages are those not matching a posted receive >>> on the receiver side. You may check with the application developers >>> to make them review the algorithm or look for any possible bug. >>> >>> Antonio >> >> >> >> _______________________________________________ >> discuss mailing listdiscuss(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 -- Antonio J. Peï¿½a Postdoctoral Appointee Mathematics and Computer Science Division Argonne National Laboratory 9700 South Cass Avenue, Bldg. 240, Of. 3148 Argonne, IL 60439-4847 apenya(a)mcs.anl.gov www.mcs.anl.gov/~apenya

1 0

Re: [mpich-discuss] mpich 3.1 configure hangs on darwin 10.9.2 with gcc 4.9
by Rajeev Thakur 24 May '14

24 May '14

Can you send us the c.txt file (i.e., the output printed by configure on the screen). Rajeev On May 23, 2014, at 4:58 PM, Karl Volz <volz(a)aeff.uaa.alaska.edu> wrote: > I noticed that others have successfully compiled using gnu compilers on Mavericks > > For 3.1 stable, I get a hung configure at > > checking for multiple__attribute_-((alias)) support in section > > "Configuring hwloc core" > > while trying: > > ./configure FC=gfortran CC=gcc CXX=g++ F77=gfortran > > I attached a config log. > > Karl Volz > Research Associate > Alaska Experimental Forecast Facility > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > <config.log>

1 0

Re: [mpich-discuss] process failing...
by Ron Palmer 24 May '14

24 May '14

Antonio, Rajeev and others, thanks for your replies and comments on possible causes for the error messages and failure, I have passed them on to the programmers of the underlying application. I must admit I do not understand what unexpected messages are (I am but a mere user), could you perhaps give examples of typical causes of them? Eg, the cluster it runs on consists of 3 dual xeon computers with varying cpu clock rating - could these error messages be due to getting out of synch, expecting results but not getting them from the slower computer? I have re-started the process but excluded the slowest computer (2.27GHz, the other two are running at 2.87 and 3.2) as I was running out of ideas. For your information, this runs well on smaller problems (few computations). Thanks, Ron On 24/05/2014 3:10 AM, Rajeev Thakur wrote: > Yes. The message below says some process has received 261,895 messages > for which no matching receives have been posted yet. > > > > Rajeev > > >> It looks like at least one of your processes is receiving too >> many unexpected messages, leading to get out of >> memory. Unexpected messages are those not matching a posted receive >> on the receiver side. You may check with the application developers >> to make them review the algorithm or look for any possible bug. >> >> Antonio > > > > _______________________________________________ > 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] Does MPICH support launching processes on Intel-MIC from host?
by Yida Wang 23 May '14

23 May '14

No, they are the same one. I mounted the directory to MICs by myself. On Fri, May 23, 2014 at 5:13 PM, Min Si <msi(a)il.is.s.u-tokyo.ac.jp> wrote: > Have you tried ssh to MIC and check mpiexec.hydra again ? It might be > different files just using the same path. > > Min > > > (14-5-23 15:48), Yida Wang wrote: > > I don't know how Intel guys implement this. But I think the mpiexec.hydra > file they provide is a regular Linux executable file. "file" it returns > "mpiexec.hydra: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), > dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped". > > One need to make sure mpiexec.hydra and pmi_proxy are accessible to MICs > before launching processes on MICs from host. > > > On Fri, May 23, 2014 at 4:43 PM, Reuti <reuti(a)staff.uni-marburg.de> wrote: > >> Am 23.05.2014 um 22:38 schrieb Yida Wang: >> >> Thank you! That works, but is not very convenient. Can I know why you >> guys don't configure mpich to behave as the same as Intel-MPI? Basically, >> using Intel-MPI, one can use the same mpiexec.hydra on both host and Xeon >> Phi. >> >> >> I don't have Intel-MPI, but is it really a binary or a wrapper to two >> different versions? What does `file mpiexec.hydra` show? >> >> -- Reuti >> >> >> On Fri, May 23, 2014 at 1:18 PM, "Antonio J. Peña" <apenya(a)mcs.anl.gov>wrote: >> >>> >>> For that, you have to deploy two installations of MPICH: one compiled >>> for the host, and the other for the MIC. To make things easy, place them >>> under the same path in both hosts - one that is not shared. >>> >>> Antonio >>> >>> >>> >>> On 05/22/2014 04:28 PM, Yida Wang wrote: >>> >>> Hi Guys, >>> >>> Can MPICH be configured to support launching processes on Intel-MIC >>> from the host? I know that there's a way to compile MPICH to be running on >>> Intel-MIC only, but how about running heterogeneously on both host and >>> Intel-MIC together? >>> >>> My compiled version returned "hydra_pmi_proxy: cannot execute binary >>> file" and got stuck when I tried to launch processes on Intel-MIC. >>> >>> Thanks, >>> YW >>> >>> >>> _______________________________________________ >>> discuss mailing list discuss(a)mpich.org >>> To manage subscription options or unsubscribe:https://lists.mpich.org/mailman/listinfo/discuss >>> >>> >>> >>> -- >>> Antonio J. Peña >>> Postdoctoral Appointee >>> Mathematics and Computer Science Division >>> Argonne National Laboratory >>> 9700 South Cass Avenue, Bldg. 240, Of. 3148 >>> Argonne, IL 60439-4847apenya(a)mcs.anl.govwww.mcs.anl.gov/~apenya <http://www.mcs.anl.gov/%7Eapenya> >>> >>> >>> _______________________________________________ >>> 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] Fwd: Make MPICH on Arch Linux
by Scott O'Malley 23 May '14

23 May '14

No I haven't specified the number of threads, would you suggest limiting it to 1 thread? I'm in the process of cleaning the make and will try again. I've seen a few examples of people compiling it on a virtual machine then porting the image to the Pi. I'll try running it with a single thread and see what the result is Scott On 23 May 2014 23:09, Kenneth Raffenetti <raffenet(a)mcs.anl.gov> wrote: > Seems it's just delaying the same behavior. If you check the kernel log, > you will probably see the OOM Killer being invoked. Are you building with > just 1 thread? i.e. no make -j<num> > > If it's the case that you can't get through a successful build, I would > recommend building on a similar, beefier machine and copying the > installation to the RaspberryPi. > > Ken > > > On 05/23/2014 05:02 PM, Scott O'Malley wrote: > >> After moving the build folder to my home directory I was able to get the >> make command to start correctly but it's still crashing out with an >> error which seems to stem from the gcc compiler, has anyone any advice? >> >> I've attached the new m.txt and c.txt >> >> Scott >> >> >> On 23 May 2014 19:05, Kenneth Raffenetti <raffenet(a)mcs.anl.gov >> <mailto:[email protected]>> wrote: >> >> I think you may be running into the OOM Killer. Is memory usage high >> on your machine? Is /tmp a tmpfs and not a real partition? If so, >> can you try building elsewhere? >> >> Ken >> >> >> On 05/23/2014 12:54 PM, Scott O'Malley wrote: >> >> Hi Guys >> >> I'm trying to build MPICH for Arch but when I get to the Make >> section of >> the user guide 3.1 I get an error, I've looked through the m.txt >> file as >> the guide suggests but the error message isn't particularly >> helpful. >> >> >> >> -- >> - Scott >> >> >> >> -- >> - Scott >> >> >> _________________________________________________ >> discuss mailing list discuss(a)mpich.org <mailto:[email protected]> >> >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/__mailman/listinfo/discuss >> <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 >> >> <https://lists.mpich.org/mailman/listinfo/discuss> >> >> >> >> >> -- >> - Scott >> >> >> _______________________________________________ >> 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 > -- - Scott

1 0

Re: [mpich-discuss] Fwd: Make MPICH on Arch Linux
by Kenneth Raffenetti 23 May '14

23 May '14

Seems it's just delaying the same behavior. If you check the kernel log, you will probably see the OOM Killer being invoked. Are you building with just 1 thread? i.e. no make -j<num> If it's the case that you can't get through a successful build, I would recommend building on a similar, beefier machine and copying the installation to the RaspberryPi. Ken On 05/23/2014 05:02 PM, Scott O'Malley wrote: > After moving the build folder to my home directory I was able to get the > make command to start correctly but it's still crashing out with an > error which seems to stem from the gcc compiler, has anyone any advice? > > I've attached the new m.txt and c.txt > > Scott > > > On 23 May 2014 19:05, Kenneth Raffenetti <raffenet(a)mcs.anl.gov > <mailto:[email protected]>> wrote: > > I think you may be running into the OOM Killer. Is memory usage high > on your machine? Is /tmp a tmpfs and not a real partition? If so, > can you try building elsewhere? > > Ken > > > On 05/23/2014 12:54 PM, Scott O'Malley wrote: > > Hi Guys > > I'm trying to build MPICH for Arch but when I get to the Make > section of > the user guide 3.1 I get an error, I've looked through the m.txt > file as > the guide suggests but the error message isn't particularly helpful. > > > > -- > - Scott > > > > -- > - Scott > > > _________________________________________________ > discuss mailing list discuss(a)mpich.org <mailto:[email protected]> > To manage subscription options or unsubscribe: > https://lists.mpich.org/__mailman/listinfo/discuss > <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 > <https://lists.mpich.org/mailman/listinfo/discuss> > > > > > -- > - Scott > > > _______________________________________________ > 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: Make MPICH on Arch Linux
by Scott O'Malley 23 May '14

23 May '14

After moving the build folder to my home directory I was able to get the make command to start correctly but it's still crashing out with an error which seems to stem from the gcc compiler, has anyone any advice? I've attached the new m.txt and c.txt Scott On 23 May 2014 19:05, Kenneth Raffenetti <raffenet(a)mcs.anl.gov> wrote: > I think you may be running into the OOM Killer. Is memory usage high on > your machine? Is /tmp a tmpfs and not a real partition? If so, can you try > building elsewhere? > > Ken > > > On 05/23/2014 12:54 PM, Scott O'Malley wrote: > >> Hi Guys >> >> I'm trying to build MPICH for Arch but when I get to the Make section of >> the user guide 3.1 I get an error, I've looked through the m.txt file as >> the guide suggests but the error message isn't particularly helpful. >> >> >> >> -- >> - Scott >> >> >> >> -- >> - Scott >> >> >> _______________________________________________ >> 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 > -- - Scott

1 0

mpich 3.1 configure hangs on darwin 10.9.2 with gcc 4.9
by Karl Volz 23 May '14

23 May '14

I noticed that others have successfully compiled using gnu compilers on Mavericks For 3.1 stable, I get a hung configure at checking for multiple__attribute_-((alias)) support in section "Configuring hwloc core" while trying: ./configure FC=gfortran CC=gcc CXX=g++ F77=gfortran I attached a config log. Karl Volz Research Associate Alaska Experimental Forecast Facility

1 0