search

hpc / ompi

Open MPI main development repository
Other
1 stars 2 forks source link

readme

Open MPI

The Open MPI Project is an open source Message Passing Interface (MPI) implementation that is developed and maintained by a consortium of academic, research, and industry partners. Open MPI is therefore able to combine the expertise, technologies, and resources from all across the High Performance Computing community in order to build the best MPI library available. Open MPI offers advantages for system and software vendors, application developers and computer science researchers.

See the MPI Forum web site for information about the MPI API specification.

Quick start

In many cases, Open MPI can be built and installed by simply indicating the installation directory on the command line:

$ tar xf openmpi-<version>.tar.bz2
$ cd openmpi-<version>
$ ./configure --prefix=<path> |& tee config.out
...lots of output...
$ make -j 8 |& tee make.out
...lots of output...
$ make install |& tee install.out
...lots of output...

Note that there are many, many configuration options to the ./configure step. Some of them may be needed for your particular environmnet; see below for desciptions of the options available.

If your installation prefix path is not writable by a regular user, you may need to use sudo or su to run the make install step. For example:

$ sudo make install |& tee install.out
[sudo] password for jsquyres: <enter your password here>
...lots of output...

Finally, note that VPATH builds are fully supported. For example:

$ tar xf openmpi-<version>.tar.bz2
$ cd openmpi-<version>
$ mkdir build
$ cd build
$ ../configure --prefix=<path> |& tee config.out
...etc.

Table of contents

The rest of this file contains:

Also, note that much, much more information is also available in the Open MPI FAQ.

General notes

The following abbreviated list of release notes applies to this code base as of this writing (April 2020):

Platform Notes

Compiler Notes

General Run-Time Support Notes

MPI Functionality and Features

OpenSHMEM Functionality and Features

All OpenSHMEM-1.3 functionality is supported.

MPI Collectives

OpenSHMEM Collectives

Network Support

Open MPI Extensions

An MPI "extensions" framework is included in Open MPI, but is not enabled by default. See the "Open MPI API Extensions" section below for more information on compiling and using MPI extensions.

The following extensions are included in this version of Open MPI:

  1. pcollreq: Provides routines for persistent collective communication operations and persistent neighborhood collective communication operations, which are planned to be included in MPI-4.0. The function names are prefixed with MPIX_ instead of MPI_, like MPIX_Barrier_init, because they are not standardized yet. Future versions of Open MPI will switch to the MPI_ prefix once the MPI Standard which includes this feature is published. See their man page for more details.
  2. shortfloat: Provides MPI datatypes MPIX_C_FLOAT16, MPIX_SHORT_FLOAT, MPIX_SHORT_FLOAT, and MPIX_CXX_SHORT_FLOAT_COMPLEX if corresponding language types are available. See ompi/mpiext/shortfloat/README.txt for details.
  3. affinity: Provides the OMPI_Affinity_str() API, which returns a string indicating the resources which a process is bound. For more details, see its man page.
  4. cuda: When the library is compiled with CUDA-aware support, it provides two things. First, a macro MPIX_CUDA_AWARE_SUPPORT. Secondly, the function MPIX_Query_cuda_support() that can be used to query for support.
  5. example: A non-functional extension; its only purpose is to provide an example for how to create other extensions.

Building Open MPI

If you have checked out a developer's copy of Open MPI (i.e., you cloned from Git), you really need to read the HACKING file before attempting to build Open MPI. Really.

If you have downloaded a tarball, then things are much simpler. Open MPI uses a traditional configure script paired with make to build. Typical installs can be of the pattern:

shell$ ./configure [...options...]
shell$ make [-j N] all install
      (use an integer value of N for parallel builds)

There are many available configure options (see ./configure --help for a full list); a summary of the more commonly used ones is included below.

