Restore setNumOMPthreads in the GROMACS 2025 patch (plumed#1435)

* Restore setNumOMPthreads in the GROMACS 2025 patch

Up to the 2024.3 patch, PLUMED was told how many OpenMP threads GROMACS
was using:

    int nth = gmx_omp_nthreads_get(ModuleMultiThread::Default);
    plumed_cmd(plumedmain, "setNumOMPthreads", &nth);

When the 2025.0 patch was written against the native PLUMED support that
GROMACS now ships, that call was not carried over. As a result
PLMD::OpenMP::getNumThreads() always returns 1, and actions that
parallelise over OpenMP silently run serially unless the user sets
PLUMED_NUM_THREADS by hand -- which is not something that can be known in
advance on a heterogeneous machine, nor after GROMACS' dynamic load
balancing has redistributed the work.

Reinstate the call in the PlumedForceProvider constructor, behind the same
API-version gate the 2024.3 patch used. The value is available at that
point: gmx_omp_nthreads_init() is called in runner.cpp well before the
force providers are constructed.

Fixes plumed#1407

* regtest: check that setNumOMPthreads reaches OpenMP::getNumThreads

The patch this branch restores works by having the MD code tell PLUMED how many
OpenMP threads it is using, via cmd("setNumOMPthreads"), from the
PlumedForceProvider constructor. Nothing was covering that path.

It cannot be covered from the patch side: patches/ is never compiled by
PLUMED's build (no object is produced under it), and there is no harness that
patches and builds a GROMACS tree. What can be covered, and is what actually
broke, is the mechanism the patch depends on -- that the command is honoured
and is visible to OpenMP::getNumThreads(). When it is not, getNumThreads()
reports 1 and every OpenMP-parallel action silently runs serially: results stay
correct, so only a test like this notices.

Setting the value twice also pins down that the command is re-issuable rather
than latch-once, and 0 is checked because PlumedMain maps it to 1 instead of
passing a meaningless thread count through.

The expected values are fixed (3, 5, 1) rather than machine-dependent:
OpenMP::setNumThreads stores what it is given without clamping.

Author: aalhossary

patches/gromacs-2025.0.diff/src/gromacs/applied_forces/plumed/plumedforceprovider.cpp

@@ -44,6 +44,7 @@
 #include "gromacs/domdec/domdec.h"
 #include "gromacs/domdec/domdec_struct.h"
 #include "gromacs/math/units.h"
+#include "gromacs/mdlib/gmx_omp_nthreads.h"
 #include "gromacs/mdrunutility/handlerestart.h"
 #include "gromacs/mdrunutility/multisim.h"
 #include "gromacs/mdtypes/commrec.h"
@@ -115,6 +116,15 @@ try : plumed_(std::make_unique<PLMD::Plumed>()),replex_(options.replex_)
         }
     }
 
+    if (plumedAPIversion_ > 5)
+    {
+        /* tell PLUMED how many OpenMP threads GROMACS is using, so that it can
+           parallelise its own work; without this PLMD::OpenMP::getNumThreads()
+           always reports 1 unless PLUMED_NUM_THREADS is set by hand */
+        int numOmpThreads = gmx_omp_nthreads_get(ModuleMultiThread::Default);
+        plumed_->cmd("setNumOMPthreads", &numOmpThreads);
+    }
+
     if (isMultiSim(options.ms_))
     {
         if (MAIN(options.cr_))

regtest/basic/rt-make-ompthreads/Makefile

@@ -0,0 +1 @@
+include ../../scripts/test.make

regtest/basic/rt-make-ompthreads/config

@@ -0,0 +1 @@
+type=make

regtest/basic/rt-make-ompthreads/main.cpp

@@ -0,0 +1,38 @@
+/*
+ * Checks the mechanism the MD-code patches rely on to tell PLUMED how many OpenMP threads the engine is
+ * using: cmd("setNumOMPthreads") must be reflected by PLMD::OpenMP::getNumThreads().
+ *
+ * The GROMACS 2025 patch issues this command from the PlumedForceProvider constructor. Without it
+ * getNumThreads() reports 1 and every OpenMP-parallel action silently runs serially, which is invisible
+ * in results and only shows up as lost performance -- exactly the kind of regression a test should catch.
+ *
+ * Setting the value twice also pins down that the command is re-issuable rather than latch-once.
+ */
+#include "plumed/wrapper/Plumed.h"
+#include "plumed/tools/OpenMP.h"
+#include <fstream>
+
+int main() {
+  std::ofstream ofs("output");
+
+  // Query first so any PLUMED_NUM_THREADS in the environment has already been latched: the point is that
+  // an explicit setNumOMPthreads overrides whatever the default resolved to.
+  PLMD::OpenMP::getNumThreads();
+
+  PLMD::Plumed p;
+
+  unsigned nt = 3;
+  p.cmd("setNumOMPthreads", &nt);
+  ofs << "after setNumOMPthreads(3): " << PLMD::OpenMP::getNumThreads() << "\n";
+
+  nt = 5;
+  p.cmd("setNumOMPthreads", &nt);
+  ofs << "after setNumOMPthreads(5): " << PLMD::OpenMP::getNumThreads() << "\n";
+
+  // 0 threads is meaningless; PlumedMain maps it to 1 rather than passing it through.
+  nt = 0;
+  p.cmd("setNumOMPthreads", &nt);
+  ofs << "after setNumOMPthreads(0): " << PLMD::OpenMP::getNumThreads() << "\n";
+
+  return 0;
+}

regtest/basic/rt-make-ompthreads/output.reference

@@ -0,0 +1,3 @@
+after setNumOMPthreads(3): 3
+after setNumOMPthreads(5): 5
+after setNumOMPthreads(0): 1