Task #2831

Updated by Mark Abraham over 1 year ago

For GROMACS 2020, we should choose some new minimum supported versions to target, remembering that they start being relevant to users when we release in 2020. Remember, there is a trade-off between what new things we can do (because we support a smaller range of things) vs what things we might require some users to do (because GROMACS no longer builds out of the box for them). Your workload as a GROMACS developer goes up for each extra version we support, even if that only shows up in what you have to do to keep Jenkins happy, or how hard it is for you to get access to others' feedback because they are thinking about something that is mysteriously broken in some Jenkins combination. Also, versions that may or may not be the bases for forks that support hardware that GROMACS users might have that isn't already shipping in early 2020 really shouldn't factor highly. The statements below are true in July 2016.


Discussion at The latest cmake 3.9.x looks like a good compromise (supports native CUDA on Linux and Windows; has supported C++14 for a long time).

DONE - cmake 3.9.6 adopted


We will move to c++14 for the main code base. If we would do that also for .cu files, then we would either need CUDA 9.0, or to complicate the build system for ensuring that they compile with c++11 in an ABI-compatible way (which means that any std::vector exposed across the internal linking boundary would have to be compiled in the same way in both sides; I don't know if it's technically feasible to link two libstdc++ for the different use cases - it would be risky even if possible). That might or might not be simpler if we already used native CUDA support in cmake.

WIP at

Done - c++14 adopted, but stdlibc++ questions remain


Ignoring corner cases, we adopted 7.0 (released March 2015) for GROMACS 2019 (released January 2019). We adopted 6.5 (released August 2014) for GROMACS 2018 (eventually released January 2018). So from a user perspective, the CUDA minimum requirement has been for one that is at least 3 years old.

That suggests CUDA 8.0 (released September 2016) would be a consistent bump for GROMACS 2020 (released January 2020). It adds support for clang 3.7 and clang 3.8 on Linux, but otherwise doesn't look compelling.

CUDA 9.0 would be the minimum required for device-side c++14 compilation. We probably don't want or need to write any c++14 code there, but not having an internal language barrier would be convenient for developers. But the version bump is more aggressive for users, and if we did that then we should consider agreeing that GROMACS 2021 should avoid a version bump.

WIP at gerrit 8963/3 git fetch ssh:// refs/changes/63/8963/3 && git checkout FETCH_HEAD

DONE Decided on CUDA 9.0, patch available for review. Undecided on using native cmake cuda support


Python 3 is required and is the only one supported by the core code. releng, physicalvalidation, check-source and documentation code will have to be ported (e.g. via 2to3). Some patches are already in gerrit


We should adopt -4.9-5, 4.9, as it supports c++14 and avoids some rough edges in 4.8 (e.g. missing regex support). DONE gcc 5 required

We support 1.2 and that's probably all that's feasible.


Probably worth a bump to get rid of any remaining workarounds for its codegen and/or bugs.


3.4 Edit: DONE required 3.6

replace uncrustify with clang-format

Need to pick a version of clang-format and update the existing config file on a Gerrit patch for any reasonable format that doesn't introduce a massive change while not requiring something ugly, install that on Jenkins, update the releng stuff during the transitional period, make the transitional patches. After a few years, remove uncrustify support in releng and Jenkins.