September 2013 - mpiwg-ft - mailman3.cels.anl.gov

Re: [mpiwg-ft] Madrid Report
by Wesley Bland 25 Sep '13

25 Sep '13

Let me add my two cents here as well. As Jim mentioned, this wasn't a rehashed slide deck. This was a new one. The confusion may have come from the fact that there haven't been any changes to the proposal recently and the talk that Rich gave was designed to be informational for those who hadn't attended the US meetings recently. As Jim mentioned, this was really supposed to be a justification talk to give background and rationale. It sounds like we may not have achieved that goal. It's unfortunate that more of us couldn't be there to help the conversation, but I'd like to try to find out more about the specific concerns that were raised as we've been working very hard to respond to these sorts of things in the past. I don't know if you actually meant that there was a desire to see the proposal split in two or not, but I'd really be against that. It would present a lot of work and without both pieces, either one individually would be useless. We've gone through the text many times to be sure that we're presenting the least intrusive interface possible that still accomplishes all of the needs of FT. As you mentioned, it isn't the most user friendly interface and we don't expect it to be. However, the real user friendly interfaces (C/R, replication, migration, strong consistency, etc.) can be built on top of the proposal, which is what we intended in our design. If that's one of the objections, then we many need to rethink things here or do a better job of convincing the forum that this is a good idea. FWIW, I believe that was always the original intent of MPI anyway. If it's going to be a problem to bring this to the forum for a reading in December, we can push things out, but we've been targeting that date and I'd like to have a better idea of what the objections are before we decide to delay again. If it's just the same arguments again, then it may not do any good to push this for another 3-6 months. I think we all expect that this proposal won't be passing unanimously. Thanks for the feedback Martin. I know that you probably weren't the one objecting and those who were probably aren't on this list. It's too bad that more of us couldn't be at the meeting, but I think we're all familiar with the funding situation in the US right now for international travel. Thanks, Wesley On Sep 25, 2013, at 8:23 AM, Jim Dinan <james.dinan(a)gmail.com> wrote: > Hi Martin, > > The slides that were presented in Madrid were actually a new deck. We had tried to address feedback that there is a need to do a better job of covering the core issues, potential approaches, and justifications for design decisions, beyond just presenting the proposal. It sounds like more discussion around these topics is needed, and we can work with that for the Chicago meeting. > > It sounds like we're being asked to break the proposal up into two sets of changes -- one that defines failures in MPI and MPI's state after a failure; and second that adds a recovery API. Is that right? I'm not sure if it's possible to tease these things apart, but we can look into it. > > Cheers, > ~Jim. > > > On Tue, Sep 24, 2013 at 2:48 PM, Martin Schulz <schulzm(a)llnl.gov> wrote: > > > > Hi all, > > > > This is more from the viewpoint of an external observer, since I haven't had the time to really participate lately. > > > > Rich gave a presentation covering the current proposal, but he also said that this was basically the old slide deck that had been shown before and didn't contain any of the new work that the FT group has been doing in coordinating with the other WGs. There were also several questions that people asked and that we couldn't answer since Rich was the only FT group member at the meeting. > > > > Based on this I got the feeling that many in the forum were still concerned about this overarching proposal and would like to hear more. In particular, a few meetings back after the MPI 3.0 vote we had a discussion about what was missing to make such concerns go away and one thing that we agreed on was to first go through the standard and clean things up to make it compatible with an FT proposal. From what I can tell, a lot of this has happened and it may help to explicitly present that before even going into the API approach. This (plus an updated talk with a broader discussion with more FT group members being present) may be better for the Chicago meeting than doing an actual formal reading (which may be too early since there doesn't seem to be consensus about the approach, yet). > > > > From the application side, I have seen a few people starting to use it. One of our PDs is using it for a large MD application and there is also the following work I saw at a recent conference: > > > > ftp://ftp.inf.ethz.ch/pub/publications/tech-reports/7xx/793.pdf > > > > Both said that the interface is overly complex and has a very (too?) high of an impact on applications, which makes me worried. Not sure how we can address this, though. > > > > Martin > > > > > > > > > > On Sep 19, 2013, at 6:43 PM, Aurélien Bouteiller <bouteill(a)icl.utk.edu> wrote: > > > > I am currently in Europe and busy. My schedule will get back to normal in october. > > > > I'm also interested in a summary of events though. > > > > Aurelien > > > > > > Le 20 sept. 2013 à 00:42, Wesley Bland <wbland(a)mcs.anl.gov> a écrit : > > > > Hi WG, > > > > I've been out if the loop for a bit since my wife had our first baby last week (everyone is doing great). I was wondering how things went at the forum meeting last week. Was there any feedback from those in attendance? > > > > Also, I didn't see an email about this week's con call. I assume that it didn't happen, but if it did can anyone mention what was discussed? > > > > Thanks, > > Wesley > > _______________________________________________ > > mpiwg-ft mailing list > > mpiwg-ft(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft > > > > > > -- > > * Dr. Aurélien Bouteiller > > * Researcher at Innovative Computing Laboratory > > * University of Tennessee > > * 1122 Volunteer Boulevard, suite 309b > > * Knoxville, TN 37996 > > * 865 974 9375 > > > > > > > > > > > > > > > > _______________________________________________ > > mpiwg-ft mailing list > > mpiwg-ft(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft > > > > > > ________________________________________________________________________ > > Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm > > CASC @ Lawrence Livermore National Laboratory, Livermore, USA > > > > > > _______________________________________________ > > mpiwg-ft mailing list > > mpiwg-ft(a)lists.mpi-forum.org > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft > _______________________________________________ > mpiwg-ft mailing list > mpiwg-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft

