On a cluster where users are expected to be running across multiple
nodes using MPI, make one installation similar to the above, and
-another using an MPI wrapper compiler and which is `building only
-mdrun`_, because that is the only component of |Gromacs| that uses
-MPI. The latter will install a single simulation engine binary,
-i.e. ``mdrun_mpi`` when the default suffix is used. Hence it is safe
+another using ``-DGMX_MPI=on``.
+The latter will install binaries and libraries named using
+a default suffix of ``_mpi`` ie ``gmx_mpi``. Hence it is safe
and common practice to install this into the same location where
the non-MPI build is installed.
appropriate value instead of ``xxx`` :
* ``-DCMAKE_C_COMPILER=xxx`` equal to the name of the C99 `Compiler`_ you wish to use (or the environment variable ``CC``)
-* ``-DCMAKE_CXX_COMPILER=xxx`` equal to the name of the C++98 `compiler`_ you wish to use (or the environment variable ``CXX``)
-* ``-DGMX_MPI=on`` to build using `MPI support`_ (generally good to combine with `building only mdrun`_)
-* ``-DGMX_GPU=on`` to build using nvcc to run using NVIDIA `CUDA GPU acceleration`_ or an OpenCL_ GPU
-* ``-DGMX_USE_OPENCL=on`` to build with OpenCL_ support enabled. ``GMX_GPU`` must also be set.
+* ``-DCMAKE_CXX_COMPILER=xxx`` equal to the name of the C++17 `compiler`_ you wish to use (or the environment variable ``CXX``)
+* ``-DGMX_MPI=on`` to build using `MPI support`_
+* ``-DGMX_GPU=CUDA`` to build with NVIDIA CUDA support enabled.
+* ``-DGMX_GPU=OpenCL`` to build with OpenCL_ support enabled.
* ``-DGMX_SIMD=xxx`` to specify the level of `SIMD support`_ of the node on which |Gromacs| will run
-* ``-DGMX_BUILD_MDRUN_ONLY=on`` for `building only mdrun`_, e.g. for compute cluster back-end nodes
* ``-DGMX_DOUBLE=on`` to build |Gromacs| in double precision (slower, and not normally useful)
* ``-DCMAKE_PREFIX_PATH=xxx`` to add a non-standard location for CMake to `search for libraries, headers or programs`_
* ``-DCMAKE_INSTALL_PREFIX=xxx`` to install |Gromacs| to a `non-standard location`_ (default ``/usr/local/gromacs``)
|Gromacs| can be compiled for many operating systems and
architectures. These include any distribution of Linux, Mac OS X or
Windows, and architectures including x86, AMD64/x86-64, several
-PowerPC including POWER8, ARM v7, ARM v8, and SPARC VIII.
+PowerPC including POWER8, ARM v8, and SPARC VIII.
Compiler
^^^^^^^^
-|Gromacs| can be compiled on any platform with ANSI C99 and C++11
+|Gromacs| can be compiled on any platform with ANSI C99 and C++17
compilers, and their respective standard C/C++ libraries. Good
performance on an OS and architecture requires choosing a good
compiler. We recommend gcc, because it is free, widely available and
frequently provides the best performance.
You should strive to use the most recent version of your
-compiler. Since we require full C++11 support the minimum supported
+compiler. Since we require full C++17 support the minimum supported
compiler versions are
-* GNU (gcc) 4.8.1
-* Intel (icc) 17.0.1
-* LLVM (clang) 3.3
-* Microsoft (MSVC) 2017 (C++14 is used)
+* GNU (gcc/libstdc++) 7
+* LLVM (clang/libc++) 8
+* Microsoft (MSVC) 2019
Other compilers may work (Cray, Pathscale, older clang) but do
not offer competitive performance. We recommend against PGI because
the performance with C++ is very bad.
+The Intel classic compiler (icc/icpc) is no longer supported in
+|Gromacs|. Use Intel's newer clang-based compiler from oneAPI, or
+gcc.
+
The xlc compiler is not supported and version 16.1 does not compile on
POWER architectures for |Gromacs|\ -\ |version|. We recommend to use
the gcc compiler instead, as it is being extensively tested.
components beside the compiler itself (e.g. assembler or linker);
these are often shipped by your OS distribution's binutils package.
-C++11 support requires adequate support in both the compiler and the
+C++17 support requires adequate support in both the compiler and the
C++ library. The gcc and MSVC compilers include their own standard
-libraries and require no further configuration. For configuration of
-other compilers, read on.
+libraries and require no further configuration. If your vendor's
+compiler also manages the standard library library via compiler flags,
+these will be honored. For configuration of other compilers, read on.
-On Linux, both the Intel and clang compiler use the libstdc++ which
+On Linux, the clang compilers use the libstdc++ which
comes with gcc as the default C++ library. For |Gromacs|, we require
-the compiler to support libstc++ version 4.8.1 or higher. To select a
-particular libstdc++ library, use:
-
-* For Intel: ``-DGMX_STDLIB_CXX_FLAGS=-gcc-name=/path/to/gcc/binary``
- or make sure that the correct gcc version is first in path (e.g. by
- loading the gcc module). It can also be useful to add
- ``-DCMAKE_CXX_LINK_FLAGS="-Wl,-rpath,/path/to/gcc/lib64
- -L/path/to/gcc/lib64"`` to ensure linking works correctly.
-* For clang:
- ``-DCMAKE_CXX_FLAGS=--gcc-toolchain=/path/to/gcc/folder``. This
- folder should contain ``include/c++``.
-
-On Windows with the Intel compiler, the MSVC standard library is used,
-and at least MSVC 2017 is required. Load the enviroment variables with
-vcvarsall.bat.
-
-To build with any compiler and clang's libcxx standard library, use
-``-DGMX_STDLIB_CXX_FLAGS=-stdlib=libc++
--DGMX_STDLIB_LIBRARIES='-lc++abi -lc++'``.
-
-If you are running on Mac OS X, the best option is the Intel
-compiler. Both clang and gcc will work, but they produce lower
-performance and each have some shortcomings. clang 3.8 now offers
-support for OpenMP, and so may provide decent performance.
+the compiler to support libstc++ version 7.1 or higher. To select a
+particular libstdc++ library, provide the path to g++ with
+``-DGMX_GPLUSPLUS_PATH=/path/to/g++``.
+
+To build with clang and llvm's libcxx standard library, use
+``-DCMAKE_CXX_FLAGS=-stdlib=libc++``.
+
+If you are running on Mac OS X, the best option is gcc. The Apple
+clang compiler provided by MacPorts will work, but does not support
+OpenMP, so will probably not provide best performance.
For all non-x86 platforms, your best option is typically to use gcc or
the vendor's default or recommended compiler, and check for
|Gromacs| has excellent support for NVIDIA GPUs supported via CUDA.
On Linux, NVIDIA CUDA_ toolkit with minimum version |REQUIRED_CUDA_VERSION|
-is required, and the latest version is strongly encouraged. Using
-Microsoft MSVC compiler requires version 9.0. NVIDIA GPUs with at
+is required, and the latest version is strongly encouraged. NVIDIA GPUs with at
least NVIDIA compute capability |REQUIRED_CUDA_COMPUTE_CAPABILITY| are
required. You are strongly recommended to
get the latest CUDA version and driver that supports your hardware, but
in order to enable this.
If you wish to run in parallel on multiple machines across a network,
-you will need to have
+you will need to have an MPI library installed that supports the MPI
+2.0 standard. That's true for any MPI library version released since
+about 2009, but the |Gromacs| team recommends the latest version (for
+best performance) of either your vendor's library, OpenMPI_ or MPICH_.
-* an MPI library installed that supports the MPI 1.3
- standard, and
-* wrapper compilers that will compile code using that library.
+To compile with MPI set your compiler to the normal (non-MPI) compiler
+and add ``-DGMX_MPI=on`` to the cmake options. It is possible to set
+the compiler to the MPI compiler wrapper but it is neither necessary
+nor recommended.
-The |Gromacs| team recommends OpenMPI_ version
-1.6 (or higher), MPICH_ version 1.4.1 (or
-higher), or your hardware vendor's MPI installation. The most recent
-version of either of these is likely to be the best. More specialized
-networks might depend on accelerations only available in the vendor's
-library. LAM-MPI_ might work, but since it has
-been deprecated for years, it is not supported.
+CUDA-Aware MPI support
+~~~~~~~~~~~~~~~~~~~~~~
+
+In simulations using multiple NVIDIA GPUs, an MPI implementation with CUDA support
+(also called "CUDA-aware") allows communication to be performed directly between the
+distinct GPU memory spaces without staging through CPU memory, often
+resulting in higher bandwidth and lower latency communication. For
+more details, see `Introduction to CUDA-aware MPI
+<https://developer.nvidia.com/blog/introduction-cuda-aware-mpi/>`_.
+
+To use CUDA-aware MPI for direct GPU communication we recommend
+using the latest OpenMPI version (>=4.1.0) with the latest UCX version
+(>=1.10), since most GROMACS internal testing on CUDA-aware support has
+been performed using these versions. OpenMPI with CUDA-aware support can
+be built following the procedure in `these OpenMPI build instructions
+<https://www.open-mpi.org/faq/?category=buildcuda>`_.
+
+With ``GPU_MPI=ON``, GROMACS attempts to automatically detect CUDA support
+in the underlying MPI library at compile time, and enables direct GPU
+communication when this is detected. However, there are some cases when
+GROMACS may fail to detect existing CUDA-aware support, in which case
+it can be manually enabled by setting environment variable ``GMX_FORCE_CUDA_AWARE_MPI=1``
+at runtime (although such cases still lack substantial
+testing, so we urge the user to carefully check correctness of results
+against those using default build options, and report any issues).
CMake
^^^^^
512-wide AVX, including KNL, add ``--enable-avx512`` also.
FFTW will create a fat library with codelets for all different instruction sets,
and pick the fastest supported one at runtime.
-On ARM architectures with NEON SIMD support and IBM Power8 and later, you
+On ARM architectures with SIMD support and IBM Power8 and later, you
definitely want version 3.3.5 or later,
and to compile it with ``--enable-neon`` and ``--enable-vsx``, respectively, for
SIMD support. If you are using a Cray, there is a special modified
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
* Run-time detection of hardware capabilities can be improved by
- linking with hwloc, which is automatically enabled if detected.
+ linking with hwloc. By default this is turned off since it might
+ not be supported everywhere, but if you have hwloc installed it
+ should work by just setting ``-DGMX_HWLOC=ON``
* Hardware-optimized BLAS and LAPACK libraries are useful
for a few of the |Gromacs| utilities focused on normal modes and
matrix manipulation, but they do not provide any benefits for normal
``-DGMX_USE_LMFIT=none``.
* zlib is used by TNG for compressing some kinds of trajectory data
* Building the |Gromacs| documentation is optional, and requires
- ImageMagick, pdflatex, bibtex, doxygen, python 2.7, sphinx
+ ImageMagick, pdflatex, bibtex, doxygen, python 3.6, sphinx
|EXPECTED_SPHINX_VERSION|, and pygments.
* The |Gromacs| utility programs often write data files in formats
suitable for the Grace plotting tool, but it is straightforward to
use these files in other plotting programs, too.
+* Set ``-DGMX_PYTHON_PACKAGE=ON`` when configuring |Gromacs| with CMake to
+ enable additional CMake targets for the gmxapi Python package and
+ sample_restraint package from the main |Gromacs| CMake build. This supports
+ additional testing and documentation generation.
Doing a build of |Gromacs|
--------------------------
::
- cmake .. -DGMX_GPU=ON -DGMX_MPI=ON -DCMAKE_INSTALL_PREFIX=/home/marydoe/programs
+ cmake .. -DGMX_GPU=CUDA -DGMX_MPI=ON -DCMAKE_INSTALL_PREFIX=/home/marydoe/programs
can be used to build with CUDA GPUs, MPI and install in a custom
location. You can even save that in a shell script to make it even
code will work on the AMD Bulldozer and Piledriver processors, it is significantly less
efficient than the ``AVX_128_FMA`` choice above - do not be fooled
to assume that 256 is better than 128 in this case.
-6. ``AVX2_128`` AMD Zen microarchitecture processors (2017);
+6. ``AVX2_128`` AMD Zen/Zen2 and Hygon Dhyana microarchitecture processors;
it will enable AVX2 with 3-way fused multiply-add instructions.
- While the Zen microarchitecture does support 256-bit AVX2 instructions,
+ While these microarchitectures do support 256-bit AVX2 instructions,
hence ``AVX2_256`` is also supported, 128-bit will generally be faster,
in particular when the non-bonded tasks run on the CPU -- hence
the default ``AVX2_128``. With GPU offload however ``AVX2_256``
Additionally, with GPU accelerated runs ``AVX2_256`` can also be
faster on high-end Skylake CPUs with both 512-bit FMA units enabled.
9. ``AVX_512_KNL`` Knights Landing Xeon Phi processors
-10. ``Sparc64_HPC_ACE`` Fujitsu machines like the K computer have this.
-11. ``IBM_VMX`` Power6 and similar Altivec processors have this.
-12. ``IBM_VSX`` Power7, Power8, Power9 and later have this.
-13. ``ARM_NEON`` 32-bit ARMv7 with NEON support.
-14. ``ARM_NEON_ASIMD`` 64-bit ARMv8 and later.
+10. ``IBM_VSX`` Power7, Power8, Power9 and later have this.
+11. ``ARM_NEON_ASIMD`` 64-bit ARMv8 and later.
+12. ``ARM_SVE`` 64-bit ARMv8 and later with the Scalable Vector Extensions (SVE).
+ The SVE vector length is fixed at CMake configure time. The default vector
+ length is automatically detected, and this can be changed via the
+ ``GMX_SIMD_ARM_SVE_LENGTH`` CMake variable.
The CMake configure system will check that the compiler you have
chosen can target the architecture you have chosen. mdrun will check
::
- cmake .. -DGMX_GPU=ON -DCUDA_TOOLKIT_ROOT_DIR=/usr/local/cuda
+ cmake .. -DGMX_GPU=CUDA -DCUDA_TOOLKIT_ROOT_DIR=/usr/local/cuda
(or whichever path has your installation). In some cases, you might
need to specify manually which of your C++ compilers should be used,
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-tested and supported of these. Linux running on POWER 8, ARM v7 and v8
+best-tested and supported of these. Linux running on POWER 8 and ARM v8
CPUs also works well.
Experimental support is available for compiling CUDA code, both for host and
-device, using clang (version 3.9 or later).
-A CUDA toolkit (>= v7.0) is still required but it is used only for GPU device code
+device, using clang (version 6.0 or later).
+A CUDA toolkit is still required but it is used only for GPU device code
generation and to link against the CUDA runtime library.
The clang CUDA support simplifies compilation and provides benefits for development
(e.g. allows the use code sanitizers in CUDA host-code).
Note that this is mainly a developer-oriented feature and it is not recommended
for production use as the performance can be significantly lower than that
of code compiled with nvcc (and it has also received less testing).
-However, note that with clang 5.0 the performance gap is significantly narrowed
+However, note that since clang 5.0 the performance gap is only moderate
(at the time of writing, about 20% slower GPU kernels), so this version
could be considered in non performance-critical use-cases.
::
- cmake .. -DGMX_GPU=ON -DGMX_USE_OPENCL=ON
+ cmake .. -DGMX_GPU=OpenCL
To build with support for Intel integrated GPUs, it is required
-to add ``-DGMX_OPENCL_NB_CLUSTER_SIZE=4`` to the cmake command line,
+to add ``-DGMX_GPU_NB_CLUSTER_SIZE=4`` to the cmake command line,
so that the GPU kernels match the characteristics of the hardware.
The `Neo driver <https://github.com/intel/compute-runtime/releases>`_
is recommended.
::
- cmake .. -DGMX_GPU=ON -DGMX_USE_OPENCL=ON -DclFFT_ROOT_DIR=/path/to/your/clFFT -DGMX_EXTERNAL_CLFFT=TRUE
+ cmake .. -DGMX_GPU=OpenCL -DclFFT_ROOT_DIR=/path/to/your/clFFT -DGMX_EXTERNAL_CLFFT=TRUE
Static linking
~~~~~~~~~~~~~~
default to static linking, the required flags have to be specified. On
Linux, this is usually ``CFLAGS=-static CXXFLAGS=-static``.
-gmxapi external API
-~~~~~~~~~~~~~~~~~~~
+gmxapi C++ API
+~~~~~~~~~~~~~~
For dynamic linking builds and on non-Windows platforms, an extra library and
headers are installed by setting ``-DGMXAPI=ON`` (default).
configuration.
Often it is possible to ensure portability by choosing the least
-common denominator of SIMD support, e.g. SSE2 for x86, and ensuring
-the you use ``cmake -DGMX_USE_RDTSCP=off`` if any of the target CPU
+common denominator of SIMD support, e.g. SSE2 for x86. In rare cases
+of very old x86 machines, ensure that
+you use ``cmake -DGMX_USE_RDTSCP=off`` if any of the target CPU
architectures does not support the ``RDTSCP`` instruction. However, we
discourage attempts to use a single |Gromacs| installation when the
execution environment is heterogeneous, such as a mix of AVX and
mdrun) that run slowly on the new hardware. Building two full
installations and locally managing how to call the correct one
(e.g. using a module system) is the recommended
-approach. Alternatively, as at the moment the |Gromacs| tools do not
-make strong use of SIMD acceleration, it can be convenient to create
-an installation with tools portable across different x86 machines, but
-with separate mdrun binaries for each architecture. To achieve this,
+approach. Alternatively, one can use different suffixes to install
+several versions of |Gromacs| in the same location. To achieve this,
one can first build a full installation with the
least-common-denominator SIMD instruction set, e.g. ``-DGMX_SIMD=SSE2``,
-then build separate mdrun binaries for each architecture present in
+in order for simple commands like ``gmx grompp`` to work on all machines,
+then build specialized ``gmx`` binaries for each architecture present in
the heterogeneous environment. By using custom binary and library
-suffixes for the mdrun-only builds, these can be installed to the
-same location as the "generic" tools installation.
-`Building just the mdrun binary`_ is possible by setting the
-``-DGMX_BUILD_MDRUN_ONLY=ON`` option.
+suffixes (with CMake variables ``-DGMX_BINARY_SUFFIX=xxx`` and
+``-DGMX_LIBS_SUFFIX=xxx``), these can be installed to the same
+location.
Linear algebra libraries
~~~~~~~~~~~~~~~~~~~~~~~~
* ``-DGMX_DOUBLE=ON -DGMX_MPI -DGMX_MIMIC=ON``
+.. _installing with CP2K:
+
+Building with CP2K QM/MM support
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+CP2K QM/MM interface integration will require linking against libcp2k
+library, that incorporates CP2K functionality into |Gromacs|.
+
+1. Download, compile and install CP2K (version 8.1 or higher is required).
+CP2K latest distribution can be downloaded `here <https://github.com/cp2k/cp2k/releases/>`_.
+For CP2K specific instructions please `follow <https://github.com/cp2k/cp2k/blob/master/INSTALL.md>`_.
+You can also check instructions on the `oficial CP2K web-page <https://www.cp2k.org/howto>`_.
+
+2. Make :file:`libcp2k.a` library by executing the following command::
+ make ARCH=<your arch file> VERSION=<your version like psmp> libcp2k
+
+The library archive (*e.g.* :file:`libcp2k.a`) should appear in the :file:`{<cp2k dir>}/lib/{<arch>}/{<version>}/` directory.
+
+3. Configure |Gromacs| with :command:`cmake`, adding the following flags.
+
+Build should be static:
+* ``-DBUILD_SHARED_LIBS=OFF -DGMXAPI=OFF -DGMX_INSTALL_NBLIB_API=OFF``
+
+Double precision in general is better than single for QM/MM
+(however both options are viable):
+* ``-DGMX_DOUBLE=ON``
+
+FFT, BLAS and LAPACK libraries should be the same between CP2K and |Gromacs|.
+Use the following flags to do so:
+
+* ``-DGMX_FFT_LIBRARY=<your library like fftw3> -DFFTWF_LIBRARY=<path to library> -DFFTWF_INCLUDE_DIR=<path to directory with headers>``
+* ``-DGMX_BLAS_USER=<path to your BLAS>``
+* ``-DGMX_LAPACK_USER=<path to your LAPACK>``
+
+4. Compilation of QM/MM interface is controled by the following flags.
+
+``-DGMX_CP2K=ON``
+ Activates QM/MM interface compilation
+``-DCP2K_DIR="<path to cp2k>/lib/local/psmp``
+ Directory with libcp2k.a library
+``-DCP2K_LINKER_FLAGS="<combination of LDFLAGS and LIBS>"``
+ Other libraries used by CP2K. Typically that should be combination
+ of LDFLAGS and LIBS from the ARCH file used for CP2K compilation.
+ Sometimes ARCH file could have several lines defining LDFLAGS and LIBS
+ or even split one line into several using "\". In that case all of them
+ should be concatenated into one long string without any extra slashes
+ or quotes.
+
+.. _suffixes:
+
Changing the names of |Gromacs| binaries and libraries
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.. _building just the mdrun binary:
-Building only mdrun
-~~~~~~~~~~~~~~~~~~~
-
-This is now supported with the ``cmake`` option
-``-DGMX_BUILD_MDRUN_ONLY=ON``, which will build a different version of
-``libgromacs`` and the ``mdrun`` program.
-Naturally, now ``make install`` installs only those
-products. By default, mdrun-only builds will default to static linking
-against |Gromacs| libraries, because this is generally a good idea for
-the targets for which an mdrun-only build is desirable.
-
Installing |Gromacs|
^^^^^^^^^^^^^^^^^^^^
need to do that, you might want to recompile with the new install
location properly set, or edit the ``GMXRC`` script.
+|Gromacs| also installs a CMake toolchains file to help with building client
+software. For an installation at ``/your/installation/prefix/here``, toolchain
+files will be installed at
+``/your/installation/prefix/here/share/cmake/gromacs${GMX_LIBS_SUFFIX}/gromacs-toolchain${GMX_LIBS_SUFFIX}.cmake``
+where ``${GMX_LIBS_SUFFIX}`` is :ref:`as documented above <suffixes>`.
+
Testing |Gromacs| for correctness
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
that a tolerance is just a tiny bit too tight. Check the output files
the script directs you too, and try a different or newer compiler if
the errors appear to be real. If you cannot get it to pass the
-regression tests, you might try dropping a line to the gmx-users
-mailing list, but then you should include a detailed description of
+regression tests, you might try dropping a line to the
+`|Gromacs| users forum <https://gromacs.bioexcel.eu/c/gromacs-user-forum>`__,
+but then you should include a detailed description of
your hardware, and the output of ``gmx mdrun -version`` (which contains
valuable diagnostic information in the header).
-A build with ``-DGMX_BUILD_MDRUN_ONLY`` cannot be tested with
-``make check`` from the build tree, because most of the tests
-require a full build to run things like ``grompp``. To test such an
-mdrun fully requires installing it to the same location as a normal
-build of |Gromacs|, downloading the regression tests tarball manually
-as described above, sourcing the correct ``GMXRC`` and running the
-perl script manually. For example, from your |Gromacs| source
-directory:
-
-::
-
- mkdir build-normal
- cd build-normal
- cmake .. -DCMAKE_INSTALL_PREFIX=/your/installation/prefix/here
- make -j 4
- make install
- cd ..
- mkdir build-mdrun-only
- cd build-mdrun-only
- cmake .. -DGMX_MPI=ON -DGMX_GPU=ON -DGMX_BUILD_MDRUN_ONLY=ON -DCMAKE_INSTALL_PREFIX=/your/installation/prefix/here
- make -j 4
- make install
- cd /to/your/unpacked/regressiontests
- source /your/installation/prefix/here/bin/GMXRC
- ./gmxtest.pl all -np 2
+Non-standard suffix
+~~~~~~~~~~~~~~~~~~~
-If your mdrun program has been suffixed in a non-standard way, then
-the ``./gmxtest.pl -mdrun`` option will let you specify that name to the
+If your ``gmx`` program has been suffixed in a non-standard way, then
+the ``./gmxtest.pl -suffix`` option will let you specify that suffix to the
test machinery. You can use ``./gmxtest.pl -double`` to test the
double-precision version. You can use ``./gmxtest.pl -crosscompiling``
to stop the test harness attempting to check that the programs can
be run. You can use ``./gmxtest.pl -mpirun srun`` if your command to
run an MPI program is called ``srun``.
+Running MPI-enabled tests
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
The ``make check`` target also runs integration-style tests that may run
with MPI if ``GMX_MPI=ON`` was set. To make these work with various possible
MPI libraries, you may need to
you try a few different parallelization options, and experiment with
tools such as ``gmx tune_pme``.
+Validating |Gromacs| for source code modifications
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+When building |Gromacs| from a release tarball, the build process automatically
+checks if any file contributing to the build process have been modified since they have
+been packed in the archive. This results in the marking of the version as either ``MODIFIED``
+(if the source files have been modified) or ``UNCHECKED`` (if no validation was possible, e.g.
+if no Python installation was found). The actual checking is performed by comparing a checksum
+stored in the release tarball against one generated by the ``createFileHash.py`` Python script
+during the build configuration. When running a |Gromacs| binary, the checksum is also printed
+in the log file, together with a message if there is a mismatch or no validation has been possible.
+
+This allows users to check whether the binary they are using was built from source code that is
+identical to the source code released by the |Gromacs| team. Thus unintentional modifications
+to the source code for building binaries that are used for running production simulations
+are easily detectable. Additionally, by manually setting a version tag using the
+GMX_VERSION_STRING_OF_FORK cmake option, users can mark a modified |Gromacs| release
+code with their custom version string suffix.
+
Having difficulty?
^^^^^^^^^^^^^^^^^^
does not currently compile |Gromacs| correctly, perhaps because the
thread-MPI atomics are incorrectly implemented in |Gromacs|).
-Fujitsu PRIMEHPC
-^^^^^^^^^^^^^^^^
-
-This is the architecture of the K computer, which uses Fujitsu
-Sparc64VIIIfx chips. On this platform, |Gromacs| has
-accelerated group kernels using the HPC-ACE instructions, no
-accelerated Verlet kernels, and a custom build toolchain. Since this
-particular chip only does double precision SIMD, the default setup
-is to build |Gromacs| in double. Since most users only need single, we have added
-an option GMX_RELAXED_DOUBLE_PRECISION to accept single precision square root
-accuracy in the group kernels; unless you know that you really need 15 digits
-of accuracy in each individual force, we strongly recommend you use this. Note
-that all summation and other operations are still done in double.
-
-The recommended configuration is to use
-
-::
-
- cmake .. -DCMAKE_TOOLCHAIN_FILE=Toolchain-Fujitsu-Sparc64-mpi.cmake \
- -DCMAKE_PREFIX_PATH=/your/fftw/installation/prefix \
- -DCMAKE_INSTALL_PREFIX=/where/gromacs/should/be/installed \
- -DGMX_MPI=ON \
- -DGMX_BUILD_MDRUN_ONLY=ON \
- -DGMX_RELAXED_DOUBLE_PRECISION=ON
- make
- make install
-
Intel Xeon Phi
^^^^^^^^^^^^^^
Xeon Phi processors, hosted or self-hosted, are supported.
-Only symmetric (aka native) mode is supported on Knights Corner. The
-performance depends among other factors on the system size, and for
-now the performance might not be faster than CPUs. When building for it,
-the recommended configuration is
-
-::
-
- cmake .. -DCMAKE_TOOLCHAIN_FILE=Platform/XeonPhi
- make
- make install
-
-
The Knights Landing-based Xeon Phi processors behave like standard x86 nodes,
but support a special SIMD instruction set. When cross-compiling for such nodes,
use the ``AVX_512_KNL`` SIMD flavor.
While it is our best belief that |Gromacs| will build and run pretty
much everywhere, it is important that we tell you where we really know
-it works because we have tested it. We do test on Linux, Windows, and
-Mac with a range of compilers and libraries for a range of our
-configuration options. Every commit in our git source code repository
-is currently tested on x86 with a number of gcc versions ranging from 4.8.1
-through 7, versions 16 and 18 of the Intel compiler, and Clang
-versions 3.4 through 5. For this, we use a variety of GNU/Linux
-flavors and versions as well as recent versions of Windows. Under
-Windows, we test both MSVC 2017 and version 16 of the Intel compiler.
-For details, you can
-have a look at the `continuous integration server used by GROMACS`_,
-which runs Jenkins_.
-
-We test irregularly on ARM v7, ARM v8, Cray, Fujitsu
-PRIMEHPC, Power8, Google Native Client and other environments, and
+it works because we have tested it.
+Every commit in our git source code repository
+is currently tested with a range of configuration options on x86 with
+gcc versions including 7 and 11,
+clang versions including 8 and 13,
+CUDA versions 11.0 and 11.4.2,
+and
+a version of oneAPI containing Intel's clang-based compiler.
+For this testing, we use Ubuntu 20.04 operating system.
+Other compiler, library, and OS versions are tested less frequently.
+For details, you can have a look at the
+`continuous integration server used by GROMACS <https://gitlab.com/gromacs/gromacs/>`_,
+which uses GitLab runner on a local k8s x86 cluster with NVIDIA and
+AMD GPU support.
+
+We test irregularly on ARM v8, Cray, Power8, Power9,
+Google Native Client and other environments, and
with other compilers and compiler versions, too.
biod.pnpi.spb.ru / alexxy / gromacs.git / blobdiff