The core GROMACS team wants to let users and downstream developers know about impending changes so that disruption is minimized. Do get in touch if you feel something inappropriate is planned!
Deprecated functionality often remains in GROMACS for a year or more, but this should not be relied upon.
Changes anticipated to GROMACS 2021 functionality#
gmx mdrun -membed#
The feature for embedding a protein in a membrane will be retained,
but probably in a different form, such as
gmx mdrun -rerun#
The feature for computing potential energy quantities from a
trajectory will be retained, but probably in a different form, such as
gmx rerun and
Integrator .mdp options will only contain dynamical integrators#
Energy minimization will be accessed in a differt form, perhaps with
gmx minimize and interpret an .mdp field for which minimizer to
use. Normal-mode analysis may be accessed with e.g.
normal-modes. The command-line help for these tools will then
be better able to document which functionality is supported when.
Much functionality in
The functionality in such tools is being separated to make it available in composable modules, that we plan to make available as simpler tools, and eventually via the GROMACS API that is under development.
gmx do_dssp to be replaced#
This tool is deprecated, because it is problematic for some users to obtain and install a separate DSSP binary, so we plan to replace the implementation at some point with a native implementation, likely based upon xssp, and make it available under a new gmx tool name.
Functionality deprecated in GROMACS 2021#
mdrun -deffnm to be removed#
This functionality is convenient when running very simple simulations,
because it permits grouping of a set of files that then differ only
their suffix. However, it does not work in the wider case of an
mdrun module (or modules) writing multiple
files. The resulting filenames collide. That, and its interaction with
checkpointing and appending, have led to quite a few bug reports.
Because users can use a folder to group files (a standard mechanism
that they understand from experience outside of GROMACS), we can
build and test better software for them if we remove the erstwhile
mdrun -deffnm. Please update your workflows
OpenCL to be removed as a GPU framework#
Issue 3818 Work is underway for ports to AMD and Intel GPUs, and it is likely that those ports will not be based on the current GROMACS OpenCL port. Nvidia GPUs are targeted by the CUDA port, and no changes are expectd there. The core team can’t maintain, test, and extend up to 4 ports with current resource levels. Since there are no prospects of an emerging GPU vendor in HPC needing OpenCL support, we will remove the OpenCL port once AMD and Intel support is established in other ways.
Intel KNC (MIC) support#
Issue 3818 This architecture is nearly extinct in HPC. Note that KNL support will continue and is not affected by this deprecation.
Sparc64 HPC ACE#
This architecture is nearly extinct in HPC.
Legacy SIMD architecture support#
Issue 3818 We occasionally need to extend the GROMACS SIMD framework, and so should slowly remove older architectures that are difficult or impossible to test. The following implementations are deprecated and will not support new functionality in future.
ARMv7 (this platform was deprecated in GROMACS 2020)
x86 MIC (this platform was deprecated in GROMACS 2021)
Sparc64 HPC ACE (this platform was deprecated in GROMACS 2021)
The mdrun-only build of GROMACS#
Issue 3808 Before GROMACS had the
gmx wrapper binary, the
mdrun binary could be built independently of the many other binary
tools that were built by default. That was useful for installing on
compute clusters because dependencies for
minimized. However, we now manage such dependencies better with CMake,
and an mdrun-only build is no longer easier to build. The mdrun-only
build is also harder to test, and introduces complexity into
documenting GROMACS and teaching users to use it. So it is time to
remove that build.
Support for version 1 of the hardware locality library
Issue 3818 Version 2 has been supported in GROMACS for several
years. The capabilities of newer hardware and hardware-support APIs
are of most interest for GROMACS moving forward, so we should
minimize our testing work and encourage clusters to upgrade older
Issue 3818 The legacy installed headers have been deprecated for a
while, however we wish to state more broadly that all headers found
src directory tree of GROMACS are intended for
internal consumption only, and are thus subject to change without
notice. Further, the form and contents of the
and related CMake targets may change as we move towards building APIs
and supporting machinery that can be stable and supported in the long
Issue 1354 This has been broken for many years, and will be removed as nobody has been found with interest to fix it.
Reading .pdo files in
The pull code in GROMACS before version 4.0 wrote files in
format. Analyses of such files are likely no longer relevant, and if
they are, using any older GROMACS version will work.
gmx wham will be
simpler to maintain and extend if we no longer support reading
Functionality deprecated in GROMACS 2020#
Support for 32bit architectures#
Issue 3252 There are no current or planned large scale resources using 32bit architectures, and we have no ability to properly test and evaluate them.
Free-energy soft-core power 48#
Issue 3253 Free-energy soft-core power 48 is almost never used and is therefore deprecated.
Support for Armv7#
Issue 2990 There are several issues with current code for the architecture, and we don’t have the resources for support and fix issues related to it. As the architecture has no large HPC impact it is thus deprecated.
Functionality deprecated in GROMACS 2019#
Generation of virtual sites to replace aromatic rings in standard residues#
Issue 3254 These are thought to produce artefacts under some circumstances (unpublished results), were never well tested, are not widely used, and we need to simplify pdb2gmx.
Benchmarking options only available with
Issue 3255 Options such as
-resetstep are not
intended for use by regular mdrun users, so making them only available
with a dedicated tool is more clear. Also, this permits us to customize
defaults for e.g. writing files at the end of a simulation part in ways
that suit the respective mdrun and benchmark use cases, so
will no longer be required.
gmx mdrun -nsteps#
Issue 3256 The number of simulation steps described by the .tpr file can be
gmx convert-tpr, or altered in .mdp file before the
gmx grompp. The convenience of this mdrun option was
outweighted by the doubtful quality of its implementation, no clear
record in the log file, and lack of maintenance.