[dropping mpi-forum@ to discuss the proposal] I've implemented a rough set of stubs for the MPIT interface in MPICH2 as "MPITX_*". I'm sure they'll undergo numerous changes before we actually get something that goes into the public version of MPICH2. However, now that I have them I tried to actually implement some of the simpler functionality, namely the control variable portion of the interface. Unfortunately I've run into some trouble while doing this. In particular, the datatype functionality doesn't quite match up with the way that you want to use the interface. For example, in MPICH2 we have four different types of controlvars (which we call parameters or params internally): integers, doubles, booleans, and strings. The first two are clearly handled by MPIT_INT and MPIT_DOUBLE. But the latter two present some problems. The MPIT interface doesn't provide a boolean, and it's not obvious what the ideal choice is as a substitute. MPIT_LOGICAL is specified by the current draft, but MPI_LOGICAL corresponds to *Fortran* LOGICAL, not any C type. We could add MPIT_C_BOOL corresponding to MPI_C_BOOL and C's _Bool type, but that effectively mandates partial C99 support. Really we want a type that means "pass an int here and it will be used for boolean values". Maybe call it MPIT_BOOLEAN? Strings are also slightly problematic. What's the right type here, MPIT_CHAR with a count greater than 1? That's awkward, since it basically mandates that the library use a fixed size buffer for any string controlvars. Why shouldn't the library be able to take a string argument and strdup() it? We would no longer mirror the MPI_Datatype types exactly, but IMO an MPIT_STRING would be a helpful addition. I think that this also further underscores the need for some example programs to help us with the API. -Dave On Jan 27, 2011, at 7:07 PM CST, Martin Schulz wrote:

Hi all,

As probably many of you know, the MPI-3 WG on tools has been (and is) working on an extension to MPI that allows tools (as well as adaptive runtime systems or applications) access to MPI internals. We have named this interface MPIT.

The WG has converged on a draft for MPIT that we plan to introduce into the MPI forum process for inclusion into MPI-3. Following the new rules for MPI-3 standardization, I will be presenting this draft at the next MPI forum meeting on Tuesday afternoon.

To help this discussion, the current version is attached to this email. As part of this proposal, we also propose to create an overarching chapter on tools, which includes both the existing (unmodified) PMPI interface and the new MPIT specification. This is reflected in the attached draft document.

I will upload it to the Tools WG Wiki as well as the MPI SVN at the following URL (once the I can get back onto the servers, which seem to be down at the moment):

https://svn.mpi-forum.org/svn/mpi-forum-docs/trunk/working-groups/mpi-3/tool...

Let me know if you have any questions or comments ahead of the presentation!

Thanks,

Martin

<mpi-report.pdf>

________________________________________________________________________ Martin Schulz, [email protected], http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

_______________________________________________ Mpi3-tools mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools