These instructions pertain to building GROMACS 5.1.2. You might also want to check the up-to-date installation instructions.
Or, as a sequence of commands to execute:
tar xfz gromacs-5.1.2.tar.gz cd gromacs-5.1.2 mkdir build cd build cmake .. -DGMX_BUILD_OWN_FFTW=ON -DREGRESSIONTEST_DOWNLOAD=ON make make check sudo make install source /usr/local/gromacs/bin/GMXRC
This will download and build first the prerequisite FFT library followed by GROMACS. If you already have FFTW installed, you can remove that argument to cmake. Overall, this build of GROMACS will be correct and reasonably fast on the machine upon which cmake ran. If you want to get the maximum value for your hardware with GROMACS, you will have to read further. Sadly, the interactions of hardware, libraries, and compilers are only going to continue to get more complex.
As above, and with further details below, but you should consider using the following CMake options with the appropriate value instead of xxx :
For installation instructions for old GROMACS versions, see the documentation for installing GROMACS 4.5, GROMACS 4.6, and GROMACS 5.0.
GROMACS can be compiled for many operating systems and architectures. These include any distribution of Linux, Mac OS X or Windows, and architectures including x86, AMD64/x86-64, PPC, ARM v7 and SPARC VIII.
On Linux, a 64-bit operating system is strongly recommended, since currently GROMACS cannot operate on large trajectories when compiled on a 32-bit system.
Technically, GROMACS can be compiled on any platform with an ANSI C99 and C++98 compiler, and their respective standard C/C++ libraries. We use only a few C99 features, but note that the C++ compiler also needs to support these C99 features (notably, int64_t and related things), which are not part of the C++98 standard. Getting good performance on an OS and architecture requires choosing a good compiler. In practice, many compilers struggle to do a good job optimizing the GROMACS architecture-optimized SIMD kernels.
For best performance, the GROMACS team strongly recommends you get the most recent version of your preferred compiler for your platform. There is a large amount of GROMACS code that depends on effective compiler optimization to get high performance. This makes GROMACS performance sensitive to the compiler used, and the binary will often only work on the hardware for which it is compiled. You may also need the most recent version compiler toolchain components beside the compiler itself (e.g. assembler or linker); these are often shipped by the distribution’s binutils package.
For maximum performance you will need to examine how you will use GROMACS and what hardware you plan to run on. Unfortunately, the only way to find out is to test different options and parallelization schemes for the actual simulations you want to run. You will still get good, performance with the default build and runtime options, but if you truly want to push your hardware to the performance limit, the days of just blindly starting programs with gmx mdrun are gone.
If you wish to use the excellent native GPU support in GROMACS, NVIDIA’s CUDA version 4.0 software development kit is required, and the latest version is strongly encouraged. NVIDIA GPUs with at least NVIDIA compute capability 2.0 are required, e.g. Fermi or Kepler cards. You are strongly recommended to get the latest CUDA version and driver supported by your hardware, but beware of possible performance regressions in newer CUDA versions on older hardware. Note that while some CUDA compilers (nvcc) might not officially support recent versions of gcc as the back-end compiler, we still recommend that you at least use a gcc version recent enough to get the best SIMD support for your CPU, since GROMACS always runs some code on the CPU. It is most reliable to use the same C++ compiler version for GROMACS code as used as the back-end compiler for nvcc, but it could be faster to mix compiler versions to suit particular contexts.
To make it possible to use other accelerators, GROMACS also includes OpenCL support. The current version is recommended for use with GCN-based AMD GPUs. It does work with NVIDIA GPUs, but using the latest NVIDIA driver (which includes the NVIDIA OpenCL runtime) is recommended, and please see the known limitations in the GROMACS user guide. The minimum OpenCL version required is 1.1.
It is not possible to configure both CUDA and OpenCL support in the same version of GROMACS.
GROMACS can run in parallel on multiple cores of a single workstation using its built-in thread-MPI. No user action is required in order to enable this.
If you wish to run in parallel on multiple machines across a network, you will need to have
The GROMACS team recommends OpenMPI version 1.6 (or higher), MPICH version 1.4.1 (or higher), or your hardware vendor’s MPI installation. The most recent version of either of these is likely to be the best. More specialized networks might depend on accelerations only available in the vendor’s library. LAM-MPI might work, but since it has been deprecated for years, it is not supported.
Often OpenMP parallelism is an advantage for GROMACS, but support for this is generally built into your compiler and detected automatically.
GROMACS uses the CMake build system, and requires version 2.8.8 or higher. Lower versions will not work. You can check whether CMake is installed, and what version it is, with cmake --version. If you need to install CMake, then first check whether your platform’s package management system provides a suitable version, or visit the CMake installation page for pre-compiled binaries, source code and installation instructions. The GROMACS team recommends you install the most recent version of CMake you can.
Many simulations in GROMACS make extensive use of fast Fourier transforms, and a software library to perform these is always required. We recommend FFTW (version 3 or higher only) or Intel MKL. The choice of library can be set with cmake -DGMX_FFT_LIBRARY=<name>, where <name> is one of fftw, mkl, or fftpack. FFTPACK is bundled with GROMACS as a fallback, and is acceptable if mdrun performance is not a priority.
FFTW is likely to be available for your platform via its package management system, but there can be compatibility and significant performance issues associated with these packages. In particular, GROMACS simulations are normally run in “mixed” floating-point precision, which is suited for the use of single precision in FFTW. The default FFTW package is normally in double precision, and good compiler options to use for FFTW when linked to GROMACS may not have been used. Accordingly, the GROMACS team recommends either
If you build FFTW from source yourself, get the most recent version and follow the FFTW installation guide. Note that we have recently contributed new SIMD optimization for several extra platforms to FFTW, which will appear in FFTW-3.3.5 (for now it is available in the FFTW repository on github, or you can find a very unofficial prerelease version at ftp://ftp.gromacs.org/pub/prerequisite_software ). Choose the precision for FFTW (i.e. single/float vs. double) to match whether you will later use mixed or double precision for GROMACS. There is no need to compile FFTW with threading or MPI support, but it does no harm. On x86 hardware, compile with both --enable-sse2 and --enable-avx for FFTW-3.3.4 and earlier. As of FFTW-3.3.5 you should also add --enable-avx2. FFTW will create a fat library with codelets for all different instruction sets, and pick the fastest supported one at runtime. On IBM Power8, you definitely want the upcoming FFTW-3.3.5 and use --enable-vsx for SIMD support. If you are using a Cray, there is a special modified (commercial) version of FFTs using the FFTW interface which might be faster, but we have not yet tested this extensively.
Using MKL with the Intel Compilers version 11 or higher is very simple. Set up your compiler environment correctly, perhaps with a command like source /path/to/compilervars.sh intel64 (or consult your local documentation). Then set -DGMX_FFT_LIBRARY=mkl when you run cmake. In this case, GROMACS will also use MKL for BLAS and LAPACK (see linear algebra libraries). Generally, there is no advantage in using MKL with GROMACS, and FFTW is often faster.
Otherwise, you can get your hands dirty and configure MKL by setting
-DGMX_FFT_LIBRARY=mkl
-DMKL_LIBRARIES="/full/path/to/libone.so;/full/path/to/libtwo.so"
-DMKL_INCLUDE_DIR="/full/path/to/mkl/include"
where the full list (and order!) of libraries you require are found in Intel’s MKL documentation for your system.
This section will cover a general build of GROMACS with CMake, but it is not an exhaustive discussion of how to use CMake. There are many resources available on the web, which we suggest you search for when you encounter problems not covered here. The material below applies specifically to builds on Unix-like systems, including Linux, and Mac OS X. For other platforms, see the specialist instructions below.
CMake will run many tests on your system and do its best to work out how to build GROMACS for you. If your build machine is the same as your target machine, then you can be sure that the defaults will be pretty good. The build configuration will for instance attempt to detect the specific hardware instructions available in your processor. However, if you want to control aspects of the build, or you are compiling on a cluster head node for back-end nodes with a different architecture, there are plenty of things you can set manually.
The best way to use CMake to configure GROMACS is to do an “out-of-source” build, by making another directory from which you will run CMake. This can be outside the source directory, or a subdirectory of it. It also means you can never corrupt your source code by trying to build it! So, the only required argument on the CMake command line is the name of the directory containing the CMakeLists.txt file of the code you want to build. For example, download the source tarball and use
tar xfz gromacs-5.1.2.tgz cd gromacs-5.1.2 mkdir build-gromacs cd build-gromacs cmake ..
You will see cmake report a sequence of results of tests and detections done by the GROMACS build system. These are written to the cmake cache, kept in CMakeCache.txt. You can edit this file by hand, but this is not recommended because you could make a mistake. You should not attempt to move or copy this file to do another build, because file paths are hard-coded within it. If you mess things up, just delete this file and start again with cmake.
If there is a serious problem detected at this stage, then you will see a fatal error and some suggestions for how to overcome it. If you are not sure how to deal with that, please start by searching on the web (most computer problems already have known solutions!) and then consult the gmx-users mailing list. There are also informational warnings that you might like to take on board or not. Piping the output of cmake through less or tee can be useful, too.
Once cmake returns, you can see all the settings that were chosen and information about them by using e.g. the curses interface
ccmake ..
You can actually use ccmake (available on most Unix platforms) directly in the first step, but then most of the status messages will merely blink in the lower part of the terminal rather than be written to standard output. Most platforms including Linux, Windows, and Mac OS X even have native graphical user interfaces for cmake, and it can create project files for almost any build environment you want (including Visual Studio or Xcode). Check out running CMake for general advice on what you are seeing and how to navigate and change things. The settings you might normally want to change are already presented. You may make changes, then re-configure (using c), so that it gets a chance to make changes that depend on yours and perform more checking. It may take several configuration passes to reach the desired configuration, in particular if you need to resolve errors.
When you have reached the desired configuration with ccmake, the build system can be generated by pressing g. This requires that the previous configuration pass did not reveal any additional settings (if it did, you need to configure once more with c). With cmake, the build system is generated after each pass that does not produce errors.
You cannot attempt to change compilers after the initial run of cmake. If you need to change, clean up, and start again.
A key thing to consider here is the setting of CMAKE_INSTALL_PREFIX to control where GROMACS will be installed. You will need permissions to be able to write to this directory. So if you do not have super-user privileges on your machine, then you will need to choose a sensible location within your home directory for your GROMACS installation. Even if you do have super-user privileges, you should use them only for the installation phase, and never for configuring, building, or running GROMACS!
Once you become comfortable with setting and changing options, you may know in advance how you will configure GROMACS. If so, you can speed things up by invoking cmake and passing the various options at once on the command line. This can be done by setting cache variable at the cmake invocation using -DOPTION=VALUE. Note that some environment variables are also taken into account, in particular variables like CC and CXX.
For example, the following command line
cmake .. -DGMX_GPU=ON -DGMX_MPI=ON -DCMAKE_INSTALL_PREFIX=/home/marydoe/programs
can be used to build with CUDA GPUs, MPI and install in a custom location. You can even save that in a shell script to make it even easier next time. You can also do this kind of thing with ccmake, but you should avoid this, because the options set with -D will not be able to be changed interactively in that run of ccmake.
GROMACS has extensive support for detecting and using the SIMD capabilities of many modern HPC CPU architectures. If you are building GROMACS on the same hardware you will run it on, then you don’t need to read more about this, unless you are getting configuration warnings you do not understand. By default, the GROMACS build system will detect the SIMD instruction set supported by the CPU architecture (on which the configuring is done), and thus pick the best available SIMD parallelization supported by GROMACS. The build system will also check that the compiler and linker used also support the selected SIMD instruction set and issue a fatal error if they do not.
Valid values are listed below, and the applicable value with the largest number in the list is generally the one you should choose:
The CMake configure system will check that the compiler you have chosen can target the architecture you have chosen. mdrun will check further at runtime, so if in doubt, choose the lowest number you think might work, and see what mdrun says. The configure system also works around many known issues in many versions of common HPC compilers.
A further GMX_SIMD=Reference option exists, which is a special SIMD-like implementation written in plain C that developers can use when developing support in GROMACS for new SIMD architectures. It is not designed for use in production simulations, but if you are using an architecture with SIMD support to which GROMACS has not yet been ported, you may wish to try this option instead of the default GMX_SIMD=None, as it can often out-perform this when the auto-vectorization in your compiler does a good job. And post on the GROMACS mailing lists, because GROMACS can probably be ported for new SIMD architectures in a few days.
The options that are displayed in the default view of ccmake are ones that we think a reasonable number of users might want to consider changing. There are a lot more options available, which you can see by toggling the advanced mode in ccmake on and off with t. Even there, most of the variables that you might want to change have a CMAKE_ or GMX_ prefix. There are also some options that will be visible or not according to whether their preconditions are satisfied.
If libraries are installed in non-default locations their location can be specified using the following variables:
The respective include, lib, or bin is appended to the path. For each of these variables, a list of paths can be specified (on Unix, separated with ”:”). These can be set as enviroment variables like:
CMAKE_PREFIX_PATH=/opt/fftw:/opt/cuda cmake ..
(assuming bash shell). Alternatively, these variables are also cmake options, so they can be set like -DCMAKE_PREFIX_PATH=/opt/fftw:/opt/cuda.
The CC and CXX environment variables are also useful for indicating to cmake which compilers to use, which can be very important for maximising GROMACS performance. Similarly, CFLAGS/CXXFLAGS can be used to pass compiler options, but note that these will be appended to those set by GROMACS for your build platform and build type. You can customize some of this with advanced options such as CMAKE_C_FLAGS and its relatives.
See also the page on CMake environment variables.
If you have the CUDA Toolkit installed, you can use cmake with:
cmake .. -DGMX_GPU=ON -DCUDA_TOOLKIT_ROOT_DIR=/usr/local/cuda
(or whichever path has your installation). In some cases, you might need to specify manually which of your C++ compilers should be used, e.g. with the advanced option CUDA_HOST_COMPILER.
To make it possible to get best performance from NVIDIA Tesla and Quadro GPUs, you should install the GPU Deployment Kit and configure GROMACS to use it by setting the CMake variable -DGPU_DEPLOYMENT_KIT_ROOT_DIR=/path/to/your/kit. The NVML support is most useful if nvidia-smi --applications-clocks-permission=UNRESTRICTED is run (as root). When application clocks permissions are unrestricted, the GPU clock speed can be increased automatically, which increases the GPU kernel performance roughly proportional to the clock increase. When using GROMACS on suitable GPUs under restricted permissions, clocks cannot be changed, and in that case informative log file messages will be produced. Background details can be found at this NVIDIA blog post. NVML support is only available if detected, and may be disabled by turning off the GMX_USE_NVML CMake advanced option.
By default, optimized code will be generated for CUDA architectures supported by the nvcc compiler (and the GROMACS build system). However, it can be beneficial to manually pick the specific CUDA architecture(s) to generate code for either to reduce compilation time (and binary size) or to target a new architecture not yet supported by the GROMACS build system. Setting the desired CUDA architecture(s) and virtual architecture(s) can be done using the GMX_CUDA_TARGET_SM and GMX_CUDA_TARGET_COMPUTE variables, respectively. These take a semicolon delimited string with the two digit suffixes of CUDA (virtual) architectures names (for details see the “Options for steering GPU code generation” section of the nvcc man / help or Chapter 6. of the nvcc manual).
The GPU acceleration has been tested on AMD64/x86-64 platforms with Linux, Mac OS X and Windows operating systems, but Linux is the best-tested and supported of these. Linux running on ARM v7 (32 bit) CPUs also works.
To build Gromacs with OpenCL support enabled, an OpenCL SDK (e.g. from AMD) must be installed in a path found in CMAKE_PREFIX_PATH (or via the environment variables AMDAPPSDKROOT or CUDA_PATH), and the following CMake flags must be set
cmake .. -DGMX_GPU=ON -DGMX_USE_OPENCL=ON
Building GROMACS OpenCL support for a CUDA GPU works, but see the known limitations in the user guide. If you want to do so anyway, because NVIDIA OpenCL support is part of the CUDA package, a C++ compiler supported by your CUDA installation is required.
On Mac OS, an AMD GPU can be used only with OS version 10.10.4 and higher; earlier OS versions are known to run incorrectly.
Dynamic linking of the GROMACS executables will lead to a smaller disk footprint when installed, and so is the default on platforms where we believe it has been tested repeatedly and found to work. In general, this includes Linux, Windows, Mac OS X and BSD systems. Static binaries take much more space, but on some hardware and/or under some conditions they are necessary, most commonly when you are running a parallel simulation using MPI libraries (e.g. BlueGene, Cray).
Here, we consider portability aspects related to CPU instruction sets, for details on other topics like binaries with statical vs dynamic linking please consult the relevant parts of this documentation or other non-GROMACS specific resources.
A GROMACS build will normally not be portable, not even across hardware with the same base instruction set like x86. Non-portable hardware-specific optimizations are selected at configure-time, such as the SIMD instruction set used in the compute-kernels. This selection will be done by the build system based on the capabilities of the build host machine or based on cross-compilation information provided to cmake at configuration.
Often it is possible to ensure portability by choosing the least common denominator of SIMD support, e.g. SSE2 for x86, and ensuring the you use cmake -DGMX_USE_RDTSCP=off if any of the target CPU architectures does not support the RDTSCP instruction. However, we discourage attempts to use a single GROMACS installation when the execution environment is heterogeneous, such as a mix of AVX and earlier hardware, because this will lead to programs (especially mdrun) that run slowly on the new hardware. Building two full installations and locally managing how to call the correct one (e.g. using a module system) is the recommended approach. Alternatively, as at the moment the GROMACS tools do not make strong use of SIMD acceleration, it can be convenient to create an installation with tools portable across different x86 machines, but with separate mdrun binaries for each architecture. To achieve this, one can first build a full installation with the least-common-denominator SIMD instruction set, e.g. -DGMX_SIMD=SSE2, then build separate mdrun binaries for each architecture present in the heterogeneous environment. By using custom binary and library suffixes for the mdrun-only builds, these can be installed to the same location as the “generic” tools installation. Building just the mdrun binary is possible by setting the -DGMX_BUILD_MDRUN_ONLY=ON option.
As mentioned above, sometimes vendor BLAS and LAPACK libraries can provide performance enhancements for GROMACS when doing normal-mode analysis or covariance analysis. For simplicity, the text below will refer only to BLAS, but the same options are available for LAPACK. By default, CMake will search for BLAS, use it if it is found, and otherwise fall back on a version of BLAS internal to GROMACS. The cmake option -DGMX_EXTERNAL_BLAS=on will be set accordingly. The internal versions are fine for normal use. If you need to specify a non-standard path to search, use -DCMAKE_PREFIX_PATH=/path/to/search. If you need to specify a library with a non-standard name (e.g. ESSL on AIX or BlueGene), then set -DGMX_BLAS_USER=/path/to/reach/lib/libwhatever.a.
If you are using Intel MKL for FFT, then the BLAS and LAPACK it provides are used automatically. This could be over-ridden with GMX_BLAS_USER, etc.
On Apple platforms where the Accelerate Framework is available, these will be automatically used for BLAS and LAPACK. This could be over-ridden with GMX_BLAS_USER, etc.
It is sometimes convenient to have different versions of the same GROMACS programs installed. The most common use cases have been single and double precision, and with and without MPI. This mechanism can also be used to install side-by-side multiple versions of mdrun optimized for different CPU architectures, as mentioned previously.
By default, GROMACS will suffix programs and libraries for such builds with _d for double precision and/or _mpi for MPI (and nothing otherwise). This can be controlled manually with GMX_DEFAULT_SUFFIX (ON/OFF), GMX_BINARY_SUFFIX (takes a string) and GMX_LIBS_SUFFIX (also takes a string). For instance, to set a custom suffix for programs and libraries, one might specify:
cmake .. -DGMX_DEFAULT_SUFFIX=OFF -DGMX_BINARY_SUFFIX=_mod -DGMX_LIBS_SUFFIX=_mod
Thus the names of all programs and libraries will be appended with _mod.
By default, a few different directories under CMAKE_INSTALL_PREFIX are used when when GROMACS is installed. Some of these can be changed, which is mainly useful for packaging GROMACS for various distributions. The directories are listed below, with additional notes about some of them. Unless otherwise noted, the directories can be renamed by editing the installation paths in the main CMakeLists.txt.
Once you have configured with cmake, you can build GROMACS with make. It is expected that this will always complete successfully, and give few or no warnings. The CMake-time tests GROMACS makes on the settings you choose are pretty extensive, but there are probably a few cases we have not thought of yet. Search the web first for solutions to problems, but if you need help, ask on gmx-users, being sure to provide as much information as possible about what you did, the system you are building on, and what went wrong. This may mean scrolling back a long way through the output of make to find the first error message!
If you have a multi-core or multi-CPU machine with N processors, then using
make -j N
will generally speed things up by quite a bit. Other build generator systems supported by cmake (e.g. ninja) also work well.
Past versions of the build system offered “mdrun” and “install-mdrun” targets (similarly for other programs too) to build and install only the mdrun program, respectively. Such a build is useful when the configuration is only relevant for mdrun (such as with parallelization options for MPI, SIMD, GPUs, or on BlueGene or Cray), or the length of time for the compile-link-install cycle is relevant when developing.
This is now supported with the cmake option -DGMX_BUILD_MDRUN_ONLY=ON, which will build a cut-down version of libgromacs and/or the mdrun program. Naturally, now make install installs only those products. By default, mdrun-only builds will default to static linking against GROMACS libraries, because this is generally a good idea for the targets for which an mdrun-only build is desirable. If you re-use a build tree and change to the mdrun-only build, then you will inherit the setting for BUILD_SHARED_LIBS from the old build, and will be warned that you may wish to manage BUILD_SHARED_LIBS yourself.
Finally, make install will install GROMACS in the directory given in CMAKE_INSTALL_PREFIX. If this is a system directory, then you will need permission to write there, and you should use super-user privileges only for make install and not the whole procedure.
GROMACS installs the script GMXRC in the bin subdirectory of the installation directory (e.g. /usr/local/gromacs/bin/GMXRC), which you should source from your shell:
source /your/installation/prefix/here/bin/GMXRC
It will detect what kind of shell you are running and set up your environment for using GROMACS. You may wish to arrange for your login scripts to do this automatically; please search the web for instructions on how to do this for your shell.
Many of the GROMACS programs rely on data installed in the share/gromacs subdirectory of the installation directory. By default, the programs will use the environment variables set in the GMXRC script, and if this is not available they will try to guess the path based on their own location. This usually works well unless you change the names of directories inside the install tree. If you still need to do that, you might want to recompile with the new install location properly set, or edit the GMXRC script.
Since 2011, the GROMACS development uses an automated system where every new code change is subject to regression testing on a number of platforms and software combinations. While this improves reliability quite a lot, not everything is tested, and since we increasingly rely on cutting edge compiler features there is non-negligible risk that the default compiler on your system could have bugs. We have tried our best to test and refuse to use known bad versions in cmake, but we strongly recommend that you run through the tests yourself. It only takes a few minutes, after which you can trust your build.
The simplest way to run the checks is to build GROMACS with -DREGRESSIONTEST_DOWNLOAD, and run make check. GROMACS will automatically download and run the tests for you. Alternatively, you can download and unpack the GROMACS regression test suite http://gerrit.gromacs.org/download/regressiontests-5.1.2.tar.gz tarball yourself and use the advanced cmake option REGRESSIONTEST_PATH to specify the path to the unpacked tarball, which will then be used for testing. If the above does not work, then please read on.
The regression tests are also available from the download section. Once you have downloaded them, unpack the tarball, source GMXRC as described above, and run ./gmxtest.pl all inside the regression tests folder. You can find more options (e.g. adding double when using double precision, or -only expanded to run just the tests whose names match “expanded”) if you just execute the script without options.
Hopefully, you will get a report that all tests have passed. If there are individual failed tests it could be a sign of a compiler bug, or that a tolerance is just a tiny bit too tight. Check the output files the script directs you too, and try a different or newer compiler if the errors appear to be real. If you cannot get it to pass the regression tests, you might try dropping a line to the gmx-users mailing list, but then you should include a detailed description of your hardware, and the output of gmx mdrun -version (which contains valuable diagnostic information in the header).
A build with -DGMX_BUILD_MDRUN_ONLY cannot be tested with make check from the build tree, because most of the tests require a full build to run things like grompp. To test such an mdrun fully requires installing it to the same location as a normal build of GROMACS, downloading the regression tests tarball manually as described above, sourcing the correct GMXRC and running the perl script manually. For example, from your GROMACS source directory:
mkdir build-normal
cd build-normal
cmake .. -DCMAKE_INSTALL_PREFIX=/your/installation/prefix/here
make -j 4
make install
cd ..
mkdir build-mdrun-only
cd build-mdrun-only
cmake .. -DGMX_MPI=ON -DGMX_GPU=ON -DGMX_BUILD_MDRUN_ONLY=ON -DCMAKE_INSTALL_PREFIX=/your/installation/prefix/here
make -j 4
make install
cd /to/your/unpacked/regressiontests
source /your/installation/prefix/here/bin/GMXRC
./gmxtest.pl all -np 2
If your mdrun program has been suffixed in a non-standard way, then the ./gmxtest.pl -mdrun option will let you specify that name to the test machinery. You can use ./gmxtest.pl -double to test the double-precision version. You can use ./gmxtest.pl -crosscompiling to stop the test harness attempting to check that the programs can be run. You can use ./gmxtest.pl -mpirun srun if your command to run an MPI program is called srun.
The make check target also runs integration-style tests that may run with MPI if GMX_MPI=ON was set. To make these work, you may need to set the CMake variables MPIEXEC, MPIEXEC_NUMPROC_FLAG, NUMPROC, MPIEXEC_PREFLAGS and MPIEXEC_POSTFLAGS so that mdrun-mpi-test_mpi would run on multiple ranks via the shell command
${MPIEXEC} ${MPIEXEC_NUMPROC_FLAG} ${NUMPROC} ${MPIEXEC_PREFLAGS} \
mdrun-mpi-test_mpi ${MPIEXEC_POSTFLAGS} -otherflags
Typically, one might use variable values mpirun, -np, 2, '', '' respectively, in order to run on two ranks.
We are still working on a set of benchmark systems for testing the performance of GROMACS. Until that is ready, we recommend that you try a few different parallelization options, and experiment with tools such as gmx tune_pme.
You are not alone - this can be a complex task! If you encounter a problem with installing GROMACS, then there are a number of locations where you can find assistance. It is recommended that you follow these steps to find the solution:
Building on Windows using native compilers is rather similar to building on Unix, so please start by reading the above. Then, download and unpack the GROMACS source archive. Make a folder in which to do the out-of-source build of GROMACS. For example, make it within the folder unpacked from the source archive, and call it build-gromacs.
For CMake, you can either use the graphical user interface provided on Windows, or you can use a command line shell with instructions similar to the UNIX ones above. If you open a shell from within your IDE (e.g. Microsoft Visual Studio), it will configure the environment for you, but you might need to tweak this in order to get either a 32-bit or 64-bit build environment. The latter provides the fastest executable. If you use a normal Windows command shell, then you will need to either set up the environment to find your compilers and libraries yourself, or run the vcvarsall.bat batch script provided by MSVC (just like sourcing a bash script under Unix).
With the graphical user interface, you will be asked about what compilers to use at the initial configuration stage, and if you use the command line they can be set in a similar way as under UNIX. You will probably make your life easier and faster by using the new facility to download and install FFTW automatically.
For the build, you can either load the generated solutions file into e.g. Visual Studio, or use the command line with cmake --build so the right tools get used.
GROMACS builds mostly out of the box on modern Cray machines, but
There is currently native acceleration on this platform for the Verlet cut-off scheme. There are no plans to provide accelerated kernels for the group cut-off scheme, but the default plain C kernels will work (slowly).
Only static linking with XL compilers is supported by GROMACS. Dynamic linking would be supported by the architecture and GROMACS, but has no advantages other than disk space, and is generally discouraged on BlueGene for performance reasons.
Computation on BlueGene floating-point units is always done in double-precision. However, mixed-precision builds of GROMACS are still normal and encouraged since they use cache more efficiently. The BlueGene hardware automatically converts values stored in single precision in memory to double precision in registers for computation, converts the results back to single precision correctly, and does so for no additional cost. As with other platforms, doing the whole computation in double precision normally shows no improvement in accuracy and costs twice as much time moving memory around.
You need to arrange for FFTW to be installed correctly, following the above instructions.
MPI wrapper compilers should be used for compiling and linking. Both xlc and bgclang are supported back ends - either might prove to be faster in practice. The MPI wrapper compilers can make it awkward to attempt to use IBM’s optimized BLAS/LAPACK called ESSL (see the section on linear algebra libraries. Since mdrun is the only part of GROMACS that should normally run on the compute nodes, and there is nearly no need for linear algebra support for mdrun, it is recommended to use the GROMACS built-in linear algebra routines - this is never a problem for normal simulations.
The recommended configuration is to use
cmake .. -DCMAKE_C_COMPILER=mpicc \
-DCMAKE_CXX_COMPILER=mpicxx \
-DCMAKE_TOOLCHAIN_FILE=Platform/BlueGeneQ-static-XL-CXX.cmake \
-DCMAKE_PREFIX_PATH=/your/fftw/installation/prefix \
-DGMX_MPI=ON \
-DGMX_BUILD_MDRUN_ONLY=ON
make
make install
which will build a statically-linked MPI-enabled mdrun for the compute nodes. Or use the Platform/BlueGeneQ-static-bgclang-cxx toolchain file if compiling with bgclang. Otherwise, GROMACS default configuration behaviour applies.
It is possible to configure and make the remaining GROMACS tools with the compute-node toolchain, but as none of those tools are MPI-aware and could then only run on the compute nodes, this would not normally be useful. Instead, these should be planned to run on the login node, and a separate GROMACS installation performed for that using the login node’s toolchain - not the above platform file, or any other compute-node toolchain.
Note that only the MPI build is available for the compute-node toolchains. The GROMACS thread-MPI or no-MPI builds are not useful at all on BlueGene/Q.
There is currently no SIMD support on this platform and no plans to add it. The default plain C kernels will work.
This is the architecture of the K computer, which uses Fujitsu Sparc64VIIIfx chips. On this platform, GROMACS has accelerated group kernels using the HPC-ACE instructions, no accelerated Verlet kernels, and a custom build toolchain. Since this particular chip only does double precision SIMD, the default setup is to build GROMACS in double. Since most users only need single, we have added an option GMX_RELAXED_DOUBLE_PRECISION to accept single precision square root accuracy in the group kernels; unless you know that you really need 15 digits of accuracy in each individual force, we strongly recommend you use this. Note that all summation and other operations are still done in double.
The recommended configuration is to use
cmake .. -DCMAKE_TOOLCHAIN_FILE=Toolchain-Fujitsu-Sparc64-mpi.cmake \
-DCMAKE_PREFIX_PATH=/your/fftw/installation/prefix \
-DCMAKE_INSTALL_PREFIX=/where/gromacs/should/be/installed \
-DGMX_MPI=ON \
-DGMX_BUILD_MDRUN_ONLY=ON \
-DGMX_RELAXED_DOUBLE_PRECISION=ON
make
make install
GROMACS has preliminary support for Intel Xeon Phi. Only symmetric (aka native) mode is supported. GROMACS is functional on Xeon Phi, but it has so far not been optimized to the same level as other architectures have. The performance depends among other factors on the system size, and for now the performance might not be faster than CPUs. Building for Xeon Phi works almost as any other Unix. See the instructions above for details. The recommended configuration is
cmake .. -DCMAKE_TOOLCHAIN_FILE=Platform/XeonPhi
make
make install
While it is our best belief that GROMACS will build and run pretty much everywhere, it is important that we tell you where we really know it works because we have tested it. We do test on Linux, Windows, and Mac with a range of compilers and libraries for a range of our configuration options. Every commit in our git source code repository is currently tested on x86 with gcc versions ranging from 4.1 through 5.1, and versions 12 through 15 of the Intel compiler as well as Clang version 3.4 through 3.6. For this, we use a variety of GNU/Linux flavors and versions as well as recent versions of Mac OS X and Windows. Under Windows we test both MSVC and the Intel compiler. For details, you can have a look at the continuous integration server used by GROMACS, which runs Jenkins.
We test irregularly on ARM v7, ARM v8, BlueGene/Q, Cray, Fujitsu PRIMEHPC, Power8, Google Native Client and other environments, and with other compilers and compiler versions, too.