Skip to content

Set required versions for GROMACS 2025

Summary

For GROMACS 2025, specify minimum support versions of dependencies, tools, and interacting software.

Use cases

We need to continuously add support for new versions of things that put new and better capabilities in the hands of users, particularly as hardware capabilities change, and because our resources are finite we need to continuously drop support for older versions of things.

Remember that the decisions here start being relevant to users when we release in 2025.

The workload of a GROMACS developer goes up for each extra version we support, even if that only shows up in what they have to do to keep CI happy, or how hard it is for a developer to get access to others’ feedback because they are thinking about something that is mysteriously broken in some CI combination.

Software versions that may or may not be the bases for GROMACS forks that support hardware that GROMACS users might have that isn’t already shipping in early 2025 really shouldn’t factor highly.

Impact

There is a trade-off between that

  • users are more likely to get software that is correct, easy to use, and fast if we support a narrower range of things, vs
  • what extra things some users might have to do when installing because GROMACS no longer builds out of the box for them.

Detailed description

CMake We have previously generally adopted the minimum version of the then-latest Ubuntu LTS ie 24.04, currently 3.28.3 per https://answers.launchpad.net/ubuntu/noble/+package/cmake. Native CMake support for HIP and nvc++ are desirable.

  • AA: let's avoid pinning a patch version

Decision: CMake 3.28.0

C++ version C++20 was standardized late in year 2020, and compilers and standard libraries have been doing a decent job for a couple of years. Requiring C++ modules is off the table because CMake support for that requires gcc 14 which will be released April 2024. Vendor compilers are now all based on LLVM and stay fairly up to date (but need testing).

  • VM: compiler version below sound reasonable. Perhaps even GCC 11.
  • PB: Paul also tested HIP fork with GCC 10 and 11, and will push for 11. Supported versions on some of the clusters?
  • MA: Standard HPC clusters have a variety of compilers
  • JJ: We need to support whatever is in distributions we want to package; everything else has Spack.

Decision: C++20

Compilers Minimum supported versions are currently generally implied by the requirement for the amount of C++20 support that we think we want. Note that support in the respective standard libraries often lags years behind support in the compiler (sometimes because they need the compiler to support language features before it is efficient to complete the library development).

gcc

  • We currently require version 9.1.
  • Increasing (e.g. to 11.1 released April 2021) could be good as that is the first to support C++ modules which we might want to require for GROMACS 2026.
  • gcc 10 was the first to support the correct flag -std=c++20.
  • We are again likely to have to maintain sub-dialects that restrict the use of C++20 features in source files and headers that compile using wrapper or device compilers.

libstdc++ compatibility notes (https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2020):

  • string and vector became constexpr in 12.1
  • Atomic waiting and notifying, std::semaphore, std::latch and std::barrier came in 11.1
  • std::source_location came in 11.1
  • mathematical constants came in 10.1
  • concepts came in 10.1
  • coroutine support came in 10.1

Discussion:

  • PB: source_location is good to have

Decision: GCC 11.1 (first release in the series)

clang

Source: https://clang.llvm.org/cxx_status.html

  • We currently require 5 even though clang 9 is the earliest that we test
  • concepts came mostly in clang 10, but several bits in clang 16
  • only partial coroutine support yet
  • modules support is ongoing, clang 15 might be the earliest that has decent support
  • we could pick a version that was released around the same time that the GCC version was released, or perhaps one after that (for any extra libstdc++ compatibility)
  • clang 12 was released April 2021

Note that GROMACS generally uses libstdc++ with clang

PB: We can also bump formatting to avoiding bugs in clang-format-11. Better use relatively new ones BH: clang-format-11 is a pain on mac AA: If we aim for Ubuntu 22.04, we can use -14 to -18 VM: Debian packages Clang 14. MA: For formatting, we want as new as possible to delay the next bump. PB: Maybe Clang 14 to be safe, Clang 18 is too new AA: By the time 2025 is realeased, Clang 18 will be stable and available. Update as late as possible to avoid merges bewtween branches with different formatting. JJ: If we can do pip install for clang-format, version does not matter much

Decision: Clang 14 for the code; Clang-latest by the end of the release cycle for formatting

MSVC

https://learn.microsoft.com/en-us/cpp/overview/what-s-new-for-visual-cpp-in-visual-studio?view=msvc-170

  • currently 2019 with OpenMP
  • We generally support whatever was the most recent release (here, 2022). They are very keen on implementing C++ library features, e.g. https://microsoft.github.io/STL/

