Commit dfc6389b authored by Nicholas Breen's avatar Nicholas Breen

Update upstream source from tag 'upstream/2018_rc1'

Update to upstream version '2018_rc1'
with Debian dir 96c939493f7dece0bce639162cbdfdd2f5bda6e5
parents 299b3d17 df69c7b3
......@@ -5,7 +5,7 @@ Installation guide
Introduction to building GROMACS
================================
These instructions pertain to building GROMACS 2018-beta3. You might
These instructions pertain to building GROMACS 2018-rc1. You might
also want to check the up-to-date installation instructions.
......@@ -28,8 +28,8 @@ Quick and dirty installation
Or, as a sequence of commands to execute:
tar xfz gromacs-2018-beta3.tar.gz
cd gromacs-2018-beta3
tar xfz gromacs-2018-rc1.tar.gz
cd gromacs-2018-rc1
mkdir build
cd build
cmake .. -DGMX_BUILD_OWN_FFTW=ON -DREGRESSIONTEST_DOWNLOAD=ON
......@@ -149,7 +149,7 @@ offer competitive performance. We recommend against PGI because the
performance with C++ is very bad.
The xlc compiler is not supported and has not been tested on POWER
architectures for GROMACS-2018-beta3. We recommend to use the gcc
architectures for GROMACS-2018-rc1. We recommend to use the gcc
compiler instead, as it is being extensively tested.
You may also need the most recent version of other compiler toolchain
......@@ -413,8 +413,8 @@ the name of the directory containing the "CMakeLists.txt" file of the
code you want to build. For example, download the source tarball and
use
tar xfz gromacs-2018-beta3.tgz
cd gromacs-2018-beta3
tar xfz gromacs-2018-rc1.tgz
cd gromacs-2018-rc1
mkdir build-gromacs
cd build-gromacs
cmake ..
......@@ -650,18 +650,18 @@ details can be found at this NVIDIA blog post. NVML support is only
available if detected, and may be disabled by turning off the
"GMX_USE_NVML" CMake advanced option.
By default, optimized code will be generated for CUDA architectures
supported by the nvcc compiler (and the GROMACS build system).
However, it can be beneficial to manually pick the specific CUDA
architecture(s) to generate code for either to reduce compilation time
(and binary size) or to target a new architecture not yet supported by
the GROMACS build system. Setting the desired CUDA architecture(s) and
virtual architecture(s) can be done using the "GMX_CUDA_TARGET_SM" and
"GMX_CUDA_TARGET_COMPUTE" variables, respectively. These take a
semicolon delimited string with the two digit suffixes of CUDA
(virtual) architectures names (for details see the “Options for
steering GPU code generation” section of the nvcc man / help or
Chapter 6. of the nvcc manual).
By default, code will be generated for the most common CUDA
architectures. However, to reduce build time and binary size we do not
generate code for every single possible architecture, which in rare
cases (say, Tegra systems) can result in the default build not being
able to use some GPUs. If this happens, or if you want to remove some
architectures to reduce binary size and build time, you can alter the
target CUDA architectures. This can be done either with the
"GMX_CUDA_TARGET_SM" or "GMX_CUDA_TARGET_COMPUTE" CMake variables,
which take a semicolon delimited string with the two digit suffixes of
CUDA (virtual) architectures names, for instance “35;50;51;52;53;60”.
For details, see the “Options for steering GPU code generation”
section of the nvcc man / help or Chapter 6. of the nvcc manual.
The GPU acceleration has been tested on AMD64/x86-64 platforms with
Linux, Mac OS X and Windows operating systems, but Linux is the best-
......@@ -968,7 +968,7 @@ The simplest way to run the checks is to build GROMACS with
"-DREGRESSIONTEST_DOWNLOAD", and run "make check". GROMACS will
automatically download and run the tests for you. Alternatively, you
can download and unpack the GROMACS regression test suite
http://gerrit.gromacs.org/download/regressiontests-2018-beta3.tar.gz
http://gerrit.gromacs.org/download/regressiontests-2018-rc1.tar.gz
tarball yourself and use the advanced "cmake" option
"REGRESSIONTEST_PATH" to specify the path to the unpacked tarball,
which will then be used for testing. If the above does not work, then
......
......@@ -18,12 +18,15 @@ gcc-4.8 simd=ARM_NEON release-with-assert
gcc-5 simd=ARM_NEON_ASIMD release-with-assert
# Test the mdrun-only build
# Test newest gcc at time of release
# TODO In combination with gmx from another build, arrange to run regressiontests
clang-3.7 double mpi no-openmp fftpack mdrun-only
gcc-7 mpi no-openmp fftpack mdrun-only
# Test MPMD PME with thread-MPI
# TODO Add double to this configuration if/when we stablize the essentialdynamics tests
gcc-7 npme=1 nranks=2 no-openmp fftpack release-with-assert
# Test newest icc at time of release
# Test icc without SIMD in double precision in release mode
# TODO enable simd=avx_256 in this config, and change the above description once #2335 is resolved
icc-18 npme=1 nranks=2 no-openmp double fftpack release simd=none
# Test non-default GMX_PREFER_STATIC_LIBS behavior
# TODO enable this
......
......@@ -29,23 +29,26 @@ gcc-4.8 gpu cuda-6.5 cmake-3.8.1 mpi npme=1 nranks=2 openmp
# Test SIMD implementation of pair search for GPU code-path
gcc-5 gpu cuda-8.0 thread-mpi openmp cmake-3.6.1 release-with-assert simd=avx2_256
# Test newest cmake at time of release
# Test with ThreadSanitizer (compiled without OpenMP, even though
# this gcc was configured with --disable-linux-futex, because
# Redmine #1850 is unresolved, which causes more suspected
# false positives than races detected)
# Test fftpack fallback
gcc-7 tsan no-openmp fftpack
gcc-7 tsan no-openmp fftpack cmake-3.10.0
# Test newest gcc at time of release
gcc-7 mpi
# Test gcc in double precision
# Test 128-bit SIMD in double precision (to cover SimdInt32 support better)
gcc-7 double mpi simd=avx_128_fma
# Test on MacOS (because gcc-6 is only available there)
# Test X11 build
gcc-6 double x11
gcc-6 x11
# Test oldest supported cmake
# Test older clang
# Test double precision
# Test clang in double precision
# Test without OpenMP
# Test thread-MPI
# Test AVX_128_FMA SIMD + Double (Important for Simd4N=Simd4 and sizeof(SimdInt32)!=4*GMX_SIMD_REAL_WIDTH)
......@@ -61,28 +64,32 @@ msvc-2015 openmp release-with-assert
# Test oldest supported icc
# Test icc on Windows
icc-16 msvc-2015 fftpack
# Test icc with SIMD in mixed precision in release mode
icc-16 msvc-2015 fftpack simd=avx2_256 release
# Test newest cmake at time of release
# Test newest icc at the time of release
# Test icc without SIMD in double precision in release mode
# Test MKL
# Test without any MPI
# Test on CentOS (because icc-18.0 is only available there)
icc-18 no-thread-mpi openmp mkl cmake-3.10.0 simd=avx_256
# Test on CentOS (because cmake-3.9.6 is available there)
icc-18 no-thread-mpi double openmp mkl cmake-3.9.6 simd=none release
# Test NVIDIA OpenCL
# Test MPI + OpenCL
# Test AVX2_256 SIMD
gcc-4.8 openmp opencl cuda-7.5 mpi release-with-assert simd=avx2_256
# Test icc with SIMD in mixed precision in release mode
icc-18 openmp opencl cuda-7.5 mpi release simd=avx2_256
# Test AMD OpenCL
# Test AVX_128_FMA SIMD
gcc-5 openmp simd=avx_128_fma opencl amdappsdk-3.0
# TODO
# Add support for CUDA 9.0
# Add OpenMP support to ASAN build (but libomp.so in clang-4 reports leaks, so might need a suitable build or suppression)
# Test hwloc support
# Test newest supported LTS Ubuntu
# Update gpu testing specifiers per https://redmine.gromacs.org/issues/2161
# Resolve Redmine #1850 so that ThreadSanitizer can test our OpenMP code
# Support icc 17
# Test AVX-512 when hardware is available
......@@ -68,8 +68,11 @@ if(${GMX_FFT_LIBRARY} STREQUAL "FFTW3")
if(GMX_BUILD_OWN_FFTW)
if(WIN32)
message(FATAL_ERROR "Cannot build FFTW3 automatically (GMX_BUILD_OWN_FFTW=ON) on Windows")
if(MSVC)
message(FATAL_ERROR "Cannot build FFTW3 automatically (GMX_BUILD_OWN_FFTW=ON) in Visual Studio")
endif()
if(CMAKE_GENERATOR STREQUAL "Ninja")
message(FATAL_ERROR "Cannot build FFTW3 automatically (GMX_BUILD_OWN_FFTW=ON) with ninja")
endif()
add_subdirectory(src/contrib/fftw)
......
......@@ -39,6 +39,8 @@
# - if CUDA is not found but GPUs were detected issue a warning
if (NOT DEFINED GMX_GPU)
set(GMX_GPU_AUTO TRUE CACHE INTERNAL "GPU acceleration will be selected automatically")
else()
set(GMX_GPU_AUTO FALSE CACHE INTERNAL "GPU acceleration will be selected automatically")
endif()
option(GMX_GPU "Enable GPU acceleration" OFF)
......
......@@ -191,7 +191,7 @@ set(GMX_VERSION_PATCH 0)
# candidates, where it signifies the most recent such release from
# this branch; it will be empty before the first such release, as well
# as after the final release is out.
set(GMX_VERSION_SUFFIX "-beta3")
set(GMX_VERSION_SUFFIX "-rc1")
# Conventionally with libtool, any ABI change must change the major
# version number, the minor version number should change if it's just
......@@ -226,7 +226,7 @@ endif()
set(REGRESSIONTEST_VERSION "${GMX_VERSION_STRING}")
set(REGRESSIONTEST_BRANCH "refs/heads/release-2018")
set(REGRESSIONTEST_MD5SUM "c43d6db286ae52696ac595c43b081c23" CACHE INTERNAL "MD5 sum of the regressiontests tarball")
set(REGRESSIONTEST_MD5SUM "d4c535a06fd8f34c9fd21e7ee5a30808" CACHE INTERNAL "MD5 sum of the regressiontests tarball")
math(EXPR GMX_VERSION_NUMERIC
"${GMX_VERSION_MAJOR}*10000 + ${GMX_VERSION_PATCH}")
......
Physical validation
===================
Physical validation tests check whether simulation results correspond
to physical (or mathematical) expectations.
Unlike the existing tests, we are not be able to keep these tests in
the "seconds, not minutes" time frame, rather aiming for "hours, not
days". They should therefore be ran periodically, but probably not
for every build.
Also, given the long run time, it will in many cases be necessary to
separate running of the systems (e.g. to run it at a specific time, or
on a different resource), such that the make script does give the
option to
* prepare run files and an execution script,
* analyze already present simulations,
* or prepare, run and analyze in one go.
Test description
----------------
Currently, simulation results are tested against three physically /
mathematically expected results:
* *Integrator convergence*: A symplectic integrator can be shown to
conserve a constant of motion (such as the energy in a
micro-canonical simulation) up to a fluctuation that is quadratic in
time step chosen. Comparing two or more constant-of-motion
trajectories realized using different time steps (but otherwise
unchanged simulation parameters) allows a check of the symplecticity
of the integration. Note that lack of symplecticity does not
necessarily imply an error in the integration algorithm, it can also
hint at physical violations in other parts of the model, such as
non-continuous potential functions, imprecise handling of
constraints, etc.
* *Kinetic energy distribution*: The kinetic energy trajectory of a
(equilibrated) system sampling a canonical or an isothermal-isobaric
ensemble is expected to be Maxwell-Boltzmann distributed. The
similarity between the physically expected and the observed
distribution allows to validate the sampled kinetic energy ensemble.
* *Distribution of configurational quantities*: As the distribution of
configurational quantities like the potential energy or the volume
are in general not known analytically, testing the likelihood of a
trajectory sampling a given ensemble is less straightforward than
for the kinetic energy. However, generally, the ratio of the
probability distribution between samples of the same ensemble at
different state points (e.g. at different temperatures, different
pressures) is known. Comparing two simulations at different state
points therefore allows a validation of the sampled ensemble.
The physical validation included in GROMACS tests a range of the
most-used settings on several systems. The general philosophy is to
leave most settings to default values with the exception of the ones
explicitly tested in order to be sensitive to changes in the default
values. The test set will be enlarged as we discover interesting test
systems and corner cases. Under double precision, some additional
tests are ran, and some other tests are ran using a lower tolerance.
Integrator convergence
^^^^^^^^^^^^^^^^^^^^^^
All simulations performed under NVE on Argon (1000 atoms) and water
(900 molecules) systems. As these tests are very sensitive to
numerical imprecision, they are performed with long-range corrections
for both Lennard-Jones and electrostatic interactions, with a very low
pair-list tolerance (``verlet-buffer-tolerance = 1e-10``), and high
LINCS settings where applicable.
**Argon**:
* *Integrators*:
- ``integrator = md``
- ``integrator = md-vv``
* *Long-range corrections LJ*:
- ``vdwtype = PME``
- ``vdwtype = cut-off``, ``vdw-modifier = force-switch``,
``rvdw-switch = 0.8``
**Water**:
* *Integrators*:
- ``integrator = md``
- ``integrator = md-vv``
* *Long-range corrections LJ*:
- ``vdwtype = PME``
- ``vdwtype = cut-off``, ``vdw-modifier = force-switch``,
``rvdw-switch = 0.8``
* *Long-range corrections electrostatics*:
- ``coulombtype = PME``, ``fourierspacing = 0.05``
* *Constraint algorithms*:
- ``constraint-algorithm = lincs``, ``lincs-order = 6``,
``lincs-iter = 2``
- ``constraint-algorithm = none``
- SETTLE
Ensemble tests
^^^^^^^^^^^^^^
The generated ensembles are tested with Argon (1000 atoms) and water
(900 molecules, with SETTLE and PME) systems, in the following
combinations:
* ``integrator = md``, ``tcoupl = v-rescale``, ``tau-t = 0.1``,
``ref-t = 87.0`` (Argon) or ``ref-t = 298.15`` (Water)
* ``integrator = md``, ``tcoupl = v-rescale``, ``tau-t = 0.1``,
``ref-t = 87.0`` (Argon) or ``ref-t = 298.15`` (Water), ``pcoupl =
parrinello-rahman``, ``ref-p = 1.0``, ``compressibility = 4.5e-5``
* ``integrator = md-vv``, ``tcoupl = v-rescale``, ``tau-t = 0.1``,
``ref-t = 87.0`` (Argon) or ``ref-t = 298.15`` (Water)
* ``integrator = md-vv``, ``tcoupl = nose-hoover``, ``tau-t = 1.0``,
``ref-t = 87.0`` (Argon) or ``ref-t = 298.15`` (Water), ``pcoupl =
mttk``, ``ref-p = 1.0``, ``compressibility = 4.5e-5``
All thermostats are applied to the entire system (``tc-grps =
system``). The simulations run for 1ns at 2fs time step with Verlet
cut-off. All other settings left to default values.
Building and testing using the build system
-------------------------------------------
Since these tests can not be ran at the same frequency as the current
tests, they are kept strictly opt-in via
``-DGMX_PHYSICAL_VALIDATION=ON``, with
``-DGMX_PHYSICAL_VALIDATION=OFF`` being the default. Independently of
that, all previously existing build targets are unchanged, including
``make check``.
If physical validation is turned on, a number of additional make
targets can be used:
* ``make check`` is unchanged, it builds the main binaries and the unit
tests, then runs the unit tests and, if available, the regression
tests.
* ``make check-phys`` builds the main binaries, then runs the physical
validation tests. **Warning**: This requires to simulate all systems
and might take several hours on a average machine!
* ``make check-all`` combines ``make check`` and ``make check-phys``.
As the simulations needed to perform the physical validation tests may
take long, it might be advantageous to run them on an external
resource. To enable this, two additional make targets are present:
* ``make check-phys-prepare`` prepares all simulation files under
``tests/physicalvalidation`` of the build directory, as well as a
rudimentary run script in the same directory.
* ``make check-phys-analyze`` runs the same tests as ``make
check-phys``, but does not simulate the systems. Instead, this
target assumes that the results can be found under
``tests/physicalvalidation`` of the build directory.
The intended usage of these additional targets is to prepare the
simulation files, then run them on a different resource or at a
different time, and later analyze them. If you want to use this, be
aware *(i)* that the run script generated is very simple and might
need (considerable) tuning to work with your setup, and *(ii)* that
the analysis script is sensitive to the folder structure, so make sure
to preserve it when copying the results to / from another resource.
Additionally to the mentioned make targets, a number of internal make
targets are defined. These are not intended to be used directly, but
are necessary to support the functionality described above, especially
the complex dependencies. These internal targets include
``run-ctest``, ``run-ctest-nophys``, ``run-ctest-phys`` and
``run-ctest-phys-analyze`` running the different tests,
``run-physval-sims`` running the simulations for physical validation,
and ``missing-tests-notice``, ``missing-tests-notice-all``,
``missing-phys-val-phys``, ``missing-phys-val-phys-analyze`` and
``missing-phys-val-all`` notifying users about missing tests.
Direct usage of the python script
---------------------------------
The ``make`` commands mentioned above are calling the python script
``tests/physicalvalidation/gmx_physicalvalidation.py``, which can be
used independently of the make system. Use the ``-h`` flag for the
general usage information, and the ``--tests`` for more details on the
available physical validations.
The script requires a ``json`` file defining the tests as an input.
Among other options, it allows to define the GROMACS binary and the
working directory to be used, and to decide whether to only prepare
the simulations, prepare and run the simulations, only analyze the
simulations, or do all three steps at once.
Adding new tests
----------------
The available tests are listed in the ``systems.json`` (tests
standardly used for single precision builds) and ``systems_d.json``
(tests standardly used for double precision builds) files in the same
directory, the GROMACS files are in the folder ``systems/``.
The ``json`` files lists the different test. Each test has a
``"name"`` attribute, which needs to be unique, a ``"dir"`` attribute,
which denotes the directory of the system (inside the ``systems/``
directory) to be tested, and a ``"test"`` attribute which lists the
validations to be performed on the system. Additionally, the optional
``"grompp_args"`` and ``"mdrun_args"`` attributes allow to pass
specific arguments to ``gmx grompp`` or ``gmx mdrun``, respectively. A
single test can contain several validations, and several independent
tests can be performed on the same input files.
To add a new test to a present system, add the test name and the
arguments to the ``json`` file(s). To use a new system, add a
subfolder in the ``systems/`` directory containing
``input/system.{gro,mdp,top}`` files defining your system.
......@@ -601,17 +601,18 @@ this `NVIDIA blog post
NVML support is only available if detected, and may be disabled by
turning off the ``GMX_USE_NVML`` CMake advanced option.
By default, optimized code will be generated for CUDA architectures
supported by the nvcc compiler (and the |Gromacs| build system).
However, it can be beneficial to manually pick the specific CUDA architecture(s)
to generate code for either to reduce compilation time (and binary size) or to
target a new architecture not yet supported by the |Gromacs| build system.
Setting the desired CUDA architecture(s) and virtual architecture(s)
can be done using the ``GMX_CUDA_TARGET_SM`` and ``GMX_CUDA_TARGET_COMPUTE``
variables, respectively. These take a semicolon delimited string with
the two digit suffixes of CUDA (virtual) architectures names
(for details see the "Options for steering GPU code generation" section of the
nvcc man / help or Chapter 6. of the nvcc manual).
By default, code will be generated for the most common CUDA architectures.
However, to reduce build time and binary size we do not generate code for
every single possible architecture, which in rare cases (say, Tegra systems)
can result in the default build not being able to use some GPUs.
If this happens, or if you want to remove some architectures to reduce
binary size and build time, you can alter the target CUDA architectures.
This can be done either with the ``GMX_CUDA_TARGET_SM`` or
``GMX_CUDA_TARGET_COMPUTE`` CMake variables, which take a semicolon delimited
string with the two digit suffixes of CUDA (virtual) architectures names, for
instance "35;50;51;52;53;60". For details, see the "Options for steering GPU
code generation" section of the nvcc man / help or Chapter 6. of the nvcc
manual.
The GPU acceleration has been tested on AMD64/x86-64 platforms with
Linux, Mac OS X and Windows operating systems, but Linux is the
......
.\" Man page generated from reStructuredText.
.
.TH "GMX-ANADOCK" "1" "Dec 19, 2017" "2018-beta3" "GROMACS"
.TH "GMX-ANADOCK" "1" "Dec 27, 2017" "2018-rc1" "GROMACS"
.SH NAME
gmx-anadock \- Cluster structures from Autodock runs
.
......
.\" Man page generated from reStructuredText.
.
.TH "GMX-ANAEIG" "1" "Dec 19, 2017" "2018-beta3" "GROMACS"
.TH "GMX-ANAEIG" "1" "Dec 27, 2017" "2018-rc1" "GROMACS"
.SH NAME
gmx-anaeig \- Analyze eigenvectors/normal modes
.
......
.\" Man page generated from reStructuredText.
.
.TH "GMX-ANALYZE" "1" "Dec 19, 2017" "2018-beta3" "GROMACS"
.TH "GMX-ANALYZE" "1" "Dec 27, 2017" "2018-rc1" "GROMACS"
.SH NAME
gmx-analyze \- Analyze data sets
.
......
.\" Man page generated from reStructuredText.
.
.TH "GMX-ANGLE" "1" "Dec 19, 2017" "2018-beta3" "GROMACS"
.TH "GMX-ANGLE" "1" "Dec 27, 2017" "2018-rc1" "GROMACS"
.SH NAME
gmx-angle \- Calculate distributions and correlations for angles and dihedrals
.
......
.\" Man page generated from reStructuredText.
.
.TH "GMX-AWH" "1" "Dec 19, 2017" "2018-beta3" "GROMACS"
.TH "GMX-AWH" "1" "Dec 27, 2017" "2018-rc1" "GROMACS"
.SH NAME
gmx-awh \- Extract data from an accelerated weight histogram (AWH) run
.
......
.\" Man page generated from reStructuredText.
.
.TH "GMX-BAR" "1" "Dec 19, 2017" "2018-beta3" "GROMACS"
.TH "GMX-BAR" "1" "Dec 27, 2017" "2018-rc1" "GROMACS"
.SH NAME
gmx-bar \- Calculate free energy difference estimates through Bennett's acceptance ratio
.
......
.\" Man page generated from reStructuredText.
.
.TH "GMX-BUNDLE" "1" "Dec 19, 2017" "2018-beta3" "GROMACS"
.TH "GMX-BUNDLE" "1" "Dec 27, 2017" "2018-rc1" "GROMACS"
.SH NAME
gmx-bundle \- Analyze bundles of axes, e.g., helices
.
......
.\" Man page generated from reStructuredText.
.
.TH "GMX-CHECK" "1" "Dec 19, 2017" "2018-beta3" "GROMACS"
.TH "GMX-CHECK" "1" "Dec 27, 2017" "2018-rc1" "GROMACS"
.SH NAME
gmx-check \- Check and compare files
.
......
.\" Man page generated from reStructuredText.
.
.TH "GMX-CHI" "1" "Dec 19, 2017" "2018-beta3" "GROMACS"
.TH "GMX-CHI" "1" "Dec 27, 2017" "2018-rc1" "GROMACS"
.SH NAME
gmx-chi \- Calculate everything you want to know about chi and other dihedrals
.
......
.\" Man page generated from reStructuredText.
.
.TH "GMX-CLUSTER" "1" "Dec 19, 2017" "2018-beta3" "GROMACS"
.TH "GMX-CLUSTER" "1" "Dec 27, 2017" "2018-rc1" "GROMACS"
.SH NAME
gmx-cluster \- Cluster structures
.
......
.\" Man page generated from reStructuredText.
.
.TH "GMX-CLUSTSIZE" "1" "Dec 19, 2017" "2018-beta3" "GROMACS"
.TH "GMX-CLUSTSIZE" "1" "Dec 27, 2017" "2018-rc1" "GROMACS"
.SH NAME
gmx-clustsize \- Calculate size distributions of atomic clusters
.
......
.\" Man page generated from reStructuredText.
.
.TH "GMX-CONFRMS" "1" "Dec 19, 2017" "2018-beta3" "GROMACS"
.TH "GMX-CONFRMS" "1" "Dec 27, 2017" "2018-rc1" "GROMACS"
.SH NAME
gmx-confrms \- Fit two structures and calculates the RMSD
.
......
.\" Man page generated from reStructuredText.
.
.TH "GMX-CONVERT-TPR" "1" "Dec 19, 2017" "2018-beta3" "GROMACS"
.TH "GMX-CONVERT-TPR" "1" "Dec 27, 2017" "2018-rc1" "GROMACS"
.SH NAME
gmx-convert-tpr \- Make a modifed run-input file
.
......
.\" Man page generated from reStructuredText.
.
.TH "GMX-COVAR" "1" "Dec 19, 2017" "2018-beta3" "GROMACS"
.TH "GMX-COVAR" "1" "Dec 27, 2017" "2018-rc1" "GROMACS"
.SH NAME
gmx-covar \- Calculate and diagonalize the covariance matrix
.
......
.\" Man page generated from reStructuredText.
.
.TH "GMX-CURRENT" "1" "Dec 19, 2017" "2018-beta3" "GROMACS"
.TH "GMX-CURRENT" "1" "Dec 27, 2017" "2018-rc1" "GROMACS"
.SH NAME
gmx-current \- Calculate dielectric constants and current autocorrelation function
.
......
.\" Man page generated from reStructuredText.
.
.TH "GMX-DENSITY" "1" "Dec 19, 2017" "2018-beta3" "GROMACS"
.TH "GMX-DENSITY" "1" "Dec 27, 2017" "2018-rc1" "GROMACS"
.SH NAME
gmx-density \- Calculate the density of the system
.
......
.\" Man page generated from reStructuredText.
.
.TH "GMX-DENSMAP" "1" "Dec 19, 2017" "2018-beta3" "GROMACS"
.TH "GMX-DENSMAP" "1" "Dec 27, 2017" "2018-rc1" "GROMACS"
.SH NAME
gmx-densmap \- Calculate 2D planar or axial-radial density maps
.
......
.\" Man page generated from reStructuredText.
.
.TH "GMX-DENSORDER" "1" "Dec 19, 2017" "2018-beta3" "GROMACS"
.TH "GMX-DENSORDER" "1" "Dec 27, 2017" "2018-rc1" "GROMACS"
.SH NAME
gmx-densorder \- Calculate surface fluctuations
.
......
.\" Man page generated from reStructuredText.
.
.TH "GMX-DIELECTRIC" "1" "Dec 19, 2017" "2018-beta3" "GROMACS"
.TH "GMX-DIELECTRIC" "1" "Dec 27, 2017" "2018-rc1" "GROMACS"
.SH NAME
gmx-dielectric \- Calculate frequency dependent dielectric constants
.
......
.\" Man page generated from reStructuredText.
.
.TH "GMX-DIPOLES" "1" "Dec 19, 2017" "2018-beta3" "GROMACS"
.TH "GMX-DIPOLES" "1" "Dec 27, 2017" "2018-rc1" "GROMACS"
.SH NAME
gmx-dipoles \- Compute the total dipole plus fluctuations
.
......
.\" Man page generated from reStructuredText.
.
.TH "GMX-DISRE" "1" "Dec 19, 2017" "2018-beta3" "GROMACS"
.TH "GMX-DISRE" "1" "Dec 27, 2017" "2018-rc1" "GROMACS"
.SH NAME
gmx-disre \- Analyze distance restraints
.
......
.\" Man page generated from reStructuredText.
.
.TH "GMX-DISTANCE" "1" "Dec 19, 2017" "2018-beta3" "GROMACS"
.TH "GMX-DISTANCE" "1" "Dec 27, 2017" "2018-rc1" "GROMACS"
.SH NAME
gmx-distance \- Calculate distances between pairs of positions
.
......
.\" Man page generated from reStructuredText.
.
.TH "GMX-DO_DSSP" "1" "Dec 19, 2017" "2018-beta3" "GROMACS"
.TH "GMX-DO_DSSP" "1" "Dec 27, 2017" "2018-rc1" "GROMACS"
.SH NAME
gmx-do_dssp \- Assign secondary structure and calculate solvent accessible surface area
.
......
.\" Man page generated from reStructuredText.
.
.TH "GMX-DOS" "1" "Dec 19, 2017" "2018-beta3" "GROMACS"
.TH "GMX-DOS" "1" "Dec 27, 2017" "2018-rc1" "GROMACS"
.SH NAME
gmx-dos \- Analyze density of states and properties based on that
.
......
.\" Man page generated from reStructuredText.
.
.TH "GMX-DUMP" "1" "Dec 19, 2017" "2018-beta3" "GROMACS"
.TH "GMX-DUMP" "1" "Dec 27, 2017" "2018-rc1" "GROMACS"
.SH NAME
gmx-dump \- Make binary files human readable
.
......
.\" Man page generated from reStructuredText.
.
.TH "GMX-DYECOUPL" "1" "Dec 19, 2017" "2018-beta3" "GROMACS"
.TH "GMX-DYECOUPL" "1" "Dec 27, 2017" "2018-rc1" "GROMACS"
.SH NAME
gmx-dyecoupl \- Extract dye dynamics from trajectories
.
......
.\" Man page generated from reStructuredText.
.
.TH "GMX-DYNDOM" "1" "Dec 19, 2017" "2018-beta3" "GROMACS"
.TH "GMX-DYNDOM" "1" "Dec 27, 2017" "2018-rc1" "GROMACS"
.SH NAME
gmx-dyndom \- Interpolate and extrapolate structure rotations
.
......
.\" Man page generated from reStructuredText.
.
.TH "GMX-EDITCONF" "1" "Dec 19, 2017" "2018-beta3" "GROMACS"
.TH "GMX-EDITCONF" "1" "Dec 27, 2017" "2018-rc1" "GROMACS"
.SH NAME
gmx-editconf \- Convert and manipulates structure files
.
......
.\" Man page generated from reStructuredText.
.
.TH "GMX-ENECONV" "1" "Dec 19, 2017" "2018-beta3" "GROMACS"
.TH "GMX-ENECONV" "1" "Dec 27, 2017" "2018-rc1" "GROMACS"
.SH NAME
gmx-eneconv \- Convert energy files
.
......
.\" Man page generated from reStructuredText.
.
.TH "GMX-ENEMAT" "1" "Dec 19, 2017" "2018-beta3" "GROMACS"
.TH "GMX-ENEMAT" "1" "Dec 27, 2017" "2018-rc1" "GROMACS"
.SH NAME
gmx-enemat \- Extract an energy matrix from an energy file
.
......