November 2011 - mpiwg-ft - mailman3.cels.anl.gov

[Mpi3-ft] FT WG Teleconference Wednesday @ Noon EDT
by Josh Hursey 29 Nov '11

29 Nov '11

Reminder that we have a teleconf tomorrow, Wednesday 11/30/2011, at Noon EDT. Date: November 30, 2011 Time: Noon EST/New York Dial-in information: 877-801-8130 Code: 1044056 Agenda: - Run-Through Stabilization Proposal https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/ft/rts_proposal_main - Other items? Additional Agenda Items [as time permits]: - Run-Through Stabilization Proposal https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/ft/run_through_stabilizat… https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/ft/run_through_stabilizat… - Process Recovery (Josh H.) https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/ft/process_recovery_2 - MPI Forum notes discussion (?) http://lists.mpi-forum.org/mpi3-ft/2011/07/0805.php - Error to Fault changes proposal (Darius B.) http://lists.mpi-forum.org/mpi3-ft/2011/06/0773.php - Piggybacking? (Martin S.) https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/Piggybacking - Network Channel Failure http://lists.mpi-forum.org/mpi3-ft/2011/06/0730.php - FT Query Interface http://lists.mpi-forum.org/mpi3-ft/2011/06/0737.php Next Meetings: * Dec. 7, 2011 (Teleconf) * Dec. 14, 2011 (Teleconf) * Jan. 4, 2012 (Teleconf) * Jan. 9, 2012 (MPI Forum Meeting) Respond to the list if you have any additional topics that you would like to discuss. -- Josh -- Joshua Hursey Postdoctoral Research Associate Oak Ridge National Laboratory http://users.nccs.gov/~jjhursey

1 0

Re: [Mpi3-ft] New version of the RTS proposal
by Josh Hursey 09 Nov '11

09 Nov '11

