-
Notifications
You must be signed in to change notification settings - Fork 20
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
Allow Openeye for charge generation #489
Comments
Duplicate of #480? |
I will point out that the context manager folks keep pointing to is, as far as I can tell, both an undocumented and untested component of the OpenFF toolkit. We've been burned already with private methods getting killed off silently upstream. Ideally OpenFF needs to make this a true supported method before we can use it here. |
Good point about the manager in the toolkit causing issues down the line. Another option might be to extend the version implemented in #479 ( openfe/openfe/utils/remove_oechem.py Line 10 in 304d85a
|
For context, the reason we have (for now) disabled OEChem backend is that we were getting an error where some molecules were generating different SMILES from rdkit and oechem so charge generation would fail. I'm a little wary of directly playing with the GLOBAL_TOOLKIT_REGISTRY as it looks a little in flux We could probably build you a backdoor to do let you use oechem in a hacky way for now @jthorton not sure I follow your thoughts on toolkit version? |
I'd prefer it if we didn't have to extend our maintenance burden unnecessarily. If someone can ask OpenFF to make that method official & supported that'd be great. In any case, in order to offer user supported selections I think we'll need to move things into the protocol unit. If so, I will need to look at things after I'm back. |
Note, rather than being hacky I would ask that we instead officially support users passing charges directly to SmallMoleculeComponents. It's something we need anyways. Once that's done we can easily just allow system generator to pick up those charges. |
I see is this due to some sort of cache?
Thanks, but I should be able to use library charges to pass in the charges computed locally. Provided I use openmm/openmmforcefields#288
Is the idea here to allow user-generated charges like RESP which can't currently be generated on the fly as well as the openeye/ambertools am1bcc charges? If so (openmm/openmmforcefields#288) would also allow this as users can add molecule specific library charges to the forcefield which might be a work around until you can pass the charges through the system generator method.
I was thinking you could copy the context manager from the toolkit until its officially supported there but I agree that playing with the global toolkit is never fun. |
The idea is that currently SMCs will read in charges stored in OpenFF Molecules if created from them. It's rather useful if you're playing around with charges using the OpenFF TK. All we need to do is make this official and add a check on SMC creation that either removes the charges by default (to allow bad things from happening), or allow users to use the input charges if they really want. Re: passing serialised information through, that can be another entry point, but ideally I'd prefer not have folks jump through hoops if they already have the charges in their Molecule. |
@jthorton the error with OEChem is we're storing molecules initially as an rdkit Mol, then creating an OpenFF Mol, then on charge generation this was converting to an OEChem Mol. It looks like there was a sanity check in
|
PR #479 removed the use of oechem which causes charge generation to go through ambertools sqm which is much slower than openeye and also leads to inconsistent charges as my bespokefit dihedrals are fit against elf10 charges. Would it be possible not to enforce this but allow the passing of some global toolkit registry which can be set using the context manager in the toolkit?
The text was updated successfully, but these errors were encountered: