GROMACS 2026.5 release notes¶
This version was released on TODO, 2026. These release notes document the changes that have taken place in GROMACS since the previous 2026.4 version, to fix known issues.
Fixes where mdrun could behave incorrectly¶
Fixed incorrect LJ-PME forces and energies for perturbed particles¶
In the free-energy non-bonded kernel, the indexing of the coefficient buffer for LJ-PME grid corrections was incorrect. This meant that forces and energies were incorrect. In addition, the coefficient buffer for LJ-PME grid corrections was not allocated sufficiently large, which meant that LJ forces and energies could be random, depending on whether the memory accessed was used for other data. And finally, the PME grids were mixed up for computing the B-state forces and energies. These issues have been present in versions 2025.0 to 2026.4.
Fix incorrect virial and pressure with perturbed atoms¶
With free-energy calculations, perturbed non-bonded interactions would have incorrect virial contributions when interacting over a periodic boundary. This led to incorrect pressures. The effect would be small when only a few atoms were perturbed. This bug has been present in release 2025.0 to 2026.4.
Fixed check for SETTLE interactions on particles with perturbed atoms¶
Using SETTLE constraints on water molecules whose masses are perturbed is not supported, and grompp and mdrun both check for this. Formerly the check worked correctly in the normal case where a SETTLE is used in a molecule type representing a single water molecule. Now it also works correctly in the general case of a fused molecule type containing a SETTLE and another molecule with an atom whose mass is perturbed.
Fixed the exclusion check of free energy calculations with multiple molecule types¶
In free energy calculations with Ewald, PME or LJ-PME, mdrun checks that the number of perturbed excluded pairs found in the pair search matches the number expected from the topology. When the inter-molecular exclusion group contained atoms of different molecule types, the expected number used the perturbation state of an atom from the wrong molecule type. This could cause a spurious fatal error, could let the check pass although perturbed excluded pairs were beyond the pair-list cut-off, or could read memory beyond the end of the atom data. This has been present in versions 2026.0 to 2026.4.
Fixed free energy calculations with multiple time stepping of listed interactions¶
With multiple time stepping and pair, dihedral or angle interactions
in mts-level2-forces, the listed interactions computed at each
time-stepping level did not get the count of non-perturbed interactions.
In free energy calculations with perturbed listed interactions,
mdrun then used uninitialized values, which could cause
crashes, incorrect forces and dH/dlambda, or incorrect foreign-lambda
energies. This has been present since version 2021.
Fixed NNPot pair-list input for models requesting only pair-shifts¶
A neural network potential model whose inputs include pair-shifts but not
atom-pairs was never subscribed to the pair-list construction, because the
option name was misspelled in that check, so the model was passed an empty
shift list without any error. Models that also request atom-pairs were not
affected. This has been present in versions 2026.0 to 2026.4.
Fixed NNPot pair-list input with single-rank domain decomposition¶
For neural network potential models with atom-pairs or pair-shifts
inputs, the local atom indices in the pair list were interpreted as global
indices. With domain decomposition, which reorders the local atoms and is
also used by default even on a single rank when non-bonded interactions are
computed on the CPU with PME or Ewald electrostatics, the model was passed
pairs that did not match the atom positions. This led to incorrect energies
and forces without any error. Single-rank runs with non-bonded interactions
on a GPU were not affected. This has been present in versions 2026.0 to 2026.4.
Added fatal error for unsupported domain decomposition with NVSHMEM¶
The experimental NVSHMEM-based PP halo exchange does not support domain
decompositions with more than one communication pulse along the second or
third decomposition dimension.
Now mdrun exits with a fatal error instead of crashing.
Fixed missing PME grid halo line with GPU PME decomposition¶
With GPU PME decomposition, the PME grid halo was one line too small when the PME grid size along a decomposed dimension was not a multiple of the number of PME ranks along that dimension. Then part of the charge of atoms close to PME domain boundaries could be missing on the grid, which gave errors in PME energies and forces. This has been present since GPU PME decomposition was introduced.
Fixes for gmx tools¶
Fixed grompp crash with deform-init-flow for integrators without velocities¶
With deform-init-flow = yes, gmx grompp crashed with a segmentation
fault for energy minimization, normal-mode analysis and test-particle insertion,
since these integrators do not use velocities. Now deform-init-flow is
ignored with these integrators, with a note when deform is set. With these
integrators, gmx grompp also no longer asks for
deform-init-flow = yes when the box is deformed. With integrator = bd,
which does not use the initial velocities, the error for gen-vel = yes
without deform-init-flow = yes is now a warning and the note asking for
deform-init-flow = yes is no longer given. This has been present in versions
2024.0 to 2026.4.
Fixed grompp note about constraints = all-bonds with virtual sites¶
gmx grompp gives a note suggesting constraints = h-bonds when
constraints = all-bonds is used with a short time step and a force
field parametrized with constraints on bonds involving hydrogens only
(AMBER, CHARMM or OPLS-AA). The note was intended to be suppressed when
the topology has 3fd virtual sites, as generated by gmx pdb2gmx
with -vsite hydrogens, but the check for such virtual sites never
found any, so the note was always given. This has been present in
versions 2019.0 to 2026.4.
grompp did not recognize hydrogen atoms with names starting with a digit for constraints
“”””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””””
When converting bonds to constraints, gmx grompp only checked the first character of the atom name. Now the second character is checked when the first is a digit.
Fixes that affect portability¶
Miscellaneous¶
Updated references to the paper describing AMBER14SB and AMBER19SB conversion and validation¶
The paper describing the conversion and validation of AMBER14SB and AMBER19SB has been published in J. Chem. Theory Comput., doi:10.1021/acs.jctc.6c01592. The force field files and the documentation now refer to it instead of the preprint, and gmx grompp asks to cite it when these force fields, Amber LEaP-like dihedral atom reordering or residue-type-specific CMAPs are used.