NOTE: if you are building Open MPI on a network filesystem, the machine you on which you are building must be time-synchronized with the file server. Specifically: Open MPI's build system requires accurate filesystem timestamps. If your make output includes warning about timestamps in the future or runs GNU Automake, Autoconf, and/or Libtool, this is not normal, and you may have an invalid build. Ensure that the time on your build machine is synchronized with the time on your file server, or build on a local filesystem. Then remove the Open MPI source directory and start over (e.g., by re-extracting the Open MPI tarball).

Note that for many of Open MPI's --with-FOO options, Open MPI will, by default, search for header files and/or libraries for FOO. If the relevant files are found, Open MPI will built support for FOO; if they are not found, Open MPI will skip building support for FOO. However, if you specify --with-FOO on the configure command line and Open MPI is unable to find relevant support for FOO, configure will assume that it was unable to provide a feature that was specifically requested and will abort so that a human can resolve out the issue.

Additionally, if a search directory is specified in the form --with-FOO=DIR, Open MPI will:

  1. Search for FOO's header files in DIR/include.
  2. Search for FOO's library files:
    1. If --with-FOO-libdir=<libdir> was specified, search in <libdir>.
    2. Otherwise, search in DIR/lib, and if they are not found there, search again in DIR/lib64.
  3. If both the relevant header files and libraries are found:
    1. Open MPI will build support for FOO.
    2. If the root path where the FOO libraries are found is neither /usr nor /usr/local, Open MPI will compile itself with RPATH flags pointing to the directory where FOO's libraries are located. Open MPI does not RPATH /usr/lib[64] and /usr/local/lib[64] because many systems already search these directories for run-time libraries by default; adding RPATH for them could have unintended consequences for the search path ordering.

Installation Options

Networking support / options

Run-time system support

Miscellaneous support libraries

MPI Functionality

OpenSHMEM Functionality

Miscellaneous Functionality

There are many other options available -- see ./configure --help.

Changing the compilers that Open MPI uses to build itself uses the standard Autoconf mechanism of setting special environment variables either before invoking configure or on the configure command line. The following environment variables are recognized by configure:

For example:

shell$ ./configure CC=mycc CXX=myc++ FC=myfortran ...

NOTE: We generally suggest using the above command line form for setting different compilers (vs. setting environment variables and then invoking ./configure). The above form will save all variables and values in the config.log file, which makes post-mortem analysis easier if problems occur.

Note that if you intend to compile Open MPI with a make other than the default one in your PATH, then you must either set the $MAKE environment variable before invoking Open MPI's configure script, or pass MAKE=your_make_prog to configure. For example:

shell$ ./configure MAKE=/path/to/my/make ...

