August 2013 - discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] Fwd: Problem with installation
by Antonio J. Peña 07 Aug '13

07 Aug '13

Hi, Is there any reason for using such an old version of MPICH? I'd suggest you try with our most recent release. Antonio On Wednesday, August 07, 2013 05:53:08 PM Alen Arturo Dioses Avellaneda wrote: Good Evening: I am trying to install MPICH-1.2.7p1 and I got a problem. I am sending the m.txt file and c.txt file. I am using CentOS5.9. I hope you can help me with this problem. I am trying to use mpich to use 2 processors I am not trying to work with nodes Alen Arturo Dioses Avellaneda Meteorological Student

1 0

Fwd: Problem with installation
by Alen Arturo Dioses Avellaneda 07 Aug '13

07 Aug '13

Good Evening: I am trying to install MPICH-1.2.7p1 and I got a problem. I am sending the m.txt file and c.txt file. I am using CentOS5.9. I hope you can help me with this problem. I am trying to use mpich to use 2 processors I am not trying to work with nodes Alen Arturo Dioses Avellaneda Meteorological Student

1 0

Incorrect error message for MPID_nem_tcp_bind (1.5, 3.0.4)
by Yauheni Zelenko 07 Aug '13

07 Aug '13

Hi! I have a problem on one host when MPID_nem_tcp_bind() failed with "MPID_nem_tcp_bind(580): unable to bind socket to port (port=1,errno=98:Address already in use)". However, MPID_nem_tcp_bind() tried to bind to port 0 (ports ranges was not specified), then failed, and port variable was incremented before final error message recorded. MPICH_PORT_RANGE helped to solve problem on aforementioned host. I tried version 1.5 and 3.0.4. Eugene.

1 0

Re: [mpich-discuss] Semantics of MPI_Cancel
by Rajeev Thakur 07 Aug '13

07 Aug '13

MPI_Cancel will succeed only if the receive can be canceled, i.e., not part of the message has already been received into the receive buffer. So, if the cancel succeeds, the send will match the next receive. You have to check the error code returned by cancel. On Aug 7, 2013, at 4:18 PM, Matthieu Dorier wrote: > So either there is no way to know which MPI_Send will be matched, since even with > MPI_Irecv(req); MPI_Test(flag,req); if(!flag) {MPI_Cancel(req)} MPI_Recv() > the MPI_Irecv could have completed between the MPI_Test and the MPI_Cancel... > > Or does the content of the MPI_Irecv, which is supposed to have been put in the user-provided buffer, gets transferred into the buffer of the next MPI_Recv upon cancellation of the MPI_Irecv? > > Thanks, > > Matthieu > > ----- Mail original ----- >> De: "Rajeev Thakur" <thakur(a)mcs.anl.gov> >> À: discuss(a)mpich.org >> Envoyé: Mercredi 7 Août 2013 16:10:02 >> Objet: Re: [mpich-discuss] Semantics of MPI_Cancel >> >> You canceled the recv, not the send. The send will still go through >> and match the first available receive that can be matched. >> >> On Aug 7, 2013, at 3:25 PM, Matthieu Dorier wrote: >> >>> Hi, >>> >>> Suppose process 0 does the following >>> MPI_Irecv(...req) >>> MPI_Cancel(req) >>> MPI_Recv >>> >>> and process 1 does >>> MPI_Send >>> MPI_Send >>> >>> Does process 0 receives the data from the first or the second >>> MPI_Send? >>> (I'd tend to say the second, but I'd like a confirmation). >>> >>> Thanks! >>> >>> Matthieu Dorier >>> PhD student at ENS Cachan Brittany and IRISA >>> http://people.irisa.fr/Matthieu.Dorier >>> _______________________________________________ >>> 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] Semantics of MPI_Cancel
by Matthieu Dorier 07 Aug '13

07 Aug '13

