[invemichele-peptone]

Description

Follow-up of #1504, which fixed checkpointing in the GROMACS 2025/2026 patches. These are the other bugs I found in those patches, plus one in the PLUMED 2.10 kernel that affects all the GROMACS patches. The bugs in the GROMACS 2020-2024 patches (among them a double-counted PLUMED virial, i.e. a wrong pressure, since the GROMACS 2019 patch) are fixed in #1505 (for v2.9); the GROMACS 2022.5, 2023.5 and 2024.3 patches are identical in v2.9 and v2.10, so they get those fixes when v2.9 is merged here. #1507 ports both PRs to master.

Each commit fixes one bug, with a CHANGES entry. Two of the bugs (the virial, and replica exchange on several ranks) are in the kernel and affect all the GROMACS patches:

Virial with a bias on ENERGY and domain decomposition (kernel, src/core)

On the domains other than the first, the Box input was flagged noforce, so that the virial computed by PLUMED is added only once. But the same flag also stopped ENERGY from rescaling that rank's share of the virial of the MD code, which is spread over all ranks. The pressure was then wrong with any bias on ENERGY (e.g. OPES multithermal-multibaric) and domain decomposition, with all the GROMACS patches. A new flag, forces_added_elsewhere, now only stops adding PLUMED's own forces on those ranks, as PLUMED 2.9 did.

• Alanine dipeptide, RESTRAINT ARG=ene SLOPE=-0.5, Pres-XX at step 0: 16.92 on 1 rank, 895.6 on 2 ranks and 29.8 on 3 ranks (GROMACS 2023.5 patch); now 16.92 on 1, 2 and 3 ranks, also with the GROMACS 2024.3 and 2026.4 patches.

Replica exchange with more than one rank per replica (kernel, src/core/GREX.cpp)

GREX::savePositions() shares the positions of all atoms, but then waits only for the inputs that are active on the step. When no action needs atoms on an exchange step, the exchange of the domain decomposition was started but never completed: with asynchronous sharing (the default on fewer than 10 ranks), the next exchange waited forever for messages that were never received, or, with small messages, received the positions of an earlier step. PLUMED 2.9 always waited. This affects -replex and -hrex with any GROMACS patch.

• Two TIP4P water replicas on 2 ranks each, -hrex, a distance printed every 10 steps: hung at the step after the first exchange attempt with the 2.10 kernel (also with the current patches); now runs, with zero exchange energy for identical replicas.

PLUMED asking to stop, e.g. COMMITTOR

The GROMACS 2025/2026 patches ignored the request: the simulation ran to the end. It is now a stop condition of the GROMACS stop handler, registered in runner.cpp: it reaches all ranks and the simulations that share state, and mdrun stops at the next step at which GROMACS communicates signals (every nstglobalcomm steps, and at least every 200 steps between simulations), writing a checkpoint. The modular simulator (md-vv) stops at the next neighbor-search step instead: when asked to stop at another step, it clears the task queue it is running from, and crashes (a GROMACS bug).

• Committing at step 2332 (leap-frog, 1 rank): ran to step 20000; now stops at step 2341. Also on 2 ranks, with md-vv, and with two walkers (both stop at step 201).

Virtual sites in the energy path

When PLUMED needs the potential energy, it runs at the end of do_force(), after GROMACS has spread the forces on the virtual sites and cleared them. The forces PLUMED applied on virtual sites (e.g. the M site of TIP4P water) were lost. They are now spread with their virial, on the steps when the atoms that PLUMED uses include virtual sites (from createFullList, which is the same on all ranks). The extra spread costs about 45 us per step, i.e. 2% of a GPU step for a 68k-atom TIP4P box (0.6% on CPU), so inputs that only bias the energy, e.g. OPES multithermal, do not pay for it.

• TIP4P water, restraint between two M sites: adding ENERGY to the input changed the forces on those waters by 6.9e3 kJ/mol/nm; now by 0.001 (1 and 2 ranks). With the restraint between two oxygens there is no extra spread, and the forces are bitwise identical to the run without ENERGY.

