Comments (9)
Duplicate of #480?
from openfe.
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.
from openfe.
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?
from openfe.
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
from openfe.
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.
from openfe.
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.
from openfe.
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 see is this due to some sort of cache?
We could probably build you a backdoor to do let you use oechem in a hacky way for now
Thanks, but I should be able to use library charges to pass in the charges computed locally. Provided I use openmm/openmmforcefields#288
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.
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.
@jthorton not sure I follow your thoughts on toolkit version?
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.
from openfe.
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.
from openfe.
@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 to_oechem
that the SMILES didn't change, we found cases where RDKit and OEChem disagreed on the stereo label on some atoms so you couldn't go RDKit->OEChem via OpenffTK. Traceback below.
'Traceback (most recent call last):\n File "/opt/conda/lib/python3.10/site-packages/gufe/protocols/protocolunit.py", line 319, in execute\n outputs = self._execute(context, **inputs)\n File "/opt/conda/lib/python3.10/site-packages/openfe/protocols/openmm_rfe/equil_rfe_methods.py", line 674, in _execute\n outputs = self.run(scratch_basepath=ctx.scratch, shared_basepath=ctx.shared)\n File "/opt/conda/lib/python3.10/site-packages/openfe/protocols/openmm_rfe/equil_rfe_methods.py", line 414, in run\n system_generator.create_system(offmol.to_topology().to_openmm(),\n File "/opt/conda/lib/python3.10/site-packages/openmmforcefields/generators/system_generators.py", line 316, in create_system\n self.template_generator.add_molecules(molecules)\n File "/opt/conda/lib/python3.10/site-packages/openmmforcefields/generators/template_generators.py", line 125, in add_molecules\n self._molecules.update( { molecule.to_smiles() : molecule for molecule in molecules } )\n File "/opt/conda/lib/python3.10/site-packages/openmmforcefields/generators/template_generators.py", line 125, in <dictcomp>\n self._molecules.update( { molecule.to_smiles() : molecule for molecule in molecules } )\n File "/opt/conda/lib/python3.10/site-packages/openff/toolkit/topology/molecule.py", line 1619, in to_smiles\n smiles = to_smiles_method(self, isomeric, explicit_hydrogens, mapped)\n File "/opt/conda/lib/python3.10/site-packages/openff/toolkit/utils/openeye_wrapper.py", line 1769, in to_smiles\n oemol = self.to_openeye(molecule)\n File "/opt/conda/lib/python3.10/site-packages/openff/toolkit/utils/openeye_wrapper.py", line 1531, in to_openeye\n oemol, off_to_oe_idx = self._connection_table_to_openeye(\n File "/opt/conda/lib/python3.10/site-packages/cachetools/__init__.py", line 737, in wrapper\n v = func(*args, **kwargs)\n File "/opt/conda/lib/python3.10/site-packages/openff/toolkit/utils/openeye_wrapper.py", line 1426, in _connection_table_to_openeye\n raise InconsistentStereochemistryError(\nopenff.toolkit.utils.exceptions.InconsistentStereochemistryError: Programming error: OpenEye atom stereochemistry assumptions failed. The atom in the oemol has stereochemistry None and the atom in the offmol has stereoheometry S.\n'
from openfe.
Related Issues (20)
- [docs] find new home for `OpenFE_showcase_1_RBFE_of_T4lysozyme.ipynb` example
- Using customized force field for small molecules HOT 8
- raise a warning if a user supplies an unsupported key in a settings yaml
- CalledProcessError: 9 HOT 2
- Fix OpenFE tests to match main on Lomap
- Validate OpenFE working on latest of our key tools
- Add rever instructions to release instructions in the wiki
- Add install instructions for the conda lock files
- Issue with PyMBAR4
- Using OPC water models for RBFE calculations HOT 3
- Using other versions of small ligand ff (GAFF) instead of the default one HOT 1
- [CLI] inspect command for json output files
- Review zenodo authors
- CI fails with latest matplotlib
- 4-point water models fail with RBFE Protocol HOT 2
- `PersesAtomMapper` combined with minimal redundant networks can yield more than one edge/mapping connecting two ligands in a `LigandNetwork` HOT 5
- Gather should support result.json.gz HOT 1
- Questions about softcore potential for vdW and electrostatic interactions HOT 1
- Checkpoint restoration HOT 3
- Apparent convergence issues
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from openfe.