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