Energy on MTS fast steps

With multiple time stepping, the slow forces and their energy are computed only every mts-level2-factor steps, so the energy passed to PLUMED on the other steps lacked the slow terms (650-1250 kJ/mol in a water test). mdrun now stops with an error if PLUMED needs the energy on such a step.

Shell (polarizable) particles

The shell relaxation calls do_force() again for each iteration, passing step 1: PLUMED calculated and updated on each of them, as step 1 (e.g. PRINT printed extra lines at step 1). PLUMED now uses the step from prepareStep(), and only recalculates its forces (performCalcNoUpdate) when called again on the same MD step (only in MD: the frames of a rerun can share a step, and CG minimization passes step -1).

• SW water dimer, METAD + PRINT every step, 21 steps: COLVAR had 44 lines, with extra lines at step 1; now 21, and the same 6 hills.

Smaller fixes

• In reruns, a stop request (e.g. COMMITTOR) was ignored: GROMACS overwrites the stop decision with the result of reading the next frame. rerun.cpp is now patched, as in the GROMACS 2020-2024 patches.
• Errors raised on purpose by the PLUMED module (e.g. NotImplementedError for replica exchange with a bias) were caught and reported as internal errors ("bug"); their type and message are now kept.
• GROMACS 2025: gmx_multisim_t was forward-declared as a class but defined as a struct.

Docs

The list of MD codes said that GROMACS 2025 and later have limited support, without saying what the patches add. It now has a table of what the PLUMED module of GROMACS 2025 and later, the patches for GROMACS 2025/2026 and the patches for GROMACS 2022-2024 support: ENERGY, multiple walkers, checkpoints, stop requests, shells, replica exchange with a bias, and lambda dynamics. The table follows the results of the regression tests below. The descriptions of the 2025/2026 patches (plumed patch --info) also list stop requests and shells.

Tests

The CI does not build GROMACS, so I wrote regression tests for PLUMED with GROMACS, and proposed them to the PLUMED testcenter in plumed-testcenter/plumed-testcenter#95, where they would run every week on all the GROMACS versions that PLUMED can patch. They compare PLUMED with references that do not depend on the versions (e.g. a RESTRAINT against the GROMACS pull code, or the same run on 1, 2 and 3 ranks), so the same tests run on any combination of GROMACS, patch and kernel. With GROMACS 2025.0 and 2026.4, they fail where described above with v2.10 and all pass with this branch; the replica exchange deadlock was found by them. They also show what the GROMACS 2025/2026 patches add to the PLUMED module of GROMACS: GROMACS 2025 without patches fails the tests of ENERGY, checkpoints, COMMITTOR, shells and replica exchange with a bias. I also tested by hand, with GROMACS 2025.0 and 2026.4 (MPI build) patched with this branch and with v2.10, and the PLUMED kernel of this branch:

• the tests above, which fail with v2.10 and pass with this branch;
• the checkpoint tests of GROMACS 2025/2026 patches: tell PLUMED about checkpoints before the force calculation (alternative to #1430) #1504 still pass (1 and 2 ranks, STATE files written at the checkpoint steps);
• ENERGY still equals the GROMACS potential energy, and -replex with a PLUMED input that only prints still runs;
• the kernel virial fix also with the GROMACS 2023.5 and 2024.3 patches, and with the kernel of master (where the same fix applies cleanly);
• basic regtests: only the two failures that v2.10 already has (rt-average, rt-output-colvar-multi-dd);
• patching a clean GROMACS tree gives exactly the files of this branch.

Target release

I would like my code to appear in release v2.10

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.

🤖 Generated with Claude Code

[invemichele-peptone]

Follow-up in #1509: the constraint virial with MTS, shells in reruns and a warning for shells with ENERGY, reruns stopping at the frame that asks, and notes in the docs table. #1508 has the follow-up for v2.9.

🤖 Generated with Claude Code