1 0

Re: [mpiwg-ft] Madrid Report
by Jim Dinan 25 Sep '13

25 Sep '13

Hi Martin, The slides that were presented in Madrid were actually a new deck. We had tried to address feedback that there is a need to do a better job of covering the core issues, potential approaches, and justifications for design decisions, beyond just presenting the proposal. It sounds like more discussion around these topics is needed, and we can work with that for the Chicago meeting. It sounds like we're being asked to break the proposal up into two sets of changes -- one that defines failures in MPI and MPI's state after a failure; and second that adds a recovery API. Is that right? I'm not sure if it's possible to tease these things apart, but we can look into it. Cheers, ~Jim. On Tue, Sep 24, 2013 at 2:48 PM, Martin Schulz <schulzm(a)llnl.gov> wrote: > > Hi all, > > This is more from the viewpoint of an external observer, since I haven't had the time to really participate lately. > > Rich gave a presentation covering the current proposal, but he also said that this was basically the old slide deck that had been shown before and didn't contain any of the new work that the FT group has been doing in coordinating with the other WGs. There were also several questions that people asked and that we couldn't answer since Rich was the only FT group member at the meeting. > > Based on this I got the feeling that many in the forum were still concerned about this overarching proposal and would like to hear more. In particular, a few meetings back after the MPI 3.0 vote we had a discussion about what was missing to make such concerns go away and one thing that we agreed on was to first go through the standard and clean things up to make it compatible with an FT proposal. From what I can tell, a lot of this has happened and it may help to explicitly present that before even going into the API approach. This (plus an updated talk with a broader discussion with more FT group members being present) may be better for the Chicago meeting than doing an actual formal reading (which may be too early since there doesn't seem to be consensus about the approach, yet). > > From the application side, I have seen a few people starting to use it. One of our PDs is using it for a large MD application and there is also the following work I saw at a recent conference: > > ftp://ftp.inf.ethz.ch/pub/publications/tech-reports/7xx/793.pdf > > Both said that the interface is overly complex and has a very (too?) high of an impact on applications, which makes me worried. Not sure how we can address this, though. > > Martin > > > > > On Sep 19, 2013, at 6:43 PM, Aurélien Bouteiller <bouteill(a)icl.utk.edu> wrote: > > I am currently in Europe and busy. My schedule will get back to normal in october. > > I'm also interested in a summary of events though. > > Aurelien > > > Le 20 sept. 2013 à 00:42, Wesley Bland <wbland(a)mcs.anl.gov> a écrit : > > Hi WG, > > I've been out if the loop for a bit since my wife had our first baby last week (everyone is doing great). I was wondering how things went at the forum meeting last week. Was there any feedback from those in attendance? > > Also, I didn't see an email about this week's con call. I assume that it didn't happen, but if it did can anyone mention what was discussed? > > Thanks, > Wesley > _______________________________________________ > mpiwg-ft mailing list > mpiwg-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft > > > -- > * Dr. Aurélien Bouteiller > * Researcher at Innovative Computing Laboratory > * University of Tennessee > * 1122 Volunteer Boulevard, suite 309b > * Knoxville, TN 37996 > * 865 974 9375 > > > > > > > > _______________________________________________ > mpiwg-ft mailing list > mpiwg-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft > > > ________________________________________________________________________ > Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm > CASC @ Lawrence Livermore National Laboratory, Livermore, USA > > > _______________________________________________ > mpiwg-ft mailing list > mpiwg-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft

1 0

Re: [mpiwg-ft] Madrid Report
by Martin Schulz 24 Sep '13

24 Sep '13

Hi all, This is more from the viewpoint of an external observer, since I haven't had the time to really participate lately. Rich gave a presentation covering the current proposal, but he also said that this was basically the old slide deck that had been shown before and didn't contain any of the new work that the FT group has been doing in coordinating with the other WGs. There were also several questions that people asked and that we couldn't answer since Rich was the only FT group member at the meeting. Based on this I got the feeling that many in the forum were still concerned about this overarching proposal and would like to hear more. In particular, a few meetings back after the MPI 3.0 vote we had a discussion about what was missing to make such concerns go away and one thing that we agreed on was to first go through the standard and clean things up to make it compatible with an FT proposal. From what I can tell, a lot of this has happened and it may help to explicitly present that before even going into the API approach. This (plus an updated talk with a broader discussion with more FT group members being present) may be better for the Chicago meeting than doing an actual formal reading (which may be too early since there doesn't seem to be consensus about the approach, yet). From the application side, I have seen a few people starting to use it. One of our PDs is using it for a large MD application and there is also the following work I saw at a recent conference: ftp://ftp.inf.ethz.ch/pub/publications/tech-reports/7xx/793.pdf Both said that the interface is overly complex and has a very (too?) high of an impact on applications, which makes me worried. Not sure how we can address this, though. Martin On Sep 19, 2013, at 6:43 PM, Aurélien Bouteiller <bouteill(a)icl.utk.edu> wrote: > I am currently in Europe and busy. My schedule will get back to normal in october. > > I'm also interested in a summary of events though. > > Aurelien > > > Le 20 sept. 2013 à 00:42, Wesley Bland <wbland(a)mcs.anl.gov> a écrit : > >> Hi WG, >> >> I've been out if the loop for a bit since my wife had our first baby last week (everyone is doing great). I was wondering how things went at the forum meeting last week. Was there any feedback from those in attendance? >> >> Also, I didn't see an email about this week's con call. I assume that it didn't happen, but if it did can anyone mention what was discussed? >> >> Thanks, >> Wesley >> _______________________________________________ >> mpiwg-ft mailing list >> mpiwg-ft(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft > > -- > * Dr. Aurélien Bouteiller > * Researcher at Innovative Computing Laboratory > * University of Tennessee > * 1122 Volunteer Boulevard, suite 309b > * Knoxville, TN 37996 > * 865 974 9375 > > > > > > > > _______________________________________________ > mpiwg-ft mailing list > mpiwg-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

Re: [mpiwg-ft] Madrid Report
by Aurélien Bouteiller 19 Sep '13

19 Sep '13

I am currently in Europe and busy. My schedule will get back to normal in october. I'm also interested in a summary of events though. Aurelien Le 20 sept. 2013 à 00:42, Wesley Bland <wbland(a)mcs.anl.gov> a écrit : > Hi WG, > > I've been out if the loop for a bit since my wife had our first baby last week (everyone is doing great). I was wondering how things went at the forum meeting last week. Was there any feedback from those in attendance? > > Also, I didn't see an email about this week's con call. I assume that it didn't happen, but if it did can anyone mention what was discussed? > > Thanks, > Wesley > _______________________________________________ > mpiwg-ft mailing list > mpiwg-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft -- * Dr. Aurélien Bouteiller * Researcher at Innovative Computing Laboratory * University of Tennessee * 1122 Volunteer Boulevard, suite 309b * Knoxville, TN 37996 * 865 974 9375