Discussion:

  • VM: Some tests were failing with 2022, but need to re-test. When tests are fixed, 2022 is reasonable.

Decision: MSVC 2022.

CUDA/nvcc

Currently we require 11.0 (for C++17 compatibility.) For approx CUDA release dates, see https://developer.nvidia.com/cuda-toolkit-archive. Historically we have supported two major versions at the time of release, but CUDA no longer has an annual release cadence. Should we adopt CUDA 12.0 as minimum? (Released Dec 2022)

Clang 14 and gcc 12.1 is the minimum supported by CUDA 12

  • AG: CUDA 12.1 has full C++20 and Graph support
  • AA: Are we ok dropping sm_3x devices?
  • AG: Not an issue from NVIDIA side.
  • MA: Users with old hw will have to old GROMACS versions.
  • BH: Also remove all the code for old devices.

Decision: CUDA 12.1

ROCM/hipcc

  • PB: There is a strong push to bump all things to 6.0.2 since it is reasonably working.
  • AA: With ACpp, 5.2.3 is works ok, and is the newest available for LUMI
  • PB: We choose whatever packages supported Clang, that's 5.3, perhaps. New versions have better CMake.
  • MA: We don't want to inconvenience Frontier and LUMI
  • PB: But we want to push people for new versions
  • ML: Any known issues with 5.3?
  • PB: Not that I know of.
  • AA: LUMI only officially has 5.2, but unofficially newer versions (and that's what we use with ACpp)

Decision: ROCm 5.2, but depends on testing

SYCL

  • MA: We require SYCL2020 and suggest latest available compilers and SDKs.
  • AA: No major changes in ACpp 24.02, and 24.06 is a bit too late.

Decision: Require oneAPI 2024.0 and AdaptiveCpp 23.10

MPI Currently 2.0, but a few things we do are technically 3.0 ( #4933). That's a decade-old standard with wide support, so we should adopt it also.

  • AA: Any reason not bump to 4?
  • MA: MPI 4 is much more recent (not a decade old like 3, June 2021), need to see if it brings new things
  • BH: MPI gets adopted more slowly, so we need to be more conservative
  • MA: Unless there's a good idea why we need MPI 4, let's use MPI 3

Decision: MPI 3

Python interpreter Python 3.9 still has security support in 2025, so is a reasonable choice for min version for GROMACS 2025

  • AA: If we're bumping the oldest version, might also want to update the newest supported version in CI.
  • VM: FreeBSD and Apple are slow in adopting new version, need to check
  • BH: My mac has 3.11, but it's a custom install
  • VM: macOS Ventura 3.9, same FreeBSD (all supported versions)
  • JJ: 3.9 is already ancient
  • VM: But let's not hurry

Decision: Python 3.9

Doxygen Some people want to update but the risk vs reward and available effort needs to be understood.

  • ML: Any reason yo upgrade?
  • MA: It's broken w.r.t. C++ dialects
  • ML: Let's upgrade then if we're bumping C++ standard
  • MA: But it will break our docs. We can fix things, but the benefit is still questionable compared to effort of going and fixing all broken things.
  • PB: Installing old Doxygen is a pain (but we have Docker), but I tried upgrading our docs to new Doxygen, and it was a pain too.
  • JJ: There's no compatibility.
  • ML: Let's not make a decision, but we won't stop people from volunteering
  • JJ: Maybe find something that's not Doxygen?
  • MA: There is something LLVM-based, but still, migration effort is perhaps not justified

Decision: leave as is

Sphinx No need to change

GoogleTest We updated to 1.12.0 in mid 2023, so no reason to plan to update unless someone will do the work and knows of a new feature that someone will then use.

clang-format No need to change, we updated in 2021

Decision: See clang discussion above, switch to Clang-latest in ~August 2024.

clang-tidy No need to change, we updated in 2021

  • AA: Clang 14 or clang-latest? Clang-latest is harder to install, but also nobody does that (we have CI)
  • MA: Clang-latest, I don't have it installed.
  • PB: I use clang-tidy as a pre-commit hook, but it does not work with HIP

Decision: Clang-latest (see Clang discussion)

CI container base Adopt Ubuntu 24.04 and use it for all CI containers (where it is possible, and after it comes out in April and is supported by GPU drivers).

  • AA: no need to commit to these decisions, let's talk to maintainers.
  • ML,MA: Sounds good.

Responsible developer

Mark Abraham

Time plan

Relevant changes here should happen in the first half of 2024, so they have time to stabilize before we focus on completion of work for the annual release.

Discussion participants:

Edited by Mark Abraham