A new version of the document is available on the following wiki page: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/ft/rts_proposal_main Change Log:-----------* 17.3: Added correction for 'connected' processes* 17.5.6: Tweaked wording of MPI_INIT to read "If MPI_INIT fails then it should try to raise an appropriate error class and not abort by default."* Remove note about object "should be collectively active upon successful creation."* 17.9: Removed sentence about MPI_CART_SUB* 17.11: Added a note about the behavior of one sided communication with known failed processes:ï¿½ The behavior of one-sided communication and synchronization operations involving a recognized failed process using a validated window object is undefined, with the exception of \mpifunc{MPI\_WIN\_FENCE}. \mpifunc{MPI\_WIN\_FENCE} will exclude the recognized failed processes from the collective operation. -- Josh On Wed, Nov 9, 2011 at 9:31 AM, Josh Hursey <jjhursey(a)open-mpi.org> wrote: > On Tue, Nov 8, 2011 at 4:22 PM, Darius Buntinas <buntinas(a)mcs.anl.gov> wrote: >> On Nov 8, 2011, at 2:47 PM, Josh Hursey wrote: >> >>> On Tue, Nov 8, 2011 at 3:03 PM, Darius Buntinas <buntinas(a)mcs.anl.gov> wrote: >>>> >>>> I saw this sentence in the proposal: >>>> ï¿½ ï¿½\MPI/ guarantees that eventually all processes in the \MPI/ >>>> ï¿½ ï¿½universe will become aware of all process failures. >>>> >>>> I think we only want to say all processes will become aware of all >>>> failures of _connected_ processes. ï¿½Two MPI jobs can technically >>>> belong to the same universe, but they don't need to be aware of each >>>> other's failures unless they're connected. ï¿½Besides, unless they were >>>> connected, there would be no way to identify the failed processes of >>>> one job to the processes of the other job. >>> >>> >>> I agree that adding _connected_ here helps clarify this statement. >>> >>>> >>>> As an aside, I did some grepping for "universe" in the standard, and >>>> found that universe is actually not well defined. ï¿½It can refer to >>>> communication within a communicator (p29), an implementation defined >>>> scope of a port name (p320) and an implementation defined set of >>>> processes that can communicate with each other. ï¿½Then there's >>>> MPI_UNIVERSE_SIZE which is the number of total processes that "can >>>> usefully be started," (p308) which implies the definition of universe >>>> that I think most people use, namely, the set of all potential >>>> processes that some process can be made aware of / be connected to. >>> >>> Humm... This is an interesting point. I think we are ok using universe >>> in the context of all processes that a single process may be connected >>> to. >> >> I think we agree, but in your sentence, I would change "may be connected to" to "can possibly connect to". ï¿½The universe implied by MPI_UNIVERSE_SIZE includes processes that the process has not connected to and even processes that haven't been created yet. >> >>> In terms of the failure detector statement, that would mean that MPI >>> provides a process notification of process failure: >>> - in it's own MPI_COMM_WORLD >>> - in a remote group when the process joins with it (via connect/accept) >> >> ï¿½- in the remote group of a parent communicator >> ï¿½- in the remote group of an intercomm returned from a spawn >> >>> But not provide the process notification of process failure if it is >>> not connected to it (2 disjoint spawned groups). >> >> Right, if the process has no communicator that contains the failed process, then there's no sense in reporting it. ï¿½So technically those disjoint spawned groups are connected (Section 10.5.4), but need not report share failure info. >> >>> So at the point where an inter-communicator is created between two >>> disjoint MPI_COMM_WORLDs then they must share failure information with >>> one another regarding the local/remote groups. But if the two disjoin >>> MPI_COMM_WORLDs never collide then they need not know about one >>> another. >> >> Right. >> >>> What do you think? >> >> I don't think we need a big clarification section on this since there's no way for the failure detector to describe the failure of a process to processes that don't share a communicator. ï¿½I guess I was just pointing out that the requirement that a process be notified of any failure in the universe is impossible to satisfy. > > I agree that a big clarification about what we mean by universe is > probably distracting/confusing, and doesn't buy us much in this > section. > > How about the following modifications (all on p540): > Line 10: > ï¿½Change "... processes will know about the failures." > ï¿½to "... processes will know about all failures of connected processes." > Line 25: > ï¿½Change "... processes will be known to all alive processes." > ï¿½to "... processes will be known to all alive processes connected to it." > Line 46: > ï¿½Change "... will become aware of all process failures." > ï¿½to "... will become aware of all failures of connected processes." > > -- Josh > >> >> -d >> >> >>> -- Josh >>> >>>> >>>> -d >>>> >>>> _______________________________________________ >>>> mpi3-ft mailing list >>>> mpi3-ft(a)lists.mpi-forum.org >>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft >>>> >>>> >>> >>> >>> >>> -- >>> Joshua Hursey >>> Postdoctoral Research Associate >>> Oak Ridge National Laboratory >>> http://users.nccs.gov/~jjhursey >>> >>> _______________________________________________ >>> mpi3-ft mailing list >>> mpi3-ft(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft >> >> >> _______________________________________________ >> mpi3-ft mailing list >> mpi3-ft(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft >> >> > > > > -- > Joshua Hursey > Postdoctoral Research Associate > Oak Ridge National Laboratory > http://users.nccs.gov/~jjhursey > -- Joshua Hursey Postdoctoral Research Associate Oak Ridge National Laboratory http://users.nccs.gov/~jjhursey

1 0

Re: [Mpi3-ft] New version of the RTS proposal
by Josh Hursey 09 Nov '11

09 Nov '11

