.. Note to developers!
   Please use """"""" to underline the individual entries for fixed issues in the subfolders,
   otherwise the formatting on the webpage is messed up.
   Also, please use the syntax :issue:`number` to reference issues on GitLab, without the
   a space between the colon and number!

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.

.. Note to maintainers!
   The sections below should general copy the contents from the previous major release,
   except where appropriate when code or planning changes have happened.

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 membed``.

``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 ``gmx test-particle-insertion``.

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. ``gmx
normal-modes``. The command-line help for these tools will then
be better able to document which functionality is supported when.

Much functionality in ``trjconv``, ``editconf``, ``eneconv`` and ``trjcat``
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
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 ``.xvg`` output
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
convenience of ``mdrun -deffnm``. Please update your workflows
accordingly.

:issue:`3818`

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.

* Power 7
* 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 ``mdrun`` were
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 ``hwloc``
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
: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
``hwloc`` installations.

Legacy API
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
:issue:`3818` The legacy installed headers have been deprecated for a
while, however we wish to state more broadly that all headers found
within the ``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 ``libgromacs`` library
and related CMake targets may change as we move towards building APIs
and supporting machinery that can be stable and supported in the long
term.

Constant-acceleration MD
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
: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 ``gmx wham``
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
The pull code in |Gromacs| before version 4.0 wrote files in ``.pdo``
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
``.pdo`` files.

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 ``gmx benchmark``
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
:issue:`3255` Options such as ``-confout``, ``-resethway``, ``-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 ``-confout``
will no longer be required.

``gmx mdrun -nsteps``
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
:issue:`3256` The number of simulation steps described by the .tpr file can be
changed with ``gmx convert-tpr``, or altered in .mdp file before the
call to ``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.

