CUDA pinned dependency

[lvotapka]

Comment:

Hi All,

I have OpenMM as a dependency of my own Conda-forge package (https://github.com/seekrcentral/seekr2_openmm_plugin-feedstock.git). CUDA is also one of my dependencies, and I've been sticking with the pinned versions (10.2, 11.0, 11.1, and 11.2). However, I've discovered that whenever I try to build my package in Conda-forge using CUDA 11, OpenMM is installed with a default version of 11.8. This creates a version mismatch that prevents me from being able to build properly.

So my questions are: 1) Are you aware of any way to specify to have OpenMM install with the proper CudaToolkit version from the meta.yaml file, or 2) Are there any plans to have the default version of OpenMM on Conda adhere to the pinned CUDA dependencies?

Thank you.

[peastman]

I'm not sure exactly how conda-forge handles this. The recipe just lists {{ compiler('cuda') }} as a dependency. That automatically gets filled in with the correct cudatoolkit version. We never specify a version ourselves. Perhaps you're missing that? See https://conda-forge.org/docs/maintainer/knowledge_base.html#cuda-builds.

Note that there's a difference between the version you build against and the version installed for users. 11.2 is binary compatible with all later 11.x versions. That's why we don't need to build against later ones. Users may still need newer ones, though. 11.2 is too old for some recent GPUs.

[lvotapka]

Thanks for the response, @peastman. I am also using the {{ compiler('cuda') }} variable. For some reason, it doesn't seem to be using the same version when installing OpenMM into the environment. It doesn't really matter to me what version of CUDA is used for the build, or by the users, but the problem is just because the CUDA version used to build my plugin and the one that is installed for OpenMM are different - which prevents the "make PythonInstall" step from working properly in the build.

However, it seems that using CUDA 10.2 avoids this problem, and I'll probably direct users to just request that version with their conda install. Although it's probably not a very sustainable solution - I'm eventually going to have to figure out how to make the later CUDA versions work when everyone moves past 10.2.