enhance GROMACS easyblock to improve control over PLUMED support (native vs. patching)

[ostueker]

Since GROMACS 2025 one can compile GROMACS with a PLUMED interface without patching it by setting CMake option -DGMX_USE_PLUMED=ON.
Applying PLUMED patches to GROMACS 2025 is still possible in order to get the latest PLUMED functionality.

This PR adds a fourth option 'patch' to the extra-option plumed.

• plumed = None (default) auto detects whether PLUMED is available and do the same as plumed = True
• plumed = True sets -DGMX_USE_PLUMED=ON for GROMACS >= 2025 or try to patch GROMACS with PLUMED's patches for older (<=2024.x) versions (depends whether the loaded version has patches for that version of GROMACS
• plumed = 'patch' will try to patch GROMACS with PLUMED's patches regardless of the GROMACS version
• plumed = False will disable PLUMED functionality, even if it is found (neither apply patches nor set -DGMX_USE_PLUMED=OFF for GROMACS >=2025

<edit>improved logic is here</edit>

I think that's the best of both worlds. It behaves like before for older GROMACS releases (before 2025) and takes the minimal-invasive route (avoiding to patch) when set to None or True.

[jhmeinke]

Wouldn't it make more sense to use, e.g., plumed = 'native' to enable the native support for GROMACS 2025 and newer? I admit it's a bit more invasive, but with this PR, plumed = True|None results in limited functionality for PLUMED in GROMACS >= 2025 compared to older versions, which might be unexpected.

[ostueker]

I quite like the idea of introducing a setting plumed = 'native' which would make clear which PLUMED integration is being used.

As far as I can tell, the plan is for GROMACS to gradually support most PLUMED use-cases via their native API. GROMACS 2025 with a limited native PLUMED-API was just the first step into that direction.

PLUMED's own description of their gromacs-2025.0 patch is:

This patch previes (sic) extra features to be implemented in the official PLUMED integration in the next GROMACS version

I think the setting that requires the most thought is plumed = None (i.e. the default), especially taking future releases (2026, 2027, ...) into consideration.
What should happen when PLUMED has been added as a dependency but no plumed = [True|'native'|'patch'] has been set?

I argue that easybuild should use the least-invasive method, which means choosing plumed = 'native' for GROMACS 2025 and newer and falling back to plumed = 'patch' for older versions for backwards compatibility.

Since their 2020 release, GROMACS validates the checksum of the release during the build-process and will modify the GROMACS version string if the checksum does not match the official release.

Overall plumed = 'native' will be the most versatile option because:

1. When built with native PLUMED support a single GROMACS module can be used with different versions of PLUMED modules as long as $PLUMED_KERNEL points to a $EBROOT_PLUMED/lib/libPlumedKernel.so. (i.e. PLUMED can be defined as a build-dependency and not a hard dependency)
2. The compiled gromacs binaries get the badge of being an official release.
3. Functionality of native PLUMED support will soon catch up to support most common use-cases.

And to serve the needs of users who will need the latest PLUMED features which are not yet supported by the native PLUMED API, we can provide modules with plumed = 'patch' that are then linked to a specific version (module) of PLUMED.

[ostueker]

Commit 82a0da5 addresses @jhmeinke 's comments.

New logic is now:

• plumed = 'patch' will try to patch GROMACS with PLUMED's patches regardless of the GROMACS version
• 🆕 plumed = 'native' sets -DGMX_USE_PLUMED=ON for GROMACS >= 2025
• plumed = False will disable PLUMED functionality, even if it is found (neither apply patches nor set -DGMX_USE_PLUMED=OFF for GROMACS >=2025
• plumed = None (default) auto detects whether PLUMED is available and
  will use native PLUMED support where available (GROMACS >= 2025) or fall
  back to patching for older versions.
• plumed = True behaves like plumed = 'patch' and could probably be deprecated.

[jhmeinke]

Thanks for the update!

I agree, the tricky part is plumed = None. I'm worried that somebody who has given PLUMED as a dependency before and now switches to a version of GROMACS >= 2025 will not get the PLUMED functionality they are expecting if the default is to go with the native PLUMED support.

If I hadn't come across this thread, I would have been wondering why some of our users are complaining about their simulations with GROMACS and PLUMED not working as expected anymore.

I would use patching as the default behavior when PLUMED is given as a dependency for all versions of GROMACS that don't have full native support for PLUMED and use plumed = 'native' to opt in for now. Once native support is complete, it should of course be the default.

[ostueker]

I did some digging:

• PLUMED versions older than 2.10 don't contain any patches for GROMACS 2025

• PLUMED 2.10 says this about the gromacs-2025.0 patch in the section "Code specific notes":

  A basic PLUMED interface is already present in GROMACS

  This patch previes (sic) extra features to be implemented in the official PLUMED integration in the next GROMACS version

  and this in the version 2.10 Change Log:

  New patches for MD codes:

  • A patch for GROMACS 2025 has been added, which is based on the native GROMACS interface to PLUMED and adds support for multiple walkers.

• The limitation about PLUMED being incompatible with thread-MPI (listed here) is also mentioned for the gromacs-2025.0 patch so it's not related to native vs. patch.

Overall it appears that the classic PLUMED patches for GROMACS seem to have been discontinued in favor of the native GROMACS interface to PLUMED. There is probably some functionality that is lost for now, even with PLUMED 2.10's patches for GROMACS 2025.

@jhmeinke if you feel it's necessary, I could change the code to default to applying the patches for GROMACS 2025 and maybe even 2026 (the PR 4622 that didn't make it into GROMACS 2025 hasn't been merged for 2026 either). But I suspect that starting with GROMACS 2027 we can default to the native interface and any possible patches would only be to activate bleeding-edge functionality.

On the PLUMED users mailing list, the lead-developer of PLUMED has mentioned, that the group is still using GROMACS 2022 internally.

[ostueker]

@jhmeinke in e2df627 I've upped the GROMACS version from which point plumed = None will prefer native PLUMED support to (the yet unreleased) GROMACS 2026.

Since even the patches for gromacs-2025.0 are based on GROMACS' native support, there seem to be certain PLUMED modes that aren't supported with very recent versions of GROMACS anyway (e.g. Hamiltonian Replica Exchange MD (H-REMD)).

[jhmeinke]

Thanks @ostueker ! I think this is a good way to move forward.