MPICH is the portable open implementation of MPI, and the build is a classic source install

The implementation of the standard, from Argonne

MPICH is described as a high-performance and widely portable implementation of the Message Passing Interface standard from the Argonne National Laboratory, and the key phrase in the README is that it provides all MPI functions and features required by the standard, with broad support for parallel computing applications. The audience is anyone running code across multiple nodes: the model is a library plus a launcher, where the library gives you send and receive primitives and the launcher starts the processes and connects them. The adoption story in the README is the reason to look at it, because a MPI implementation is only useful if your cluster already runs it. The project says it is widely adopted by multiple vendor partners including Intel, Hewlett Packard Enterprise, ParTec and Ohio State University through X-ScaleSolutions, and that it has been deployed on many Top 500 HPC systems. That is a compatibility argument: a program written against MPI compiled here is the same program those sites run.

The prerequisites are short, and two of them can be switched off

Before anything else, the README lists what you need. The source tarball is required, so is Perl, and so is a C compiler, with C99 support required and C11 preferred for C11 Atomics. Three things are optional, and each has a configure switch to turn it off. A C++ compiler is needed only if C++ applications will be used, and can be disabled with --disable-cxx. A Fortran compiler is needed only if Fortran applications will be used, and can be disabled with --disable-fortran. Python 3 is needed to generate the Fortran bindings, with no switch mentioned for it. That last point is worth flagging: the build has a Python dependency in the Fortran binding generation step, which is easy to miss when planning a build on a cluster that does not carry Python on the login or compute nodes.

Configure, make, install, and the path has to match everywhere

The installation sequence is the classic GNU autotools one, and the README walks it step by step. Unpack and enter the directory:

tar xzf mpich-<version>.tar.gz
cd mpich-<version>

Then configure with the prefix and let it pick a device:

./configure --prefix=/home/<USERNAME>/mpich-install 2>&1 | tee c.txt

The build, and the install, are the same two steps you would expect:

make 2>&1 | tee m.txt

make install 2>&1 | tee mi.txt

The install step collects the required executables and scripts in the bin subdirectory of the prefix directory, and you add that to your path:

PATH=/home/<USERNAME>/mpich-install/bin:$PATH ; export PATH

The README then flags the constraint that catches people out, marked as an important note: the install directory has to be visible at exactly the same path on all machines you want to run your applications on. It says this is typically achieved by installing MPICH on a shared NFS file system, and that without one you have to copy the install directory to every machine at exactly the same location. That is not a stylistic preference, it is a property of how the launcher finds the runtime binaries.

CH4 and the network module are the two choices the build bakes in

The default configuration described in the README is the CH4 device with the OFI network module and Hydra process management, and the configure step tries to determine the best device based on the system environment. You can override that. The two examples given are the OFI module and the UCX module:

./configure --prefix=... --with-device=ch4:ofi |...

./configure --prefix=... --with-device=ch4:ucx |...

So the transport is a separate decision from the device, and the README has a dedicated section on the CH4 network modules. For a cluster operator this is the part that matters. A vendor build of MPICH arrives with a network module already matched to that vendor's fabric, whereas a source build asks you to name one, and OFI and UCX are the two routes the documentation gives. If you are not sure which applies to your hardware, the configure step is where you find out, since it inspects the environment, and the README notes that a failure during configure is usually a straight-forward error to follow, such as the message about a missing Fortran compiler.

Hydra starts the processes, and the CPI example proves it

MPICH uses a process manager for starting MPI applications, and the manager provides the mpiexec executable together with other utility executables. The package ships with multiple process managers, and the default is called Hydra. The README's test is the classic CPI example, which computes the value of pi by numerical integration in parallel, and it lives in the examples directory of the installation. Running it locally on one machine takes a process count:

mpiexec -n <number> ./examples/cpi

Testing across nodes uses a hostfile instead, with the mpiexec -f m form given in the README. Two details are worth keeping in mind. The examples are installed alongside the binaries, so the CPI program is present on every node as soon as the shared install directory is mounted, and the same directory also contains the other bundled examples. The examples directory in the source tree is richer than that: alongside cpi.c, hellow.c and the Fortran and C++ variants, it carries the pmandel family, which shows the MPI process spawn and service interfaces, plus directories for CUDA, Argobots and F08 Fortran.

A GNU autotools tree with the packaging of a distribution

The repository layout is that of a long established C project. The build system is autotools, with configure.ac, Makefile.am, autogen.sh and a top level Makefile.am. The source lives in src/, the network and process management modules in modules/, the configuration database tooling in confdb/, with contrib/, maint/, packaging/, test/, examples/ and doc/ completing the tree. Documentation is generated for Doxygen through mpich-doxygen.in, and the release tarball ships two PDFs that the README points at, doc/installguide/install.pdf and doc/userguide/user.pdf, while the source tree carries a doc/wiki directory with the same content in a browsable form. A .packit.yaml file suggests the project is packaged for Fedora through Packit, and .travis.yml shows the older continuous integration configuration. There are also governance files, GOVERNANCE.md, CONTRIBUTING, COPYRIGHT and CHANGES, which is a sign of a project with an institutional owner rather than a single maintainer.

Source builds and release tarballs are different paths

The README opens with a note that matters if you are cloning rather than downloading. This guide assumes you are building from a release tarball, and if you are starting from a git checkout you will need a few additional steps, which the README refers to the wiki page for. That is the practical difference between the two routes. The tarball is pre-configured and ships the manuals, while a checkout needs the extra bootstrap steps and relies on doc/wiki for documentation. The table of contents also lists sections for developer builds, compiler flags, support for multiple Fortran compilers, ABI compatibility and how to cite MPICH, and those last two are the ones to read before you commit to a version in a long lived project. The ABI section in particular is what tells you whether a rebuild of your application is needed, and the release history shows the pace: v5.0.1 on 2026-04-10, v5.0.2 on 2026-09-28, and an alpha, v5.1.0a1, on 2026-10-15, with the last push on 2026-10-20.

When a vendor build is the better answer

The alternative to building MPICH yourself is to use one of the vendor builds of the same implementation, since Intel, Hewlett Packard Enterprise, ParTec and X-ScaleSolutions all ship versions. The difference in approach is not the API, it is what comes with it. A source build gives you the generic implementation, the CH4 device, the network module you name at configure time, and a compiler you chose, with the build recipe in front of you and the ability to change any of it. A vendor build gives you a configuration already matched to that vendor's fabric and interconnect, usually with the tuning and the testing that come with it, and a support path that goes to the vendor rather than to a mailing list. For a cluster you do not own, the vendor build is usually the right answer, because the people who built the machine know which network module it wants. For a research group that needs a specific compiler, a specific network module or a patched source, the tarball build in this README is the one to follow. The licence is the one thing to check either way, because the repository licence could not be classified automatically and the COPYRIGHT file sits alongside it.

Editorial conclusion

Adopt MPICH if you are building parallel applications and want an implementation that tracks the MPI standard closely, with the option to choose your own network module and to rebuild from a release tarball with your own compiler, since that is exactly the path the README documents. Do not adopt it if you need vendor tuned performance and a single support contract, because the vendor partners listed in the README ship their own builds of this same implementation, and the source build leaves you responsible for the toolchain on every node. Before you start, confirm the install directory will be at the identical path on all machines, because MPICH requires it, and decide the CH4 network module and process manager settings before you configure, since those are the two choices the build bakes in.

Frequently asked questions

Official sources

1. Issues
2. pmodels/mpich on GitHub
3. Project website
4. README
5. Releases