[Mpi3-ft] Topics for next telecon

Graham, Richard L. rlgraham at ornl.gov
Sun Jun 14 19:19:07 CDT 2009


All the information is on the web, under the mpi-3 ft working group. If you need a URL, I can send it to you later - don't have access now.

Rich

________________________________

From: mpi3-ft-bounces at lists.mpi-forum.org 
To: MPI 3.0 Fault Tolerance and Dynamic Process Control working Group 
Sent: Sun Jun 14 20:11:04 2009
Subject: Re: [Mpi3-ft] Topics for next telecon 


Hi, What is the telecon schedule and how does one get invited?
Thanks,
Tony



On Wed, Jun 10, 2009 at 11:54 PM, Martin Schulz <schulzm at llnl.gov> wrote:


	Hi all,


	At 06:00 PM 6/10/2009, Greg Bronevetsky wrote:
	

		For the next telecon I propose that we address the following topics.
		- The piggybacking proposal was considered by the FT group several months ago but then got lost in a limbo between the FT group and the tools group. We need to discuss this proposal and the issues behind it so that we can figure out how to make progress on it.
		


	I agree with Greg - it would be great if we could pick this up
	again and try to come up with a single, common proposal. There is
	interest in this from multiple WGs (which is probably part of
	the problem of why nobody has pushed this forward) and if the FT
	group could continue to "host" this, that would be great. It
	would also be good to cross-post the TelCon announcement to the
	tools and AM WGs (for the latter, Torsten has voiced interest).
	
	Thanks,
	
	Martin




		- During the face-to-face discussion we began talking about the desired error notification semantics for collectives. The question is: are MPI implementations allowed to provide no error notification as part of their collectives, relying on calls to MPI_Validate for this functionality or do we expect them to report all relevant errors. In particular, is MPI_Barrier responsible for reporting failures of any members of the communicator or is it allowed to mis-behave in the event of failures and for example, return successfully even if one process failed before calling MPI_Barrier? If so, how do we bound the limit of such mis-behaviors?
		
		Greg Bronevetsky
		Post-Doctoral Researcher
		Lawrence Livermore National Lab
		(925) 424-5756
		bronevetsky at llnl.gov
		http:// greg.bronevetsky.com
		_______________________________________________
		mpi3-ft mailing list
		mpi3-ft at lists.mpi-forum.org
		http:// lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft
		


	_______________________________________________________________________
	Martin Schulz, schulzm at llnl.gov, http://people.llnl.gov/schulz6
	CASC @ Lawrence Livermore National Laboratory, Livermore, USA  

	_______________________________________________
	mpi3-ft mailing list
	mpi3-ft at lists.mpi-forum.org
	http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft
	




-- 
Tony Skjellum, PhD
RunTime Computing Solutions, LLC
tony at runtimecomputing.com
direct: +1-205-314-3595
cell: +1-205-807-4968


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-ft/attachments/20090614/01671d6b/attachment-0001.html>


More information about the mpiwg-ft mailing list