Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve espaloma Support #336

Open
mikemhenry opened this issue May 13, 2024 · 5 comments
Open

Improve espaloma Support #336

mikemhenry opened this issue May 13, 2024 · 5 comments

Comments

@mikemhenry
Copy link
Collaborator

mikemhenry commented May 13, 2024

We should update the default espaloma ff to espaloma-0.3.2.pt

@ijpulidos
Copy link
Collaborator

Espaloma 0.3.x is supported, we have run simulations using it for both protein and small molecules. That said, the way to use it is probably not that easy to accomplish, we should make this more streamlined.

We had specific GHA workflows to test the espaloma support but I don't know why or when these were removed. Sounds like we should get these back.

@mattwthompson
Copy link
Collaborator

I'm curious the use cases of Espaloma with this package vs. just using Espaloma's API directly to generate parameters (in the form of an openmm.System)? I can only think of

  • Experiments using Espaloma for one portion of a topology and another force field for another portion
  • Similar to above, but using a non-Espaloma on chemistries it's not suitable for

The current architecture of building something on top of SystemGenerator (which itself has a lot of magic built on top of these templates) which parses Espaloma data to eventually get a system - compared to just getting it directly from Espaloma's parameters. It may be that rewriting downstream code to use Espaloma's API is not so simple, I'm not sure

@mikemhenry
Copy link
Collaborator Author

They were just consolidated into a single CI file, I said "improve" espaloma support since for the end-user it looks like we only support once espaloma ff, I will update the issue instead to update what we consider the "default" espaloma version (just like we updated the default openff version)

def INSTALLED_FORCEFIELDS(self):
"""Return list of available force field versions."""
# TODO: Does this belong here? Is there a better way to do this?
# TODO: Update this
# TODO: Can we list force fields installed locally?
# TODO: Maybe we can check ~/.espaloma and ESPALOMA_PATH?
return ["espaloma-0.3.2"]

@ijpulidos
Copy link
Collaborator

They were just consolidated into a single CI file, I said "improve" espaloma support since for the end-user it looks like we

Ah I see, what I saw is that the espaloma tests are being skipped. I set these tests to be run with the --runespaloma flag, we should probably add that to the pytests flags or remove the requirement for it. At the time this was designed in such a way because the espaloma tests were optional and we only wanted to run the espaloma tests in that specific CI workflow.

@ijpulidos
Copy link
Collaborator

I'm curious the use cases of Espaloma with this package vs. just using Espaloma's API directly

@mattwthompson This is a good point to raise. As far as I can tell, we do want to maintain the possibility of using Espaloma only for specific portions of the topology (be it only the small molecule, or a mutant residue, a cofactor, etc.). However, I agree that the current approach is very cumbersome and hard to maintain in the longer term.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants