MPI, mpi - LAM MPI implementation

DESCRIPTION

       LAM  features  a  full  implementation  of Message-Passing
       Interface, with the exception that the MPI_CANCEL function
       will  not  properly  cancel  messages that have been sent.
       Pending receive requests can be  canceled;  implementation
       of  canceling send messages was judged to be too difficult
       (and not enough LAM users asked for it).

       Compliant applications are source  code  portable  between
       LAM  and  any other implementation of MPI.  In addition to
       meeting the standard in a high quality manner, LAM  offers
       extensive  monitoring  capabilities  to support debugging.
       Monitoring happens on two levels.  LAM has  the  hooks  to
       allow a snapshot of process and message status to be taken
       at  any  time  during  an  application  run.   The  status
       includes  all aspects of synchronization plus datatype map
       / signature, communicator  group  membership  and  message
       contents.  On the second level, the MPI library is instru
       mented to produce a cumulative  record  of  communication,
       which  can be visualized either at runtime or post-mortem.

       Another strength of this MPI implementation is  the  move
       ment  of  non-blocking  communication  requests, including
       those that result from buffered sends.  This is  the  real
       challenge of implementing MPI; everything else is mostly a
       straight forward wrapping of an  underlying  communication
       mechanism.   LAM  allows  messages  to  be buffered on the
       source end in any state  of  progression,  including  par
       tially  transmitted  packets.   This  capability  leads to
       great portability and robustness.

   Up-to-Date Information
       The LAM home page can be found on the World Wide  Web  at:
       http://www.mpi.nd.edu/lam/  .   It should be consulted for
       the  most  current  information  about  LAM,  as  well  as
       updates, patches, etc.

   Direct MPI Communication
       The sophisticated message advancing engine at the heart of
       the MPI library uses only a handful of routines  to  drive
       the underlying communication system.  Runtime flags decide
       which implementation of these low-level routines is  used,
       so  recompilation is not necessary.  The default implemen
       tation  uses  LAM's  network  message-passing   subsystem,
       including its buffer daemon.  In this "daemon" mode, LAM's
       extensive monitoring features are  fully  available.   The
       main purpose of daemon based communication is development,
       but depending on the application's decomposition granular
       ity and communication requirement, it may also be entirely
       adequate for production execution.
       communication  intends  to  use  the  highest  performance
       underlying mechanism, certainly bypassing the  LAM  daemon
       and  connecting  directly  between  application processes.
       This is the "client to client" mode (C2C).

       The availability of optimal C2C implementations will  con
       tinue  to  change  as  architectures  come and go.  At the
       least, LAM includes a combination TCP/IP and shared memory
       implementation of C2C that bypasses the LAM daemon.

       MPI process and message monitoring commands and tools will
       be much less effective in C2C mode, usually reporting run
       ning  processes and empty message queues.  Signal delivery
       with doom(1) is unaffected.

   Guaranteed Envelope Resources
       Applications may fail, legitimately, on  some  implementa
       tions  but  not  others  due to an escape hatch in the MPI
       Standard called "resource  limitations".   Most  resources
       are  managed  locally and it is easy for an implementation
       to provide a helpful error  code  and/or  message  when  a
       resource is exhausted.  Buffer space for message envelopes
       is often a remote resource (as in LAM) which is  difficult
       to  manage.   An  overflow may not be reported (as in some
       other implementations) to  the  process  that  caused  the
       overflow.   Moreover,  interpretation of the MPI guarantee
       on message progress may confuse the debugging of an appli
       cation that actually died on envelope overflow.

       LAM  has a property called "Guaranteed Envelope Resources"
       (GER) which serves two purposes.  It is a promise from the
       implementation to the application that a minimum amount of
       envelope buffering will be available to each process pair.
       Secondly,  it  ensures  that the producer of messages that
       overflows this resource will be throttled or cited with an
       error as necessary.

       A  minimum  GER  is configured when LAM is built.  The MPI
       library uses a protocol to ensure GER when running in dae
       mon  mode.   The  default C2C mode (TCP/IP) does not use a
       protocol, because process-pair protection is  provided  by
       TCP/IP  itself.  Errors are only reported to the receiving
       process in C2C mode.  An option to mpirun(1) disables GER.

   Input and Output
       The MPI standard does not specify standard I/O functional
       ity.  LAM does not interfere with the I/O capabilities  of
       the  underlying system but it does make special provisions
       for remote terminal I/O  using  the  ANSI/POSIX  routines.
       See mpirun(1) and tstdio(3).

       LAM  now  includes  the  ROMIO distribution for MPI-2 file
       provided.

       ROMIO  has  some  important  limitations  under  LAM;  the
       RELEASE_NOTES  file in the LAM distribution should be con
       sulted before writing MPI programs that use MPI I/O.

   Dynamic Processes
       LAM includes an implementation of  MPI-2  dynamic  process
       creation.  The non-blocking functions are not implemented.

LAM Extensions to MPI

   Debugging Aids
       Opaque MPI objects are monitored by LAM commands  but  the
       user  needs  a  way  to cross-reference the identification
       given by the commands with variables within  MPI  applica
       tion.   These extensions extract identifiers from MPI com
       municators  and  datatypes.    See   MPIL_Comm_id(2)   and
       MPIL_Type_id(2).

       Additionally,  LAM  provides the capability to launch non-
       MPI  programs  on  remote  nodes.   This  includes   shell
       scripts,  debuggers,  etc.   As  long as an MPI program is
       eventually launched (as a child,  grandchild,  etc.),  LAM
       can handle executing as many intermediate programs as nec
       essary.  This can greatly help debugging  and  logging  of
       user programs.

   Trace Generation
       To avoid being swamped with trace data from a long running
       application, LAM supplies collective  operations  to  turn
       the   tap   on   and   off.    See   MPIL_Trace_on(2)  and
       MPIL_Trace_off(2).

   Asynchronous Signals
       LAM has an signal handling package which mirrors but  does
       not  interfere  with POSIX signal handling.  An MPI exten
       sion  routine  delivers  a  signal  to  a  process.    See
       MPIL_Signal(2).

MPI, mpi - LAM MPI implementation

DESCRIPTION

LAM Extensions to MPI

SEE ALSO