Hi Martin, Hi group, its great to see the first versions of a proposal, I went over it and tried to find issues and errors. As I am unfortunately only rarely able to join the telco, I may raise issues that had already been discussed, if so feel free to ignore these comments. p7, line 3: "Fortran bindings are not required." -> One might give a rational for that, which is I guess that this targets tools that are usually not written in Fortran. p7, line 35: Uses "MPIT_Init" to refer to "MPIT_INIT" (consistency change) (also in line 41) p8, line 4-6: "Once this routine is called no MPIT routine ... may be called ...." -> I would add an except MPIT_INITIALIZED and MPIT_FINALIZED p9: general comment to MPIT_Datatype: A MPIT_DATATYPE_NULL might make the design more consistent to the regular MPI_Datatype design ... p9, line 32: "MPI_MAX_ENUMTYPE" -> "MPIT_MAX_ENUMTYPE" p11, line 18/19: IN iterator -> INOUT iterator p11 general comment to names: "MPIT_CONFIG_QUERY" and "MPI_Configquery_iterator" seem not very consistent p11 general comment on iterators: * Is there a strong need to use distinct iterator types for the config query and the performance query, couldn't we use a MPIT_Iterator type instead ? * MPIT_CONFIG_QUERY and MPIT_PERFORMANCE_QUERY might also set the iterator to MPIT_[ITERATOR|CONFIGQUERY|PERFORMANCEQUERY]_END when the call returns an MPIT_END (for consistency with common iterator concepts) p12, line 8: "MPIT_CONFIG_INFO(name, type, ...)" -> "MPIT_CONFIG_INFO(name, datatype, count, ...)" p12 comments on "MPIT_CONFIG_INFO": * Strictly seen, when the user may set desc to NULL, I would define desc as INOUT * What is the value of desclen when the user sets desc to NULL ? p13, line 33: "...the appropriate sized and ..." -> "...the appropriate size and ..." p16, line 18: "IN set string to a set" -> "string to a set" is not very descriptive, what about "string identifier of a set" or something similar ? p16, line 35: "that explains in the use ..." -> "that explains the use ..." p16, line 38: "name and description, are ..." -> "<b>name</b> and <b>desc</b>, are ..." p16, line 39: "A conforming MPI implementation may not ... " -> "A conforming MPI implementation must not ... " p16, line 41: "MPIT_PERFORMANCE_QUERY may ..." -> "MPIT_GET_SETINFO may ..." (same in line 46!) p16, line 44: "MPI_MAX_SET_NAME" -> "MPIT_MAX_SET_NAME" p16, general comment about MPIT_GET_SETINFO: * Strictly seen, when the user may set desc to NULL, I would define desc as INOUT (Same holds for further calls, I stopped listing all of them) p17, line 2: "MPI_MAX_SET_DESC" -> "MPIT_MAX_SET_DESC" p17, line 15: IN iterator iterator .... -> INOUT .... p17 comment about naming: "MPIT_PERFORMANCE_QUERY" vs "MPIT_Performancequery_iterator" p17, line 43: "The parameter name is used to return a short and unique name for the performance variable found." -> "The parameter name is used to return a short and unique name for the performance variable found, which is used as its identifier in other calls to the MPIT performance interface." p17, line 44: "A conforming MPI implementation may not..." -> "A conforming MPI implementation must not ..." p18, line 4: "MPI_MAX_PERFORMANCEVAR_NAME" -> "MPIT_MAX_PERFORMANCEVAR_NAME" p18, line 47: "MPI_MAX_PERFORMANCEVAR_DESC" -> "MPIT_MAX_PERFORMANCEVAR_DESC" p19, line 10: "MPI_MAX_PERFORMANCEVAR_SETS(???)" -> "MPIT_MAX_PERFORMANCEVAR_SETS(???)" p19, general comment to naming of MPIT Performance interface calls: * binding names like "MPIT_Performance_changed ()" seem to suggest a totally different behavior than they actually implement, in fact the MPIT_Performance is meant as a sort of namespace here why not use MPIT_PERFORMANCE_Changed to denote that, or if this is inconsistent with the rest of the standard (which apparently is the case), then why not use an extra word here, e.g. MPIT_Performance_vars_changed. p19, comment to MPIT_Performancehandle: * none of the other MPI handles use "handle" as part of their name, so what about "MPIT_Performance[_]var" ? * what about a MPIT_PERFORMANCE[HANDLE/VAR]_NULL for consistency with the other MPI handles ? * One might add that the user of the MPIT interface should free all performance handles before calling MPIT_FINALIZE * MPIT_PERFORMANCE_ALL is inconsistent with other constant handles (that use the handle name as their base name. e.g. MPI_Comm -> MPI_COMM_WORLD), what about MPIT_PERFORMANCE[HANDLE|VAR]_ALL p21, line 33: "MPIT_ERR_PERFORANCE_WRITE" -> "MPIT_PERFORMANCE_WRITE" -Tobias Martin Schulz wrote:

Hi all,

I uploaded a new draft of the MPIT proposal to

https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI3Tools/draft

Changes since the last draft are marked with changebars and are colored in green. The latest draft contains changes based on comments from Kathryn Mohror and the MPI group at Sun/Oracle.

There is one open question that I would like to bring up for a general discussion: as discussed in the WG earlier, we need some kind of verbosity parameter that allows the MPI implementation to classify each variable according to its importance and general usage scenario. Jeff and I have been going forth and back on this one for a while over email, but we can't come to a useful conclusion and hence would like wider feedback.

In general, we both think that we want 5 classes of verbosity (odd number larger than 3, but not too large).

The original proposal had the following classes VERY_HIGH HIGH MEDIUM LOW VERY_LOW which was rejected by the forum (I think rightfully so) since it doesn't really convey any useful application level information.

The current proposal has: USER_BASIC USER_DETAILED TUNER_BASIC TUNER_DETAILED MPI_IMPLEMENTOR with the idea that the first two classes are intended for general MPI users, the third and fourth for performance experts and system administrators wishing to tune the performance of MPI itself, while the fifth is for MPI implementors and would include debugging information.

Open MPI uses a similar idea of verbosity and defines the following five classes: INFORMATION TRIVIAL MINOR MAJOR CRITICAL However, both Jeff and I don't like these classes, since they don't convey any useful information either.

Jeff proposes something like BASIC ? ADVANCED ? INTERNAL but this proposal misses good names for 2 and 4.

Any comments or suggestions (either extending one of the above or completely new) would be very much appreciated.

Thanks,

Martin

________________________________________________________________________ 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

-- Tobias Hilbrich GWT - TUD GmbH Chemnitzer Stra�e 48b 01187 Dresden Tel.: +49 351 463 35876 Fax: +49 351 463 37773 http://www.gwtonline.de Gesch�ftsf�hrer: Claus-Peter Held Prokuristin: Beate-Victoria Ermisch Die GWT ist eingetragen beim Amtsgericht Dresden - HRB: 13 840