So either there is no way to know which MPI_Send will be matched, since even with MPI_Irecv(req); MPI_Test(flag,req); if(!flag) {MPI_Cancel(req)} MPI_Recv() the MPI_Irecv could have completed between the MPI_Test and the MPI_Cancel... Or does the content of the MPI_Irecv, which is supposed to have been put in the user-provided buffer, gets transferred into the buffer of the next MPI_Recv upon cancellation of the MPI_Irecv? Thanks, Matthieu ----- Mail original ----- > De: "Rajeev Thakur" <thakur(a)mcs.anl.gov> > À: discuss(a)mpich.org > Envoyé: Mercredi 7 Août 2013 16:10:02 > Objet: Re: [mpich-discuss] Semantics of MPI_Cancel > > You canceled the recv, not the send. The send will still go through > and match the first available receive that can be matched. > > On Aug 7, 2013, at 3:25 PM, Matthieu Dorier wrote: > > > Hi, > > > > Suppose process 0 does the following > > MPI_Irecv(...req) > > MPI_Cancel(req) > > MPI_Recv > > > > and process 1 does > > MPI_Send > > MPI_Send > > > > Does process 0 receives the data from the first or the second > > MPI_Send? > > (I'd tend to say the second, but I'd like a confirmation). > > > > Thanks! > > > > Matthieu Dorier > > PhD student at ENS Cachan Brittany and IRISA > > http://people.irisa.fr/Matthieu.Dorier > > _______________________________________________ > > 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] Semantics of MPI_Cancel
by Rajeev Thakur 07 Aug '13

07 Aug '13

You canceled the recv, not the send. The send will still go through and match the first available receive that can be matched. On Aug 7, 2013, at 3:25 PM, Matthieu Dorier wrote: > Hi, > > Suppose process 0 does the following > MPI_Irecv(...req) > MPI_Cancel(req) > MPI_Recv > > and process 1 does > MPI_Send > MPI_Send > > Does process 0 receives the data from the first or the second MPI_Send? > (I'd tend to say the second, but I'd like a confirmation). > > Thanks! > > Matthieu Dorier > PhD student at ENS Cachan Brittany and IRISA > http://people.irisa.fr/Matthieu.Dorier > _______________________________________________ > 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] Semantics of MPI_Cancel
by Dries Kimpe 07 Aug '13

07 Aug '13

What if the MPI_Irecv completed before the call to MPI_Cancel was made? Dries * Matthieu Dorier <matthieu.dorier(a)irisa.fr> [2013-08-07 22:25:58]: > Hi, > Suppose process 0 does the following > MPI_Irecv(...req) > MPI_Cancel(req) > MPI_Recv > and process 1 does > MPI_Send > MPI_Send > Does process 0 receives the data from the first or the second MPI_Send? > (I'd tend to say the second, but I'd like a confirmation). > Thanks! > Matthieu Dorier > PhD student at ENS Cachan Brittany and IRISA > http://people.irisa.fr/Matthieu.Dorier > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

Semantics of MPI_Cancel
by Matthieu Dorier 07 Aug '13

07 Aug '13

Hi, Suppose process 0 does the following MPI_Irecv(...req) MPI_Cancel(req) MPI_Recv and process 1 does MPI_Send MPI_Send Does process 0 receives the data from the first or the second MPI_Send? (I'd tend to say the second, but I'd like a confirmation). Thanks! Matthieu Dorier PhD student at ENS Cachan Brittany and IRISA http://people.irisa.fr/Matthieu.Dorier

1 0

Re: [mpich-discuss] Generalized request classes
by Jim Dinan 05 Aug '13

05 Aug '13

I think it would be reasonable to bootstrap this discussion through the hybrid working group. That group is active, and most of the right people are subscribed to that mailing list. ~Jim. On Mon, Aug 5, 2013 at 1:22 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > Jeff Hammond <jeff.science(a)gmail.com> writes: > > At this point, you should subscribe to > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-greq and have > > further discussion of this issue there. I copied that list to make > > the transition seemless. > > The mpi3-greq list hasn't had any activity in five years, so it's not > clear any interested parties are there. I care quite a bit about > improving the ability of generalized requests to make progress, mostly > because I want to be able to implement domain-specific nonblocking > collectives with similar progress semantics to those provided directly > by MPI. > > _______________________________________________ > 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] Generalized request classes
by Jed Brown 05 Aug '13

05 Aug '13

Jeff Hammond <jeff.science(a)gmail.com> writes: > At this point, you should subscribe to > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-greq and have > further discussion of this issue there. I copied that list to make > the transition seemless. The mpi3-greq list hasn't had any activity in five years, so it's not clear any interested parties are there. I care quite a bit about improving the ability of generalized requests to make progress, mostly because I want to be able to implement domain-specific nonblocking collectives with similar progress semantics to those provided directly by MPI.

1 0