CUDA Builds

[SimonBoothroyd]

Comment:

Hi,

I was interested in using some of the CUDA accelerated functionality of cpptraj to speed up some calculations, but it doesn't look like ambertools has any CUDA builds nor is there a separate cpptraj package that I could see similar to how parmed is split out.

Assuming I haven't missed anything (and apologies if I have!), would you be open to providing either a CUDA build of ambertools (assuming that would in turn provide CUDA enabled cpptraj) or alternatively splitting out a separate cpptraj package that itself has a CUDA build available if that is a path of less resistance?

[dacase]

I'd be fine with a CUDA-enabled AmberTools. The only change to the Amber side of the build should be to set CUDA=TRUE in the cmake invocation. This should build for many popular types of Nvidia hardware. But I don't know how to get cuda compilers from conda-forge, or whether or not one wants/needs to have several builds that depend on the SM value for the hardware being used.
One could build cpptraj only from Dan Roe's github.com/amber-md/cpptraj. This would avoid problems with other CUDA-enabled parts of AmberTools that you don't need anyway. But users would need to keep track of which cpptraj was being used -- the one from AmberTools or the one from Dan Roe.

[jaimergp]

We can add cpptraj (and pytraj?) as a separate package and then depend on it from ambertools like we do with parmed. We just need to ensure that Amber is using a publicly released (tagged) version from the same repo, and not an ad-hoc variation.

It's a good time to add CUDA stuff now that most of the new packages for CUDA components are available.

[SimonBoothroyd]

Thanks for the comments!

We can add cpptraj (and pytraj?) as a separate package and then depend on it from ambertools like we do with parmed

I'd have a slight preference for this approach so we could be a bit more granular in choosing our dependencies, but both paths seem reasonable.

One could build cpptraj only from Dan Roe's github.com/amber-md/cpptraj.

@dacase do you know if this repo has diverged significantly from the source bundled with AmberTools? It looks like the last 'release' of that repo is the same version that shipped in AmberTools 22, but there isn't mention of AmberTools 23.

If people would be happy to go down the separate cpptraj package I'd be happy to open a PR to staged recipes for this and try and get things passing.

[dacase]

On Mon, Jul 17, 2023, SimonBoothroyd wrote: > One could build cpptraj only from Dan Roe's github.com/amber-md/cpptraj. @dacase do you know if this repo has diverged significantly from the source bundled with AmberTools? It looks like the last 'release' of that repo is the same version that shipped in AmberTools 22, but there isn't mention of AmberTools 23.

I'm cc-ing Dan here. At each release of AmberTools (e.g. AmberTools23) we copy the latest version from Dan's repo. His repo hasn't diverged "significantly" since April, but there are some new features. Dan has a versioning system, but I'll leave further comments to him. ....dac

[dacase]

Hi, Yeah, I usually cut a release of cpptraj that matches what is released with the latest AT - I just haven't done that yet. Is it required? I'll try to get it done ASAP.

…

-Dan

On Tue, Jul 18, 2023 at 11:31 AM David A Case ***@***.***> wrote: On Mon, Jul 17, 2023, SimonBoothroyd wrote: > >> One could build cpptraj only from Dan Roe's github.com/amber-md/cpptraj. > ***@***.*** do you know if this repo has diverged significantly from the source >bundled with AmberTools? It looks like the last 'release' of that repo is >the same version that shipped in AmberTools 22, but there isn't mention of >AmberTools 23. I'm cc-ing Dan here. At each release of AmberTools (e.g. AmberTools23) we copy the latest version from Dan's repo. His repo hasn't diverged "significantly" since April, but there are some new features. Dan has a versioning system, but I'll leave further comments to him. ....dac

[dacase]

Of course, if you can just make a separate cpptraj package from the latest GitHub repo that would be best since bugfixes are a bit slower to filter in to the AT version. Let me know if there is anything I can do to facilitate this.

…

-Dan

On Wed, Jul 19, 2023 at 11:15 AM Daniel Roe ***@***.***> wrote: Hi, Yeah, I usually cut a release of cpptraj that matches what is released with the latest AT - I just haven't done that yet. Is it required? I'll try to get it done ASAP. -Dan On Tue, Jul 18, 2023 at 11:31 AM David A Case ***@***.***> wrote: > > On Mon, Jul 17, 2023, SimonBoothroyd wrote: > > > >> One could build cpptraj only from Dan Roe's github.com/amber-md/cpptraj. > > > ***@***.*** do you know if this repo has diverged significantly from the source > >bundled with AmberTools? It looks like the last 'release' of that repo is > >the same version that shipped in AmberTools 22, but there isn't mention of > >AmberTools 23. > > I'm cc-ing Dan here. At each release of AmberTools (e.g. AmberTools23) we > copy the latest version from Dan's repo. His repo hasn't diverged > "significantly" since April, but there are some new features. Dan has a > versioning system, but I'll leave further comments to him. > > ....dac >

[SimonBoothroyd]

Sounds great @dacase!

I've started to put together a recipe for cpptraj, and will also work on pytraj once that's working.

[SimonBoothroyd]

Ok I think the cpptraj and pytraj builds (CUDA+MPI) are working here: conda-forge/staged-recipes#23435.

@jaimergp would you be up to take a quick look if you get a moment?

[SimonBoothroyd]

If that looks reasonable, I guess some blockers would be:

• getting release made for pytraj and cpptraj, ideally one for AT22 and one for AT23
• modifying the new recipes to be incompatible with the current AT builds on CF to avoid clobbering
• modifying the AT recipe to not vendor pytraj and cpptraj and instead include the new packages as dependencies and make a new build

does that sound about right?

[dacase]

General related comment: splitting off cpptraj, pytraj (and other components) into individual packages seems like a good idea to me. We (i.e. Amber developers) should also simplify things -- there are parts of AmberTools that are very rarely used, and are no longer being developed or updated. We could reduce our vulnerability to compiler updates, etc.

[One item on my to-do list is to try to remove dependency on boost: it was (in my view) a mistake to ever let that creep in.]

[mattwthompson]

Somebody made progress on this with a PR that looks good but needs more reviews: #133

[xiki-tempula]

I think there is still value to add a CUDA build to this feedstock. My use case is that internally, we want to provision amber (specifically pmemd.CUDA.MPI) via a internal conda channel. Our current approach is to fork this repo and replace the source code with the AMBER source code, and use the build-locally script to build the package and deploy it. The downside is that we need to add the CUDA and MPI dependency ourselves and it would be good to concentrate this effort inside the community to avoid duplicated effort.