Fix MPICH vs. MPICH2 inconsistencies

[geimer]

An MPICH 3.x-based toolchain exists for both ClangGCC and GCC, however, the first uses MPICH as MPI toolchain name and the second MPICH2. Since the project has renamed itself back to MPICH with version 3.0 (see http://www.mpich.org/about/overview/ last paragraph), MPICH seems to be the right name to use. This PR fixes these inconsistencies.

Note: This PR requires changes in some easyconfigs (see easybuilders/easybuild-easyconfigs#1217) and potentially also in some easyblocks (still under investigation).

[hpcugentbot]

Automatic reply from Jenkins: Can I test this?

[geimer]

Potentially related PRs:

• Added support for Parastation MPICH toolchains with Intel compilers #1072 (Added support for Parastation MPICH toolchains with Intel compilers)
• Added support for Parastation MPICH toolchains with GCC compilers #1073 (Added support for Parastation MPICH toolchains with GCC compilers)
• adding support for MPICH (instead of just MPICH2) #1098 (adding support for MPICH instead of just MPICH2)

[wpoely86]

ok to test

[wpoely86]

Looks like something for EB v2 as it will break stuff. @boegel ?

[boegel]

@geimer: rather than renaming/fixing the existing toolchain definition for gmpich2, I would simply add one for gmpich next to it (as is done in #1073)... The gmpich2 toolchain definition should not disappear, since people using that (sub)toolchain (correctly, i.e. with MPICH v2.x) should still be able to do so.

The changes made in gmpolf look correct to me, but maybe we should also introduce gmpolf2?

I'm more concerned about this change, since this will make further builds with existing gmpolf toolchains impossible; the toolchain definition changed, hence the toolchain module will need to be reinstalled using the patched easyconfigs from easybuilders/easybuild-easyconfigs#1217.
It should be OK to do that without rebuilding everything else though, since the toolchain components remain the same; it only concerns a rebuild of MPICH 3.x under the correct name, and regenerating the gmpolf toolchain module.

I'm only aware of our friends in New Zealand using gmpolf (cfr. easybuilders/easybuild-easyconfigs#460). @nesi, @Bart-CER, @jordiblasco, @pm67nz, @scintimandrion: thoughts?

[hpcugentbot]

Test PASSed.

[geimer]

@boegel: Generally, I'm fine with keeping the gmpich2 toolchain definition. In fact, I was thinking about keeping it for MPICH2 1.x, too. But to avoid subtle side effects by accidentally using the wrong toolchain definition, I preferred to remove it. But I'll add it back.

Introducing gmpolf2 may make some sense. However, the only MPICH2 easyconfig file I could find was MPICH2-1.1-GCC-4.8.1.eb, for which no further toolchain exists. So I'm not sure whether it's worth the effort. But it could be added, of course.

Regenerating the gmpolf toolchain and modules is probably necessary, true. And if someone has installed custom versions of the gmpich2 (with MPICH 3) and gmpolf toolchains, these probably have to be adjusted and regenerated, too. But I currently see no way round this to clean up this mess...
Suggestions welcome.

[hpcugentbot]

Test PASSed.

[hpcugentbot]

Test PASSed.

[geimer]

I can confirm that rebuilding the gmpolf toolchain using eb --force gmpolf-1.4.8.eb -r is (a) necessary and (b) working for existing packages (tested with HPL). MPICH by default uses --rpath anyway so that the "old" installation will be picked up by existing packages, but it still works with the remaining, newly built "olf" packages.

Note that rebuilding gmpolf is necessary "in both directions". However, I'm not sure whether using an older version of EasyBuild after a new one is available is a common use case...

BTW: Shouldn't the name of a full MPICH2 toolchain be gmp2olf rather than gmpolf2? I mean, it's MPICH2 and not FFTW2. Please let me know whether there is interest in this toolchain and I will add it.

[Bart-Ver]

We actually don't use the gmpolf toolchain. There is only one application installed with it (OpenSees), and we will just leave it as is.