Fix a bug in GROMACS-2025.0 incomplete patch.

[aalhossary]

Description

Problem

GROMACS 2025.0 has a CMake ordering bug that prevents the real PLUMED module from being compiled, even when GMX_USE_PLUMED=ON is set.

Symptom

When running gmx_mpi mdrun -plumed plumed.dat, users get:

GROMACS is not compiled with the PLUMED interface, if you want to use -plumed option, 
please reconfigure GROMACS with -DGMX_USE_PLUMED=ON.

Even though GROMACS was configured with -DGMX_USE_PLUMED=ON.

Root Cause

In src/gromacs/CMakeLists.txt:

• Line 78: add_subdirectory(applied_forces) - checks GMX_PLUMED_ACTIVE variable
• Line 453: gmx_manage_plumed() - sets GMX_PLUMED_ACTIVE=ON

The variable is checked before it's set, causing CMake to always compile the stub (plumedMDModule_stub.cpp) instead of the real PLUMED module (plumedMDModule.cpp).

Solution

Move gmx_manage_plumed() call to before add_subdirectory(applied_forces).

Type of contribution

• changes to code or doc authored by PLUMED developers, or additions of code in the core or within the default modules
• changes to a module not authored by you
• new module contribution or edit of a module authored by you

Copyright

• I agree to transfer the copyright of the code I have written to the PLUMED developers or to the author of the code I am modifying.

• the module I added or modified contains a COPYRIGHT file with the correct license information. Code should be released under an open source license. I also used the command cd src && ./header.sh mymodulename in order to make sure the headers of the module are correct.

Tests

• I added a new regtest or modified an existing regtest to validate my changes.
• I verified that all regtests are passed successfully on GitHub Actions.

[Iximiel]

Thanks for you contribution

Are you sure about this?

This should have been caught by the gromacs CI before the release of GMX 2025 and it should matter also all the other modules that are included in gromacs (like colvar).

[aalhossary]

Calling gmx mdrun -plumed along does not produce any compilation or runtime problem. However, it does not set the multisim_communicator
I don't know what happens inside the CI. Also note that 2025 wa supposed to work without the need for patching at all, which is the case until someone uses the multisim_comm in a real multisimulation.

[GiovanniBussi]

@Iximiel do I remember correctly that this was a bug that we fixed after gromacs beta but gromacs developers preferred not to include? And that it is solved by patching?

[Iximiel]

@Iximiel do I remember correctly that this was a bug that we fixed after gromacs beta but gromacs developers preferred not to include?

The lack of the multisim is not a bug, is a missing feature. We did not manage to put it in time for the 2025, and then we left the PR open...

And that it is solved by patching?

The change proposed do not impact the behaviour of the patch. If I remember well,Cmake is intended to be run at least twice: configuration (in which things changes) and generation (in which settings are not touched and it is supposed to create the compilation procedure), look at how the various cmake guis behave, so that the order in which the cache is populated should not be a problem.

@aalhossary the problem--symptom couple you have indicated in the opening message is not the problem you are talking about in your second comment. This leave me a bit confused

[GiovanniBussi]

@Iximiel can you confirm that if one applies the patch then the problem is solved?

[Iximiel]

I just checked, @GiovanniBussi the "multisim" machinery is in the 2025 patch we deliver with plumed since 2.10.0