On Tue, Nov 8, 2011 at 4:22 PM, Darius Buntinas <buntinas(a)mcs.anl.gov> wrote: > On Nov 8, 2011, at 2:47 PM, Josh Hursey wrote: > >> On Tue, Nov 8, 2011 at 3:03 PM, Darius Buntinas <buntinas(a)mcs.anl.gov> wrote: >>> >>> I saw this sentence in the proposal: >>> ï¿½ ï¿½\MPI/ guarantees that eventually all processes in the \MPI/ >>> ï¿½ ï¿½universe will become aware of all process failures. >>> >>> I think we only want to say all processes will become aware of all >>> failures of _connected_ processes. ï¿½Two MPI jobs can technically >>> belong to the same universe, but they don't need to be aware of each >>> other's failures unless they're connected. ï¿½Besides, unless they were >>> connected, there would be no way to identify the failed processes of >>> one job to the processes of the other job. >> >> >> I agree that adding _connected_ here helps clarify this statement. >> >>> >>> As an aside, I did some grepping for "universe" in the standard, and >>> found that universe is actually not well defined. ï¿½It can refer to >>> communication within a communicator (p29), an implementation defined >>> scope of a port name (p320) and an implementation defined set of >>> processes that can communicate with each other. ï¿½Then there's >>> MPI_UNIVERSE_SIZE which is the number of total processes that "can >>> usefully be started," (p308) which implies the definition of universe >>> that I think most people use, namely, the set of all potential >>> processes that some process can be made aware of / be connected to. >> >> Humm... This is an interesting point. I think we are ok using universe >> in the context of all processes that a single process may be connected >> to. > > I think we agree, but in your sentence, I would change "may be connected to" to "can possibly connect to". ï¿½The universe implied by MPI_UNIVERSE_SIZE includes processes that the process has not connected to and even processes that haven't been created yet. > >> In terms of the failure detector statement, that would mean that MPI >> provides a process notification of process failure: >> - in it's own MPI_COMM_WORLD >> - in a remote group when the process joins with it (via connect/accept) > > ï¿½- in the remote group of a parent communicator > ï¿½- in the remote group of an intercomm returned from a spawn > >> But not provide the process notification of process failure if it is >> not connected to it (2 disjoint spawned groups). > > Right, if the process has no communicator that contains the failed process, then there's no sense in reporting it. ï¿½So technically those disjoint spawned groups are connected (Section 10.5.4), but need not report share failure info. > >> So at the point where an inter-communicator is created between two >> disjoint MPI_COMM_WORLDs then they must share failure information with >> one another regarding the local/remote groups. But if the two disjoin >> MPI_COMM_WORLDs never collide then they need not know about one >> another. > > Right. > >> What do you think? > > I don't think we need a big clarification section on this since there's no way for the failure detector to describe the failure of a process to processes that don't share a communicator. ï¿½I guess I was just pointing out that the requirement that a process be notified of any failure in the universe is impossible to satisfy. I agree that a big clarification about what we mean by universe is probably distracting/confusing, and doesn't buy us much in this section. How about the following modifications (all on p540): Line 10: Change "... processes will know about the failures." to "... processes will know about all failures of connected processes." Line 25: Change "... processes will be known to all alive processes." to "... processes will be known to all alive processes connected to it." Line 46: Change "... will become aware of all process failures." to "... will become aware of all failures of connected processes." -- Josh > > -d > > >> -- Josh >> >>> >>> -d >>> >>> _______________________________________________ >>> mpi3-ft mailing list >>> mpi3-ft(a)lists.mpi-forum.org >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft >>> >>> >> >> >> >> -- >> Joshua Hursey >> Postdoctoral Research Associate >> Oak Ridge National Laboratory >> http://users.nccs.gov/~jjhursey >> >> _______________________________________________ >> mpi3-ft mailing list >> mpi3-ft(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft > > > _______________________________________________ > mpi3-ft mailing list > mpi3-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft > > -- Joshua Hursey Postdoctoral Research Associate Oak Ridge National Laboratory http://users.nccs.gov/~jjhursey

1 0

Re: [Mpi3-ft] New version of the RTS proposal
by Josh Hursey 09 Nov '11

09 Nov '11

I suspect that maybe I've confused myself thinking about this too much, and maybe it is best to talk at the teleconf today about this. I guess what was troubling me was in the scenario where MPI_INIT cannot complete successfully due to process failure (e.g., it messed up the connection establishment in a way that cannot be recovered). So MPI_Init bails out with an error. What can the MPI application do? It is not allowed to call MPI_Init again, and the state of the internal library is non-functional in this case. So in the example above, I would think that the MPI implementation would terminate the calling process because the user is left with no recourse in managing that scenario. The user may not be abel to even set an error handler or call MPI_Finalize. However if MPI_Init found a process failure during initialization, and was able to successfully setup the library in spite of the failure then I think we are in the safe zone for the user. We need MPI_Init to return success and raise an error at the next MPI operation. So we previously said that: "if a process failure occurs before or during MPI_INIT then MPI_INIT should try to raise and error and not abort by default." If MPI_Init raises an error then what does that mean to the application. If it is PROC_FAIL_STOP, does that mean that the MPI library is initialized, but detected a process failure? or does it mean that the MPI library is not setup because it returned an error (the operation failed). It might be better to say that MPI_INIT will -not- return an error of the class PROC_FAIL_STOP if a process failure is detected during MPI_INIT but the library initialized properly. This error is delayed until the next MPI call. ... But then what is the difference between detecting the process failure during MPI_INIT versus just afterward? Maybe I'm just troubled by the idea that MPI_INIT can return an error, but still have completed successfully. What do you all think? -- Josh On Tue, Nov 8, 2011 at 4:00 PM, Darius Buntinas <buntinas(a)mcs.anl.gov> wrote: > > I think what we have doesn't require it to complete successfully. ï¿½It says MPI_INIT should try to raise an error and not abort by default. ï¿½Then the advice to implementors says a critical error can make it abort. > > However, I think maybe we should say that MPI_Init is not required to raise an error simply because it detected a process failure. ï¿½It should raise an error (and give an error on the next non-errhandler function blah blah...) if it is unable to initialize the library due to a process failure. > > Or is this what you were suggesting? > > -d > > > On Nov 7, 2011, at 12:58 PM, Josh Hursey wrote: > >> * We need to review 17.5.6: What if MPI_INIT does not internally >> complete successfully due to process failure? The text seems to assume >> that MPI_INIT will always be able to complete successfully in the >> presence of failure. Maybe we should state that 'if it is able to >> complete successfully, then it should even in the presence of >> failure'? > > > _______________________________________________ > mpi3-ft mailing list > mpi3-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft > > -- Joshua Hursey Postdoctoral Research Associate Oak Ridge National Laboratory http://users.nccs.gov/~jjhursey

1 0

Re: [Mpi3-ft] New version of the RTS proposal
by Josh Hursey 09 Nov '11

09 Nov '11

Yeah I think that makes sense. It was the comment about mpi_comm_split in the MPI_CART_SUB paragraph in the current standard that was throwing me. I agree that since a process cannot contribute a value (like the 'color' in mpi_comm_split) then there is nothing more we can say. So it just falls into the class of other topology creation operations that may carry over failed processes to the derived communicators. I'll remove the sentence on p561 line 21-22 in the next pass. Thanks, Josh On Tue, Nov 8, 2011 at 3:47 PM, Darius Buntinas <buntinas(a)mcs.anl.gov> wrote: > > In MPI_Cart_sub, processes don't "contribute" to the operation, so the current sentence on p561 doesn't really make sense. ï¿½However, I don't think what we did for MPI_Comm_split will work here either. ï¿½I think that MPI_Cart_sub should create the communicators as described in Section 7.5.7, which may result in failed processes being included in a new communicator. > > E.g., in Example 7.8 on p291, if the process at coordinate (0,2,1) in the topology failed, then if remain_dims = (true, false, true), then the third communicator (i.e., the one containing processes at coordinates (A,2,B), A = 0..1, B = 0..3) would have a failed process (at coordinates (0,1) ). > > Maybe the example makes things more confusing. ï¿½I think MPI_CART_SUB is already covered in by the sentence starting on line 7 page 561, so we can probably take the MPI_CART_SUB sentence out. > > -d > > > On Nov 7, 2011, at 12:58 PM, Josh Hursey wrote: > >> * I would like some more folks to look over the process topologies >> chapter. In particular I think we need to fix the wording for >> MPI_CART_SUB - maybe to better match the wording for mpi_comm_split. > > > _______________________________________________ > mpi3-ft mailing list > mpi3-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft > > -- Joshua Hursey Postdoctoral Research Associate Oak Ridge National Laboratory http://users.nccs.gov/~jjhursey

1 0

Re: [Mpi3-ft] New version of the RTS proposal
by Darius Buntinas 08 Nov '11

08 Nov '11

