GROMACS 2023.2 release notes#
This version was released on July 12th, 2023. These release notes document the changes that have taken place in GROMACS since the previous 2023.1 version, to fix known issues. It also incorporates all fixes made in version 2022.6 and earlier, which you can find described in the Release notes.
Fixes where mdrun could behave incorrectly#
Fix mdrun segfault when perturbing only LJ-14 parameters#
Fix numerical instability with free-energy and LJ-PME#
When combining free-energy calculation with PME for Lennard-Jones interactions, large rounding error would cause instabilities when two atoms were at short distance.
Fix mdrun domain decomposition setup limit of 715827882 atoms#
An overflow in the domain decomposition grid setup limited the maximum number of atoms that could be simulated to max_int/3, unless the -dd option was specified.
Allow bonded pair interactions to be missing#
With -noddcheck, mdrun did not allow bonded pair interactions to be missing. This is now allowed again.
Increase and check for atom count limits in output files#
The maximum number of atoms in the checkpoint and trr files was 715 827 882 and has been increased to 1 431 655 765 atoms. Now mdrun exits with a clear error message when these limits are exceeded. For XTC files, the limit is raised by a separate fix.
Fix assertion failure with annealing and multiple T-coupling groups#
Properly update the backup checkpoint#
In 2023 and 2023.1, the state_prev.cpt file was never
overwritten, and thus always contained the very first checkpoint
for the run.
Fix domain decomposition with bonded interactions with long distances#
mdrun would exit with an error about missing bonded interactions when domain decomposition was used and bonded interactions involved distances longer than the pairlist cutoff.
Fixes for gmx tools#
Avoid error in tools reading tpr files with energy minimization#
Many tools would exit with an error “No v in input file” when reading a tpr file with integrator set to energy minimization, NM or TPI.
Tools now retain chain identifiers when reading PDB is used as input#
The gmx hbond tool could produce random ouput#
Because memory was not initialized, the gmx hbond tool could produce random output. This would not go unnoticed. This also fixes issues with the -ac and -life options.
Fixes that affect portability#
CMake config package#
Depending on the build environment, GROMACS 2023 and 2023.1 could install a malformed
gromacs-config.cmake file in prefix/share/cmake/gromacs$SUFFIX/ that
could cause failure of the find_package(gromacs) CMake command.
rocfftis no longer ever a public dependency.The config package file now fully express the dependency on hipSYCL (Open SYCL), when relevant.
Miscellaneous#
gmxapi.commandline_operation environment variable filtering#
A new utility (gmxapi.runtime.filtered_mpi_environ()) is available
to remove MPI-related environment variables from os.environ, such as
to prepare the subprocess environment of gmxapi.commandline_operation.
This is a follow-up to Issue 4423, for which the original fix appeared to be insufficient.
build-dependent checking for gmxapi runtime arguments#
Depending on whether GROMACS was built with MPI support or thread-MPI support, some gmx mdrun options are not defined. Such errors may only appear in the MD log file, and can thus be hard to identify in API use cases.
Additional checking has been added to gmxapi.simulation.workflow.from_tpr()
to try to preempt user errors,
and additional usage notes have been added to gmxapi.mdrun.
gmxapi.mdrun task uniqueness#
Fix a bug in which all gmxapi.mdrun simulation tasks had the same ID (and working directory).
Fix for crash when CUDA Graphs are enabled on multi-GPU#
A bug was introduced into version 2023.1 resulting in a crash when the non-default CUDA Graphs experimental feature was enabled on multi-GPU, caused by the introduction of extra synchronization which is not required for the CUDA graphs codepath. This version fixes the issue by avoiding this synchronization when graphs are in use.
Enable XTC support for gigantic systems#
The (old) XTC format uses an internal char buffer whose size in bytes was stored as an integer in the file, which led to crashes when storing systems with more than roughly 300 million atoms. This version fixes the issue by introducing a 64-bit size only for large systems, and using a different magic number (2023) in the XTC header. This will only change the XTC format for large systems (which anyway would lead to crashes in the old version). Short-term the large system XTC files might not be readable by external tools (you will get errors about incorrect magic number), but we are working with external packages to update their implementations.
Fix resource leak in OpenCL#
gmx mdrun built with OpenCL was slowly leaking memory when
running on GPUs. That’s fixed now.
Allow convert-tpr to assign initial velocities#
To help ensemble projects like free energy that sometimes rely on thousands of simulations for each system, we now allow convert-tpr to assign a new set of random velocities rather than using grompp to regenerate the full tpr. This also fixes a bug where using 0 for velocity seed in the mdp file would have the same effect as -1 and cause a new seed to be generated from the OS.
Correct formulas for Nosé-Hoover thermostat#
Several formulas describing Nosé-Hoover temperature coupling contained inconsistencies. The reference manual was updated to match the actual implementation.
Fix commandline-test on broken gcc versions#
gcc 9.3.1 would fail generating proper paths for comparison, resulting in test failures.
Fix SIMD detection/recommendation on AMD Zen 4 / Genoa#
Zen 4 provides a single AVX-512 unit, but in contrast to Intel chips it is still faster to use the single AVX-512 unit than the double AVX2 units, likely due to higher clock and lower instruction pressure. This change will select AVX-512 by default on Zen 4 (which can improve performance 5-10%), and it modifies the hardware detection so we only try to count AVX units on Intel CPUs. It also clarifies detection messages to make it clear it’s based on expected performance rather than hardware support for a particular instruction set, and makes sure the stdout messages fit in a single line.