Thanks, John. I've read through it quickly and I have a few comments. Page 3: What are the units of the value in MPIR_proctablesize? (bytes, elements, ints, ...) Page 3: An MPIR_Event is introduced. Is this the definition of an MPIR_Event? It might be best to have a separate definition first. Page 4ff: MPICH 1 should probably be written as MPICH-1 or MPICH1 or just MPICH (the MPICH<space>1 is awkward). Page 5ff: mpirun vs mpiexec . Its true that mpirun is the most common name, but mpiexec has been the preferred and *official, standard sanctioned* name for over 12 (!) years. I'd like the document to recognize that mpiexec is the correct name for the program that may be used to start MPI programs, and mention that mpirun is non- standard, but historical and still widely used, name. Page 8, Table 1: Thank you! (I haven't gone through it in detail, but this is a great thing to have) Page 11, first line: "is specified a set" should be either "specified a set" or "is specified as a set". Page 11, definition of VOLATILE. I'm concerned about this. First, it requires that VOLATILE be defined as empty if __STDC__ and __cplusplus are not defined - shouldn't volatile be allowed if supported? More seriously, if volatile is not supported, can the interface work? If so, then why include VOLATILE? Page 11, MPIR_PROCDESC description. Is the pid an int (unknown size) or an int of a specific size? The text suggests that it is an int of an unspecified size (the tool must determine). May be worth a reminder to implementors, particularly on systems where ints may be different sizes depending on compilation options. Page 12ff: const, volatile, and the declarations. I think we should look over the declarations carefully to see whether they should include const and/or volatile . For example, MPIR_debug_state is declared without volatile - shouldn't volatile be used for any variable that (a) may be changed and (b) read by another agent (such as the debug tool)? There's also one array declaration that uses "char MPIR_dll_name[];"; the others all use pointers ("char *MPIR_debug_abort_string") (not counting the ones that allocate storage, e.g., char MPIR_executable_path[256]), which itself seems dangerously small. All in all, an excellent and valuable start. Thanks, John! Bill On Feb 27, 2010, at 11:39 AM, John DelSignore wrote:

Hi all,

Attached is DRAFT copy of a document in PDF format that contains a description of the MPIR Process Acquisition Interface. I think it's still pretty raw and there's more information and clarification needed, but it is fairly complete and should serve as solid foundation material for a more formal interface description that could be incorporated into the standard. I can be prepared to discuss this paper during the March 2010 meeting, if the MPI-3 Tools Workgroup deems it appropriate.

Note that to date, I have made no effort to more formally document the MPIR Message Queue Display Interface. I inserted a placeholder at the end of the attached document as a reminder that this is a TO- DO item.

Cheers, John D. <MPIR Process Acquisition Interface.pdf><ATT00001..txt>

William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign