Renamed former user manual to reference manual.
The content for the new user guide has mostly migrated in from the
wiki, install guide, and mdrun -h, and updated as appropriate. This
guide is intended for documenting practical use, whereas the reference
manual should document algorithms and high-level implementations, etc.
Established references.md to do automatic linking of frequently
used things. This can be automatically concatenated by pandoc
onto any Markdown file to do easy link generation.
Section on mdrun and performance imported and enhanced from the
Acceleration and Parallelization wiki page.
Added section on mdrun features, e.g. rerun and multi-simulation.
Section on getting started imported from online/getting_started.html
and updated - there used to be a tutorial here, but there isn't any
more. Linked to more up-to-date tutorials.
Added TNG to docs/manual/files.tex.
Removed gmx options, now that its content is in the user guide (in
tools.md).
Moved old mdp_opt.html to docs/mdp-options.html, for now. Removed from
reference manual, left pointer to new location. This is not an ideal
format or location either, but it's a step closer to being able to
generate it from the code. Some trivial fixes to content. Generating
links and references to follow in a future commit.
Moved environment-variable section from reference manual to user guide.
Minor fixes here.
Removed superseded reference manual sections on running in parallel or
with GPUs. Renamed install.tex as technical-details.tex, because that
is all that is left there. Moved section on use of floating-point
precision to chapter on definitions and units, and thus eliminated the
former Appendix A.
Cross-references from user-guide.pdf don't work well yet, but that
should be dealt with when we decide on the final publishing platform.
Some TODO comments for documentation sections remain for work in
future patches, but please note the other new content in existing
child patches, so we don't duplicate any work.
Change-Id: I026d67353863ae069c6c45b840a61fcaf205a377
As [PDF](install-guide.pdf)
* [User Guide](user-guide.html)
+ Includes getting started, .mdp options, advice using mdrun and more.
As [PDF](user-guide.pdf)
* [Online Reference](online.html)
#
# This file is part of the GROMACS molecular simulation package.
#
-# Copyright (c) 2013,2014, by the GROMACS development team, led by
+# Copyright (c) 2013,2014,2015, by the GROMACS development team, led by
# Mark Abraham, David van der Spoel, Berk Hess, and Erik Lindahl,
# and including many others, as listed in the AUTHORS file in the
# top-level source directory and at http://www.gromacs.org.
#
# Only files that can be built should be listed in DEPENDS. Makefile
# rules are generated for those files.
- #
- # The .mdp options section is now intended to be built directly
- # from a GROMACS source directory. This facilitates drafting
- # updates in that HTML file without copying files by hand.
-
- ADD_CUSTOM_COMMAND(OUTPUT ${output_dir}/mdp_opt.tex
- COMMAND ${CMAKE_CURRENT_SOURCE_DIR}/mkmdp ARGS ${CMAKE_CURRENT_SOURCE_DIR}/../old-html
- DEPENDS mkmdp ${CMAKE_CURRENT_SOURCE_DIR}/../old-html/online/mdp_opt.html
- )
# Finally, the command to build the manual.
ADD_LATEX_DOCUMENT(gromacs.tex
# Normal LaTeX \included files
INPUTS algorithms.tex defunits.tex implement.tex macros.tex special.tex
- analyse.tex files.tex install.tex topology.tex
+ analyse.tex files.tex topology.tex
averages.tex forcefield.tex gromacs.tex intro.tex programs.tex
# CMake does variable replacement in these files
CONFIGURE macros.tex
- # These files we're responsible for creating in the
- # add_custom_targets() above. They should not be in the git
- # repository, or its directory, or the dependencies will not work
- # properly.
- DEPENDS mdp_opt.tex
-
BIBFILES monster.bib unpubl.bib
IMAGE_DIRS plots
DEFAULT_PDF
%
% This file is part of the GROMACS molecular simulation package.
%
-% Copyright (c) 2013,2014, by the GROMACS development team, led by
+% Copyright (c) 2013,2014,2015, by the GROMACS development team, led by
% Mark Abraham, David van der Spoel, Berk Hess, and Erik Lindahl,
% and including many others, as listed in the AUTHORS file in the
% top-level source directory and at http://www.gromacs.org.
be excluded\index{exclusions}
\ifthenelse{\equal{\gmxlite}{1}}
{.}
-{(see \secref{mdpopt}).}
+{(see details in the User Guide).}
Pairs of particles from excluded pairs of energy-monitor groups
are not put into the pair list.
This can result in a significant speedup
{\gromacs} can also write reduced-precision coordinates for a subset of
the simulation system to a special compressed trajectory file
format. All the other tools can read and write this format. See
-\secref{mdpopt} for details on how to set up your {\tt .mdp} file
+the User Guide for details on how to set up your {\tt .mdp} file
to have {\tt mdrun} use this feature.
% \ifthenelse{\equal{\gmxlite}{1}}{}{
% LocalWords: GROningen MAchine BIOSON Groningen GROMACS Berendsen der Spoel
% LocalWords: Drunen Comp Phys Comm ROck NS FFT pbc EM ifthenelse gmxlite ff
% LocalWords: octahedra triclinic Ewald PME PPPM trjconv xy solvated
-% LocalWords: boxtypes boxshapes editconf Lennard mdpopt COM XTC TNG kT defunits
+% LocalWords: boxtypes boxshapes editconf Lennard COM XTC TNG kT defunits
% LocalWords: Boltzmann's Mueller nb int mdrun chargegroup simplerc prefactor
% LocalWords: pme waterloops CH NH CO df com virial integrator Verlet vverlet
% LocalWords: integrators ref timepoint timestep timesteps mdp md vv avek NVE
%
% This file is part of the GROMACS molecular simulation package.
%
-% Copyright (c) 2013,2014, by the GROMACS development team, led by
+% Copyright (c) 2013,2014,2015, by the GROMACS development team, led by
% Mark Abraham, David van der Spoel, Berk Hess, and Erik Lindahl,
% and including many others, as listed in the AUTHORS file in the
% top-level source directory and at http://www.gromacs.org.
\end{table}
+\section{Mixed or Double precision}
+{\gromacs} can be compiled in either mixed\index{mixed
+precision|see{precision, mixed}}\index{precision, mixed} or
+\pawsindex{double}{precision}. Documentation of previous {\gromacs}
+versions referred to ``single precision'', but the implementation
+has made selective use of double precision for many years.
+Using single precision
+for all variables would lead to a significant reduction in accuracy.
+Although in ``mixed precision'' all state vectors, i.e. particle coordinates,
+velocities and forces, are stored in single precision, critical variables
+are double precision. A typical example of the latter is the virial,
+which is a sum over all forces in the system, which have varying signs.
+In addition, in many parts of the code we managed to avoid double precision
+for arithmetic, by paying attention to summation order or reorganization
+of mathematical expressions. The default configuration uses mixed precision,
+but it is easy to turn on double precision by adding the option
+{\tt -DGMX_DOUBLE=on} to {\tt cmake}. Double precision
+will be 20 to 100\% slower than mixed precision depending on the
+architecture you are running on. Double precision will use somewhat
+more memory and run input, energy and full-precision trajectory files
+will be almost twice as large.
+
+The energies in mixed precision are accurate up to the last decimal,
+the last one or two decimals of the forces are non-significant.
+The virial is less accurate than the forces, since the virial is only one
+order of magnitude larger than the size of each element in the sum over
+all atoms (\secref{virial}).
+In most cases this is not really a problem, since the fluctuations in the
+virial can be two orders of magnitude larger than the average.
+Using cut-offs for the Coulomb interactions cause large errors
+in the energies, forces, and virial.
+Even when using a reaction-field or lattice sum method, the errors
+are larger than, or comparable to, the errors due to the partial use of
+single precision.
+Since MD is chaotic, trajectories with very similar starting conditions will
+diverge rapidly, the divergence is faster in mixed precision than in double
+precision.
+
+For most simulations, mixed precision is accurate enough.
+In some cases double precision is required to get reasonable results:
+\begin{itemize}
+\item normal mode analysis,
+for the conjugate gradient or l-bfgs minimization and the calculation and
+diagonalization of the Hessian
+\item long-term energy conservation, especially for large systems
+\end{itemize}
+
+
% LocalWords: ij basicunits derivedunits kJ mol mV kcal consts LJ BT
% LocalWords: nm ps
%
% This file is part of the GROMACS molecular simulation package.
%
-% Copyright (c) 2013,2014, by the GROMACS development team, led by
+% Copyright (c) 2013,2014,2015, by the GROMACS development team, led by
% Mark Abraham, David van der Spoel, Berk Hess, and Erik Lindahl,
% and including many others, as listed in the AUTHORS file in the
% top-level source directory and at http://www.gromacs.org.
\tt traj & \tt trr & & \tt & Full precision trajectory: \tt trr cpt \\[-0.1ex]
\tt traj & \tt trr & xdr & \tt & Trajectory in portable xdr format \\[-0.1ex]
\tt root & \tt xpm & Asc & \tt & X PixMap compatible matrix file \\[-0.1ex]
-\tt traj & \tt xtc & & \tt -f & Trajec., input: \tt xtc trr cpt gro g96 pdb \\[-0.1ex]
-\tt traj & \tt xtc & & \tt -f & Trajectory, output: \tt xtc trr gro g96 pdb \\[-0.1ex]
+\tt traj & \tt xtc & & \tt -f & Trajec., input: \tt xtc trr tng cpt gro g96 pdb \\[-0.1ex]
+\tt traj & \tt xtc & & \tt -f & Trajectory, output: \tt xtc trr tng gro g96 pdb \\[-0.1ex]
\tt traj & \tt xtc & xdr & \tt & Compressed trajectory (portable xdr format) \\[-0.1ex]
\tt graph & \tt xvg & Asc & \tt -o & xvgr/xmgr file \\[-0.1ex]
\dline
%
% This file is part of the GROMACS molecular simulation package.
%
-% Copyright (c) 2013,2014, by the GROMACS development team, led by
+% Copyright (c) 2013,2014,2015, by the GROMACS development team, led by
% Mark Abraham, David van der Spoel, Berk Hess, and Erik Lindahl,
% and including many others, as listed in the AUTHORS file in the
% top-level source directory and at http://www.gromacs.org.
For both Coulomb and van der Waals interactions there are interaction
type selectors (termed {\tt vdwtype} and {\tt coulombtype}) and two
parameters, for a total of six non-bonded interaction parameters. See
-\secref{mdpopt} for a complete description of these parameters.
+the User Guide for a complete description of these parameters.
The neighbor searching (NS) can be performed using a single-range, or a twin-range
approach. Since the former is merely a special case of the latter, we will
% LocalWords: fc ravdisre nstdisreout dipolar lll ccc orientational MSD const
% LocalWords: orire fitgrp nstorireout Drude intra Noskov et al fecalc coulrf
% LocalWords: polarizabilities parameterized sigeps Ek sc softcore GROMOS NBF
-% LocalWords: hydrogens alkane vdwtype coulombtype mdpopt rlist rcoulomb rvdw
+% LocalWords: hydrogens alkane vdwtype coulombtype rlist rcoulomb rvdw
% LocalWords: nstlist virial funcparm VdW jk jl fvsite fd vsites lcr vsitetop
% LocalWords: vsite lclllll lcl parameterize parameterization enercorr avcsix
% LocalWords: pcorr ecorr totalcoulomb dir fourierspacing ewald rtol Darden gz
%
% This file is part of the GROMACS molecular simulation package.
%
-% Copyright (c) 2013,2014, by the GROMACS development team, led by
+% Copyright (c) 2013,2014,2015, by the GROMACS development team, led by
% Mark Abraham, David van der Spoel, Berk Hess, and Erik Lindahl,
% and including many others, as listed in the AUTHORS file in the
% top-level source directory and at http://www.gromacs.org.
\ifthenelse{\equal{\gmxlite}{1}}
{
-\fcolorbox{blue}{blue}{\textcolor{white}{\fontsize{56}{64} \selectfont User Manual {\em ~Lite~}}}
+\fcolorbox{blue}{blue}{\textcolor{white}{\fontsize{56}{64} \selectfont Reference Manual {\em ~Lite~}}}
}
{
-\fcolorbox{blue}{blue}{\textcolor{white}{\fontsize{56}{64} \selectfont ~USER MANUAL~}}
+\fcolorbox{blue}{blue}{\textcolor{white}{\fontsize{56}{64} \selectfont ~Reference Manual~}}
} % Brace matches ifthenelse test for gmxlite
\vspace{4mm}
\vspace{1cm}
{\fontsize{40}{50} \selectfont
GROMACS\\
-USER MANUAL\\[1cm]
+Reference Manual\\[1cm]
}
{\LARGE\bf Version \gmxver}\\[1cm]
% A P P E N D I C E S
%
\appendix
-\include{install}
+\include{technical}
\include{implement}
\include{averages}
} % Brace matches ifthenelse test for gmxlite
+++ /dev/null
-%
-% This file is part of the GROMACS molecular simulation package.
-%
-% Copyright (c) 2013,2014,2015, by the GROMACS development team, led by
-% Mark Abraham, David van der Spoel, Berk Hess, and Erik Lindahl,
-% and including many others, as listed in the AUTHORS file in the
-% top-level source directory and at http://www.gromacs.org.
-%
-% GROMACS is free software; you can redistribute it and/or
-% modify it under the terms of the GNU Lesser General Public License
-% as published by the Free Software Foundation; either version 2.1
-% of the License, or (at your option) any later version.
-%
-% GROMACS is distributed in the hope that it will be useful,
-% but WITHOUT ANY WARRANTY; without even the implied warranty of
-% MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-% Lesser General Public License for more details.
-%
-% You should have received a copy of the GNU Lesser General Public
-% License along with GROMACS; if not, see
-% http://www.gnu.org/licenses, or write to the Free Software Foundation,
-% Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
-%
-% If you want to redistribute modifications to GROMACS, please
-% consider that scientific software is very special. Version
-% control is crucial - bugs must be traceable. We will be happy to
-% consider code for inclusion in the official distribution, but
-% derived work must not be called official GROMACS. Details are found
-% in the README & COPYING files - if they are missing, get the
-% official version at http://www.gromacs.org.
-%
-% To help us fund GROMACS development, we humbly ask that you cite
-% the research papers on the package. Check out http://www.gromacs.org.
-
-\chapter{Technical Details}
-
-\section{Mixed or Double precision}
-{\gromacs} can be compiled in either mixed\index{mixed
-precision|see{precision, mixed}}\index{precision, mixed} or
-\pawsindex{double}{precision}. Documentation of previous {\gromacs}
-versions referred to ``single precision'', but the implementation
-has made selective use of double precision for many years.
-Using single precision
-for all variables would lead to a significant reduction in accuracy.
-Although in ``mixed precision'' all state vectors, i.e. particle coordinates,
-velocities and forces, are stored in single precision, critical variables
-are double precision. A typical example of the latter is the virial,
-which is a sum over all forces in the system, which have varying signs.
-In addition, in many parts of the code we managed to avoid double precision
-for arithmetic, by paying attention to summation order or reorganization
-of mathematical expressions. The default configuration uses mixed precision,
-but it is easy to turn on double precision by adding the option
-{\tt -DGMX_DOUBLE=on} to {\tt cmake}. Double precision
-will be 20 to 100\% slower than mixed precision depending on the
-architecture you are running on. Double precision will use somewhat
-more memory and run input, energy and full-precision trajectory files
-will be almost twice as large.
-
-The energies in mixed precision are accurate up to the last decimal,
-the last one or two decimals of the forces are non-significant.
-The virial is less accurate than the forces, since the virial is only one
-order of magnitude larger than the size of each element in the sum over
-all atoms (\secref{virial}).
-In most cases this is not really a problem, since the fluctuations in the
-virial can be two orders of magnitude larger than the average.
-Using cut-offs for the Coulomb interactions cause large errors
-in the energies, forces, and virial.
-Even when using a reaction-field or lattice sum method, the errors
-are larger than, or comparable to, the errors due to the partial use of
-single precision.
-Since MD is chaotic, trajectories with very similar starting conditions will
-diverge rapidly, the divergence is faster in mixed precision than in double
-precision.
-
-For most simulations, mixed precision is accurate enough.
-In some cases double precision is required to get reasonable results:
-\begin{itemize}
-\item normal mode analysis,
-for the conjugate gradient or l-bfgs minimization and the calculation and
-diagonalization of the Hessian
-\item long-term energy conservation, especially for large systems
-\end{itemize}
-
-\section{Environment Variables}
-{\gromacs} programs may be influenced by the use of
-\normindex{environment variables}. First of all, the variables set in
-the {\tt \normindex{GMXRC}} file are essential for running and
-compiling {\gromacs}. Some other useful environment variables are
-listed in the following sections. Most environment variables function
-by being set in your shell to any non-NULL value. Specific
-requirements are described below if other values need to be set. You
-should consult the documentation for your shell for instructions on
-how to set environment variables in the current shell, or in config
-files for future shells. Note that requirements for exporting
-environment variables to jobs run under batch control systems vary and
-you should consult your local documentation for details.
-
-{\bf Output Control}
-
-\begin{enumerate}
-
-\item {\tt GMX_CONSTRAINTVIR}: print constraint virial and force virial energy terms.
-\item {\tt GMX_MAXBACKUP}: {\gromacs} automatically backs up old
- copies of files when trying to write a new file of the same
- name, and this variable controls the maximum number of
- backups that will be made, default 99. If set to 0 it fails to
- run if any output file already exists. And if set to -1 it
- overwrites any output file without making a backup.
-\item {\tt GMX_NO_QUOTES}: if this is explicitly set, no cool quotes
- will be printed at the end of a program.
-\item {\tt GMX_SUPPRESS_DUMP}: prevent dumping of step files during
- (for example) blowing up during failure of constraint
- algorithms.
-\item {\tt GMX_TPI_DUMP}: dump all configurations to a {\tt .pdb}
- file that have an interaction energy less than the value set
- in this environment variable.
-\item {\tt GMX_VIEW_XPM}: {\tt GMX_VIEW_XVG}, {\tt
- GMX_VIEW_EPS} and {\tt GMX_VIEW_PDB}, commands used to
- automatically view \@ {\tt .xvg}, {\tt .xpm}, {\tt .eps}
- and {\tt .pdb} file types, respectively; they default to {\tt xv}, {\tt xmgrace},
- {\tt ghostview} and {\tt rasmol}. Set to empty to disable
- automatic viewing of a particular file type. The command will
- be forked off and run in the background at the same priority
- as the {\gromacs} tool (which might not be what you want).
- Be careful not to use a command which blocks the terminal
- ({\eg} {\tt vi}), since multiple instances might be run.
-\item {\tt GMX_VIRIAL_TEMPERATURE}: print virial temperature energy term
-\item {\tt GMX_LOG_BUFFER}: the size of the buffer for file I/O. When set
- to 0, all file I/O will be unbuffered and therefore very slow.
- This can be handy for debugging purposes, because it ensures
- that all files are always totally up-to-date.
-\item {\tt GMX_LOGO_COLOR}: set display color for logo in {\tt \normindex{ngmx}}.
-\item {\tt GMX_PRINT_LONGFORMAT}: use long float format when printing
- decimal values.
-\item {\tt GMX_COMPELDUMP}: Applies for computational electrophysiology setups
- only (see section \ref{sec:compel}). The initial structure gets dumped to
- {\tt .pdb} file, which allows to check whether multimeric channels have
- the correct PBC representation.
-\end{enumerate}
-
-
-{\bf Debugging}
-
-\begin{enumerate}
-
-\item {\tt GMX_PRINT_DEBUG_LINES}: when set, print debugging info on line numbers.
-\item {\tt GMX_DD_NST_DUMP}: number of steps that elapse between dumping
- the current DD to a PDB file (default 0). This only takes effect
- during domain decomposition, so it should typically be
- 0 (never), 1 (every DD phase) or a multiple of {\tt nstlist}.
-\item {\tt GMX_DD_NST_DUMP_GRID}: number of steps that elapse between dumping
- the current DD grid to a PDB file (default 0). This only takes effect
- during domain decomposition, so it should typically be
- 0 (never), 1 (every DD phase) or a multiple of {\tt nstlist}.
-\item {\tt GMX_DD_DEBUG}: general debugging trigger for every domain
- decomposition (default 0, meaning off). Currently only checks
- global-local atom index mapping for consistency.
-\item {\tt GMX_DD_NPULSE}: over-ride the number of DD pulses used
- (default 0, meaning no over-ride). Normally 1 or 2.
-
-%\item There are a number of extra environment variables like these
-% that are used in debugging - check the code!
-
-\end{enumerate}
-
-{\bf Performance and Run Control}
-
-\begin{enumerate}
-
-\item {\tt GMX_DO_GALACTIC_DYNAMICS}: planetary simulations are made possible (just for fun) by setting
- this environment variable, which allows setting {\tt epsilon_r = -1} in the {\tt .mdp}
- file. Normally, {\tt epsilon_r} must be greater than zero to prevent a fatal error.
- See {\wwwpage} for example input files for a planetary simulation.
-\item {\tt GMX_ALLOW_CPT_MISMATCH}: when set, runs will not exit if the
- ensemble set in the {\tt .tpr} file does not match that of the
- {\tt .cpt} file.
-\item {\tt GMX_CUDA_NB_EWALD_TWINCUT}: force the use of twin-range cutoff kernel even if {\tt rvdw} =
- {\tt rcoulomb} after PP-PME load balancing. The switch to twin-range kernels is automated,
- so this variable should be used only for benchmarking.
-\item {\tt GMX_CUDA_NB_ANA_EWALD}: force the use of analytical Ewald kernels. Should be used only for benchmarking.
-\item {\tt GMX_CUDA_NB_TAB_EWALD}: force the use of tabulated Ewald kernels. Should be used only for benchmarking.
-\item {\tt GMX_CUDA_STREAMSYNC}: force the use of cudaStreamSynchronize on ECC-enabled GPUs, which leads
- to performance loss due to a known CUDA driver bug present in API v5.0 NVIDIA drivers (pre-30x.xx).
- Cannot be set simultaneously with {\tt GMX_NO_CUDA_STREAMSYNC}.
-\item {\tt GMX_CYCLE_ALL}: times all code during runs. Incompatible with threads.
-\item {\tt GMX_CYCLE_BARRIER}: calls MPI_Barrier before each cycle start/stop call.
-\item {\tt GMX_DD_ORDER_ZYX}: build domain decomposition cells in the order
- (z, y, x) rather than the default (x, y, z).
-\item {\tt GMX_DD_USE_SENDRECV2}: during constraint and vsite communication, use a pair
- of {\tt MPI_SendRecv} calls instead of two simultaneous non-blocking calls
- (default 0, meaning off). Might be faster on some MPI implementations.
-\item {\tt GMX_DLB_BASED_ON_FLOPS}: do domain-decomposition dynamic load balancing based on flop count rather than
- measured time elapsed (default 0, meaning off).
- This makes the load balancing reproducible, which can be useful for debugging purposes.
- A value of 1 uses the flops; a value $>1$ adds $(\mbox{value} - 1)\times5\%$ of noise to the flops to increase the imbalance and the scaling.
-\item {\tt GMX_DLB_MAX_BOX_SCALING}: maximum percentage box scaling permitted per domain-decomposition
- load-balancing step (default 10)
-\item {\tt GMX_DD_RECORD_LOAD}: record DD load statistics for reporting at end of the run (default 1, meaning on)
-\item {\tt GMX_DD_NST_SORT_CHARGE_GROUPS}: number of steps that elapse between re-sorting of the charge
- groups (default 1). This only takes effect during domain decomposition, so should typically
- be 0 (never), 1 (to mean at every domain decomposition), or a multiple of {\tt nstlist}.
-\item {\tt GMX_DETAILED_PERF_STATS}: when set, print slightly more detailed performance information
- to the {\tt .log} file. The resulting output is the way performance summary is reported in versions
- 4.5.x and thus may be useful for anyone using scripts to parse {\tt .log} files or standard output.
-\item {\tt GMX_DISABLE_SIMD_KERNELS}: disables architecture-specific SIMD-optimized (SSE2, SSE4.1, AVX, etc.)
- non-bonded kernels thus forcing the use of plain C kernels.
-\item {\tt GMX_DISABLE_CUDA_TIMING}: timing of asynchronously executed GPU operations can have a
- non-negligible overhead with short step times. Disabling timing can improve performance in these cases.
-\item {\tt GMX_DISABLE_GPU_DETECTION}: when set, disables GPU detection even if {\tt \normindex{mdrun}} was compiled
- with GPU support.
-\item {\tt GMX_DISABLE_PINHT}: disable pinning of consecutive threads to physical cores when using
- Intel hyperthreading. Controlled with {\tt \normindex{mdrun} -nopinht} and thus this environment
- variable will likely be removed.
-\item {\tt GMX_DISRE_ENSEMBLE_SIZE}: the number of systems for distance restraint ensemble
- averaging. Takes an integer value.
-\item {\tt GMX_EMULATE_GPU}: emulate GPU runs by using algorithmically equivalent CPU reference code instead of
- GPU-accelerated functions. As the CPU code is slow, it is intended to be used only for debugging purposes.
- The behavior is automatically triggered if non-bonded calculations are turned off using {\tt GMX_NO_NONBONDED}
- case in which the non-bonded calculations will not be called, but the CPU-GPU transfer will also be skipped.
-\item {\tt GMX_ENX_NO_FATAL}: disable exiting upon encountering a corrupted frame in an {\tt .edr}
- file, allowing the use of all frames up until the corruption.
-\item {\tt GMX_FORCE_UPDATE}: update forces when invoking {\tt \normindex{mdrun} -rerun}.
-\item {\tt GMX_GPU_ID}: set in the same way as the {\tt \normindex{mdrun}} option {\tt -gpu_id}, {\tt GMX_GPU_ID}
- allows the user to specify different GPU id-s, which can be useful for selecting different
- devices on different compute nodes in a cluster. Cannot be used in conjunction with {\tt -gpu_id}.
-\item {\tt GMX_IGNORE_FSYNC_FAILURE_ENV}: allow {\tt \normindex{mdrun}} to continue even if
- a file is missing.
-\item {\tt GMX_LJCOMB_TOL}: when set to a floating-point value, overrides the default tolerance of
- 1e-5 for force-field floating-point parameters.
-\item {\tt GMX_MAX_MPI_THREADS}: sets the maximum number of MPI-threads that {\tt \normindex{mdrun}}
- can use.
-\item {\tt GMX_MAXCONSTRWARN}: if set to -1, {\tt \normindex{mdrun}} will
- not exit if it produces too many LINCS warnings.
-\item {\tt GMX_NB_GENERIC}: use the generic C kernel. Should be set if using
- the group-based cutoff scheme and also sets {\tt GMX_NO_SOLV_OPT} to be true,
- thus disabling solvent optimizations as well.
-\item {\tt GMX_NB_MIN_CI}: neighbor list balancing parameter used when running on GPU. Sets the
- target minimum number pair-lists in order to improve multi-processor load-balance for better
- performance with small simulation systems. Must be set to a positive integer, the default value
- is optimized for NVIDIA Fermi and Kepler GPUs, therefore changing it is not necessary for
- normal usage, but it can be useful on future architectures.
-\item {\tt GMX_NBLISTCG}: use neighbor list and kernels based on charge groups.
-\item {\tt GMX_NBNXN_CYCLE}: when set, print detailed neighbor search cycle counting.
-\item {\tt GMX_NBNXN_EWALD_ANALYTICAL}: force the use of analytical Ewald non-bonded kernels,
- mutually exclusive of {\tt GMX_NBNXN_EWALD_TABLE}.
-\item {\tt GMX_NBNXN_EWALD_TABLE}: force the use of tabulated Ewald non-bonded kernels,
- mutually exclusive of {\tt GMX_NBNXN_EWALD_ANALYTICAL}.
-\item {\tt GMX_NBNXN_SIMD_2XNN}: force the use of 2x(N+N) SIMD CPU non-bonded kernels,
- mutually exclusive of {\tt GMX_NBNXN_SIMD_4XN}.
-\item {\tt GMX_NBNXN_SIMD_4XN}: force the use of 4xN SIMD CPU non-bonded kernels,
- mutually exclusive of {\tt GMX_NBNXN_SIMD_2XNN}.
-\item {\tt GMX_NO_ALLVSALL}: disables optimized all-vs-all kernels.
-\item {\tt GMX_NO_CART_REORDER}: used in initializing domain decomposition communicators. Rank reordering
- is default, but can be switched off with this environment variable.
-\item {\tt GMX_NO_CUDA_STREAMSYNC}: the opposite of {\tt GMX_CUDA_STREAMSYNC}. Disables the use of the
- standard cudaStreamSynchronize-based GPU waiting to improve performance when using CUDA driver API
- ealier than v5.0 with ECC-enabled GPUs.
-\item {\tt GMX_NO_INT}, {\tt GMX_NO_TERM}, {\tt GMX_NO_USR1}: disable signal handlers for SIGINT,
- SIGTERM, and SIGUSR1, respectively.
-\item {\tt GMX_NO_NODECOMM}: do not use separate inter- and intra-node communicators.
-\item {\tt GMX_NO_NONBONDED}: skip non-bonded calculations; can be used to estimate the possible
- performance gain from adding a GPU accelerator to the current hardware setup -- assuming that this is
- fast enough to complete the non-bonded calculations while the CPU does listed force and PME computation.
-\item {\tt GMX_NO_PULLVIR}: when set, do not add virial contribution to COM pull forces.
-\item {\tt GMX_NOCHARGEGROUPS}: disables multi-atom charge groups, {\ie} each atom
- in all non-solvent molecules is assigned its own charge group.
-\item {\tt GMX_NOPREDICT}: shell positions are not predicted.
-\item {\tt GMX_NO_SOLV_OPT}: turns off solvent optimizations; automatic if {\tt GMX_NB_GENERIC}
- is enabled.
-\item {\tt GMX_NSCELL_NCG}: the ideal number of charge groups per neighbor searching grid cell is hard-coded
- to a value of 10. Setting this environment variable to any other integer value overrides this hard-coded
- value.
-\item {\tt GMX_PME_NTHREADS}: set the number of OpenMP or PME threads (overrides the number guessed by
- {\tt \normindex{mdrun}}.
-\item {\tt GMX_PME_P3M}: use P3M-optimized influence function instead of smooth PME B-spline interpolation.
-\item {\tt GMX_PME_THREAD_DIVISION}: PME thread division in the format ``x y z'' for all three dimensions. The
- sum of the threads in each dimension must equal the total number of PME threads (set in
- {\tt GMX_PME_NTHREADS}).
-\item {\tt GMX_PMEONEDD}: if the number of domain decomposition cells is set to 1 for both x and y,
- decompose PME in one dimension.
-\item {\tt GMX_REQUIRE_SHELL_INIT}: require that shell positions are initiated.
-\item {\tt GMX_REQUIRE_TABLES}: require the use of tabulated Coulombic
- and van der Waals interactions.
-\item {\tt GMX_SCSIGMA_MIN}: the minimum value for soft-core $\sigma$. {\bf Note} that this value is set
- using the {\tt sc-sigma} keyword in the {\tt .mdp} file, but this environment variable can be used
- to reproduce pre-4.5 behavior with respect to this parameter.
-\item {\tt GMX_TPIC_MASSES}: should contain multiple masses used for test particle insertion into a cavity.
- The center of mass of the last atoms is used for insertion into the cavity.
-\item {\tt GMX_USE_GRAPH}: use graph for bonded interactions.
-\item {\tt GMX_VERLET_BUFFER_RES}: resolution of buffer size in Verlet cutoff scheme. The default value is
- 0.001, but can be overridden with this environment variable.
-\item {\tt MPIRUN}: the {\tt mpirun} command used by {\tt \normindex{g_tune_pme}}.
-\item {\tt MDRUN}: the {\tt \normindex{mdrun}} command used by {\tt \normindex{g_tune_pme}}.
-\item {\tt GMX_NSTLIST}: sets the default value for {\tt nstlist}, preventing it from being tuned during
- {\tt \normindex{mdrun}} startup when using the Verlet cutoff scheme.
-\item {\tt GMX_USE_TREEREDUCE}: use tree reduction for nbnxn force reduction. Potentially faster for large number of
- OpenMP threads (if memory locality is important).
-
-\end{enumerate}
-
-{\bf Analysis and Core Functions}
-
-\begin{enumerate}
-
-\item {\tt GMX_QM_ACCURACY}: accuracy in Gaussian L510 (MC-SCF) component program.
-\item {\tt GMX_QM_ORCA_BASENAME}: prefix of {\tt .tpr} files, used in Orca calculations
- for input and output file names.
-\item {\tt GMX_QM_CPMCSCF}: when set to a nonzero value, Gaussian QM calculations will
- iteratively solve the CP-MCSCF equations.
-\item {\tt GMX_QM_MODIFIED_LINKS_DIR}: location of modified links in Gaussian.
-\item {\tt DSSP}: used by {\tt \normindex{do_dssp}} to point to the {\tt dssp}
- executable (not just its path).
-\item {\tt GMX_QM_GAUSS_DIR}: directory where Gaussian is installed.
-\item {\tt GMX_QM_GAUSS_EXE}: name of the Gaussian executable.
-\item {\tt GMX_DIPOLE_SPACING}: spacing used by {\tt \normindex{g_dipoles}}.
-\item {\tt GMX_MAXRESRENUM}: sets the maximum number of residues to be renumbered by
- {\tt \normindex{grompp}}. A value of -1 indicates all residues should be renumbered.
-\item {\tt GMX_FFRTP_TER_RENAME}: Some force fields (like AMBER) use specific names for N- and C-
- terminal residues (NXXX and CXXX) as {\tt .rtp} entries that are normally renamed. Setting
- this environment variable disables this renaming.
-\item {\tt GMX_PATH_GZIP}: {\tt gunzip} executable, used by {\tt \normindex{g_wham}}.
-\item {\tt GMX_FONT}: name of X11 font used by {\tt \normindex{ngmx}}.
-\item {\tt GMXTIMEUNIT}: the time unit used in output files, can be
- anything in fs, ps, ns, us, ms, s, m or h.
-\item {\tt GMX_QM_GAUSSIAN_MEMORY}: memory used for Gaussian QM calculation.
-\item {\tt MULTIPROT}: name of the {\tt multiprot} executable, used by the
- contributed program {\tt \normindex{do_multiprot}}.
-\item {\tt NCPUS}: number of CPUs to be used for Gaussian QM calculation
-\item {\tt GMX_ORCA_PATH}: directory where Orca is installed.
-\item {\tt GMX_QM_SA_STEP}: simulated annealing step size for Gaussian QM calculation.
-\item {\tt GMX_QM_GROUND_STATE}: defines state for Gaussian surface hopping calculation.
-\item {\tt GMX_TOTAL}: name of the {\tt total} executable used by the contributed
- {\tt \normindex{do_shift}} program.
-\item {\tt GMX_ENER_VERBOSE}: make {\tt \normindex{g_energy}} and {\tt \normindex{eneconv}}
- loud and noisy.
-\item {\tt VMD_PLUGIN_PATH}: where to find VMD plug-ins. Needed to be
- able to read file formats recognized only by a VMD plug-in.
-\item {\tt VMDDIR}: base path of VMD installation.
-\item {\tt GMX_USE_XMGR}: sets viewer to {\tt xmgr} (deprecated) instead of {\tt xmgrace}.
-
-\end{enumerate}
-
-\section{Running {\gromacs} in parallel}
-By default {\gromacs} will be compiled with the built-in thread-MPI library.
-This library handles communication between threads on a single
-node more efficiently than using an external MPI library.
-To run {\gromacs} in parallel over multiple nodes, e.g. on a cluster,
-you need to configure and compile {\gromacs} with an external
-MPI library. All supercomputers are shipped with MPI libraries optimized for
-that particular platform, and there are several good free MPI
-implementations; OpenMPI is usually a good choice.
-Note that MPI and thread-MPI support are mutually incompatible.
-
-In addition to MPI parallelization, {\gromacs} supports also
-thread-parallelization through \normindex{OpenMP}. MPI and OpenMP parallelization
-can be combined, which results in, so called, hybrid parallelization. It can offer
-better performance and scaling in some cases.
-
-See {\wwwpage} for details on the use and performance of the different
-parallelization schemes.
-
-\section{Running {\gromacs} on \normindex{GPUs}}
-As of version 4.6, {\gromacs} has native GPU support through CUDA.
-Note that {\gromacs} only off-loads the most compute intensive parts
-to the GPU, currently the non-bonded interactions, and does all other
-parts of the MD calculation on the CPU. The requirements for the CUDA code
-are an Nvidia GPU with compute capability $\geq 2.0$, i.e. at
-least Fermi class.
-In many cases {\tt cmake} can auto-detect GPUs and the support will be
-configured automatically. To be sure GPU support is configured, pass
-the {\tt -DGMX_GPU=on} option to {\tt cmake}. The actual use of GPUs
-is decided at run time by {\tt mdrun}, depending on the availability
-of (suitable) GPUs and on the run input settings. A binary compiled
-with GPU support can also run CPU only simulations. Use {\tt mdrun -nb cpu}
-to force a simulation to run on CPUs only. Only simulations with the Verlet
-cut-off scheme will run on a GPU.
-Getting good performance with {\gromacs} on GPUs is easy,
-but getting best performance can be difficult.
-Please check {\wwwpage} for up to date information on GPU usage.
-
-% LocalWords: Opteron Itanium PowerPC Altivec Athlon Fortran virial bfgs Nasm
-% LocalWords: diagonalization Cygwin MPI Multi GMXHOME extern gmx tx pid buf
-% LocalWords: bufsize txs rx rxs init nprocs fp msg GMXRC DUMPNL BUFS GMXNPRI
-% LocalWords: unbuffered SGI npri mdrun covar nmeig setenv XPM XVG EPS
-% LocalWords: PDB xvg xpm eps pdb xmgrace ghostview rasmol GMXTIMEUNIT fs dssp
-% LocalWords: mpi distclean ing mpirun goofus doofus fred topol np
-% LocalWords: internet gromacs DGMX cmake SIMD intrinsics AVX PME XN
-% LocalWords: Verlet pre config CONSTRAINTVIR MAXBACKUP TPI ngmx mdp
-% LocalWords: LONGFORMAT DISTGCT CPT tpr cpt CUDA EWALD TWINCUT rvdw
-% LocalWords: rcoulomb STREAMSYNC cudaStreamSynchronized ECC GPUs sc
-% LocalWords: ZYX PERF GPU PINHT hyperthreading DISRE NONBONDED ENX
-% LocalWords: edr ENER gpu FSYNC ENV LJCOMB TOL MAXCONSTRWARN LINCS
-% LocalWords: SOLV NBLISTCG NBNXN XNN ALLVSALL cudaStreamSynchronize
-% LocalWords: USR SIGINT SIGTERM SIGUSR NODECOMM intra PULLVIR multi
-% LocalWords: NOCHARGEGROUPS NOPREDICT NSCELL NCG NTHREADS OpenMP CP
-% LocalWords: PMEONEDD Coulombic der Waals SCSIGMA TPIC GMXNPRIALL
-% LocalWords: GOMP KMP pme NSTLIST ENVVAR nstlist startup OMP NUM ps
-% LocalWords: ACC SCF BASENAME Orca CPMCSCF MCSCF DEVEL EXE GKRWIDTH
-% LocalWords: MAXRESRENUM grompp FFRTP TER NXXX CXXX rtp GZIP gunzip
-% LocalWords: GMXFONT ns MEM MULTIPROT multiprot NCPUS CPUs OPENMM
-% LocalWords: PLUGIN OpenMM plugins SASTEP TESTMC eneconv VMD VMDDIR
-% LocalWords: GMX_USE_XMGR xmgr parallelization nt online Nvidia nb cpu
-% LocalWords: grommp
+++ /dev/null
-#!/bin/bash
-
-if [[ ! -d $1 ]]; then
- echo "Error: provide the GROMACS html directory as first argument."
- exit
-fi
-
-GMXHTMLDIR=$1
-
-dir=${PWD}
-
-TEXDIR=.
-MANDIR=online
-HTML=$GMXHTMLDIR
-HTMLOL=$HTML/$MANDIR
-HTMLMDPOPT=$HTMLOL/mdp_opt.html
-TEXMDPOPT=$TEXDIR/mdp_opt.tex
-
-echo "Will convert $HTMLMDPOPT (html format)"
-echo "to $TEXMDPOPT (latex format)"
-
-echo -n "parsing."
-sed \
--e 's/<[aA] [^>]*>//g' \
--e 's/<\/[aA]>//g' \
--e 's/<[iI][mM][gG] [^>]*>//g' \
--e 's/<[pP]>//g' \
--e 's/<\/[pP]>//g' \
--e 's/&[nN][bB][sS][pP];/~/g' \
--e 's/<[hH][rR]>//g' \
-$HTMLMDPOPT > temp1
-
-echo -n "."
-awk '{
- if (NF) {
- if ( ($1 == "<P>") || ($1 == "<p>") || ($1 == "<BR>") || ($1 == "<br>") )
- print ""
- else
- print $0
- }
- }' temp1 > temp2
-echo -n "."
-sed \
--e 's/>=/$\\geq$/g;s/≥/$\\geq$/g' \
--e 's/>/$\>$/g' \
--e 's/<=/$\\leq$/g;s/≤/$\\leq$/g' \
--e 's/</$\<$/g' \
--e 's/_/_/g' \
--e 's/%/\\%/g' \
--e 's/&/\\&/g' \
--e 's/<sup>\([^<]*\)<\/sup>/$^{\1}$/g' \
--e 's/<sub>\([^<]*\)<\/sub>/$_{\1}$/g' \
--e 's/<[tT][tT]>\([^<]*\)<\/[tT][tT]>/{\\tt \1}/g' \
--e 's/<[pP][rR][eE]>\([^<]*\)<\/[pP][rR][eE]>/\\\\{\\tt\1}\\\\/g' \
--e 's/<\!--Idx-->\([^>]*\)<\!--EIdx-->/\\normindex{\1}/g' \
--e 's/<\!--QuietIdx-->\([^>]*\)<\!--EQuietIdx-->/\\index{\1}/g' \
--e 's/<[hH]1>\([^<]*\)<\/[hH]1>/\\section{\1}/g' \
--e 's/<[hH]3>\([^<]*\)<\/[hH]3>/\\subsection{\1}/g' \
-temp2 > temp3
-
-echo -n "."
-sed \
--e 's/<[uU][lL]>/\\begin{itemize}/g' \
--e 's/<\/[uU][lL]>/\\end{itemize}/g' \
--e 's/<[lL][iI]>/\\item /g' \
--e 's/<[dD][lL] [cC][oO][^>]*>/\\vspace{-2ex}\\begin{description}[font=\\ttfamily]/g' \
--e 's/<[dD][lL][^>]*>/\\begin{description}[font=\\ttfamily]/g' \
--e 's/<\/[dD][lL]>/\\end{description}/g' \
--e 's/<[dD][tT]><[bB]>\(.*\)<\/[bB]>\(.*\)<\/[dD][tT]>/\\item[\1] \2\\hfill\\\\/g' \
--e 's/<[dD][tT]>\([^<]*\)<\/[dD][tT]>/\\item[\1]\\hfill\\\\/g' \
--e 's/<[bB]>\([^<]*\)<\/[bB]>/{\\tt \1}/g' \
--e 's/<[iI]>\([^<]*\)<\/[iI]>/{\\em \1}/g' \
--e 's/<[dD][dD]>//g' \
--e 's/<\/[dD][dD]>//g' \
--e 's/<\/[dD][tT]>//g' \
--e 's/ \(\[[^]]*\]\)\]/ {\1}\]/g' \
--e 's/\$lt\$/$<$/g' \
--e 's/\$gt\$/$>$/g' \
--e 's/e\.g\./{\\eg}/g' \
--e 's/i\.e\./{\\ie}/g' \
-temp3 > temp4
-
-echo -n "."
-awk 'BEGIN { printf("\\label{sec:mdpopt}\n"); }\
-{\
- if ( index($0,"subsection") ) {\
- if ( index($0,"General") ) {\
- output=1;\
- } else if ( index($0,"Index") )\
- output=0;\
- }\
- if (output) print;\
-}' temp4 > $TEXMDPOPT
-
-echo "."
-
-rm temp1 temp2 temp3 temp4
-
-#last line
-exit
%
% This file is part of the GROMACS molecular simulation package.
%
-% Copyright (c) 2013,2014, by the GROMACS development team, led by
+% Copyright (c) 2013,2014,2015, by the GROMACS development team, led by
% Mark Abraham, David van der Spoel, Berk Hess, and Erik Lindahl,
% and including many others, as listed in the AUTHORS file in the
% top-level source directory and at http://www.gromacs.org.
\input{files}
\section{Run Parameters\swapindexquiet{run}{parameter}}
-\input{mdp_opt}
+% TODO Check this is up to date when things stabilize
+The descriptions of {\tt .mdp} parameters can be found at
+\url{http://manual.gromacs.org/current/mdp-options.html}
+or in your installation at {\tt share/gromacs/html/mdp-options.html}
% LocalWords: online html GMXRC MANPATH grompp xdr NFS
%
% This file is part of the GROMACS molecular simulation package.
%
-% Copyright (c) 2013,2014, by the GROMACS development team, led by
+% Copyright (c) 2013,2014,2015, by the GROMACS development team, led by
% Mark Abraham, David van der Spoel, Berk Hess, and Erik Lindahl,
% and including many others, as listed in the AUTHORS file in the
% top-level source directory and at http://www.gromacs.org.
groups of atoms, this can be set through energy groups.
Different tables can be used for non-bonded interactions between
different energy groups pairs through the {\tt .mdp} option {\tt energygrp-table}
-(see \secref{mdpopt}).
+(see details in the User Guide).
Atoms that should interact with a different potential should
be put into different energy groups.
Between group pairs which are not listed in {\tt energygrp-table},
% LocalWords: vsitehydro planarity chirality pdb gmx virtualize virtualized xz
% LocalWords: vis massless tryptophan histidine phenyl parameterizing ij PPPM
% LocalWords: parameterization Berendsen rlist coulombtype rcoulomb vdwtype LJ
-% LocalWords: rvdw energygrp mdrun pre GMXLIB mdpopt MOPAC GAMESS CPMD ONIOM
+% LocalWords: rvdw energygrp mdrun pre GMXLIB MOPAC GAMESS CPMD ONIOM
% LocalWords: Morokuma iJ AQ AJ initio atomtype QMatom MMatom QMMM grps et al
% LocalWords: QMmethod QMbasis QMMMscheme RHF DFT LYP CASSCF MMVB CASelectrons
% LocalWords: CASorbitals planewavecutoff STO QMcharge QMmult diabatic edr
+<!-- TODO migrate remaining content to new user guide (in future commits) -->
<TITLE>GROMACS Online Reference</TITLE>
<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=10>
<TR>
<TD VALIGN=top WIDTH="25%">
<h3>General</h3>
-<A HREF="online/getting_started.html">Getting Started</a>
-<br><br>
<A HREF="online/flow.html">Flow Chart</a>
<br><br>
<A HREF="online/files.html">File Formats</a>
<br><br>
-<A HREF="online/mdp_opt.html">mdp options</a>
-<br><br>
-<A HREF="http://www.gromacs.org/Documentation/FAQs">FAQ</a>
-<br>
-</TD>
-<TD VALIGN=top WIDTH=75%>
-<h3>Programs</h3>
-<A HREF="online/options.html">Options</a>
-<br><br>
-<a href="programs/byname.html">All Programs Alphabetically</a>
-<br><br>
-<a href="programs/bytopic.html">Programs by Topic</a>
</TD>
</TR>
</TABLE>
<h3>Description</h3>
The dlg file format is used as input for the
<a href="../programs/gmx-view.html">gmx view</a>
-trajectory viewer. These files are not meant to be altered bu the end user.
+trajectory viewer. These files are not meant to be altered by the end user.
<h3>Sample</h3>
<pre>
grid 39 18 {
<p>This is a flow chart of a typical GROMACS MD run of a protein
in a box of water.
A more detailed example is available in the
-<A HREF="getting_started.html">Getting Started</A>
+<A HREF="../user-guide.html#getting-started-with-gromacs">Getting Started</A>
section. Several steps of energy minimization may be necessary,
these consist of cycles: grompp -> mdrun.
<p>
+++ /dev/null
-<TITLE>Getting started</TITLE>
-<H3>Contents</H3>
-
-<ul>
-<li><a href="#start">Introduction</a>
-<ul>
- <li><a href="#setup">Setting up your environment</a>
-</ul>
-<li><a href="#files">GROMACS files</a>
-<ul>
- <li><a href="#top">Molecular topology file</a>
- <li><a href="#gro">Molecular structure file</a>
- <li><a href="#mdp">Molecular dynamics parameter file</a>
- <li><a href="#ndx">Index file</a>
- <li><a href="#tpr">Run input file</a>
- <li><a href="#trx">Trajectory file</a>
-</ul>
-<li><a href="#ref">References</a>
-</ul>
-
-<P>
-More info can be found in the
-<A HREF="flow.html">flowchart</A>
-(for a quick overview) and the
-<A HREF="http://www.gromacs.org/Documentation/FAQs">GROMACS FAQs</A>.
-</P>
-
-<br><hr><br>
-
-<a name="start"><H2>Introduction</A></H2>
-<p>
-In this chapter we assume the reader is familiar with Molecular
-Dynamics and familiar with Unix, including the use of a text editor
-such as <tt>jot</tt>, <tt>emacs</tt> or <tt>vi</tt>. We furthermore assume the
-GROMACS software is installed properly on your system. When you see a line
-like</p>
-
-<table BORDER=0 CELLSPACING=0 CELLPADDING=8 COLS=3 WIDTH="100%" NOSAVE >
-<tr NOSAVE>
-<td WIDTH="2%" NOSAVE><font color="#000000"></font></td>
-<td WIDTH="80%" BGCOLOR="#000066" NOSAVE><font color="#FFFFFF">
-
-<tt> ls -l
-</tt>
-<td></td>
-</tr>
-</table>
-<br>
-you are supposed to type the contents of that line on your computer.
-
-<H3><A NAME="setup">Setting up your environment</A></H3>
-<p>
-In order to check whether you have access to the GROMACS software, please
-start by entering the command:
-</p>
-<table BORDER=0 CELLSPACING=0 CELLPADDING=8 COLS=3 WIDTH="100%" NOSAVE >
-<tr NOSAVE>
-<td WIDTH="2%" NOSAVE><font color="#000000"></font></td>
-<td WIDTH="80%" BGCOLOR="#000066" NOSAVE><font color="#FFFFFF">
-
-<tt> mdrun -version
-</tt>
-<td></td>
-</tr>
-</table>
-<br>
-This command should print out information about the version of Gromacs
-installed.
-
-If this, in contrast, returns the phrase
-<pre>
-mdrun: command not found.
-</pre>
-
-then you have to verify where your version of GROMACS is installed.
-
-In the default case, the binaries are located in
-'/usr/local/gromacs/bin', however, you can ask your local system
-administrator for more information. If we assume that GROMACS is
-installed in directory <tt>XXX</tt> you would find the executables (programs) in
-<tt>XXX/bin</tt>. To be able to access the programs without
-problems, you will have to edit the login file for your shell. If you
-use the C shell, this file is called <TT>.cshrc</TT> or
-<TT>.tcshrc</TT>, and it is located in your home directory. Add a line
-like:
-
-<br><br>
-<table BORDER=0 CELLSPACING=0 CELLPADDING=8 COLS=3 WIDTH="100%" NOSAVE >
-<tr NOSAVE>
-<td WIDTH="2%" NOSAVE><font color="#000000"></font></td>
-<td WIDTH="80%" BGCOLOR="#000066" NOSAVE><font color="#FFFFFF">
-<tt>
-source XXX/bin/GMXRC
-</tt>
-<td></td>
-</tr>
-</table>
-<br>
-
-Issue this command at the prompt too, or log off and on again to
-automatically get the environment.
-You should have an environment variable set now that is called
-GMXDATA that we will use further on. Let us check whether this was
-successful using:<br><br>
-
-<table BORDER=0 CELLSPACING=0 CELLPADDING=8 COLS=3 WIDTH="100%" NOSAVE >
-<tr NOSAVE>
-<td WIDTH="2%" NOSAVE><font color="#000000"></font></td>
-<td WIDTH="80%" BGCOLOR="#000066" NOSAVE><font color="#FFFFFF">
-
-<tt> echo $GMXDATA
-</tt>
-<td></td>
-</tr>
-</table>
-<br>
-If it prints a directory name you are ready to rock, otherwise go back two steps.
-
-<br><hr><br>
-<H2><A NAME="files">GROMACS files</A></h2>
-Here is an overview of the most important GROMACS file types that you will
-encounter during the tutorial.
-<DL>
-<DT>
-<h3><A NAME="top">Molecular Topology file (<TT><a href="top.html">.top</a></TT>)</A></h3>
-<DD>
-The molecular topology file is generated by the program <TT>
-<a href="../programs/gmx-pdb2gmx.html">gmx pdb2gmx</a></TT>.
-<a href="../programs/gmx-pdb2gmx.html">gmx pdb2gmx</a> translates a
-<a href="pdb.html">pdb</a> structure file of any peptide or protein
-to a molecular topology file. This topology file contains a complete
-description of all the interactions in your peptide or protein.
-<P></P>
-
-<DT>
-<h3><A NAME="gro">Molecular Structure file (<TT><a href="gro.html">.gro</a></TT>, <TT><a href="pdb.html">.pdb</a></TT>)</A></h3>
-<DD>
-When the <a href="../programs/gmx-pdb2gmx.html">gmx pdb2gmx</a> program is executed
-to generate a molecular
-topology, it also translates the structure file (<TT><a href="pdb.html">.pdb</a></TT> file)
-to a gromos
-structure file (<TT><a href="gro.html">.gro</a></TT> file). The main difference between a
-<a href="pdb.html">pdb</a> file and a gromos file is their format and that
-a <TT><a href="gro.html">.gro</a></TT> file can also hold velocities. However, if you do not need the
-velocities, you can also use a <a href="pdb.html">pdb</a> file in all programs.
-To generate a box of solvent molecules
-around the peptide, the program
-<a href="../programs/gmx-solvate.html">gmx solvate</a> is used. First the program
-<a href="../programs/gmx-editconf.html">gmx editconf</a> should be used to
-define a box of appropriate size around the molecule.
-<a href="../programs/gmx-solvate.html">gmx solvate</a>
-solvates a solute molecule (the peptide) into any solvent (in this
-case water). The output of <TT><a href="../programs/gmx-solvate.html">gmx solvate</a></TT>
-is a gromos structure file of the peptide solvated in water. The
-<a href="../programs/gmx-solvate.html">gmx solvate</a> program also changes the
-molecular topology file (generated by <a href="../programs/gmx-pdb2gmx.html">gmx pdb2gmx</a>)
-to add solvent to the topology.
-<P></P>
-
-<DT>
-<h3><A NAME="mdp">Molecular Dynamics parameter file (<TT><a href="mdp_opt.html">.mdp</a></TT>)</A></h3>
-<DD>
-The Molecular Dynamics Parameter (<TT><a href="mdp_opt.html">.mdp</a></TT>) file contains all
-information about the Molecular Dynamics simulation itself
-e.g. time-step, number of steps, temperature, pressure etc. The
-easiest way of handling such a file is by adapting a sample <TT><a href="mdp_opt.html">.mdp</a></TT>
-file. A <TT><a href="mdp.html">sample mdp file</a></TT>
-can be found online.
-<P></P>
-
-<DT>
-<h3><A NAME="ndx">Index file (<TT><a href="ndx.html">.ndx</a></TT>)</A></h3>
-<DD>
-Sometimes you may need an index file to specify actions on groups of atoms
-(e.g. Temperature coupling, accelerations, freezing). Usually the default index
-groups will be sufficient, so for this demo we will
-not consider the use of index files.
-<P></P>
-
-<DT>
-<h3><A NAME="tpr">Run input file (<TT><a href="tpr.html">.tpr</a></TT>)</A></h3>
-<DD>
-The next step is to combine the molecular structure (<TT><a href="gro.html">.gro</a></TT> file),
-topology (<TT><a href="top.html">.top</a></TT> file) MD-parameters (<TT><a href="mdp_opt.html">.mdp</a></TT> file) and
-(optionally) the
-index file (<TT><a href="ndx.html">ndx</a></TT>) to generate a run input file (<TT><a href="tpr.html">.tpr</a></tt> extension.
-This file contains all information needed to start a simulation with GROMACS.
-The
-<a href="../programs/gmx-grompp.html">gmx grompp</a> program processes all
-input files and generates the run input
-<tt><a href="tpr.html">.tpr</a></tt> file.
-<P></P>
-
-<DT>
-<h3><A NAME="trx">Trajectory file (<TT><a href="trr.html">.trr</a></TT></A>)</h3>
-<DD>
-Once the run input file is available, we can start the
-simulation. The program which starts the simulation is called
-<a href="../programs/gmx-mdrun.html">gmx mdrun</a>. The only input file
-of <TT><a href="../programs/gmx-mdrun.html">gmx mdrun</a></TT> you usually need
-to start a run
-is the run input file (<TT><a href="tpr.html">.tpr</a></TT> file).
-The output files of
-<TT><a href="../programs/gmx-mdrun.html">gmx mdrun</a></TT> are the
-trajectory file (<TT><a href="trr.html">.trr</a></TT> file) and a logfile (
-<TT><a href="log.html">.log</A></TT> file).
-<P></P>
-
-</DL>
-
-<br><hr><br>
-
-<P><H2><A NAME="ref">References</A></h2>
-
-<blockquote>
-<dl>
-
-<dt><A NAME="berendsen81">Berendsen, H.J.C., Postma, J.P.M., van
-Gunsteren, W.F., Hermans, J. (1981) <dd><it>Intermolecular
-Forces</it>, chapter Interaction models for water in relation to
-protein hydration, pp 331-342. Dordrecht: D. Reidel Publishing Company
-Dordrecht</dd><p>
-
-<dt><A NAME="kabsch83">Kabsch, W., Sander, C. (1983). <dd>Dictionary
-of protein secondary structure: Pattern recognition of hydrogen-bonded
-and geometrical features. <it>Biopolymers</it> <b>22</b>,
-2577--2637.</dd><p>
-
-<dt><A NAME="mierke91">Mierke, D.F., Kessler, H. (1991). <dd>Molecular
-dynamics with dimethyl sulfoxide as a solvent. Conformation of a
-cyclic hexapeptide. <it>J. Am. Chem. Soc.</it> <b>113</b>, 9446.</dd><p>
-
-<dt><A NAME="stryer88">Stryer, L. (1988). <dd><it>Biochemistry</it>
-vol. 1, p. 211. New York: Freeman, 3 edition.</dd><p>
-
-</dl>
-</blockquote>
<title>mdp file format</title>
-<P> Follow <a href="mdp_opt.html">this link</a> for a detailed description of the options</a>. </P>
+<P> See the <a href="../user-guide.html#molecular-dynamics-parameters-.mdp-options">user guide</a>
+for a detailed description of the options</a>. </P>
<P> Below is a sample mdp file.
The ordering of the items is not important, but if you enter the same
+++ /dev/null
-<TITLE>mdp options</TITLE>
-<!--
-
-PLEASE BE VERY CAREFUL WHEN EDITING THIS FILE: IT MUST BE
-AUTOMATICALLY PARSED BY A SIMPLE SCRIPT (mkmdp in the GROMACS manual repository) TO PRODUCE A
-CORRESPONDING LATEX FILE.
-
-IF YOU'RE NOT SURE ABOUT WHAT YOU'RE DOING, DON'T DO IT!
-
--->
-
-<H3>Table of Contents</H3>
-
-<ul>
-<li><A HREF="#general"><b>General remarks</b></A>
-<p> </p>
-<li><A HREF="#pp"><b>preprocessing</b></A> (include, define)
-<li><A HREF="#run"><b>run control</b></A> (integrator, tinit, dt, nsteps, init-step, comm-mode, nstcomm, comm-grps)
-<li><A HREF="#ld"><b>langevin dynamics</b></A> (bd-fric, ld-seed)
-<li><A HREF="#em"><b>energy minimization</b></A> (emtol, emstep, nstcgsteep)
-<li><a HREF="#shellmd"><b>shell molecular dynamics</b></a>(emtol,niter,fcstep)
-<li><a HREF="#tpi"><b>test particle insertion</b></a>(rtpi)
-<li><A HREF="#out"><b>output control</b></A> (nstxout, nstvout, nstfout, nstlog, nstcalcenergy, nstenergy, nstxout-compressed, compressed-x-precision, compressed-x-grps, energygrps)
-<li><A HREF="#nl"><b>neighbor searching</b></A> (cutoff-scheme, nstlist, nstcalclr, ns-type, pbc, periodic-molecules, verlet-buffer-tolerance, rlist, rlistlong)
-<li><A HREF="#el"><b>electrostatics</b></A> (coulombtype, coulomb-modifier, rcoulomb-switch, rcoulomb, epsilon-r, epsilon-rf)
-<li><A HREF="#vdw"><b>VdW</b></A> (vdwtype, vdw-modifier, rvdw-switch, rvdw, DispCorr)
-<li><A HREF="#table"><b>tables</b></A> (table-extension, energygrp-table)
-<li><A HREF="#ewald"><b>Ewald</b></A> (fourierspacing, fourier-nx, fourier-ny, fourier-nz, pme-order, ewald-rtol, ewald-geometry, epsilon-surface)
-<li><A HREF="#tc"><b>Temperature coupling</b></A> (tcoupl, nsttcouple, tc-grps, tau-t, ref-t)
-<li><A HREF="#pc"><b>Pressure coupling</b></A> (pcoupl, pcoupltype,
- nstpcouple, tau-p, compressibility, ref-p, refcoord-scaling)
-<li><A HREF="#sa"><b>simulated annealing</b></A> (annealing, annealing-npoints, annealing-time, annealing-temp)
-<li><A HREF="#vel"><b>velocity generation</b></A> (gen-vel, gen-temp, gen-seed)
-<li><A HREF="#bond"><b>bonds</b></A> (constraints, constraint-algorithm, continuation, shake-tol, lincs-order, lincs-iter, lincs-warnangle, morse)
-<li><A HREF="#egexcl"><b>Energy group exclusions</b></A> (energygrp-excl)
-<li><A HREF="#walls"><b>Walls</b></A> (nwall, wall-type, wall-r-linpot, wall-atomtype,
-wall-density, wall-ewald-zfac)
-<li><A HREF="#pull"><b>COM pulling</b></A> (pull, ...)
-<li><A HREF="#nmr"><b>NMR refinement</b></A> (disre, disre-weighting, disre-mixed, disre-fc, disre-tau, nstdisreout, orire, orire-fc, orire-tau, orire-fitgrp, nstorireout)
-<li><A HREF="#free"><b>Free energy calculations</b></A> (free-energy, nstdhdl, dhdl-print-energy, init-lambda, delta-lambda, fep-lambdas, coul-lambdas, vdw-lambdas, bonded-lambdas, restraint-lambdas, mass-lambdas, temperature-lambdas, sc-alpha, sc-coul, sc-power, sc-r-power, sc-sigma, couple-moltype, couple-lambda0, couple-lambda1, couple-intramol)
-<li><A HREF="#expanded"><b>Expanded ensemble simulation</b></A> (lmc-stats, lmc-mc-move, lmc-seed, lmc-gibbsdelta, mc-temperature, nst-transition-matrix, init-lambda-weights, initial-wl-delta, wl-scale, wl-ratio, symmetrized-transition-matrix, lmc-forced-nstart, mininum-var-min, lmc-weights-equil, weight-equil-wl-delta, weight-equil-number-all-lambda, weight-equil-number-steps, weight-equil-number-samples, weight-equil-count-ratio, simulated-tempering, simulated-tempering-scaling, sim-temp-low, sim-temp-high)
-<li><A HREF="#neq"><b>Non-equilibrium MD</b></A> (acc-grps, accelerate, freezegrps, freezedim, cos-acceleration, deform)
-<li><A HREF="#ef"><b>Electric fields</b></A> (E-x, E-xt, E-y, E-yt, E-z, E-zt )
-<li><A HREF="#qmmm"><b>Mixed quantum/classical dynamics</b></A> (QMMM, QMMM-grps, QMMMscheme, QMmethod, QMbasis, QMcharge, Qmmult, CASorbitals, CASelectrons, SH)
-<li><A HREF="#gbsa"><b>Implicit solvent</b></A> (implicit-solvent, gb-algorithm, nstgbradii, rgbradii, gb-epsilon-solvent, gb-saltconc, gb-obc-alpha, gb-obc-beta, gb-obc-gamma, gb-dielectric-offset, sa-algorithm, sa-surface-tension)
-<li><A HREF="#adress"><b>AdResS settings</b></A> (adress, adress_type, adress_const_wf, adress_ex_width, adress_hy_width, adress_ex_forcecap, adress_interface_correction, adress_site, adress_reference_coords, adress_tf_grp_names, adress_cg_grp_names)
-<li><A HREF="#user"><b>User defined thingies</b></A> (user1-grps, user2-grps, userint1, userint2, userint3, userint4, userreal1, userreal2, userreal3, userreal4)
-<li><A HREF="#idx"><b>Index</b></A>
-</ul>
-</P>
-
-<HR>
-
-<A NAME="general"><br>
-<h3>General</h3>
-
-<P>
-Default values are given in parentheses. The first option in
-the list is always the default option. Units are given in
-square brackets The difference between a dash and an underscore
-is ignored. </P>
-
-<P>
-A <a href="mdp.html">sample <TT>.mdp</TT> file</a> is
-available. This should be appropriate to start a normal
-simulation. Edit it to suit your specific needs and desires. </P>
-
-<A NAME="pp"><br>
-<hr>
-<h3>Preprocessing</h3>
-
-<dl>
-<dt><b>include:</b></dt>
-<dd>directories to include in your topology. Format:
-<PRE>-I/home/john/mylib -I../otherlib</PRE></dd>
-<dt><b>define:</b></dt>
-<dd>defines to pass to the preprocessor, default is no defines. You can use
-any defines to control options in your customized topology files. Options
-that are already available by default are:
-<dd><dl compact>
-<dt>-DFLEXIBLE</dt>
-<dd>Will tell <tt>grompp</tt> to include flexible water in stead of rigid water into your
-topology, this can be useful for normal mode analysis.</dd>
-<dt>-DPOSRES</dt>
-<dd>Will tell <tt>grompp</tt> to include posre.itp into your topology, used for
-<!--Idx-->position restraint<!--EIdx-->s.</dd>
-</dl>
-</dl>
-
-<A NAME="run"><br>
-<hr>
-<h3>Run control</h3>
-
-<dl>
-<dt><b>integrator:</b> (Despite the name, this list includes algorithms that are not actually integrators. <tt>steep</tt> and all entries following it are in this category)</dt>
-<dd><dl compact>
-<dt><b>md</b></dt>
-<dd>A leap-frog algorithm<!--QuietIdx-->leap-frog integrator<!--EQuietIdx-->
-for integrating Newton's equations of motion.</dd>
-<dt><b>md-vv</b></dt>
-<dd>A velocity Verlet algorithm for integrating Newton's equations of motion.
-For constant NVE simulations started from corresponding points in the same trajectory, the trajectories
-are analytically, but not binary, identical to the <b>md</b> leap-frog integrator. The the kinetic
-energy, which is determined from the whole step velocities and is therefore
-slightly too high. The advantage of this integrator is more accurate,
-reversible Nose-Hoover and Parrinello-Rahman coupling integration
-based on Trotter expansion, as well as (slightly too small) full step velocity
-output. This all comes at the cost off extra computation, especially with
-constraints and extra communication in parallel. Note that for nearly all
-production simulations the <b>md</b> integrator is accurate enough.
-</dd>
-<dt><b>md-vv-avek</b></dt>
-<dd>A velocity Verlet algorithm identical to <b>md-vv</b>, except that
-the kinetic energy is determined as the average of
-the two half step kinetic energies as in the <b>md</b> integrator, and this thus more accurate.
-With Nose-Hoover and/or Parrinello-Rahman coupling this comes with
-a slight increase in computational cost.
-</dd>
-<dt><b>sd</b></dt>
-<dd> An accurate and efficient leap-frog stochastic dynamics integrator.
-With constraints, coordinates needs to be constrained twice per integration step.
-Depending on the computational cost of the force calculation,
-this can take a significant part of the simulation time.
-The temperature for one or more groups of atoms
-(<b><A HREF="#tc">tc-grps</A></b>)
-is set with <b><A HREF="#tc">ref-t</A></b> [K],
-the inverse friction constant for each group is set with
-<b><A HREF="#tc">tau-t</A></b> [ps].
-The parameter <b><A HREF="#tc">tcoupl</A></b> is ignored.
-The random generator is initialized with <b><A HREF="#ld">ld-seed</A></b>.
-When used as a thermostat, an appropriate value for <b>tau-t</b> is 2 ps,
-since this results in a friction that is lower than the internal friction
-of water, while it is high enough to remove excess heat
-NOTE: temperature deviations decay twice as fast as with
-a Berendsen thermostat with the same <b>tau-t</b>.</dd>
-<dt><b>sd2</b></dt>
-<dd> This used to be the default sd integrator, but is now deprecated.
-Four Gaussian random numbers are required per coordinate per step.
-With constraints, the temperature will be slightly too high.</dd>
-<dt><b>bd</b></dt>
-<dd>An Euler integrator for Brownian or position Langevin dynamics, the
-velocity is the force divided by a friction coefficient
-(<b><A HREF="#ld">bd-fric</A></b> [amu ps<sup>-1</sup>])
-plus random thermal noise (<b><A HREF="#tc">ref-t</A></b>).
-When <b><A HREF="#ld">bd-fric</A></b><tt>=0</tt>, the friction coefficient for each
-particle is calculated as mass/<b><A HREF="#tc">tau-t</A></b>, as for the
-integrator <tt>sd</tt>.
-The random generator is initialized with <b><A HREF="#ld">ld-seed</A></b>.</dd>
-
-<dt><b>steep</b></dt>
-<dd>A <!--Idx-->steepest descent<!--EIdx--> algorithm for energy
-minimization. The maximum step size is <b><A HREF="#em">emstep</A></b>
-[nm], the tolerance is <b><A HREF="#em">emtol</A></b> [kJ
-mol<sup>-1</sup> nm<sup>-1</sup>].</dd>
-<dt><b>cg</b></dt>
-<dd>A <!--Idx-->conjugate gradient<!--EIdx--> algorithm for energy
-minimization, the tolerance is <b>emtol</b> [kJ mol<sup>-1</sup>
-nm<sup>-1</sup>]. CG is more efficient when a steepest descent step
-is done every once in a while, this is determined by
-<b><A HREF="#em">nstcgsteep</A></b>.
-For a minimization prior to a normal mode analysis, which requires
-a very high accuracy, GROMACS should be compiled in double precision.</dd>
-<dt><b>l-bfgs</b></dt>
-<dd>A <!--Idx-->quasi-Newtonian<!--EIdx--> algorithm for energy minimization
-according to the low-memory Broyden-Fletcher-Goldfarb-Shanno approach.
-In practice this seems to converge faster than Conjugate Gradients, but due
-to the correction steps necessary it is not (yet) parallelized.
-</dd>
-<dt><b>nm</b></dt>
-<dd>Normal mode analysis<!--QuietIdx-->normal-mode analysis<!--EQuietIdx--> is performed
-on the structure in the <tt>tpr</tt> file. GROMACS should be
-compiled in double precision.</dd>
-<dt><b>tpi</b></dt>
-<dd> Test particle insertion. The last molecule in the topology
-is the test particle. A trajectory should be provided with
-the <tt>-rerun</tt> option of <tt>mdrun</tt>. This trajectory
-should not contain the molecule to be inserted. Insertions
-are performed <b>nsteps</b> times in each frame at random locations
-and with random orientiations of the molecule. When <b>nstlist</b>
-is larger than one, <b>nstlist</b> insertions are performed
-in a sphere with radius <b><A HREF="#tpi">rtpi</A></b>
-around a the same random location using the same neighborlist
-(and the same long-range energy when <b>rvdw</b> or <b>rcoulomb</b>><b>rlist</b>,
-which is only allowed for single-atom molecules).
-Since neighborlist construction is expensive, one can perform several
-extra insertions with the same list almost for free.
-The random seed is set with <b><A HREF="#ld">ld-seed</A></b>.
-The temperature for the Boltzmann weighting is set with
-<b><A HREF="#tc">ref-t</A></b>, this should match the temperature
-of the simulation of the original trajectory.
-Dispersion correction is implemented correctly for tpi.
-All relevant quantities are written to the file specified with
-the <tt>-tpi</tt> option of <tt>mdrun</tt>.
-The distribution of insertion energies is written to the file specified with
-the <tt>-tpid</tt> option of <tt>mdrun</tt>.
-No trajectory or energy file is written.
-Parallel tpi gives identical results to single node tpi.
-For charged molecules, using PME with a fine grid is most accurate
-and also efficient, since the potential in the system only needs
-to be calculated once per frame.
-</dd>
-<dt><b>tpic</b></dt>
-<dd> Test particle insertion into a predefined cavity location.
-The procedure is the same as for <b>tpi</b>, except that one coordinate
-extra is read from the trajectory, which is used as the insertion location.
-The molecule to be inserted should be centered at 0,0,0. Gromacs does
-not do this for you, since for different situations a different
-way of centering might be optimal.
-Also <b><A HREF="#tpi">rtpi</A></b> sets the radius for the sphere
-around this location. Neighbor searching is done only once per frame,
-<b>nstlist</b> is not used.
-Parallel tpic gives identical results to single node tpic.
-</dl>
-
-<dt><b>tinit: (0) [ps]</b></dt>
-<dd>starting time for your run (only makes sense for integrators <tt>md</tt>,
-<tt>sd</tt> and <tt>bd</tt>)</dd>
-<dt><b>dt: (0.001) [ps]</b></dt></dd>
-<dd>time step for integration (only makes sense for integrators <tt>md</tt>,
-<tt>sd</tt> and <tt>bd</tt>)</dd>
-<dt><b>nsteps: (0)</b></dt>
-<dd>maximum number of steps to integrate or minimize, -1 is no maximum</dd>
-<dt><b>init-step: (0)</b></dt>
-<dd>The starting step.
-The time at an step i in a run is calculated as: t = <tt>tinit</tt> + <tt>dt</tt>*(<tt>init-step</tt> + i).
-The free-energy lambda is calculated as: lambda = <tt>init-lambda</tt> + <tt>delta-lambda</tt>*(<tt>init-step</tt> + i).
-Also non-equilibrium MD parameters can depend on the step number.
-Thus for exact restarts or redoing part of a run it might be necessary to
-set <tt>init-step</tt> to the step number of the restart frame.
-<tt>gmx convert-tpr</tt> does this automatically.
-</dd>
-<dt><b>comm-mode:</b></dt>
-<dd><dl compact>
-<dt><b>Linear</b></dt>
-<dd>Remove center of mass translation</dd>
-<dt><b>Angular</b></dt>
-<dd>Remove center of mass translation and rotation around the center of mass
-</dd>
-<dt><b>None</b></dt>
-<dd>No restriction on the center of mass motion
-</dl></dd>
-<dt><b>nstcomm: (100) [steps]</b></dt>
-<dd>frequency for center of mass motion removal</dd>
-<dt><b>comm-grps:</b></dt>
-<dd>group(s) for center of mass motion removal, default is the whole system</dd>
-</dl>
-
-<A NAME="ld"><br>
-<hr>
-<h3><!--Idx-->Langevin dynamics<!--EIdx--></h3>
-
-<dl>
-<dt><b>bd-fric: (0) [amu ps<sup>-1</sup>]</b></dt>
-<dd>Brownian dynamics friction coefficient.
-When <b>bd-fric</b><tt>=0</tt>, the friction coefficient for each
-particle is calculated as mass/<b><A HREF="#tc">tau-t</A></b>.</dd>
-<dt><b>ld-seed: (-1) [integer]</b></dt>
-<dd>used to initialize random generator for thermal noise
-for stochastic and Brownian dynamics.
-When <b>ld-seed</b> is set to -1, a pseudo random seed is used.
-When running BD or SD on multiple processors, each processor uses a seed equal
-to <b>ld-seed</b> plus the processor number.</dd>
-</dl>
-
-<A NAME="em"><br>
-<hr>
-<h3>Energy minimization<!--QuietIdx-->energy minimization<!--EQuietIdx--></h3>
-<dl>
-<dt><b>emtol: (10.0) [kJ mol<sup>-1</sup> nm<sup>-1</sup>]</b></dt>
-<dd>the minimization is converged when the maximum force is smaller than
-this value</dd>
-<dt><b>emstep: (0.01) [nm]</b></dt>
-<dd>initial step-size</dd>
-<dt><b>nstcgsteep: (1000) [steps]</b></dt>
-<dd>frequency of performing 1 steepest descent step while doing
-conjugate gradient energy minimization.</dd>
-<dt><b>nbfgscorr: (10)</b></dt>
-<dd>Number of correction steps to use for L-BFGS minimization. A higher
-number is (at least theoretically) more accurate, but slower.</dd>
-</dl>
-
-<A NAME="shellmd"><br>
-<hr>
-<h3>Shell Molecular Dynamics<!--QuietIdx-->shell molecular dynamics<!--EQuietIdx--></h3>
-When shells or
-flexible constraints are present in the system the positions of the shells
-and the lengths of the flexible constraints are optimized at
-every time step until either the RMS force on the shells and constraints
-is less than emtol, or a maximum number of iterations (niter) has been reached
-<dl>
-<dt><b>emtol: (10.0) [kJ mol<sup>-1</sup> nm<sup>-1</sup>]</b></dt>
-<dd>the minimization is converged when the maximum force is smaller than
-this value. For shell MD this value should be 1.0 at most, but since the
-variable is used for energy minimization as well the default is 10.0.</dd>
-<dt><b>niter: (20)</b></dt>
-<dd>maximum number of iterations for optimizing the shell positions
-and the flexible constraints.</dd>
-<dt><b>fcstep: (0) [ps<sup>2</sup>]</b></dt>
-<dd>the step size for optimizing the flexible constraints.
-Should be chosen as mu/(d<sup>2</sup>V/dq<sup>2</sup>)
-where mu is the reduced mass of two particles in a flexible constraint
-and d<sup>2</sup>V/dq<sup>2</sup> is the second derivative of the potential
-in the constraint direction. Hopefully this number does not differ too
-much between the flexible constraints, as the number of iterations
-and thus the runtime is very sensitive to <tt>fcstep</tt>.
-Try several values!</dd>
-</dl>
-
-<A NAME="tpi"><br>
-<hr>
-<h3>Test particle insertion</h3>
-<dl>
-<dt><b>rtpi: (0.05) [nm]</b></dt>
-<dd>the test particle insertion radius see integrators
-<b><a href="#run">tpi</a></b> and <b><a href="#run">tpic</a></b></dd>
-</dl>
-
-<A NAME="out"><br>
-<hr>
-<h3>Output control</h3>
-<dl>
-<dt><b>nstxout: (0) [steps]</b></dt>
-<dd>number of steps that elapse between writing coordinates to output
-<!--Idx-->trajectory file<!--EIdx-->, the last coordinates are always written</dd>
-<dt><b>nstvout: (0) [steps]</b></dt>
-<dd>number of steps that elapse between writing velocities to output trajectory,
-the last velocities are always written</dd>
-<dt><b>nstfout: (0) [steps]</b></dt>
-<dd>number of steps that elapse between writing forces to output trajectory.</dd>
-<dt><b>nstlog: (1000) [steps]</b></dt>
-<dd>number of steps that elapse between writing energies to the <!--Idx-->log file<!--EIdx-->,
-the last energies are always written</dd>
-<dt><b>nstcalcenergy: (100)</b></dt>
-<dd>number of steps that elapse between calculating the energies, 0 is never.
-This option is only relevant with dynamics.
-With a twin-range cut-off setup <b>nstcalcenergy</b> should be equal to
-or a multiple of <b>nstlist</b>.
-This option affects the performance in parallel simulations,
-because calculating energies requires global communication between all
-processes which can become a bottleneck at high parallelization.
-</dd>
-<dt><b>nstenergy: (1000) [steps]</b></dt>
-<dd>number of steps that else between writing energies to energy file,
-the last energies are always written,
-should be a multiple of <b>nstcalcenergy</b>.
-Note that the exact sums and fluctuations over all MD steps
-modulo <b>nstcalcenergy</b> are stored in the energy file,
-so <tt>g_energy</tt> can report exact
-energy averages and fluctuations also when <b>nstenergy</b><tt>>1</tt></dd>
-<dt><b>nstxout-compressed: (0) [steps]</b></dt>
-<dd>number of steps that elapse between writing position coordinates using lossy compression</dd>
-<dt><b>compressed-x-precision: (1000) [real]</b></dt>
-<dd>precision with which to write to the compressed trajectory file</dd>
-<dt><b>compressed-x-grps:</b></dt>
-<dd>group(s) to write to the compressed trajectory file, by default the whole system is written
-(if <b>nstxout-compressed</b> > 0)</dd>
-<dt><b>energygrps:</b></dt>
-<dd>group(s) to write to energy file</dd>
-</dl>
-
-<A NAME="nl"><br>
-<hr>
-<h3>Neighbor searching<!--QuietIdx-->neighbor searching<!--EQuietIdx--></h3>
-<dl>
-<dt><b>cutoff-scheme:</b></dt>
-<dd><dl compact>
-<dt><b>Verlet</b></dt>
-<dd>Generate a pair list with buffering. The buffer size is automatically set
-based on <b>verlet-buffer-tolerance</b>, unless this is set to -1, in which case
-<b>rlist</b> will be used. This option has an explicit, exact cut-off at
-<b>rvdw</b>=<b>rcoulomb</b>. Currently only cut-off, reaction-field,
-PME electrostatics and plain LJ are supported. Some <tt>mdrun</tt> functionality
-is not yet supported with the <b>Verlet</b> scheme, but <tt>grompp</tt> checks for this.
-Native GPU acceleration is only supported with <b>Verlet</b>.
-With GPU-accelerated PME or with separate PME ranks,
-<tt>mdrun</tt> will automatically tune the CPU/GPU load balance by
-scaling <b>rcoulomb</b> and the grid spacing. This can be turned off with
-<tt>-notunepme</tt>.
-
-<b>Verlet</b> is faster than <b>group</b> when there is no water, or if <b>group</b> would use a pair-list buffer to conserve energy.
-</dd>
-<dt><b>group</b></dt>
-<dd>Generate a pair list for groups of atoms. These groups correspond to the
-charge groups in the topology. This was the only cut-off treatment scheme
-before version 4.6.
-There is no explicit buffering of the pair list. This enables efficient force
-calculations for water, but energy is only conserved when a buffer is explicitly added.</dd>
-
-</dl></dd>
-
-<dt><b>nstlist: (10) [steps]</b></dt>
-<dd><dl compact>
-<dt><b>>0</b></dt>
-<dd>Frequency to update the <!--Idx-->neighbor list<!--EIdx--> (and
-the long-range forces, when using twin-range cut-offs). When this is 0,
-the neighbor list is made only once.
-With energy minimization the neighborlist will be updated for every
-energy evaluation when <b>nstlist</b><tt>>0</tt>.
-With <b>cutoff-scheme=Verlet</b> and <b>verlet-buffer-tolerance</b> set,
-<b>nstlist</b> is actually a minimum value and <tt>mdrun</tt> might increase it, unless it is set to 1.
-With parallel simulations and/or non-bonded force calculation on the GPU,
-a value of 20 or 40 often gives the best performance.
-With <b>cutoff-scheme=Group</b> and non-exact cut-off's, <b>nstlist</b> will
-affect the accuracy of your simulation and it can not be chosen freely.
-</dd>
-<dt><b>0</b></dt>
-<dd>The neighbor list is only constructed once and never updated.
-This is mainly useful for vacuum simulations in which all particles
-see each other.</dd>
-<dt><b><0</b></dt>
-<dd>Unused</dd>
-</dl></dd>
-
-<dt><b>nstcalclr: (-1) [steps]</b></dt>
-<dd>
-Controls the period between calculations of long-range forces when
-using the group cut-off scheme.
-<dl compact>
-<dt><b>1</b></dt>
-<dd>Calculate the long-range forces every single step. This is useful
-to have separate neighbor lists with buffers for electrostatics and Van
-der Waals interactions, and in particular it makes it possible to have
-the Van der Waals cutoff longer than electrostatics (useful e.g. with
-PME). However, there is no point in having identical long-range
-cutoffs for both interaction forms and update them every step - then
-it will be slightly faster to put everything in the short-range
-list.</dd>
-<dt><b>>1</b></dt>
-<dd>Calculate the long-range forces every <b>nstcalclr</b> steps and
-use a multiple-time-step integrator to combine forces. This can now be
-done more frequently than <b>nstlist</b> since the lists are stored,
-and it might be a good idea e.g. for Van der Waals interactions that
-vary slower than electrostatics.</dd>
-<dt><b>-1</b></dt>
-<dd>Calculate long-range forces on steps where neighbor searching is
-performed. While this is the default value, you might want to consider
-updating the long-range forces more frequently.</dd>
-</dl>
-Note that twin-range force evaluation might be enabled automatically
-by PP-PME load balancing. This is done in order to maintain the chosen
-Van der Waals interaction radius even if the load balancing is
-changing the electrostatics cutoff. If the <tt>.mdp</tt> file already
-specifies twin-range interactions (e.g. to evaluate Lennard-Jones
-interactions with a longer cutoff than the PME electrostatics every
-2-3 steps), the load balancing will have also a small effect on
-Lennard-Jones, since the short-range cutoff (inside which forces are
-evaluated every step) is changed.
-</dd>
-
-
-
-<dt><b>ns-type:</b></dt>
-<dd><dl compact>
-<dt><b>grid</b></dt>
-<dd>Make a grid in the box and only check atoms in neighboring grid
-cells when constructing a new neighbor list every <b>nstlist</b> steps.
-In large systems grid search is much faster than simple search.</dd>
-<dt><b>simple</b></dt>
-<dd>Check every atom in the box when constructing a new neighbor list
-every <b>nstlist</b> steps (only with <b>cutoff-scheme=group</b>).</dd>
-</dl></dd>
-
-<dt><b>pbc:</b></dt>
-<dd><dl compact>
-<dt><b>xyz</b></dt>
-<dd>Use periodic boundary conditions in all directions.</dd>
-<dt><b>no</b></dt>
-<dd>Use no periodic boundary conditions, ignore the box.
-To simulate without cut-offs, set all cut-offs to 0 and <b>nstlist</b><tt>=0</tt>.
-For best performance without cut-offs on a single MPI rank,
-use <b>nstlist</b><tt>=0</tt>, <b>ns-type</b><tt>=simple</tt></dd>
-<dt><b>xy</b></dt>
-<dd>Use periodic boundary conditions in x and y directions only.
-This works only with <b>ns-type</b><tt>=grid</tt> and can be used
-in combination with <b><a href="#walls">walls</a></b>.
-Without walls or with only one wall the system size is infinite
-in the z direction. Therefore pressure coupling or Ewald summation
-methods can not be used.
-These disadvantages do not apply when two walls are used.</dd>
-</dl></dd>
-
-<dt><b>periodic-molecules:</b></dt>
-<dd><dl compact>
-<dt><b>no</b></dt>
-<dd>molecules are finite, fast molecular PBC can be used</dd>
-<dt><b>yes</b></dt>
-<dd>for systems with molecules that couple to themselves through
-the periodic boundary conditions, this requires a slower PBC algorithm
-and molecules are not made whole in the output</dd>
-</dl></dd>
-
-<dt><b>verlet-buffer-tolerance: (0.005) [kJ/mol/ps]</b></dt>
-<dd>Useful only with <b>cutoff-scheme</b>=<b>Verlet</b>. This sets the maximum
-allowed error for pair interactions per particle caused by the Verlet buffer,
-which indirectly sets <b>rlist</b>.
-As both <b>nstlist</b> and the Verlet buffer size are fixed
-(for performance reasons), particle pairs not in the pair list can occasionally
-get within the cut-off distance during <b>nstlist</b>-1 nsteps. This
-causes very small jumps in the energy. In a constant-temperature ensemble,
-these very small energy jumps can be
-estimated for a given cut-off and <b>rlist</b>. The estimate assumes a
-homogeneous particle distribution, hence the errors might be slightly
-underestimated for multi-phase systems. For longer pair-list life-time
-(<b>nstlist</b>-1)*dt the buffer is overestimated, because the interactions
-between particles are ignored. Combined with cancellation of errors,
-the actual drift of the total energy is usually one to two orders of magnitude
-smaller.
-Note that the generated buffer size takes into account that
-the GROMACS pair-list setup leads to a reduction in the drift by
-a factor 10, compared to a simple particle-pair based list.
-Without dynamics (energy minimization etc.), the buffer is 5% of the cut-off.
-For NVE simulations the initial temperature is used, unless this is zero,
-in which case a buffer of 10% is used. For NVE simulations the tolerance
-usually needs to be lowered to achieve proper energy conservation on
-the nanosecond time scale. To override the automated buffer setting,
-use <b>verlet-buffer-tolerance</b>=-1 and set <b>rlist</b> manually.</dd>
-
-<dt><b>rlist: (1) [nm]</b></dt>
-<dd>Cut-off distance for the short-range neighbor list.
-With <b>cutoff-scheme</b>=<b>Verlet</b>, this is by default set by the
-<b>verlet-buffer-tolerance</b> option and the value of <b>rlist</b> is ignored.</dd>
-
-<dt><b>rlistlong: (-1) [nm]</b></dt>
-<dd>Cut-off distance for the long-range neighbor list.
-This parameter is only relevant for a twin-range cut-off setup
-with switched potentials. In that case a buffer region is required to account
-for the size of charge groups. In all other cases this parameter
-is automatically set to the longest cut-off distance.</dd>
-</dl>
-
-
-<A NAME="el"><br>
-<hr>
-<h3>Electrostatics<!--QuietIdx-->electrostatics<!--EQuietIdx--></h3>
-<dl>
-<dt><b>coulombtype:</b></dt>
-<dd><dl compact>
-
-<dt><b>Cut-off</b></dt>
-<dd>Twin range cut-offs with neighborlist cut-off <b>rlist</b> and
-Coulomb cut-off <b>rcoulomb</b>,
-where <b>rcoulomb</b>≥<b>rlist</b>.
-
-<dt><b>Ewald</b></dt>
-<dd>Classical <!--Idx-->Ewald sum<!--EIdx--> electrostatics.
-The real-space cut-off <b>rcoulomb</b> should be equal to <b>rlist</b>.
-Use e.g. <b>rlist</b><tt>=0.9</tt>, <b>rcoulomb</b><tt>=0.9</tt>. The highest magnitude of
-wave vectors used in reciprocal space is controlled by <b>fourierspacing</b>.
-The relative accuracy of direct/reciprocal space
-is controlled by <b>ewald-rtol</b>.
-<br>
-NOTE: Ewald scales as O(N<sup>3/2</sup>)
-and is thus extremely slow for large systems. It is included mainly for
-reference - in most cases PME will perform much better.</dd>
-
-<dt><b><!--Idx-->PME<!--EIdx--></b></dt>
-<dd>Fast smooth Particle-Mesh Ewald (SPME) electrostatics. Direct space is similar
-to the Ewald sum, while the reciprocal part is performed with
-FFTs. Grid dimensions are controlled with <b>fourierspacing</b> and the
-interpolation order with <b>pme-order</b>. With a grid spacing of 0.1
-nm and cubic interpolation the electrostatic forces have an accuracy
-of 2-3*10<sup>-4</sup>. Since the error from the vdw-cutoff is larger than this you
-might try 0.15 nm. When running in parallel the interpolation
-parallelizes better than the FFT, so try decreasing grid dimensions
-while increasing interpolation.</dd>
-
-<dt><b><!--Idx-->P3M-AD<!--EIdx--></b></dt>
-<dd>Particle-Particle Particle-Mesh algorithm with analytical derivative
-for for long range electrostatic interactions. The method and code
-is identical to SPME, except that the influence function is optimized
-for the grid. This gives a slight increase in accuracy.</dd>
-
-<dt><b>Reaction-Field electrostatics<!--QuietIdx-->reaction-field electrostatics<!--EQuietIdx--></b></dt>
-<dd>Reaction field with Coulomb cut-off <b>rcoulomb</b>,
-where <b>rcoulomb</b> ≥ <b>rlist</b>.
-The dielectric constant beyond the cut-off is <b>epsilon-rf</b>.
-The dielectric constant can be set to infinity by setting <b>epsilon-rf</b><tt>=0</tt>.</dd>
-
-<dt><b>Generalized-Reaction-Field</b></dt>
-<dd>Generalized reaction field with Coulomb cut-off <b>rcoulomb</b>,
-where <b>rcoulomb</b> ≥ <b>rlist</b>.
-The dielectric constant beyond the cut-off is <b>epsilon-rf</b>.
-The ionic strength is computed from the number of charged
-(i.e. with non zero charge) <!--Idx-->charge group<!--EIdx-->s.
-The temperature for the GRF potential is set with
-<b><A HREF="#tc">ref-t</A></b> [K].</dd>
-
-<dt><b>Reaction-Field-zero</b></dt>
-<dd>In GROMACS, normal reaction-field electrostatics with
-<b>cutoff-scheme</b><b>=group</b> leads to bad
-energy conservation. <b>Reaction-Field-zero</b> solves this
-by making the potential zero beyond the cut-off. It can only
-be used with an infinite dielectric constant (<b>epsilon-rf=0</b>),
-because only for that value the force vanishes at the cut-off.
-<b>rlist</b> should be 0.1 to 0.3 nm larger than <b>rcoulomb</b>
-to accommodate for the size of charge groups and diffusion
-between neighbor list updates. This, and the fact that table lookups
-are used instead of analytical functions make <b>Reaction-Field-zero</b>
-computationally more expensive than normal reaction-field.</dd>
-
-<dt><b>Reaction-Field-nec</b></dt>
-<dd>The same as <b>Reaction-Field</b>, but implemented as in
-GROMACS versions before 3.3. No reaction-field correction is applied
-to excluded atom pairs and self pairs.
-The 1-4 interactions are calculated using a reaction-field.
-The missing correction due to the excluded pairs that do not have a 1-4
-interaction is up to a few percent of the total electrostatic
-energy and causes a minor difference in the forces and the pressure.</dd>
-
-<dt><b>Shift</b></dt>
-<dd>Analogous to <b>Shift</b> for <b>vdwtype</b>.
-You might want to use <b>Reaction-Field-zero</b> instead,
-which has a similar potential shape, but has a physical interpretation
-and has better energies due to the exclusion correction terms.
-</dd>
-
-<dt><b>Encad-Shift</b></dt>
-<dd>The Coulomb
-potential is decreased over the whole range, using the definition
-from the Encad simulation package.</dd>
-
-<dt><b>Switch</b></dt>
-<dd>Analogous to <b>Switch</b> for <b>vdwtype</b>.
-Switching the Coulomb potential can lead to serious artifacts,
-advice: use <b>Reaction-Field-zero</b> instead.</dd>
-
-<dt><b>User</b></dt>
-<dd><a name="usertab"></a><tt>mdrun</tt> will now expect to find a file
-<tt>table.xvg</tt> with user-defined potential functions for
-repulsion, dispersion and Coulomb. When pair interactions are present,
-<tt>mdrun</tt> also expects to find a file <tt>tablep.xvg</tt> for
-the pair interactions. When the same interactions should be used
-for non-bonded and pair interactions the user can specify the same
-file name for both table files.
-These files should contain 7
-columns: the <tt>x</tt> value,
-<tt>f(x)</tt>, <tt>-f'(x)</tt>,
-<tt>g(x)</tt>, <tt>-g'(x)</tt>,
-<tt>h(x)</tt>, <tt>-h'(x)</tt>,
-where <tt>f(x)</tt> is the Coulomb function, <tt>g(x)</tt> the dispersion function
-and <tt>h(x)</tt> the repulsion function.
-When <b>vdwtype</b> is not set to <b>User</b> the values
-for <tt>g</tt>, <tt>-g'</tt>, <tt>h</tt> and <tt>-h'</tt> are ignored.
-For the non-bonded interactions <tt>x</tt> values should run
-from 0 to the largest cut-off distance + <b>table-extension</b>
-and should be uniformly spaced. For the pair interactions the table
-length in the file will be used.
-The optimal spacing, which is used for non-user tables,
-is <tt>0.002</tt> [nm] when you run in mixed precision
-or <tt>0.0005</tt> [nm] when you run in double precision.
-The function value at <tt>x=0</tt> is not important. More information is
-in the printed manual.</dd>
-
-<dt><b>PME-Switch</b></dt>
-<dd>A combination of PME and a switch function for the direct-space part
-(see above). <b>rcoulomb</b> is allowed to be smaller than <b>rlist</b>.
-This is mainly useful constant energy simulations (note that using
-<b>PME</b> with <b>cutoff-scheme</b>=<b>Verlet</b> will be more efficient).
-</dd>
-
-<dt><b>PME-User</b></dt>
-<dd>A combination of PME and user tables (see above).
-<b>rcoulomb</b> is allowed to be smaller than <b>rlist</b>.
-The PME mesh contribution is subtracted from the user table by <tt>mdrun</tt>.
-Because of this subtraction the user tables should contain
-about 10 decimal places.</dd>
-
-<dt><b>PME-User-Switch</b></dt>
-<dd>A combination of PME-User and a switching function (see above).
-The switching function is applied to final particle-particle interaction,
-i.e. both to the user supplied function and the PME Mesh correction part.</dd>
-
-</dl></dd>
-
-<dt><b>coulomb-modifier:</b></dt>
-<dd><dl compact>
-<dt><b>Potential-shift-Verlet</b></dt>
-<dd>Selects <b>Potential-shift</b> with the Verlet cutoff-scheme,
-as it is (nearly) free; selects <b>None</b> with the group cutoff-scheme.</dd>
-<dt><b>Potential-shift</b></dt>
-<dd>Shift the Coulomb potential by a constant such that it is zero at the cut-off.
-This makes the potential the integral of the force. Note that this does not
-affect the forces or the sampling.</dd>
-<dt><b>None</b></dt>
-<dd>Use an unmodified Coulomb potential. With the group scheme this means no exact cut-off is used, energies and forces are calculated for all pairs in the neighborlist.</dd>
-</dl></dd>
-
-
-<A NAME="el2">
-<dt><b>rcoulomb-switch: (0) [nm]</b></dt>
-<dd>where to start switching the Coulomb potential, only relevant when force or potential switching is used</dd>
-
-<dt><b>rcoulomb: (1) [nm]</b></dt>
-<dd>distance for the Coulomb <!--Idx-->cut-off<!--EIdx--></dd>
-
-<dt><b>epsilon-r: (1)</b></dt>
-<dd>The relative <!--Idx-->dielectric constant<!--EIdx-->.
-A value of 0 means infinity.</dd>
-
-<dt><b>epsilon-rf: (0)</b></dt>
-<dd>The relative dielectric constant of the reaction field.
-This is only used with reaction-field electrostatics.
-A value of 0 means infinity.</dd>
-</dl>
-
-<A NAME="vdw">
-<hr>
-<h3>VdW</h3>
-<dl>
-<dt><b>vdwtype:</b></dt>
-<dd><dl compact>
-<dt><b>Cut-off</b></dt>
-<dd>Twin range cut-offs with neighbor list cut-off <b>rlist</b> and
-VdW cut-off <b>rvdw</b>,
-where <b>rvdw</b> <tt>≥</tt> <b>rlist</b>.</dd>
-
-<dt><b>PME</b></dt>
-<dd>Fast smooth Particle-mesh Ewald (SPME) for VdW interactions. The
-grid dimensions are controlled with <b>fourierspacing</b> in the same
-way as for electrostatics, and the interpolation order is controlled
-with <b>pme-order</b>. The relative accuracy of direct/reciprocal
-space is controlled by <b>ewald-rtol-lj</b>, and the specific
-combination rules that are to be used by the reciprocal routine are
-set using <b>lj-pme-comb-rule</b>.</dd>
-
-<dt><b>Shift</b></dt>
-<dd>This functionality is deprecated and replaced by <b>vdw-modifier = Force-switch</b>.
-The LJ (not Buckingham) potential is decreased over the whole
-range and the forces decay smoothly to zero between <b>rvdw-switch</b>
-and <b>rvdw</b>. The neighbor search cut-off <b>rlist</b> should be
-0.1 to 0.3 nm larger than <b>rvdw</b> to accommodate for the size of
-charge groups and diffusion between neighbor list
-updates.</dd>
-
-<dt><b>Switch</b></dt>
-<dd>This functionality is deprecated and replaced by <b>vdw-modifier = Potential-switch</b>.
-The LJ (not Buckingham)
-potential is normal out to <b>rvdw-switch</b>, after which it is switched
-off to reach zero at <b>rvdw</b>. Both the potential and force functions
-are continuously smooth, but be aware that all switch functions will give rise
-to a bulge (increase) in the force (since we are switching the potential).
-The neighbor search cut-off <b>rlist</b> should be 0.1 to 0.3 nm larger than
-<b>rvdw</b> to accommodate for the size of charge groups and diffusion
-between neighbor list updates.</dd>
-
-<dt><b>Encad-Shift</b></dt>
-<dd>The LJ (not Buckingham)
-potential is decreased over the whole range, using the definition
-from the Encad simulation package.</dd>
-
-<dt><b>User</b></dt>
-<dd>See <b><a href="#usertab">user</a></b> for <b>coulombtype</b>.
-The function value at <tt>x=0</tt> is not important. When you want to
-use LJ correction, make sure that <b>rvdw</b> corresponds to the
-cut-off in the user-defined function.
-When <b>coulombtype</b> is not set to <b>User</b> the values
-for <tt>f</tt> and <tt>-f'</tt> are ignored.</dd>
-</dl></dd>
-
-<dt><b>vdw-modifier:</b></dt>
-<dd><dl compact>
-<dt><b>Potential-shift-Verlet</b></dt>
-<dd>Selects <b>Potential-shift</b> with the Verlet cutoff-scheme,
-as it is (nearly) free; selects <b>None</b> with the group cutoff-scheme.</dd>
-<dt><b>Potential-shift</b></dt>
-<dd>Shift the Van der Waals potential by a constant such that it is zero at the cut-off.
-This makes the potential the integral of the force. Note that this does not
-affect the forces or the sampling.</dd>
-<dt><b>None</b></dt>
-<dd>Use an unmodified Van der Waals potential. With the group scheme this means no exact cut-off is used, energies and forces are calculated for all pairs in the neighborlist.</dd>
-<dt><b>Force-switch</b></dt>
-<dd>Smoothly switches the forces to zero between <b>rvdw-switch</b> and <b>rvdw</b>. This shifts the potential shift over the whole range and switches it to zero at the cut-off. Note that this is more expensive to calculate than a plain cut-off and it is not required for energy conservation, since <b>Potential-shift</b> conserves energy just as well.</dd>
-<dt><b>Potential-switch</b></dt>
-<dd>Smoothly switches the potential to zero between <b>rvdw-switch</b> and <b>rvdw</b>. Note that this introduces articifically large forces in the switching region and is much more expensive to calculate. This option should only be used if the force field you are using requires this.</dd>
-</dl></dd>
-
-<dt><b>rvdw-switch: (0) [nm]</b></dt>
-<dd>where to start switching the LJ force and possibly the potential, only relevant when force or potential switching is used</dd>
-
-<dt><b>rvdw: (1) [nm]</b></dt>
-<dd>distance for the LJ or Buckingham <!--Idx-->cut-off<!--EIdx--></dd>
-
-<dt><b>DispCorr:</b></dt>
-<dd><dl compact></dd>
-<dt><b>no</b></dt>
-<dd>don't apply any correction</dd>
-<dt><b>EnerPres</b></dt>
-<dd>apply long range <!--Idx-->dispersion correction<!--EIdx-->s for Energy
-and Pressure</dd>
-<dt><b>Ener</b></dt>
-<dd>apply long range dispersion corrections for Energy
-only</dd>
-</dl>
-</dl>
-
-<A NAME="table">
-<hr>
-<h3>Tables</h3>
-<dl>
-<dt><b>table-extension: (1) [nm]</b></dt>
-<dd>Extension of the non-bonded potential lookup tables beyond the largest cut-off distance.
-The value should be large enough to account for charge group sizes
-and the diffusion between neighbor-list updates.
-Without user defined potential the same table length is used
-for the lookup tables for the 1-4 interactions,
-which are always tabulated irrespective of the use of
-tables for the non-bonded interactions. The value of <b>table-extension</b> in no way
-affects the values of <b>rlist</b>, <b>rcoulomb</b>, or <b>rvdw</b>. </dd>
-
-<dt><b>energygrp-table:</b></dt>
-<dd>When user tables are used for electrostatics and/or VdW,
-here one can give pairs of energy groups for which seperate
-user tables should be used.
-The two energy groups will be appended to the table file name,
-in order of their definition in <b>energygrps</b>, seperated by underscores.
-For example, if <tt>energygrps = Na Cl Sol</tt>
-and <tt>energygrp-table = Na Na Na Cl</tt>, <tt>mdrun</tt> will read
-<tt>table_Na_Na.xvg</tt> and <tt>table_Na_Cl.xvg</tt> in addition
-to the normal <tt>table.xvg</tt> which will be used for all other
-energy group pairs.
-</dd>
-</dl>
-
-<A NAME="ewald">
-<hr>
-<h3>Ewald</h3>
-<dl>
-<dt><b>fourierspacing: (0.12) [nm]</b></dt>
-<dd>For ordinary Ewald, the ratio of the box dimensions and the spacing
-determines a lower bound for the number of wave vectors to use in each
-(signed) direction. For PME and P3M, that ratio determines a lower bound
-for the number of Fourier-space grid points that will be used along that
-axis. In all cases, the number for each direction can be overridden by
-entering a non-zero value for <b>fourier_n[xyz]</b>.
-For optimizing the relative load of the particle-particle interactions
-and the mesh part of PME, it is useful to know that
-the accuracy of the electrostatics remains nearly constant
-when the Coulomb cut-off and the PME grid spacing are scaled
-by the same factor.</dd>
-
-<dt><b>fourier-nx (0) ; fourier-ny (0) ; fourier-nz: (0)</b></dt>
-<dd>Highest magnitude of wave vectors in reciprocal space when using Ewald.</dd>
-<dd>Grid size when using PME or P3M. These values override
-<b>fourierspacing</b> per direction. The best choice is powers of
-2, 3, 5 and 7. Avoid large primes.</dd>
-
-<dt><b>pme-order (4)</b></dt>
-<dd>Interpolation order for PME. 4 equals cubic interpolation. You might try
-6/8/10 when running in parallel and simultaneously decrease grid dimension.</dd>
-
-<dt><b>ewald-rtol (1e-5)</b></dt>
-<dd>The relative strength of the Ewald-shifted direct potential at
-<b>rcoulomb</b> is given by <b>ewald-rtol</b>.
-Decreasing this will give a more accurate direct sum,
-but then you need more wave vectors for the reciprocal sum.</dd>
-
-<dt><b>ewald-rtol-lj (1e-3)</b></dt>
-<dd>When doing PME for VdW-interactions, <b>ewald-rtol-lj</b> is used
-to control the relative strength of the dispersion potential at <b>rvdw</b> in
-the same way as <b>ewald-rtol</b> controls the electrostatic potential.</dd>
-
-<dt><b>lj-pme-comb-rule (Geometric)</b></dt>
-<dd>The combination rules used to combine VdW-parameters in the reciprocal part of LJ-PME.
-Geometric rules are much faster than Lorentz-Berthelot and usually the recommended choice, even
-when the rest of the force field uses the Lorentz-Berthelot rules.</dd>
-<dd><dl compact>
-<dt><b>Geometric</b></dt>
-<dd>Apply geometric combination rules</dd>
-<dt><b>Lorentz-Berthelot</b></dt>
-<dd>Apply Lorentz-Berthelot combination rules</dd>
-</dl></dd>
-
-<dt><b>ewald-geometry: (3d)</b></dt>
-<dd><dl compact>
-<dt><b>3d</b></dt>
-<dd>The Ewald sum is performed in all three dimensions.</dd>
-<dt><b>3dc</b></dt>
-<dd>The reciprocal sum is still performed in 3D,
-but a force and potential correction applied in the <tt>z</tt>
-dimension to produce a pseudo-2D summation.
-If your system has a slab geometry in the <tt>x-y</tt> plane you can
-try to increase the <tt>z</tt>-dimension of the box (a box height of 3 times
-the slab height is usually ok)
-and use this option.</dd>
-</dl></dd>
-
-<dt><b>epsilon-surface: (0)</b></dt>
-<dd>This controls the dipole correction to the Ewald summation in 3D. The
-default value of zero means it is turned off. Turn it on by setting it to the value
-of the relative permittivity of the imaginary surface around your infinite system. Be
-careful - you shouldn't use this if you have free mobile charges in your system.
-This value does not affect the slab 3DC variant of the long range corrections.</dd>
-
-</dl>
-
-<A NAME="tc"><br>
-<hr>
-<h3>Temperature coupling<!--QuietIdx-->temperature coupling<!--EQuietIdx--></h3>
-
-<dl>
-<dt><b>tcoupl:</b></dt>
-<dd><dl compact>
-<dt><b>no</b></dt>
-<dd>No temperature coupling.</dd>
-<dt><b>berendsen</b></dt>
-<dd>Temperature coupling with a Berendsen-thermostat to a bath with
-temperature <b>ref-t</b> [K], with time constant <b>tau-t</b> [ps].
-Several groups can be coupled separately, these are specified in the
-<b>tc-grps</b> field separated by spaces.</dd>
-<dt><b>nose-hoover</b></dt>
-<dd>Temperature coupling using a Nose-Hoover extended
-ensemble. The reference temperature and coupling groups are selected
-as above, but in this case <b>tau-t</b> [ps] controls the period
-of the temperature fluctuations at equilibrium, which is slightly
-different from a relaxation time.
-For NVT simulations the conserved energy quantity is written
-to energy and log file.</dd>
-<dt><b>andersen</b></dt>
-<dd>Temperature coupling by randomizing a fraction of the particles
-at each timestep. Reference temperature and coupling groups are selected
-as above. <b>tau-t</b> is the average time between randomization of each molecule.
-Inhibits particle dynamics somewhat, but little or no ergodicity issues. Currently
-only implemented with velocity Verlet, and not implemented with constraints.</dd>
-<dt><b>andersen-massive</b></dt>
-<dd>Temperature coupling by randomizing all particles at infrequent timesteps.
-Reference temperature and coupling groups are selected
-as above. <b>tau-t</b> is the time between randomization of all molecules.
-Inhibits particle dynamics somewhat, but little or no ergodicity issues. Currently
-only implemented with velocity Verlet.</dd>
-<dt><b>v-rescale</b></dt>
-<dd>Temperature coupling using velocity rescaling with a stochastic term
-(JCP 126, 014101).
-This thermostat is similar to Berendsen coupling, with the same scaling
-using <b>tau-t</b>, but the stochastic term ensures that a proper
-canonical ensemble is generated. The random seed is set with
-<b><A HREF="#ld">ld-seed</A></b>.
-This thermostat works correctly even for <b>tau-t</b><tt>=0</tt>.
-For NVT simulations the conserved energy quantity is written
-to the energy and log file.</dd>
-</dl>
-<dt><b>nsttcouple: (-1)</b></dt>
-<dd>The frequency for coupling the temperature.
-The default value of -1 sets <b>nsttcouple</b> equal to <b>nstlist</b>,
-unless <b>nstlist</b>≤0, then a value of 10 is used.
-For velocity Verlet integrators <b>nsttcouple</b> is set to 1.</dd>
-</dd>
-<dt><b>nh-chain-length (10)</b></dt>
-<dd>the number of chained Nose-Hoover thermostats for velocity Verlet integrators, the leap-frog <b>md</b> integrator only supports 1. Data for the NH chain variables is not printed to the .edr, but can be using the <tt>GMX_NOSEHOOVER_CHAINS</tt> environment variable</dd>
-<dt><b>tc-grps:</b></dt>
-<dd>groups to couple separately to temperature bath</dd>
-<dt><b>tau-t: [ps]</b></dt>
-<dd>time constant for coupling (one for each group in <b>tc-grps</b>),
--1 means no temperature coupling</dd>
-<dt><b>ref-t: [K]</b></dt>
-<dd>reference temperature for coupling (one for each group in <b>tc-grps</b>)</dd>
-</dl>
-
-<A NAME="pc"><br>
-<hr>
-<h3>Pressure coupling<!--QuietIdx-->pressure coupling<!--EQuietIdx--></h3>
-
-<dl>
-<dt><b>pcoupl:</b></dt>
-<dd><dl compact>
-<dt><b>no</b></dt>
-<dd>No pressure coupling. This means a fixed box size.</dd>
-<dt><b>berendsen</b></dt>
-<dd>Exponential relaxation pressure coupling with time constant
-<b>tau-p</b> [ps]. The box is scaled every timestep. It has been
-argued that this does not yield a correct thermodynamic ensemble,
-but it is the most efficient way to scale a box at the beginning
-of a run.</dd>
-<dt><b>Parrinello-Rahman</b></dt>
-<dd>Extended-ensemble pressure coupling where the box vectors are
-subject to an equation of motion. The equation of motion for the atoms
-is coupled to this. No instantaneous scaling takes place. As for
-Nose-Hoover temperature coupling the time constant <b>tau-p</b> [ps]
-is the period of pressure fluctuations at equilibrium. This is
-probably a better method when you want to apply pressure scaling
-during data collection, but beware that you can get very large
-oscillations if you are starting from a different pressure. For
-simulations where the exact fluctation of the NPT ensemble are
-important, or if the pressure coupling time is very short it may not
-be appropriate, as the previous time step pressure is used in some
-steps of the GROMACS implementation for the current time step pressure.</dd>
-</dl></dd>
-<dt><b>MTTK</b></dt>
-<dd>Martyna-Tuckerman-Tobias-Klein implementation, only useable with <b>md-vv</b>
-or <b>md-vv-avek</b>, very similar to Parrinello-Rahman.
-As for Nose-Hoover temperature coupling the time constant <b>tau-p</b>
-[ps] is the period of pressure fluctuations at equilibrium. This is
-probably a better method when you want to apply pressure scaling
-during data collection, but beware that you can get very large
-oscillations if you are starting from a different pressure. Currently (as of version 5.1), it
-only supports isotropic scaling, and only works without constraints.</dd>
-</dl></dd>
-
-<dl>
-<dt><b>pcoupltype:</b></dt>
-<dd><dl compact>
-<dt><b>isotropic</b></dt>
-<dd>Isotropic pressure coupling with time constant <b>tau-p</b> [ps].
-The compressibility and reference pressure are set with
-<b>compressibility</b> [bar<sup>-1</sup>] and <b>ref-p</b> [bar], one
-value is needed.</dd>
-<dt><b>semiisotropic</b></dt>
-<dd>Pressure coupling which is isotropic in the <tt>x</tt> and <tt>y</tt> direction,
-but different in the <tt>z</tt> direction.
-This can be useful for membrane simulations.
-2 values are needed for <tt>x/y</tt> and <tt>z</tt> directions respectively.</dd>
-<dt><b>anisotropic</b></dt>
-<dd>Idem, but 6 values are needed for <tt>xx</tt>, <tt>yy</tt>, <tt>zz</tt>, <tt>xy/yx</tt>, <tt>xz/zx</tt> and <tt>yz/zy</tt>
-components, respectively.
-When the off-diagonal compressibilities are set to zero,
-a rectangular box will stay rectangular.
-Beware that anisotropic scaling can lead to extreme deformation
-of the simulation box.</dd>
-<dt><b>surface-tension</b></dt>
-<dd>Surface tension coupling for surfaces parallel to the xy-plane.
-Uses normal pressure coupling for the <tt>z</tt>-direction, while the surface tension
-is coupled to the <tt>x/y</tt> dimensions of the box.
-The first <b>ref-p</b> value is the reference surface tension times
-the number of surfaces [bar nm],
-the second value is the reference <tt>z</tt>-pressure [bar].
-The two <b>compressibility</b> [bar<sup>-1</sup>] values are the compressibility
-in the <tt>x/y</tt> and <tt>z</tt> direction respectively.
-The value for the <tt>z</tt>-compressibility should be reasonably accurate since it
-influences the convergence of the surface-tension, it can also be set to zero
-to have a box with constant height.</dd>
-</dl></dd>
-
-<dt><b>nstpcouple: (-1)</b></dt>
-<dd>The frequency for coupling the pressure.
-The default value of -1 sets <b>nstpcouple</b> equal to <b>nstlist</b>,
-unless <b>nstlist</b> ≤0, then a value of 10 is used.
-For velocity Verlet integrators <b>nstpcouple</b> is set to 1.</dd>
-</dd>
-
-<dt><b>tau-p: (1) [ps]</b></dt>
-<dd>time constant for coupling</dd>
-<dt><b>compressibility: [bar<sup>-1</sup>]</b></dt>
-<dd>compressibility (NOTE: this is now really in bar<sup>-1</sup>)
-For water at 1 atm and 300 K the compressibility is 4.5e-5 [bar<sup>-1</sup>].</dd>
-<dt><b>ref-p: [bar]</b></dt>
-<dd>reference pressure for coupling</dd>
-<dt><b>refcoord-scaling:</b></dt>
-<dd><dl compact>
-<dt><b>no</b></dt>
-<dd>The reference coordinates for position restraints are not modified.
-Note that with this option the virial and pressure will depend on the absolute
-positions of the reference coordinates.</dd>
-<dt><b>all</b></dt>
-<dd>The reference coordinates are scaled with the scaling matrix of the pressure coupling.</dd>
-<dt><b>com</b></dt>
-<dd>Scale the center of mass of the reference coordinates with the scaling matrix of the pressure coupling. The vectors of each reference coordinate to the center of mass are not scaled. Only one COM is used, even when there are multiple molecules with position restraints. For calculating the COM of the reference coordinates in the starting configuration, periodic boundary conditions are not taken into account.
-</dl></dd>
-</dd>
-</dl>
-
-<A NAME="sa"><br>
-<hr>
-<h3>Simulated annealing<!--QuietIdx-->simulated annealing<!--EQuietIdx--></h3>
-
-Simulated annealing is controlled separately for each temperature group in GROMACS. The reference temperature is a piecewise linear function, but you can use an arbitrary number of points for each group, and choose either a single sequence or a periodic behaviour for each group. The actual annealing is performed by dynamically changing the reference temperature used in the thermostat algorithm selected, so remember that the system will usually not instantaneously reach the reference temperature!
-<dl>
-<dt><b>annealing:</b></dt>
-<dd>Type of annealing for each temperature group</dd>
-<dd><dl compact></dd>
-<dt><b>no</b></dt>
-<dd>No simulated annealing - just couple to reference temperature value.</dd>
-<dt><b>single</b></dt>
-<dd>A single sequence of annealing points. If your simulation is longer than the time of the last point, the temperature will be coupled to this constant value after the annealing sequence has reached the last time point.</dd>
-<dt><b>periodic</b></dt>
-<dd>The annealing will start over at the first reference point once the last reference time is reached. This is repeated until the simulation ends.
-</dd>
-</dl>
-
-<dt><b>annealing-npoints:</b></dt>
-<dd>A list with the number of annealing reference/control points used for
-each temperature group. Use 0 for groups that are not annealed. The number of entries should equal the number of temperature groups.</dd>
-
-<dt><b>annealing-time:</b></dt>
-<dd>List of times at the annealing reference/control points for each group. If you are using periodic annealing, the times will be used modulo the last value, i.e. if the values are 0, 5, 10, and 15, the coupling will restart at the 0ps value after 15ps, 30ps, 45ps, etc. The number of entries should equal the sum of the numbers given in <tt>annealing-npoints</tt>.</dd>
-
-<dt><b>annealing-temp:</b></dt>
-<dd>List of temperatures at the annealing reference/control points for each group. The number of entries should equal the sum of the numbers given in <tt>annealing-npoints</tt>.</dd>
-<br>
-Confused? OK, let's use an example. Assume you have two temperature groups, set the group selections to <tt>annealing = single periodic</tt>, the number of points of each group to <tt>annealing-npoints = 3 4</tt>, the times to <tt>annealing-time = 0 3 6 0 2 4 6</tt> and finally temperatures to <tt>annealing-temp = 298 280 270 298 320 320 298</tt>.
-The first group will be coupled to 298K at 0ps, but the reference temperature will drop linearly to reach 280K at 3ps, and then linearly between 280K and 270K from 3ps to 6ps. After this is stays constant, at 270K. The second group is coupled to 298K at 0ps, it increases linearly to 320K at 2ps, where it stays constant until 4ps. Between 4ps and 6ps it decreases to 298K, and then it starts over with the same pattern again, i.e. rising linearly from 298K to 320K between 6ps and 8ps. Check the summary printed by <tt>grompp</tt> if you are unsure!
-</dl>
-
-<A NAME="vel"><br>
-<hr>
-<h3>Velocity generation</h3>
-
-<dl>
-<dt><b>gen-vel:</b></dt>
-<dd><dl compact>
-<dt><b>no</b></dt>
-<dd> Do not generate velocities. The velocities are set to zero
-when there are no velocities in the input structure file.</dd>
-<dt><b>yes</b></dt>
-<dd>Generate velocities in <tt>grompp</tt> according to a Maxwell distribution at
-temperature <b>gen-temp</b> [K], with random seed <b>gen-seed</b>.
-This is only meaningful with integrator <b><A HREF="#run">md</A></b>.</dd>
-</dl></dd>
-<dt><b>gen-temp: (300) [K]</b></dt>
-<dd>temperature for Maxwell distribution</dd>
-<dt><b>gen-seed: (-1) [integer]</b></dt>
-<dd>used to initialize random generator for random velocities,
-when <b>gen-seed</b> is set to -1, a pseudo random seed is used.
-</dl>
-
-<A NAME="bond"><br>
-<hr>
-<h3>Bonds</h3>
-
-<dl>
-<dt><b>constraints<!--QuietIdx-->constraint algorithms<!--EQuietIdx-->:</b></dt>
-<dd><dl compact>
-<dt><b>none</b></dt>
-<dd>No constraints except for those defined explicitly in the topology,
-i.e. bonds are represented by a harmonic (or other) potential
-or a Morse potential (depending on the setting of <b>morse</b>)
-and angles by a harmonic (or other) potential.
-<dt><b>h-bonds</b></dt>
-<dd>Convert the bonds with H-atoms to constraints.</dd>
-<dt><b>all-bonds</b></dt>
-<dd>Convert all bonds to constraints.</dd>
-<dt><b>h-angles</b></dt>
-<dd>Convert all bonds and additionally the angles that involve H-atoms
-to bond-constraints.</dd>
-<dt><b>all-angles</b></dt>
-<dd>Convert all bonds and angles to bond-constraints.</dd>
-</dl>
-
-<dt><b>constraint-algorithm:</b></dt>
-<dd><dl compact>
-<dt><b><!--Idx-->LINCS<!--EIdx--></b></dt>
-<dd>LINear Constraint Solver.
-With domain decomposition the parallel version P-LINCS is used.
-The accuracy in set with
-<b>lincs-order</b>, which sets the number of matrices in the expansion
-for the matrix inversion.
-After the matrix inversion correction the algorithm does
-an iterative correction to compensate for lengthening due to rotation.
-The number of such iterations can be controlled with
-<b>lincs-iter</b>. The root mean square relative constraint deviation
-is printed to the log file every <b>nstlog</b> steps.
-If a bond rotates more than <b>lincs-warnangle</b> [degrees] in one step,
-a warning will be printed both to the log file and to <TT>stderr</TT>.
-LINCS should not be used with coupled angle constraints.
-</dd>
-<dt><b><!--Idx-->SHAKE<!--EIdx--></b></dt>
-<dd>SHAKE is slightly slower and less stable than LINCS, but does work with
-angle constraints.
-The relative tolerance is set with <b>shake-tol</b>, 0.0001 is a good value
-for ``normal'' MD. SHAKE does not support constraints between atoms
-on different nodes, thus it can not be used with domain decompositon
-when inter charge-group constraints are present.
-SHAKE can not be used with energy minimization.
-</dd>
-</dl></dd>
-<dt><b>continuation:</b></dt>
-<dd>This option was formerly known as <tt>unconstrained-start</tt>.</dd>
-<dd><dl compact>
-<dt><b>no</b></dt>
-<dd>apply constraints to the start configuration and reset shells</dd>
-<dt><b>yes</b></dt>
-<dd>do not apply constraints to the start configuration
-and do not reset shells, useful for exact coninuation and reruns</dd>
-</dl></dd>
-
-<A NAME="bond2">
-<dt><b>shake-tol: (0.0001)</b></dt>
-<dd>relative tolerance for SHAKE</dd>
-<dt><b>lincs-order: (4)</b></dt>
-<dd>Highest order in the expansion of the constraint coupling matrix.
-When constraints form triangles, an additional expansion of the same
-order is applied on top of the normal expansion only for the couplings
-within such triangles.
-For ``normal'' MD simulations an order of 4 usually suffices, 6 is
-needed for large time-steps with virtual sites or BD.
-For accurate energy minimization an order of 8 or more might be required.
-With domain decomposition, the cell size is limited by the distance
-spanned by <b>lincs-order</b>+1 constraints. When one wants to scale
-further than this limit, one can decrease <b>lincs-order</b> and increase
-<b>lincs-iter</b>, since the accuracy does not deteriorate
-when (1+<b>lincs-iter</b>)*<b>lincs-order</b> remains constant.</dd>
-<dt><b>lincs-iter: (1)</b></dt>
-<dd>Number of iterations to correct for rotational lengthening in LINCS.
-For normal runs a single step is sufficient, but for NVE
-runs where you want to conserve energy accurately or for accurate
-energy minimization you might want to increase it to 2.
-<dt><b>lincs-warnangle: </b>(30) [degrees]</dt>
-<dd>maximum angle that a bond can rotate before LINCS will complain</dd>
-
-<dt><b>morse:</b></dt>
-<dd><dl compact>
-<dt><b>no</b></dt>
-<dd>bonds are represented by a harmonic potential</dd>
-<dt><b>yes</b></dt>
-<dd>bonds are represented by a Morse potential</dd>
-</dl></dd>
-</dl>
-
-<A NAME="egexcl"><br>
-<hr>
-<h3>Energy group <!--Idx-->exclusions<!--EIdx--></h3>
-<dl>
-<dt><b>energygrp-excl: </b></dt>
-<dd>Pairs of energy groups for which all non-bonded interactions are
-excluded. An example: if you have two energy groups <tt>Protein</tt>
-and <tt>SOL</tt>, specifying
-<br>
-<tt>energygrp-excl = Protein Protein SOL SOL</tt>
-<br>
-would give only the non-bonded interactions between the protein and the
-solvent. This is especially useful for speeding up energy calculations with
-<tt>mdrun -rerun</tt> and for excluding interactions within frozen groups.</dd>
-</dl>
-
-<A NAME="walls"><br>
-<hr>
-<h3>Walls<!--QuietIdx-->walls<!--EQuietIdx--></h3>
-<dl>
-<dt><b>nwall: 0</b></dt>
-<dd>When set to <b>1</b> there is a wall at <tt>z=0</tt>, when set to <b>2</b>
-there is also a wall at <tt>z=z-box</tt>. Walls can only be used with <b>pbc=xy</b>.
-When set to <b>2</b> pressure coupling and Ewald summation can be used
-(it is usually best to use semiisotropic pressure coupling with
-the <tt>x/y</tt> compressibility set to 0, as otherwise the surface area will change).
-Walls interact wit the rest of the system through an optional <tt>wall-atomtype</tt>.
-Energy groups <tt>wall0</tt> and <tt>wall1</tt> (for <b>nwall=2</b>) are
-added automatically to monitor the interaction of energy groups
-with each wall.
-The <A HREF="#run">center of mass motion removal</A> will be turned
-off in the <tt>z</tt>-direction.</dd>
-<dt><b>wall-atomtype:</b></dt>
-<dd>the atom type name in the force field for each wall.
-By (for example) defining a special wall atom type in the topology with its
-own combination rules, this allows for independent tuning of the interaction
-of each atomtype with the walls.</dd>
-<dt><b>wall-type:</b></dt>
-<dd><dl compact>
-<dt><b>9-3</b></dt>
-<dd>LJ integrated over the volume behind the wall: 9-3 potential</dd>
-<dt><b>10-4</b></dt>
-<dd>LJ integrated over the wall surface: 10-4 potential</dd>
-<dt><b>12-6</b></dt>
-<dd>direct LJ potential with the z distance from the wall</dd>
-<dt><b>table</b></dt><dd>user defined potentials indexed with the z distance from the wall, the tables are read analogously to
-the <b><A HREF="#table">energygrp-table</A></b> option,
-where the first name is for a ``normal'' energy group and the second name
-is <tt>wall0</tt> or <tt>wall1</tt>,
-only the dispersion and repulsion columns are used</dd>
-</dl></dd>
-<dt><b>wall-r-linpot: -1 (nm)</b></dt>
-<dd>Below this distance from the wall the potential is continued
-linearly and thus the force is constant. Setting this option to
-a postive value is especially useful for equilibration when some atoms
-are beyond a wall.
-When the value is ≤0 (<0 for <b>wall-type=table</b>),
-a fatal error is generated when atoms are beyond a wall.
-</dd>
-<dt><b>wall-density: [nm<sup>-3</sup>/nm<sup>-2</sup>]</b></dt>
-<dd>the number density of the atoms for each wall for wall types
-<b>9-3</b> and <b>10-4</b>
-<dt><b>wall-ewald-zfac: 3</b></dt>
-<dd>The scaling factor for the third box vector for Ewald summation only,
-the minimum is 2.
-Ewald summation can only be used with <b>nwall=2</b>, where one
-should use <b><A HREF="#ewald">ewald-geometry</A><tt>=3dc</tt></b>.
-The empty layer in the box serves to decrease the unphysical Coulomb
-interaction between periodic images.</dd>
-</dl>
-
-<A NAME="pull"><br>
-<hr>
-<h3>COM <!--Idx-->pulling<!--EIdx--></h3>
-<dl>
-<dt><b>pull:</b></dt>
-<dd><dl compact>
-<dt><b>no</b></dt>
-<dd>No center of mass pulling.
-All the following pull options will be ignored
-(and if present in the <tt>.mdp</tt> file, they unfortunately generate warnings)</dd>
-<dt><b>umbrella</b></dt>
-<dd>Center of mass pulling using an umbrella potential
-between the reference group and one or more groups.</dd>
-<dt><b>constraint</b></dt>
-<dd>Center of mass pulling using a constraint
-between the reference group and one or more groups.
-The setup is identical to the option <b>umbrella</b>, except for the fact
-that a rigid constraint is applied instead of a harmonic potential.</dd>
-<dt><b>constant-force</b></dt>
-<dd>Center of mass pulling using a linear potential and therefore
-a constant force. For this option there is no reference position
-and therefore the parameters <b>pull-init</b> and <b>pull-rate</b>
-are not used.</dd>
-</dl></dd>
-<dt><b>pull-geometry:</b></dt>
-<dd><dl compact>
-<dt><b>distance</b></dt>
-<dd>Pull along the vector connecting the two groups.
-Components can be selected with <b>pull-dim</b>.</dd>
-<dt><b>direction</b></dt>
-<dd>Pull in the direction of <b>pull-vec</b>.</dd>
-<dt><b>direction-periodic</b></dt>
-<dd>As <b>direction</b>, but allows the distance to be larger than
-half the box size. With this geometry the box should not be dynamic
-(e.g. no pressure scaling) in the pull dimensions and the pull force
-is not added to virial.</dd>
-<dt><b>cylinder</b></dt>
-<dd>Designed for pulling with respect to a layer where the reference COM
-is given by a local cylindrical part of the reference group.
-The pulling is in the direction of <b>pull-vec</b>.
-From the reference group a cylinder is selected around the axis going
-through the pull group with direction <b>pull-vec</b> using two radii.
-The radius <b>pull-r1</b> gives the radius within which all
-the relative weights are one, between <b>pull-r1</b> and
-<b>pull-r0</b> the weights are switched to zero. Mass weighting is also used.
-Note that the radii should be smaller than half the box size.
-For tilted cylinders they should be even smaller than half the box size
-since the distance of an atom in the reference group
-from the COM of the pull group has both a radial and an axial component.</dd>
-</dl></dd>
-<dt><b>pull-dim: (Y Y Y)</b></dt>
-<dd>the distance components to be used with geometry <b>distance</b>,
-and also sets which components are printed
-to the output files</dd>
-<dt><b>pull-r1: (1) [nm]</b></dt>
-<dd>the inner radius of the cylinder for geometry <b>cylinder</b></dd>
-<dt><b>pull-r0: (1) [nm]</b></dt>
-<dd>the outer radius of the cylinder for geometry <b>cylinder</b></dd>
-<dt><b>pull-constr-tol: (1e-6)</b></dt>
-<dd>the relative constraint tolerance for constraint pulling</dd>
-<dt><b>pull-start:</b></dt>
-<dd><dl compact>
-<dt><b>no</b></dt>
-<dd>do not modify <b>pull-init</b>
-<dt><b>yes</b></dt>
-<dd>add the COM distance of the starting conformation to <b>pull-init</b></dd>
-</dl>
-<dt><b>pull-print-reference: (10)</b></dt>
-<dd><dl compact>
-<dt><b>no</b></dt>
-<dd>do not print the COM of the first group in each pull coordinate</dd>
-<dt><b>yes</b></dt>
-<dd>print the COM of the first group in each pull coordinate</dd>
-</dl>
-<dt><b>pull-nstxout: (10)</b></dt>
-<dd>frequency for writing out the COMs of all the pull group</dd>
-<dt><b>pull-nstfout: (1)</b></dt>
-<dd>frequency for writing out the force of all the pulled group</dd>
-<dt><b>pull-ngroups: (1)</b></dt>
-<dd>The number of pull groups, not including the absolute reference group,
-when used. Pull groups can be reused in multiple pull coordinates.
-Below only the pull options for group 1 are given, further groups simply
-increase the group index number.</dd>
-<dt><b>pull-ncoords: (1)</b></dt>
-<dd>The number of pull coordinates. Below only the pull options for
-coordinate 1 are given, further coordinates simply increase the coordinate
-index number.</dd>
-
-<dt><b>pull-group1-name: </b></dt>
-<dd>The name of the pull group, is looked up in the index file
-or in the default groups to obtain the atoms involved.</dd>
-<dt><b>pull-group1-weights: </b></dt>
-<dd>Optional relative weights which are multiplied with the masses of the atoms
-to give the total weight for the COM. The number should be 0, meaning all 1,
-or the number of atoms in the pull group.</dd>
-<dt><b>pull-group1-pbcatom: (0)</b></dt>
-<dd>The reference atom for the treatment of periodic boundary conditions
-inside the group
-(this has no effect on the treatment of the pbc between groups).
-This option is only important when the diameter of the pull group
-is larger than half the shortest box vector.
-For determining the COM, all atoms in the group are put at their periodic image
-which is closest to <b>pull-group1-pbcatom</b>.
-A value of 0 means that the middle atom (number wise) is used.
-This parameter is not used with geometry <b>cylinder</b>.
-A value of -1 turns on cosine weighting, which is useful for a group
-of molecules in a periodic system, e.g. a water slab (see Engin et al.
-J. Chem. Phys. B 2010).</dd>
-
-<dt><b>pull-coord1-groups: </b></dt>
-<dd>The two groups indices should be given on which this pull coordinate
-will operate. The first index can be 0, in which case an absolute reference
-of <b>pull-coord1-origin</b> is used. With an absolute reference the system
-is no longer translation invariant and one should think about what to do with
-the <A HREF="#run">center of mass motion</A>.</dd>
-<dt><b>pull-coord1-origin: (0.0 0.0 0.0)</b></dt>
-<dd>The pull reference position for use with an absolute reference.</dd>
-<dt><b>pull-coord1-vec: (0.0 0.0 0.0)</b></dt>
-<dd>The pull direction. <tt>grompp</tt> normalizes the vector.</dd>
-<dt><b>pull-coord1-init: (0.0) [nm]</b></dt>
-<dd>The reference distance at t=0.</dd>
-<dt><b>pull-coord1-rate: (0) [nm/ps]</b></dt>
-<dd>The rate of change of the reference position.</dd>
-<dt><b>pull-coord1-k: (0) [kJ mol<sup>-1</sup> nm<sup>-2</sup>] / [kJ mol<sup>-1</sup> nm<sup>-1</sup>]</b></dt>
-<dd>The force constant. For umbrella pulling this is the harmonic force
-constant in [kJ mol<sup>-1</sup> nm<sup>-2</sup>]. For constant force pulling
-this is the force constant of the linear potential, and thus minus (!)
-the constant force in [kJ mol<sup>-1</sup> nm<sup>-1</sup>].</dd>
-<dt><b>pull-coord1-kB: (pull-k1) [kJ mol<sup>-1</sup> nm<sup>-2</sup>] / [kJ mol<sup>-1</sup> nm<sup>-1</sup>]</b></dt>
-<dd>As <b>pull-coord1-k</b>, but for state B. This is only used when
-<A HREF="#free"><b>free-energy</b></A> is turned on.
-The force constant is then (1 - lambda)*<b>pull-coord1-k</b> + lambda*<b>pull-coord1-kB</b></dt>.
-
-</dl>
-
-<A NAME="nmr"><br>
-<hr>
-<h3><!--Idx-->NMR refinement<!--EIdx--></h3>
-<dl>
-<dt><b>disre:</b></dt>
-<dd><dl compact>
-<dt><b>no</b></dt>
-<dd>ignore <!--Idx-->distance restraint<!--EIdx--> information in topology file</dd>
-<dt><b>simple</b></dt>
-<dd>simple (per-molecule) distance restraints.
-<dt><b>ensemble</b></dt>
-<dd>distance restraints over an ensemble of molecules in one
-simulation box. Normally, one would perform ensemble averaging over
-multiple subsystems, each in a separate box, using <tt>mdrun -multi</tt>;s
-upply <tt>topol0.tpr</tt>, <tt>topol1.tpr</tt>, ... with different
-coordinates and/or velocities.
-The environment variable <tt>GMX_DISRE_ENSEMBLE_SIZE</tt> sets the number
-of systems within each ensemble (usually equal to the <tt>mdrun -multi</tt> value).</dd>
-</dd>
-</dl></dd>
-<dt><b>disre-weighting:</b></dt>
-<dd><dl compact>
-<dt><b>equal</b> (default)</dt>
-<dd>divide the restraint force equally over all atom pairs in the restraint</dd>
-<dt><b>conservative</b></dt>
-<dd>the forces are the derivative of the restraint potential,
-this results in an r<sup>-7</sup> weighting of the atom pairs.
-The forces are conservative when <tt>disre-tau</tt> is zero.</dd>
-</dl></dd>
-<dt><b>disre-mixed:</b></dt>
-<dd><dl compact>
-<dt><b>no</b></dt>
-<dd>the violation used in the calculation of the restraint force is the
-time-averaged violation </dd>
-<dt><b>yes</b></dt>
-<dd>the violation used in the calculation of the restraint force is the
-square root of the product of the time-averaged violation and the instantaneous violation</dd>
-</dl></dd>
-
-<dt><b>disre-fc: (1000) [kJ mol<sup>-1</sup> nm<sup>-2</sup>]</b></dt>
-<dd>force constant for distance restraints, which is multiplied by a
-(possibly) different factor for each restraint given in the <tt>fac</tt>
-column of the interaction in the topology file.</dd>
-
-<dt><b>disre-tau: (0) [ps]</b></dt>
-<dd>time constant for distance restraints running average. A value of zero turns off time averaging.</dd>
-
-<dt><b>nstdisreout: (100) [steps]</b></dt>
-<dd>period between steps when the running time-averaged and instantaneous distances
-of all atom pairs involved in restraints are written to the energy file
-(can make the energy file very large)</dd>
-
-<A NAME="nmr2">
-<dt><b>orire:</b></dt>
-<dd><dl compact>
-<dt><b>no</b></dt>
-<dd>ignore <!--Idx-->orientation restraint<!--EIdx--> information in topology file</dd>
-<dt><b>yes</b></dt>
-<dd>use orientation restraints, ensemble averaging can be performed
-with <tt>mdrun -multi</tt></dd>
-</dl>
-<dt><b>orire-fc: (0) [kJ mol]</b></dt>
-<dd>force constant for orientation restraints, which is multiplied by a
-(possibly) different weight factor for each restraint, can be set to zero to
-obtain the orientations from a free simulation</dd>
-<dt><b>orire-tau: (0) [ps]</b></dt>
-<dd>time constant for orientation restraints running average. A value of zero turns off time averaging.</dd>
-<dt><b>orire-fitgrp: </b></dt>
-<dd>fit group for orientation restraining. This group of atoms is used
-to determine the rotation <b>R</b> of the system with respect to the
-reference orientation. The reference orientation is the starting
-conformation of the first subsystem. For a protein, backbone is a reasonable
-choice</dd>
-<dt><b>nstorireout: (100) [steps]</b></dt>
-<dd>period between steps when the running time-averaged and instantaneous orientations
-for all restraints, and the molecular order tensor are written to the energy file
-(can make the energy file very large)</dd>
-</dl>
-
-<A NAME="free"><br>
-<hr>
-<h3>Free energy calculations<!--QuietIdx-->free energy calculations<!--EQuietIdx--></h3>
-
-<dl>
-<dt><b>free-energy:</b></dt>
-<dd><dl compact>
-<dt><b>no</b></dt>
-<dd>Only use topology A.</dd>
-<dt><b>yes</b></dt>
-<dd>Interpolate between topology A (lambda=0) to topology B (lambda=1)
-and write the derivative of the Hamiltonian with respect to lambda (as specified with <b>dhdl-derivatives</b>), or the Hamiltonian differences with respect to other lambda values (as specified with <b>foreign-lambda</b>) to
-the energy file and/or to <tt>dhdl.xvg</tt>, where they can be processed by, for example <tt>g_bar</tt>.
-The potentials, bond-lengths and angles are interpolated linearly as
-described in the manual. When <b>sc-alpha</b> is larger than zero, soft-core
-potentials are used for the LJ and Coulomb interactions.</dd>
-<dt><b>expanded</b></dt>
-<dd> Turns on expanded ensemble simulation, where the alchemical state becomes a dynamic variable, allowing jumping between different Hamiltonians. See the <A HREF="#expanded">expanded ensemble options</A> for controlling how expanded ensemble simulations are performed. The different Hamiltonians used in expanded ensemble simulations are defined by the other free energy options.</dd>
-</dl></dd>
-<dt><b>init-lambda: (-1)</b></dt>
-<dd>starting value for lambda (float). Generally, this should only be used with slow growth (i.e. nonzero <b>delta-lambda</b>). In other cases, <b>init-lambda-state</b> should be specified instead. Must be greater than or equal to 0.</dd>
-<dt><b>delta-lambda: (0)</b></dt>
-<dd>increment per time step for lambda</dd>
-<dt><b>init-lambda-state: (-1)</b></dt>
-<dd>starting value for the lambda state (integer). Specifies which columm of the lambda vector (<b>coul-lambdas</b>, <b>vdw-lambdas</b>, <b>bonded-lambdas</b>, <b>restraint-lambdas</b>, <b>mass-lambdas</b>, <b>temperature-lambdas</b>, <b>fep-lambdas</b>) should be used. This is a zero-based index: <b>init-lambda-state</b> 0 means the first column, and so on.</dd>
-<dt><b>fep-lambdas: ()</b></dt>
-<dd>Zero, one or more lambda values for which Delta H values will
-be determined and written to dhdl.xvg every <b>nstdhdl</b> steps.
-Values must be between 0 and 1.
-Free energy differences between different lambda values can then
-be determined with <tt>g_bar</tt>. <b>fep-lambdas</b> is different from the other -lambdas keywords because
-all components of the lambda vector that are not specified will use <b>fep-lambdas</b> (including restraint-lambdas and therefore the pull code restraints).</dd>
-<dt><b>coul-lambdas: ()</b></dt>
-<dd>Zero, one or more lambda values for which Delta H values will
-be determined and written to dhdl.xvg every <b>nstdhdl</b> steps. Values must be between 0 and 1.
-Only the electrostatic interactions are controlled with this component of the lambda vector (and only if the lambda=0 and lambda=1 states have differing electrostatic interactions).</dd>
-<dt><b>vdw-lambdas: ()</b></dt>
-<dd>Zero, one or more lambda values for which Delta H values will
-be determined and written to dhdl.xvg every <b>nstdhdl</b> steps. Values must be between 0 and 1.
-Only the van der Waals interactions are controlled with this component of the lambda vector.</dd>
-<dt><b>bonded-lambdas: ()</b></dt>
-<dd>Zero, one or more lambda values for which Delta H values will
-be determined and written to dhdl.xvg every <b>nstdhdl</b> steps. Values must be between 0 and 1.
-Only the bonded interactions are controlled with this component of the lambda vector.</dd>
-<dt><b>restraint-lambdas: ()</b></dt>
-<dd>Zero, one or more lambda values for which Delta H values will
-be determined and written to dhdl.xvg every <b>nstdhdl</b> steps. Values must be between 0 and 1.
-Only the restraint interactions: dihedral restraints, and the pull code restraints are controlled with this component of the lambda vector. </dd>
-<dt><b>mass-lambdas: ()</b></dt>
-<dd>Zero, one or more lambda values for which Delta H values will
-be determined and written to dhdl.xvg every <b>nstdhdl</b> steps. Values must be between 0 and 1.
-Only the particle masses are controlled with this component of the lambda vector.</dd>
-<dt><b>temperature-lambdas: ()</b></dt>
-<dd>Zero, one or more lambda values for which Delta H values will
-be determined and written to dhdl.xvg every <b>nstdhdl</b> steps. Values must be between 0 and 1.
-Only the temperatures controlled with this component of the lambda vector.
-Note that these lambdas should not be used for replica exchange, only for simulated tempering.</dd>
-<dt><b>calc-lambda-neighbors (1)</b></dt>
-<dd>Controls the number of lambda values for which Delta H values will be
-calculated and written out, if <b>init-lambda-state</b> has been set. A
-positive value will limit the number of lambda points calculated to only the
-nth neighbors of <b>init-lambda-state</b>: for example, if
-<b>init-lambda-state</b> is 5 and this parameter has a value of 2, energies for
-lambda points 3-7 will be calculated and writen out. A value of -1 means all
-lambda points will be written out. For normal BAR such as with g_bar, a value
-of 1 is sufficient, while for MBAR -1 should be used.</dd>
-<dt><b>sc-alpha: (0)</b></dt>
-<dd>the soft-core alpha parameter, a value of 0 results in linear interpolation of the LJ and Coulomb interactions</dd>
-<dt><b>sc-r-power: (6)</b></dt>
-<dd>the power of the radial term in the soft-core equation. Possible values are 6 and 48. 6 is more standard, and is the default. When 48 is used, then sc-alpha should generally be much lower (between 0.001 and 0.003).</dd>
-<dt><b>sc-coul: (no)</b></dt>
-<dd>Whether to apply the soft core free energy interaction transformation to the Columbic interaction of a molecule. Default is no, as it is generally
-more efficient to turn off the Coulomic interactions linearly before turning off the van der Waals interactions.</dd>
-<dt><b>sc-power: (0)</b></dt>
-<dd>the power for lambda in the soft-core function, only the values 1 and 2 are supported</dd>
-<dt><b>sc-sigma: (0.3) [nm]</b></dt>
-<dd>the soft-core sigma for particles which have a C6 or C12 parameter equal
-to zero or a sigma smaller than <b>sc-sigma</b></dd>
-<dt><b>couple-moltype:</b></dt>
-<dd>Here one can supply a molecule type (as defined in the topology)
-for calculating solvation or coupling free energies.
-There is a special option <b>system</b> that couples all molecule types
-in the system. This can be useful for equilibrating a system
-starting from (nearly) random coordinates.
-<b>free-energy</b> has to be turned on.
-The Van der Waals interactions and/or charges in this molecule type can be
-turned on or off between lambda=0 and lambda=1, depending on the settings
-of <b>couple-lambda0</b> and <b>couple-lambda1</b>. If you want to decouple
-one of several copies of a molecule, you need to copy and rename
-the molecule definition in the topology.</dd>
-<dt><b>couple-lambda0:</b></dt>
-<dd><dl compact>
-<dt><b>vdw-q</b></dt>
-<dd>all interactions are on at lambda=0
-<dt><b>vdw</b></dt>
-<dd>the charges are zero (no Coulomb interactions) at lambda=0
-<dt><b>q</b></dt>
-<dd>the Van der Waals interactions are turned at lambda=0; soft-core interactions will be required to avoid singularities
-<dt><b>none</b></dt>
-<dd>the Van der Waals interactions are turned off and the charges are zero at lambda=0; soft-core interactions will be required to avoid singularities.
-</dl>
-<dt><b>couple-lambda1:</b></dt>
-<dd> analogous to <b>couple-lambda1</b>, but for lambda=1
-<dt><b>couple-intramol:</b></dt>
-<dd><dl compact>
-<dt><b>no</b></dt>
-<dd>All intra-molecular non-bonded interactions for moleculetype <b>couple-moltype</b> are replaced by exclusions and explicit pair interactions. In this manner the decoupled state of the molecule corresponds to the proper vacuum state without periodicity effects.
-<dt><b>yes</b></dt>
-<dd>The intra-molecular Van der Waals and Coulomb interactions are also turned on/off. This can be useful for partitioning free-energies of relatively large molecules, where the intra-molecular non-bonded interactions might lead to kinetically trapped vacuum conformations. The 1-4 pair interactions are not turned off.
-</dl>
-<dt><b>nstdhdl: (100)</b></dt>
-<dd>the frequency for writing dH/dlambda and possibly Delta H to dhdl.xvg,
-0 means no ouput, should be a multiple of <b>nstcalcenergy</b></dd>.</dd>
-<dt><b>dhdl-derivatives: (yes)</b></dt>
-<dd>If yes (the default), the derivatives of the Hamiltonian with respect to lambda at each <b>nstdhdl</b> step are written out. These values are needed for interpolation of linear energy differences with <tt>g_bar</tt> (although the same can also be achieved with the right <b>foreign lambda</b> setting, that may not be as flexible), or with thermodynamic integration</dd>
-<dt><b>dhdl-print-energy: (no)</b></dt>
-<dd> Include either the total or the potential energy in the dhdl file. Options are 'no', 'potential', or 'total'. This information is needed for later free energy analysis if the states of interest are at different temperatures. If all states are at the same temperature, this information is not needed. 'potential' is useful in case one is using <tt>mdrun -rerun</tt> to generate the <tt>dhdl.xvg</tt> file. When rerunning from an existing trajectory, the kinetic energy will often not be correct, and thus one must compute the residual free energy from the potential alone, with the kinetic energy component computed analytically.
-</dd>
-<dt><b>separate-dhdl-file: (yes)</b></dt>
-<dd><dl compact>
-<dt><b>yes</b></dt>
-<dd>the free energy values that are calculated (as specified with the <b>foreign-lambda</b> and <b>dhdl-derivatives</b> settings) are written out to a separate file, with the default name <tt>dhdl.xvg</tt>. This file can be used directly with <tt>g_bar</tt>.</dd>
-<dt><b>no</b></dt>
-<dd>The free energy values are written out to the energy output file (<tt>ener.edr</tt>, in accumulated blocks at every <b>nstenergy</b> steps), where they can be extracted with <tt>g_energy</tt> or used directly with <tt>g_bar</tt>.</dd>
-</dl>
-<dt><b>dh-hist-size: (0)</b></dt>
-<dd>If nonzero, specifies the size of the histogram into which the Delta H values (specified with <b>foreign-lambda</b>) and the derivative dH/dl values are binned, and written to ener.edr. This can be used to save disk space while calculating free energy differences. One histogram gets written for each <b>foreign lambda</b> and two for the dH/dl, at every <b>nstenergy</b> step. Be aware that incorrect histogram settings (too small size or too wide bins) can introduce errors. Do not use histograms unless you're certain you need it.</dd>
-<dt><b>dh-hist-spacing (0.1)</b></dt>
-<dd>Specifies the bin width of the histograms, in energy units. Used in conjunction with <b>dh-hist-size</b>. This size limits the accuracy with which free energies can be calculated. Do not use histograms unless you're certain you need it.</dd>
-</dl>
-<A NAME="expanded"><br>
-<hr>
-<h3><!--Idx-->Expanded Ensemble calculations<!--EIdx--></h3>
-
-<dl>
-<dt><b>nstexpanded</b></dt> <dd>The number of integration steps beween attempted moves changing the system Hamiltonian in expanded ensemble simulations. Must be a multiple of <b>nstcalcenergy</b>, but can be greater or less than <b>nstdhdl</b>.</dd>
-<dt><b>lmc-stats:</b></dt>
-<dd><dl compact>
-<dt><b>no</b></dt>
-<dd>No Monte Carlo in state space is performed.</dd>
-<dt><b>metropolis-transition</b></dt>
-<dd> Uses the Metropolis weights to update the expanded ensemble weight of each state.
-Min{1,exp(-(beta_new u_new - beta_old u_old)}</dd>
-<dt><b>barker-transition</b></dt>
-<dd> Uses the Barker transition critera to update the expanded ensemble weight of each state i, defined by
-exp(-beta_new u_new)/[exp(-beta_new u_new)+exp(-beta_old u_old)</dd>
-<dt><b>wang-landau</b></dt>
-<dd>Uses the Wang-Landau algorithm (in state space, not energy space) to update the expanded ensemble weights.</dd>
-<dt><b>min-variance</b></dt>
-<dd>Uses the minimum variance updating method of Escobedo et al. to update the expanded ensemble weights. Weights
-will not be the free energies, but will rather emphasize states that need more sampling to give even uncertainty.</dd>
-</dl>
-<dt><b>lmc-mc-move:</b></dt>
-<dd><dl compact>
-<dt><b>no</b></dt>
-<dd>No Monte Carlo in state space is performed.</dd>
-<dt><b>metropolis-transition</b></dt>
-<dd> Randomly chooses a new state up or down, then uses the Metropolis critera to decide whether to accept or reject:
-Min{1,exp(-(beta_new u_new - beta_old u_old)}</dd>
-<dt><b>barker-transition</b></dt>
-<dd> Randomly chooses a new state up or down, then uses the Barker transition critera to decide whether to accept or reject: exp(-beta_new u_new)/[exp(-beta_new u_new)+exp(-beta_old u_old)]</dd>
-<dt><b>gibbs</b></dt>
-<dd> Uses the conditional weights of the state given the coordinate (exp(-beta_i u_i) / sum_k exp(beta_i u_i) to
-decide which state to move to.</dd>
-<dt><b>metropolized-gibbs</b></dt>
-<dd>
-<dd> Uses the conditional weights of the state given the coordinate (exp(-beta_i u_i) / sum_k exp(beta_i u_i) to
-decide which state to move to, EXCLUDING the current state, then uses a rejection step to ensure detailed
-balance. Always more efficient that Gibbs, though only marginally so in many situations, such as when only the nearest neighbors have decent phase space overlap.</dd>
-</dl>
-<dt><b>lmc-seed: (-1)</b></dt>
-<dd> random seed to use for Monte Carlo moves in state space. When <b>lmc-seed</b> is set to -1, a pseudo random seed is us</dd>
-<dt><b>mc-temperature:</b></dt>
-<dd> Temperature used for acceptance/rejection for Monte Carlo moves. If not specified, the temperature of the
-simulation specified in the first group of <b>ref_t</b> is used.</dd>
-<dt><b>wl-ratio: (0.8)</b></dt>
-<dd>The cutoff for the histogram of state occupancies to be reset, and the free energy incrementor to be reset as delta -> delta*wl-scale. If we define the Nratio = (number of samples at each histogram) / (average number of samples at each histogram). <b>wl-ratio</b> of 0.8 means that means that the histogram is only considered flat if all Nratio > 0.8 AND simultaneously all 1/Nratio > 0.8.</dd>
-<dt><b>wl-scale: (0.8)</b></dt>
-<dd> Each time the histogram is considered flat, then the current value of the Wang-Landau incrementor for the free energies is multiplied by <b>wl-scale</b>. Value must be between 0 and 1.</dd>
-<dt><b>init-wl-delta: (1.0)</b></dt>
-<dd>The initial value of the Wang-Landau incrementor in kT. Some value near 1 kT is usually most efficient, though sometimes a value of 2-3 in units of kT works better if the free energy differences are large.</dd>
-<dt><b>wl-oneovert: (no)</b></dt>
-<dd>Set Wang-Landau incrementor to scale with 1/(simulation time) in the large sample limit. There is significant evidence that the standard Wang-Landau algorithms in state space presented here result in free energies getting 'burned in' to incorrect values that depend on the initial state. when <b>wl-oneovert</b> is true, then when the incrementor becomes less than 1/N, where N is the mumber of samples collected (and thus proportional to the data collection time, hence '1 over t'), then the Wang-Lambda incrementor is set to 1/N, decreasing every step. Once this occurs, <b>wl-ratio</b> is ignored, but the weights will still stop updating when the equilibration criteria set in <b>lmc-weights-equil</b> is achieved.</dd>
-<dt><b>lmc-repeats: (1)</b></dt>
-<dd>Controls the number of times that each Monte Carlo swap type is performed each iteration. In the limit of large numbers of Monte Carlo repeats, then all methods converge to Gibbs sampling. The value will generally not need to be different from 1.</dd>
-<dt><b>lmc-gibbsdelta: (-1)</b></dt>
-<dd> Limit Gibbs sampling to selected numbers of neighboring states. For Gibbs sampling, it is sometimes inefficient to perform Gibbs sampling over all of the states that are defined. A positive value of <b>lmc-gibbsdelta</b> means that only states plus or minus <b>lmc-gibbsdelta</b> are considered in exchanges up and down. A value of -1 means that all states are considered. For less than 100 states, it is probably not that expensive to include all states.</dd>
-<dt><b>lmc-forced-nstart: (0)</b></dt>
-<dd> Force initial state space sampling to generate weights. In order to come up with reasonable initial weights, this setting allows the simulation to drive from the initial to the final lambda state, with <b>lmc-forced-nstart</b> steps at each state before moving on to the next lambda state. If <b>lmc-forced-nstart</b> is sufficiently long (thousands of steps, perhaps), then the weights will be close to correct. However, in most cases, it is probably better to simply run the standard weight equilibration algorithms.
-<dt><b>nst-transition-matrix: (-1)</b></dt>
-<dd>Frequency of outputting the expanded ensemble transition matrix. A negative number means it will only be printed at the end of the simulation.<dd>
-<dt><b>symmetrized-transition-matrix: (no) </b></dt>
-<dd>Whether to symmetrize the empirical transition matrix. In the infinite limit the matrix will be symmetric, but will diverge with statistical noise for short timescales. Forced symmetrization, by using the matrix T_sym = 1/2 (T + transpose(T)), removes problems like the existence of (small magnitude) negative eigenvalues.</dd>
-<dt><b>mininum-var-min: (100)</b></dt>
-<dd> The <b>min-variance</b> strategy (option of <b>lmc-stats</b> is only valid for larger number of samples, and can get stuck if too few samples are used at each state. <b>mininum-var-min</b> is the minimum number of samples that each state that are allowed before the <b>min-variance</b> strategy is activated if selected.</dd>
-<dt><b>init-lambda-weights: </b></dt>
-<dd>The initial weights (free energies) used for the expanded ensemble states. Default is a vector of zero weights. format is similar to the lambda vector settings in <b>fep-lambdas</b>, except the weights can be any floating point number. Units are kT. Its length must match the lambda vector lengths.</dd>
-<dt><b>lmc-weights-equil: (no)</b></dt>
-<dd><dl compact>
-<dt><b>no</b></dt>
-<dd>Expanded ensemble weights continue to be updated throughout the simulation.</dd>
-<dt><b>yes</b></dt>
-<dd>The input expanded ensemble weights are treated as equilibrated, and are not updated throughout the simulation.</dd>
-<dt><b>wl-delta</b></dt>
-<dd>Expanded ensemble weight updating is stopped when the Wang-Landau incrementor falls below the value specified by <b>weight-equil-wl-delta</b>.</dd>
-<dt><b>number-all-lambda</b></dt>
-<dd>Expanded ensemble weight updating is stopped when the number of samples at all of the lambda states is greater than the value specified by <b>weight-equil-number-all-lambda</b>.</dd>
-<dt><b>number-steps</b></dt>
-<dd>Expanded ensemble weight updating is stopped when the number of steps is greater than the level specified by <b>weight-equil-number-steps</b>.</dd>
-<dt><b>number-samples</b></dt>
-<dd>Expanded ensemble weight updating is stopped when the number of total samples across all lambda states is greater than the level specified by <b>weight-equil-number-samples</b>.</dd>
-<dt><b>count-ratio</b></dt>
-<dd>Expanded ensemble weight updating is stopped when the ratio of samples at the least sampled lambda state and most sampled lambda state greater than the value specified by <b>weight-equil-count-ratio</b>.</dd>
-</dl>
-<dt><b>simulated-tempering: (no)</b></dt>
-<dd>Turn simulated tempering on or off. Simulated tempering is implemented as expanded ensemble sampling with different temperatures instead of different Hamiltonians.</dd>
-<dt><b>sim-temp-low: (300)</b></dt>
-<dd>Low temperature for simulated tempering.</dd>
-<dt><b>sim-temp-high: (300)</b></dt>
-<dd>High temperature for simulated tempering.</dd>
-<dt><b>simulated-tempering-scaling: (linear)</b></dt>
-<dd>Controls the way that the temperatures at intermediate lambdas are calculated from the <b>temperature-lambda</b> part of the lambda vector.</dd>
-<dd><dl compact>
-<dt><b>linear</b></dt>
-<dd>Linearly interpolates the temperatures using the values of <b>temperature-lambda</b>,i.e. if <b>sim-temp-low</b>=300, <b>sim-temp-high</b>=400, then lambda=0.5 correspond to a temperature of 350. A nonlinear set of temperatures can always be implemented with uneven spacing in lambda.</dd>
-<dt><b>geometric</b></dt>
-<dd> Interpolates temperatures geometrically between <b>sim-temp-low</b> and <b>sim-temp-high</b>. The i:th state has temperature <b>sim-temp-low</b> * (<b>sim-temp-high</b>/<b>sim-temp-low</b>) raised to the power of (i/(ntemps-1)). This should give roughly equal exchange for constant heat capacity, though of course things simulations that involve protein folding have very high heat capacity peaks.</dd>
-<dt><b>exponential</b></dt>
-<dd> Interpolates temperatures exponentially between <b>sim-temp-low</b> and <b>sim-temp-high</b>. The ith state has temperature
-<b>sim-temp-low</b> + (<b>sim-temp-high</b>-<b>sim-temp-low</b>)*((exp(<b>temperature-lambdas</b>[i])-1)/(exp(1.0)-1)).</dd>
-</dl>
-</dl>
-
-<A NAME="neq"><br>
-<hr>
-<h3>Non-equilibrium MD<!--QuietIdx-->non-equilibrium MD<!--EQuietIdx--></h3>
-
-<dl>
-<dt><b>acc-grps: </b></dt>
-<dd>groups for constant acceleration (e.g.: <tt>Protein Sol</tt>)
-all atoms in groups Protein and Sol will experience constant acceleration
-as specified in the <b>accelerate</b> line</dd>
-<dt><b>accelerate: (0) [nm ps<sup>-2</sup>]</b></dt>
-<dd>acceleration for <b>acc-grps</b>; x, y and z for each group
-(e.g. <tt>0.1 0.0 0.0 -0.1 0.0 0.0</tt> means that first group has constant
-acceleration of 0.1 nm ps<sup>-2</sup> in X direction, second group the
-opposite).</dd>
-<dt><b>freezegrps: </b></dt>
-<dd>Groups that are to be frozen (i.e. their X, Y, and/or Z position will
-not be updated; e.g. <tt>Lipid SOL</tt>). <b>freezedim</b> specifies for
-which dimension the freezing applies.
-To avoid spurious contibrutions to the virial and pressure due to large
-forces between completely frozen atoms you need to use
-<A HREF="#egexcl">energy group exclusions</A>, this also saves computing time.
-Note that coordinates of frozen atoms are not scaled by pressure-coupling
-algorithms.</dd>
-<dt><b>freezedim: </b></dt>
-<dd>dimensions for which groups in <b>freezegrps</b> should be frozen,
-specify <tt>Y</tt> or <tt>N</tt> for X, Y and Z and for each group
-(e.g. <tt>Y Y N N N N</tt> means that particles in the first group
-can move only in Z direction. The particles in the second group can
-move in any direction).</dd>
-<dt><b>cos-acceleration: (0) [nm ps<sup>-2</sup>]</b></dt>
-<dd>the amplitude of the acceleration profile for calculating the
-<!--Idx-->viscosity<!--EIdx-->.
-The acceleration is in the X-direction and the magnitude is
-<b>cos-acceleration</b> cos(2 pi z/boxheight).
-Two terms are added to the energy file:
-the amplitude of the velocity profile and 1/viscosity.</dd>
-<dt><b><!--Idx-->deform<!--EIdx-->: (0 0 0 0 0 0) [nm ps<sup>-1</sup>]</b></dt>
-<dd>The velocities of deformation for the box elements:
-a(x) b(y) c(z) b(x) c(x) c(y). Each step the box elements
-for which <b>deform</b> is non-zero are calculated as:
-box(ts)+(t-ts)*deform, off-diagonal elements are corrected
-for periodicity. The coordinates are transformed accordingly.
-Frozen degrees of freedom are (purposely) also transformed.
-The time ts is set to t at the first step and at steps at which
-x and v are written to trajectory to ensure exact restarts.
-Deformation can be used together with semiisotropic or anisotropic
-pressure coupling when the appropriate compressibilities are set to zero.
-The diagonal elements can be used to <!--Idx-->strain<!--EIdx--> a solid.
-The off-diagonal elements can be used to <!--Idx-->shear<!--EIdx--> a solid
-or a liquid.</dd>
-</dl>
-
-<A NAME="ef"><br>
-<hr>
-<h3>Electric fields<!--QuietIdx-->electric field<!--EQuietIdx--></h3>
-
-<dl>
-<dt><b>E-x ; E-y ; E-z:</b></dt>
-<dd>If you want to use an electric field in a direction, enter 3 numbers
-after the appropriate <b>E-*</b>, the first number: the number of cosines,
-only 1 is implemented (with frequency 0) so enter 1,
-the second number: the strength of the electric field in
-<b>V nm<sup>-1</sup></b>,
-the third number: the phase of the cosine, you can enter any number here
-since a cosine of frequency zero has no phase.</dd>
-<dt><b>E-xt; E-yt; E-zt: </b></dt>
-<dd>not implemented yet</dd>
-</dl>
-<br>
-
-<hr>
-<A NAME="qmmm"><br>
-<h3>Mixed quantum/classical molecular dynamics<!--QuietIdx>QM/MM<!--EQuietIdx--></h3>
-
-<dl>
-<dt><b>QMMM:</b></dt>
-<dd><dl compact="compact">
-<dt><b>no</b></dt>
-<dd>No QM/MM.</dd>
-<dt><b>yes</b></dt>
-<dd>Do a QM/MM simulation. Several groups can be described at
-different QM levels separately. These are specified in
-the <b>QMMM-grps</b> field separated by spaces. The level of <i>ab
-initio</i> theory at which the groups are described is specified
-by <b>QMmethod</b> and <b>QMbasis</b> Fields. Describing the
-groups at different levels of theory is only possible with the ONIOM
-QM/MM scheme, specified by <b>QMMMscheme</b>.</dd>
-</dl></dd>
-
-<dt><b>QMMM-grps:</b></dt>
-<dd>groups to be descibed at the QM level</dd>
-
-<dt><b>QMMMscheme:</b></dt>
-<dd><dl compact="compact">
-<dt><b>normal</b></dt>
-<dd>normal QM/MM. There can only be one <b>QMMM-grps</b> that is modelled
-at the <b>QMmethod</b> and <b>QMbasis</b> level of <i>ab initio</i>
-theory. The rest of the system is described at the MM level. The QM
-and MM subsystems interact as follows: MM point charges are included
-in the QM one-electron hamiltonian and all Lennard-Jones interactions
-are described at the MM level.</dd>
-<dt><b>ONIOM</b></dt>
-<dd>The interaction between the subsystem is described using the ONIOM
-method by Morokuma and co-workers. There can be more than one <b>QMMM-grps</b> each modeled at a different level of QM theory
-(<b>QMmethod</b> and <b>QMbasis</b>).
-</dd></dl></dd>
-
-<dt><b>QMmethod: (RHF)</b></dt>
-<dd>Method used to compute the energy and gradients on the QM
-atoms. Available methods are AM1, PM3, RHF, UHF, DFT, B3LYP, MP2,
-CASSCF, and MMVB. For CASSCF, the number of electrons and orbitals
-included in the active space is specified by <b>CASelectrons</b>
-and <b>CASorbitals</b>. </dd>
-
-<dt><b>QMbasis: (STO-3G)</b></dt>
-<dd>Basis set used to expand the electronic wavefuntion. Only Gaussian
-basis sets are currently available, <i>i.e.</i> STO-3G, 3-21G, 3-21G*,
-3-21+G*, 6-21G, 6-31G, 6-31G*, 6-31+G*, and 6-311G.</dd>
-
-<dt><b>QMcharge: (0) [integer]</b></dt>
-<dd>The total charge in <tt>e</tt> of the <b>QMMM-grps</b>. In case
-there are more than one <b>QMMM-grps</b>, the total charge of each
-ONIOM layer needs to be specified separately.</dd>
-
-<dt><b>QMmult: (1) [integer]</b></dt>
-<dd>The multiplicity of the <b>QMMM-grps</b>. In case there are more
-than one <b>QMMM-grps</b>, the multiplicity of each ONIOM layer needs
-to be specified separately.</dd>
-
-<dt><b>CASorbitals: (0) [integer]</b></dt>
-<dd>The number of orbitals to be included in the active space when
-doing a CASSCF computation.</dd>
-
-<dt><b>CASelectrons: (0) [integer]</b></dt>
-<dd>The number of electrons to be included in the active space when
-doing a CASSCF computation.</dd>
-
-<dt><b>SH:</b></dt>
-<dd><dl compact="compact">
-<dt><b>no</b></dt>
-<dd>No surface hopping. The system is always in the electronic
-ground-state.</dd>
-<dt><b>yes</b></dt>
-<dd>Do a QM/MM MD simulation on the excited state-potential energy
-surface and enforce a <i>diabatic</i> hop to the ground-state when the
-system hits the conical intersection hyperline in the course the
-simulation. This option only works in combination with the CASSCF
-method.</dd>
-</dl>
-</dl>
-
-<A NAME="gbsa"><br>
-<hr>
-<h3>Implicit solvent</h3>
-
-<dl>
-<dt><b>implicit-solvent:</b></dt>
-<dd><dl compact="compact">
-<dt><b>no</b></dt>
-<dd>No implicit solvent</dd>
-<dt><b>GBSA</b></dt>
-<dd>Do a simulation with implicit solvent using the Generalized Born formalism.
-Three different methods for calculating the Born radii are available, Still, HCT and
-OBC. These are specified with the <b>gb-algorithm</b> field. The non-polar solvation
-is specified with the <b>sa-algorithm</b> field.</dd>
-</dl>
-
-<dt><b>gb-algorithm:</b></dt>
-<dd><dl compact="compact">
-<dt><b>Still</b></dt>
-<dd>Use the Still method to calculate the Born radii</dd>
-<dt><b>HCT</b></dt>
-<dd>Use the Hawkins-Cramer-Truhlar method to calculate the Born radii</dd>
-<dt><b>OBC</b></dt>
-<dd>Use the Onufriev-Bashford-Case method to calculate the Born radii</dd>
-</dl>
-
-<dt><b>nstgbradii: (1) [steps]</b></dt>
-<dd>Frequency to (re)-calculate the Born radii. For most practial purposes,
-setting a value larger than 1 violates energy conservation and leads to
-unstable trajectories.</dd>
-
-<dt><b>rgbradii: (1.0) [nm]</b></dt>
-<dd>Cut-off for the calculation of the Born radii. Currently must be equal to rlist</dd>
-
-<dt><b>gb-epsilon-solvent: (80)</b></dt>
-<dd>Dielectric constant for the implicit solvent</dd>
-
-<dt><b>gb-saltconc: (0) [M]</b></dt>
-<dd>Salt concentration for implicit solvent models, currently not used</dd>
-
-<dt><b>gb-obc-alpha (1); gb-obc-beta (0.8); gb-obc-gamma (4.85);</b></dt>
-<dd>Scale factors for the OBC model. Default values are OBC(II).
-Values for OBC(I) are 0.8, 0 and 2.91 respectively</dd>
-
-<dt><b>gb-dielectric-offset: (0.009) [nm]</b></dt>
-<dd>Distance for the di-electric offset when calculating the Born radii. This is
-the offset between the center of each atom the center of the polarization energy
-for the corresponding atom</dd>
-
-<dt><b>sa-algorithm</b></dt>
-<dd><dl compact="compact">
-<dt><b>Ace-approximation</b></dt>
-<dd>Use an Ace-type approximation (default)</dd>
-<dt><b>None</b></dt>
-<dd>No non-polar solvation calculation done. For GBSA only the polar part gets
-calculated</dd>
-</dl>
-
-<dt><b>sa-surface-tension: [kJ mol<sup>-1</sup> nm<sup>-2</sup>]</b></dt>
-<dd>Default value for surface tension with SA algorithms. The default value is -1;
-Note that if this default value is not changed
-it will be overridden by <tt>grompp</tt> using values that are specific for the choice
-of radii algorithm (0.0049 kcal/mol/Angstrom<sup>2</sup> for Still, 0.0054 kcal/mol/Angstrom<sup>2</sup>
-for HCT/OBC)
-
-Setting it to 0 will while using an sa-algorithm other than None means
-no non-polar calculations are done.
-</dd>
-</dl>
-
-<A NAME="adress"><br>
-<hr>
-<h3>Adaptive Resolution Simulation</h3>
-
-<dl>
-<dt><b>adress: (no)</b></dt>
-<dd>Decide whether the AdResS feature is turned on.</dd>
-<dt><b>adress-type: (Off)</b></dt>
-<dd><dl compact>
-<dt><b>Off</b></dt>
-<dd>Do an AdResS simulation with weight equal 1, which is equivalent to an explicit (normal) MD simulation. The difference to disabled AdResS is that the AdResS variables are still read-in and hence are defined.</dd>
-<dt><b>Constant</b></dt>
-<dd>Do an AdResS simulation with a constant weight, <b>adress-const-wf</b> defines the value of the weight</dd>
-<dt><b>XSplit</b></dt>
-<dd>Do an AdResS simulation with simulation box split in x-direction, so basically the weight is only a function of the x coordinate and all distances are measured using the x coordinate only.</dd>
-<dt><b>Sphere</b></dt>
-<dd>Do an AdResS simulation with spherical explicit zone.</dd>
-</dl></dd>
-<dt><b>adress-const-wf: (1)</b></dt>
-<dd>Provides the weight for a constant weight simulation (<b>adress-type</b>=Constant)</dd>
-<dt><b>adress-ex-width: (0)</b></dt>
-<dd>Width of the explicit zone, measured from <b>adress-reference-coords</b>.</dd>
-<dt><b>adress-hy-width: (0)</b></dt>
-<dd>Width of the hybrid zone.</dd>
-<dt><b>adress-reference-coords: (0,0,0)</b></dt>
-<dd>Position of the center of the explicit zone. Periodic boundary conditions apply for measuring the distance from it.</dd>
-<dt><b>adress-cg-grp-names</b></dt>
-<dd>The names of the coarse-grained energy groups. All other energy groups are considered explicit and their interactions will be automatically excluded with the coarse-grained groups.</dd>
-<dt><b>adress-site: (COM)</b>The mapping point from which the weight is calculated.</dt>
-<dd><dl compact>
-<dt><b>COM</b></dt>
-<dd>The weight is calculated from the center of mass of each charge group.</dd>
-<dt><b>COG</b></dt>
-<dd>The weight is calculated from the center of geometry of each charge group.</dd>
-<dt><b>Atom</b></dt>
-<dd>The weight is calculated from the position of 1st atom of each charge group.</dd>
-<dt><b>AtomPerAtom</b></dt>
-<dd>The weight is calculated from the position of each individual atom.</dd>
-</dl></dd>
-<dt><b>adress-interface-correction: (Off)</b></dt>
-<dd><dl compact>
-<dt><b>Off</b></dt>
-<dd>Do not a apply any interface correction.</dd>
-<dt><b>thermoforce</b></dt>
-<dd>Apply thermodynamic force interface correction. The table can be specified using the <tt>-tabletf</tt> option of <tt>mdrun</tt>. The table should contain the potential and force (acting on molecules) as function of the distance from <b>adress-reference-coords</b>.</dd>
-</dl></dd>
-<dt><b>adress-tf-grp-names</b></dt>
-<dd>The names of the energy groups to which the <b>thermoforce</b> is applied if enabled in <b>adress-interface-correction</b>. If no group is given the default table is applied.</dd>
-<dt><b>adress-ex-forcecap: (0)</b></dt>
-<dd>Cap the force in the hybrid region, useful for big molecules. 0 disables force capping.</dd>
-</dl>
-
-<A NAME="user"><br>
-<hr>
-<h3>User defined thingies</h3>
-
-<dl>
-<dt><b>user1-grps; user2-grps: </b></dt>
-<dt><b>userint1 (0); userint2 (0); userint3 (0); userint4 (0)</b></dt>
-<dt><b>userreal1 (0); userreal2 (0); userreal3 (0); userreal4 (0)</b></dt>
-<dd>These you can use if you modify code. You can pass integers and
-reals to your subroutine. Check the inputrec definition in
-<tt>src/include/types/inputrec.h</tt></dd>
-
-</dl>
-
-<A NAME="idx"><br>
-<hr>
-<h3>Index</h3>
-
-<P>
-
-<multicol cols=4>
-<A HREF="#neq">acc-grps</A><br>
-<A HREF="#neq">accelerate</A><br>
-<A HREF="#sa">annealing</A><br>
-<A HREF="#sa">annealing-npoints</A><br>
-<A HREF="#sa">annealing-time</A><br>
-<A HREF="#sa">annealing-temp</A><br>
-<A HREF="#ld">bd-fric</A><br>
-<A HREF="#vdw">bDispCorr</A><br>
-<A HREF="#run">comm-mode</A><br>
-<A HREF="#run">comm-grps</A><br>
-<A HREF="#pc">compressibility</A><br>
-<A HREF="#bond">constraint-algorithm</A><br>
-<A HREF="#bond">constraints</A><br>
-<A HREF="#neq">cos-acceleration</A><br>
-<A HREF="#el">coulombtype</A><br>
-<A HREF="#el">coulomb-modifier</A><br>
-<A HREF="#free">couple-intramol</A><br>
-<A HREF="#free">couple-lambda0</A><br>
-<A HREF="#free">couple-lambda1</A><br>
-<A HREF="#free">couple-moltype</A><br>
-<A HREF="#nl">cutoff-scheme</A><br>
-<A HREF="#pp">define</A><br>
-<A HREF="#neq">deform</A><br>
-<A HREF="#free">delta-lambda</A><br>
-<A HREF="#nmr">disre</A><br>
-<A HREF="#nmr">disre-weighting</A><br>
-<A HREF="#nmr">disre-mixed</A><br>
-<A HREF="#nmr">disre-fc</A><br>
-<A HREF="#nmr">disre-tau</A><br>
-<A HREF="#run">dt</A><br>
-<A HREF="#em">emstep</A><br>
-<A HREF="#em">emtol</A><br>
-<A HREF="#egexcl">energygrp-excl</A><br>
-<A HREF="#table">energygrp-table</A><br>
-<A HREF="#out">energygrps</A><br>
-<A HREF="#el2">epsilon-r</A><br>
-<A HREF="#el2">epsilon-rf</A><br>
-<A HREF="#ewald">ewald-rtol</A><br>
-<A HREF="#ewald">ewald-geometry</A><br>
-<A HREF="#ewald">epsilon-surface</A><br>
-<A HREF="#ef">E-x</A><br>
-<A HREF="#ef">E-xt</A><br>
-<A HREF="#ef">E-y</A><br>
-<A HREF="#ef">E-yt</A><br>
-<A HREF="#ef">E-z</A><br>
-<A HREF="#ef">E-zt </A><br>
-<A HREF="#shellmd">fcstep</A><br>
-<A HREF="#ewald">fourier-nx</A><br>
-<A HREF="#ewald">fourier-ny</A><br>
-<A HREF="#ewald">fourier-nz</A><br>
-<A HREF="#ewald">fourierspacing</A><br>
-<A HREF="#free">free-energy</A><br>
-<A HREF="#neq">freezedim </A><br>
-<A HREF="#neq">freezegrps</A><br>
-<A HREF="#vel">gen-seed</A><br>
-<A HREF="#vel">gen-temp</A><br>
-<A HREF="#vel">gen-vel</A><br>
-<A HREF="#pp">include</A><br>
-<A HREF="#free">init-lambda</A><br>
-<A HREF="#expanded">init-lambda-weights</A><br>
-<A HREF="#run">init-step</A><br>
-<A HREF="#expanded">initial-wl-delta</A><br>
-<A HREF="#run">integrator</A><br>
-<A HREF="#ld">ld-seed</A><br>
-<A HREF="#bond2">lincs-iter</A><br>
-<A HREF="#bond2">lincs-order</A><br>
-<A HREF="#bond2">lincs-warnangle</A><br>
-<A HREF="#expanded">lmc-forced-nstart</A><br>
-<A HREF="#expanded">lmc-gibbsdelta</A><br>
-<A HREF="#expanded">lmc-mc-move</A><br>
-<A HREF="#expanded">lmc-seed</A><br>
-<A HREF="#expanded">lmc-stats</A><br>
-<A HREF="#expanded">lmc-weights-equil</A><br>
-<A HREF="#expanded">mc-temperature</A><br>
-<A HREF="#expanded">mininum-var-min</A><br>
-<A HREF="#bond2">morse</A><br>
-<A HREF="#em">nbfgscorr</A><br>
-<A HREF="#shellmd">niter</A><br>
-<A HREF="#tc">nh-chain-length</A><br>
-<A HREF="#em">nstcgsteep</A><br>
-<A HREF="#out">nstcalcenergy</A><br>
-<A HREF="#run">nstcomm</A><br>
-<A HREF="#nmr">nstdisreout</A><br>
-<A HREF="#out">nstenergy</A><br>
-<A HREF="#run">nsteps</A><br>
-<A HREF="#out">nstfout</A><br>
-<A HREF="#nl">nstlist</A><br>
-<A HREF="#out">nstlog</A><br>
-<A HREF="#pc">nstpcouple</A><br>
-<A HREF="#tc">nsttcouple</A><br>
-<A HREF="#out">nstvout</A><br>
-<A HREF="#out">nstxout</A><br>
-<A HREF="#out">nstxout-compressed</A><br>
-<A HREF="#expanded">nst-transition-matrix</A><br>
-<A HREF="#nl">ns-type</A><br>
-<A HREF="#wall">nwall</A><br>
-<A HREF="#nmr2">orire</A><br>
-<A HREF="#nmr2">orire-fc</A><br>
-<A HREF="#nmr2">orire-tau</A><br>
-<A HREF="#nmr2">orire-fitgrp</A><br>
-<A HREF="#nmr2">nstorireout</A><br>
-<A HREF="#nl">pbc</A><br>
-<A HREF="#pc">pcoupl</A><br>
-<A HREF="#pc">pcoupltype</A><br>
-<A HREF="#nl">periodic-molecules</A><br>
-<A HREF="#ewald">pme-order</A><br>
-<A HREF="#pull">pull</A><br>
-<A HREF="#pc">refcoord-scaling</A><br>
-<A HREF="#pc">ref-p</A><br>
-<A HREF="#tc">ref-t</A><br>
-<A HREF="#el2">rcoulomb-switch</A><br>
-<A HREF="#el2">rcoulomb</A><br>
-<A HREF="#nl">rlist</A><br>
-<A HREF="#nl">rlistlong</A><br>
-<A HREF="#tpi">rtpi</A><br>
-<A HREF="#vdw">rvdw-switch</A><br>
-<A HREF="#vdw">rvdw</A><br>
-<A HREF="#free">sc-alpha</A><br>
-<A HREF="#free">sc-power</A><br>
-<A HREF="#free">sc-sigma</A><br>
-<A HREF="#bond2">shake-tol</A><br>
-<A HREF="#expanded">sim-temp-low</A><br>
-<A HREF="#expanded">sim-temp-high</A><br>
-<A HREF="#expanded">simulated-tempering</A><br>
-<A HREF="#expanded">simulated-tempering-scaling</A><br>
-<A HREF="#expanded">symmetrized-transition-matrix</A><br>
-<A HREF="#table">table-extension</A><br>
-<A HREF="#pc">tau-p</A><br>
-<A HREF="#tc">tau-t</A><br>
-<A HREF="#tc">tc-grps</A><br>
-<A HREF="#tc">tcoupl</A><br>
-<A HREF="#run">tinit</A><br>
-<A HREF="#bond">continuation</A><br>
-<A HREF="#user">user1-grps</A><br>
-<A HREF="#user">user2-grps</A><br>
-<A HREF="#user">userint1</A><br>
-<A HREF="#user">userint2</A><br>
-<A HREF="#user">userint3</A><br>
-<A HREF="#user">userint4</A><br>
-<A HREF="#user">userreal1</A><br>
-<A HREF="#user">userreal2</A><br>
-<A HREF="#user">userreal3</A><br>
-<A HREF="#user">userreal4</A><br>
-<A HREF="#vdw">vdwtype</A><br>
-<A HREF="#vdw">vdw-modifier</A><br>
-<A HREF="#nl">verlet-buffer-tolerance</A><br>
-<A HREF="#out">compressed-x-grps</A><br>
-<A HREF="#out">compressed-x-precision</A><br>
-<A HREF="#sa">zero-temp-time</A><br>
-<A HREF="#walls">wall-atomtype</A><br>
-<A HREF="#walls">wall-density</A><br>
-<A HREF="#walls">wall-ewald-zfac</A><br>
-<A HREF="#walls">wall-r-linpot</A><br>
-<A HREF="#walls">wall-type</A><br>
-<A HREF="#expanded">weight-equil-count-ratio</A><br>
-<A HREF="#expanded">weight-equil-number-all-lambda</A><br>
-<A HREF="#expanded">weight-equil-number-samples</A><br>
-<A HREF="#expanded">weight-equil-number-steps</A><br>
-<A HREF="#expanded">weight-equil-wl-delta</A><br>
-<A HREF="#expanded">wl-ratio</A><br>
-<A HREF="#expanded">wl-scale</A><br>
-</multicol>
+++ /dev/null
-<TITLE>Options</TITLE>
-<UL>
-<LI>
-Optional files are not used unless the option is set, in contrast to
-non optional files, where the default file name is used when the
-option is not set.
-<P>
-All GROMACS programs will accept file options without a file extension
-or filename being specified. In such cases the default filenames will
-be used. With multiple input file types, such as generic structure
-format, the directory will be searched for files of each type with the
-supplied or default name. When no such file is found, or with output
-files the first file type will be used.
-<P>
-All GROMACS programs with the exception of <tt>mdrun</tt>,
-<tt>trjcat</tt> and <tt>eneconv</tt> check if the command line options
-are valid. If this is not the case, the program will be halted.
-<P>
-<LI>
-All GROMACS programs have 4 hidden options:
-<TABLE BORDER=1 CELLSPACING=0 CELLPADDING=2>
-<TR><TH>option</TH><TH>type</TH><TH>default</TH><TH>description</TH></TR>
-<TR><TD ALIGN=RIGHT> <b><tt>-[no]hidden</tt></b> </TD><TD ALIGN=RIGHT> bool </TD><TD ALIGN=RIGHT> <tt> yes</tt> </TD><TD> [hidden] Print hidden options </TD></TD>
-<TR><TD ALIGN=RIGHT> <b><tt>-[no]quiet</tt></b> </TD><TD ALIGN=RIGHT> bool </TD><TD ALIGN=RIGHT> <tt> no</tt> </TD><TD> [hidden] Do not print help info </TD></TD>
-<TR><TD ALIGN=RIGHT> <b><tt>-man</tt></b> </TD><TD ALIGN=RIGHT> enum </TD><TD ALIGN=RIGHT> <tt>html</tt> </TD><TD> [hidden] Write manual and quit: no, html, tex, nroff, java, ascii or completion </TD></TD>
-<TR><TD ALIGN=RIGHT> <b><tt>-[no]debug</tt></b> </TD><TD ALIGN=RIGHT> bool </TD><TD ALIGN=RIGHT> <tt> no</tt> </TD><TD> [hidden] Write file with debug information </TD></TD>
-</TABLE>
-<P>
-<LI>
-Enumerated options (enum) should be used with one of the arguments
-listed in the option description, the argument may be abbreviated.
-The first match to the shortest argument in the list will be selected.
-<P>
-<LI>
-Vector options can be used with 1 or 3 parameters. When only one
-parameter is supplied the two others are also set to this value.
-<P>
-<LI>
-All GROMACS programs can read compressed or g-zipped files. There
-might be a problem with reading compressed <tt>.xtc</tt>,
-<tt>.trr</tt> files, but these will not compress
-very well anyway.
-<P>
-<LI>
-Most GROMACS programs can process a trajectory with less atoms than
-the run input or structure file, but only if the trajectory consists
-of the first n atoms of the run input or structure file.
-</UL>
#
# This file is part of the GROMACS molecular simulation package.
#
-# Copyright (c) 2014, by the GROMACS development team, led by
+# Copyright (c) 2014,2015, by the GROMACS development team, led by
# Mark Abraham, David van der Spoel, Berk Hess, and Erik Lindahl,
# and including many others, as listed in the AUTHORS file in the
# top-level source directory and at http://www.gromacs.org.
if(MARKDOWN_CONFIGURE_IS_POSSIBLE AND PANDOC_EXECUTABLE)
set(name "user-guide")
configure_markdown(main.md)
- make_markdown_html(${name} ${CMAKE_CURRENT_BINARY_DIR}/main.md)
- make_markdown_pdf(${name} ${CMAKE_CURRENT_BINARY_DIR}/main.md)
+ configure_markdown(references.md)
+
+ # TODO The concatenation of the markdown into a single document on
+ # the pandoc command line generated by CMake is not pretty, but
+ # there's no standard native include-file mechanism in
+ # Markdown. We should resolve this when we agree on a final
+ # generation platform.
+ list(APPEND list_of_markdown_files
+ ${CMAKE_CURRENT_SOURCE_DIR}/getting-started.md
+ ${CMAKE_CURRENT_SOURCE_DIR}/tools.md
+ ${CMAKE_CURRENT_SOURCE_DIR}/mdp-options.md
+ ${CMAKE_CURRENT_SOURCE_DIR}/cutoff-schemes.md
+ ${CMAKE_CURRENT_SOURCE_DIR}/mdrun-features.md
+ ${CMAKE_CURRENT_SOURCE_DIR}/mdrun-performance.md
+ ${CMAKE_CURRENT_SOURCE_DIR}/file-formats.md
+ ${CMAKE_CURRENT_SOURCE_DIR}/environment-variables.md
+ )
+
+ make_markdown_html(${name} ${CMAKE_CURRENT_BINARY_DIR}/main.md ${list_of_markdown_files} ${CMAKE_CURRENT_BINARY_DIR}/references.md)
+ make_markdown_pdf(${name} ${CMAKE_CURRENT_BINARY_DIR}/main.md ${list_of_markdown_files} ${CMAKE_CURRENT_BINARY_DIR}/references.md)
# Add a top-level target for the webpage build to hook onto
add_custom_target(${name}
--- /dev/null
+# Non-bonded cut-off schemes
+
+TODO in future patch
--- /dev/null
+
+# Environment Variables
+
+GROMACS programs may be influenced by the use of
+environment variables. First of all, the variables set in
+the `GMXRC` file are essential for running and
+compiling GROMACS. Some other useful environment variables are
+listed in the following sections. Most environment variables function
+by being set in your shell to any non-NULL value. Specific
+requirements are described below if other values need to be set. You
+should consult the documentation for your shell for instructions on
+how to set environment variables in the current shell, or in config
+files for future shells. Note that requirements for exporting
+environment variables to jobs run under batch control systems vary and
+you should consult your local documentation for details.
+
+## Output Control
+
+* `GMX_CONSTRAINTVIR`: print constraint virial and force virial energy terms.
+
+* `GMX_MAXBACKUP`: GROMACS automatically backs up old
+ copies of files when trying to write a new file of the same
+ name, and this variable controls the maximum number of
+ backups that will be made, default 99. If set to 0 it fails to
+ run if any output file already exists. And if set to -1 it
+ overwrites any output file without making a backup.
+
+* `GMX_NO_QUOTES`: if this is explicitly set, no cool quotes
+ will be printed at the end of a program.
+
+* `GMX_SUPPRESS_DUMP`: prevent dumping of step files during
+ (for example) blowing up during failure of constraint
+ algorithms.
+
+* `GMX_TPI_DUMP`: dump all configurations to a [.pdb]
+ file that have an interaction energy less than the value set
+ in this environment variable.
+
+* `GMX_VIEW_XPM`: `GMX_VIEW_XVG`, `GMX_VIEW_EPS` and `GMX_VIEW_PDB`, commands used to
+ automatically view [.xvg], [.xpm], [.eps]
+ and [.pdb] file types, respectively; they default to `xv`, `xmgrace`,
+ `ghostview` and `rasmol`. Set to empty to disable
+ automatic viewing of a particular file type. The command will
+ be forked off and run in the background at the same priority
+ as the GROMACS tool (which might not be what you want).
+ Be careful not to use a command which blocks the terminal
+ (e.g. `vi`), since multiple instances might be run.
+
+* `GMX_VIRIAL_TEMPERATURE`: print virial temperature energy term
+
+* `GMX_LOG_BUFFER`: the size of the buffer for file I/O. When set
+ to 0, all file I/O will be unbuffered and therefore very slow.
+ This can be handy for debugging purposes, because it ensures
+ that all files are always totally up-to-date.
+
+* `GMX_LOGO_COLOR`: set display color for logo in [gmx view].
+
+* `GMX_PRINT_LONGFORMAT`: use long float format when printing
+ decimal values.
+
+* `GMX_COMPELDUMP`: Applies for computational electrophysiology setups
+ only (see reference manual). The initial structure gets dumped to
+ [.pdb] file, which allows to check whether multimeric channels have
+ the correct PBC representation.
+
+## Debugging
+
+* `GMX_PRINT_DEBUG_LINES`: when set, print debugging info on line numbers.
+
+* `GMX_DD_NST_DUMP`: number of steps that elapse between dumping
+ the current DD to a PDB file (default 0). This only takes effect
+ during domain decomposition, so it should typically be
+ 0 (never), 1 (every DD phase) or a multiple of `nstlist`.
+
+* `GMX_DD_NST_DUMP_GRID`: number of steps that elapse between dumping
+ the current DD grid to a PDB file (default 0). This only takes effect
+ during domain decomposition, so it should typically be
+ 0 (never), 1 (every DD phase) or a multiple of `nstlist`.
+
+* `GMX_DD_DEBUG`: general debugging trigger for every domain
+ decomposition (default 0, meaning off). Currently only checks
+ global-local atom index mapping for consistency.
+
+* `GMX_DD_NPULSE`: over-ride the number of DD pulses used
+ (default 0, meaning no over-ride). Normally 1 or 2.
+
+* There are a number of extra environment variables like these
+ that are used in debugging - check the code!
+
+## Performance and Run Control
+
+* `GMX_DO_GALACTIC_DYNAMICS`: planetary simulations are made possible (just for fun) by setting
+ this environment variable, which allows setting `epsilon_r = -1` in the [.mdp]
+ file. Normally, `epsilon_r` must be greater than zero to prevent a fatal error.
+ See [wwwpage] for example input files for a planetary simulation.
+
+* `GMX_ALLOW_CPT_MISMATCH`: when set, runs will not exit if the
+ ensemble set in the [.tpr] file does not match that of the
+ [.cpt] file.
+
+* `GMX_CUDA_NB_EWALD_TWINCUT`: force the use of twin-range cutoff kernel even if `rvdw` =
+ `rcoulomb` after PP-PME load balancing. The switch to twin-range kernels is automated,
+ so this variable should be used only for benchmarking.
+
+* `GMX_CUDA_NB_ANA_EWALD`: force the use of analytical Ewald kernels. Should be used only for benchmarking.
+
+* `GMX_CUDA_NB_TAB_EWALD`: force the use of tabulated Ewald kernels. Should be used only for benchmarking.
+
+* `GMX_CUDA_STREAMSYNC`: force the use of cudaStreamSynchronize on ECC-enabled GPUs, which leads
+ to performance loss due to a known CUDA driver bug present in API v5.0 NVIDIA drivers (pre-30x.xx).
+ Cannot be set simultaneously with `GMX_NO_CUDA_STREAMSYNC`.
+
+* `GMX_CYCLE_ALL`: times all code during runs. Incompatible with threads.
+
+* `GMX_CYCLE_BARRIER`: calls MPI_Barrier before each cycle start/stop call.
+
+* `GMX_DD_ORDER_ZYX`: build domain decomposition cells in the order
+ (z, y, x) rather than the default (x, y, z).
+
+* `GMX_DD_USE_SENDRECV2`: during constraint and vsite communication, use a pair
+ of `MPI_SendRecv` calls instead of two simultaneous non-blocking calls
+ (default 0, meaning off). Might be faster on some MPI implementations.
+
+* `GMX_DLB_BASED_ON_FLOPS`: do domain-decomposition dynamic load balancing based on flop count rather than
+ measured time elapsed (default 0, meaning off).
+ This makes the load balancing reproducible, which can be useful for debugging purposes.
+ A value of 1 uses the flops; a value > 1 adds (value - 1)*5% of noise to the flops to increase the imbalance and the scaling.
+
+* `GMX_DLB_MAX_BOX_SCALING`: maximum percentage box scaling permitted per domain-decomposition
+ load-balancing step (default 10)
+
+* `GMX_DD_RECORD_LOAD`: record DD load statistics for reporting at end of the run (default 1, meaning on)
+
+* `GMX_DD_NST_SORT_CHARGE_GROUPS`: number of steps that elapse between re-sorting of the charge
+ groups (default 1). This only takes effect during domain decomposition, so should typically
+ be 0 (never), 1 (to mean at every domain decomposition), or a multiple of `nstlist`.
+
+* `GMX_DETAILED_PERF_STATS`: when set, print slightly more detailed performance information
+ to the [.log] file. The resulting output is the way performance summary is reported in versions
+ 4.5.x and thus may be useful for anyone using scripts to parse [.log] files or standard output.
+
+* `GMX_DISABLE_SIMD_KERNELS`: disables architecture-specific SIMD-optimized (SSE2, SSE4.1, AVX, etc.)
+ non-bonded kernels thus forcing the use of plain C kernels.
+
+* `GMX_DISABLE_CUDA_TIMING`: timing of asynchronously executed GPU operations can have a
+ non-negligible overhead with short step times. Disabling timing can improve performance in these cases.
+
+* `GMX_DISABLE_GPU_DETECTION`: when set, disables GPU detection even if [mdrun] was compiled
+ with GPU support.
+
+* `GMX_DISRE_ENSEMBLE_SIZE`: the number of systems for distance restraint ensemble
+ averaging. Takes an integer value.
+
+* `GMX_EMULATE_GPU`: emulate GPU runs by using algorithmically equivalent CPU reference code instead of
+ GPU-accelerated functions. As the CPU code is slow, it is intended to be used only for debugging purposes.
+ The behavior is automatically triggered if non-bonded calculations are turned off using `GMX_NO_NONBONDED`
+ case in which the non-bonded calculations will not be called, but the CPU-GPU transfer will also be skipped.
+
+* `GMX_ENX_NO_FATAL`: disable exiting upon encountering a corrupted frame in an [.edr]
+ file, allowing the use of all frames up until the corruption.
+
+* `GMX_FORCE_UPDATE`: update forces when invoking `mdrun -rerun`.
+
+* `GMX_GPU_ID`: set in the same way as `mdrun -gpu_id`, `GMX_GPU_ID`
+ allows the user to specify different GPU id-s, which can be useful for selecting different
+ devices on different compute nodes in a cluster. Cannot be used in conjunction with `mdrun -gpu_id`.
+
+* `GMX_IGNORE_FSYNC_FAILURE_ENV`: allow [mdrun] to continue even if
+ a file is missing.
+
+* `GMX_LJCOMB_TOL`: when set to a floating-point value, overrides the default tolerance of
+ 1e-5 for force-field floating-point parameters.
+
+* `GMX_MAX_MPI_THREADS`: sets the maximum number of MPI-threads that [mdrun]
+ can use.
+
+* `GMX_MAXCONSTRWARN`: if set to -1, [mdrun] will
+ not exit if it produces too many LINCS warnings.
+
+* `GMX_NB_GENERIC`: use the generic C kernel. Should be set if using
+ the group-based cutoff scheme and also sets `GMX_NO_SOLV_OPT` to be true,
+ thus disabling solvent optimizations as well.
+
+* `GMX_NB_MIN_CI`: neighbor list balancing parameter used when running on GPU. Sets the
+ target minimum number pair-lists in order to improve multi-processor load-balance for better
+ performance with small simulation systems. Must be set to a positive integer, the default value
+ is optimized for NVIDIA Fermi and Kepler GPUs, therefore changing it is not necessary for
+ normal usage, but it can be useful on future architectures.
+
+* `GMX_NBLISTCG`: use neighbor list and kernels based on charge groups.
+
+* `GMX_NBNXN_CYCLE`: when set, print detailed neighbor search cycle counting.
+
+* `GMX_NBNXN_EWALD_ANALYTICAL`: force the use of analytical Ewald non-bonded kernels,
+ mutually exclusive of `GMX_NBNXN_EWALD_TABLE`.
+
+* `GMX_NBNXN_EWALD_TABLE`: force the use of tabulated Ewald non-bonded kernels,
+ mutually exclusive of `GMX_NBNXN_EWALD_ANALYTICAL`.
+
+* `GMX_NBNXN_SIMD_2XNN`: force the use of 2x(N+N) SIMD CPU non-bonded kernels,
+ mutually exclusive of `GMX_NBNXN_SIMD_4XN`.
+
+* `GMX_NBNXN_SIMD_4XN`: force the use of 4xN SIMD CPU non-bonded kernels,
+ mutually exclusive of `GMX_NBNXN_SIMD_2XNN`.
+
+* `GMX_NO_ALLVSALL`: disables optimized all-vs-all kernels.
+
+* `GMX_NO_CART_REORDER`: used in initializing domain decomposition communicators. Rank reordering
+ is default, but can be switched off with this environment variable.
+
+* `GMX_NO_CUDA_STREAMSYNC`: the opposite of `GMX_CUDA_STREAMSYNC`. Disables the use of the
+ standard cudaStreamSynchronize-based GPU waiting to improve performance when using CUDA driver API
+ ealier than v5.0 with ECC-enabled GPUs.
+
+* `GMX_NO_INT`, `GMX_NO_TERM`, `GMX_NO_USR1`: disable signal handlers for SIGINT,
+ SIGTERM, and SIGUSR1, respectively.
+
+* `GMX_NO_NODECOMM`: do not use separate inter- and intra-node communicators.
+
+* `GMX_NO_NONBONDED`: skip non-bonded calculations; can be used to estimate the possible
+ performance gain from adding a GPU accelerator to the current hardware setup -- assuming that this is
+ fast enough to complete the non-bonded calculations while the CPU does bonded force and PME computation.
+
+* `GMX_NO_PULLVIR`: when set, do not add virial contribution to COM pull forces.
+
+* `GMX_NOCHARGEGROUPS`: disables multi-atom charge groups, i.e. each atom
+ in all non-solvent molecules is assigned its own charge group.
+
+* `GMX_NOPREDICT`: shell positions are not predicted.
+
+* `GMX_NO_SOLV_OPT`: turns off solvent optimizations; automatic if `GMX_NB_GENERIC`
+ is enabled.
+
+* `GMX_NSCELL_NCG`: the ideal number of charge groups per neighbor searching grid cell is hard-coded
+ to a value of 10. Setting this environment variable to any other integer value overrides this hard-coded
+ value.
+
+* `GMX_PME_NTHREADS`: set the number of OpenMP or PME threads (overrides the number guessed by
+ [mdrun].
+
+* `GMX_PME_P3M`: use P3M-optimized influence function instead of smooth PME B-spline interpolation.
+
+* `GMX_PME_THREAD_DIVISION`: PME thread division in the format "x y z" for all three dimensions. The
+ sum of the threads in each dimension must equal the total number of PME threads (set in
+ `GMX_PME_NTHREADS`).
+
+* `GMX_PMEONEDD`: if the number of domain decomposition cells is set to 1 for both x and y,
+ decompose PME in one dimension.
+
+* `GMX_REQUIRE_SHELL_INIT`: require that shell positions are initiated.
+
+* `GMX_REQUIRE_TABLES`: require the use of tabulated Coulombic
+ and van der Waals interactions.
+
+* `GMX_SCSIGMA_MIN`: the minimum value for soft-core sigma. **Note** that this value is set
+ using the `sc-sigma` keyword in the [.mdp] file, but this environment variable can be used
+ to reproduce pre-4.5 behavior with respect to this parameter.
+
+* `GMX_TPIC_MASSES`: should contain multiple masses used for test particle insertion into a cavity.
+ The center of mass of the last atoms is used for insertion into the cavity.
+
+* `GMX_USE_GRAPH`: use graph for bonded interactions.
+
+* `GMX_VERLET_BUFFER_RES`: resolution of buffer size in Verlet cutoff scheme. The default value is
+ 0.001, but can be overridden with this environment variable.
+
+* `MPIRUN`: the `mpirun` command used by [gmx tune_pme].
+
+* `MDRUN`: the [mdrun] command used by [gmx tune_pme].
+
+* `GMX_NSTLIST`: sets the default value for `nstlist`, preventing it from being tuned during
+ [mdrun] startup when using the Verlet cutoff scheme.
+
+* `GMX_USE_TREEREDUCE`: use tree reduction for nbnxn force reduction. Potentially faster for large number of
+ OpenMP threads (if memory locality is important).
+
+## Analysis and Core Functions
+
+* `GMX_QM_ACCURACY`: accuracy in Gaussian L510 (MC-SCF) component program.
+
+* `GMX_QM_ORCA_BASENAME`: prefix of [.tpr] files, used in Orca calculations
+ for input and output file names.
+
+* `GMX_QM_CPMCSCF`: when set to a nonzero value, Gaussian QM calculations will
+ iteratively solve the CP-MCSCF equations.
+
+* `GMX_QM_MODIFIED_LINKS_DIR`: location of modified links in Gaussian.
+
+* `DSSP`: used by [gmx do_dssp] to point to the `dssp`
+ executable (not just its path).
+
+* `GMX_QM_GAUSS_DIR`: directory where Gaussian is installed.
+
+* `GMX_QM_GAUSS_EXE`: name of the Gaussian executable.
+
+* `GMX_DIPOLE_SPACING`: spacing used by [gmx dipoles].
+
+* `GMX_MAXRESRENUM`: sets the maximum number of residues to be renumbered by
+ [gmx grompp]. A value of -1 indicates all residues should be renumbered.
+
+* `GMX_FFRTP_TER_RENAME`: Some force fields (like AMBER) use specific names for N- and C-
+ terminal residues (NXXX and CXXX) as [.rtp] entries that are normally renamed. Setting
+ this environment variable disables this renaming.
+
+* `GMX_PATH_GZIP`: `gunzip` executable, used by [gmx wham].
+
+* `GMX_FONT`: name of X11 font used by [gmx view].
+
+* `GMXTIMEUNIT`: the time unit used in output files, can be
+ anything in fs, ps, ns, us, ms, s, m or h.
+
+* `GMX_QM_GAUSSIAN_MEMORY`: memory used for Gaussian QM calculation.
+
+* `MULTIPROT`: name of the `multiprot` executable, used by the
+ contributed program `do_multiprot`.
+
+* `NCPUS`: number of CPUs to be used for Gaussian QM calculation
+
+* `GMX_ORCA_PATH`: directory where Orca is installed.
+
+* `GMX_QM_SA_STEP`: simulated annealing step size for Gaussian QM calculation.
+
+* `GMX_QM_GROUND_STATE`: defines state for Gaussian surface hopping calculation.
+
+* `GMX_TOTAL`: name of the `total` executable used by the contributed
+ `do_shift` program.
+
+* `GMX_ENER_VERBOSE`: make [gmx energy] and [gmx eneconv]
+ loud and noisy.
+
+* `VMD_PLUGIN_PATH`: where to find VMD plug-ins. Needed to be
+ able to read file formats recognized only by a VMD plug-in.
+
+* `VMDDIR`: base path of VMD installation.
+
+* `GMX_USE_XMGR`: sets viewer to `xmgr` (deprecated) instead of `xmgrace`.
--- /dev/null
+# GROMACS file formats
+
+TODO in future patch: gather information from
+docs/old-html/online/*html, convert to Markdown, update for accuracy,
+organize here.
--- /dev/null
+# Getting started with GROMACS
+
+In this chapter we assume the reader is familiar with Molecular Dynamics and
+familiar with Unix, including the use of a text editor such as `jot`, `emacs`
+or `vi`. We furthermore assume the GROMACS software is installed properly on
+your system. When you see a line like
+
+ ls -l
+
+you are supposed to type the contents of that line on your computer terminal.
+
+## Setting up your environment
+
+In order to check whether you have access to GROMACS, please
+start by entering the command:
+
+ gmx -version
+
+This command should print out information about the version of Gromacs
+installed. If this, in contrast, returns the phrase
+
+ gmx: command not found.
+
+then you have to find where your version of GROMACS is installed. In
+the default case, the binaries are located in
+`/usr/local/gromacs/bin`, however, you can ask your local system
+administrator for more information, and then follow the advice in the
+[install guide](install-guide.html#getting-access-to-gromacs-after-installation).
+
+## Flowchart of typical GROMACS simulation
+
+A typical simulation workflow with GROMACS is [illustrated here](online/flow.html).
+
+## Important GROMACS files
+
+Here is an overview of the most important GROMACS file types that you will
+encounter.
+
+### Molecular Topology file (`.top`)
+
+The molecular topology file is generated by the program [gmx pdb2gmx]. [gmx pdb2gmx] translates a [PDB] structure file of any peptide or protein to a molecular topology file. This topology file contains a complete description of all the interactions in your peptide or protein.
+
+### Molecular Structure file (`.gro`, `.pdb`)
+
+When [gmx pdb2gmx] is executed to generate a molecular topology, it also translates the structure file ([.pdb] file) to a GROMOS structure file ([.gro] file). The main difference between a [pdb] file and a gromos file is their format and that a [.gro] file can also hold velocities. However, if you do not need the velocities, you can also use a [PDB] file in all programs. To generate a box of solvent molecules around the peptide, the program [gmx solvate] is used. First the program [gmx editconf] should be used to define a box of appropriate size around the molecule. [gmx solvate] solvates a solute molecule (the peptide) into any solvent (in this case, water). The output of [gmx solvate] is a gromos structure file of the peptide solvated in water. [gmx solvate] also changes the molecular topology file (generated by [gmx pdb2gmx]) to add solvent to the topology.
+
+### Molecular Dynamics parameter file (`.mdp`)
+
+The Molecular Dynamics Parameter ([.mdp]) file contains all information about the Molecular Dynamics simulation itself e.g. time-step, number of steps, temperature, pressure etc. The easiest way of handling such a file is by adapting a sample [.mdp] file. A [sample mdp file](online/mdp.html) is available.
+
+### Index file (`.ndx`)
+
+Sometimes you may need an index file to specify actions on groups of atoms (e.g. temperature coupling, accelerations, freezing). Usually the default index groups will be sufficient, so for this demo we will not consider the use of index files.
+
+### Run input file (`.tpr`)
+
+The next step is to combine the molecular structure ([.gro] file), topology ([.top] file) MD-parameters ([.mdp] file) and (optionally) the index file ([.ndx]) to generate a run input file ([.tpr] extension). This file contains all information needed to start a simulation with GROMACS. The [gmx grompp] program processes all input files and generates the run input [.tpr] file.
+
+### Trajectory file (`.trr`)
+
+Once the run input file is available, we can start the simulation. The program which starts the simulation is called [gmx mdrun] (or sometimes just mdrun, or mdrun_mpi). The only input file of [gmx mdrun] that you usually need in order to start a run is the run input file ([.tpr] file). The typical output files of [gmx mdrun] are the trajectory file ([.trr] file), a logfile ( [.log] file),
+and perhaps a checkpoint file ([.cpt] file).
+
+## Tutorial material
+
+There are [many tutorials
+available](http://www.gromacs.org/Documentation/Tutorials) that cover
+aspects of using GROMACS.
+
+## Background reading
+
+> Berendsen, H.J.C., Postma, J.P.M., van Gunsteren, W.F., Hermans, J. (1981)
+Intermolecular Forces, chapter Interaction models for water in relation to
+protein hydration, pp 331-342. Dordrecht: D. Reidel Publishing Company
+Dordrecht
+
+>
+
+> Kabsch, W., Sander, C. (1983). Dictionary of protein secondary
+structure: Pattern recognition of hydrogen-bonded and geometrical features.
+Biopolymers **22**, 2577--2637.
+
+>
+
+> Mierke, D.F., Kessler, H. (1991). Molecular dynamics with dimethyl
+sulfoxide as a solvent. Conformation of a cyclic hexapeptide. J. Am. Chem.
+Soc. **113**, 9446.
+
+>
+
+> Stryer, L. (1988). Biochemistry vol. 1, p. 211. New York: Freeman, 3
+edition.
# Introduction #
-Coming soon!
+This guide provides
+
+* material introducing GROMACS
+* practical advice for making effective use of GROMACS.
+
+For getting, building and installing GROMACS, see the [install
+guide]. For background on algorithms and implementations, see the
+[reference manual].
--- /dev/null
+# Molecular dynamics parameters (.mdp options)
+
+## General information
+
+Default values are given in parentheses. The first option in the list is always the default option. Units are given in square brackets The difference between a dash and an underscore is ignored.
+
+A [sample `.mdp` file](online/mdp.html) is available. This should be appropriate to start a normal simulation. Edit it to suit your specific needs and desires.
+
+
+### Preprocessing
+
+include:
+: directories to include in your topology. Format: `-I/home/john/mylib -I../otherlib`
+
+define:
+: defines to pass to the preprocessor, default is no defines. You can use any defines to control options in your customized topology files. Options that are already available by default are:
+ `-DFLEXIBLE` will use flexible water instead of rigid water into your topology, this can be useful for normal mode analysis.
+ `-DPOSRES` will trigger the inclusion of `posre.itp` into your topology, used for position restraints.
+
+
+### Run control
+
+integrator:
+: (Despite the name, this list includes algorithms that are not actually integrators. **steep** and all entries following it are in this category)
+
+ md
+ : A leap-frog algorithm for integrating Newton's equations of motion.
+
+ md-vv
+ : A velocity Verlet algorithm for integrating Newton's equations of motion. For constant NVE simulations started from corresponding points in the same trajectory, the trajectories are analytically, but not binary, identical to the **md** leap-frog integrator. The the kinetic energy, which is determined from the whole step velocities and is therefore slightly too high. The advantage of this integrator is more accurate, reversible Nose-Hoover and Parrinello-Rahman coupling integration based on Trotter expansion, as well as (slightly too small) full step velocity output. This all comes at the cost off extra computation, especially with constraints and extra communication in parallel. Note that for nearly all production simulations the **md** integrator is accurate enough.
+
+ md-vv-avek
+ : A velocity Verlet algorithm identical to **md-vv**, except that the kinetic energy is determined as the average of the two half step kinetic energies as in the **md** integrator, and this thus more accurate. With Nose-Hoover and/or Parrinello-Rahman coupling this comes with a slight increase in computational cost.
+
+ sd
+ : An accurate and efficient leap-frog stochastic dynamics integrator. With constraints, coordinates needs to be constrained twice per integration step. Depending on the computational cost of the force calculation, this can take a significant part of the simulation time. The temperature for one or more groups of atoms (**tc-grps**) is set with **ref-t**, the inverse friction constant for each group is set with **tau-t**. The parameter **tcoupl** is ignored. The random generator is initialized with **ld-seed**. When used as a thermostat, an appropriate value for **tau-t** is 2 ps, since this results in a friction that is lower than the internal friction of water, while it is high enough to remove excess heat NOTE: temperature deviations decay twice as fast as with a Berendsen thermostat with the same **tau-t**.
+
+ sd2
+ : This used to be the default sd integrator, but is now deprecated. Four Gaussian random numbers are required per coordinate per step. With constraints, the temperature will be slightly too high.
+
+ bd
+ : An Euler integrator for Brownian or position Langevin dynamics, the velocity is the force divided by a friction coefficient (**bd-fric**) plus random thermal noise (**ref-t**). When **bd-fric**`=0`, the friction coefficient for each particle is calculated as mass/**tau-t**, as for the integrator **sd**. The random generator is initialized with **ld-seed**.
+
+ steep
+ : A steepest descent algorithm for energy minimization. The maximum step size is **emstep**, the tolerance is **emtol**.
+
+ cg
+ : A conjugate gradient algorithm for energy minimization, the tolerance is **emtol**. CG is more efficient when a steepest descent step is done every once in a while, this is determined by **nstcgsteep**. For a minimization prior to a normal mode analysis, which requires a very high accuracy, GROMACS should be compiled in double precision.
+
+ l-bfgs
+ : A quasi-Newtonian algorithm for energy minimization according to the low-memory Broyden-Fletcher-Goldfarb-Shanno approach. In practice this seems to converge faster than Conjugate Gradients, but due to the correction steps necessary it is not (yet) parallelized.
+
+ nm
+ : Normal mode analysis is performed on the structure in the [.tpr] file. GROMACS should be compiled in double precision.
+
+ tpi
+ : Test particle insertion. The last molecule in the topology is the test particle. A trajectory must be provided to `mdrun -rerun`. This trajectory should not contain the molecule to be inserted. Insertions are performed **nsteps** times in each frame at random locations and with random orientiations of the molecule. When **nstlist** is larger than one, **nstlist** insertions are performed in a sphere with radius **rtpi** around a the same random location using the same neighborlist (and the same long-range energy when **rvdw** or **rcoulomb**>**rlist**, which is only allowed for single-atom molecules). Since neighborlist construction is expensive, one can perform several extra insertions with the same list almost for free. The random seed is set with **ld-seed**. The temperature for the Boltzmann weighting is set with **ref-t**, this should match the temperature of the simulation of the original trajectory. Dispersion correction is implemented correctly for TPI. All relevant quantities are written to the file specified with `mdrun -tpi`. The distribution of insertion energies is written to the file specified with `mdrun -tpid`. No trajectory or energy file is written. Parallel TPI gives identical results to single-node TPI. For charged molecules, using PME with a fine grid is most accurate and also efficient, since the potential in the system only needs to be calculated once per frame.
+
+ tpic
+ : Test particle insertion into a predefined cavity location. The procedure is the same as for **tpi**, except that one coordinate extra is read from the trajectory, which is used as the insertion location. The molecule to be inserted should be centered at 0,0,0. Gromacs does not do this for you, since for different situations a different way of centering might be optimal. Also **rtpi** sets the radius for the sphere around this location. Neighbor searching is done only once per frame, **nstlist** is not used. Parallel **tpic** gives identical results to single-rank **tpic**.
+
+tinit: (0) [ps]
+: starting time for your run (only makes sense for integrators **md**, **sd** and **bd**)
+
+dt: (0.001) [ps]
+: time step for integration (only makes sense for integrators **md**, **sd** and **bd**)
+
+nsteps: (0)
+: maximum number of steps to integrate or minimize, -1 is no maximum
+
+init-step: (0)
+: The starting step. The time at an step i in a run is calculated as: t = **tinit** + **dt** * (**init-step** + i). The free-energy lambda is calculated as: lambda = **init-lambda** + **delta-lambda** * (**init-step** + i). Also non-equilibrium MD parameters can depend on the step number. Thus for exact restarts or redoing part of a run it might be necessary to set **init-step** to the step number of the restart frame. [gmx convert-tpr] does this automatically.
+
+comm-mode:
+: + **Linear**
+ Remove center of mass translation
+
+ + **Angular**
+ Remove center of mass translation and rotation around the center of mass
+
+ + **None**
+ No restriction on the center of mass motion
+
+nstcomm: (100) [steps]
+: frequency for center of mass motion removal
+
+comm-grps:
+: group(s) for center of mass motion removal, default is the whole system
+
+
+### Langevin dynamics
+
+bd-fric: (0) [amu ps-1]
+: Brownian dynamics friction coefficient. When **bd-fric** =0, the friction coefficient for each particle is calculated as mass/**tau-t**.
+
+ld-seed: (-1) [integer]
+: used to initialize random generator for thermal noise for stochastic and Brownian dynamics. When **ld-seed** is set to -1, a pseudo random seed is used. When running BD or SD on multiple processors, each processor uses a seed equal to **ld-seed** plus the processor number.
+
+
+### Energy minimization
+
+emtol: (10.0) [kJ mol-1 nm-1]
+: the minimization is converged when the maximum force is smaller than this value
+
+emstep: (0.01) [nm]
+: initial step-size
+
+nstcgsteep: (1000) [steps]
+: frequency of performing 1 steepest descent step while doing conjugate gradient energy minimization.
+
+nbfgscorr: (10)
+: Number of correction steps to use for L-BFGS minimization. A higher number is (at least theoretically) more accurate, but slower.
+
+
+### Shell Molecular Dynamics
+
+When shells or flexible constraints are present in the system the positions of the shells and the lengths of the flexible constraints are optimized at every
+time step until either the RMS force on the shells and constraints is less than emtol, or a maximum number of iterations **niter** has been reached
+
+emtol: (10.0) [kJ mol-1 nm-1]
+: the minimization is converged when the maximum force is smaller than this value. For shell MD this value should be 1.0 at most, but since the variable is used for energy minimization as well the default is 10.0.
+
+niter: (20)
+: maximum number of iterations for optimizing the shell positions and the flexible constraints.
+
+fcstep: (0) [ps2]
+: the step size for optimizing the flexible constraints. Should be chosen as mu/(d2V/dq2) where mu is the reduced mass of two particles in a flexible constraint and d2V/dq2 is the second derivative of the potential in the constraint direction. Hopefully this number does not differ too much between the flexible constraints, as the number of iterations and thus the runtime is very sensitive to **fcstep**. Try several values!
+
+
+### Test particle insertion
+
+rtpi: (0.05) [nm]
+: the test particle insertion radius, see integrators **tpi** and **tpic**
+
+
+### Output control
+
+nstxout: (0) [steps]
+: number of steps that elapse between writing coordinates to output trajectory file, the last coordinates are always written
+
+nstvout: (0) [steps]
+: number of steps that elapse between writing velocities to output trajectory, the last velocities are always written
+
+nstfout: (0) [steps]
+: number of steps that elapse between writing forces to output trajectory.
+
+nstlog: (1000) [steps]
+: number of steps that elapse between writing energies to the log file, the last energies are always written
+
+nstcalcenergy: (100)
+: number of steps that elapse between calculating the energies, 0 is never. This option is only relevant with dynamics. With a twin-range cut-off setup **nstcalcenergy** should be equal to or a multiple of **nstlist**. This option affects the performance in parallel simulations, because calculating energies requires global communication between all processes which can become a bottleneck at high parallelization.
+
+nstenergy: (1000) [steps]
+: number of steps that else between writing energies to energy file, the last energies are always written, should be a multiple of **nstcalcenergy**. Note that the exact sums and fluctuations over all MD steps modulo **nstcalcenergy** are stored in the energy file, so [gmx energy] can report exact energy averages and fluctuations also when **nstenergy** >1
+
+nstxout-compressed: (0) [steps]
+: number of steps that elapse between writing position coordinates using lossy compression
+
+compressed-x-precision: (1000) [real]
+: precision with which to write to the compressed trajectory file
+
+compressed-x-grps:
+: group(s) to write to the compressed trajectory file, by default the whole system is written (if **nstxout-compressed** > 0)
+
+energygrps:
+: group(s) to write to energy file
+
+
+### Neighbor searching
+
+cutoff-scheme:
+: + **Verlet**
+ Generate a pair list with buffering. The buffer size is automatically set based on **verlet-buffer-tolerance**, unless this is set to -1, in which case **rlist** will be used. This option has an explicit, exact cut-off at **rvdw**=**rcoulomb**. Currently only cut-off, reaction-field, PME electrostatics and plain LJ are supported. Some [mdrun] functionality is not yet supported with the **Verlet** scheme, but [gmx grompp] checks for this. Native GPU acceleration is only supported with **Verlet**. With GPU-accelerated PME or with separate PME ranks, [mdrun] will automatically tune the CPU/GPU load balance by scaling **rcoulomb** and the grid spacing. This can be turned off with `mdrun -notunepme`. **Verlet** is faster than **group** when there is no water, or if **group** would use a pair-list buffer to conserve energy.
+
+ + **group**
+ Generate a pair list for groups of atoms. These groups correspond to the charge groups in the topology. This was the only cut-off treatment scheme before version 4.6, and is **deprecated in 5.0**. There is no explicit buffering of the pair list. This enables efficient force calculations for water, but energy is only conserved when a buffer is explicitly added.
+
+nstlist: (10) [steps]
+: + **>0**
+ Frequency to update the neighbor list (and the long-range forces, when using twin-range cut-offs). When this is 0, the neighbor list is made only once. With energy minimization the neighborlist will be updated for every energy evaluation when **nstlist** >0. With **cutoff-scheme=Verlet** and **verlet-buffer-tolerance** set, **nstlist** is actually a minimum value and [mdrun] might increase it, unless it is set to 1. With parallel simulations and/or non-bonded force calculation on the GPU, a value of 20 or 40 often gives the best performance. With **cutoff-scheme=Group** and non-exact cut-off's, **nstlist** will affect the accuracy of your simulation and it can not be chosen freely.
+
+ + **0**
+ The neighbor list is only constructed once and never updated. This is mainly useful for vacuum simulations in which all particles see each other.
+
+ + **<0**
+ Unused.
+
+nstcalclr: (-1) [steps]
+: Controls the period between calculations of long-range forces when using the group cut-off scheme.
+
+ + **1**
+ Calculate the long-range forces every single step. This is useful to have separate neighbor lists with buffers for electrostatics and Van der Waals interactions, and in particular it makes it possible to have the Van der Waals cutoff longer than electrostatics (useful _e.g._ with PME). However, there is no point in having identical long-range cutoffs for both interaction forms and update them every step - then it will be slightly faster to put everything in the short-range list.
+
+ + **>1**
+ Calculate the long-range forces every **nstcalclr** steps and use a multiple-time-step integrator to combine forces. This can now be done more frequently than **nstlist** since the lists are stored, and it might be a good idea _e.g._ for Van der Waals interactions that vary slower than electrostatics.
+
+ + **-1**
+ Calculate long-range forces on steps where neighbor searching is performed. While this is the default value, you might want to consider updating the long-range forces more frequently.
+
+ Note that twin-range force evaluation might be enabled automatically by PP-PME load balancing. This is done in order to maintain the chosen Van der Waals interaction radius even if the load balancing is changing the electrostatics cutoff. If the [.mdp] file already specifies twin-range interactions (_e.g._ to evaluate Lennard-Jones interactions with a longer cutoff than the PME electrostatics every 2-3 steps), the load balancing will have also a small effect on Lennard-Jones, since the short-range cutoff (inside which forces are evaluated every step) is changed.
+
+ns-type:
+: + **grid**
+ Make a grid in the box and only check atoms in neighboring grid cells when constructing a new neighbor list every **nstlist** steps. In large systems grid search is much faster than simple search.
+
+ + **simple**
+ Check every atom in the box when constructing a new neighbor list every **nstlist** steps (only with **cutoff-scheme=group**).
+
+pbc:
+: + **xyz**
+ Use periodic boundary conditions in all directions.
+
+ + **no**
+ Use no periodic boundary conditions, ignore the box. To simulate without cut-offs, set all cut-offs and **nstlist** to 0. For best performance without cut-offs on a single MPI rank, set **nstlist** to zero and `ns-type=simple`.
+
+ + **xy**
+ Use periodic boundary conditions in x and y directions only. This works only with `ns-type=grid` and can be used in combination with **walls**. Without walls or with only one wall the system size is infinite in the z direction. Therefore pressure coupling or Ewald summation methods can not be used. These disadvantages do not apply when two walls are used.
+
+periodic-molecules:
+: + **no**
+ molecules are finite, fast molecular PBC can be used
+
+ + **yes**
+ for systems with molecules that couple to themselves through the periodic boundary conditions, this requires a slower PBC algorithm and molecules are not made whole in the output
+
+verlet-buffer-tolerance: (0.005) [kJ/mol/ps]
+: Useful only with **cutoff-scheme**=**Verlet**. This sets the maximum allowed error for pair interactions per particle caused by the Verlet buffer, which indirectly sets **rlist**. As both **nstlist** and the Verlet buffer size are fixed (for performance reasons), particle pairs not in the pair list can occasionally get within the cut-off distance during **nstlist**-1 nsteps. This causes very small jumps in the energy. In a constant-temperature ensemble, these very small energy jumps can be estimated for a given cut-off and **rlist**. The estimate assumes a homogeneous particle distribution, hence the errors might be slightly underestimated for multi-phase systems. For longer pair-list life-time (**nstlist**-1)*dt the buffer is overestimated, because the interactions between particles are ignored. Combined with cancellation of errors, the actual drift of the total energy is usually one to two orders of magnitude smaller. Note that the generated buffer size takes into account that the GROMACS pair-list setup leads to a reduction in the drift by a factor 10, compared to a simple particle-pair based list. Without dynamics (energy minimization etc.), the buffer is 5% of the cut-off. For NVE simulations the initial temperature is used, unless this is zero, in which case a buffer of 10% is used. For NVE simulations the tolerance usually needs to be lowered to achieve proper energy conservation on the nanosecond time scale. To override the automated buffer setting, use **verlet-buffer-tolerance**=-1 and set **rlist** manually.
+
+rlist: (1) [nm]
+: Cut-off distance for the short-range neighbor list. With **cutoff-scheme**=**Verlet**, this is by default set by the **verlet-buffer-tolerance** option and the value of **rlist** is ignored.
+
+rlistlong: (-1) [nm]
+: Cut-off distance for the long-range neighbor list. This parameter is only relevant for a twin-range cut-off setup with switched potentials. In that case a buffer region is required to account for the size of charge groups. In all other cases this parameter is automatically set to the longest cut-off distance.
+
+
+### Electrostatics
+
+coulombtype:
+: + **Cut-off**
+ Twin range cut-offs with neighborlist cut-off **rlist** and Coulomb cut-off **rcoulomb**, where **rcoulomb**>=**rlist**.
+
+ + **Ewald**
+ Classical Ewald sum electrostatics. The real-space cut-off **rcoulomb** should be equal to **rlist**. Use _e.g._ **rlist** =0.9, **rcoulomb** =0.9. The highest magnitude of wave vectors used in reciprocal space is controlled by **fourierspacing**. The relative accuracy of direct/reciprocal space is controlled by **ewald-rtol**.
+ NOTE: Ewald scales as O(N3/2) and is thus extremely slow for large systems. It is included mainly for reference - in most cases PME will perform much better.
+
+ + **PME**
+ Fast smooth Particle-Mesh Ewald (SPME) electrostatics. Direct space is similar to the Ewald sum, while the reciprocal part is performed with FFTs. Grid dimensions are controlled with **fourierspacing** and the interpolation order with **pme-order**. With a grid spacing of 0.1 nm and cubic interpolation the electrostatic forces have an accuracy of 2-3*10-4. Since the error from the vdw-cutoff is larger than this you might try 0.15 nm. When running in parallel the interpolation parallelizes better than the FFT, so try decreasing grid dimensions while increasing interpolation.
+
+ + **P3M-AD**
+ Particle-Particle Particle-Mesh algorithm with analytical derivative for for long range electrostatic interactions. The method and code is identical to SPME, except that the influence function is optimized for the grid. This gives a slight increase in accuracy.
+
+ + **Reaction-Field electrostatics**
+ Reaction field with Coulomb cut-off **rcoulomb**, where **rcoulomb** >= **rlist**. The dielectric constant beyond the cut-off is **epsilon-rf**. The dielectric constant can be set to infinity by setting **epsilon-rf**=0.
+
+ + **Generalized-Reaction-Field**
+ Generalized reaction field with Coulomb cut-off **rcoulomb**, where **rcoulomb** >= **rlist**. The dielectric constant beyond the cut-off is **epsilon-rf**. The ionic strength is computed from the number of charged (_i.e._ with non zero charge) charge groups. The temperature for the GRF potential is set with **ref-t**.
+
+ + **Reaction-Field-zero**
+ In GROMACS, normal reaction-field electrostatics with **cutoff-scheme****=group** leads to bad energy conservation. **Reaction-Field-zero** solves this by making the potential zero beyond the cut-off. It can only be used with an infinite dielectric constant (**epsilon-rf=0**), because only for that value the force vanishes at the cut-off. **rlist** should be 0.1 to 0.3 nm larger than **rcoulomb** to accommodate for the size of charge groups and diffusion between neighbor list updates. This, and the fact that table lookups are used instead of analytical functions make **Reaction-Field-zero** computationally more expensive than normal reaction-field.
+
+ + **Reaction-Field-nec**
+ The same as **Reaction-Field**, but implemented as in GROMACS versions before 3.3. No reaction-field correction is applied to excluded atom pairs and self pairs. The 1-4 interactions are calculated using a reaction-field. The missing correction due to the excluded pairs that do not have a 1-4 interaction is up to a few percent of the total electrostatic energy and causes a minor difference in the forces and the pressure.
+
+ + **Shift**
+ Analogous to **Shift** for **vdwtype**. You might want to use **Reaction-Field-zero** instead, which has a similar potential shape, but has a physical interpretation and has better energies due to the exclusion correction terms.
+
+ + **Encad-Shift**
+ The Coulomb potential is decreased over the whole range, using the definition from the Encad simulation package.
+
+ + **Switch**
+ Analogous to **Switch** for **vdwtype**. Switching the Coulomb potential can lead to serious artifacts, advice: use **Reaction-Field-zero** instead.
+
+ + **User**
+ [mdrun] will now expect to find a file `table.xvg` with user-defined potential functions for repulsion, dispersion and Coulomb. When pair interactions are present, [mdrun] also expects to find a file `tablep.xvg` for the pair interactions. When the same interactions should be used for non-bonded and pair interactions the user can specify the same file name for both table files. These files should contain 7 columns: the `x` value, `f(x)`, `-f'(x)`, `g(x)`, `-g'(x)`, `h(x)`, `-h'(x)`, where `f(x)` is the Coulomb function, `g(x)` the dispersion function and `h(x)` the repulsion function. When **vdwtype** is not set to **User** the values for `g`, `-g'`, `h` and `-h'` are ignored. For the non-bonded interactions `x` values should run from 0 to the largest cut-off distance + **table-extension** and should be uniformly spaced. For the pair interactions the table length in the file will be used. The optimal spacing, which is used for non-user tables, is `0.002 nm` when you run in mixed precision or `0.0005 nm` when you run in double precision. The function value at `x=0` is not important. More information is in the printed manual.
+
+ + **PME-Switch**
+ A combination of PME and a switch function for the direct-space part (see above). **rcoulomb** is allowed to be smaller than **rlist**. This is mainly useful constant energy simulations (note that using **PME** with **cutoff-scheme**=**Verlet** will be more efficient).
+
+ + **PME-User**
+ A combination of PME and user tables (see above). **rcoulomb** is allowed to be smaller than **rlist**. The PME mesh contribution is subtracted from the user table by [mdrun]. Because of this subtraction the user tables should contain about 10 decimal places.
+
+ + **PME-User-Switch**
+ A combination of PME-User and a switching function (see above). The switching function is applied to final particle-particle interaction, _i.e._ both to the user supplied function and the PME Mesh correction part.
+
+coulomb-modifier:
+: + **Potential-shift-Verlet**
+ Selects **Potential-shift** with the Verlet cutoff-scheme, as it is (nearly) free; selects **None** with the group cutoff-scheme.
+
+ + **Potential-shift**
+ Shift the Coulomb potential by a constant such that it is zero at the cut-off. This makes the potential the integral of the force. Note that this does not affect the forces or the sampling.
+
+ + **None**
+ Use an unmodified Coulomb potential. With the group scheme this means no exact cut-off is used, energies and forces are calculated for all pairs in the neighborlist.
+
+rcoulomb-switch: (0) [nm]
+: where to start switching the Coulomb potential, only relevant when force or potential switching is used
+
+rcoulomb: (1) [nm]
+: distance for the Coulomb cut-off
+
+epsilon-r: (1)
+: The relative dielectric constant. A value of 0 means infinity.
+
+epsilon-rf: (0)
+: The relative dielectric constant of the reaction field. This is only used with reaction-field electrostatics. A value of 0 means infinity.
+
+
+### VdW
+
+vdwtype:
+: + **Cut-off**
+ Twin range cut-offs with neighbor list cut-off **rlist** and VdW cut-off **rvdw**, where **rvdw** >= **rlist**.
+
+ + **PME**
+ Fast smooth Particle-mesh Ewald (SPME) for VdW interactions. The grid dimensions are controlled with **fourierspacing** in the same way as for electrostatics, and the interpolation order is controlled with **pme-order**. The relative accuracy of direct/reciprocal space is controlled by **ewald-rtol-lj**, and the specific combination rules that are to be used by the reciprocal routine are set using **lj-pme-comb-rule**.
+
+ + **Shift**
+ This functionality is deprecated and replaced by **vdw-modifier = Force-switch**. The LJ (not Buckingham) potential is decreased over the whole range and the forces decay smoothly to zero between **rvdw-switch** and **rvdw**. The neighbor search cut-off **rlist** should be 0.1 to 0.3 nm larger than **rvdw** to accommodate for the size of charge groups and diffusion between neighbor list updates.
+
+ + **Switch**
+ This functionality is deprecated and replaced by **vdw-modifier = Potential-switch**. The LJ (not Buckingham) potential is normal out to **rvdw-switch**, after which it is switched off to reach zero at **rvdw**. Both the potential and force functions are continuously smooth, but be aware that all switch functions will give rise to a bulge (increase) in the force (since we are switching the potential). The neighbor search cut-off **rlist** should be 0.1 to 0.3 nm larger than **rvdw** to accommodate for the size of charge groups and diffusion between neighbor list updates.
+
+ + **Encad-Shift**
+ The LJ (not Buckingham) potential is decreased over the whole range, using the definition from the Encad simulation package.
+
+ + **User**
+ See **user** for **coulombtype**. The function value at zero is not important. When you want to use LJ correction, make sure that **rvdw** corresponds to the cut-off in the user-defined function. When **coulombtype** is not set to **User** the values for `f` and `-f'` are ignored.
+
+vdw-modifier:
+: + **Potential-shift-Verlet**
+ Selects **Potential-shift** with the Verlet cutoff-scheme, as it is (nearly) free; selects **None** with the group cutoff-scheme.
+
+ + **Potential-shift**
+ Shift the Van der Waals potential by a constant such that it is zero at the cut-off. This makes the potential the integral of the force. Note that this does not affect the forces or the sampling.
+
+ + **None**
+ Use an unmodified Van der Waals potential. With the group scheme this means no exact cut-off is used, energies and forces are calculated for all pairs in the neighborlist.
+
+ + **Force-switch**
+ Smoothly switches the forces to zero between **rvdw-switch** and **rvdw**. This shifts the potential shift over the whole range and switches it to zero at the cut-off. Note that this is more expensive to calculate than a plain cut-off and it is not required for energy conservation, since **Potential-shift** conserves energy just as well.
+
+ + **Potential-switch**
+ Smoothly switches the potential to zero between **rvdw-switch** and **rvdw**. Note that this introduces articifically large forces in the switching region and is much more expensive to calculate. This option should only be used if the force field you are using requires this.
+
+rvdw-switch: (0) [nm]
+: where to start switching the LJ force and possibly the potential, only relevant when force or potential switching is used
+
+rvdw: (1) [nm]
+: distance for the LJ or Buckingham cut-off
+
+DispCorr:
+: + **no**
+ don't apply any correction
+
+ + **EnerPres**
+ apply long range dispersion corrections for Energy and Pressure
+
+ + **Ener**
+ apply long range dispersion corrections for Energy only
+
+
+### Tables
+
+table-extension: (1) [nm]
+: Extension of the non-bonded potential lookup tables beyond the largest cut-off distance. The value should be large enough to account for charge group sizes and the diffusion between neighbor-list updates. Without user defined potential the same table length is used for the lookup tables for the 1-4 interactions, which are always tabulated irrespective of the use of tables for the non-bonded interactions. The value of **table-extension** in no way affects the values of **rlist**, **rcoulomb**, or **rvdw**.
+
+energygrp-table:
+: When user tables are used for electrostatics and/or VdW, here one can give pairs of energy groups for which seperate user tables should be used. The two energy groups will be appended to the table file name, in order of their definition in **energygrps**, seperated by underscores. For example, if `energygrps = Na Cl Sol` and `energygrp-table = Na Na Na Cl`, [mdrun] will read `table_Na_Na.xvg` and `table_Na_Cl.xvg` in addition to the normal `table.xvg` which will be used for all other energy group pairs.
+
+
+### Ewald
+
+fourierspacing: (0.12) [nm]
+: For ordinary Ewald, the ratio of the box dimensions and the spacing determines a lower bound for the number of wave vectors to use in each (signed) direction. For PME and P3M, that ratio determines a lower bound for the number of Fourier-space grid points that will be used along that axis. In all cases, the number for each direction can be overridden by entering a non-zero value for **fourier_n[xyz]**. For optimizing the relative load of the particle-particle interactions and the mesh part of PME, it is useful to know that the accuracy of the electrostatics remains nearly constant when the Coulomb cut-off and the PME grid spacing are scaled by the same factor.
+
+fourier-nx (0) ; fourier-ny (0) ; fourier-nz: (0)
+: Highest magnitude of wave vectors in reciprocal space when using Ewald.
+ Grid size when using PME or P3M. These values override **fourierspacing** per direction. The best choice is powers of 2, 3, 5 and 7. Avoid large primes.
+
+pme-order (4)
+: Interpolation order for PME. 4 equals cubic interpolation. You might try 6/8/10 when running in parallel and simultaneously decrease grid dimension.
+
+ewald-rtol (1e-5)
+: The relative strength of the Ewald-shifted direct potential at **rcoulomb** is given by **ewald-rtol**. Decreasing this will give a more accurate direct sum, but then you need more wave vectors for the reciprocal sum.
+
+ewald-rtol-lj (1e-3)
+: When doing PME for VdW-interactions, **ewald-rtol-lj** is used to control the relative strength of the dispersion potential at **rvdw** in the same way as **ewald-rtol** controls the electrostatic potential.
+
+lj-pme-comb-rule (Geometric)
+: The combination rules used to combine VdW-parameters in the reciprocal part of LJ-PME. Geometric rules are much faster than Lorentz-Berthelot and usually the recommended choice, even when the rest of the force field uses the Lorentz-Berthelot rules.
+
+ + **Geometric**
+ Apply geometric combination rules
+
+ + **Lorentz-Berthelot**
+ Apply Lorentz-Berthelot combination rules
+
+ewald-geometry: (3d)
+: + **3d**
+ The Ewald sum is performed in all three dimensions.
+
+ + **3dc**
+ The reciprocal sum is still performed in 3D, but a force and potential correction applied in the `z` dimension to produce a pseudo-2D summation. If your system has a slab geometry in the `x-y` plane you can try to increase the `z`-dimension of the box (a box height of 3 times the slab height is usually ok) and use this option.
+
+epsilon-surface: (0)
+: This controls the dipole correction to the Ewald summation in 3D. The default value of zero means it is turned off. Turn it on by setting it to the value of the relative permittivity of the imaginary surface around your infinite system. Be careful - you shouldn't use this if you have free mobile charges in your system. This value does not affect the slab 3DC variant of the long range corrections.
+
+
+### Temperature coupling
+
+tcoupl:
+: + **no**
+ No temperature coupling.
+
+ + **berendsen**
+ Temperature coupling with a Berendsen-thermostat to a bath with temperature **ref-t**, with time constant **tau-t**. Several groups can be coupled separately, these are specified in the **tc-grps** field separated by spaces.
+
+ + **nose-hoover**
+ Temperature coupling using a Nose-Hoover extended ensemble. The reference temperature and coupling groups are selected as above, but in this case **tau-t** controls the period of the temperature fluctuations at equilibrium, which is slightly different from a relaxation time. For NVT simulations the conserved energy quantity is written to energy and log file.
+
+ + **andersen**
+ Temperature coupling by randomizing a fraction of the particles at each timestep. Reference temperature and coupling groups are selected as above. **tau-t** is the average time between randomization of each molecule. Inhibits particle dynamics somewhat, but little or no ergodicity issues. Currently only implemented with velocity Verlet, and not implemented with constraints.
+
+ + **andersen-massive**
+ Temperature coupling by randomizing all particles at infrequent timesteps. Reference temperature and coupling groups are selected as above. **tau-t** is the time between randomization of all molecules. Inhibits particle dynamics somewhat, but little or no ergodicity issues. Currently only implemented with velocity Verlet.
+
+ + **v-rescale**
+ Temperature coupling using velocity rescaling with a stochastic term (JCP 126, 014101). This thermostat is similar to Berendsen coupling, with the same scaling using **tau-t**, but the stochastic term ensures that a proper canonical ensemble is generated. The random seed is set with **ld-seed**. This thermostat works correctly even for **tau-t**=0. For NVT simulations the conserved energy quantity is written to the energy and log file.
+
+nsttcouple: (-1)
+: The frequency for coupling the temperature. The default value of -1 sets **nsttcouple** equal to **nstlist**, unless **nstlist**<=0, then a value of 10 is used. For velocity Verlet integrators **nsttcouple** is set to 1.
+
+nh-chain-length (10)
+: the number of chained Nose-Hoover thermostats for velocity Verlet integrators, the leap-frog **md** integrator only supports 1. Data for the NH chain variables is not printed to the .edr, but can be using the `GMX_NOSEHOOVER_CHAINS` environment variable
+
+tc-grps:
+: groups to couple to separate temperature baths
+
+tau-t: [ps]
+: time constant for coupling (one for each group in **tc-grps**), -1 means no temperature coupling
+
+ref-t: [K]
+: reference temperature for coupling (one for each group in **tc-grps**)
+
+
+### Pressure coupling
+
+pcoupl:
+: + **no**
+ No pressure coupling. This means a fixed box size.
+
+ + **berendsen**
+ Exponential relaxation pressure coupling with time constant **tau-p**. The box is scaled every timestep. It has been argued that this does not yield a correct thermodynamic ensemble, but it is the most efficient way to scale a box at the beginning of a run.
+
+ + **Parrinello-Rahman**
+ Extended-ensemble pressure coupling where the box vectors are subject to an equation of motion. The equation of motion for the atoms is coupled to this. No instantaneous scaling takes place. As for Nose-Hoover temperature coupling the time constant **tau-p** is the period of pressure fluctuations at equilibrium. This is probably a better method when you want to apply pressure scaling during data collection, but beware that you can get very large oscillations if you are starting from a different pressure. For simulations where the exact fluctation of the NPT ensemble are important, or if the pressure coupling time is very short it may not be appropriate, as the previous time step pressure is used in some steps of the GROMACS implementation for the current time step pressure.
+
+ + **MTTK**
+ Martyna-Tuckerman-Tobias-Klein implementation, only useable with **md-vv** or **md-vv-avek**, very similar to Parrinello-Rahman. As for Nose-Hoover temperature coupling the time constant **tau-p** is the period of pressure fluctuations at equilibrium. This is probably a better method when you want to apply pressure scaling during data collection, but beware that you can get very large oscillations if you are starting from a different pressure. Currently (as of version 5.1), it only supports isotropic scaling, and only works without constraints.
+
+pcoupltype:
+: + **isotropic**
+ Isotropic pressure coupling with time constant **tau-p**. The compressibility and reference pressure are set with **compressibility** and **ref-p**, one value is needed.
+
+ + **semiisotropic**
+ Pressure coupling which is isotropic in the `x` and `y` direction, but different in the `z` direction. This can be useful for membrane simulations. 2 values are needed for `x/y` and `z` directions respectively.
+
+ + **anisotropic**
+ Idem, but 6 values are needed for `xx`, `yy`, `zz`, `xy/yx`, `xz/zx` and `yz/zy` components, respectively. When the off-diagonal compressibilities are set to zero, a rectangular box will stay rectangular. Beware that anisotropic scaling can lead to extreme deformation of the simulation box.
+
+ + **surface-tension**
+ Surface tension coupling for surfaces parallel to the xy-plane. Uses normal pressure coupling for the `z`-direction, while the surface tension is coupled to the `x/y` dimensions of the box. The first **ref-p** value is the reference surface tension times the number of surfaces [bar nm], the second value is the reference `z`-pressure [bar]. The two **compressibility** values are the compressibility in the `x/y` and `z` direction respectively. The value for the `z`-compressibility should be reasonably accurate since it influences the convergence of the surface-tension, it can also be set to zero to have a box with constant height.
+
+nstpcouple: (-1)
+: The frequency for coupling the pressure. The default value of -1 sets **nstpcouple** equal to **nstlist**, unless **nstlist** <=0, then a value of 10 is used. For velocity Verlet integrators **nstpcouple** is set to 1.
+
+tau-p: (1) [ps]
+: time constant for coupling
+
+compressibility: [bar-1]
+: compressibility (NOTE: this is now really in bar-1) For water at 1 atm and 300 K the compressibility is 4.5e-5 [bar-1].
+
+ref-p: [bar]
+: reference pressure for coupling
+
+refcoord-scaling:
+: + **no**
+ The reference coordinates for position restraints are not modified. Note that with this option the virial and pressure will depend on the absolute positions of the reference coordinates.
+
+ + **all**
+ The reference coordinates are scaled with the scaling matrix of the pressure coupling.
+
+ + **com**
+ Scale the center of mass of the reference coordinates with the scaling matrix of the pressure coupling. The vectors of each reference coordinate to the center of mass are not scaled. Only one COM is used, even when there are multiple molecules with position restraints. For calculating the COM of the reference coordinates in the starting configuration, periodic boundary conditions are not taken into account.
+
+
+### Simulated annealing
+
+Simulated annealing is controlled separately for each temperature group in GROMACS. The reference temperature is a piecewise linear function, but you can use an arbitrary number of points for each group, and choose either a single sequence or a periodic behaviour for each group. The actual annealing is performed by dynamically changing the reference temperature used in the thermostat algorithm selected, so remember that the system will usually not instantaneously reach the reference temperature!
+
+annealing:
+: Type of annealing for each temperature group
+
+ + **no**
+ No simulated annealing - just couple to reference temperature value.
+
+ + **single**
+ A single sequence of annealing points. If your simulation is longer than the time of the last point, the temperature will be coupled to this constant value after the annealing sequence has reached the last time point.
+
+ + **periodic**
+ The annealing will start over at the first reference point once the last reference time is reached. This is repeated until the simulation ends.
+
+annealing-npoints:
+: A list with the number of annealing reference/control points used for each temperature group. Use 0 for groups that are not annealed. The number of entries should equal the number of temperature groups.
+
+annealing-time:
+: List of times at the annealing reference/control points for each group. If you are using periodic annealing, the times will be used modulo the last value, _i.e._ if the values are 0, 5, 10, and 15, the coupling will restart at the 0ps value after 15ps, 30ps, 45ps, etc. The number of entries should equal the sum of the numbers given in **annealing-npoints**.
+
+annealing-temp:
+: List of temperatures at the annealing reference/control points for each group. The number of entries should equal the sum of the numbers given in **annealing-npoints**.
+
+ Confused? OK, let's use an example. Assume you have two temperature groups, set the group selections to `annealing = single periodic`, the number of points of each group to `annealing-npoints = 3 4`, the times to `annealing-time = 0 3 6 0 2 4 6` and finally temperatures to `annealing-temp = 298 280 270 298 320 320 298`. The first group will be coupled to 298K at 0ps, but the reference temperature will drop linearly to reach 280K at 3ps, and then linearly between 280K and 270K from 3ps to 6ps. After this is stays constant, at 270K. The second group is coupled to 298K at 0ps, it increases linearly to 320K at 2ps, where it stays constant until 4ps. Between 4ps and 6ps it decreases to 298K, and then it starts over with the same pattern again, _i.e._ rising linearly from 298K to 320K between 6ps and 8ps. Check the summary printed by [gmx grompp] if you are unsure!
+
+
+### Velocity generation
+
+gen-vel:
+: + **no**
+ Do not generate velocities. The velocities are set to zero when there are no velocities in the input structure file.
+
+ + **yes**
+ Generate velocities in [gmx grompp] according to a Maxwell distribution at temperature **gen-temp**, with random seed **gen-seed**. This is only meaningful with integrator **md**.
+
+gen-temp: (300) [K]
+: temperature for Maxwell distribution
+
+gen-seed: (-1) [integer]
+: used to initialize random generator for random velocities, when **gen-seed** is set to -1, a pseudo random seed is used.
+
+
+### Bonds
+
+constraints:
+: + **none**
+ No constraints except for those defined explicitly in the topology, _i.e._ bonds are represented by a harmonic (or other) potential or a Morse potential (depending on the setting of **morse**) and angles by a harmonic (or other) potential. **h-bonds**
+ Convert the bonds with H-atoms to constraints.
+
+ + **all-bonds**
+ Convert all bonds to constraints.
+
+ + **h-angles**
+ Convert all bonds and additionally the angles that involve H-atoms to bond-constraints.
+
+ + **all-angles**
+ Convert all bonds and angles to bond-constraints.
+
+constraint-algorithm:
+: + **LINCS**
+ LINear Constraint Solver. With domain decomposition the parallel version P-LINCS is used. The accuracy in set with **lincs-order**, which sets the number of matrices in the expansion for the matrix inversion. After the matrix inversion correction the algorithm does an iterative correction to compensate for lengthening due to rotation. The number of such iterations can be controlled with **lincs-iter**. The root mean square relative constraint deviation is printed to the log file every **nstlog** steps. If a bond rotates more than **lincs-warnangle** in one step, a warning will be printed both to the log file and to `stderr`. LINCS should not be used with coupled angle constraints.
+
+ + **SHAKE**
+ SHAKE is slightly slower and less stable than LINCS, but does work with angle constraints. The relative tolerance is set with **shake-tol**, 0.0001 is a good value for "normal" MD. SHAKE does not support constraints between atoms on different nodes, thus it can not be used with domain decompositon when inter charge-group constraints are present. SHAKE can not be used with energy minimization.
+
+continuation:
+: This option was formerly known as **unconstrained-start**.
+
+ + **no**
+ apply constraints to the start configuration and reset shells
+
+ + **yes**
+ do not apply constraints to the start configuration and do not reset shells, useful for exact coninuation and reruns
+
+shake-tol: (0.0001)
+: relative tolerance for SHAKE
+
+lincs-order: (4)
+: Highest order in the expansion of the constraint coupling matrix. When constraints form triangles, an additional expansion of the same order is applied on top of the normal expansion only for the couplings within such triangles. For "normal" MD simulations an order of 4 usually suffices, 6 is needed for large time-steps with virtual sites or BD. For accurate energy minimization an order of 8 or more might be required. With domain decomposition, the cell size is limited by the distance spanned by **lincs-order**+1 constraints. When one wants to scale further than this limit, one can decrease **lincs-order** and increase **lincs-iter**, since the accuracy does not deteriorate when (1+**lincs-iter**)***lincs-order** remains constant.
+
+lincs-iter: (1)
+: Number of iterations to correct for rotational lengthening in LINCS. For normal runs a single step is sufficient, but for NVE runs where you want to conserve energy accurately or for accurate energy minimization you might want to increase it to 2.
+
+lincs-warnangle: (30) [degrees]
+: maximum angle that a bond can rotate before LINCS will complain
+
+morse:
+: + **no**
+ bonds are represented by a harmonic potential
+
+ + **yes**
+ bonds are represented by a Morse potential
+
+
+### Energy group exclusions
+
+energygrp-excl:
+: Pairs of energy groups for which all non-bonded interactions are excluded. An example: if you have two energy groups `Protein` and `SOL`, specifying `energygrp-excl = Protein Protein SOL SOL` would give only the non-bonded interactions between the protein and the solvent. This is especially useful for speeding up energy calculations with `mdrun -rerun` and for excluding interactions within frozen groups.
+
+
+### Walls
+
+nwall: 0
+: When set to **1** there is a wall at `z=0`, when set to **2** there is also a wall at `z=z-box`. Walls can only be used with **pbc=xy**. When set to **2** pressure coupling and Ewald summation can be used (it is usually best to use semiisotropic pressure coupling with the `x/y` compressibility set to 0, as otherwise the surface area will change). Walls interact wit the rest of the system through an optional **wall-atomtype**. Energy groups `wall0` and `wall1` (for **nwall=2**) are added automatically to monitor the interaction of energy groups with each wall. The center of mass motion removal will be turned off in the `z`-direction.
+
+wall-atomtype:
+: the atom type name in the force field for each wall. By (for example) defining a special wall atom type in the topology with its own combination rules, this allows for independent tuning of the interaction of each atomtype with the walls.
+
+wall-type:
+: + **9-3**
+ LJ integrated over the volume behind the wall: 9-3 potential
+
+ + **10-4**
+ LJ integrated over the wall surface: 10-4 potential
+
+ + **12-6**
+ direct LJ potential with the `z` distance from the wall
+
+ + **table**
+ user defined potentials indexed with the `z` distance from the wall, the tables are read analogously to the **energygrp-table** option, where the first name is for a "normal" energy group and the second name is `wall0` or `wall1`, only the dispersion and repulsion columns are used
+
+wall-r-linpot: -1 (nm)
+: Below this distance from the wall the potential is continued linearly and thus the force is constant. Setting this option to a postive value is especially useful for equilibration when some atoms are beyond a wall. When the value is <=0 (<0 for **wall-type=table**), a fatal error is generated when atoms are beyond a wall.
+
+wall-density: [nm-3/nm-2]
+: the number density of the atoms for each wall for wall types **9-3** and **10-4**
+
+wall-ewald-zfac: 3
+: The scaling factor for the third box vector for Ewald summation only, the minimum is 2. Ewald summation can only be used with **nwall=2**, where one should use **ewald-geometry`=3dc`**. The empty layer in the box serves to decrease the unphysical Coulomb interaction between periodic images.
+
+
+### COM pulling
+
+pull:
+: + **no**
+ No center of mass pulling. All the following pull options will be ignored (and if present in the [.mdp] file, they unfortunately generate warnings)
+
+ + **umbrella**
+ Center of mass pulling using an umbrella potential between the reference group and one or more groups.
+
+ + **constraint**
+ Center of mass pulling using a constraint between the reference group and one or more groups. The setup is identical to the option **umbrella**, except for the fact that a rigid constraint is applied instead of a harmonic potential.
+
+ + **constant-force**
+ Center of mass pulling using a linear potential and therefore a constant force. For this option there is no reference position and therefore the parameters **pull-init** and **pull-rate** are not used.
+
+pull-geometry:
+: + **distance**
+ Pull along the vector connecting the two groups. Components can be selected with **pull-dim**.
+
+ + **direction**
+ Pull in the direction of **pull-vec**.
+
+ + **direction-periodic**
+ As **direction**, but allows the distance to be larger than half the box size. With this geometry the box should not be dynamic (_e.g._ no pressure scaling) in the pull dimensions and the pull force is not added to virial.
+
+ + **cylinder**
+ Designed for pulling with respect to a layer where the reference COM is given by a local cylindrical part of the reference group. The pulling is in the direction of **pull-vec**. From the reference group a cylinder is selected around the axis going through the pull group with direction **pull-vec** using two radii. The radius **pull-r1** gives the radius within which all the relative weights are one, between **pull-r1** and **pull-r0** the weights are switched to zero. Mass weighting is also used. Note that the radii should be smaller than half the box size. For tilted cylinders they should be even smaller than half the box size since the distance of an atom in the reference group from the COM of the pull group has both a radial and an axial component.
+
+pull-dim: (Y Y Y)
+: the distance components to be used with geometry **distance**, and also sets which components are printed to the output files
+
+pull-r1: (1) [nm]
+: the inner radius of the cylinder for geometry **cylinder**
+
+pull-r0: (1) [nm]
+: the outer radius of the cylinder for geometry **cylinder**
+
+pull-constr-tol: (1e-6)
+: the relative constraint tolerance for constraint pulling
+
+pull-start:
+: + **no**
+ do not modify **pull-init**
+
+ + **yes**
+ add the COM distance of the starting conformation to **pull-init**
+
+pull-print-reference: (10)
+: + **no**
+ do not print the COM of the first group in each pull coordinate
+
+ + **yes**
+ print the COM of the first group in each pull coordinate
+
+pull-nstxout: (10)
+: frequency for writing out the COMs of all the pull group
+
+pull-nstfout: (1)
+: frequency for writing out the force of all the pulled group
+
+pull-ngroups: (1)
+: The number of pull groups, not including the absolute reference group, when used. Pull groups can be reused in multiple pull coordinates. Below only the pull options for group 1 are given, further groups simply increase the group index number.
+
+pull-ncoords: (1)
+: The number of pull coordinates. Below only the pull options for coordinate 1 are given, further coordinates simply increase the coordinate index number.
+
+pull-group1-name:
+: The name of the pull group, is looked up in the index file or in the default groups to obtain the atoms involved.
+
+pull-group1-weights:
+: Optional relative weights which are multiplied with the masses of the atoms to give the total weight for the COM. The number should be 0, meaning all 1, or the number of atoms in the pull group.
+
+pull-group1-pbcatom: (0)
+: The reference atom for the treatment of periodic boundary conditions inside the group (this has no effect on the treatment of the pbc between groups). This option is only important when the diameter of the pull group is larger than half the shortest box vector. For determining the COM, all atoms in the group are put at their periodic image which is closest to **pull-group1-pbcatom**. A value of 0 means that the middle atom (number wise) is used. This parameter is not used with geometry **cylinder**. A value of -1 turns on cosine weighting, which is useful for a group of molecules in a periodic system, _e.g._ a water slab (see Engin et al. J. Chem. Phys. B 2010).
+
+pull-coord1-groups:
+: The two groups indices should be given on which this pull coordinate will operate. The first index can be 0, in which case an absolute reference of **pull-coord1-origin** is used. With an absolute reference the system is no longer translation invariant and one should think about what to do with the center of mass motion.
+
+pull-coord1-origin: (0.0 0.0 0.0)
+: The pull reference position for use with an absolute reference.
+
+pull-coord1-vec: (0.0 0.0 0.0)
+: The pull direction. [gmx grompp] normalizes the vector.
+
+pull-coord1-init: (0.0) [nm]
+: The reference distance at t=0.
+
+pull-coord1-rate: (0) [nm/ps]
+: The rate of change of the reference position.
+
+pull-coord1-k: (0) [kJ mol-1 nm-2] / [kJ mol-1 nm-1]
+: The force constant. For umbrella pulling this is the harmonic force constant in [kJ mol-1 nm-2]. For constant force pulling this is the force constant of the linear potential, and thus the negative (!) of the constant force in [kJ mol-1 nm-1].
+
+pull-coord1-kB: (pull-k1) [kJ mol-1 nm-2] / [kJ mol-1 nm-1]
+: As **pull-coord1-k**, but for state B. This is only used when **free-energy** is turned on. The force constant is then (1 - lambda) * **pull-coord1-k** + lambda * **pull-coord1-kB**.
+
+
+### NMR refinement
+
+disre:
+: + **no**
+ ignore distance restraint information in topology file
+
+ + **simple**
+ simple (per-molecule) distance restraints.
+
+ + **ensemble**
+ distance restraints over an ensemble of molecules in one simulation box. Normally, one would perform ensemble averaging over multiple subsystems, each in a separate box, using `mdrun -multi`. Supply `topol0.tpr`, `topol1.tpr`, ... with different coordinates and/or velocities. The environment variable `GMX_DISRE_ENSEMBLE_SIZE` sets the number of systems within each ensemble (usually equal to the `mdrun -multi` value).
+
+disre-weighting:
+: + **equal** (default)
+ divide the restraint force equally over all atom pairs in the restraint
+
+ + **conservative**
+ the forces are the derivative of the restraint potential, this results in an weighting of the atom pairs to the reciprocal seventh power of the displacement. The forces are conservative when **disre-tau** is zero.
+
+disre-mixed:
+: + **no**
+ the violation used in the calculation of the restraint force is the time-averaged violation
+
+ + **yes**
+ the violation used in the calculation of the restraint force is the square root of the product of the time-averaged violation and the instantaneous violation
+
+disre-fc: (1000) [kJ mol-1 nm-2]
+: force constant for distance restraints, which is multiplied by a (possibly) different factor for each restraint given in the `fac` column of the interaction in the topology file.
+
+disre-tau: (0) [ps]
+: time constant for distance restraints running average. A value of zero turns off time averaging.
+
+nstdisreout: (100) [steps]
+: period between steps when the running time-averaged and instantaneous distances of all atom pairs involved in restraints are written to the energy file (can make the energy file very large)
+
+orire:
+: + **no**
+ ignore orientation restraint information in topology file
+
+ + **yes**
+ use orientation restraints, ensemble averaging can be performed with `mdrun -multi`
+
+orire-fc: (0) [kJ mol]
+: force constant for orientation restraints, which is multiplied by a (possibly) different weight factor for each restraint, can be set to zero to obtain the orientations from a free simulation
+
+orire-tau: (0) [ps]
+: time constant for orientation restraints running average. A value of zero turns off time averaging.
+
+orire-fitgrp:
+: fit group for orientation restraining. This group of atoms is used to determine the rotation **R** of the system with respect to the reference orientation. The reference orientation is the starting conformation of the first subsystem. For a protein, backbone is a reasonable choice
+
+nstorireout: (100) [steps]
+: period between steps when the running time-averaged and instantaneous orientations for all restraints, and the molecular order tensor are written to the energy file (can make the energy file very large)
+
+
+### Free energy calculations
+
+free-energy:
+: + **no**
+ Only use topology A.
+
+ + **yes**
+ Interpolate between topology A (lambda=0) to topology B (lambda=1) and write the derivative of the Hamiltonian with respect to lambda (as specified with **dhdl-derivatives**), or the Hamiltonian differences with respect to other lambda values (as specified with **foreign-lambda**) to the energy file and/or to `dhdl.xvg`, where they can be processed by, for example [gmx bar]. The potentials, bond-lengths and angles are interpolated linearly as described in the manual. When **sc-alpha** is larger than zero, soft-core potentials are used for the LJ and Coulomb interactions.
+
+ + **expanded**
+ Turns on expanded ensemble simulation, where the alchemical state becomes a dynamic variable, allowing jumping between different Hamiltonians. See the expanded ensemble options for controlling how expanded ensemble simulations are performed. The different Hamiltonians used in expanded ensemble simulations are defined by the other free energy options.
+
+init-lambda: (-1)
+: starting value for lambda (float). Generally, this should only be used with slow growth (_i.e._ nonzero **delta-lambda**). In other cases, **init-lambda-state** should be specified instead. Must be greater than or equal to 0.
+
+delta-lambda: (0)
+: increment per time step for lambda
+
+init-lambda-state: (-1)
+: starting value for the lambda state (integer). Specifies which columm of the lambda vector (**coul-lambdas**, **vdw-lambdas**, **bonded-lambdas**, **restraint-lambdas**, **mass-lambdas**, **temperature-lambdas**, **fep-lambdas**) should be used. This is a zero-based index: **init-lambda-state** 0 means the first column, and so on.
+
+fep-lambdas: ()
+: Zero, one or more lambda values for which Delta H values will be determined and written to dhdl.xvg every **nstdhdl** steps. Values must be between 0 and 1. Free energy differences between different lambda values can then be determined with [gmx bar]. **fep-lambdas** is different from the other `-lambdas` keywords because all components of the lambda vector that are not specified will use **fep-lambdas** (including restraint-lambdas and therefore the pull code restraints).
+
+coul-lambdas: ()
+: Zero, one or more lambda values for which Delta H values will be determined and written to dhdl.xvg every **nstdhdl** steps. Values must be between 0 and 1. Only the electrostatic interactions are controlled with this component of the lambda vector (and only if the lambda=0 and lambda=1 states have differing electrostatic interactions).
+
+vdw-lambdas: ()
+: Zero, one or more lambda values for which Delta H values will be determined and written to dhdl.xvg every **nstdhdl** steps. Values must be between 0 and 1. Only the van der Waals interactions are controlled with this component of the lambda vector.
+
+bonded-lambdas: ()
+: Zero, one or more lambda values for which Delta H values will be determined and written to dhdl.xvg every **nstdhdl** steps. Values must be between 0 and 1. Only the bonded interactions are controlled with this component of the lambda vector.
+
+restraint-lambdas: ()
+: Zero, one or more lambda values for which Delta H values will be determined and written to dhdl.xvg every **nstdhdl** steps. Values must be between 0 and 1. Only the restraint interactions: dihedral restraints, and the pull code restraints are controlled with this component of the lambda vector.
+
+mass-lambdas: ()
+: Zero, one or more lambda values for which Delta H values will be determined and written to dhdl.xvg every **nstdhdl** steps. Values must be between 0 and 1. Only the particle masses are controlled with this component of the lambda vector.
+
+temperature-lambdas: ()
+: Zero, one or more lambda values for which Delta H values will be determined and written to dhdl.xvg every **nstdhdl** steps. Values must be between 0 and 1. Only the temperatures controlled with this component of the lambda vector. Note that these lambdas should not be used for replica exchange, only for simulated tempering.
+
+calc-lambda-neighbors (1)
+: Controls the number of lambda values for which Delta H values will be calculated and written out, if **init-lambda-state** has been set. A positive value will limit the number of lambda points calculated to only the nth neighbors of **init-lambda-state**: for example, if **init-lambda-state** is 5 and this parameter has a value of 2, energies for lambda points 3-7 will be calculated and writen out. A value of -1 means all lambda points will be written out. For normal BAR such as with [gmx bar], a value of 1 is sufficient, while for MBAR -1 should be used.
+
+sc-alpha: (0)
+: the soft-core alpha parameter, a value of 0 results in linear interpolation of the LJ and Coulomb interactions
+
+sc-r-power: (6)
+: the power of the radial term in the soft-core equation. Possible values are 6 and 48. 6 is more standard, and is the default. When 48 is used, then sc-alpha should generally be much lower (between 0.001 and 0.003).
+
+sc-coul: (no)
+: Whether to apply the soft core free energy interaction transformation to the Columbic interaction of a molecule. Default is no, as it is generally more efficient to turn off the Coulomic interactions linearly before turning off the van der Waals interactions.
+
+sc-power: (0)
+: the power for lambda in the soft-core function, only the values 1 and 2 are supported
+
+sc-sigma: (0.3) [nm]
+: the soft-core sigma for particles which have a C6 or C12 parameter equal to zero or a sigma smaller than **sc-sigma**
+
+couple-moltype:
+: Here one can supply a molecule type (as defined in the topology) for calculating solvation or coupling free energies. There is a special option **system** that couples all molecule types in the system. This can be useful for equilibrating a system starting from (nearly) random coordinates. **free-energy** has to be turned on. The Van der Waals interactions and/or charges in this molecule type can be turned on or off between lambda=0 and lambda=1, depending on the settings of **couple-lambda0** and **couple-lambda1**. If you want to decouple one of several copies of a molecule, you need to copy and rename the molecule definition in the topology.
+
+couple-lambda0:
+: + **vdw-q**
+ all interactions are on at lambda=0
+
+ + **vdw**
+ the charges are zero (no Coulomb interactions) at lambda=0
+
+ + **q**
+ the Van der Waals interactions are turned at lambda=0; soft-core interactions will be required to avoid singularities
+
+ + **none**
+ the Van der Waals interactions are turned off and the charges are zero at lambda=0; soft-core interactions will be required to avoid singularities.
+
+couple-lambda1:
+: analogous to **couple-lambda1**, but for lambda=1
+
+couple-intramol:
+: + **no**
+ All intra-molecular non-bonded interactions for moleculetype **couple-moltype** are replaced by exclusions and explicit pair interactions. In this manner the decoupled state of the molecule corresponds to the proper vacuum state without periodicity effects.
+
+ + **yes**
+ The intra-molecular Van der Waals and Coulomb interactions are also turned on/off. This can be useful for partitioning free-energies of relatively large molecules, where the intra-molecular non-bonded interactions might lead to kinetically trapped vacuum conformations. The 1-4 pair interactions are not turned off.
+
+* **nstdhdl: (100)**
+ the frequency for writing dH/dlambda and possibly Delta H to dhdl.xvg, 0 means no ouput, should be a multiple of **nstcalcenergy**.
+
+dhdl-derivatives: (yes)
+: If yes (the default), the derivatives of the Hamiltonian with respect to lambda at each **nstdhdl** step are written out. These values are needed for interpolation of linear energy differences with [gmx bar] (although the same can also be achieved with the right **foreign lambda** setting, that may not be as flexible), or with thermodynamic integration
+
+dhdl-print-energy: (no)
+: Include either the total or the potential energy in the dhdl file. Options are 'no', 'potential', or 'total'. This information is needed for later free energy analysis if the states of interest are at different temperatures. If all states are at the same temperature, this information is not needed. 'potential' is useful in case one is using `mdrun -rerun` to generate the `dhdl.xvg` file. When rerunning from an existing trajectory, the kinetic energy will often not be correct, and thus one must compute the residual free energy from the potential alone, with the kinetic energy component computed analytically.
+
+separate-dhdl-file: (yes)
+: + **yes**
+ the free energy values that are calculated (as specified with the **foreign-lambda** and **dhdl-derivatives** settings) are written out to a separate file, with the default name `dhdl.xvg`. This file can be used directly with [gmx bar].
+
+ + **no**
+ The free energy values are written out to the energy output file (`ener.edr`, in accumulated blocks at every **nstenergy** steps), where they can be extracted with [gmx energy] or used directly with [gmx bar].
+
+dh-hist-size: (0)
+: If nonzero, specifies the size of the histogram into which the Delta H values (specified with **foreign-lambda**) and the derivative dH/dl values are binned, and written to ener.edr. This can be used to save disk space while calculating free energy differences. One histogram gets written for each **foreign lambda** and two for the dH/dl, at every **nstenergy** step. Be aware that incorrect histogram settings (too small size or too wide bins) can introduce errors. Do not use histograms unless you're certain you need it.
+
+dh-hist-spacing (0.1)
+: Specifies the bin width of the histograms, in energy units. Used in conjunction with **dh-hist-size**. This size limits the accuracy with which free energies can be calculated. Do not use histograms unless you're certain you need it.
+
+
+### Expanded Ensemble calculations
+
+nstexpanded
+: The number of integration steps beween attempted moves changing the system Hamiltonian in expanded ensemble simulations. Must be a multiple of **nstcalcenergy**, but can be greater or less than **nstdhdl**.
+lmc-stats:
+: + **no**
+ No Monte Carlo in state space is performed.
+
+ + **metropolis-transition**
+ Uses the Metropolis weights to update the expanded ensemble weight of each state. Min{1,exp(-(beta_new u_new - beta_old u_old)}
+
+ + **barker-transition**
+ Uses the Barker transition critera to update the expanded ensemble weight of each state i, defined by exp(-beta_new u_new)/[exp(-beta_new u_new)+exp(-beta_old u_old)
+
+ + **wang-landau**
+ Uses the Wang-Landau algorithm (in state space, not energy space) to update the expanded ensemble weights.
+
+ + **min-variance**
+ Uses the minimum variance updating method of Escobedo et al. to update the expanded ensemble weights. Weights will not be the free energies, but will rather emphasize states that need more sampling to give even uncertainty.
+
+lmc-mc-move:
+: + **no**
+ No Monte Carlo in state space is performed.
+
+ + **metropolis-transition**
+ Randomly chooses a new state up or down, then uses the Metropolis critera to decide whether to accept or reject: Min{1,exp(-(beta_new u_new - beta_old u_old)}
+
+ + **barker-transition**
+ Randomly chooses a new state up or down, then uses the Barker transition critera to decide whether to accept or reject: exp(-beta_new u_new)/[exp(-beta_new u_new)+exp(-beta_old u_old)]
+
+ + **gibbs**
+ Uses the conditional weights of the state given the coordinate (exp(-beta_i u_i) / sum_k exp(beta_i u_i) to decide which state to move to.
+
+ + **metropolized-gibbs**
+ Uses the conditional weights of the state given the coordinate (exp(-beta_i u_i) / sum_k exp(beta_i u_i) to decide which state to move to, EXCLUDING the current state, then uses a rejection step to ensure detailed balance. Always more efficient that Gibbs, though only marginally so in many situations, such as when only the nearest neighbors have decent phase space overlap.
+
+lmc-seed: (-1)
+: random seed to use for Monte Carlo moves in state space. When **lmc-seed** is set to -1, a pseudo random seed is us
+
+mc-temperature:
+: Temperature used for acceptance/rejection for Monte Carlo moves. If not specified, the temperature of the simulation specified in the first group of **ref_t** is used.
+
+wl-ratio: (0.8)
+: The cutoff for the histogram of state occupancies to be reset, and the free energy incrementor to be changed from delta to delta * **wl-scale**. If we define the Nratio = (number of samples at each histogram) / (average number of samples at each histogram). **wl-ratio** of 0.8 means that means that the histogram is only considered flat if all Nratio > 0.8 AND simultaneously all 1/Nratio > 0.8.
+
+wl-scale: (0.8)
+: Each time the histogram is considered flat, then the current value of the Wang-Landau incrementor for the free energies is multiplied by **wl-scale**. Value must be between 0 and 1.
+
+init-wl-delta: (1.0)
+: The initial value of the Wang-Landau incrementor in kT. Some value near 1 kT is usually most efficient, though sometimes a value of 2-3 in units of kT works better if the free energy differences are large.
+
+wl-oneovert: (no)
+: Set Wang-Landau incrementor to scale with 1/(simulation time) in the large sample limit. There is significant evidence that the standard Wang-Landau algorithms in state space presented here result in free energies getting 'burned in' to incorrect values that depend on the initial state. when **wl-oneovert** is true, then when the incrementor becomes less than 1/N, where N is the mumber of samples collected (and thus proportional to the data collection time, hence '1 over t'), then the Wang-Lambda incrementor is set to 1/N, decreasing every step. Once this occurs, **wl-ratio** is ignored, but the weights will still stop updating when the equilibration criteria set in **lmc-weights-equil** is achieved.
+
+lmc-repeats: (1)
+: Controls the number of times that each Monte Carlo swap type is performed each iteration. In the limit of large numbers of Monte Carlo repeats, then all methods converge to Gibbs sampling. The value will generally not need to be different from 1.
+
+lmc-gibbsdelta: (-1)
+: Limit Gibbs sampling to selected numbers of neighboring states. For Gibbs sampling, it is sometimes inefficient to perform Gibbs sampling over all of the states that are defined. A positive value of **lmc-gibbsdelta** means that only states plus or minus **lmc-gibbsdelta** are considered in exchanges up and down. A value of -1 means that all states are considered. For less than 100 states, it is probably not that expensive to include all states.
+
+lmc-forced-nstart: (0)
+: Force initial state space sampling to generate weights. In order to come up with reasonable initial weights, this setting allows the simulation to drive from the initial to the final lambda state, with **lmc-forced-nstart** steps at each state before moving on to the next lambda state. If **lmc-forced-nstart** is sufficiently long (thousands of steps, perhaps), then the weights will be close to correct. However, in most cases, it is probably better to simply run the standard weight equilibration algorithms. **nst-transition-matrix: (-1)**
+ Frequency of outputting the expanded ensemble transition matrix. A negative number means it will only be printed at the end of the simulation.
+
+symmetrized-transition-matrix: (no)
+: Whether to symmetrize the empirical transition matrix. In the infinite limit the matrix will be symmetric, but will diverge with statistical noise for short timescales. Forced symmetrization, by using the matrix T_sym = 1/2 (T + transpose(T)), removes problems like the existence of (small magnitude) negative eigenvalues.
+
+mininum-var-min: (100)
+: The **min-variance** strategy (option of **lmc-stats** is only valid for larger number of samples, and can get stuck if too few samples are used at each state. **mininum-var-min** is the minimum number of samples that each state that are allowed before the **min-variance** strategy is activated if selected.
+
+init-lambda-weights:
+: The initial weights (free energies) used for the expanded ensemble states. Default is a vector of zero weights. format is similar to the lambda vector settings in **fep-lambdas**, except the weights can be any floating point number. Units are kT. Its length must match the lambda vector lengths.
+
+lmc-weights-equil: (no)
+: + **no**
+ Expanded ensemble weights continue to be updated throughout the simulation.
+
+ + **yes**
+ The input expanded ensemble weights are treated as equilibrated, and are not updated throughout the simulation.
+
+ + **wl-delta**
+ Expanded ensemble weight updating is stopped when the Wang-Landau incrementor falls below the value specified by **weight-equil-wl-delta**.
+
+ + **number-all-lambda**
+ Expanded ensemble weight updating is stopped when the number of samples at all of the lambda states is greater than the value specified by **weight-equil-number-all-lambda**.
+
+ + **number-steps**
+ Expanded ensemble weight updating is stopped when the number of steps is greater than the level specified by **weight-equil-number-steps**.
+
+ + **number-samples**
+ Expanded ensemble weight updating is stopped when the number of total samples across all lambda states is greater than the level specified by **weight-equil-number-samples**.
+
+ + **count-ratio**
+ Expanded ensemble weight updating is stopped when the ratio of samples at the least sampled lambda state and most sampled lambda state greater than the value specified by **weight-equil-count-ratio**.
+
+simulated-tempering: (no)
+: Turn simulated tempering on or off. Simulated tempering is implemented as expanded ensemble sampling with different temperatures instead of different Hamiltonians.
+
+sim-temp-low: (300) [K]
+: Low temperature for simulated tempering.
+
+sim-temp-high: (300) [K]
+: High temperature for simulated tempering.
+
+simulated-tempering-scaling: (linear)
+: Controls the way that the temperatures at intermediate lambdas are calculated from the **temperature-lambda** part of the lambda vector.
+
+ + **linear**
+ Linearly interpolates the temperatures using the values of **temperature-lambda**, _i.e._ if **sim-temp-low**=300, **sim-temp-high**=400, then lambda=0.5 correspond to a temperature of 350. A nonlinear set of temperatures can always be implemented with uneven spacing in lambda.
+
+ + **geometric**
+ Interpolates temperatures geometrically between **sim-temp-low** and **sim-temp-high**. The i:th state has temperature **sim-temp-low** * (**sim-temp-high**/**sim-temp-low**) raised to the power of (i/(ntemps-1)). This should give roughly equal exchange for constant heat capacity, though of course things simulations that involve protein folding have very high heat capacity peaks.
+
+ + **exponential**
+ Interpolates temperatures exponentially between **sim-temp-low** and **sim-temp-high**. The ith state has temperature **sim-temp-low** + (**sim-temp-high**-**sim-temp-low**)*((exp(**temperature-lambdas**[i])-1)/(exp(1.0)-1)).
+
+
+### Non-equilibrium MD
+
+acc-grps:
+: groups for constant acceleration (_e.g._ `Protein Sol`) all atoms in groups Protein and Sol will experience constant acceleration as specified in the **accelerate** line
+
+accelerate: (0) [nm ps-2]
+: acceleration for **acc-grps**; x, y and z for each group (_e.g._ `0.1 0.0 0.0 -0.1 0.0 0.0` means that first group has constant acceleration of 0.1 nm ps-2 in X direction, second group the opposite).
+
+freezegrps:
+: Groups that are to be frozen (_i.e._ their X, Y, and/or Z position will not be updated; _e.g._ `Lipid SOL`). **freezedim** specifies for which dimension the freezing applies. To avoid spurious contibrutions to the virial and pressure due to large forces between completely frozen atoms you need to use energy group exclusions, this also saves computing time. Note that coordinates of frozen atoms are not scaled by pressure-coupling algorithms.
+
+freezedim:
+: dimensions for which groups in **freezegrps** should be frozen, specify `Y` or `N` for X, Y and Z and for each group (_e.g._ `Y Y N N N N` means that particles in the first group can move only in Z direction. The particles in the second group can move in any direction).
+
+cos-acceleration: (0) [nm ps-2]
+: the amplitude of the acceleration profile for calculating the viscosity. The acceleration is in the X-direction and the magnitude is **cos-acceleration** cos(2 pi z/boxheight). Two terms are added to the energy file: the amplitude of the velocity profile and 1/viscosity.
+
+deform: (0 0 0 0 0 0) [nm ps-1]
+: The velocities of deformation for the box elements: a(x) b(y) c(z) b(x) c(x) c(y). Each step the box elements for which **deform** is non-zero are calculated as: box(ts)+(t-ts)*deform, off-diagonal elements are corrected for periodicity. The coordinates are transformed accordingly. Frozen degrees of freedom are (purposely) also transformed. The time ts is set to t at the first step and at steps at which x and v are written to trajectory to ensure exact restarts. Deformation can be used together with semiisotropic or anisotropic pressure coupling when the appropriate compressibilities are set to zero. The diagonal elements can be used to strain a solid. The off-diagonal elements can be used to shear a solid or a liquid.
+
+
+### Electric fields
+
+E-x ; E-y ; E-z:
+: If you want to use an electric field in a direction, enter 3 numbers after the appropriate **E-***, the first number: the number of cosines, only 1 is implemented (with frequency 0) so enter 1, the second number: the strength of the electric field in **V nm-1**, the third number: the phase of the cosine, you can enter any number here since a cosine of frequency zero has no phase.
+
+E-xt; E-yt; E-zt:
+: not implemented yet
+
+
+### Mixed quantum/classical molecular dynamics
+
+QMMM:
+: + **no**
+ No QM/MM.
+
+ + **yes**
+ Do a QM/MM simulation. Several groups can be described at different QM levels separately. These are specified in the **QMMM-grps** field separated by spaces. The level of _ab initio_ theory at which the groups are described is specified by **QMmethod** and **QMbasis** Fields. Describing the groups at different levels of theory is only possible with the ONIOM QM/MM scheme, specified by **QMMMscheme**.
+
+QMMM-grps:
+: groups to be descibed at the QM level
+
+QMMMscheme:
+: + **normal**
+ normal QM/MM. There can only be one **QMMM-grps** that is modelled at the **QMmethod** and **QMbasis** level of _ab initio_ theory. The rest of the system is described at the MM level. The QM and MM subsystems interact as follows: MM point charges are included in the QM one-electron hamiltonian and all Lennard-Jones interactions are described at the MM level.
+
+ + **ONIOM**
+ The interaction between the subsystem is described using the ONIOM method by Morokuma and co-workers. There can be more than one **QMMM-grps** each modeled at a different level of QM theory (**QMmethod** and **QMbasis**).
+
+QMmethod: (RHF)
+: Method used to compute the energy and gradients on the QM atoms. Available methods are AM1, PM3, RHF, UHF, DFT, B3LYP, MP2, CASSCF, and MMVB. For CASSCF, the number of electrons and orbitals included in the active space is specified by **CASelectrons** and **CASorbitals**.
+
+QMbasis: (STO-3G)
+: Basis set used to expand the electronic wavefuntion. Only Gaussian basis sets are currently available, _i.e._ `STO-3G, 3-21G, 3-21G*, 3-21+G*, 6-21G, 6-31G, 6-31G*, 6-31+G*,` and `6-311G`.
+
+QMcharge: (0) [integer]
+: The total charge in `e` of the **QMMM-grps**. In case there are more than one **QMMM-grps**, the total charge of each ONIOM layer needs to be specified separately.
+
+QMmult: (1) [integer]
+: The multiplicity of the **QMMM-grps**. In case there are more than one **QMMM-grps**, the multiplicity of each ONIOM layer needs to be specified separately.
+
+CASorbitals: (0) [integer]
+: The number of orbitals to be included in the active space when doing a CASSCF computation.
+
+CASelectrons: (0) [integer]
+: The number of electrons to be included in the active space when doing a CASSCF computation.
+
+SH:
+: + **no**
+ No surface hopping. The system is always in the electronic ground-state.
+
+ + **yes**
+ Do a QM/MM MD simulation on the excited state-potential energy surface and enforce a _diabatic_ hop to the ground-state when the system hits the conical intersection hyperline in the course the simulation. This option only works in combination with the CASSCF method.
+
+
+### Implicit solvent
+
+implicit-solvent:
+: + **no**
+ No implicit solvent
+
+ + **GBSA**
+ Do a simulation with implicit solvent using the Generalized Born formalism. Three different methods for calculating the Born radii are available, Still, HCT and OBC. These are specified with the **gb-algorithm** field. The non-polar solvation is specified with the **sa-algorithm** field.
+
+gb-algorithm:
+: + **Still**
+ Use the Still method to calculate the Born radii
+
+ + **HCT**
+ Use the Hawkins-Cramer-Truhlar method to calculate the Born radii
+
+ + **OBC**
+ Use the Onufriev-Bashford-Case method to calculate the Born radii
+
+nstgbradii: (1) [steps]
+: Frequency to (re)-calculate the Born radii. For most practial purposes, setting a value larger than 1 violates energy conservation and leads to unstable trajectories.
+
+rgbradii: (1.0) [nm]
+: Cut-off for the calculation of the Born radii. Currently must be equal to rlist
+
+gb-epsilon-solvent: (80)
+: Dielectric constant for the implicit solvent
+
+gb-saltconc: (0) [M]
+: Salt concentration for implicit solvent models, currently not used
+
+gb-obc-alpha (1); gb-obc-beta (0.8); gb-obc-gamma (4.85);
+: Scale factors for the OBC model. Default values are OBC(II). Values for OBC(I) are 0.8, 0 and 2.91 respectively
+
+gb-dielectric-offset: (0.009) [nm]
+: Distance for the di-electric offset when calculating the Born radii. This is the offset between the center of each atom the center of the polarization energy for the corresponding atom
+
+sa-algorithm
+: + **Ace-approximation**
+ Use an Ace-type approximation (default)
+
+ + **None**
+ No non-polar solvation calculation done. For GBSA only the polar part gets calculated
+
+sa-surface-tension: [kJ mol-1 nm-2]
+: Default value for surface tension with SA algorithms. The default value is -1; Note that if this default value is not changed it will be overridden by [gmx grompp] using values that are specific for the choice of radii algorithm (0.0049 kcal/mol/Angstrom2 for Still, 0.0054 kcal/mol/Angstrom2 for HCT/OBC) Setting it to 0 will while using an sa-algorithm other than None means no non-polar calculations are done.
+
+
+### Adaptive Resolution Simulation
+
+adress: (no)
+: Decide whether the AdResS feature is turned on.
+
+adress-type: (Off)
+: + **Off**
+ Do an AdResS simulation with weight equal 1, which is equivalent to an explicit (normal) MD simulation. The difference to disabled AdResS is that the AdResS variables are still read-in and hence are defined.
+
+ + **Constant**
+ Do an AdResS simulation with a constant weight, **adress-const-wf** defines the value of the weight
+
+ + **XSplit**
+ Do an AdResS simulation with simulation box split in x-direction, so basically the weight is only a function of the x coordinate and all distances are measured using the x coordinate only.
+
+ + **Sphere**
+ Do an AdResS simulation with spherical explicit zone.
+
+adress-const-wf: (1)
+: Provides the weight for a constant weight simulation (**adress-type**=Constant)
+
+adress-ex-width: (0)
+: Width of the explicit zone, measured from **adress-reference-coords**.
+
+adress-hy-width: (0)
+: Width of the hybrid zone.
+
+adress-reference-coords: (0,0,0)
+: Position of the center of the explicit zone. Periodic boundary conditions apply for measuring the distance from it.
+
+adress-cg-grp-names
+: The names of the coarse-grained energy groups. All other energy groups are considered explicit and their interactions will be automatically excluded with the coarse-grained groups.
+* **adress-site: (COM)** The mapping point from which the weight is calculated.
+
+ + **COM**
+ The weight is calculated from the center of mass of each charge group.
+
+ + **COG**
+ The weight is calculated from the center of geometry of each charge group.
+
+ + **Atom**
+ The weight is calculated from the position of 1st atom of each charge group.
+
+ + **AtomPerAtom**
+ The weight is calculated from the position of each individual atom.
+
+adress-interface-correction: (Off)
+: + **Off**
+ Do not a apply any interface correction.
+
+ + **thermoforce**
+ Apply thermodynamic force interface correction. The table can be specified using the `-tabletf` option of [mdrun]. The table should contain the potential and force (acting on molecules) as function of the distance from **adress-reference-coords**.
+
+adress-tf-grp-names
+: The names of the energy groups to which the **thermoforce** is applied if enabled in **adress-interface-correction**. If no group is given the default table is applied.
+
+adress-ex-forcecap: (0)
+: Cap the force in the hybrid region, useful for big molecules. 0 disables force capping.
+
+
+### User defined thingies
+
+user1-grps; user2-grps; userint1 (0); userint2 (0); userint3 (0); userint4 (0); userreal1 (0); userreal2 (0); userreal3 (0); userreal4 (0)
+: These you can use if you modify code. You can pass integers and reals to your subroutine. Check the inputrec definition in `src/include/types/inputrec.h`
--- /dev/null
+# Useful `mdrun` features #
+
+This section discusses features in `mdrun` that don't fit well
+elsewhere.
+
+## Re-running a simulation
+
+The rerun feature allows you to take a trajectory file in any
+supported format and compute quantities based upon the coordinates in
+that file using the model physics supplied in the `topol.tpr` file. It
+can be used with command lines like `mdrun -s topol -rerun
+traj.trr`. That [.tpr] could be different from the one that generated
+the trajectory. This can be used to compute the energy or forces for
+exactly the coordinates supplied as input, or to extract quantities
+based on subsets of the molecular system (see [gmx convert-tpr] and
+[gmx trjconv]).
+
+Neighbour searching is normally performed for every frame in the
+trajectory, since [mdrun] can no longer assume anything about how the
+structures were generated. If `nstlist` is zero, then only one
+neighbour list will be constructed. Naturally, no update or constraint
+algorithms are ever used.
+
+## Running a simulation in reproducible mode
+
+It is generally difficult to run an efficient parallel MD simulation
+that is based primarily on floating-point arithmetic and is fully
+reproducible. By default, [mdrun] will observe how things are going
+and vary how the simulation is conducted in order to optimize
+throughput. However, there is a "reproducible mode" available with
+`mdrun -reprod` that will systematically eliminate all sources of
+variation within that run; repeated invocations on the same input and
+hardware will be binary identical. However, running in this mode on
+different hardware, or with a different compiler, etc. will not be
+reproducible. This should normally only be used when investigating
+possible problems.
+
+## Running multi-simulations
+
+There are numerous situations where running a related set of
+simulations within the same invocation of mdrun are necessary or
+useful. Running a replica-exchange simulation requires it, as do
+simulations using ensemble-based distance or orientation restraints.
+Running a related series of lambda points for a free-energy
+computation is also convenient to do this way.
+
+This feature requires [configuring GROMACS with an external MPI
+library](install-guide.html#mpi-support) so that the set of
+simulations can communicate. The `n` simulations within the set can
+use internal MPI parallelism also, so that `mpirun -np x mdrun_mpi`
+for `x` a multiple of `n` will use `x/n` ranks per simulation.
+
+There are two ways of organizing files when running such
+simulations. Most of the normal mechanisms work in either case,
+including `-deffnm`.
+
+`-multidir`
+ You must create a set of `n` directories for the `n` simulations,
+ place all the relevant input files in those directories (e.g. named
+ `topol.tpr`), and run with `mpirun -np x mdrun_mpi -s topol
+ -multidir <names-of-directories>`. If the order of the simulations
+ within the multi-simulation is significant, then you are responsible
+ for ordering their names when you provide them to `-multidir`. Be
+ careful with shells that do filename globbing dictionary-style, e.g.
+ `dir1 dir10 dir11 ... dir2 ...`. This option is generally the
+ most convenient to use. `mdrun -table` for the group cutoff-scheme
+ works only in this mode.
+
+`-multi`
+ You must organize that the filenames for each simulation in a set of
+ `n` simulations have an integer `0` through `n-1` appended to
+ the filename (e.g. `topol2.tpr`), and run with `mpirun -np x mdrun
+ -multi n -s input`. The order of simulations within the set is
+ determined by the integer appended.
+
+### Examples running multi-simulations
+
+ mpirun -np 32 mdrun_mpi -multi
+
+Starts a multi-simulation on 32 ranks with as many simulations `n` as
+there are files named `topol*.tpr` for integers `0` to `n-1`. Other
+input and output files are suffixed similarly.
+
+ mpirun -np 32 mdrun_mpi -multidir a b c d
+
+Starts a multi-simulation on 32 ranks with 4 simulations. The input
+and output files are found in directories `a`, `b`, `c`, and `d`.
+
+ mpirun -np 32 mdrun_mpi -multidir a b c d -gpu_id 0000000011111111
+
+Starts the same multi-simulation as before. On a machine with two
+physical nodes and two GPUs per node, there will be 16 MPI ranks per
+node, and 8 MPI ranks per simulation. The 16 MPI ranks doing PP work
+on a node are mapped to the GPUs with IDs 0 and 1, even though they
+come from more than one simulation. They are mapped in the order
+indicated, so that the PP ranks from each simulation use a single
+GPU. However, the order `0101010101010101` could run faster.
+
+### Running replica-exchange simulations
+
+When running a multi-simulation, using `mdrun -replex n` means that a
+replica exchange is attempted every given number of steps. The number
+of replicas is set with the `-multi` or `-multidir` option, described
+above. All run input files should use a different value for the
+coupling parameter (e.g. temperature), which ascends over the set of
+input files. The random seed for replica exchange is set with
+`-reseed`. After every exchange, The velocities are scaled and
+neighbor searching is performed. See the Reference Manual for more
+details on how replica exchange functions in GROMACS.
--- /dev/null
+# Getting good performance from `mdrun` #
+
+The GROMACS build system and the `mdrun` tool has a lot of built-in
+and configurable intelligence to detect your hardware and make pretty
+effective use of that hardware. For a lot of casual and serious use of
+`mdrun`, the automatic machinery works well enough. But to get the
+most from your hardware to maximise your scientific quality, read on!
+
+## Hardware background information ##
+
+Modern computer hardware is complex and heterogeneous, so we need to
+discuss a little bit of background information and set up some
+definitions. Experienced HPC users can skip this section.
+
+core
+: A hardware compute unit that actually executes instructions. There
+ is normally more than one core in a processor, often many more.
+
+cache
+: A special kind of memory local to core(s) that is much faster to
+ access than main memory, kind of like the top of a human's desk,
+ compared to their filing cabinet. There are often several layers
+ of caches associated with a core.
+
+socket
+: A group of cores that share some kind of locality, such as a shared
+ cache. This makes it more efficient to spread computational work
+ over cores within a socket than over cores in different
+ sockets. Modern processors often have more than one socket.
+
+node
+: A group of sockets that share coarser-level locality, such as shared
+ access to the same memory without requiring any network
+ hardware. A normal laptop or desktop computer is a node. A node
+ is often the smallest amount of a large compute cluster that a
+ user can request to use.
+
+thread
+: A stream of instructions for a core to execute. There are
+ many different programming abstractions that create and manage
+ spreading computation over multiple threads, such as OpenMP,
+ pthreads, winthreads, CUDA, OpenCL, and OpenACC. Some kinds of
+ hardware can map more than one software thread to a core; on Intel
+ x86 processors this is called "hyper-threading." Normally,
+ `mdrun` will not benefit from such mapping.
+
+affinity
+: On some kinds of hardware, software threads can migrate
+ between cores to help automatically balance workload. Normally,
+ the performance of `mdrun` will degrade dramatically if this is
+ permitted, so `mdrun` will by default set the affinity of its
+ threads to their cores, unless the user or software environment
+ has already done so. Setting thread affinity is sometimes called
+ "pinning" threads to cores.
+
+MPI
+: The dominant multi-node parallelization-scheme, which
+ provides a standardized language in which programs can be
+ written that work across more than one node.
+
+rank
+: In MPI, a rank is the smallest grouping of hardware
+ used in the multi-node parallelization scheme. That grouping can
+ be controlled by the user, and might correspond to a core, a
+ socket, a node, or a group of nodes. The best choice varies with
+ the hardware, software and compute task. Sometimes an MPI rank is
+ called an MPI process.
+
+GPU
+: A graphics processing unit, which is often faster
+ and more efficient than conventional processors for particular
+ kinds of compute workloads. A GPU is always associated with a
+ particular node, and often a particular socket within that node.
+
+OpenMP
+: A standardized technique supported by many compilers
+ to share a compute workload over multiple cores. Often
+ combined with MPI to achieve hybrid MPI/OpenMP parallelism.
+
+CUDA
+: A programming-language extension developed by Nvidia
+ for use in writing code for their GPUs.
+
+SIMD
+: Modern CPU cores have instructions that can execute
+ large numbers of floating-point instructions in a single
+ cycle.
+
+
+## GROMACS background information ##
+
+The algorithms in `mdrun` and their implementations are most relevant
+when choosing how to make good use of the hardware. For details,
+see the Reference Manual. The most important of these are
+
+Domain Decomposition (DD)
+: This algorithm decomposes the (short-ranged) component of the
+ non-bonded interactions into domains that share spatial locality,
+ which permits efficient code to be written. Each domain handles
+ all of the particle-particle (PP) interactions for its members,
+ and is mapped to a single rank. Within a PP rank, OpenMP threads
+ can share the workload, or the work can be off-loaded to a
+ GPU. The PP rank also handles any bonded interactions for the
+ members of its domain. A GPU may perform work for more than one PP
+ rank, but it is normally most efficient to use a single PP rank
+ per GPU and for that rank to have thousands of atoms. When the
+ work of a PP rank is done on the CPU, mdrun will make extensive
+ use of the SIMD capabilities of the core. There are various
+ [command-line options](#controlling-the-domain-decomposition-algorithm)
+ to control the behaviour of the DD algorithm.
+
+Particle-mesh Ewald (PME)
+: This algorithm treats the long-ranged components of the non-bonded
+ interactions (Coulomb and/or Lennard-Jones). Either all, or just
+ a subset of ranks may participate in the work for computing
+ long-ranged component (often inaccurately called simple the "PME"
+ component). Because the algorithm uses a 3D FFT that requires
+ global communication, its performance gets worse as more ranks
+ participate, which can mean it is fastest to use just a subset of
+ ranks (e.g. one-quarter to one-half of the ranks). If there are
+ separate PME ranks, then the remaining ranks handle the PP
+ work. Otherwise, all ranks do both PP and PME work.
+
+## Running mdrun within a single node ##
+
+`mdrun` can be configured and compiled in several different ways that
+are efficient to use within a single node. The default configuration
+using a suitable compiler will deploy a multi-level hybrid parallelism
+that uses CUDA, OpenMP and the threading platform native to the
+hardware. For programming convenience, in GROMACS, those native
+threads are used to implement on a single node the same MPI scheme as
+would be used between nodes, but much more efficient; this is called
+thread-MPI. From a user's perspective, real MPI and thread-MPI look
+almost the same, and GROMACS refers to MPI ranks to mean either kind,
+except where noted. A real external MPI can be used for `mdrun` within
+a single node, but runs more slowly than the thread-MPI version.
+
+By default, `mdrun` will inspect the hardware available at run time
+and do its best to make fairly efficient use of the whole node. The
+log file, stdout and stderr are used to print diagnostics that
+inform the user about the choices made and possible consequences.
+
+A number of command-line parameters are available to vary the default
+behaviour.
+
+`-nt`
+: The total number of threads to use. The default, 0, will start as
+ many threads as available cores. Whether the threads are
+ thread-MPI ranks, or OpenMP threads within such ranks depends on
+ other settings.
+
+`-ntmpi`
+: The total number of thread-MPI ranks to use. The default, 0,
+ will start one rank per GPU (if present), and otherwise one rank
+ per core.
+
+`-ntomp`
+: The total number of OpenMP threads per rank to start. The
+ default, 0, will start one thread on each available core.
+ Alternatively, mdrun will honour the appropriate system
+ environment variable (e.g. `OMP_NUM_THREADS`) if set.
+
+`-npme`
+: The total number of ranks to dedicate to the long-ranged
+ component of PME, if used. The default, -1, will dedicate ranks
+ only if the total number of threads is at least 12, and will use
+ around one-third of the ranks for the long-ranged component.
+
+`-ntomp_pme`
+: When using PME with separate PME ranks,
+ the total number of OpenMP threads per separate PME ranks.
+ The default, 0, copies the value from `-ntomp`.
+
+`-gpu_id`
+: A string that specifies the ID numbers of the GPUs to be
+ used by corresponding PP ranks on this node. For example,
+ "0011" specifies that the lowest two PP ranks use GPU 0,
+ and the other two use GPU 1.
+
+`-pin`
+: Can be set to "auto," "on" or "off" to control whether
+ mdrun will attempt to set the affinity of threads to cores.
+ Defaults to "auto," which means that if mdrun detects that all the
+ cores on the node are being used for mdrun, then it should behave
+ like "on," and attempt to set the affinities (unless they are
+ already set by something else).
+
+`-pinoffset`
+: If `-pin on`, specifies the logical core number to
+ which mdrun should pin the first thread. When running more than
+ one instance of mdrun on a node, use this option to to avoid
+ pinning threads from different mdrun instances to the same core.
+
+`-pinstride`
+: If `-pin on`, specifies the stride in logical core
+ numbers for the cores to which mdrun should pin its threads. When
+ running more than one instance of mdrun on a node, use this option
+ to to avoid pinning threads from different mdrun instances to the
+ same core. Use the default, 0, to minimize the number of threads
+ per physical core - this lets mdrun manage the hardware-, OS- and
+ configuration-specific details of how to map logical cores to
+ physical cores.
+
+`-ddorder`
+: Can be set to "interleave," "pp_pme" or "cartesian."
+ Defaults to "interleave," which means that any separate PME ranks
+ will be mapped to MPI ranks in an order like PP, PP, PME, PP, PP,
+ PME, ... etc. This generally makes the best use of the available
+ hardware. "pp_pme" maps all PP ranks first, then all PME
+ ranks. "cartesian" is a special-purpose mapping generally useful
+ only on special torus networks with accelerated global
+ communication for Cartesian communicators. Has no effect if there
+ are no separate PME ranks.
+
+`-nb`
+: Can be set to "auto", "cpu", "gpu", "cpu_gpu."
+ Defaults to "auto," which uses a compatible GPU if available.
+ Setting "cpu" requires that no GPU is used. Setting "gpu" requires
+ that a compatible GPU be available and will be used. Setting
+ "cpu_gpu" permits the CPU to execute a GPU-like code path, which
+ will run slowly on the CPU and should only be used for debugging.
+
+### Examples for mdrun on one node
+
+ mdrun
+Starts mdrun using all the available resources. mdrun
+will automatically choose a fairly efficient division
+into thread-MPI ranks, OpenMP threads and assign work
+to compatible GPUs. Details will vary with hardware
+and the kind of simulation being run.
+
+ mdrun -nt 8
+Starts mdrun using 8 threads, which might be thread-MPI
+or OpenMP threads depending on hardware and the kind
+of simulation being run.
+
+ mdrun -ntmpi 2 -ntomp 4
+Starts mdrun using eight total threads, with four thread-MPI
+ranks and two OpenMP threads per core. You should only use
+these options when seeking optimal performance, and
+must take care that the ranks you create can have
+all of their OpenMP threads run on the same socket.
+The number of ranks must be a multiple of the number of
+sockets, and the number of cores per node must be
+a multiple of the number of threads per rank.
+
+ mdrun -gpu_id 12
+Starts mdrun using GPUs with IDs 1 and 2 (e.g. because
+GPU 0 is dedicated to running a display). This requires
+two thread-MPI ranks, and will split the available
+CPU cores between them using OpenMP threads.
+
+ mdrun -ntmpi 4 -gpu_id "1122"
+Starts mdrun using four thread-MPI ranks, and maps them
+to GPUs with IDs 1 and 2. The CPU cores available will
+be split evenly between the ranks using OpenMP threads.
+
+ mdrun -nt 6 -pin on -pinoffset 0
+ mdrun -nt 6 -pin on -pinoffset 3
+Starts two mdrun processes, each with six total threads.
+Threads will have their affinities set to particular
+logical cores, beginning from the logical core
+with rank 0 or 3, respectively. The above would work
+well on an Intel CPU with six physical cores and
+hyper-threading enabled. Use this kind of setup only
+if restricting mdrun to a subset of cores to share a
+node with other processes.
+
+ mpirun_mpi -np 2
+When using an `mdrun_mpi` compiled with external MPI,
+this will start two ranks and as many OpenMP threads
+as the hardware and MPI setup will permit. If the
+MPI setup is restricted to one node, then the resulting
+`mdrun_mpi` will be local to that node.
+
+## Running mdrun on more than one node ##
+
+This requires configuring GROMACS to build with an external MPI
+library. By default, this mdrun executable will be named
+`mdrun_mpi`. All of the considerations for running single-node
+mdrun still apply, except that `-ntmpi` and `-nt` cause a fatal
+error, and instead the number of ranks is controlled by the
+MPI environment.
+Settings such as `-npme` are much more important when
+using multiple nodes. Configuring the MPI environment to
+produce one rank per core is generally good until one
+approaches the strong-scaling limit. At that point, using
+OpenMP to spread the work of an MPI rank over more than one
+core is needed to continue to improve absolute performance.
+The location of the scaling limit depends on the processor,
+presence of GPUs, network, and simulation algorithm, but
+it is worth measuring at around ~200 atoms/core if you
+need maximum throughput.
+
+There are further command-line parameters that are relevant in these
+cases.
+
+`-tunepme`
+: If "on," will optimize various aspects of the PME
+ and DD algorithms, shifting load between ranks and/or
+ GPUs to maximize throughput
+
+`-gcom`
+: Can be used to limit global communication every n steps. This can
+ improve performance for highly parallel simulations where this global
+ communication step becomes the bottleneck. For a global thermostat
+ and/or barostat, the temperature and/or pressure will also only be
+ updated every `-gcom` steps. By default, it is set to the
+ minimum of `nstcalcenergy` and `nstlist`.
+
+The [gmx tune_pme] utility is available to search a wider
+range of parameter space, including making safe
+modifications to the [.tpr] file, and varying `-npme`.
+It is only aware of the number of ranks created by
+the MPI environment, and does not explicitly manage
+any aspect of OpenMP during the optimization.
+
+### Examples for mdrun on more than one node ##
+
+The examples and explanations for for single-node mdrun are
+still relevant, but `-nt` is no longer the way
+to choose the number of MPI ranks.
+
+ mpirun -np 16 mdrun_mpi
+Starts `mdrun_mpi` with 16 ranks, which are mapped to
+the hardware by the MPI library, e.g. as specified
+in an MPI hostfile. The available cores will be
+automatically split among ranks using OpenMP threads,
+depending on the hardware and any environment settings
+such as `OMP_NUM_THREADS`.
+
+ mpirun -np 16 mdrun_mpi -npme 5
+Starts `mdrun_mpi` with 16 ranks, as above, and
+require that 5 of them are dedicated to the PME
+component.
+
+ mpirun -np 11 mdrun_mpi -ntomp 2 -npme 6 -ntomp_pme 1
+Starts `mdrun_mpi` with 11 ranks, as above, and
+require that six of them are dedicated to the PME
+component with one OpenMP thread each. The remaining
+five do the PP component, with two OpenMP threads
+each.
+
+ mpirun -np 4 mdrun -ntomp 6 -gpu_id 00
+Starts `mdrun_mpi` on a machine with two nodes, using
+four total ranks, each rank with six OpenMP threads,
+and both ranks on a node sharing GPU with ID 0.
+
+ mpirun -np 8 mdrun -ntomp 3 -gpu_id 0000
+Starts `mdrun_mpi` on a machine with two nodes, using
+eight total ranks, each rank with three OpenMP threads,
+and all four ranks on a node sharing GPU with ID 0.
+This may or may not be faster than the previous setup
+on the same hardware.
+
+ mpirun -np 20 mdrun_mpi -ntomp 4 -gpu_id 0
+Starts `mdrun_mpi` with 20 ranks, and assigns the CPU cores evenly
+across ranks each to one OpenMP thread. This setup is likely to be
+suitable when there are ten nodes, each with one GPU, and each node
+has two sockets.
+
+ mpirun -np 20 mdrun_mpi -gpu_id 00
+Starts `mdrun_mpi` with 20 ranks, and assigns the CPU cores evenly
+across ranks each to one OpenMP thread. This setup is likely to be
+suitable when there are ten nodes, each with one GPU, and each node
+has two sockets.
+
+ mpirun -np 20 mdrun_mpi -gpu_id 01
+Starts `mdrun_mpi` with 20 ranks. This setup is likely
+to be suitable when there are ten nodes, each with two
+GPUs.
+
+ mpirun -np 40 mdrun_mpi -gpu_id 0011
+Starts `mdrun_mpi` with 40 ranks. This setup is likely
+to be suitable when there are ten nodes, each with two
+GPUs, and OpenMP performs poorly on the hardware.
+
+## Controlling the domain decomposition algorithm
+
+This section lists all the options that affect how the domain
+decomposition algorithm decomposes the workload to the available
+parallel hardware.
+
+`-rdd`
+: Can be used to set the required maximum distance for inter
+ charge-group bonded interactions. Communication for two-body
+ bonded interactions below the non-bonded cut-off distance always
+ comes for free with the non-bonded communication. Atoms beyond
+ the non-bonded cut-off are only communicated when they have
+ missing bonded interactions; this means that the extra cost is
+ minor and nearly indepedent of the value of `-rdd`. With dynamic
+ load balancing, option `-rdd` also sets the lower limit for the
+ domain decomposition cell sizes. By default `-rdd` is determined
+ by [mdrun] based on the initial coordinates. The chosen value will
+ be a balance between interaction range and communication cost.
+
+`-ddcheck`
+: On by default. When inter charge-group bonded interactions are
+ beyond the bonded cut-off distance, [mdrun] terminates with an
+ error message. For pair interactions and tabulated bonds that do
+ not generate exclusions, this check can be turned off with the
+ option `-noddcheck`.
+
+`-rcon`
+: When constraints are present, option `-rcon` influences
+ the cell size limit as well.
+ Atoms connected by NC constraints, where NC is the LINCS order
+ plus 1, should not be beyond the smallest cell size. A error
+ message is generated when this happens, and the user should change
+ the decomposition or decrease the LINCS order and increase the
+ number of LINCS iterations. By default [mdrun] estimates the
+ minimum cell size required for P-LINCS in a conservative
+ fashion. For high parallelization, it can be useful to set the
+ distance required for P-LINCS with `-rcon`.
+
+`-dds`
+: Sets the minimum allowed x, y and/or z scaling of the cells with
+ dynamic load balancing. [mdrun] will ensure that the cells can
+ scale down by at least this factor. This option is used for the
+ automated spatial decomposition (when not using `-dd`) as well as
+ for determining the number of grid pulses, which in turn sets the
+ minimum allowed cell size. Under certain circumstances the value
+ of `-dds` might need to be adjusted to account for high or low
+ spatial inhomogeneity of the system.
+
+## Finding out how to run mdrun better
+
+TODO In future patch: red flags in log files, how to interpret wallcycle output
+
+TODO In future patch: import wiki page stuff on performance checklist; maybe here,
+maybe elsewhere
+
+## Running mdrun with GPUs
+
+TODO In future patch: any tips not covered above
--- /dev/null
+[/a/]: # (TODO when we decide on file formats and generation engine, resolve whether generating these should be automated, or whatever)
+
+[gmx bar]: programs/gmx-bar.html
+[gmx energy]: programs/gmx-energy.html
+[gmx convert-tpr]: programs/gmx-convert-tpr.html
+[gmx trjconv]: programs/gmx-trjconv.html
+[gmx dipoles]: programs/gmx-dipoles.html
+[gmx tune_pme]: programs/gmx-tune_pme.html
+[gmx do_dssp]: programs/gmx-do_dssp.html
+[gmx view]: programs/gmx-view.html
+[gmx eneconv]: programs/gmx-eneconv.html
+[gmx wham]: programs/gmx-wham.html
+[gmx grompp]: programs/gmx-grompp.html
+[gmx solvate]: programs/gmx-solvate.html
+[gmx editconf]: programs/gmx-editconf.html
+[gmx pdb2gmx]: programs/gmx-pdb2gmx.html
+[gmx mdrun]: programs/gmx-mdrun.html
+[mdrun]: programs/gmx-mdrun.html
+[trjcat]: programs/gmx-trjcat.html
+[eneconv]: programs/gmx-eneconv.html
+
+[pdb]: online/pdb.html
+[.pdb]: online/pdb.html
+[.gro]: online/gro.html
+[.top]: online/top.html
+[.cpt]: online/cpt.html
+[.trr]: online/trr.html
+[.xtc]: online/xtc.html
+[.tng]: online/tng.html
+[.tpr]: online/tpr.html
+[.ndx]: online/ndx.html
+[.mdp]: online/mdp.html
+
+[wwwpage]: http://www.gromacs.org
+[install guide]: install-guide.html
+[reference manual]: manual-@PROJECT_VERSION@.pdf
--- /dev/null
+# Command-line tools in GROMACS
+
+GROMACS includes many tools for preparing, running and analysing
+molecular dynamics simulations. These are all structured as part of
+the `gmx` binary, and invoked with commands like `gmx grompp`.
+[mdrun] is the only other binary that [can be
+built](install-guide.html#building-only-mdrun), but even it can be run
+with `gmx mdrun`. Documentation for these can be found at the links
+below.
+
+* Tools documentation [by name](programs/byname.html)
+* Tools documentation [by topic](programs/bytopic.html)
+
+## Common options and behaviour of GROMACS tools
+
+Optional files are not used unless the option is set, in contrast to
+non optional files, where the default file name is used when the
+option is not set.
+
+All GROMACS tools will accept file options without a file extension
+or filename being specified. In such cases the default filenames will
+be used. With multiple input file types, such as generic structure
+format, the directory will be searched for files of each type with the
+supplied or default name. When no such file is found, or with output
+files the first file type will be used.
+
+All GROMACS tools with the exception of [mdrun], [trjcat] and
+[eneconv] check if the command line options are valid. If this is not
+the case, the program will be halted.
+
+All GROMACS tools have 4 hidden options:
+
+ option type default description
+------------- ---- ------- ------------------
+`-[no]hidden` bool [`yes`] [hidden] Print description for hidden options
+`-[no]quiet` bool [` no`] [hidden] Do not print help info
+`-[no]debug` bool [` no`] [hidden] Write file with debug information
+
+Many tools accept enumerated options (enum), which should be used with
+one of the arguments listed in the option description. The argument
+may be abbreviated, and the first match to the shortest argument in
+the list will be selected.
+
+Many tools also use options that may accept a vector of values. Either
+1 or 3 parameters can be supplied; when only one parameter is supplied
+the two other values are also set to this value.
+
+All GROMACS tools can read compressed (`*.Z`) or g-zipped (`*.gz`)
+files. There might be a problem with reading compressed [.tng] or
+[.xtc] files, but these will not compress very well anyway.
+
+Most GROMACS tools can process a trajectory with fewer atoms than the
+run input or structure file, but only if the trajectory consists of
+the first n atoms of the run input or structure file.
+
+
*
* Copyright (c) 1991-2000, University of Groningen, The Netherlands.
* Copyright (c) 2001-2008, The GROMACS development team.
- * Copyright (c) 2013,2014, by the GROMACS development team, led by
+ * Copyright (c) 2013,2014,2015, by the GROMACS development team, led by
* Mark Abraham, David van der Spoel, Berk Hess, and Erik Lindahl,
* and including many others, as listed in the AUTHORS file in the
* top-level source directory and at http://www.gromacs.org.
int
gmx_pme_error(int argc, char *argv[]);
-int
-gmx_options(int argc, char *argv[]);
-
int
gmx_sans(int argc, char *argv[]);
+++ /dev/null
-/*
- * This file is part of the GROMACS molecular simulation package.
- *
- * Copyright (c) 1991-2000, University of Groningen, The Netherlands.
- * Copyright (c) 2001-2006, The GROMACS development team.
- * Copyright (c) 2013,2014, by the GROMACS development team, led by
- * Mark Abraham, David van der Spoel, Berk Hess, and Erik Lindahl,
- * and including many others, as listed in the AUTHORS file in the
- * top-level source directory and at http://www.gromacs.org.
- *
- * GROMACS is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public License
- * as published by the Free Software Foundation; either version 2.1
- * of the License, or (at your option) any later version.
- *
- * GROMACS is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with GROMACS; if not, see
- * http://www.gnu.org/licenses, or write to the Free Software Foundation,
- * Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
- *
- * If you want to redistribute modifications to GROMACS, please
- * consider that scientific software is very special. Version
- * control is crucial - bugs must be traceable. We will be happy to
- * consider code for inclusion in the official distribution, but
- * derived work must not be called official GROMACS. Details are found
- * in the README & COPYING files - if they are missing, get the
- * official version at http://www.gromacs.org.
- *
- * To help us fund GROMACS development, we humbly ask that you cite
- * the research papers on the package. Check out http://www.gromacs.org.
- */
-#include "gmxpre.h"
-
-#include "gromacs/commandline/pargs.h"
-#include "gromacs/legacyheaders/macros.h"
-#include "gromacs/legacyheaders/typedefs.h"
-
-/*
- * This program is needed to create the files:
- * options.html
- * options.tex
- * for the html and latex manuals.
- * It should be ran with the option: -hidden
- */
-
-int
-gmx_options(int argc, char *argv[])
-{
- const char *desc[] = {
- "GROMACS programs have some standard options,",
- "of which some are hidden by default:"
- };
-
- const char *bugs[] = {
- "If the configuration script found Motif or Lesstif on your system, "
- "you can use the graphical interface (if not, you will get an error):[BR]"
- "[TT]-X[tt] gmx_bool [TT]no[tt] Use dialog box GUI to edit command line options",
-
- "Optional files are not used unless the option is set, in contrast to "
- "non-optional files, where the default file name is used when the "
- "option is not set.",
-
- "All GROMACS programs will accept file options without a file extension "
- "or filename being specified. In such cases the default filenames will "
- "be used. With multiple input file types, such as generic structure "
- "format, the directory will be searched for files of each type with the "
- "supplied or default name. When no such file is found, or with output "
- "files the first file type will be used.",
-
- "All GROMACS programs with the exception of [TT]mdrun[tt] "
- "and [TT]eneconv[tt] check if the command line options "
- "are valid. If this is not the case, the program will be halted.",
-
- "Enumerated options (enum) should be used with one of the arguments "
- "listed in the option description, the argument may be abbreviated. "
- "The first match to the shortest argument in the list will be selected.",
-
- "Vector options can be used with 1 or 3 parameters. When only one "
- "parameter is supplied the two others are also set to this value.",
-
- "All GROMACS programs can read compressed or g-zipped files. There "
- "might be a problem with reading compressed [TT].xtc[tt], "
- "[TT].trr[tt] files, but these will not compress "
- "very well anyway.",
-
- "Most GROMACS programs can process a trajectory with fewer atoms than "
- "the run input or structure file, but only if the trajectory consists "
- "of the first n atoms of the run input or structure file.",
-
- "Many GROMACS programs will accept the [TT]-tu[tt] option to set the "
- "time units to use in output files (e.g. for [TT]xmgr[tt] graphs or "
- "[TT]xpm[tt] matrices) and in all time options."
- };
-
- output_env_t oenv = NULL;
- if (!parse_common_args(&argc, argv, 0,
- 0, NULL, 0, NULL, asize(desc), desc, asize(bugs), bugs, &oenv))
- {
- return 0;
- }
-
- return 0;
-}
/*
* This file is part of the GROMACS molecular simulation package.
*
- * Copyright (c) 2012,2013,2014, by the GROMACS development team, led by
+ * Copyright (c) 2012,2013,2014,2015, by the GROMACS development team, led by
* Mark Abraham, David van der Spoel, Berk Hess, and Erik Lindahl,
* and including many others, as listed in the AUTHORS file in the
* top-level source directory and at http://www.gromacs.org.
"Generate an ensemble of structures from the normal modes");
registerModule(manager, &gmx_nmtraj, "nmtraj",
"Generate a virtual oscillating trajectory from an eigenvector");
- registerModule(manager, &gmx_options, "options", NULL);
registerModule(manager, &gmx_order, "order",
"Compute the order parameter per atom for carbon tails");
registerModule(manager, &gmx_pme_error, "pme_error",
"([TT]-x[tt]).[PAR]",
"The option [TT]-dhdl[tt] is only used when free energy calculation is",
"turned on.[PAR]",
- "A simulation can be run in parallel using two different parallelization",
- "schemes: MPI parallelization and/or OpenMP thread parallelization.",
- "The MPI parallelization uses multiple processes when [TT]mdrun[tt] is",
- "compiled with a normal MPI library or threads when [TT]mdrun[tt] is",
- "compiled with the GROMACS built-in thread-MPI library. OpenMP threads",
- "are supported when [TT]mdrun[tt] is compiled with OpenMP. Full OpenMP support",
- "is only available with the Verlet cut-off scheme, with the (older)",
- "group scheme only PME-only ranks can use OpenMP parallelization.",
- "In all cases [TT]mdrun[tt] will by default try to use all the available",
- "hardware resources. With a normal MPI library only the options",
- "[TT]-ntomp[tt] (with the Verlet cut-off scheme) and [TT]-ntomp_pme[tt],",
- "for PME-only ranks, can be used to control the number of threads.",
- "With thread-MPI there are additional options [TT]-nt[tt], which sets",
- "the total number of threads, and [TT]-ntmpi[tt], which sets the number",
- "of thread-MPI threads.",
- "The number of OpenMP threads used by [TT]mdrun[tt] can also be set with",
- "the standard environment variable, [TT]OMP_NUM_THREADS[tt].",
- "The [TT]GMX_PME_NUM_THREADS[tt] environment variable can be used to specify",
- "the number of threads used by the PME-only ranks.[PAR]",
- "Note that combined MPI+OpenMP parallelization is in many cases",
- "slower than either on its own. However, at high parallelization, using the",
- "combination is often beneficial as it reduces the number of domains and/or",
- "the number of MPI ranks. (Less and larger domains can improve scaling,",
- "with separate PME ranks, using fewer MPI ranks reduces communication costs.)",
- "OpenMP-only parallelization is typically faster than MPI-only parallelization",
- "on a single CPU(-die). Since we currently don't have proper hardware",
- "topology detection, [TT]mdrun[tt] compiled with thread-MPI will only",
- "automatically use OpenMP-only parallelization when you use up to 4",
- "threads, up to 12 threads with Intel Nehalem/Westmere, or up to 16",
- "threads with Intel Sandy Bridge or newer CPUs. Otherwise MPI-only",
- "parallelization is used (except with GPUs, see below).",
- "[PAR]",
- "With GPUs (only supported with the Verlet cut-off scheme), the number",
- "of GPUs should match the number of particle-particle ranks, i.e.",
- "excluding PME-only ranks. With thread-MPI, unless set on the command line, the number",
- "of MPI threads will automatically be set to the number of GPUs detected.",
- "To use a subset of the available GPUs, or to manually provide a mapping of",
- "GPUs to PP ranks, you can use the [TT]-gpu_id[tt] option. The argument of [TT]-gpu_id[tt] is",
- "a string of digits (without delimiter) representing device id-s of the GPUs to be used.",
- "For example, \"[TT]02[tt]\" specifies using GPUs 0 and 2 in the first and second PP ranks per compute node",
- "respectively. To select different sets of GPU-s",
- "on different nodes of a compute cluster, use the [TT]GMX_GPU_ID[tt] environment",
- "variable instead. The format for [TT]GMX_GPU_ID[tt] is identical to ",
- "[TT]-gpu_id[tt], with the difference that an environment variable can have",
- "different values on different compute nodes. Multiple MPI ranks on each node",
- "can share GPUs. This is accomplished by specifying the id(s) of the GPU(s)",
- "multiple times, e.g. \"[TT]0011[tt]\" for four ranks sharing two GPUs in this node.",
- "This works within a single simulation, or a multi-simulation, with any form of MPI.",
- "[PAR]",
- "With the Verlet cut-off scheme and verlet-buffer-tolerance set,",
- "the pair-list update interval nstlist can be chosen freely with",
- "the option [TT]-nstlist[tt]. [TT]mdrun[tt] will then adjust",
- "the pair-list cut-off to maintain accuracy, and not adjust nstlist.",
- "Otherwise, by default, [TT]mdrun[tt] will try to increase the",
- "value of nstlist set in the [TT].mdp[tt] file to improve the",
- "performance. For CPU-only runs, nstlist might increase to 20, for",
- "GPU runs up to 40. For medium to high parallelization or with",
- "fast GPUs, a (user-supplied) larger nstlist value can give much",
- "better performance.",
- "[PAR]",
- "When using PME with separate PME ranks or with a GPU, the two major",
- "compute tasks, the non-bonded force calculation and the PME calculation",
- "run on different compute resources. If this load is not balanced,",
- "some of the resources will be idle part of time. With the Verlet",
- "cut-off scheme this load is automatically balanced when the PME load",
- "is too high (but not when it is too low). This is done by scaling",
- "the Coulomb cut-off and PME grid spacing by the same amount. In the first",
- "few hundred steps different settings are tried and the fastest is chosen",
- "for the rest of the simulation. This does not affect the accuracy of",
- "the results, but it does affect the decomposition of the Coulomb energy",
- "into particle and mesh contributions. The auto-tuning can be turned off",
- "with the option [TT]-notunepme[tt].",
- "[PAR]",
- "[TT]mdrun[tt] pins (sets affinity of) threads to specific cores,",
- "when all (logical) cores on a compute node are used by [TT]mdrun[tt],",
- "even when no multi-threading is used,",
- "as this usually results in significantly better performance.",
- "If the queuing systems or the OpenMP library pinned threads, we honor",
- "this and don't pin again, even though the layout may be sub-optimal.",
- "If you want to have [TT]mdrun[tt] override an already set thread affinity",
- "or pin threads when using less cores, use [TT]-pin on[tt].",
- "With SMT (simultaneous multithreading), e.g. Intel Hyper-Threading,",
- "there are multiple logical cores per physical core.",
- "The option [TT]-pinstride[tt] sets the stride in logical cores for",
- "pinning consecutive threads. Without SMT, 1 is usually the best choice.",
- "With Intel Hyper-Threading 2 is best when using half or less of the",
- "logical cores, 1 otherwise. The default value of 0 do exactly that:",
- "it minimizes the threads per logical core, to optimize performance.",
- "If you want to run multiple [TT]mdrun[tt] jobs on the same physical node,"
- "you should set [TT]-pinstride[tt] to 1 when using all logical cores.",
- "When running multiple [TT]mdrun[tt] (or other) simulations on the same physical",
- "node, some simulations need to start pinning from a non-zero core",
- "to avoid overloading cores; with [TT]-pinoffset[tt] you can specify",
- "the offset in logical cores for pinning.",
- "[PAR]",
- "When [TT]mdrun[tt] is started with more than 1 rank,",
- "parallelization with domain decomposition is used.",
- "[PAR]",
- "With domain decomposition, the spatial decomposition can be set",
- "with option [TT]-dd[tt]. By default [TT]mdrun[tt] selects a good decomposition.",
- "The user only needs to change this when the system is very inhomogeneous.",
- "Dynamic load balancing is set with the option [TT]-dlb[tt],",
- "which can give a significant performance improvement,",
- "especially for inhomogeneous systems. The only disadvantage of",
- "dynamic load balancing is that runs are no longer binary reproducible,",
- "but in most cases this is not important.",
- "By default the dynamic load balancing is automatically turned on",
- "when the measured performance loss due to load imbalance is 5% or more.",
- "At low parallelization these are the only important options",
- "for domain decomposition.",
- "At high parallelization the options in the next two sections",
- "could be important for increasing the performace.",
- "[PAR]",
- "When PME is used with domain decomposition, separate ranks can",
- "be assigned to do only the PME mesh calculation;",
- "this is computationally more efficient starting at about 12 ranks,",
- "or even fewer when OpenMP parallelization is used.",
- "The number of PME ranks is set with option [TT]-npme[tt],",
- "but this cannot be more than half of the ranks.",
- "By default [TT]mdrun[tt] makes a guess for the number of PME",
- "ranks when the number of ranks is larger than 16. With GPUs,",
- "using separate PME ranks is not selected automatically,",
- "since the optimal setup depends very much on the details",
- "of the hardware. In all cases, you might gain performance",
- "by optimizing [TT]-npme[tt]. Performance statistics on this issue",
- "are written at the end of the log file.",
- "For good load balancing at high parallelization, the PME grid x and y",
- "dimensions should be divisible by the number of PME ranks",
- "(the simulation will run correctly also when this is not the case).",
- "[PAR]",
- "This section lists all options that affect the domain decomposition.",
- "[PAR]",
- "Option [TT]-rdd[tt] can be used to set the required maximum distance",
- "for inter charge-group bonded interactions.",
- "Communication for two-body bonded interactions below the non-bonded",
- "cut-off distance always comes for free with the non-bonded communication.",
- "Atoms beyond the non-bonded cut-off are only communicated when they have",
- "missing bonded interactions; this means that the extra cost is minor",
- "and nearly indepedent of the value of [TT]-rdd[tt].",
- "With dynamic load balancing option [TT]-rdd[tt] also sets",
- "the lower limit for the domain decomposition cell sizes.",
- "By default [TT]-rdd[tt] is determined by [TT]mdrun[tt] based on",
- "the initial coordinates. The chosen value will be a balance",
- "between interaction range and communication cost.",
- "[PAR]",
- "When inter charge-group bonded interactions are beyond",
- "the bonded cut-off distance, [TT]mdrun[tt] terminates with an error message.",
- "For pair interactions and tabulated bonds",
- "that do not generate exclusions, this check can be turned off",
- "with the option [TT]-noddcheck[tt].",
- "[PAR]",
- "When constraints are present, option [TT]-rcon[tt] influences",
- "the cell size limit as well.",
- "Atoms connected by NC constraints, where NC is the LINCS order plus 1,",
- "should not be beyond the smallest cell size. A error message is",
- "generated when this happens and the user should change the decomposition",
- "or decrease the LINCS order and increase the number of LINCS iterations.",
- "By default [TT]mdrun[tt] estimates the minimum cell size required for P-LINCS",
- "in a conservative fashion. For high parallelization it can be useful",
- "to set the distance required for P-LINCS with the option [TT]-rcon[tt].",
- "[PAR]",
- "The [TT]-dds[tt] option sets the minimum allowed x, y and/or z scaling",
- "of the cells with dynamic load balancing. [TT]mdrun[tt] will ensure that",
- "the cells can scale down by at least this factor. This option is used",
- "for the automated spatial decomposition (when not using [TT]-dd[tt])",
- "as well as for determining the number of grid pulses, which in turn",
- "sets the minimum allowed cell size. Under certain circumstances",
- "the value of [TT]-dds[tt] might need to be adjusted to account for",
- "high or low spatial inhomogeneity of the system.",
- "[PAR]",
- "The option [TT]-gcom[tt] can be used to only do global communication",
- "every n steps.",
- "This can improve performance for highly parallel simulations",
- "where this global communication step becomes the bottleneck.",
- "For a global thermostat and/or barostat the temperature",
- "and/or pressure will also only be updated every [TT]-gcom[tt] steps.",
- "By default it is set to the minimum of nstcalcenergy and nstlist.[PAR]",
- "With [TT]-rerun[tt] an input trajectory can be given for which ",
- "forces and energies will be (re)calculated. Neighbor searching will be",
- "performed for every frame, unless [TT]nstlist[tt] is zero",
- "(see the [TT].mdp[tt] file).[PAR]",
+ "Running mdrun efficiently in parallel is a complex topic topic,",
+ "many aspects of which are covered in the online User Guide. You",
+ "should look there for practical advice on using many of the options",
+ "available in mdrun.[PAR]",
"ED (essential dynamics) sampling and/or additional flooding potentials",
"are switched on by using the [TT]-ei[tt] flag followed by an [TT].edi[tt]",
"file. The [TT].edi[tt] file can be produced with the [TT]make_edi[tt] tool",
"The options [TT]-px[tt] and [TT]-pf[tt] are used for writing pull COM",
"coordinates and forces when pulling is selected",
"in the [TT].mdp[tt] file.[PAR]",
- "With [TT]-multi[tt] or [TT]-multidir[tt], multiple systems can be ",
- "simulated in parallel.",
- "As many input files/directories are required as the number of systems. ",
- "The [TT]-multidir[tt] option takes a list of directories (one for each ",
- "system) and runs in each of them, using the input/output file names, ",
- "such as specified by e.g. the [TT]-s[tt] option, relative to these ",
- "directories.",
- "With [TT]-multi[tt], the system number is appended to the run input ",
- "and each output filename, for instance [TT]topol.tpr[tt] becomes",
- "[TT]topol0.tpr[tt], [TT]topol1.tpr[tt] etc.",
- "The number of ranks per system is the total number of ranks",
- "divided by the number of systems.",
- "One use of this option is for NMR refinement: when distance",
- "or orientation restraints are present these can be ensemble averaged",
- "over all the systems.[PAR]",
- "With [TT]-replex[tt] replica exchange is attempted every given number",
- "of steps. The number of replicas is set with the [TT]-multi[tt] or ",
- "[TT]-multidir[tt] option, described above.",
- "All run input files should use a different coupling temperature,",
- "the order of the files is not important. The random seed is set with",
- "[TT]-reseed[tt]. The velocities are scaled and neighbor searching",
- "is performed after every exchange.[PAR]",
"Finally some experimental algorithms can be tested when the",
"appropriate options have been given. Currently under",
"investigation are: polarizability.",
biod.pnpi.spb.ru / alexxy / gromacs.git / commitdiff