New and improved features
^^^^^^^^^^^^^^^^^^^^^^^^^

.. 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
   a space between the colon and number!


Collective variables module (Colvars) update
""""""""""""""""""""""""""""""""""""""""""""

The (`Colvars <https://colvars.github.io>`_) library for enhanced sampling simulations included
in |Gromacs| has been updated to version 2025-10-13.

This update brings many improvements, including:
- performance improvements for moving frame of reference calculations
- improved OPES implementation
- improved moving restraint logic, allowing for moving harmonic walls
- more flexible definitions of grids on CVs
A complete list of changes can be found `here <https://gitlab.com/gromacs/gromacs/-/merge_requests/5397>`_.

For documentation see :ref:`this section <colvars>`
of the |Gromacs| doc along with the `Colvars documentation page
<https://colvars.github.io/gromacs-2026/colvars-refman-gromacs.html>`_ dedicated to |Gromacs| 2026.
Messages about Colvars in the |Gromacs| discussion forum should be tagged
with the `colvars keyword <https://gromacs.bioexcel.eu/tag/colvars>`_ for
easier consultation.

Added LEaP-compatible dihedral reordering
"""""""""""""""""""""""""""""""""""""""""

AMBER LEaP reorders (improper) dihedrals when processing the topology, alphabetically
by atom type. In order for GROMACS to be able to match the topology produced by LEaP,
:ref:`gmx grompp` was extended LEaP-compatible dihedrals reordering. This functionality
is intended for usage with the ports of recent AMBER force fields (e.g. ff14SB and
ff19SB), but it is enabled on any force field that defines the
``_FF_AMBER_LEAP_ATOM_REORDERING`` macro.

This feature has been validated on all supported dipeptides and tripeptides as well as
select tetrapeptides and pentapeptides. Systematic validation on a broader set of
scientifically relevant biomolecules is still pending.

:issue:`4998`

Added the port of AMBER's ff14SB and ff19SB protein force fields
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

The latest AMBER force field for proteins, ff19SB, has been ported to |Gromacs|. The port
encompasses all functional forms, including per-amino-acid CMAPs, which are a new feature
of ff19SB. Furthermore, the port also includes the recommended optimal 4-point and 3-point
charge water models, better known as OPC and OPC3, and matching ions.

Older AMBER force field, ff14SB, has also been ported. For it, the TIP3P and TIP4PEW are
considered to be the recommended water models.

Due to the limited usage for production simulations thus far and possible bugs in |Gromacs|
features that these force fields use, these ports are considered validation pending.

:issue:`4998`

Changed the behaviour of ``pdb2gmx -rtpres``
""""""""""""""""""""""""""""""""""""""""""""

In order to support force fields like AMBER19SB, :ref:`pdb2gmx <gmx pdb2gmx>` can now
automatically rename residues to have the name of the chosen residue type, so that
:ref:`grompp <gmx grompp>` can assign the CMAP terms correctly. This is handled by
a new field in the ``[ bondedtypes ]`` description in the :ref:`residue types database<rtp>`
that specifies that such force fields must rename the residues accordingly.
``gmx pdb2gmx -rtpres`` now defaults to ``auto``, which means to preserve the residue name
unless that residue-type-database setting requires renaming to match the residue type.
It may also be set manually to ``no`` or ``yes``.

Improved implementation of the neural network potential interface
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

The neural network potential (NNP) interface has been extended to support new model inputs.
Firstly, it is now possible to use a list of atom pairs within the NNP region filtered by a
user-specified cutoff, as well as corresponding periodic shift vectors, as an input to the NNP.
This enables the use of model architectures such as SchNet or MACE and re-uses the pair-list
generated by |Gromacs|. Secondly, we also add support to pass positions and charges of the MM
region around the NNP region to the model, enabling the use of electrostatic embedding schemes
such as implemented in EMLE. Furthermore, a link atom scheme is now employed to treat covalent
bonds between the NNP and MM regions. In addition, there have been minor performance improvements,
and the interface now supports both CUDA and ROCm/HIP-builds of LibTorch. For more details on the
supported features and usage, please see the :ref:`NNPot section in the reference manual <nnpot>`.

Added support for H5MD trajectory file format
"""""""""""""""""""""""""""""""""""""""""""""

Trajectory data can now be written to the H5MD file format by :ref:`gmx mdrun`. Data written
to this file format includes positions, velocities, forces, and the simulation box. Chemical bonds
are also written to the connectivity group. For this release, only lossless output is supported.

Note that support for this file format in |Gromacs| tools is experimental. Analysis tools are
able to read all files but bugs should be expected. H5MD output from :ref:`gmx trjconv` and
:ref:`gmx trjcat` is not implemented.

Fast Multipole Method (FMM) interface support
"""""""""""""""""""""""""""""""""""""""""""""

Support for simulations with external FMM libraries has been added. Short-range electrostatics can 
be computed by either |Gromacs| or the FMM library, while long-range electrostatics are handled by
the FMM library when an FMM backend is selected. Although the FMM interface allows short-range 
electrostatics to be configured for either |Gromacs| or the FMM backend, short-range FMM interactions 
support in |Gromacs| is planned but not part of this release. MDP options are available for the well-known 
FMM libraries i.e., ExaFMM and FMSolvr, and these options are validated internally by the interface.

For more details, please see :ref:`the FMM section in the reference manual <fmm>`.

Add two new performance metrics
"""""""""""""""""""""""""""""""

:ref:`gmx mdrun` reports two additional time step-independent metrics to measure the
performance of a simulation on specific hardware. The ms/step is the average 
wall-clock time (in milliseconds) required to compute a single timestep.
As a direct measure of computational cost per timestep, it is useful for 
profiling code or hardware performance for a specific system.
Matom*steps/s considers the number of atoms and measures the throughput of 
actions (number of steps * number of atoms) per second. This metric is suitable 
when comparing performance across systems and hardware. A similar metric can also 
be found from `PLUMED <https://docs.lammps.org/Speed_measure.html#examples-comparing-serial-performance>`_. 

:issue:`5374`

QM/MM CP2K interface updates
""""""""""""""""""""""""""""

QM/MM simulations with CP2K interface could now use GROMACS checkpoint files
for saving QM subsystem centering translation. It greatly improves stability
of QM/MM simulations during long trajectories and upon restarting from checkpoint. 

:issue:`5529`
