Support HIP

[mikemhenry]

Will use this PR to track what we need to support HIP. Related PRs and Issues:
#826
choderalab/openmmtools#753

Checklist

• Added a news entry

Developers certificate of origin

• I certify that this contribution is covered by the MIT License here and the Developer Certificate of Origin at https://developercertificate.org/.

[mikemhenry]

Will keep adding to this PR as needed, will also expand the news entry when the dust settles

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.64%. Comparing base (979676a) to head (5b5953b).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #951      +/-   ##
==========================================
- Coverage   94.59%   91.64%   -2.95%     
==========================================
  Files         134      134              
  Lines        9935     9935              
==========================================
- Hits         9398     9105     -293     
- Misses        537      830     +293     

Flag	Coverage Δ
fast-tests	91.64% <100.00%> (?)
slow-tests	?

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[IAlibay]

@mikemhenry do you want to add the allowable platforms list as a validator to the OpenmmEngineSettings class? I feel like we should document what we support somewhere, and it's probably as good a place to go "well you can do this but know that OpenCL and HIP aren't thoroughly validated.

[mikemhenry]

@IAlibay that is a good point! I will add that and also add a note somewhere in the docs, maybe we need a page that is like "Using OpenFE in Production" where we list what we have heavily validated and also list tips for using it, like generating all the partial charges before running transformations.

[IAlibay]

Do we need to set DeterministicForces or Percision for HIP?

[mikemhenry]

Good catch, I was able to do that with the OpenMM API, but I need to test on a real GPU to see if it works (as in, setting those properties worked on my openMM HIP build but it could crash as soon as I try and run a MD step on the GPU)

[IAlibay]

Is there an easy way to test this out? I.e. would spinning up an AWS runner that uses an AMD card work?

[mikemhenry]

So we don't currently have any validators:

https://github.com/OpenFreeEnergy/openfe/blob/main/openfe/protocols/openmm_utils/omm_settings.py#L300-L313

A literal would be my preference -- users can deal with errors of using cuda instead of CUDA since the error happens as soon as they set the setting and not at simulation run time, BUT I do think this would be considered an API change. If I use a validator I can then at least use it to warn users if they choose an option that won't work or choose an option that isn't well validated

[IAlibay]

So we don't currently have any validators:

https://github.com/OpenFreeEnergy/openfe/blob/main/openfe/protocols/openmm_utils/omm_settings.py#L300-L313

A literal would be my preference -- users can deal with errors of using cuda instead of CUDA since the error happens as soon as they set the setting and not at simulation run time, BUT I do think this would be considered an API change. If I use a validator I can then at least use it to warn users if they choose an option that won't work or choose an option that isn't well validated

I personally would prefer it if it was a validator - mainly you get things like "OpenCL" | "opencl".
Using a literal is too strict, we just need the lowercase to match in the protocol.