Hi Bob and Chip,

We (MILC) have studied the most recent description of the Message
Passing API and had some questions, which I attach.  Given the
convergence of Columbia's and MILC'c priorities, I would propose we
start resolving these issues via e-mail, if possible, to speed things
up, but certainly try to make progress in this week's conference call.

Regards,
Carleton

----------------------------------------------------------------------
    Questions about the Message Passing API Version 0.7 (9 Aug 2001)
    http://www.jlab.org/~watson/lqcd/MessageAPI.htm

(1) The interface as described appears to be more primitive than even
    the few basic MPI calls we listed in the initial survey of desired
    capabilities.  Is this correct?  Have we moved away from the idea
    that we were going to supply at least these few MPI functions?
    Is this design also best for QCDOC?

    (a) In particular, in the the MPI_Irecv command, one specifies the
    source node as well as a message label.  In this way it is
    possible for messages of the same type from more than one source
    to arrive asynchronously, and be distinguished.  I do not see this
    capability in the Version 0.7 document.

    (b) If more than one message of a given type might arrive at a
    given node in a communication operation, it would be incorrect to
    assign it a specific buffer, lest a second arriving message
    clobber the first.  So the caller now has to sort through the FIFO
    to find the desired message.  With MPI_Recv, one specifies the
    message type and sending node, if desired, and the next message in
    the queue satisfying those criteria is automatically delivered.

(2) If efficiency demands an interface more primitive than MPI, then
    are we proposing to write an MPI implementation on top of this
    interface for code that runs under MPI?  Would there be any gains
    in performance expected over straight MPI in that case?  On QCDOC
    where MPI is not available, we would need an MPI implementation to
    be able to run MPI code at all.

(3) If efficiency requires such an interface, it will require more
    effort to port legacy MPI code to the interface.  This can be
    done, but it must be understood that there is a price to be paid.

(4) What does "declareLogicalTopology" do?  Do we need it?  Why not
    supply a variety of "generateTopology" procedures that can be
    plugged in, depending on the architecture, or which figure out how
    to lay out the lattice in the optimum way, based on responses to
    getMachine* calls and specified lattice dimensions?  I think it
    is smoother protocol to ask generateTopology to do the best it can
    (and give diagnostics if it doesn't look good), rather than to
    tell it what to do and get a possible "no, I can't" reply.
- ----------------------------------------------------------------------
_______________________________________________
QCDapi mailing list
QCDapi@physics.bu.edu
http://physics.bu.edu/mailman/listinfo/qcdapi
------- End of forwarded message -------