Minutes for the June 6-7, 2000 MPI/RT meeting hosted by Mercury Computer Systems, Inc. in Boston Dimitris Christodoulou SKY dimitris@skycomputers.com Dennis Cottel SSC-SD dennis@spawar.navy.mil Zhenqian Cui MSTI zcui@mpi-softtech.com Yogi Dandass MSU yogi@cs.msstate.edu Nathan Doss LMCO nathan.e.doss@lmco.com Arkady Kanevsky Mercury arkady@mc.com James Lebak MIT/Lincoln Lab jlebak@ll.mit.edu Tom Murphy UMAS Lowell Steve Paavola SKY paavola@skycomputers.com Michael Pepe Mercury mpepe@ms.com Anna Rounbehler arounbe@ieee.org Jeffrey Smith Mercury jesmith@ms.com 1. There was a discussion on how we can make MPI/RT more popular. There was general consensus that a public domain version was needed to demonstrate the API. However, no funding sources for this implementation exist as yet. 2. Dennis Cottel gave a status review of the Test Suite. a. The test suite has been executed using the Mercury and CSPI implementations b. Dennis is waiting for access to the SKY computer at Rome Lab c. Dennis will put a copy of the test suite on the MPI/RT web site so others may exercise the test suite independently. d. SKY Computers will use the publicly released test suite on their platform 3. Errors Proposal a. Arkady will post rephrased wording for paragraph on lines 23-25 on page 15. b. Function arguments are checked in a strictly left-to-right manner based on the LIS definition. This needs to be specifically stated for C implementations. In C++, the object whose member function is being called is checked first. c. Create a chapter/appendix to keep deprecated objects and constants. For example, MPIRT_ERR_COMMITTED_OBJECT is replaced by MPIRT_ERR_OBJECT_COMMITTED. d. The list of errors will continue to grow as the test suite uncovers additional error conditions. 4. Error string proposal a. The function should return a pointer to an error string. b. The production mode library can return any valid null terminated string (i.e., does not have to return a pointer to an error string, an empty null-terminated string is permitted). c. This proposal should be incorporated in the document as section 1.4.4 d. Straw vote to continue work on proposal: 8/1/0 5. Errata straw vote: 6/0/0 6. Sleep proposal a. Remove references to "thread" since a threaded model in not required by MPI/RT. b. Replace the reference to MPIRT_TIME_INFINITE with MPIRT_TIMESPEC_IGNORE. c. Remove MPIRT_TIME_INFINITE from the end-of-chapter summaries paragraph. d. Straw vote to continue work on proposal: 6/0/0 7. Receptor wait a. Minor wording changes. b. Straw vote to continue work on proposal: 6/0/0 8. Bufiter get status proposal a. MPIRT_BUFITER_GET_STATUS changed to MPIRT_BUFITER_RETRIEVE_BUFFERS b. Clarify what the function returns when this function is called before commit, after uncommit, and during the real-time (committed) mode of the MPI/RT application. c. The last parameter (vcontainer) of the function is an INOUT parameter. d. The size of the vcontainer is not increased to the bufiter size. If the number of buffers in the bufiter is greater than the capacity of the vcontainer, the function returns error MPIRT_ERR_INV_RANGE e. Straw vote to continue work on proposal: 6/0/0 9. MPIRT_INT64_EXPORT32 function proposal a. The C++ binding has an error. The first parameter should have type const MPIRT::Int64, not MPIRT_Int64. b. Remove advice to users. c. Formal vote: 5/0/0 10. Container operations proposal a. The container parameter for all operations in the proposal should be IN only (not INOUT). b. The container must only contain objects that can be started. If the container parameter is not a valid container the function returns MPIRT_ERR_INV_CONTAINER. All other error returns are those raised by the channel activation function. c. The flatten function removes duplicates without raising errors. d. The flatten function takes a parameter of type MPIRT_TRAVERSAL_ORDER that specifies the traversal order of nested input containers. The values of this parameter can be MPIRT_TRAVERSE_BREADTH, MPIRT_TRAVERSE_DEPTH, and MPIRT_TRAVERSE_INORDER. e. The traversal order determines the relative position of the objects in the resulting container. f. MPIRT_CONTAINER_FLATTEN becomes MPIRT_name-of-container-class_FLATTEN. g. The container operations, except for filter, are not applicable to Groups h. Remove the MPIRT_ERR_DUPLICATE_MEMBER error. Make this condition the subject of an "advise to users" paragraph. i. Put a reference to the activate and deactivate functions in the container chapter with the container operations. j. Straw vote to continue work on proposal: 7/0/0 11. Container iterator proposal a. Change the wording of the paragraph that states that iterators are derived from MPIRT_OBJECT to be consistent with the other objects in the document. b. Correct the C/C++ bindings for all functions. c. Put the GET operations before the SET operations. d. In the SET_CONTAINER operation, replace the last two sentences to "This operation resets the container iterator." e. Clarify the meaning of "invalidate." f. The last paragraph before the code example, remove the text "(e.g., during a real-time phase of processing). g. List the meta-classes (list on page 21) over which container iterators are defined. h. Add container interators to the object hierarchy diagram (under probe). i. Consider adding a small introduction to container iterators in Chapter 1. j. Deprecate old retrieve-next container operations (add to the Deprecated appendix). k. Straw vote to continue work on proposal: 7/0/0 12. All-to-all collective (non-bipartite) channel proposal a. It was decided to require that the buffers be evenly divisible by the number of participating processes. b. An error is returned (MPIRT_ERR_ILLEGAL_BUFITER) when the channel is created and also when the channel is committed if the buffer size is not divisible by the cardinality of the group. c. Add a paragraph after the channel creation binding stating that parameter consistency checks are performed at channel creation and commit time. d. Straw vote to continue work on proposal: 7/0/0 13. Bipartitie all-to-all channel proposal a. Add "bipartite" to glossary b. The sentence "The order of dividing a send message into smaller messages..." needs to be clarified. c. A diagram explaining the data transfer is needed. d. The two participating groups must be disjoint. e. Add the function bindings. f. The condition naming convention for these channels is: object_name:group_name:rank:cond_name g. Straw vote to continue work on proposal: 5/0/2 14. Strided buffer proposal a. Reword rationale to clarify and correct. b. Need a diagram to describe how strided buffers can be subdivided. There are several cases. Provide examples. c. Ensure that strided buffers work for all channel types (e.g., reduce, scatter, etc.). d. No existing calls will change, the proposal extends the buffer object. It does not introduce a new object. e. Straw vote to continue work on proposal: 5/1/2