I vote for the attribute option. I don't know what using the MPI_T interface would add, but I guess we could do both. I don't like the explicit query function. -d On Mar 14, 2012, at 9:19 AM, Josh Hursey wrote:
During the MPI Forum meeting it was requested that the FT WG add the ability to query the implementation to determine if it supports the functionality described in the new proposal. Such a query interface would allow the user to determine whether they should use a code path including fault recovery techniques, or use an alternative path that does not include such error checking.
Note that both execution paths must be supported by the MPI implementation, but if the implementation will never return the error codes defined in that chapter (and makes 'MPI_Comm_shrink' a 'MPI_Comm_dup' and 'MPI_Comm_invalidate' a noop) then the user is doing extra work that is not necessary for that implementation. Further, if the implementation does not support the functionality, this would provide the user with an early sanity check and allow them to bail out before wasting time on the machine.
At bottom are a few suggestions for how to provide this functionality. This would be a ticket targeted at 3.1. It is not necessary functionality for the current set of tickets (e.g., 323), just a user convenience interface.
The MPI Predefined Attribute option sounds the best to me, though the MPI_T interface extension is interesting as well. What do others think?
-- Josh
MPI Defined Attribute: ---------------------- Section 8.1.2 of the MPI 2.2 standard defined a small set of attributes that are defined for MPI_COMM_WORLD to "describe the execution environment." We could add a new attribute: - MPI_SUPPORT_PROC_FAILURE : Boolean variable that indicates whether the implementation is able to provide support for the behavior specified in Chapter 17.
The MPI implementation would have to define this 'key' so users can portably query it. The 'value' should be set to 'true' if the functionality is support, and all other values indicate that the implementation does not support the functionality.
Explicit MPI Function(s): ------------------------- MPI_FT_QUERY(bool &supported); A general query interface to determine if the functionality in Chapter 17 is supported.
We could also explore a per-communication object interface to allow for future implementation flexibility (though it would be more difficult for the user to program against). MPI_COMM_FT_QUERY(MPI_Comm comm, bool &supported); MPI_WIN_FT_QUERY(...); MPI_FILE_FT_QUERY(...);
We could also have an an initialization function, similar to threads: MPI_INIT_FT(required, provided);
MPI_T interface: ---------------- Extend the interface, as appropriate and in coordination with the tools group, to allow the user to query the implementation to determine support for various error codes. This would possibly allow us to extend beyond the error codes defined in Chapter 17.
So that users can query for 'how well supported is MPI_ERR_X' or 'what is the state of the implementation after returning MPI_ERR_X'. For example, returning MPI_ERR_ARG is not critical in most implementation configurations (but in some it may be). So this would allow the user to ask the MPI implementation if it can continue using MPI after an error, or what it can do after the error is returned.
This thread might also be interesting to consider for this point: http://lists.mpi-forum.org/mpi3-ft/2011/06/0737.php
-- Joshua Hursey Postdoctoral Research Associate Oak Ridge National Laboratory http://users.nccs.gov/~jjhursey
_______________________________________________ mpi3-ft mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft