9 Introduction to building |Gromacs|
10 ==================================
12 These instructions pertain to building |Gromacs|
13 |version|. You might also want to check the `up-to-date installation instructions`_.
15 Quick and dirty installation
16 ----------------------------
17 1. Get the latest version of your C and C++ compilers.
18 2. Check that you have CMake version |GMX_CMAKE_MINIMUM_REQUIRED_VERSION| or later.
19 3. Get and unpack the latest version of the |Gromacs| tarball.
20 4. Make a separate build directory and change to it.
21 5. Run ``cmake`` with the path to the source as an argument
22 6. Run ``make``, ``make check``, and ``make install``
23 7. Source ``GMXRC`` to get access to |Gromacs|
25 Or, as a sequence of commands to execute:
29 tar xfz gromacs-|version|.tar.gz
33 cmake .. -DGMX_BUILD_OWN_FFTW=ON -DREGRESSIONTEST_DOWNLOAD=ON
37 source /usr/local/gromacs/bin/GMXRC
39 This will download and build first the prerequisite FFT library
40 followed by |Gromacs|. If you already have FFTW installed, you can
41 remove that argument to ``cmake``. Overall, this build of |Gromacs| will
42 be correct and reasonably fast on the machine upon which ``cmake``
43 ran. If you want to get the maximum value for your hardware with
44 |Gromacs|, you will have to read further. Sadly, the interactions of
45 hardware, libraries, and compilers are only going to continue to get
50 As above, and with further details below, but you should consider
51 using the following `CMake options`_ with the
52 appropriate value instead of ``xxx`` :
54 * ``-DCMAKE_C_COMPILER=xxx`` equal to the name of the C99 `Compiler`_ you wish to use (or the environment variable ``CC``)
55 * ``-DCMAKE_CXX_COMPILER=xxx`` equal to the name of the C++98 `compiler`_ you wish to use (or the environment variable ``CXX``)
56 * ``-DGMX_MPI=on`` to build using `MPI support`_
57 * ``-DGMX_GPU=on`` to build using nvcc to run using NVIDIA `native GPU acceleration`_ or an OpenCL_ GPU
58 * ``-DGMX_USE_OPENCL=on`` to build with OpenCL_ support enabled. ``GMX_GPU`` must also be set.
59 * ``-DGMX_SIMD=xxx`` to specify the level of `SIMD support`_ of the node on which |Gromacs| will run
60 * ``-DGMX_BUILD_MDRUN_ONLY=on`` for `building only mdrun`_, e.g. for compute cluster back-end nodes
61 * ``-DGMX_DOUBLE=on`` to build |Gromacs| in double precision (slower, and not normally useful)
62 * ``-DCMAKE_PREFIX_PATH=xxx`` to add a non-standard location for CMake to `search for libraries, headers or programs`_
63 * ``-DCMAKE_INSTALL_PREFIX=xxx`` to install |Gromacs| to a `non-standard location`_ (default ``/usr/local/gromacs``)
64 * ``-DBUILD_SHARED_LIBS=off`` to turn off the building of shared libraries to help with `static linking`_
65 * ``-DGMX_FFT_LIBRARY=xxx`` to select whether to use ``fftw``, ``mkl`` or ``fftpack`` libraries for `FFT support`_
66 * ``-DCMAKE_BUILD_TYPE=Debug`` to build |Gromacs| in debug mode
68 Building older versions
69 -----------------------
70 For installation instructions for old |Gromacs| versions, see the
71 documentation for installing
72 `GROMACS 4.5 <http://www.gromacs.org/Documentation/Installation_Instructions_4.5>`_,
73 `GROMACS 4.6 <http://www.gromacs.org/Documentation/Installation_Instructions_4.6>`_,
75 `GROMACS 5.0 <http://www.gromacs.org/Documentation/Installation_Instructions_5.0>`_.
81 |Gromacs| can be compiled for many operating systems and architectures.
82 These include any distribution of Linux, Mac OS X or Windows, and
83 architectures including x86, AMD64/x86-64, PPC, ARM v7 and SPARC VIII.
85 On Linux, a 64-bit operating system is strongly recommended, since currently
86 |Gromacs| cannot operate on large trajectories when compiled on a 32-bit
91 Technically, |Gromacs| can be compiled on any platform with an ANSI C99
92 and C++11 compiler, and their respective standard C/C++ libraries.
93 GROMACS uses a subset of C99 and C++11. A not fully standard compliant
94 compiler might be able to compile GROMACS.
95 Getting good performance on an OS and architecture requires choosing a
96 good compiler. In practice, many compilers struggle to do a good job
97 optimizing the |Gromacs| architecture-optimized SIMD kernels.
99 C++11 support requires both support in the compiler as well as in the
100 C++ library. Multiple compilers do not provide their own library
101 but use the system library. It is required to select a library with
102 sufficient C++11 support. Both the Intel and clang compiler on Linux use
103 the libstdc++ which comes with gcc as the default C++ library. 4.6.1 of
104 that library is required. Also the C++ library version has to be
105 supported by the compiler. To select the C++ library version use:
107 * For Intel: ``CXXFLAGS=-gcc-name=/path/to/gcc/binary`` or make sure
108 that the correct gcc version is first in path (e.g. by loading the gcc
110 * For clang: ``CFLAGS=--gcc-toolchain=/path/to/gcc/folder
111 CXXFLAGS=--gcc-toolchain=/path/to/gcc/folder``. This folder should
112 contain ``include/c++``.
113 * On Windows with e.g. Intel: at least MSVC 2013 is required. Load the
114 enviroment with vcvarsall.bat.
116 For best performance, the |Gromacs| team strongly recommends you get the
117 most recent version of your preferred compiler for your platform.
118 There is a large amount of |Gromacs| code that depends on effective
119 compiler optimization to get high performance. This makes |Gromacs|
120 performance sensitive to the compiler used, and the binary will often
121 only work on the hardware for which it is compiled.
123 * In particular, |Gromacs| includes a lot of explicit SIMD (single
124 instruction, multiple data) optimization that suits
125 modern processors. This can greatly increase
126 performance, but for recent processors you
127 also need a similarly recent compiler to get this benefit. The
128 configuration does a good job at detecting this, and you will
129 usually get warnings if |Gromacs| and your hardware support a more
130 recent instruction set than your compiler.
132 * On Intel-based x86 hardware, we recommend you to use the GNU
133 compilers version 4.7 or later or Intel compilers version 12 or
134 later for best performance. The Intel compiler has historically been
135 better at instruction scheduling, but recent gcc versions have
136 proved to be as fast or sometimes faster than Intel.
138 * The Intel and GNU compilers produce much faster |Gromacs| executables
139 than the PGI and Cray compilers.
141 * On AMD-based x86 hardware up through the "K10" microarchitecture
142 ("Family 10h") Thuban/Magny-Cours architecture (e.g. Opteron
143 6100-series processors), it is worth using the Intel compiler for
144 better performance, but gcc version 4.7 and later are also
147 * On the AMD Bulldozer architecture (Opteron 6200), AMD introduced
148 fused multiply-add instructions and an "FMA4" instruction format not
149 available on Intel x86 processors. Thus, on the most recent AMD
150 processors you want to use gcc version 4.7 or later for best
151 performance! The Intel compiler will only generate code for the
152 subset also supported by Intel processors, and that is significantly
155 * If you are running on Mac OS X, the best option is the Intel
156 compiler. Both clang and gcc will work, but they produce lower
157 performance and each have some shortcomings. Current clang does not
158 support OpenMP. This may change when clang 3.7 becomes available.
160 * For all non-x86 platforms, your best option is typically to use the
161 vendor's default or recommended compiler, and check for specialized
164 Compiling with parallelization options
165 --------------------------------------
167 For maximum performance you will need to examine how you will use
168 |Gromacs| and what hardware you plan to run on. Unfortunately, the
169 only way to find out is to test different options and parallelization
170 schemes for the actual simulations you want to run. You will still get
171 *good*, performance with the default build and runtime options, but if
172 you truly want to push your hardware to the performance limit, the
173 days of just blindly starting programs with ``gmx mdrun`` are gone.
177 If you wish to use the excellent native GPU support in |Gromacs|,
178 NVIDIA's CUDA_ version |REQUIRED_CUDA_VERSION| software development kit is required,
179 and the latest version is strongly encouraged. NVIDIA GPUs with at
180 least NVIDIA compute capability |REQUIRED_CUDA_COMPUTE_CAPABILITY| are
181 required, e.g. Fermi or Kepler cards. You are strongly recommended to
182 get the latest CUDA version and driver supported by your hardware, but
183 beware of possible performance regressions in newer CUDA versions on
184 older hardware. Note that while some CUDA compilers (nvcc) might not
185 officially support recent versions of gcc as the back-end compiler, we
186 still recommend that you at least use a gcc version recent enough to
187 get the best SIMD support for your CPU, since |Gromacs| always runs some
188 code on the CPU. It is most reliable to use the same C++ compiler
189 version for |Gromacs| code as used as the back-end compiler for nvcc,
190 but it could be faster to mix compiler versions to suit particular
193 To make it possible to use other accelerators, |Gromacs| also includes
194 OpenCL_ support. The current version is recommended for use with
195 GCN-based AMD GPUs. It does work with NVIDIA GPUs, but using the latest
196 NVIDIA driver (which includes the NVIDIA OpenCL runtime) is recommended,
197 and please see the known limitations in the |Gromacs| user guide. The
198 minimum OpenCL version required is |REQUIRED_OPENCL_MIN_VERSION|.
200 It is not possible to configure both CUDA and OpenCL support in the
201 same version of |Gromacs|.
208 |Gromacs| can run in parallel on multiple cores of a single
209 workstation using its built-in thread-MPI. No user action is required
210 in order to enable this.
212 If you wish to run in parallel on multiple machines across a network,
213 you will need to have
215 * an MPI library installed that supports the MPI 1.3
217 * wrapper compilers that will compile code using that library.
219 The |Gromacs| team recommends OpenMPI_ version
220 1.6 (or higher), MPICH_ version 1.4.1 (or
221 higher), or your hardware vendor's MPI installation. The most recent
222 version of either of these is likely to be the best. More specialized
223 networks might depend on accelerations only available in the vendor's
224 library. LAM-MPI_ might work, but since it has
225 been deprecated for years, it is not supported.
227 Often OpenMP_ parallelism is an
228 advantage for |Gromacs|, but support for this is generally built into
229 your compiler and detected automatically.
233 |Gromacs| uses the CMake build system, and requires
234 version |GMX_CMAKE_MINIMUM_REQUIRED_VERSION| or higher. Lower versions
235 will not work. You can check whether CMake is installed, and what
236 version it is, with ``cmake --version``. If you need to install CMake,
237 then first check whether your platform's package management system
238 provides a suitable version, or visit the `CMake installation page`_
240 binaries, source code and installation instructions. The |Gromacs| team
241 recommends you install the most recent version of CMake you can.
245 Fast Fourier Transform library
246 ------------------------------
247 Many simulations in |Gromacs| make extensive use of fast Fourier
248 transforms, and a software library to perform these is always
249 required. We recommend FFTW_ (version 3 or higher only) or
250 Intel MKL_. The choice of
251 library can be set with ``cmake -DGMX_FFT_LIBRARY=<name>``, where
252 ``<name>`` is one of ``fftw``, ``mkl``, or ``fftpack``. FFTPACK is bundled
253 with |Gromacs| as a fallback, and is acceptable if mdrun performance is
258 FFTW_ is likely to be available for your platform via its package
259 management system, but there can be compatibility and significant
260 performance issues associated with these packages. In particular,
261 |Gromacs| simulations are normally run in "mixed" floating-point
262 precision, which is suited for the use of single precision in
263 FFTW. The default FFTW package is normally in double
264 precision, and good compiler options to use for FFTW when linked to
265 |Gromacs| may not have been used. Accordingly, the |Gromacs| team
268 * that you permit the |Gromacs| installation to download and
269 build FFTW from source automatically for you (use
270 ``cmake -DGMX_BUILD_OWN_FFTW=ON``), or
271 * that you build FFTW from the source code.
273 If you build FFTW from source yourself, get the most recent version
274 and follow the `FFTW installation guide`_. Note that we have recently
275 contributed new SIMD optimization for several extra platforms to
276 FFTW, which will appear in FFTW-3.3.5 (for now it is available in the
277 FFTW repository on github, or you can find a very unofficial prerelease
278 version at ftp://ftp.gromacs.org/pub/prerequisite_software ).
279 Choose the precision for FFTW (i.e. single/float vs. double) to
280 match whether you will later use mixed or double precision for
281 |Gromacs|. There is no need to compile FFTW with
282 threading or MPI support, but it does no harm. On x86 hardware,
283 compile with *both* ``--enable-sse2`` and ``--enable-avx`` for
284 FFTW-3.3.4 and earlier. As of FFTW-3.3.5 you should also add
285 ``--enable-avx2``. FFTW will create a fat library with codelets
286 for all different instruction sets, and pick the fastest supported
287 one at runtime. On IBM Power8, you definitely want the upcoming
288 FFTW-3.3.5 and use ``--enable-vsx`` for SIMD support. If you are
289 using a Cray, there is a special modified (commercial) version of
290 FFTs using the FFTW interface which might be faster, but we have
291 not yet tested this extensively.
295 Using MKL_ with the Intel Compilers version 11 or higher is very
296 simple. Set up your compiler environment correctly, perhaps with a
297 command like ``source /path/to/compilervars.sh intel64`` (or consult
298 your local documentation). Then set ``-DGMX_FFT_LIBRARY=mkl`` when you
299 run cmake. In this case, |Gromacs| will also use MKL for BLAS and LAPACK
300 (see `linear algebra libraries`_). Generally,
301 there is no advantage in using MKL with |Gromacs|, and FFTW is often
304 Otherwise, you can get your hands dirty and configure MKL by setting
308 -DGMX_FFT_LIBRARY=mkl
309 -DMKL_LIBRARIES="/full/path/to/libone.so;/full/path/to/libtwo.so"
310 -DMKL_INCLUDE_DIR="/full/path/to/mkl/include"
312 where the full list (and order!) of libraries you require are found in
313 Intel's MKL documentation for your system.
315 Optional build components
316 -------------------------
317 * Compiling to run on NVIDIA GPUs requires CUDA_
318 * Compiling to run on AMD GPUs requires OpenCL_
319 * Hardware-optimized BLAS and LAPACK libraries are useful
320 for a few of the |Gromacs| utilities focused on normal modes and
321 matrix manipulation, but they do not provide any benefits for normal
322 simulations. Configuring these is discussed at
323 `linear algebra libraries`_.
324 * The built-in |Gromacs| trajectory viewer ``gmx view`` requires X11 and
325 Motif/Lesstif libraries and header files. You may prefer to use
326 third-party software for visualization, such as VMD_ or PyMol_.
327 * An external TNG library for trajectory-file handling can be used,
328 but TNG 1.7.6 is bundled in the |Gromacs| source already
329 * zlib is used by TNG for compressing some kinds of trajectory data
330 * Running the |Gromacs| test suite requires libxml2
331 * Building the |Gromacs| documentation requires ImageMagick, pdflatex,
332 bibtex, doxygen, python 2.7, sphinx and pygments.
333 * The |Gromacs| utility programs often write data files in formats
334 suitable for the Grace plotting tool, but it is straightforward to
335 use these files in other plotting programs, too.
337 Doing a build of |Gromacs|
338 ==========================
339 This section will cover a general build of |Gromacs| with CMake_, but it
340 is not an exhaustive discussion of how to use CMake. There are many
341 resources available on the web, which we suggest you search for when
342 you encounter problems not covered here. The material below applies
343 specifically to builds on Unix-like systems, including Linux, and Mac
344 OS X. For other platforms, see the specialist instructions below.
346 Configuring with CMake
347 ----------------------
348 CMake will run many tests on your system and do its best to work out
349 how to build |Gromacs| for you. If your build machine is the same as
350 your target machine, then you can be sure that the defaults will be
351 pretty good. The build configuration will for instance attempt to
352 detect the specific hardware instructions available in your
353 processor. However, if you want to control aspects of the build, or
354 you are compiling on a cluster head node for back-end nodes with a
355 different architecture, there are plenty of things you can set
358 The best way to use CMake to configure |Gromacs| is to do an
359 "out-of-source" build, by making another directory from which you will
360 run CMake. This can be outside the source directory, or a subdirectory
361 of it. It also means you can never corrupt your source code by trying
362 to build it! So, the only required argument on the CMake command line
363 is the name of the directory containing the ``CMakeLists.txt`` file of
364 the code you want to build. For example, download the source tarball
369 tar xfz gromacs-|version|.tgz
375 You will see ``cmake`` report a sequence of results of tests and
376 detections done by the |Gromacs| build system. These are written to the
377 ``cmake`` cache, kept in ``CMakeCache.txt``. You can edit this file by
378 hand, but this is not recommended because you could make a mistake.
379 You should not attempt to move or copy this file to do another build,
380 because file paths are hard-coded within it. If you mess things up,
381 just delete this file and start again with ``cmake``.
383 If there is a serious problem detected at this stage, then you will see
384 a fatal error and some suggestions for how to overcome it. If you are
385 not sure how to deal with that, please start by searching on the web
386 (most computer problems already have known solutions!) and then
387 consult the gmx-users mailing list. There are also informational
388 warnings that you might like to take on board or not. Piping the
389 output of ``cmake`` through ``less`` or ``tee`` can be
392 Once ``cmake`` returns, you can see all the settings that were chosen
393 and information about them by using e.g. the curses interface
399 You can actually use ``ccmake`` (available on most Unix platforms)
400 directly in the first step, but then
401 most of the status messages will merely blink in the lower part
402 of the terminal rather than be written to standard output. Most platforms
403 including Linux, Windows, and Mac OS X even have native graphical user interfaces for
404 ``cmake``, and it can create project files for almost any build environment
405 you want (including Visual Studio or Xcode).
406 Check out `running CMake`_ for
407 general advice on what you are seeing and how to navigate and change
408 things. The settings you might normally want to change are already
409 presented. You may make changes, then re-configure (using ``c``), so that it
410 gets a chance to make changes that depend on yours and perform more
411 checking. It may take several configuration passes to reach the desired
412 configuration, in particular if you need to resolve errors.
414 When you have reached the desired configuration with ``ccmake``, the
415 build system can be generated by pressing ``g``. This requires that the previous
416 configuration pass did not reveal any additional settings (if it did, you need
417 to configure once more with ``c``). With ``cmake``, the build system is generated
418 after each pass that does not produce errors.
420 You cannot attempt to change compilers after the initial run of
421 ``cmake``. If you need to change, clean up, and start again.
423 .. _non-standard location:
425 Where to install GROMACS
426 ^^^^^^^^^^^^^^^^^^^^^^^^
428 A key thing to consider here is the setting of
429 ``CMAKE_INSTALL_PREFIX`` to control where |Gromacs| will be installed.
430 You will need permissions to be able to write to this directory.
431 So if you do not have super-user privileges on your
432 machine, then you will need to choose a sensible location within your
433 home directory for your |Gromacs| installation. Even if you do have
434 super-user privileges, you should use them only for the installation
435 phase, and never for configuring, building, or running |Gromacs|!
439 Using CMake command-line options
440 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
441 Once you become comfortable with setting and changing options, you may
442 know in advance how you will configure |Gromacs|. If so, you can speed
443 things up by invoking ``cmake`` and passing the various options at once
444 on the command line. This can be done by setting cache variable at the
445 cmake invocation using ``-DOPTION=VALUE``. Note that some
446 environment variables are also taken into account, in particular
447 variables like ``CC`` and ``CXX``.
449 For example, the following command line
453 cmake .. -DGMX_GPU=ON -DGMX_MPI=ON -DCMAKE_INSTALL_PREFIX=/home/marydoe/programs
455 can be used to build with CUDA GPUs, MPI and install in a custom
456 location. You can even save that in a shell script to make it even
457 easier next time. You can also do this kind of thing with ``ccmake``,
458 but you should avoid this, because the options set with ``-D`` will not
459 be able to be changed interactively in that run of ``ccmake``.
463 |Gromacs| has extensive support for detecting and using the SIMD
464 capabilities of many modern HPC CPU architectures. If you are building
465 |Gromacs| on the same hardware you will run it on, then you don't need
466 to read more about this, unless you are getting configuration warnings
467 you do not understand. By default, the |Gromacs| build system will
468 detect the SIMD instruction set supported by the CPU architecture (on
469 which the configuring is done), and thus pick the best
470 available SIMD parallelization supported by |Gromacs|. The build system
471 will also check that the compiler and linker used also support the
472 selected SIMD instruction set and issue a fatal error if they
475 Valid values are listed below, and the applicable value with the
476 largest number in the list is generally the one you should choose:
478 1. ``None`` For use only on an architecture either lacking SIMD,
479 or to which |Gromacs| has not yet been ported and none of the
480 options below are applicable.
481 2. ``SSE2`` This SIMD instruction set was introduced in Intel
482 processors in 2001, and AMD in 2003. Essentially all x86
483 machines in existence have this, so it might be a good choice if
484 you need to support dinosaur x86 computers too.
485 3. ``SSE4.1`` Present in all Intel core processors since 2007,
486 but notably not in AMD Magny-Cours. Still, almost all recent
487 processors support this, so this can also be considered a good
488 baseline if you are content with portability between reasonably
490 4. ``AVX_128_FMA`` AMD bulldozer processors (2011) have this.
491 Unfortunately Intel and AMD have diverged the last few years;
492 If you want good performance on modern AMD processors
493 you have to use this since it also allows the rest of the
494 code to use AMD 4-way fused multiply-add instructions. The drawback
495 is that your code will not run on Intel processors at all.
496 5. ``AVX_256`` This instruction set is present on Intel processors
497 since Sandy Bridge (2011), where it is the best choice unless
498 you have an even more recent CPU that supports AVX2. While this
499 code will work on recent AMD processors, it is significantly
500 less efficient than the ``AVX_128_FMA`` choice above - do not be
501 fooled to assume that 256 is better than 128 in this case.
502 6. ``AVX2_256`` Present on Intel Haswell (and later) processors (2013),
503 and it will also enable Intel 3-way fused multiply-add instructions.
504 This code will not work on AMD CPUs.
505 7. ``IBM_QPX`` BlueGene/Q A2 cores have this.
506 8. ``Sparc64_HPC_ACE`` Fujitsu machines like the K computer have this.
507 9. ``IBM_VMX`` Power6 and similar Altivec processors have this.
508 10. ``IBM_VSX`` Power7 and Power8 have this.
510 The CMake configure system will check that the compiler you have
511 chosen can target the architecture you have chosen. mdrun will check
512 further at runtime, so if in doubt, choose the lowest number you
513 think might work, and see what mdrun says. The configure system also
514 works around many known issues in many versions of common HPC
517 A further ``GMX_SIMD=Reference`` option exists, which is a special
518 SIMD-like implementation written in plain C that developers can use
519 when developing support in |Gromacs| for new SIMD architectures. It is
520 not designed for use in production simulations, but if you are using
521 an architecture with SIMD support to which |Gromacs| has not yet been
522 ported, you may wish to try this option instead of the default
523 ``GMX_SIMD=None``, as it can often out-perform this when the
524 auto-vectorization in your compiler does a good job. And post on the
525 |Gromacs| mailing lists, because |Gromacs| can probably be ported for new
526 SIMD architectures in a few days.
528 CMake advanced options
529 ^^^^^^^^^^^^^^^^^^^^^^
530 The options that are displayed in the default view of ``ccmake`` are
531 ones that we think a reasonable number of users might want to consider
532 changing. There are a lot more options available, which you can see by
533 toggling the advanced mode in ``ccmake`` on and off with ``t``. Even
534 there, most of the variables that you might want to change have a
535 ``CMAKE_`` or ``GMX_`` prefix. There are also some options that will be
536 visible or not according to whether their preconditions are satisfied.
538 .. _search for libraries, headers or programs:
540 Helping CMake find the right libraries, headers, or programs
541 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
542 If libraries are installed in non-default locations their location can
543 be specified using the following variables:
545 * ``CMAKE_INCLUDE_PATH`` for header files
546 * ``CMAKE_LIBRARY_PATH`` for libraries
547 * ``CMAKE_PREFIX_PATH`` for header, libraries and binaries
548 (e.g. ``/usr/local``).
550 The respective ``include``, ``lib``, or ``bin`` is
551 appended to the path. For each of these variables, a list of paths can
552 be specified (on Unix, separated with ":"). These can be set as
553 enviroment variables like:
557 CMAKE_PREFIX_PATH=/opt/fftw:/opt/cuda cmake ..
559 (assuming ``bash`` shell). Alternatively, these variables are also
560 ``cmake`` options, so they can be set like
561 ``-DCMAKE_PREFIX_PATH=/opt/fftw:/opt/cuda``.
563 The ``CC`` and ``CXX`` environment variables are also useful
564 for indicating to ``cmake`` which compilers to use, which can be very
565 important for maximising |Gromacs| performance. Similarly,
566 ``CFLAGS``/``CXXFLAGS`` can be used to pass compiler
567 options, but note that these will be appended to those set by
568 |Gromacs| for your build platform and build type. You can customize
569 some of this with advanced options such as ``CMAKE_C_FLAGS``
572 See also the page on `CMake environment variables`_.
574 .. _Native GPU acceleration:
576 Native CUDA GPU acceleration
577 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
578 If you have the CUDA_ Toolkit installed, you can use ``cmake`` with:
582 cmake .. -DGMX_GPU=ON -DCUDA_TOOLKIT_ROOT_DIR=/usr/local/cuda
584 (or whichever path has your installation). In some cases, you might
585 need to specify manually which of your C++ compilers should be used,
586 e.g. with the advanced option ``CUDA_HOST_COMPILER``.
589 possible to get best performance from NVIDIA Tesla and Quadro GPUs,
590 you should install the `GPU Deployment Kit
591 <https://developer.nvidia.com/gpu-deployment-kit>`_ and configure
592 |Gromacs| to use it by setting the CMake variable
593 ``-DGPU_DEPLOYMENT_KIT_ROOT_DIR=/path/to/your/kit``. The NVML support
595 ``nvidia-smi --applications-clocks-permission=UNRESTRICTED`` is run
596 (as root). When application clocks permissions are unrestricted, the
597 GPU clock speed can be increased automatically, which increases the
598 GPU kernel performance roughly proportional to the clock
599 increase. When using |Gromacs| on suitable GPUs under restricted
600 permissions, clocks cannot be changed, and in that case informative
601 log file messages will be produced. Background details can be found at
602 this `NVIDIA blog post
603 <http://devblogs.nvidia.com/parallelforall/increase-performance-gpu-boost-k80-autoboost/>`_.
604 NVML support is only available if detected, and may be disabled by
605 turning off the ``GMX_USE_NVML`` CMake advanced option.
607 By default, optimized code will be generated for CUDA architectures
608 supported by the nvcc compiler (and the |Gromacs| build system).
609 However, it can be beneficial to manually pick the specific CUDA architecture(s)
610 to generate code for either to reduce compilation time (and binary size) or to
611 target a new architecture not yet supported by the |GROMACS| build system.
612 Setting the desired CUDA architecture(s) and virtual architecture(s)
613 can be done using the ``GMX_CUDA_TARGET_SM`` and ``GMX_CUDA_TARGET_COMPUTE``
614 variables, respectively. These take a semicolon delimited string with
615 the two digit suffixes of CUDA (virtual) architectures names
616 (for details see the "Options for steering GPU code generation" section of the
617 nvcc man / help or Chapter 6. of the nvcc manual).
619 The GPU acceleration has been tested on AMD64/x86-64 platforms with
620 Linux, Mac OS X and Windows operating systems, but Linux is the
621 best-tested and supported of these. Linux running on ARM v7 (32 bit)
624 OpenCL GPU acceleration
625 ^^^^^^^^^^^^^^^^^^^^^^^
626 To build Gromacs with OpenCL support enabled, an OpenCL_ SDK
627 (e.g. `from AMD <http://developer.amd.com/appsdk>`_) must be installed
628 in a path found in ``CMAKE_PREFIX_PATH`` (or via the environment
629 variables ``AMDAPPSDKROOT`` or ``CUDA_PATH``), and the following CMake
634 cmake .. -DGMX_GPU=ON -DGMX_USE_OPENCL=ON
636 Building |Gromacs| OpenCL support for a CUDA_ GPU works, but see the
637 known limitations in the user guide. If you want to
638 do so anyway, because NVIDIA OpenCL support is part of the CUDA
639 package, a C++ compiler supported by your CUDA installation is
642 On Mac OS, an AMD GPU can be used only with OS version 10.10.4 and
643 higher; earlier OS versions are known to run incorrectly.
647 Dynamic linking of the |Gromacs| executables will lead to a
648 smaller disk footprint when installed, and so is the default on
649 platforms where we believe it has been tested repeatedly and found to work.
650 In general, this includes Linux, Windows, Mac OS X and BSD systems.
651 Static binaries take much more space, but on some hardware and/or under
652 some conditions they are necessary, most commonly when you are running a parallel
653 simulation using MPI libraries (e.g. BlueGene, Cray).
655 * To link |Gromacs| binaries statically against the internal |Gromacs|
656 libraries, set ``-DBUILD_SHARED_LIBS=OFF``.
657 * To link statically against external (non-system) libraries as well,
658 set ``-DGMX_PREFER_STATIC_LIBS=ON``. Note, that in
659 general ``cmake`` picks up whatever is available, so this option only
660 instructs ``cmake`` to prefer static libraries when both static and
661 shared are available. If no static version of an external library is
662 available, even when the aforementioned option is ``ON``, the shared
663 library will be used. Also note that the resulting binaries will
664 still be dynamically linked against system libraries on platforms
665 where that is the default. To use static system libraries,
666 additional compiler/linker flags are necessary, e.g. ``-static-libgcc
668 * To attempt to link a fully static binary set
669 ``-DGMX_BUILD_SHARED_EXE=OFF``. This will prevent CMake from explicitly
670 setting any dynamic linking flags. This option also sets
671 ``-DBUILD_SHARED_LIBS=OFF`` and ``-DGMX_PREFER_STATIC_LIBS=ON`` by
672 default, but the above caveats apply. For compilers which don't
673 default to static linking, the required flags have to be specified. On
674 Linux, this is usually ``CFLAGS=-static CXXFLAGS=-static``.
678 Here, we consider portability aspects related to CPU instruction sets,
679 for details on other topics like binaries with statical vs dynamic
680 linking please consult the relevant parts of this documentation or
681 other non-|Gromacs| specific resources.
683 A |Gromacs| build will normally not be portable, not even across
684 hardware with the same base instruction set like x86. Non-portable
685 hardware-specific optimizations are selected at configure-time, such
686 as the SIMD instruction set used in the compute-kernels. This
687 selection will be done by the build system based on the capabilities
688 of the build host machine or based on cross-compilation information
689 provided to ``cmake`` at configuration.
691 Often it is possible to ensure portability by choosing the least
692 common denominator of SIMD support, e.g. SSE2 for x86, and ensuring
693 the you use ``cmake -DGMX_USE_RDTSCP=off`` if any of the target CPU
694 architectures does not support the ``RDTSCP`` instruction. However, we
695 discourage attempts to use a single |Gromacs| installation when the
696 execution environment is heterogeneous, such as a mix of AVX and
697 earlier hardware, because this will lead to programs (especially
698 mdrun) that run slowly on the new hardware. Building two full
699 installations and locally managing how to call the correct one
700 (e.g. using a module system) is the recommended
701 approach. Alternatively, as at the moment the |Gromacs| tools do not
702 make strong use of SIMD acceleration, it can be convenient to create
703 an installation with tools portable across different x86 machines, but
704 with separate mdrun binaries for each architecture. To achieve this,
705 one can first build a full installation with the
706 least-common-denominator SIMD instruction set, e.g. ``-DGMX_SIMD=SSE2``,
707 then build separate mdrun binaries for each architecture present in
708 the heterogeneous environment. By using custom binary and library
709 suffixes for the mdrun-only builds, these can be installed to the
710 same location as the "generic" tools installation.
711 `Building just the mdrun binary`_ is possible by setting the
712 ``-DGMX_BUILD_MDRUN_ONLY=ON`` option.
714 Linear algebra libraries
715 ^^^^^^^^^^^^^^^^^^^^^^^^
716 As mentioned above, sometimes vendor BLAS and LAPACK libraries
717 can provide performance enhancements for |Gromacs| when doing
718 normal-mode analysis or covariance analysis. For simplicity, the text
719 below will refer only to BLAS, but the same options are available
720 for LAPACK. By default, CMake will search for BLAS, use it if it
721 is found, and otherwise fall back on a version of BLAS internal to
722 |Gromacs|. The ``cmake`` option ``-DGMX_EXTERNAL_BLAS=on`` will be set
723 accordingly. The internal versions are fine for normal use. If you
724 need to specify a non-standard path to search, use
725 ``-DCMAKE_PREFIX_PATH=/path/to/search``. If you need to specify a
726 library with a non-standard name (e.g. ESSL on AIX or BlueGene), then
727 set ``-DGMX_BLAS_USER=/path/to/reach/lib/libwhatever.a``.
729 If you are using Intel MKL_ for FFT, then the BLAS and
730 LAPACK it provides are used automatically. This could be
731 over-ridden with ``GMX_BLAS_USER``, etc.
733 On Apple platforms where the Accelerate Framework is available, these
734 will be automatically used for BLAS and LAPACK. This could be
735 over-ridden with ``GMX_BLAS_USER``, etc.
737 Changing the names of |Gromacs| binaries and libraries
738 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
739 It is sometimes convenient to have different versions of the same
740 |Gromacs| programs installed. The most common use cases have been single
741 and double precision, and with and without MPI. This mechanism can
742 also be used to install side-by-side multiple versions of mdrun
743 optimized for different CPU architectures, as mentioned previously.
745 By default, |Gromacs| will suffix programs and libraries for such builds
746 with ``_d`` for double precision and/or ``_mpi`` for MPI (and nothing
747 otherwise). This can be controlled manually with ``GMX_DEFAULT_SUFFIX
748 (ON/OFF)``, ``GMX_BINARY_SUFFIX`` (takes a string) and ``GMX_LIBS_SUFFIX``
749 (also takes a string). For instance, to set a custom suffix for
750 programs and libraries, one might specify:
754 cmake .. -DGMX_DEFAULT_SUFFIX=OFF -DGMX_BINARY_SUFFIX=_mod -DGMX_LIBS_SUFFIX=_mod
756 Thus the names of all programs and libraries will be appended with
759 Changing installation tree structure
760 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
761 By default, a few different directories under ``CMAKE_INSTALL_PREFIX`` are used
762 when when |Gromacs| is installed. Some of these can be changed, which is mainly
763 useful for packaging |Gromacs| for various distributions. The directories are
764 listed below, with additional notes about some of them. Unless otherwise noted,
765 the directories can be renamed by editing the installation paths in the main
769 The standard location for executables and some scripts.
770 Some of the scripts hardcode the absolute installation prefix, which needs
771 to be changed if the scripts are relocated.
773 The standard location for installed headers.
775 The standard location for libraries. The default depends on the system, and
776 is determined by CMake.
777 The name of the directory can be changed using ``GMX_LIB_INSTALL_DIR`` CMake
780 Information about the installed ``libgromacs`` library for ``pkg-config`` is
781 installed here. The ``lib/`` part adapts to the installation location of the
782 libraries. The installed files contain the installation prefix as absolute
785 CMake package configuration files are installed here.
787 Various data files and some documentation go here.
788 The ``gromacs`` part can be changed using ``GMX_DATA_INSTALL_DIR``. Using this
789 CMake variable is the preferred way of changing the installation path for
790 ``share/gromacs/top/``, since the path to this directory is built into
791 ``libgromacs`` as well as some scripts, both as a relative and as an absolute
792 path (the latter as a fallback if everything else fails).
794 Installed man pages go here.
796 Compiling and linking
797 ---------------------
798 Once you have configured with ``cmake``, you can build |Gromacs| with ``make``.
799 It is expected that this will always complete successfully, and
800 give few or no warnings. The CMake-time tests |Gromacs| makes on the settings
801 you choose are pretty extensive, but there are probably a few cases we
802 have not thought of yet. Search the web first for solutions to
803 problems, but if you need help, ask on gmx-users, being sure to
804 provide as much information as possible about what you did, the system
805 you are building on, and what went wrong. This may mean scrolling back
806 a long way through the output of ``make`` to find the first error
809 If you have a multi-core or multi-CPU machine with ``N``
810 processors, then using
816 will generally speed things up by quite a bit. Other build generator systems
817 supported by ``cmake`` (e.g. ``ninja``) also work well.
819 .. _building just the mdrun binary:
823 Past versions of the build system offered "mdrun" and "install-mdrun"
824 targets (similarly for other programs too) to build and install only
825 the mdrun program, respectively. Such a build is useful when the
826 configuration is only relevant for mdrun (such as with
827 parallelization options for MPI, SIMD, GPUs, or on BlueGene or Cray),
828 or the length of time for the compile-link-install cycle is relevant
831 This is now supported with the ``cmake`` option
832 ``-DGMX_BUILD_MDRUN_ONLY=ON``, which will build a cut-down version of
833 ``libgromacs`` and/or the mdrun program.
834 Naturally, now ``make install`` installs only those
835 products. By default, mdrun-only builds will default to static linking
836 against |Gromacs| libraries, because this is generally a good idea for
837 the targets for which an mdrun-only build is desirable. If you re-use
838 a build tree and change to the mdrun-only build, then you will inherit
839 the setting for ``BUILD_SHARED_LIBS`` from the old build, and will be
840 warned that you may wish to manage ``BUILD_SHARED_LIBS`` yourself.
844 Finally, ``make install`` will install |Gromacs| in the
845 directory given in ``CMAKE_INSTALL_PREFIX``. If this is a system
846 directory, then you will need permission to write there, and you
847 should use super-user privileges only for ``make install`` and
848 not the whole procedure.
850 .. _getting access to GROMACS:
852 Getting access to |Gromacs| after installation
853 ----------------------------------------------
854 |Gromacs| installs the script ``GMXRC`` in the ``bin``
855 subdirectory of the installation directory
856 (e.g. ``/usr/local/gromacs/bin/GMXRC``), which you should source
861 source /your/installation/prefix/here/bin/GMXRC
863 It will detect what kind of shell you are running and set up your
864 environment for using |Gromacs|. You may wish to arrange for your
865 login scripts to do this automatically; please search the web for
866 instructions on how to do this for your shell.
868 Many of the |Gromacs| programs rely on data installed in the
869 ``share/gromacs`` subdirectory of the installation directory. By
870 default, the programs will use the environment variables set in the
871 ``GMXRC`` script, and if this is not available they will try to guess the
872 path based on their own location. This usually works well unless you
873 change the names of directories inside the install tree. If you still
874 need to do that, you might want to recompile with the new install
875 location properly set, or edit the ``GMXRC`` script.
877 Testing |Gromacs| for correctness
878 ---------------------------------
879 Since 2011, the |Gromacs| development uses an automated system where
880 every new code change is subject to regression testing on a number of
881 platforms and software combinations. While this improves
882 reliability quite a lot, not everything is tested, and since we
883 increasingly rely on cutting edge compiler features there is
884 non-negligible risk that the default compiler on your system could
885 have bugs. We have tried our best to test and refuse to use known bad
886 versions in ``cmake``, but we strongly recommend that you run through
887 the tests yourself. It only takes a few minutes, after which you can
890 The simplest way to run the checks is to build |Gromacs| with
891 ``-DREGRESSIONTEST_DOWNLOAD``, and run ``make check``.
892 |Gromacs| will automatically download and run the tests for you.
893 Alternatively, you can download and unpack the GROMACS
894 regression test suite |gmx-regressiontests-package| tarball yourself
895 and use the advanced ``cmake`` option ``REGRESSIONTEST_PATH`` to
896 specify the path to the unpacked tarball, which will then be used for
897 testing. If the above does not work, then please read on.
899 The regression tests are also available from the download_ section.
900 Once you have downloaded them, unpack the tarball, source
901 ``GMXRC`` as described above, and run ``./gmxtest.pl all``
902 inside the regression tests folder. You can find more options
903 (e.g. adding ``double`` when using double precision, or
904 ``-only expanded`` to run just the tests whose names match
905 "expanded") if you just execute the script without options.
907 Hopefully, you will get a report that all tests have passed. If there
908 are individual failed tests it could be a sign of a compiler bug, or
909 that a tolerance is just a tiny bit too tight. Check the output files
910 the script directs you too, and try a different or newer compiler if
911 the errors appear to be real. If you cannot get it to pass the
912 regression tests, you might try dropping a line to the gmx-users
913 mailing list, but then you should include a detailed description of
914 your hardware, and the output of ``gmx mdrun -version`` (which contains
915 valuable diagnostic information in the header).
917 A build with ``-DGMX_BUILD_MDRUN_ONLY`` cannot be tested with
918 ``make check`` from the build tree, because most of the tests
919 require a full build to run things like ``grompp``. To test such an
920 mdrun fully requires installing it to the same location as a normal
921 build of |Gromacs|, downloading the regression tests tarball manually
922 as described above, sourcing the correct ``GMXRC`` and running the
923 perl script manually. For example, from your |Gromacs| source
930 cmake .. -DCMAKE_INSTALL_PREFIX=/your/installation/prefix/here
934 mkdir build-mdrun-only
936 cmake .. -DGMX_MPI=ON -DGMX_GPU=ON -DGMX_BUILD_MDRUN_ONLY=ON -DCMAKE_INSTALL_PREFIX=/your/installation/prefix/here
939 cd /to/your/unpacked/regressiontests
940 source /your/installation/prefix/here/bin/GMXRC
941 ./gmxtest.pl all -np 2
943 If your mdrun program has been suffixed in a non-standard way, then
944 the ``./gmxtest.pl -mdrun`` option will let you specify that name to the
945 test machinery. You can use ``./gmxtest.pl -double`` to test the
946 double-precision version. You can use ``./gmxtest.pl -crosscompiling``
947 to stop the test harness attempting to check that the programs can
948 be run. You can use ``./gmxtest.pl -mpirun srun`` if your command to
949 run an MPI program is called ``srun``.
951 The ``make check`` target also runs integration-style tests that may run
952 with MPI if ``GMX_MPI=ON`` was set. To make these work, you may need to
953 set the CMake variables ``MPIEXEC``, ``MPIEXEC_NUMPROC_FLAG``, ``NUMPROC``,
954 ``MPIEXEC_PREFLAGS`` and ``MPIEXEC_POSTFLAGS`` so that
955 ``mdrun-mpi-test_mpi`` would run on multiple ranks via the shell command
959 ${MPIEXEC} ${MPIEXEC_NUMPROC_FLAG} ${NUMPROC} ${MPIEXEC_PREFLAGS} \
960 mdrun-mpi-test_mpi ${MPIEXEC_POSTFLAGS} -otherflags
962 Typically, one might use variable values ``mpirun``, ``-np``, ``2``, ``''``,
963 ``''`` respectively, in order to run on two ranks.
966 Testing |Gromacs| for performance
967 ---------------------------------
968 We are still working on a set of benchmark systems for testing
969 the performance of |Gromacs|. Until that is ready, we recommend that
970 you try a few different parallelization options, and experiment with
971 tools such as ``gmx tune_pme``.
975 You are not alone - this can be a complex task! If you encounter a
976 problem with installing |Gromacs|, then there are a number of
977 locations where you can find assistance. It is recommended that you
978 follow these steps to find the solution:
980 1. Read the installation instructions again, taking note that you
981 have followed each and every step correctly.
983 2. Search the |Gromacs| webpage_ and users emailing list for information
985 ``site:https://mailman-1.sys.kth.se/pipermail/gromacs.org_gmx-users``
986 to a Google search may help filter better results.
988 3. Search the internet using a search engine such as Google.
990 4. Post to the |Gromacs| users emailing list gmx-users for
991 assistance. Be sure to give a full description of what you have
992 done and why you think it did not work. Give details about the
993 system on which you are installing. Copy and paste your command
994 line and as much of the output as you think might be relevant -
995 certainly from the first indication of a problem. In particular,
996 please try to include at least the header from the mdrun logfile,
997 and preferably the entire file. People who might volunteer to help
998 you do not have time to ask you interactive detailed follow-up
999 questions, so you will get an answer faster if you provide as much
1000 information as you think could possibly help. High quality bug
1001 reports tend to receive rapid high quality answers.
1003 Special instructions for some platforms
1004 =======================================
1008 Building on Windows using native compilers is rather similar to
1009 building on Unix, so please start by reading the above. Then, download
1010 and unpack the |Gromacs| source archive. Make a folder in which to do
1011 the out-of-source build of |Gromacs|. For example, make it within the
1012 folder unpacked from the source archive, and call it ``build-gromacs``.
1014 For CMake, you can either use the graphical user interface provided on
1015 Windows, or you can use a command line shell with instructions similar
1016 to the UNIX ones above. If you open a shell from within your IDE
1017 (e.g. Microsoft Visual Studio), it will configure the environment for
1018 you, but you might need to tweak this in order to get either a 32-bit
1019 or 64-bit build environment. The latter provides the fastest
1020 executable. If you use a normal Windows command shell, then you will
1021 need to either set up the environment to find your compilers and
1022 libraries yourself, or run the ``vcvarsall.bat`` batch script provided
1023 by MSVC (just like sourcing a bash script under Unix).
1025 With the graphical user interface, you will be asked about what
1026 compilers to use at the initial configuration stage, and if you use
1027 the command line they can be set in a similar way as under UNIX. You
1028 will probably make your life easier and faster by using the new
1029 facility to download and install FFTW automatically.
1031 For the build, you can either load the generated solutions file into
1032 e.g. Visual Studio, or use the command line with ``cmake --build`` so
1033 the right tools get used.
1037 |Gromacs| builds mostly out of the box on modern Cray machines, but
1039 * you may need to specify the use of static binaries
1040 with ``-DGMX_BUILD_SHARED_EXE=off``,
1041 * you may need to set the F77 environmental variable to ``ftn`` when
1044 Building on BlueGene
1045 --------------------
1049 There is currently native acceleration on this platform for the Verlet
1050 cut-off scheme. There are no plans to provide accelerated kernels for
1051 the group cut-off scheme, but the default plain C kernels will work
1054 Only static linking with XL compilers is supported by |Gromacs|. Dynamic
1055 linking would be supported by the architecture and |Gromacs|, but has no
1056 advantages other than disk space, and is generally discouraged on
1057 BlueGene for performance reasons.
1059 Computation on BlueGene floating-point units is always done in
1060 double-precision. However, mixed-precision builds of |Gromacs| are still
1061 normal and encouraged since they use cache more efficiently. The
1062 BlueGene hardware automatically converts values stored in single
1063 precision in memory to double precision in registers for computation,
1064 converts the results back to single precision correctly, and does so
1065 for no additional cost. As with other platforms, doing the whole
1066 computation in double precision normally shows no improvement in
1067 accuracy and costs twice as much time moving memory around.
1069 You need to arrange for FFTW to be installed correctly, following the
1072 MPI wrapper compilers should be used for compiling and linking. Both
1073 xlc and bgclang are supported back ends - either might prove to be
1074 faster in practice. The MPI wrapper compilers can make it awkward to
1075 attempt to use IBM's optimized BLAS/LAPACK called ESSL (see the
1076 section on `linear algebra libraries`_. Since mdrun is the only part
1077 of |Gromacs| that should normally run on the compute nodes, and there is
1078 nearly no need for linear algebra support for mdrun, it is recommended
1079 to use the |Gromacs| built-in linear algebra routines - this is never
1080 a problem for normal simulations.
1082 The recommended configuration is to use
1086 cmake .. -DCMAKE_C_COMPILER=mpicc \
1087 -DCMAKE_CXX_COMPILER=mpicxx \
1088 -DCMAKE_TOOLCHAIN_FILE=Platform/BlueGeneQ-static-XL-CXX.cmake \
1089 -DCMAKE_PREFIX_PATH=/your/fftw/installation/prefix \
1091 -DGMX_BUILD_MDRUN_ONLY=ON
1095 which will build a statically-linked MPI-enabled mdrun for the compute
1096 nodes. Or use the Platform/BlueGeneQ-static-bgclang-cxx
1097 toolchain file if compiling with bgclang. Otherwise, |Gromacs| default configuration
1100 It is possible to configure and make the remaining |Gromacs| tools with
1101 the compute-node toolchain, but as none of those tools are MPI-aware
1102 and could then only run on the compute nodes, this would not normally
1103 be useful. Instead, these should be planned to run on the login node,
1104 and a separate |Gromacs| installation performed for that using the login
1105 node's toolchain - not the above platform file, or any other
1106 compute-node toolchain.
1108 Note that only the MPI build is available for the compute-node
1109 toolchains. The |Gromacs| thread-MPI or no-MPI builds are not useful at
1114 There is currently no SIMD support on this platform and no plans to
1115 add it. The default plain C kernels will work.
1119 This is the architecture of the K computer, which uses Fujitsu
1120 Sparc64VIIIfx chips. On this platform, |Gromacs| has
1121 accelerated group kernels using the HPC-ACE instructions, no
1122 accelerated Verlet kernels, and a custom build toolchain. Since this
1123 particular chip only does double precision SIMD, the default setup
1124 is to build |Gromacs| in double. Since most users only need single, we have added
1125 an option GMX_RELAXED_DOUBLE_PRECISION to accept single precision square root
1126 accuracy in the group kernels; unless you know that you really need 15 digits
1127 of accuracy in each individual force, we strongly recommend you use this. Note
1128 that all summation and other operations are still done in double.
1130 The recommended configuration is to use
1134 cmake .. -DCMAKE_TOOLCHAIN_FILE=Toolchain-Fujitsu-Sparc64-mpi.cmake \
1135 -DCMAKE_PREFIX_PATH=/your/fftw/installation/prefix \
1136 -DCMAKE_INSTALL_PREFIX=/where/gromacs/should/be/installed \
1138 -DGMX_BUILD_MDRUN_ONLY=ON \
1139 -DGMX_RELAXED_DOUBLE_PRECISION=ON
1145 |Gromacs| has preliminary support for Intel Xeon Phi. Only symmetric
1146 (aka native) mode is supported. |Gromacs| is functional on Xeon Phi, but
1147 it has so far not been optimized to the same level as other
1148 architectures have. The performance depends among other factors on the
1149 system size, and for
1150 now the performance might not be faster than CPUs. Building for Xeon
1151 Phi works almost as any other Unix. See the instructions above for
1152 details. The recommended configuration is
1156 cmake .. -DCMAKE_TOOLCHAIN_FILE=Platform/XeonPhi
1162 While it is our best belief that |Gromacs| will build and run pretty
1163 much everywhere, it is important that we tell you where we really know
1164 it works because we have tested it. We do test on Linux, Windows, and
1165 Mac with a range of compilers and libraries for a range of our
1166 configuration options. Every commit in our git source code repository
1167 is currently tested on x86 with gcc versions ranging from 4.6 through
1168 5.1, and versions 14 and 15 of the Intel compiler as well as Clang
1169 version 3.4 through 3.6. For this, we use a variety of GNU/Linux
1170 flavors and versions as well as recent versions of Mac OS X and Windows. Under
1171 Windows we test both MSVC and the Intel compiler. For details, you can
1172 have a look at the `continuous integration server used by GROMACS`_,
1173 which runs Jenkins_.
1175 We test irregularly on ARM v7, ARM v8, BlueGene/Q, Cray, Fujitsu
1176 PRIMEHPC, Power8, Google Native Client and other environments, and
1177 with other compilers and compiler versions, too.
biod.pnpi.spb.ru / alexxy / gromacs.git / blob