Installation Instructions 4.6

    1. Building GROMACS

    These instructions pertain to building GROMACS 4.6 and newer releases using our new CMake-based build system. For installations instructions for old GROMACS versions, see the documentation at

    2. Quick and dirty installation

    1. Get the latest version of your compiler.

    2. Check you have CMake version 2.8.x or later.

    3. Unpack the GROMACS tarball.

    4. Make a separate build directory and change to it.

    5. Run CMake with the path to the source as an argument

    6. Run make and make install

    Or, as a sequence of commands to execute:

    tar xfz gromacs-4.6.5.tar.gz
    cd gromacs-4.6.5
    mkdir build
    cd build
    cmake .. -DGMX_BUILD_OWN_FFTW=ON
    sudo make install

    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. It will generally be 30-50% faster than GROMACS 4.5.x, but if you want to get the maximum value for your hardware with GROMACS, you'll have to read further. Sadly, the interactions of hardware, libraries, and compilers are only going to continue to get more complex.

    3. Prerequisites

    3.1. Platform

    GROMACS can be compiled for any distribution of Linux, Mac OS X, Windows (native, Cygwin or MinGW), BlueGene, Cray and many other architectures. Technically, it can be compiled on any platform with an ANSI C compiler and supporting libraries, such as the GNU C library. However, Gromacs also comes with many hardware-specific extensions to provide very high performance on those platforms, and to enable these we have slightly more specific requirements since old compilers do not support new features, or they can be buggy.

    3.2. Compiler

    GROMACS requires an ANSI C compiler that complies with the C89 standard. For best performance, the GROMACS team strongly recommends you get the most recent version of your preferred compiler for your platform (e.g. GCC 4.7 or Intel 12.0 or newer on x86 hardware). There is a large amount of GROMACS code introduced in version 4.6 that depends on effective compiler optimization to get high performance - the old raw assembly-language kernel routines are all gone. Unfortunately this makes GROMACS more sensitive to the compiler used, and the binary will only work on the hardware for which it is compiled, but the good news is that it has enabled us to significantly accelerate performance compared to version 4.5.

    • On Intel-based x86 hardware, we recommend you to use the GNU compilers version 4.7 or later or Intel compilers version 12 or later for best performance. The Intel compiler has historically been better at instruction scheduling, but recent gcc versions have proved to be as fast or sometimes faster than Intel.

    • On AMD-based x86 hardware up through the “K10” microarchitecture (“Family 10h”) Thuban/Magny-Cours architecture (e.g. Opteron 6100-series processors), it is worth using the Intel compiler for better performance, but gcc version 4.7 and later are also reasonable.

    • On the AMD Bulldozer architecture (Opteron 6200), AMD introduced fused multiply-add instructions and an ”FMA4” instruction format not available on Intel x86 processors. Thus, on the most recent AMD processors you want to use gcc version 4.7 or later for better performance! The Intel compiler will only generate code for the subset also supported by Intel processors, and that is significantly slower right now.

    • If you are running on Mac OS X, the best option is the Intel compiler. Both clang and gcc will work, but they produce lower performance and each have some shortcomings. Clang does not support OpenMP, and the current gcc ports (e.g. from MacPorts) do not support AVX instructions.

    • For all non-x86 platforms, your best option is typically to use the vendor's default compiler, and check for specialized information below.

    3.2.1. Running in parallel

    GROMACS can run in parallel on multiple cores of a single workstation using its built-in ThreadMPI. No user action is required in order to enable this.

    If you wish to use the excellent new native GPU support in GROMACS, NVIDIA's CUDA version 3.2 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.

    The GPU support from GROMACS version 4.5 using OpenMM is still contained in the code, but in the “user contributions” section (src/contrib). You will need to set

    in order to build it. It also requires CUDA, and remains the only hardware-based acceleration available for implicit solvent simulations in GROMACS at the moment. However, the long-term plan is to enable this functionality in core Gromacs, and not have the OpenMM interface supported by the GROMACSteam.

    If you wish to run in parallel on multiple machines across a network, you will need to have

    • an MPI library installed that supports the MPI 1.3 standard, and

    • wrapper compilers that will compile code using that library.

    The GROMACS team recommends OpenMPI version 1.4.1 (or higher), MPICH version 1.4.1 (or higher), or your hardware vendor's MPI installation. The most recent version of either of this 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.

    In some cases, OpenMP parallelism is an advantage for GROMACS, but support for this is generally built into your compiler and detected automatically. The one common exception is Mac OS X, where the default clang compiler currently does not fully support OpenMP. You can install gcc version 4.7 instead, but the currently available binary distribution of gcc uses an old system assembler that does not support AVX acceleration instructions. There are some examples on the Internet where people have hacked this to work, but presently the only straightforward way to get both OpenMP and AVX support on Mac OS X is to get the Intel compiler.

    In summary, for maximum performance you will need to examine how you will use GROMACS, what hardware you plan to run on, and whether you can afford a non-free compiler for slightly better performance. The only way to find out is unfortunately 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 (better than in version 4.5), but if you truly want to push your hardware to the performance limit the days of just blindly starting programs like 'mdrun' are gone.

    3.3. CMake

    From version 4.6, GROMACS uses the build system CMake. The previous build system that used configure from the GNU autotools package has been removed permanently. CMake permits the GROMACS team to support a very wide range of hardware, compilers and build configurations while continuing to provide the portability, robustness and performance for which GROMACS is known.

    GROMACS requires CMake version 2.8.0 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 for pre-compiled binaries, source code and installation instructions. The GROMACS team recommends you install the most recent version of CMake you can. If you need to compile CMake yourself and have a really old environment, you might first have to compile a moderately recent version (say, 2.6) to bootstrap version 2.8. This is a one-time job, and you can find lots of documentation on the CMake website if you run into problems.

    3.4. Fast Fourier Transform library

    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's MKL

    3.4.1. FFTW

    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 single floating-point precision whereas 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

    • that you permit the GROMACS installation to download and build FFTW 3.3.2 from source automatically for you (use cmake -DGMX_BUILD_OWN_FFTW=ON), or

    • that you build FFTW from the source code. Note that the GROMACS-managed download of the FFTW tarball has a slight chance of posing a security risk. If you use this option, you will see a warning that advises how you can eliminate this risk.

    If you build FFTW from source yourself, get the most recent version and follow its installation guide available from Choose the precision (i.e. single or float vs. double) to match what you will later require for GROMACS. There is no need to compile with threading or MPI support, but it does no harm. On x86 hardware, compile only with --enable-sse2 (regardless of precision) even if your processors can take advantage of AVX extensions. Since GROMACS uses fairly short transform lengths we do not benefit from the FFTW AVX acceleration, and because of memory system performance limitations, it can even degrade GROMACS performance by around 20%. There is no way for GROMACS to limit the use to SSE2 acceleration at run time if AVX support has been compiled into FFTW, so you need to set this at compile time.

    3.4.2. MKL

    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/ 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 .

    Otherwise, you can configure MKL by setting

    , where the full list (and order!) of libraries you require are found in Intel's MKL documentation for your system.

    3.5. Optional build components

    • Hardware-optimized BLAS and LAPACK libraries are useful for a few of the GROMACS utilities focused on normal modes and matrix manipulation, but they do not provide any benefits for normal simulations. Configuring these are discussed here.

    • The built-in GROMACS trajectory viewer ngmx requires X11 and Motif/Lesstif libraries and header files. Generally, the GROMACS team rather recommends you use third-party software for visualization, such as VMD or PyMOL

    • A few GROMACS tools get some extra functionality when linked with the GNU scientific library GSL.

    4. Doing a build of GROMACS

    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, Mac OS X, MinGW and Cygwin. For other platforms, see the specialist instructions below.

    4.1. Configuring with CMake

    CMake will run many tests on your system and do its best to work out how to build GROMACS for you. If you are building GROMACS on hardware that is identical to that where you will run mdrun, 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, 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 a subdirectory or not, it doesn't matter. 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-4.6.5.tgz
    $ cd gromacs-4.6.5
    $ mkdir build-cmake
    $ cd build-cmake
    $ cmake ..

    You will see cmake report the results of a large number of tests on your system made by CMake and by GROMACS. These are written to the CMake cache, kept in CMakeCache.txt. You can edit this file by hand, but this is not recommended because it is easy to reach an inconsistent state. 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's a serious problem detected at this stage, then you will see a fatal error and some suggestions for how to overcome it. If you're 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.

    CMake works in an iterative fashion, re-running each time a setting is changed to try to make sure other things are consistent. Once things seem consistent, the iterations stop. 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, if the curses library is supported) 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 out. 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 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. If you make any changes, then ccmake will notice that and require that you re-configure (using 'c'), so that it gets a chance to make changes that depend on yours and perform more checking. This might require several configuration stages when you are using ccmake - when you are using cmake the iteration is done behind the scenes.

    A key thing to consider here is the setting of CMAKE_INSTALL_PREFIX. You will need to be able to write to this directory in order to install GROMACS later, and if you change your mind later, changing it in the cache triggers a full re-build, unfortunately. 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.

    When cmake or ccmake have completed iterating, the cache is stable and a build tree can be generated, with 'g' in ccmake or automatically with cmake.

    You should not attempt to change compilers after the initial run of CMake. If you need to change, clean up and start again.

    4.2. Using CMake command-line options

    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 with a command like:

    $ cmake .. -DGMX_GPU=ON -DGMX_MPI=ON -DCMAKE_INSTALL_PREFIX=/home/marydoe/programs

    to build with 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.

    4.3. CMake advanced options

    The options that can be seen with 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.

    4.3.1. Portability aspects

    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.

    Most often a GROMACS build will by default not be portable, not even across hardware with the same base instruction set like x86. The reason for this is that hardware-specific optimizations are selected at configure-time, like 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 CMake option GMX_USE_RDTSCP is 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 slow binaries (especially mdrun), on the new hardware. Building two full installations and locally managing how to call the correct one (e.g. using the 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. 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.

    4.4. Helping CMake find the right libraries/headers/programs

    If libraries are installed in non-default locations their location can be specified using the following environment variables:

    • CMAKE_INCLUDE_PATH for header files

    • CMAKE_LIBRARY_PATH for libraries

    • CMAKE_PREFIX_PATH for header, libraries and binaries (e.g. '/usr/local').

    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 ”:”). Note that these are enviroment variables (and not CMake command-line arguments) and in a 'bash' shell are used like:

    $ CMAKE_PREFIX_PATH=/opt/fftw:/opt/cuda cmake ..

    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.

    4.5. Linear algebra libraries

    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 GMX_EXTERNAL_BLAS 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's 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.

    4.6. Native GPU acceleration

    If you have the CUDA Software Development Kit installed, you can use CMake with:

    cmake .. -DGMX_GPU=ON -DCUDA_TOOLKIT_ROOT_DIR=/usr/local/cuda

    (or whichever path has your installation). Note that this will require a working C++ compiler, and in some cases you might need to handle this manually, e.g. with the advanced option CUDA_HOST_COMPILER.

    Historically, Linux GPU builds have received most testing, but we want to support GPU builds both under x86 Linux, Windows, Mac OS X and in the future ARM. Any feedback on this build process (and fixes in particular) are very welcome!

    4.7. Static linking

    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.

    • To link GROMACS binaries statically against the internal GROMACS libraries, set BUILD_SHARED_LIBS=OFF.

    • To link statically against external libraries as well, the GMX_PREFER_STATIC_LIBS=ON option can be used. Note, that in general CMake picks up whatever is available, so this option only instructs CMake to prefer static libraries when both static and shared are available. If no static version of an external library is available, even when the aforementioned option is ON, the shared library will be used. Also note, that the resulting binaries will still be dynamically linked against system libraries if that is all that is available (common on Mac OS X).

    4.8. Changing the names of GROMACS binaries and libraries

    It is sometimes convenient to have different versions of the same GROMACS libraries installed. The most common use cases have been single and double precision, and with and without MPI. By default, GROMACS will suffix binaries 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). This can also be useful for resolving libary-naming conflicts with existing packges (GMX_PREFIX_LIBMD also can be useful). For instance, to set a custom suffix for binaries and libraries, one might specify:


    Thus the names of all binaries and libraries will be appended with ”_mod.”

    4.9. Building GROMACS

    Once you have a stable cache, you can build GROMACS. If you're not sure the cache is stable, you can re-run cmake .. or ccmake ..' to see. Then you can run make to start the compilation. Before actual compilation starts, make checks that the cache is stable, so if it isn't you will see CMake run again.

    So long as any changes you've made to the configuration are sensible, it is expected that the make procedure will always complete successfully. The tests GROMACS makes on the settings you choose are pretty extensive, but there are probably a few cases we haven't 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.

    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.

    4.10. Installing GROMACS

    Finally, make install will install GROMACS in the directory given in CMAKE_INSTALL_PREFIX. If this is an 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.

    4.11. Getting access to GROMACS after installation

    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 our share/gromacs 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.

    4.12. Testing GROMACS for correctness

    Since 2011, the GROMACS development uses an automated system where every new patch is subject to regression testing. 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 regression 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 tarball yourself from, and use the advanced CMake option -DREGRESSIONTEST_PATH=/path to specify the path to the unpacked tarball, which will then be used for testing (can set -DREGRESSIONTEST_DOWNLOAD=NO at the same time if downloading the file prevents successful configuration.). If this doesn't work, then please read on.

    The regression tests are available from the GROMACS website and ftp site. Once you have downloaded them, unpack the tarball, source GMXRC as described above, and run ./ all inside the regression tests folder. You can find more options (e.g. adding double when using double precision) 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 an example logfile from mdrun (which contains valuable information in the header).

    4.13. Testing GROMACS for performance

    We are still working on a set of benchmark systems for testing the performance of GROMACS. Until that is ready, we recommend that you start by comparing the performance to release 4.5, and also try a few different parallelization options.

    4.14. Having difficulty?

    You're 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:

    1. Read the installation instructions again, taking note that you have followed each and every step correctly.

    2. Search the GROMACS website and users emailing list for information on the error.

    3. Search the internet using a search engine such as Google.

    4. Post to the GROMACS users emailing list gmx-users for assistance. Be sure to give a full description of what you have done and why you think it didn't work. Give details about the system on which you are installing. Copy and paste your command line and as much of the output as you think might be relevant - certainly from the first indication of a problem. In particular, please try to include at least the header from the mdrun logfile, and preferably the entire file. People who might volunteer to help you do not have time to ask you interactive detailed follow-up questions, so you will get an answer faster if you provide as much information as you think could possibly help. High quality bug reports tend to receive rapid high quality answers.

    5. Special instructions for some platforms

    5.1. Building on Windows

    Building on Cygwin/MinGW/etc. works just like Unix. Please see the instructions above.

    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. The UNIX-standard .tar.gz format can be managed on Windows, but you may prefer to browse to obtain a zip format file, which doesn't need any external tools to unzip on recent Windows systems. 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-cmake”.

    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.

    5.2. Building on Cray

    Gromacs builds mostly out of the box on modern Cray machines, but you want to use static libraries due to the peculiarities with parallel job execution.

    5.3. Building on BlueGene

    5.3.1. BlueGene/P

    There is currently no native acceleration on this platform and no plans to make one. The default plain C kernels will work.

    5.3.2. BlueGene/Q

    There is currently native acceleration on this platform for the Verlet cut-off scheme. Accelerated kernels for the group cut-off scheme may come in the future, but the default plain C kernels will work.

    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, single-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.

    mpicc is used for compiling and linking. This can make it awkward to attempt to use IBM's optimized BLAS/LAPACK called ESSL (see the section on linear algebra). 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 - it is rare for this to be a bottleneck.

    The recommended configuration is to use

    cmake .. -DCMAKE_TOOLCHAIN_FILE=Platform/BlueGeneQ-static-XL-CXX \
             -DCMAKE_PREFIX_PATH=/your/fftw/installation/prefix \
    make mdrun
    make install-mdrun

    which will build a statically-linked MPI-enabled mdrun for the back end. 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 serial builds are not useful at all on BlueGene/Q.

    5.3.3. Fujitsu PRIMEHPC

    This is the architecture of the K computer, which uses Fujitsu Sparc64viiifx chips. Gromacs-4.6 will build with default C kernels on this architecture, and Gromacs-4.6.2 added accelerated group kernels and a custom toolchain.

    6. Tested platforms

    While it is our best belief that GROMACS will build and run pretty much everywhere, it's important that we tell you where we really know it works because we've 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.4 through 4.7, and versions 12 and 13 of the Intel compiler as well as Clang version 3.1 through 3.3. For this we use a variety of GNU/Linux flavors and versions as well as recent version of Mac OS X. Under Windows we test both MSVC and the Intel compiler. For details, you can have a look at the continuous integration server at

    We test irregularly on BlueGene/Q, Cray, Fujitsu PRIMEHPC, Google Native Client and other environments. In the future we expect ARM to be an important test target too, but this is currently not included.

    Contributions to this section are welcome.

    Later we might set up the ability for users to contribute test results to Jenkins.

    7. Other issues

    The GROMACS utility programs often write data files in formats suitable for the Grace plotting tool, but it is straightforward to use these files in other plotting programs, too.

    Page last modified 13:51, 24 Sep 2014 by johnny.lu128?