Enable MPI support

[awvwgk]

Checklist

• [x] Used a personal fork of the feedstock to propose changes
• [x] Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• [x] Re-rendered with the latest conda-smithy (Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• [x] Ensured the license file is being packaged.

Closes #21

• creates low-priority variants for MPI enabled versions using MPICH and OpenMPI (non-MPI version is installed by default)
• does not add MPI support for OSX on ARM

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe:

• License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

Documentation on acceptable licenses can be found here.

[GiovanniBussi]

@awvwgk thanks a lot!!! I had a question on one line (added in the review). Can you also explain how to choose the version that will be installed (nompi/openmpi/mpich) or point me to a documentation page where this is discussed? Thanks again

[awvwgk]

The conda-forge knowledge base is quite detailed on this topic: https://conda-forge.org/docs/maintainer/knowledge_base.html#message-passing-interface-mpi

The mpi package on conda-forge is a virtual package which makes MPICH and OpenMPI mutually exclusive. With the build variants of conda-build defined in conda_build_config.yaml in the recipe directory we create three variants (nompi, mpich, openmpi), where only the MPI variants depend on the mpi metapackage. To make the selection straight-forward for conda install, we increase the build number for the non-MPI build to be always preferred over the MPI variants.

The user has to explicitly install the MPI variant:

conda install plumed  # always non-MPI version of plumed
conda install 'plumed=*=mpi_*'  # some MPI version of plumed
conda install mpich 'plumed=*=mpi_*'  # MPICH version of plumed

[GiovanniBussi]

The conda-forge knowledge base is quite detailed on this topic: https://conda-forge.org/docs/maintainer/knowledge_base.html#message-passing-interface-mpi

The mpi package on conda-forge is a virtual package which makes MPICH and OpenMPI mutually exclusive. With the build variants of conda-build defined in conda_build_config.yaml in the recipe directory we create three variants (nompi, mpich, openmpi), where only the MPI variants depend on the mpi metapackage. To make the selection straight-forward for conda install, we increase the build number for the non-MPI build to be always preferred over the MPI variants.

The user has to explicitly install the MPI variant:

conda install plumed  # always non-MPI version of plumed
conda install 'plumed=*=mpi_*'  # some MPI version of plumed
conda install mpich 'plumed=*=mpi_*'  # MPICH version of plumed

Amazing... thanks a lot!

[GiovanniBussi]

@awvwgk sorry for coming back to this, I have a little doubt. In the documentation you pointed to there are also these lines:

{% if mpi == 'nompi' %}
# prioritize nompi variant via build number
{% set build = build + 100 %}
{% endif %}

These are not present in the plumed recipe. Could you explain how the priority of nompi is controlled?

Thanks!

Giovanni

[awvwgk]

My bad, I forgot to add those lines to recipe, sorry about that. I just checked and an unspecified install will pick some plumed version and maybe even install some MPI in the same environment, unless there is a constraint present which prefers one of the three available versions.

Adding those three lines to the recipe would properly prioritize the non-MPI version. I can submit a patch to fix it.