Task #3047

Set required versions for GROMACS 2021

Added by Eric Irrgang over 1 year ago. Updated 11 months ago.

Feedback wanted
Target version:


For GROMACS 2021, specify minimum support versions of dependencies, tools, and interacting software. Document and confirm test coverage.

Remember that they start being relevant to users when we release in 2021. 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 2021 really shouldn't factor highly.



proposed (#3290): 3.12

C++ Compilers


Unless something compelling comes along, let's give sysadmins a break for 2021, then bump to gcc 7 for C++17 support in 2022.

See also discussion at #3297



updating to clang-3.9 would avoid running into some issues where the standard was updated.




Python interpreter

The end-of-life schedule for Python minor versions may be too aggressive to guide support plans in the context of HPC installations, but it is becoming easier to manage multiple/custom Python installations, and potentially extra hassle to get EOLed versions into our testing infrastructure. It may be worth dropping support for 3.5 to simplify testing. There are also various improvements to Python meta-typing in 3.6 that allow removal of some awkward boiler plate in gmxapi. Let's make this choice as #3272 gets wrapped up.




Source code checking and other infrastructure

clang-format and clang-tidy may warrant coordinated clang infrastructure versioning as clangd becomes more useful and widespread.


Task #2905: Add a Jenkins configuration with std library assert New
Task #3033: Clean up and modernize googletest bundling and usageIn Progress
Task #3290: Require CMake >= 3.12Resolved

Related issues

Related to GROMACS - Task #2899: Update testing matrix versions for GROMACS 2020 releaseClosed
Has duplicate GROMACS - Task #3065: Agree and implement version support for GROMACS 2021Closed

Associated revisions

Revision 95c346f0 (diff)
Added by M. Eric Irrgang 10 months ago

Require Python 3.6.

Python 3.5 will reach end-of-life 2020-09-13.

Refs #3047


#1 Updated by Eric Irrgang over 1 year ago

  • Has duplicate Task #3065: Agree and implement version support for GROMACS 2021 added

#2 Updated by Mark Abraham over 1 year ago

  • Related to Task #2899: Update testing matrix versions for GROMACS 2020 release added

#3 Updated by Mark Abraham over 1 year ago

  • Target version changed from future to 2021-infrastructure-stable

#4 Updated by Eric Irrgang about 1 year ago

  • Description updated (diff)
  • Status changed from New to Feedback wanted

#5 Updated by Mark Abraham about 1 year ago

  • Description updated (diff)
  • Category deleted (documentation)
  • Target version deleted (2021-infrastructure-stable)

#6 Updated by Mark Abraham about 1 year ago

Discussed updating to clang 3.9 at

#7 Updated by Mark Abraham about 1 year ago

In email discussion, Gilles Guillardot reported that ACLE (ie ARM SVE intrinsics) is expected to be supported in mainline LLVM and gcc versions 10 (each due at some stage of 2020). Arm compiler currently supports them, but only version 19.3 is currently fully functional for GROMACS, and is based on LLVM 7.1. That's great, and will suit any minimum clang version we might choose.

The Fujitsu compilers work, but are NDA, so Erik has been asked by Paul to find out from Fujitsu what the base LLVM version is, so we can make an informed choice there.

#8 Updated by Mark Abraham 11 months ago

Twitter discussion reveals Fujitsu is also based on llvm 7.1.0, so there's no known risk to updating our minimum supported clang version to 3.9


Also available in: Atom PDF