On Nov 8, 2011, at 2:47 PM, Josh Hursey wrote: > On Tue, Nov 8, 2011 at 3:03 PM, Darius Buntinas <buntinas(a)mcs.anl.gov> wrote: >> >> I saw this sentence in the proposal: >> \MPI/ guarantees that eventually all processes in the \MPI/ >> universe will become aware of all process failures. >> >> I think we only want to say all processes will become aware of all >> failures of _connected_ processes. Two MPI jobs can technically >> belong to the same universe, but they don't need to be aware of each >> other's failures unless they're connected. Besides, unless they were >> connected, there would be no way to identify the failed processes of >> one job to the processes of the other job. > > > I agree that adding _connected_ here helps clarify this statement. > >> >> As an aside, I did some grepping for "universe" in the standard, and >> found that universe is actually not well defined. It can refer to >> communication within a communicator (p29), an implementation defined >> scope of a port name (p320) and an implementation defined set of >> processes that can communicate with each other. Then there's >> MPI_UNIVERSE_SIZE which is the number of total processes that "can >> usefully be started," (p308) which implies the definition of universe >> that I think most people use, namely, the set of all potential >> processes that some process can be made aware of / be connected to. > > Humm... This is an interesting point. I think we are ok using universe > in the context of all processes that a single process may be connected > to. I think we agree, but in your sentence, I would change "may be connected to" to "can possibly connect to". The universe implied by MPI_UNIVERSE_SIZE includes processes that the process has not connected to and even processes that haven't been created yet. > In terms of the failure detector statement, that would mean that MPI > provides a process notification of process failure: > - in it's own MPI_COMM_WORLD > - in a remote group when the process joins with it (via connect/accept) - in the remote group of a parent communicator - in the remote group of an intercomm returned from a spawn > But not provide the process notification of process failure if it is > not connected to it (2 disjoint spawned groups). Right, if the process has no communicator that contains the failed process, then there's no sense in reporting it. So technically those disjoint spawned groups are connected (Section 10.5.4), but need not report share failure info. > So at the point where an inter-communicator is created between two > disjoint MPI_COMM_WORLDs then they must share failure information with > one another regarding the local/remote groups. But if the two disjoin > MPI_COMM_WORLDs never collide then they need not know about one > another. Right. > What do you think? I don't think we need a big clarification section on this since there's no way for the failure detector to describe the failure of a process to processes that don't share a communicator. I guess I was just pointing out that the requirement that a process be notified of any failure in the universe is impossible to satisfy. -d > -- Josh > >> >> -d >> >> _______________________________________________ >> mpi3-ft mailing list >> mpi3-ft(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft >> >> > > > > -- > Joshua Hursey > Postdoctoral Research Associate > Oak Ridge National Laboratory > http://users.nccs.gov/~jjhursey > > _______________________________________________ > mpi3-ft mailing list > mpi3-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft

1 0

Re: [Mpi3-ft] New version of the RTS proposal
by Darius Buntinas 08 Nov '11

08 Nov '11

I think what we have doesn't require it to complete successfully. It says MPI_INIT should try to raise an error and not abort by default. Then the advice to implementors says a critical error can make it abort. However, I think maybe we should say that MPI_Init is not required to raise an error simply because it detected a process failure. It should raise an error (and give an error on the next non-errhandler function blah blah...) if it is unable to initialize the library due to a process failure. Or is this what you were suggesting? -d On Nov 7, 2011, at 12:58 PM, Josh Hursey wrote: > * We need to review 17.5.6: What if MPI_INIT does not internally > complete successfully due to process failure? The text seems to assume > that MPI_INIT will always be able to complete successfully in the > presence of failure. Maybe we should state that 'if it is able to > complete successfully, then it should even in the presence of > failure'?

1 0

Re: [Mpi3-ft] New version of the RTS proposal
by Josh Hursey 08 Nov '11

08 Nov '11

On Tue, Nov 8, 2011 at 3:03 PM, Darius Buntinas <buntinas(a)mcs.anl.gov> wrote: > > I saw this sentence in the proposal: > ï¿½ ï¿½\MPI/ guarantees that eventually all processes in the \MPI/ > ï¿½ ï¿½universe will become aware of all process failures. > > I think we only want to say all processes will become aware of all > failures of _connected_ processes. ï¿½Two MPI jobs can technically > belong to the same universe, but they don't need to be aware of each > other's failures unless they're connected. ï¿½Besides, unless they were > connected, there would be no way to identify the failed processes of > one job to the processes of the other job. I agree that adding _connected_ here helps clarify this statement. > > As an aside, I did some grepping for "universe" in the standard, and > found that universe is actually not well defined. ï¿½It can refer to > communication within a communicator (p29), an implementation defined > scope of a port name (p320) and an implementation defined set of > processes that can communicate with each other. ï¿½Then there's > MPI_UNIVERSE_SIZE which is the number of total processes that "can > usefully be started," (p308) which implies the definition of universe > that I think most people use, namely, the set of all potential > processes that some process can be made aware of / be connected to. Humm... This is an interesting point. I think we are ok using universe in the context of all processes that a single process may be connected to. In terms of the failure detector statement, that would mean that MPI provides a process notification of process failure: - in it's own MPI_COMM_WORLD - in a remote group when the process joins with it (via connect/accept) But not provide the process notification of process failure if it is not connected to it (2 disjoint spawned groups). So at the point where an inter-communicator is created between two disjoint MPI_COMM_WORLDs then they must share failure information with one another regarding the local/remote groups. But if the two disjoin MPI_COMM_WORLDs never collide then they need not know about one another. What do you think? -- Josh > > -d > > _______________________________________________ > mpi3-ft mailing list > mpi3-ft(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft > > -- Joshua Hursey Postdoctoral Research Associate Oak Ridge National Laboratory http://users.nccs.gov/~jjhursey

1 0

Re: [Mpi3-ft] New version of the RTS proposal
by Darius Buntinas 08 Nov '11

08 Nov '11

In MPI_Cart_sub, processes don't "contribute" to the operation, so the current sentence on p561 doesn't really make sense. However, I don't think what we did for MPI_Comm_split will work here either. I think that MPI_Cart_sub should create the communicators as described in Section 7.5.7, which may result in failed processes being included in a new communicator. E.g., in Example 7.8 on p291, if the process at coordinate (0,2,1) in the topology failed, then if remain_dims = (true, false, true), then the third communicator (i.e., the one containing processes at coordinates (A,2,B), A = 0..1, B = 0..3) would have a failed process (at coordinates (0,1) ). Maybe the example makes things more confusing. I think MPI_CART_SUB is already covered in by the sentence starting on line 7 page 561, so we can probably take the MPI_CART_SUB sentence out. -d On Nov 7, 2011, at 12:58 PM, Josh Hursey wrote: > * I would like some more folks to look over the process topologies > chapter. In particular I think we need to fix the wording for > MPI_CART_SUB - maybe to better match the wording for mpi_comm_split.

1 0

[Mpi3-ft] FT WG Teleconference Wednesday @ Noon EDT
by Josh Hursey 08 Nov '11

08 Nov '11

Reminder that we have a teleconf tomorrow, Wednesday 11/9/2011, at Noon EDT. Date: November 9, 2011 Time: Noon EST/New York Dial-in information: 877-801-8130 Code: 1044056 Agenda: - MPI Forum Meeting debrief - Run-Through Stabilization Proposal https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/ft/rts_proposal_main - Other items? Additional Agenda Items [as time permits]: - Run-Through Stabilization Proposal https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/ft/run_through_stabilizat… https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/ft/run_through_stabilizat… - Process Recovery (Josh H.) https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/ft/process_recovery_2 - MPI Forum notes discussion (?) http://lists.mpi-forum.org/mpi3-ft/2011/07/0805.php - Error to Fault changes proposal (Darius B.) http://lists.mpi-forum.org/mpi3-ft/2011/06/0773.php - Piggybacking? (Martin S.) https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/Piggybacking - Network Channel Failure http://lists.mpi-forum.org/mpi3-ft/2011/06/0730.php - FT Query Interface http://lists.mpi-forum.org/mpi3-ft/2011/06/0737.php Next Meetings: * Nov. 30, 2011 (Teleconf) * Dec. 7, 2011 (Teleconf) * Dec. 14, 2011 (Teleconf) * Jan. 4, 2012 (Teleconf) * Jan. 9, 2012 (MPI Forum Meeting) Respond to the list if you have any additional topics that you would like to discuss. -- Josh -- Joshua Hursey Postdoctoral Research Associate Oak Ridge National Laboratory http://users.nccs.gov/~jjhursey

1 0