Enable CMake parallel build

[mvhulten]

For components using the CMake build tool; tested with ParFlow.

Four threads appears to be the sweet spot. Walltimes (ParFlow only):

-j 1 -> 164 s
-j 2 -> 100 s
-j 4 -> 64 s
-j 8 -> 50 s

[mvhulten]

I don't know how to do this for ParFlow alone, but it should not break building of any other component as it is CMake native.

Maybe CI is also faster now. Can this be checked?

[kvrigor]

Not a good idea to hardcode --parallel 4 as it would pose a problem for coupled builds (see #62). Instead what I'd suggest is to parameterize the # of build threads, e.g.:

# default.env should provide a default setting for TSMP2_PARALLEL_JOBS.
# Either default=1 or a machine-specific default value.
export TSMP2_PARALLEL_JOBS=4

# Should be aware of TSMP2_PARALLEL_JOBS setting
./build_tsmp2.sh ...

This way you can still enable parallel builds while keeping the default build behavior to a known working state (i.e. -j1).

[mvhulten]

Firstly, I don't see what TSMP2_PARALLEL_JOBS does (assuming we're not going to write somewhere later --parallel $TSMP2_PARALLEL_JOBS, because then I'm missing the point).

Then, I suppose it is still not good enough, because your amended solution would mean that we have to test anyway if "-j 4" works on JSC machines. This is where I want to use it, at least sometimes.

I suppose, by default it must everywhere be "-j 1", and we could introduce build_tsmp2.sh --jobs and then add to the build command --parallel $jobs.

[mvhulten]

• It's important here to squash all commits
• There is the -j 8 of ICON to consider, but I don't think it matters (just in that the --help is lying)

[kvrigor]

assuming we're not going to write somewhere later --parallel $TSMP2_PARALLEL_JOBS

I was thinking to use TSMP2_PARALLEL_JOBS to parallelize builds within Build*.cmake scripts. Currently each component model uses a hardcoded -j setting. These hardcoded settings can be replaced by reading from the TSMP2_PARALLEL_JOBS env var.

Then, I suppose it is still not good enough, because your amended solution would mean that we have to test anyway if "-j 4" works on JSC machines. This is where I want to use it, at least sometimes.

It makes more sense to set the optimal TSMP2_PARALLEL_JOBS per machine thru environment files. If we do it this way, the default env file should set a conservative setting of TSMP2_PARALLEL_JOBS=1.

[kvrigor]

Parallel builds are now possible via the --parallel/-j switch:

./build_tsmp2.sh eclm parflow --parallel 16
./build_tsmp2.sh eclm parflow -j 16

If --parallel/-j is unset, the default number of jobs are read from the TSMP2_PARALLEL_JOBS environment variable, which I've already prescribed in the environment files. A quick test for an eCLM-Parflow build on JURECA (Intel, S2025) went from 23 mins (j=1) down to 8 mins (j=16).

One caveat: I skipped --parallel/-j in due to build errors. I didn't dig too deeply, but I suspect the issue is related to the recursive use of make within PDAF. I'll fix parallel PDAF builds some other time.

@AGonzalezNicolas can you help to verify if this works on your JUBE workflows? You'll only need to add git checkout parallel-build-mvh on your JUBE script; parallelization should automatically work as TSMP2_PARALLEL_JOBS=16 is automatically set when building on JSC machines.

[jjokella]

Short note: The update of the cmake_minimum_required to 3.28 means that the environments up to Stages/2024 are blocked. Is this wanted/needed?

[AGonzalezNicolas]

@kvrigor the branch parallel-build-mvh works with the jube

[kvrigor]

The update of the cmake_minimum_required to 3.28 means that the environments up to Stages/2024 are blocked. Is this wanted/needed?

Making TSMP2 work on Stages in which JSC have already dropped support would mean we'd have to deal with whatever weird issue we encounter in these old Stages, so it's best to limit the Stages supported in TSMP2. Also, fewer Stages would mean that active TSMP2 experiments run on a handful of toolchains, which makes debugging and comparing results more manageable for us TSMP2 maintainers.

stale review comment.