remove legacy CUDA non-bonded kernels
[alexxy/gromacs.git] / manual / install.tex
1 % This file is part of the GROMACS molecular simulation package.
2 %
3 % Copyright (c) 2013, by the GROMACS development team, led by
4 % David van der Spoel, Berk Hess, Erik Lindahl, and including many
5 % others, as listed in the AUTHORS file in the top-level source
6 % directory and at http://www.gromacs.org.
7 %
8 % GROMACS is free software; you can redistribute it and/or
9 % modify it under the terms of the GNU Lesser General Public License
10 % as published by the Free Software Foundation; either version 2.1
11 % of the License, or (at your option) any later version.
12 %
13 % GROMACS is distributed in the hope that it will be useful,
14 % but WITHOUT ANY WARRANTY; without even the implied warranty of
15 % MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
16 % Lesser General Public License for more details.
17 %
18 % You should have received a copy of the GNU Lesser General Public
19 % License along with GROMACS; if not, see
20 % http://www.gnu.org/licenses, or write to the Free Software Foundation,
21 % Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA.
22 %
23 % If you want to redistribute modifications to GROMACS, please
24 % consider that scientific software is very special. Version
25 % control is crucial - bugs must be traceable. We will be happy to
26 % consider code for inclusion in the official distribution, but
27 % derived work must not be called official GROMACS. Details are found
28 % in the README & COPYING files - if they are missing, get the
29 % official version at http://www.gromacs.org.
30 %
31 % To help us fund GROMACS development, we humbly ask that you cite
32 % the research papers on the package. Check out http://www.gromacs.org
33
34 \chapter{Technical Details}
35 \label{ch:install}
36 \section{Installation}
37 The entire {\gromacs} package is Free Software, licensed under the GNU
38 Lesser General Public License; either version 2.1 of the License, or
39 (at your option) any later version.
40 The main distribution site is our WWW server at {\wwwpage}. 
41
42 The package is mainly distributed as source code, but others provide
43 packages for Linux and Mac. Check your Linux distribution tools
44 (search for gromacs). On Mac OS X the {\bf port} tool will allow you
45 to install a recent version.
46 On the home page you will find all the information you need to 
47 \normindex{install} the package, mailing lists with archives,
48 and several additional on-line resources like contributed topologies, etc.
49 %% The default installation action is simply to unpack the source code and
50 %% then issue:
51 %% \begin{verbatim}
52 %% ./configure
53 %% make
54 %% make install
55 %% \end{verbatim}
56 %% The configuration script should automatically determine the best options
57 %% for your platform, and it will tell you if anything is missing on
58 %% your system. You will also find detailed step-by-step installation
59 %% instructions on the website. There is a \normindex{cmake} based
60 %% installation route as well:
61 %% \begin{verbatim}
62 %% cmake
63 %% make
64 %% make install
65 %% \end{verbatim}
66 %% which is being tested in the wild since {\gromacs} version 4.5.
67
68 \section{Single or Double precision}
69 {\gromacs} can be compiled in either single\index{single
70 precision|see{precision, single}}\index{precision, single} or
71 \pawsindex{double}{precision}. It is very important to note here that
72 single precision is actually mixed precision. Using single precision
73 for all variables would lead to a significant reduction in accuracy.
74 Although in single precision all state vectors, i.e. particle coordinates,
75 velocities and forces, are stored in single precision, critical variables
76 are double precision. A typical example of the latter is the virial,
77 which is a sum over all forces in the system, which have varying signs.
78 In addition, in many parts of the code we managed to avoid double precision
79 for arithmetic, by paying attention to summation order or reorganization
80 of mathematical expressions. The default choice is single precision,
81 but it is easy to turn on double precision by adding the option
82 {\tt -DGMX_DOUBLE=on} to {\tt cmake}. Double precision
83 will be 20 to 100\% slower than single precision depending on the
84 architecture you are running on. Double precision will use somewhat
85 more memory and run input, energy and full-precision trajectory files
86 will be almost twice as large.  SIMD (single-instruction multiple-data)
87 intrinsics non-bonded force and/or energy kernels are available for x86
88 hardware in single and double precision in different SSE and AVX flavors;
89 the minimum requirement is SSE2.
90 IBM Blue Gene Q intrinsics will be available soon. Some other parts of
91 the code, especially PME, also employ x86 SIMD intrinsics. All other
92 hardware will use optimized C kernels. The Verlet non-bonded scheme
93 uses SIMD non-bonded kernels that are C pre-processor macro driven,
94 therefore it is straightforward to implement SIMD acceleration
95 for new architectures; a guide is provided on {\wwwpage}.
96
97 The energies in single precision are accurate up to the last decimal,
98 the last one or two decimals of the forces are non-significant.
99 The virial is less accurate than the forces, since the virial is only one
100 order of magnitude larger than the size of each element in the sum over
101 all atoms (\secref{virial}).
102 In most cases this is not really a problem, since the fluctuations in the
103 virial can be two orders of magnitude larger than the average.
104 Using cut-offs for the Coulomb interactions cause large errors
105 in the energies, forces, and virial.
106 Even when using a reaction-field or lattice sum method, the errors
107 are larger than, or comparable to, the errors due to the single precision.
108 Since MD is chaotic, trajectories with very similar starting conditions will
109 diverge rapidly, the divergence is faster in single precision than in double
110 precision.
111
112 For most simulations single precision is accurate enough.
113 In some cases double precision is required to get reasonable results:
114 \begin{itemize}
115 \item normal mode analysis,
116 for the conjugate gradient or l-bfgs minimization and the calculation and
117 diagonalization of the Hessian
118 \item long-term energy conservation, especially for large systems
119 \end{itemize}
120
121 \section{Porting {\gromacs}}
122 The {\gromacs} system is designed with portability as a major design
123 goal. However there are a number of things we assume to be present on
124 the system {\gromacs} is being ported on. We assume the following
125 features:
126
127 \begin{enumerate}
128 \item   A UNIX-like operating system (BSD 4.x or SYSTEM V rev.3 or higher) 
129         or UNIX-like libraries running under {\eg} Cygwin
130 \item   an ANSI C compiler 
131 \end{enumerate}
132
133 There are some additional features in the package that require extra
134 stuff to be present, but it is checked for in the configuration script
135 and you will be warned if anything important is missing.
136
137 That's the requirements for a single node system. If you want
138 to compile {\gromacs} for running a single simulation across multiple nodes,
139 you also need an MPI library (Message-Passing Interface) to perform the 
140 parallel communication. This is always shipped with supercomputers, and
141 for workstations you can find links to free MPI implementations through
142 the {\gromacs} homepage at {\wwwpage}.
143
144
145 \section{Environment Variables}
146 {\gromacs} programs may be influenced by the use of
147 \normindex{environment variables}.  First of all, the variables set in
148 the {\tt \normindex{GMXRC}} file are essential for running and
149 compiling {\gromacs}. Some other useful environment variables are
150 listed in the following sections. Most environment variables function
151 by being set in your shell to any non-NULL value. Specific
152 requirements are described below if other values need to be set. You
153 should consult the documentation for your shell for instructions on
154 how to set environment variables in the current shell, or in config
155 files for future shells. Note that requirements for exporting
156 environment variables to jobs run under batch control systems vary and
157 you should consult your local documentation for details.
158
159 {\bf Output Control}
160
161 \begin{enumerate}
162
163 \item   {\tt GMX_CONSTRAINTVIR}: print constraint virial and force virial energy terms.
164 \item   {\tt GMX_MAXBACKUP}: {\gromacs} automatically backs up old
165         copies of files when trying to write a new file of the same
166         name, and this variable controls the maximum number of
167         backups that will be made, default 99.
168 \item   {\tt GMX_NO_QUOTES}: if this is explicitly set, no cool quotes
169         will be printed at the end of a program.
170 \item   {\tt GMX_SUPPRESS_DUMP}: prevent dumping of step files during
171         (for example) blowing up during failure of constraint
172         algorithms.
173 \item   {\tt GMX_TPI_DUMP}: dump all configurations to a {\tt .pdb}
174         file that have an interaction energy less than the value set
175         in this environment variable.
176 \item   {\tt GMX_VIEW_XPM}: {\tt GMX_VIEW_XVG}, {\tt
177         GMX_VIEW_EPS} and {\tt GMX_VIEW_PDB}, commands used to
178         automatically view \@ {\tt .xvg}, {\tt .xpm}, {\tt .eps}
179         and {\tt .pdb} file types, respectively; they default to {\tt xv}, {\tt xmgrace},
180         {\tt ghostview} and {\tt rasmol}. Set to empty to disable
181         automatic viewing of a particular file type. The command will
182         be forked off and run in the background at the same priority
183         as the {\gromacs} tool (which might not be what you want).
184         Be careful not to use a command which blocks the terminal
185         ({\eg} {\tt vi}), since multiple instances might be run.
186 \item   {\tt GMX_VIRIAL_TEMPERATURE}: print virial temperature energy term
187 \item   {\tt LOG_BUFS}: the size of the buffer for file I/O. When set
188         to 0, all file I/O will be unbuffered and therefore very slow.
189         This can be handy for debugging purposes, because it ensures
190         that all files are always totally up-to-date.
191 \item   {\tt LOGO}: set display color for logo in {\tt \normindex{ngmx}}.
192 \item   {\tt LONGFORMAT}: use long float format when printing
193         decimal values.
194
195 \end{enumerate}
196
197
198 {\bf Debugging}
199
200 \begin{enumerate}
201
202 \item   {\tt DUMPNL}: dump neighbor list. 
203         If set to a positive number the {\em entire}
204         neighbor list is printed in the log file (may be many megabytes).
205         Mainly for debugging purposes, but may also be handy for
206         porting to other platforms.
207 \item   {\tt WHERE}: when set, print debugging info on line numbers.
208
209 % At this point, all environment variables should be described
210 %\item   There are a number of extra environment variables like these
211 %        that are used in debugging - check the code!
212
213 \end{enumerate}
214
215 {\bf Performance and Run Control}
216
217 \begin{enumerate}
218
219 \item   {\tt DISTGCT}: couple distances between two atoms when doing general coupling
220         theory processes. The format is a string containing two integers, separated by a space.
221 \item   {\tt GALACTIC_DYNAMICS}: planetary simulations are made possible (just for fun) by setting
222         this environment variable, which allows setting {\tt epsilon_r = -1} in the {\tt .mdp}
223         file. Normally, {\tt epsilon_r} must be greater than zero to prevent a fatal error.
224         See {\wwwpage} for example input files for a planetary simulation.
225 \item   {\tt GMX_ALLOW_CPT_MISMATCH}: when set, runs will not exit if the
226         ensemble set in the {\tt .tpr} file does not match that of the
227         {\tt .cpt} file.
228 \item   {\tt GMX_CAPACITY}: the maximum capacity of charge groups per
229         processor when using particle decomposition.
230 \item   {\tt GMX_CUDA_NB_EWALD_TWINCUT}: force the use of twin-range cutoff kernel even if {\tt rvdw} =
231         {\tt rcoulomb} after PP-PME load balancing. The switch to twin-range kernels is automated,
232         so this variable should be used only for benchmarking.
233 \item   {\tt GMX_CUDA_NB_ANA_EWALD}: force the use of analytical Ewald kernels. Should be used only for benchmarking.
234 \item   {\tt GMX_CUDA_NB_TAB_EWALD}: force the use of tabulated Ewald kernels. Should be used only for benchmarking.
235 \item   {\tt GMX_CUDA_STREAMSYNC}: force the use of cudaStreamSynchronize on ECC-enabled GPUs, which leads
236         to performance loss due to a known CUDA driver bug present in API v5.0 NVIDIA drivers (pre-30x.xx).
237         Cannot be set simultaneously with {\tt GMX_NO_CUDA_STREAMSYNC}.
238 \item   {\tt GMX_CYCLE_ALL}: times all code during runs.  Incompatible with threads.
239 \item   {\tt GMX_CYCLE_BARRIER}: calls MPI_Barrier before each cycle start/stop call.
240 \item   {\tt GMX_DD_ORDER_ZYX}: build domain decomposition cells in the order
241         (z, y, x) rather than the default (x, y, z).
242 \item   {\tt GMX_DETAILED_PERF_STATS}: when set, print slightly more detailed performance information
243         to the {\tt .log} file. The resulting output is the way performance summary is reported in versions
244         4.5.x and thus may be useful for anyone using scripts to parse {\tt .log} files or standard output.
245 \item   {\tt GMX_DISABLE_CPU_ACCELERATION}: disables CPU architecture-specific SIMD-optimized (SSE2, SSE4, AVX, etc.)
246         non-bonded kernels thus forcing the use of plain C kernels.
247 \item   {\tt GMX_DISABLE_CUDA_TIMING}: timing of asynchronously executed GPU operations can have a
248         non-negligible overhead with short step times. Disabling timing can improve performance in these cases.
249 \item   {\tt GMX_DISABLE_GPU_DETECTION}: when set, disables GPU detection even if {\tt \normindex{mdrun}} was compiled
250         with GPU support.
251 \item   {\tt GMX_DISABLE_PINHT}: disable pinning of consecutive threads to physical cores when using
252         Intel hyperthreading. Controlled with {\tt \normindex{mdrun} -nopinht} and thus this environment
253         variable will likely be removed.
254 \item   {\tt GMX_DISRE_ENSEMBLE_SIZE}: the number of systems for distance restraint ensemble
255         averaging. Takes an integer value.
256 \item   {\tt GMX_EMULATE_GPU}: emulate GPU runs by using algorithmically equivalent CPU reference code instead of
257         GPU-accelerated functions. As the CPU code is slow, it is intended to be used only for debugging purposes.
258         The behavior is automatically triggered if non-bonded calculations are turned off using {\tt GMX_NO_NONBONDED}
259         case in which the non-bonded calculations will not be called, but the CPU-GPU transfer will also be skipped.
260 \item   {\tt GMX_ENX_NO_FATAL}: disable exiting upon encountering a corrupted frame in an {\tt .edr}
261         file, allowing the use of all frames up until the corruption.
262 \item   {\tt GMX_FORCE_UPDATE}: update forces when invoking {\tt \normindex{mdrun} -rerun}.
263 \item   {\tt GMX_GPU_ID}: set in the same way as the {\tt \normindex{mdrun}} option {\tt -gpu_id}, {\tt GMX_GPU_ID}
264         allows the user to specify different GPU id-s, which can be useful for selecting different
265         devices on different compute nodes in a cluster.  Cannot be used in conjunction with {\tt -gpu_id}.
266 \item   {\tt GMX_IGNORE_FSYNC_FAILURE_ENV}: allow {\tt \normindex{mdrun}} to continue even if
267         a file is missing.
268 \item   {\tt GMX_LJCOMB_TOL}: when set to a floating-point value, overrides the default tolerance of
269         1e-5 for force-field floating-point parameters.
270 \item   {\tt GMX_MAX_MPI_THREADS}: sets the maximum number of MPI-threads that {\tt \normindex{mdrun}}
271         can use.
272 \item   {\tt GMX_MAXCONSTRWARN}: if set to -1, {\tt \normindex{mdrun}} will
273         not exit if it produces too many LINCS warnings.
274 \item   {\tt GMX_NB_GENERIC}: use the generic C kernel.  Should be set if using
275         the group-based cutoff scheme and also sets {\tt GMX_NO_SOLV_OPT} to be true,
276         thus disabling solvent optimizations as well.
277 \item   {\tt GMX_NB_MIN_CI}: neighbor list balancing parameter used when running on GPU. Sets the
278         target minimum number pair-lists in order to improve multi-processor load-balance for better
279         performance with small simulation systems. Must be set to a positive integer, the default value
280         is optimized for NVIDIA Fermi and Kepler GPUs, therefore changing it is not necessary for
281         normal usage, but it can be useful on future architectures.
282 \item   {\tt GMX_NBLISTCG}: use neighbor list and kernels based on charge groups.
283 \item   {\tt GMX_NBNXN_CYCLE}: when set, print detailed neighbor search cycle counting.
284 \item   {\tt GMX_NBNXN_EWALD_ANALYTICAL}: force the use of analytical Ewald non-bonded kernels,
285         mutually exclusive of {\tt GMX_NBNXN_EWALD_TABLE}.
286 \item   {\tt GMX_NBNXN_EWALD_TABLE}: force the use of tabulated Ewald non-bonded kernels,
287         mutually exclusive of {\tt GMX_NBNXN_EWALD_ANALYTICAL}.
288 \item   {\tt GMX_NBNXN_SIMD_2XNN}: force the use of 2x(N+N) SIMD CPU non-bonded kernels,
289         mutually exclusive of {\tt GMX_NBNXN_SIMD_4XN}.
290 \item   {\tt GMX_NBNXN_SIMD_4XN}: force the use of 4xN SIMD CPU non-bonded kernels,
291         mutually exclusive of {\tt GMX_NBNXN_SIMD_2XNN}.
292 \item   {\tt GMX_NO_ALLVSALL}: disables optimized all-vs-all kernels.
293 \item   {\tt GMX_NO_CART_REORDER}: used in initializing domain decomposition communicators. Node reordering
294         is default, but can be switched off with this environment variable.
295 \item   {\tt GMX_NO_CUDA_STREAMSYNC}: the opposite of {\tt GMX_CUDA_STREAMSYNC}. Disables the use of the
296         standard cudaStreamSynchronize-based GPU waiting to improve performance when using CUDA driver API
297         ealier than v5.0 with ECC-enabled GPUs.
298 \item   {\tt GMX_NO_INT}, {\tt GMX_NO_TERM}, {\tt GMX_NO_USR1}: disable signal handlers for SIGINT,
299         SIGTERM, and SIGUSR1, respectively.
300 \item   {\tt GMX_NO_NODECOMM}: do not use separate inter- and intra-node communicators.
301 \item   {\tt GMX_NO_NONBONDED}: skip non-bonded calculations; can be used to estimate the possible
302         performance gain from adding a GPU accelerator to the current hardware setup -- assuming that this is
303         fast enough to complete the non-bonded calculations while the CPU does bonded force and PME computation.
304 \item   {\tt GMX_NO_PULLVIR}: when set, do not add virial contribution to COM pull forces.
305 \item   {\tt GMX_NOCHARGEGROUPS}: disables multi-atom charge groups, {\ie} each atom 
306         in all non-solvent molecules is assigned its own charge group.
307 \item   {\tt GMX_NOPREDICT}: shell positions are not predicted.
308 \item   {\tt GMX_NO_SOLV_OPT}: turns off solvent optimizations; automatic if {\tt GMX_NB_GENERIC}
309         is enabled.
310 \item   {\tt GMX_NSCELL_NCG}: the ideal number of charge groups per neighbor searching grid cell is hard-coded
311         to a value of 10. Setting this environment variable to any other integer value overrides this hard-coded
312         value.
313 \item   {\tt GMX_PME_NTHREADS}: set the number of OpenMP or PME threads (overrides the number guessed by 
314         {\tt \normindex{mdrun}}.
315 \item   {\tt GMX_PME_P3M}: use P3M-optimized influence function instead of smooth PME B-spline interpolation.
316 \item   {\tt GMX_PME_THREAD_DIVISION}: PME thread division in the format ``x y z'' for all three dimensions. The
317         sum of the threads in each dimension must equal the total number of PME threads (set in 
318         {\tt GMX_PME_NTHREADS}).
319 \item   {\tt GMX_PMEONEDD}: if the number of domain decomposition cells is set to 1 for both x and y, 
320         decompose PME in one dimension.
321 \item   {\tt GMX_REQUIRE_SHELL_INIT}: require that shell positions are initiated.
322 \item   {\tt GMX_REQUIRE_TABLES}: require the use of tabulated Coulombic
323         and van der Waals interactions.
324 \item   {\tt GMX_SCSIGMA_MIN}: the minimum value for soft-core $\sigma$. {\bf Note} that this value is set
325         using the {\tt sc-sigma} keyword in the {\tt .mdp} file, but this environment variable can be used
326         to reproduce pre-4.5 behavior with respect to this parameter.
327 \item   {\tt GMX_TPIC_MASSES}: should contain multiple masses used for test particle insertion into a cavity.
328         The center of mass of the last atoms is used for insertion into the cavity.
329 \item   {\tt GMX_USE_GRAPH}: use graph for bonded interactions.
330 \item   {\tt GMX_VERLET_BUFFER_RES}: resolution of buffer size in Verlet cutoff scheme.  The default value is
331         0.001, but can be overridden with this environment variable.
332 \item   {\tt GMX_VERLET_SCHEME}: convert from group-based to Verlet cutoff scheme, even if the {\tt cutoff_scheme} is
333         not set to use Verlet in the {\tt .mdp} file. It is unnecessary since the {\tt -testverlet} option of
334         {\tt \normindex{mdrun}} has the same functionality, but it is maintained for backwards compatibility.
335 \item   {\tt GMXNPRI}: for SGI systems only. When set, gives the default non-degrading priority (npri) 
336         for {\tt \normindex{mdrun}}, {\tt \normindex{g_covar}} and {\tt \normindex{g_nmeig}},
337         {\eg} setting {\tt setenv GMXNPRI 250} causes all runs to be performed at near-lowest priority by default.
338 \item   {\tt GMXNPRIALL}: same as {\tt GMXNPRI}, but for all processes.
339 \item   {\tt MPIRUN}: the {\tt mpirun} command used by {\tt \normindex{g_tune_pme}}.
340 \item   {\tt MDRUN}: the {\tt \normindex{mdrun}} command used by {\tt \normindex{g_tune_pme}}.
341 \item   {\tt GMX_NSTLIST}: sets the default value for {\tt nstlist}, preventing it from being tuned during
342         {\tt \normindex{mdrun}} startup when using the Verlet cutoff scheme.
343
344 \end{enumerate}
345
346 {\bf Analysis and Core Functions}
347
348 \begin{enumerate}
349
350 \item   {\tt ACC}: accuracy in Gaussian L510 (MC-SCF) component program.
351 \item   {\tt BASENAME}: prefix of {\tt .tpr} files, used in Orca calculations
352         for input and output file names.
353 \item   {\tt CPMCSCF}: when set to a nonzero value, Gaussian QM calculations will
354         iteratively solve the CP-MCSCF equations.
355 \item   {\tt DEVEL_DIR}: location of modified links in Gaussian.
356 \item   {\tt DSSP}: used by {\tt \normindex{do_dssp}} to point to the {\tt dssp}
357         executable (not just its path).
358 \item   {\tt GAUSS_DIR}: directory where Gaussian is installed.
359 \item   {\tt GAUSS_EXE}: name of the Gaussian executable.
360 \item   {\tt GKRWIDTH}: spacing used by {\tt \normindex{g_dipoles}}.
361 \item   {\tt GMX_MAXRESRENUM}: sets the maximum number of residues to be renumbered by
362         {\tt \normindex{grompp}}. A value of -1 indicates all residues should be renumbered.
363 \item   {\tt GMX_FFRTP_TER_RENAME}: Some force fields (like AMBER) use specific names for N- and C-
364         terminal residues (NXXX and CXXX) as {\tt .rtp} entries that are normally renamed. Setting
365         this environment variable disables this renaming.
366 \item   {\tt GMX_PATH_GZIP}: {\tt gunzip} executable, used by {\tt \normindex{g_wham}}.
367 \item   {\tt GMXFONT}: name of X11 font used by {\tt \normindex{ngmx}}.
368 \item   {\tt GMXTIMEUNIT}: the time unit used in output files, can be
369         anything in fs, ps, ns, us, ms, s, m or h.
370 \item   {\tt MEM}: memory used for Gaussian QM calculation.
371 \item   {\tt MULTIPROT}: name of the {\tt multiprot} executable, used by the
372         contributed program {\tt \normindex{do_multiprot}}.
373 \item   {\tt NCPUS}: number of CPUs to be used for Gaussian QM calculation
374 \item   {\tt OPENMM_PLUGIN_DIR}: the location of OpenMM plugins, needed for
375         {\tt \normindex{mdrun-gpu}}.
376 \item   {\tt ORCA_PATH}: directory where Orca is installed.
377 \item   {\tt SASTEP}: simulated annealing step size for Gaussian QM calculation.
378 \item   {\tt STATE}: defines state for Gaussian surface hopping calculation.
379 \item   {\tt TESTMC}: perform 1000 random swaps in Monte Carlo clustering method
380         within {\tt \normindex{g_cluster}}.
381 \item   {\tt TOTAL}: name of the {\tt total} executable used by the contributed
382         {\tt \normindex{do_shift}} program.
383 \item   {\tt VERBOSE}: make {\tt \normindex{g_energy}} and {\tt \normindex{eneconv}}
384         loud and noisy.
385 \item   {\tt VMD_PLUGIN_PATH}: where to find VMD plug-ins. Needed to be
386         able to read file formats recognized only by a VMD plug-in.
387 \item   {\tt VMDDIR}: base path of VMD installation.
388 \item   {\tt XMGR}: sets viewer to {\tt xmgr} (deprecated) instead of {\tt xmgrace}.
389
390 \end{enumerate}
391
392 \section{Running {\gromacs} in parallel}
393 By default {\gromacs} will be compiled with the built-in threaded MPI library.
394 This library supports MPI communication between threads instead of between
395 processes. To run {\gromacs} in parallel over multiple nodes in a cluster
396 of a supercomputer, you need to configure and compile {\gromacs} with an external
397 MPI library. All supercomputers are shipped with MPI libraries optimized for 
398 that particular platform, and if you are using a cluster of workstations
399 there are several good free MPI implementations;
400 Open MPI is usually a good choice. Once you have an MPI library
401 installed it's trivial to compile {\gromacs} with MPI support: Just pass
402 the option {\tt -DGMX_MPI=on} to {\tt cmake} and (re-)compile. Please see
403 {\wwwpage} for more detailed instructions.
404 Note that in addition to MPI parallelization, {\gromacs} supports
405 thread-parallelization through \normindex{OpenMP}. MPI and OpenMP parallelization
406 can be combined, which results in, so called, hybrid parallelization.
407 See {\wwwpage} for details on use and performance of the parallelization
408 schemes.
409
410 For communications over multiple nodes connected by a network,
411 there is a program usually called {\tt mpirun} with which you can start 
412 the parallel processes. A typical command line could look like:
413 {\tt mpirun -np 10 mdrun_mpi -s topol -v}
414
415 With the implementation of threading available by default in {\gromacs} version 4.5, 
416 if you have a single machine with multiple processors you don't have to
417 use the {\tt mpirun} command, or compile with MPI. Instead, you can
418 allow {\gromacs} to determine the number of threads automatically, or use the {\tt mdrun} option {\tt -nt}:
419 {\tt mdrun -nt 8 -s topol.tpr}
420
421 Check your local manuals (or online manual) for exact details
422 of your MPI implementation.
423
424 If you are interested in programming MPI yourself, you can find
425 manuals and reference literature on the internet.
426
427
428 \section{Running {\gromacs} on \normindex{GPUs}}
429 As of version 4.6, {\gromacs} has native GPU support through CUDA.
430 Note that {\gromacs} only off-loads the most compute intensive parts
431 to the GPU, currently the non-bonded interactions, and does all other
432 parts of the MD calculation on the CPU. The requirements for the CUDA code
433 are an Nvidia GPU with compute capability $\geq 2.0$, i.e. at
434 least Fermi class.
435 In many cases {\tt cmake} can auto-detect GPUs and the support will be
436 configured automatically. To be sure GPU support is configured, pass
437 the {\tt -DGMX_GPU=on} option to {\tt cmake}. The actual use of GPUs
438 is decided at run time by {\tt mdrun}, depending on the availability
439 of (suitable) GPUs and on the run input settings. A binary compiled
440 with GPU support can also run CPU only simulations. Use {\tt mdrun -nb cpu}
441 to force a simulation to run on CPUs only. Only simulations with the Verlet
442 cut-off scheme will run on a GPU. To test performance of old tpr files
443 with GPUs, you can use the {\tt -testverlet} option of {\tt mdrun},
444 but as this doesn't do the full parameter consistency check of {\tt grommp},
445 you should not use this option for production simulations.
446 Getting good performance with {\gromacs} on GPUs is easy,
447 but getting best performance can be difficult.
448 Please check {\wwwpage} for up to date information on GPU usage.
449
450 % LocalWords:  Opteron Itanium PowerPC Altivec Athlon Fortran virial bfgs Nasm
451 % LocalWords:  diagonalization Cygwin MPI Multi GMXHOME extern gmx tx pid buf
452 % LocalWords:  bufsize txs rx rxs init nprocs fp msg GMXRC DUMPNL BUFS GMXNPRI
453 % LocalWords:  unbuffered SGI npri mdrun covar nmeig setenv XPM XVG EPS
454 % LocalWords:  PDB xvg xpm eps pdb xmgrace ghostview rasmol GMXTIMEUNIT fs dssp
455 % LocalWords:  mpi distclean ing mpirun goofus doofus fred topol np
456 % LocalWords:  internet gromacs DGMX cmake SIMD intrinsics AVX PME XN
457 % LocalWords:  Verlet pre config CONSTRAINTVIR MAXBACKUP TPI ngmx mdp
458 % LocalWords:  LONGFORMAT DISTGCT CPT tpr cpt CUDA EWALD TWINCUT rvdw
459 % LocalWords:  rcoulomb STREAMSYNC cudaStreamSynchronized ECC GPUs sc
460 % LocalWords:  ZYX PERF GPU PINHT hyperthreading DISRE NONBONDED ENX
461 % LocalWords:  edr ENER gpu FSYNC ENV LJCOMB TOL MAXCONSTRWARN LINCS
462 % LocalWords:  SOLV NBLISTCG NBNXN XNN ALLVSALL cudaStreamSynchronize
463 % LocalWords:  USR SIGINT SIGTERM SIGUSR NODECOMM intra PULLVIR multi
464 % LocalWords:  NOCHARGEGROUPS NOPREDICT NSCELL NCG NTHREADS OpenMP CP
465 % LocalWords:  PMEONEDD Coulombic der Waals SCSIGMA TPIC GMXNPRIALL
466 % LocalWords:  GOMP KMP pme NSTLIST ENVVAR nstlist startup OMP NUM ps
467 % LocalWords:  ACC SCF BASENAME Orca CPMCSCF MCSCF DEVEL EXE GKRWIDTH
468 % LocalWords:  MAXRESRENUM grompp FFRTP TER NXXX CXXX rtp GZIP gunzip
469 % LocalWords:  GMXFONT ns MEM MULTIPROT multiprot NCPUS CPUs OPENMM
470 % LocalWords:  PLUGIN OpenMM plugins SASTEP TESTMC eneconv VMD VMDDIR
471 % LocalWords:  XMGR xmgr parallelization nt online Nvidia nb cpu
472 % LocalWords:  testverlet grommp