This could be the case, for instance, if you have a shell alias for make, or you always type gmake out of habit. Failure to tell configure which non-default make you will use to compile Open MPI can result in undefined behavior (meaning: don't do that).

Note that you may also want to ensure that the value of LD_LIBRARY_PATH is set appropriately (or not at all) for your build (or whatever environment variable is relevant for your operating system). For example, some users have been tripped up by setting to use a non-default Fortran compiler via the FC environment variable, but then failing to set LD_LIBRARY_PATH to include the directory containing that non-default Fortran compiler's support libraries. This causes Open MPI's configure script to fail when it tries to compile / link / run simple Fortran programs.

It is required that the compilers specified be compile and link compatible, meaning that object files created by one compiler must be able to be linked with object files from the other compilers and produce correctly functioning executables.

Open MPI supports all the make targets that are provided by GNU Automake, such as:

Once Open MPI has been built and installed, it is safe to run make clean and/or remove the entire build tree.

VPATH and parallel builds are fully supported.

Generally speaking, the only thing that users need to do to use Open MPI is ensure that PREFIX/bin is in their PATH and PREFIX/lib is in their LD_LIBRARY_PATH. Users may need to ensure to set the PATH and LD_LIBRARY_PATH in their shell setup files (e.g., .bashrc, .cshrc) so that non-interactive rsh/ssh-based logins will be able to find the Open MPI executables.

Open MPI Version Numbers and Binary Compatibility

Open MPI has two sets of version numbers that are likely of interest to end users / system administrator:

  1. Software version number
  2. Shared library version numbers

Both are predicated on Open MPI's definition of "backwards compatibility."

NOTE: The version numbering conventions were changed with the release of v1.10.0. Most notably, Open MPI no longer uses an "odd/even" release schedule to indicate feature development vs. stable releases. See the README in releases prior to v1.10.0 for more information (e.g., https://github.com/open-mpi/ompi/blob/v1.8/README#L1392-L1475).

Backwards Compatibility

Open MPI version Y is backwards compatible with Open MPI version X (where Y>X) if users can:

Note that this definition encompasses several things:

However, this definition only applies when the same version of Open MPI is used with all instances of the runtime and MPI / OpenSHMEM processes in a single MPI job. If the versions are not exactly the same everywhere, Open MPI is not guaranteed to work properly in any scenario.

Backwards compatibility tends to work best when user applications are dynamically linked to one version of the Open MPI / OSHMEM libraries, and can be updated at run time to link to a new version of the Open MPI / OSHMEM libraries.

For example, if an MPI / OSHMEM application links statically against the libraries from Open MPI vX, then attempting to launch that application with mpirun / oshrun from Open MPI vY is not guaranteed to work (because it is mixing vX and vY of Open MPI in a single job).

Similarly, if using a container technology that internally bundles all the libraries from Open MPI vX, attempting to launch that container with mpirun / oshrun from Open MPI vY is not guaranteed to work.

Software Version Number

Official Open MPI releases use the common "A.B.C" version identifier format. Each of the three numbers has a specific meaning:

The "A.B.C" version number may optionally be followed by a Quantifier:

Nightly development snapshot tarballs use a different version number scheme; they contain three distinct values:

For example, a snapshot tarball filename of openmpi-v2.x-201703070235-e4798fb.tar.gz indicates that this tarball was created from the v2.x branch, on March 7, 2017, at 2:35am GMT, from git hash e4798fb.

Shared Library Version Number

The GNU Libtool official documentation details how the versioning scheme works. The quick version is that the shared library versions are a triple of integers: (current,revision,age), or c:r:a. This triple is not related to the Open MPI software version number. There are six simple rules for updating the values (taken almost verbatim from the Libtool docs):

  1. Start with version information of 0:0:0 for each shared library.
  2. Update the version information only immediately before a public release of your software. More frequent updates are unnecessary, and only guarantee that the current interface number gets larger faster.
  3. If the library source code has changed at all since the last update, then increment revision (c:r:a becomes c:r+1:a).
  4. If any interfaces have been added, removed, or changed since the last update, increment current, and set revision to 0.
  5. If any interfaces have been added since the last public release, then increment age.
  6. If any interfaces have been removed since the last public release, then set age to 0.

Here's how we apply those rules specifically to Open MPI:

  1. The above rules do not apply to MCA components (a.k.a. "plugins"); MCA component .so versions stay unspecified.
  2. The above rules apply exactly as written to the following libraries starting with Open MPI version v1.5 (prior to v1.5, libopen-pal and libopen-rte were still at 0:0:0 for reasons discussed in bug ticket #2092 https://svn.open-mpi.org/trac/ompi/ticket/2092):
    • libopen-rte
    • libopen-pal
    • libmca_common_*
  3. The following libraries use a slightly modified version of the above rules: rules 4, 5, and 6 only apply to the official MPI and OpenSHMEM interfaces (functions, global variables). The rationale for this decision is that the vast majority of our users only care about the official/public MPI/OpenSHMEM interfaces; we therefore want the .so version number to reflect only changes to the official MPI/OpenSHMEM APIs. Put simply: non-MPI/OpenSHMEM API / internal changes to the MPI-application-facing libraries are irrelevant to pure MPI/OpenSHMEM applications.
    • libmpi
    • libmpi_mpifh
    • libmpi_usempi_tkr
    • libmpi_usempi_ignore_tkr
    • libmpi_usempif08
    • libmpi_cxx
    • libmpi_java
    • liboshmem

Checking Your Open MPI Installation

The ompi_info command can be used to check the status of your Open MPI installation (located in PREFIX/bin/ompi_info). Running it with no arguments provides a summary of information about your Open MPI installation.

Note that the ompi_info command is extremely helpful in determining which components are installed as well as listing all the run-time settable parameters that are available in each component (as well as their default values).

The following options may be helpful:

Changing the values of these parameters is explained in the "The Modular Component Architecture (MCA)" section, below.

When verifying a new Open MPI installation, we recommend running six tests:

  1. Use mpirun to launch a non-MPI program (e.g., hostname or uptime) across multiple nodes.
  2. Use mpirun to launch a trivial MPI program that does no MPI communication (e.g., the hello_c program in the examples/ directory in the Open MPI distribution).
  3. Use mpirun to launch a trivial MPI program that sends and receives a few MPI messages (e.g., the ring_c program in the examples/ directory in the Open MPI distribution).
  4. Use oshrun to launch a non-OpenSHMEM program across multiple nodes.
  5. Use oshrun to launch a trivial MPI program that does no OpenSHMEM communication (e.g., hello_shmem.c program in the examples/ directory in the Open MPI distribution.)
  6. Use oshrun to launch a trivial OpenSHMEM program that puts and gets a few messages (e.g., the ring_shmem.c in the examples/ directory in the Open MPI distribution.)

If you can run all six of these tests successfully, that is a good indication that Open MPI built and installed properly.

Open MPI API Extensions

Open MPI contains a framework for extending the MPI API that is available to applications. Each extension is usually a standalone set of functionality that is distinct from other extensions (similar to how Open MPI's plugins are usually unrelated to each other). These extensions provide new functions and/or constants that are available to MPI applications.

WARNING: These extensions are neither standard nor portable to other MPI implementations!

Compiling the extensions

Open MPI extensions are all enabled by default; they can be disabled via the --disable-mpi-ext command line switch.

Since extensions are meant to be used by advanced users only, this file does not document which extensions are available or what they do. Look in the ompi/mpiext/ directory to see the extensions; each subdirectory of that directory contains an extension. Each has a README file that describes what it does.

Using the extensions

To reinforce the fact that these extensions are non-standard, you must include a separate header file after <mpi.h> to obtain the function prototypes, constant declarations, etc. For example:

#include <mpi.h>
#if defined(OPEN_MPI) && OPEN_MPI
#include <mpi-ext.h>
#endif

int main() {
    MPI_Init(NULL, NULL);

#if defined(OPEN_MPI) && OPEN_MPI
    {
        char ompi_bound[OMPI_AFFINITY_STRING_MAX];
        char current_binding[OMPI_AFFINITY_STRING_MAX];
        char exists[OMPI_AFFINITY_STRING_MAX];
        OMPI_Affinity_str(OMPI_AFFINITY_LAYOUT_FMT, ompi_bound,
                          current_bindings, exists);
    }
#endif
    MPI_Finalize();
    return 0;
}

Notice that the Open MPI-specific code is surrounded by the #if statement to ensure that it is only ever compiled by Open MPI.

The Open MPI wrapper compilers (mpicc and friends) should automatically insert all relevant compiler and linker flags necessary to use the extensions. No special flags or steps should be necessary compared to "normal" MPI applications.

Compiling Open MPI Applications

Open MPI provides "wrapper" compilers that should be used for compiling MPI and OpenSHMEM applications:

For example:

shell$ mpicc hello_world_mpi.c -o hello_world_mpi -g
shell$

For OpenSHMEM applications:

shell$ oshcc hello_shmem.c -o hello_shmem -g
shell$

All the wrapper compilers do is add a variety of compiler and linker flags to the command line and then invoke a back-end compiler. To be specific: the wrapper compilers do not parse source code at all; they are solely command-line manipulators, and have nothing to do with the actual compilation or linking of programs. The end result is an MPI executable that is properly linked to all the relevant libraries.

Customizing the behavior of the wrapper compilers is possible (e.g., changing the compiler [not recommended] or specifying additional compiler/linker flags); see the Open MPI FAQ for more information.

Alternatively, Open MPI also installs pkg-config(1) configuration files under $libdir/pkgconfig. If pkg-config is configured to find these files, then compiling / linking Open MPI programs can be performed like this:

shell$ gcc hello_world_mpi.c -o hello_world_mpi -g \
            `pkg-config ompi-c --cflags --libs`
shell$

Open MPI supplies multiple pkg-config(1) configuration files; one for each different wrapper compiler (language):

The following pkg-config(1) configuration files may be installed, depending on which command line options were specified to Open MPI's configure script. They are not necessary for MPI applications, but may be used by applications that use Open MPI's lower layer support libraries.

Running Open MPI Applications

Open MPI supports both mpirun and mpiexec (they are exactly equivalent) to launch MPI applications. For example:

shell$ mpirun -np 2 hello_world_mpi
or
shell$ mpiexec -np 1 hello_world_mpi : -np 1 hello_world_mpi

are equivalent.

The rsh launcher (which defaults to using ssh) accepts a --hostfile parameter (the option --machinefile is equivalent); you can specify a --hostfile parameter indicating a standard mpirun-style hostfile (one hostname per line):

shell$ mpirun --hostfile my_hostfile -np 2 hello_world_mpi

If you intend to run more than one process on a node, the hostfile can use the "slots" attribute. If "slots" is not specified, a count of 1 is assumed. For example, using the following hostfile:

shell$ cat my_hostfile
node1.example.com
node2.example.com
node3.example.com slots=2
node4.example.com slots=4
shell$ mpirun --hostfile my_hostfile -np 8 hello_world_mpi

will launch MPI_COMM_WORLD rank 0 on node1, rank 1 on node2, ranks 2 and 3 on node3, and ranks 4 through 7 on node4.

Other starters, such as the resource manager / batch scheduling environments, do not require hostfiles (and will ignore the hostfile if it is supplied). They will also launch as many processes as slots have been allocated by the scheduler if no "-np" argument has been provided. For example, running a SLURM job with 8 processors:

shell$ salloc -n 8 mpirun a.out

The above command will reserve 8 processors and run 1 copy of mpirun, which will, in turn, launch 8 copies of a.out in a single MPI_COMM_WORLD on the processors that were allocated by SLURM.

Note that the values of component parameters can be changed on the mpirun / mpiexec command line. This is explained in the section below, "The Modular Component Architecture (MCA)".

Open MPI supports oshrun to launch OpenSHMEM applications. For example:

shell$ oshrun -np 2 hello_world_oshmem

OpenSHMEM applications may also be launched directly by resource managers such as SLURM. For example, when OMPI is configured --with-pmix and --with-slurm, one may launch OpenSHMEM applications via srun:

shell$ srun -N 2 hello_world_oshmem

The Modular Component Architecture (MCA)

The MCA is the backbone of Open MPI -- most services and functionality are implemented through MCA components.

MPI layer frameworks

Here is a list of all the component frameworks in the MPI layer of Open MPI:

OpenSHMEM component frameworks

Back-end run-time environment (RTE) component frameworks:

Miscellaneous frameworks:

Framework notes

Each framework typically has one or more components that are used at run-time. For example, the btl framework is used by the MPI layer to send bytes across different types underlying networks. The tcp btl, for example, sends messages across TCP-based networks; the ucx pml sends messages across InfiniBand-based networks.

Each component typically has some tunable parameters that can be changed at run-time. Use the ompi_info command to check a component to see what its tunable parameters are. For example:

shell$ ompi_info --param btl tcp

shows some of the parameters (and default values) for the tcp btl component (use --level to show all the parameters; see below).

Note that ompi_info only shows a small number a component's MCA parameters by default. Each MCA parameter has a "level" value from 1 to 9, corresponding to the MPI-3 MPI_T tool interface levels. In Open MPI, we have interpreted these nine levels as three groups of three:

  1. End user / basic
  2. End user / detailed
  3. End user / all
  4. Application tuner / basic
  5. Application tuner / detailed
  6. Application tuner / all
  7. MPI/OpenSHMEM developer / basic
  8. MPI/OpenSHMEM developer / detailed
  9. MPI/OpenSHMEM developer / all

Here's how the three sub-groups are defined:

  1. End user: Generally, these are parameters that are required for correctness, meaning that someone may need to set these just to get their MPI/OpenSHMEM application to run correctly.
  2. Application tuner: Generally, these are parameters that can be used to tweak MPI application performance.
  3. MPI/OpenSHMEM developer: Parameters that either don't fit in the other two, or are specifically intended for debugging / development of Open MPI itself.

Each sub-group is broken down into three classifications:

  1. Basic: For parameters that everyone in this category will want to see.
  2. Detailed: Parameters that are useful, but you probably won't need to change them often.
  3. All: All other parameters -- probably including some fairly esoteric parameters.

To see all available parameters for a given component, specify that ompi_info should use level 9:

shell$ ompi_info --param btl tcp --level 9

These values can be overridden at run-time in several ways. At run-time, the following locations are examined (in order) for new values of parameters:

  1. PREFIX/etc/openmpi-mca-params.conf: This file is intended to set any system-wide default MCA parameter values -- it will apply, by default, to all users who use this Open MPI installation. The default file that is installed contains many comments explaining its format.

  2. $HOME/.openmpi/mca-params.conf: If this file exists, it should be in the same format as PREFIX/etc/openmpi-mca-params.conf. It is intended to provide per-user default parameter values.

  3. environment variables of the form OMPI_MCA_<name> set equal to a VALUE:

    Where <name> is the name of the parameter. For example, set the variable named OMPI_MCA_btl_tcp_frag_size to the value 65536 (Bourne-style shells):

    shell$ OMPI_MCA_btl_tcp_frag_size=65536
shell$ export OMPI_MCA_btl_tcp_frag_size

  4. the mpirun/oshrun command line: --mca NAME VALUE

    Where is the name of the parameter. For example:

    shell$ mpirun --mca btl_tcp_frag_size 65536 -np 2 hello_world_mpi

These locations are checked in order. For example, a parameter value passed on the mpirun command line will override an environment variable; an environment variable will override the system-wide defaults.

Each component typically activates itself when relevant. For example, the usNIC component will detect that usNIC devices are present and will automatically be used for MPI communications. The SLURM component will automatically detect when running inside a SLURM job and activate itself. And so on.

Components can be manually activated or deactivated if necessary, of course. The most common components that are manually activated, deactivated, or tuned are the btl components -- components that are used for MPI point-to-point communications on many types common networks.

For example, to only activate the tcp and self (process loopback) components are used for MPI communications, specify them in a comma-delimited list to the btl MCA parameter:

shell$ mpirun --mca btl tcp,self hello_world_mpi

To add shared memory support, add sm into the command-delimited list (list order does not matter):

shell$ mpirun --mca btl tcp,sm,self hello_world_mpi

(there used to be a vader BTL for shared memory support; it was renamed to sm in Open MPI v5.0.0, but the alias vader still works as well)

To specifically deactivate a specific component, the comma-delimited list can be prepended with a ^ to negate it:

shell$ mpirun --mca btl ^tcp hello_mpi_world

The above command will use any other btl component other than the tcp component.

Questions? Problems?

Found a bug? Got a question? Want to make a suggestion? Want to contribute to Open MPI? Please let us know!

When submitting questions and problems, be sure to include as much extra information as possible. See the community help web page for details on all the information that we request in order to provide assistance:

The best way to report bugs, send comments, or ask questions is to sign up on the user's and/or developer's mailing list (for user-level and developer-level questions; when in doubt, send to the user's list):

Because of spam, only subscribers are allowed to post to these lists (ensure that you subscribe with and post from exactly the same e-mail address -- joe@example.com is considered different than joe@mycomputer.example.com!). Visit these pages to subscribe to the lists:

Make today an Open MPI day!