1 0

Madrid Report
by Wesley Bland 19 Sep '13

19 Sep '13

Hi WG, I've been out if the loop for a bit since my wife had our first baby last week (everyone is doing great). I was wondering how things went at the forum meeting last week. Was there any feedback from those in attendance? Also, I didn't see an email about this week's con call. I assume that it didn't happen, but if it did can anyone mention what was discussed? Thanks, Wesley

1 0

Re: [mpiwg-ft] FTWG Con Call 2013-09-03
by Wesley Bland 05 Sep '13

05 Sep '13

How does it make a difference? You still have to protect the call to FAILURE_ACK from wildcard operations if you're using threads do you not? I guess the result here is that we're not ready to merge the two function calls and we should probably stick with the original slide. We can keep discussing this on the calls and make a decision for December. On Sep 5, 2013, at 4:58 AM, Aurélien Bouteiller <bouteill(a)icl.utk.edu> wrote: > I cannot read steadily my emails. I am in backward europe now :) > > Anyway, George statement is correct. I found a circumvolved way to use the single call, it works, but it is very ugly and extremely difficult to understand/operate. The split operation is much simpler to use. Additionnaly for several use cases (where the user just want to resume ANY_SOURCE and does not care about the failed group) it can spare quite a significant memory overhead on group storage. I advise we keep it as-is. > > I won't be very active in the next 2 weeks. I hope for the best :) > > Aurelien > > > > Le 4 sept. 2013 à 21:19, Wesley Bland <wbland(a)mcs.anl.gov> a écrit : > >> His email was designed to show that it is possible to use either case reliably. In fact, both cases require this check to ensure that you aren't acknowledging failures that you didn't mean to acknowledge. The only difference is that they're combined into one call. You still need to be careful to ensure that you don't acknowledge failures while another thread is using an ANY_SOURCE. So in the end, they should be equivalent. >> >> Wesley >> >> On Sep 3, 2013, at 5:13 PM, George Bosilca <bosilca(a)icl.utk.edu> wrote: >> >>> On Sep 3, 2013, at 21:40 , Wesley Bland <wbland(a)mcs.anl.gov> wrote: >>> >>>> Due to lack of participate (just Manju & I), we cancelled this week's call. We didn't have anything major to discuss today as we have the forum meeting next week and things have mostly been prepped for that meeting. I distributed the most recent version of the slides this morning. I don't think there are any more changes to be made there other than deciding about the failure_ack/get_acked vs. get_failed semantic. Once we make a decision, we need to remove one slide or the other. Which brings me to the other point I was going to discuss today: >>>> >>>> Aurelien provided an example use case for the MPI_COMM_GET_FAILED semantic just before the call last week. >>> >>> Reading Aurelien's email I have a different understanding. It seems that he provides an example on how it can be used, and not a use case. While the example seems to be correct it is extremely complex, not something we want to enforce on users. >>> >>> The current approach with two separate calls ACK + GET_ACK allows for a simpler management of errors while enabling the developers to write different, more flexible, approaches to deal with failures. I fail to see the need to replace such a flexible mechanism with a call that only allows a single usage pattern. >>> >>> George. >>> >>>> Since we didn't have much time with it, we decided to wait and discuss it this week. I've been looking at it and the idea seems solid to me. It's possible that there might be a semantic issue or two, but the rationale seems good. I propose that we combine MPI_COMM_FAILURE_ACK/GET_ACKED to create a new function MPI_COMM_GET_FAILED. Essentially the new function will do exactly the same thing as the previous functions, just without the separated semantics. The function header would look like this: >>>> >>>> int MPI_Comm_get_failed(MPI_Comm comm, MPI_Group *failed_group); >>>> >>>> Where ''failed_group'' is the group of processes which is locally known to have failed in ''comm''. Obviously there will need to be some textual changes in the chapter to reflect this change. For the slides, essentially, we just need to take out slide 7 and remove "[Alternative]" from the title of slide 8. I won't bother sending out another version of the slides for this. Rich, can you make these changes in your version? >>>> >>>> Other than that, we can talk about future plans on the next call. My participation over the next month or two might be intermittent. My wife and I are expecting our first baby in the next 2-3 weeks so I might miss a couple of calls. >>>> >>>> Thanks, >>>> Wesley >>>> >>>> >>>> On Tue, Sep 3, 2013 at 8:58 AM, Wesley Bland <wbland(a)mcs.anl.gov> wrote: >>>> Dear WG members, >>>> >>>> This is a reminder that according to our planning, we are having our regular phone meeting today at 3pm EDT. >>>> >>>> NOTE THE NEW CALL-IN NUMBER. This a permanent change from the old number. >>>> >>>> Date: September 3, >>>> Time: 3pm EDT/New York >>>> Dial-in information: 712-432-0360 >>>> Code: 623998# >>>> >>>> Agenda: >>>> * Discuss Aurelien's example for MPI_COMM_GET_FAILED >>>> * Plan for Madrid meeting (quick skim of slides, including changes which happened after last call) >>>> * Discuss plan for proposal moving toward December reading >>>> >>>> Next Meetings: >>>> * September 17, 2013 >>>> * October 1, 2013 >>>> * October 15, 2013 >>>> * October 29, 2013 >>>> >>>> _______________________________________________ >>>> mpiwg-ft mailing list >>>> mpiwg-ft(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft >>> >>> _______________________________________________ >>> mpiwg-ft mailing list >>> mpiwg-ft(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft >> >> _______________________________________________ >> mpiwg-ft mailing list >> mpiwg-ft(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft > > -- > * Dr. Aurélien Bouteiller > * Researcher at Innovative Computing Laboratory > * University of Tennessee > * 1122 Volunteer Boulevard, suite 309b > * Knoxville, TN 37996 > * 865 974 9375 > > > > > > > > _______________________________________________ > mpiwg-ft mailing list > mpiwg-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft

1 0

Re: [mpiwg-ft] FTWG Con Call 2013-09-03
by Aurélien Bouteiller 05 Sep '13

05 Sep '13

I cannot read steadily my emails. I am in backward europe now :) Anyway, George statement is correct. I found a circumvolved way to use the single call, it works, but it is very ugly and extremely difficult to understand/operate. The split operation is much simpler to use. Additionnaly for several use cases (where the user just want to resume ANY_SOURCE and does not care about the failed group) it can spare quite a significant memory overhead on group storage. I advise we keep it as-is. I won't be very active in the next 2 weeks. I hope for the best :) Aurelien Le 4 sept. 2013 à 21:19, Wesley Bland <wbland(a)mcs.anl.gov> a écrit : > His email was designed to show that it is possible to use either case reliably. In fact, both cases require this check to ensure that you aren't acknowledging failures that you didn't mean to acknowledge. The only difference is that they're combined into one call. You still need to be careful to ensure that you don't acknowledge failures while another thread is using an ANY_SOURCE. So in the end, they should be equivalent. > > Wesley > > On Sep 3, 2013, at 5:13 PM, George Bosilca <bosilca(a)icl.utk.edu> wrote: > >> On Sep 3, 2013, at 21:40 , Wesley Bland <wbland(a)mcs.anl.gov> wrote: >> >>> Due to lack of participate (just Manju & I), we cancelled this week's call. We didn't have anything major to discuss today as we have the forum meeting next week and things have mostly been prepped for that meeting. I distributed the most recent version of the slides this morning. I don't think there are any more changes to be made there other than deciding about the failure_ack/get_acked vs. get_failed semantic. Once we make a decision, we need to remove one slide or the other. Which brings me to the other point I was going to discuss today: >>> >>> Aurelien provided an example use case for the MPI_COMM_GET_FAILED semantic just before the call last week. >> >> Reading Aurelien's email I have a different understanding. It seems that he provides an example on how it can be used, and not a use case. While the example seems to be correct it is extremely complex, not something we want to enforce on users. >> >> The current approach with two separate calls ACK + GET_ACK allows for a simpler management of errors while enabling the developers to write different, more flexible, approaches to deal with failures. I fail to see the need to replace such a flexible mechanism with a call that only allows a single usage pattern. >> >> George. >> >>> Since we didn't have much time with it, we decided to wait and discuss it this week. I've been looking at it and the idea seems solid to me. It's possible that there might be a semantic issue or two, but the rationale seems good. I propose that we combine MPI_COMM_FAILURE_ACK/GET_ACKED to create a new function MPI_COMM_GET_FAILED. Essentially the new function will do exactly the same thing as the previous functions, just without the separated semantics. The function header would look like this: >>> >>> int MPI_Comm_get_failed(MPI_Comm comm, MPI_Group *failed_group); >>> >>> Where ''failed_group'' is the group of processes which is locally known to have failed in ''comm''. Obviously there will need to be some textual changes in the chapter to reflect this change. For the slides, essentially, we just need to take out slide 7 and remove "[Alternative]" from the title of slide 8. I won't bother sending out another version of the slides for this. Rich, can you make these changes in your version? >>> >>> Other than that, we can talk about future plans on the next call. My participation over the next month or two might be intermittent. My wife and I are expecting our first baby in the next 2-3 weeks so I might miss a couple of calls. >>> >>> Thanks, >>> Wesley >>> >>> >>> On Tue, Sep 3, 2013 at 8:58 AM, Wesley Bland <wbland(a)mcs.anl.gov> wrote: >>> Dear WG members, >>> >>> This is a reminder that according to our planning, we are having our regular phone meeting today at 3pm EDT. >>> >>> NOTE THE NEW CALL-IN NUMBER. This a permanent change from the old number. >>> >>> Date: September 3, >>> Time: 3pm EDT/New York >>> Dial-in information: 712-432-0360 >>> Code: 623998# >>> >>> Agenda: >>> * Discuss Aurelien's example for MPI_COMM_GET_FAILED >>> * Plan for Madrid meeting (quick skim of slides, including changes which happened after last call) >>> * Discuss plan for proposal moving toward December reading >>> >>> Next Meetings: >>> * September 17, 2013 >>> * October 1, 2013 >>> * October 15, 2013 >>> * October 29, 2013 >>> >>> _______________________________________________ >>> mpiwg-ft mailing list >>> mpiwg-ft(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft >> >> _______________________________________________ >> mpiwg-ft mailing list >> mpiwg-ft(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft > > _______________________________________________ > mpiwg-ft mailing list > mpiwg-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft -- * Dr. Aurélien Bouteiller * Researcher at Innovative Computing Laboratory * University of Tennessee * 1122 Volunteer Boulevard, suite 309b * Knoxville, TN 37996 * 865 974 9375

1 0

Re: [mpiwg-ft] FTWG Con Call 2013-09-03
by Wesley Bland 04 Sep '13

04 Sep '13

His email was designed to show that it is possible to use either case reliably. In fact, both cases require this check to ensure that you aren't acknowledging failures that you didn't mean to acknowledge. The only difference is that they're combined into one call. You still need to be careful to ensure that you don't acknowledge failures while another thread is using an ANY_SOURCE. So in the end, they should be equivalent. Wesley On Sep 3, 2013, at 5:13 PM, George Bosilca <bosilca(a)icl.utk.edu> wrote: > On Sep 3, 2013, at 21:40 , Wesley Bland <wbland(a)mcs.anl.gov> wrote: > >> Due to lack of participate (just Manju & I), we cancelled this week's call. We didn't have anything major to discuss today as we have the forum meeting next week and things have mostly been prepped for that meeting. I distributed the most recent version of the slides this morning. I don't think there are any more changes to be made there other than deciding about the failure_ack/get_acked vs. get_failed semantic. Once we make a decision, we need to remove one slide or the other. Which brings me to the other point I was going to discuss today: >> >> Aurelien provided an example use case for the MPI_COMM_GET_FAILED semantic just before the call last week. > > Reading Aurelien's email I have a different understanding. It seems that he provides an example on how it can be used, and not a use case. While the example seems to be correct it is extremely complex, not something we want to enforce on users. > > The current approach with two separate calls ACK + GET_ACK allows for a simpler management of errors while enabling the developers to write different, more flexible, approaches to deal with failures. I fail to see the need to replace such a flexible mechanism with a call that only allows a single usage pattern. > > George. > >> Since we didn't have much time with it, we decided to wait and discuss it this week. I've been looking at it and the idea seems solid to me. It's possible that there might be a semantic issue or two, but the rationale seems good. I propose that we combine MPI_COMM_FAILURE_ACK/GET_ACKED to create a new function MPI_COMM_GET_FAILED. Essentially the new function will do exactly the same thing as the previous functions, just without the separated semantics. The function header would look like this: >> >> int MPI_Comm_get_failed(MPI_Comm comm, MPI_Group *failed_group); >> >> Where ''failed_group'' is the group of processes which is locally known to have failed in ''comm''. Obviously there will need to be some textual changes in the chapter to reflect this change. For the slides, essentially, we just need to take out slide 7 and remove "[Alternative]" from the title of slide 8. I won't bother sending out another version of the slides for this. Rich, can you make these changes in your version? >> >> Other than that, we can talk about future plans on the next call. My participation over the next month or two might be intermittent. My wife and I are expecting our first baby in the next 2-3 weeks so I might miss a couple of calls. >> >> Thanks, >> Wesley >> >> >> On Tue, Sep 3, 2013 at 8:58 AM, Wesley Bland <wbland(a)mcs.anl.gov> wrote: >> Dear WG members, >> >> This is a reminder that according to our planning, we are having our regular phone meeting today at 3pm EDT. >> >> NOTE THE NEW CALL-IN NUMBER. This a permanent change from the old number. >> >> Date: September 3, >> Time: 3pm EDT/New York >> Dial-in information: 712-432-0360 >> Code: 623998# >> >> Agenda: >> * Discuss Aurelien's example for MPI_COMM_GET_FAILED >> * Plan for Madrid meeting (quick skim of slides, including changes which happened after last call) >> * Discuss plan for proposal moving toward December reading >> >> Next Meetings: >> * September 17, 2013 >> * October 1, 2013 >> * October 15, 2013 >> * October 29, 2013 >> >> _______________________________________________ >> mpiwg-ft mailing list >> mpiwg-ft(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft > > _______________________________________________ > mpiwg-ft mailing list > mpiwg-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft

1 0

Re: [mpiwg-ft] FTWG Con Call 2013-09-03
by George Bosilca 03 Sep '13

03 Sep '13

On Sep 3, 2013, at 21:40 , Wesley Bland <wbland(a)mcs.anl.gov> wrote: > Due to lack of participate (just Manju & I), we cancelled this week's call. We didn't have anything major to discuss today as we have the forum meeting next week and things have mostly been prepped for that meeting. I distributed the most recent version of the slides this morning. I don't think there are any more changes to be made there other than deciding about the failure_ack/get_acked vs. get_failed semantic. Once we make a decision, we need to remove one slide or the other. Which brings me to the other point I was going to discuss today: > > Aurelien provided an example use case for the MPI_COMM_GET_FAILED semantic just before the call last week. Reading Aurelien's email I have a different understanding. It seems that he provides an example on how it can be used, and not a use case. While the example seems to be correct it is extremely complex, not something we want to enforce on users. The current approach with two separate calls ACK + GET_ACK allows for a simpler management of errors while enabling the developers to write different, more flexible, approaches to deal with failures. I fail to see the need to replace such a flexible mechanism with a call that only allows a single usage pattern. George. > Since we didn't have much time with it, we decided to wait and discuss it this week. I've been looking at it and the idea seems solid to me. It's possible that there might be a semantic issue or two, but the rationale seems good. I propose that we combine MPI_COMM_FAILURE_ACK/GET_ACKED to create a new function MPI_COMM_GET_FAILED. Essentially the new function will do exactly the same thing as the previous functions, just without the separated semantics. The function header would look like this: > > int MPI_Comm_get_failed(MPI_Comm comm, MPI_Group *failed_group); > > Where ''failed_group'' is the group of processes which is locally known to have failed in ''comm''. Obviously there will need to be some textual changes in the chapter to reflect this change. For the slides, essentially, we just need to take out slide 7 and remove "[Alternative]" from the title of slide 8. I won't bother sending out another version of the slides for this. Rich, can you make these changes in your version? > > Other than that, we can talk about future plans on the next call. My participation over the next month or two might be intermittent. My wife and I are expecting our first baby in the next 2-3 weeks so I might miss a couple of calls. > > Thanks, > Wesley > > > On Tue, Sep 3, 2013 at 8:58 AM, Wesley Bland <wbland(a)mcs.anl.gov> wrote: > Dear WG members, > > This is a reminder that according to our planning, we are having our regular phone meeting today at 3pm EDT. > > NOTE THE NEW CALL-IN NUMBER. This a permanent change from the old number. > > Date: September 3, > Time: 3pm EDT/New York > Dial-in information: 712-432-0360 > Code: 623998# > > Agenda: > * Discuss Aurelien's example for MPI_COMM_GET_FAILED > * Plan for Madrid meeting (quick skim of slides, including changes which happened after last call) > * Discuss plan for proposal moving toward December reading > > Next Meetings: > * September 17, 2013 > * October 1, 2013 > * October 15, 2013 > * October 29, 2013 > > _______________________________________________ > mpiwg-ft mailing list > mpiwg-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-ft

1 0

Re: [mpiwg-ft] FTWG Con Call 2013-09-03
by Wesley Bland 03 Sep '13

03 Sep '13

Due to lack of participate (just Manju & I), we cancelled this week's call. We didn't have anything major to discuss today as we have the forum meeting next week and things have mostly been prepped for that meeting. I distributed the most recent version of the slides this morning. I don't think there are any more changes to be made there other than deciding about the failure_ack/get_acked vs. get_failed semantic. Once we make a decision, we need to remove one slide or the other. Which brings me to the other point I was going to discuss today: Aurelien provided an example use case for the MPI_COMM_GET_FAILED semantic just before the call last week. Since we didn't have much time with it, we decided to wait and discuss it this week. I've been looking at it and the idea seems solid to me. It's possible that there might be a semantic issue or two, but the rationale seems good. I propose that we combine MPI_COMM_FAILURE_ACK/GET_ACKED to create a new function MPI_COMM_GET_FAILED. Essentially the new function will do exactly the same thing as the previous functions, just without the separated semantics. The function header would look like this: int MPI_Comm_get_failed(MPI_Comm comm, MPI_Group *failed_group); Where ''failed_group'' is the group of processes which is locally known to have failed in ''comm''. Obviously there will need to be some textual changes in the chapter to reflect this change. For the slides, essentially, we just need to take out slide 7 and remove "[Alternative]" from the title of slide 8. I won't bother sending out another version of the slides for this. Rich, can you make these changes in your version? Other than that, we can talk about future plans on the next call. My participation over the next month or two might be intermittent. My wife and I are expecting our first baby in the next 2-3 weeks so I might miss a couple of calls. Thanks, Wesley On Tue, Sep 3, 2013 at 8:58 AM, Wesley Bland <wbland(a)mcs.anl.gov> wrote: > Dear WG members, > > This is a reminder that according to our planning, we are having our > regular phone meeting today at 3pm EDT. > > *NOTE THE NEW CALL-IN NUMBER.* This a permanent change from the old > number. > > Date: September 3, > Time: 3pm EDT/New York > Dial-in information: 712-432-0360 <218-339-4600> > Code: 623998# > > Agenda: > * Discuss Aurelien's example for MPI_COMM_GET_FAILED > * Plan for Madrid meeting (quick skim of slides, including changes which > happened after last call) > * Discuss plan for proposal moving toward December reading > > Next Meetings: > * September 17, 2013 > * October 1, 2013 > * October 15, 2013 > * October 29, 2013 >

1 0