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

Conformer generation failed for some of the benchmarkset molecules #321

Closed
proteneer opened this issue May 14, 2019 · 11 comments
Closed

Conformer generation failed for some of the benchmarkset molecules #321

proteneer opened this issue May 14, 2019 · 11 comments

Comments

@proteneer
Copy link
Collaborator

For some of the ring-cage host guest systems, the conformer generation step (possibly from charge assignment) fails:

from simtk.openmm.app import PDBFile
from openforcefield.topology import Molecule, Topology
from openforcefield.typing.engines.smirnoff import ForceField

sdf_mol = Molecule('/home/yzhao/Code/benchmarksets/input_files/cb7-set1/sdf/guest-17.sdf')
force_field = ForceField('smirnoff99Frosst.offxml')

# Parametrize the ligand molecule by creating a Topology object from it
ligand_system = force_field.create_openmm_system(sdf_mol.to_topology())
Unable to load toolkit <openforcefield.utils.toolkits.RDKitToolkitWrapper object at 0x7f52a02690b8>.
Unable to load toolkit <openforcefield.utils.toolkits.AmberToolsToolkitWrapper object at 0x7f52a02690b8>.
Warning: OEMMFFParams::PrepMol() : unable to type atom 0 N 
Warning: OEMMFFParams::PrepMol() : unable to type atom 1 N 
Warning: OEMMFFParams::PrepMol() : unable to type atom 12 H 
Warning: OEMMFFParams::PrepMol() : unable to type atom 13 H 
Warning: OEMMFFParams::PrepMol() : unable to type atom 14 H 
Warning: OEMMFFParams::PrepMol() : unable to type atom 15 H 
Warning: OEMMFFParams::PrepMol() : unable to type atom 16 H 
Warning: OEMMFFParams::PrepMol() : unable to type atom 17 H 
Warning: force field setup failed due to missing parameters for molecule MOL
Traceback (most recent call last):
  File "system_setup.py", line 9, in <module>
    ligand_system = force_field.create_openmm_system(sdf_mol.to_topology())
  File "/home/yzhao/Code/timemachine/openforcefield/openforcefield/typing/engines/smirnoff/forcefield.py", line 863, in create_openmm_system
    parameter_handler.create_force(system, topology, **kwargs)
  File "/home/yzhao/Code/timemachine/openforcefield/openforcefield/typing/engines/smirnoff/parameters.py", line 2027, in create_force
    temp_mol.generate_conformers(num_conformers=10, toolkit_registry=toolkit_registry)
  File "/home/yzhao/Code/timemachine/openforcefield/openforcefield/topology/molecule.py", line 1947, in generate_conformers
    clear_existing=clear_existing)
  File "/home/yzhao/Code/timemachine/openforcefield/openforcefield/utils/toolkits.py", line 3027, in call
    return method(*args, **kwargs)
  File "/home/yzhao/Code/timemachine/openforcefield/openforcefield/utils/toolkits.py", line 1130, in generate_conformers
    raise Exception("OpenEye Omega conformer generation failed")
Exception: OpenEye Omega conformer generation failed
@proteneer
Copy link
Collaborator Author

Benchmark sets can be found here: https://github.com/MobleyLab/benchmarksets/tree/master/input_files

@j-wags
Copy link
Member

j-wags commented May 14, 2019

@SimonBoothroyd is out today, but he had similar problems with conformer generation for ring systems in the property calculator.

Simon eventually resorted to using externally-generated charges for rings using the charge_from_molecules kwarg to create_openmm_system.

@jchodera
Copy link
Member

This is an OpenEye toolkit MMFF type assignment issue. We should be able to easily construct a test case where you simply try to generate conformers with Omega and report that to their bug tracker.

@proteneer
Copy link
Collaborator Author

proteneer commented May 15, 2019

If I already have a starting geometry, why can't I just use that directly to do the AM1 calculations? This is a ring cage so there isn't that much conformational flexibility anyways.

@jchodera
Copy link
Member

If I already have a starting geometry, why can't I just use that directly to do the AM1 calculations? This is a ring cage so there isn't that much conformational flexibility anyways.

We generate geometries automatically in an effort to make the force field less dependent on the specific choice of geometry you use. If we did not do this, you could get vastly different behavior simply due to which conformer you picked.

In particular, we use the canonical ELF10 AM1-BCC procedure, which is intended to prevent large geometry-dependent charge fluctuations.

You are supposed to be able to specify your own partial charges by providing a charged molecule as an optional argument to ForceField.create_openmm_system(), but I'm not seeing that argument implemented.

@j-wags : Did this user-specified charge assignment option accidentally fall off the roadmap somehow? This is a critical feature.

@andrrizzi
Copy link
Collaborator

I'm not seeing that argument implemented

I think it is implemented as Jeff mentioned, but it is absorbed in the kwargs that is forwarded to one of the handlers, and we probably forgot to include it explicitly in the docstring.

@jchodera
Copy link
Member

I think it is implemented as Jeff mentioned, but it is absorbed in the kwargs that is forwarded to one of the handlers, and we probably forgot to include it explicitly in the docstring.

Great! Can you create an issue to fix the docs?

@andrrizzi
Copy link
Collaborator

Can you create an issue to fix the docs?

I've already fixed it in #322 .

@guoweiqi
Copy link

guoweiqi commented May 28, 2019

OEChem also has difficulties generating conformers for very basic charged molecules, like butylammonium (https://github.com/MobleyLab/benchmarksets/blob/master/input_files/cd-set1/sdf/guest-1.sdf)

@guoweiqi
Copy link

Looks like using mol2 instead of sdf files works

@j-wags j-wags added this to the 0.5.1 milestone May 30, 2019
@j-wags j-wags modified the milestones: 0.5.1, 0.5.0 Jun 10, 2019
@j-wags
Copy link
Member

j-wags commented Aug 13, 2019

I'm finally getting back to this. The SDF in question can be loaded and processed, but only if the atomic formal charges are updated. @guoweiqi already figured this out, and opened an Issue + PR at MobleyLab/benchmarksets#68 and MobleyLab/benchmarksets#69.

I think it's reasonable to say that this issue is closed, and the root cause is that the underlying data may be incorrect. Discussion on that should continue on the relevant PRs in benchmarksets

@j-wags j-wags closed this as completed Aug 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants