Let the force field resolve the partial charge assignment - #2152
Conversation
|
No API break detected ✅ Griffe output |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2152 +/- ##
==========================================
- Coverage 95.04% 90.33% -4.71%
==========================================
Files 206 206
Lines 20553 20660 +107
==========================================
- Hits 19534 18664 -870
- Misses 1019 1996 +977
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
pre-commit.ci autofix |
for more information, see https://pre-commit.ci
# Conflicts: # src/openfe/tests/protocols/test_openmmutils.py
IAlibay
left a comment
There was a problem hiding this comment.
Couple of things - mainly it doesn't look like the CLI would work right now (maybe it just needs a test to check it).
| # which is different to how settings work which can leave off the .offxml extension | ||
| ff = ForceField(*forcefields) | ||
| # let the force field resolve the partial charge assignment | ||
| charges = ff.get_partial_charges(offmol) |
There was a problem hiding this comment.
I believe this needs to get wrapped around toolkit_registry_manager, otherwise we'll go back to encountering the annoying rdkit & openeye toolkit aren't compatible problem.
There was a problem hiding this comment.
Probably but which registry would we use as it could influence the charge method used? I think the default is openeye and am1bccelf10 and then fall back to AmberToolsam1bcc?
There was a problem hiding this comment.
Just use what the user has in the settings for the toolkit_backend and make it clear in the docs that the backend is always followed when a charge is generated.
There was a problem hiding this comment.
Ah this doesn't work if the force field uses nagl charges, as our default is ambertools, we might need to use a different method to make the registry. Maybe something like:
If the user has openeye pass:
- openeye
- nagl
- ambertools
If the user has rdkit and no openeye: - rdkit
- nagl
- ambertools
There was a problem hiding this comment.
Sorry I don't understand why it's not working.
The "AmberTools" backend is AmberTools + RDKit, that should be enough for NAGL to work no?
There was a problem hiding this comment.
Ah ok - the issue is that the NAGL registry isn't in there?
There was a problem hiding this comment.
I think it might be ok to just add the NAGLToolkitWrapper to both AmberTools & OpenEye backend lists - please double check but I think it will still do the "protection" that we're trying to do (i.e. it will block you from doing am1bcc with openeye if you don't want it).
There was a problem hiding this comment.
Add the wrapper to all backends if nagl is available which I think is what we want?
|
pre-commit.ci autofix |
IAlibay
left a comment
There was a problem hiding this comment.
Overall looks good, but yeah we might need to change the backends behaviour. Let me know if you want to have a chat tomorow morning.
| off_toolkit_backend: ambertools | ||
| number_of_conformers: None | ||
| nagl_model: None | ||
| forcefields: None |
There was a problem hiding this comment.
How about including an example of this under the settings help section?
There was a problem hiding this comment.
That section is already getting quite big, I think it would be better to point to the docs and have small examples there that users can copy for some different options, this would simplify the CLI help message as well!
There was a problem hiding this comment.
Added the new options to the CLI settings template here
| settings = { | ||
| "partial_charge": { | ||
| "method": "forcefield", | ||
| "settings": {"forcefields": ["openff_unconstrained-2.3.0"]}, |
There was a problem hiding this comment.
[nit] Any reason for using unconstrained here? Might be better to use the default we use day-to-day.
There was a problem hiding this comment.
No was just trying different one, will change to the normall one.
| if not overwrite: | ||
| return offmol | ||
|
|
||
| if method.lower() == "forcefield": |
There was a problem hiding this comment.
Can we have a check for the other way around too? I'm thinking new users might not easily know you need to set both - especially via the CLI.
There was a problem hiding this comment.
Add the reverse check and test.
|
pre-commit.ci autofix |
| Only ``ambertools`` and ``rdkit`` `off_toolkit_backend`` options | ||
| are supported. A maximum of one conformer is allowed. | ||
|
|
||
| ``forcefield``: |
There was a problem hiding this comment.
I've been thinking about the impact of doing this - i.e. what would this mean to users if we merged this PR with a forcefield entry here and how confusing it would be at the Protocol level.
Is there any way we could not update these settings and just have it as a separate arg that gets picked up from the YAML file (i.e. I think right now we only need this for the CLI?).
There was a problem hiding this comment.
I don't love it, but what if we a) created a subclass of settings specifically for the CLI, or b) just allowed extras?
There was a problem hiding this comment.
I think this would depend on what we do with #2132, if we say that no charge assignment will be done by OpenFE and set the partial charge settings to None by default and have a warning that the option is deprecated and ignored at the protocol level then using this as the CLI charge settings class would be fine.
If not would we not want a to get the pydantic validation on the settings?
There was a problem hiding this comment.
I think this PR has to try to exist standalone of any follow up. There's a good chance we won't be able to deal with the other PR properly ahead of the next release. It would be better if we could safely merge this PR first.
I'm going to advocate for a specific CLI settings subclass for now.
| "via `forcefields`." | ||
| ) | ||
| raise ValueError(errmsg) | ||
| elif forcefields is not None: |
There was a problem hiding this comment.
This can pass even if forcefields is an empty list,
There was a problem hiding this comment.
Thanks this should be caught now!
|
pre-commit.ci autofix |
|
pre-commit.ci autofix |
|
From today's iteration meeting - we should add a test for a system with virtual sites. |
IAlibay
left a comment
There was a problem hiding this comment.
Just the one thing, otherwise it looks good to me - approving early.
Co-authored-by: Irfan Alibay <IAlibay@users.noreply.github.com>
Co-authored-by: Irfan Alibay <IAlibay@users.noreply.github.com>
|
pre-commit.ci autofix |
for more information, see https://pre-commit.ci
Fixes #2116, #2117
LLM / AI generated code disclosure
LLMs or other AI-powered tools (beyond simple IDE use cases) were used in this contribution: yes / no
If yes, please provide details here: No
Checklist
newsentry, or the changes are not user-facing.pre-commit.ci autofix.Manual Tests: these are slow so don't need to be run every commit, only before merging and when relevant changes are made (generally at reviewer-discretion).
Developers certificate of origin