Openff-toolkit: Current OpenEyeToolkitWrapper.from_file interpret incorrectly AlkEthOH atom types

[andrrizzi]

Running this script using the bleeding-edge code currently in PR #164 (soon to be merged to the topology branch)

#!/bin/env python

from openforcefield.topology import Molecule
molecule = Molecule.from_file('AlkEthOH_r209.mol2')

atoms_elements = [atom.element.symbol for atom in molecule.atoms]
print(atoms_elements)

prints

['C', 'C', 'C', 'C', 'C', 'C', 'C', 'C', 'C', 'Os', 'Os', 'O', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'Ho']

Note the two osmiums and the final holmium elements instead of oxygen and hydrogen. In the mol2 file (attached here), these atoms have types OS and HO respectively.

This problem is causing the example in examples/SMIRNOFF_comparison/compare_set_energies.py to fail because openforcefield.topology.Topology.from_openmm(openmm_topology, unique_molecules) can't find a match between the molecules in openmm_topology and unique_molecules.

I'm not sure if we already settle on a solution to avoid problems with mol2 atom types.

AlkEthOH_r209.mol2.zip

[j-wags]

Quick reply, will look more later: That file has AMBERTools-style atom types. It's probably an intermediate output from tleap/antechamber. Usually for these molecules we have a correct ("SYBYL", I think) mol2 somewhere nearby.

[j-wags]

It's worth thinking about if we want to throw an error/warning when it looks like we're reading one of these AMBERTools-derived files. Something like "Does your ligand _really_ have an Osmium? Consider checking your input".

[davidlmobley]

We should not support reading molecules with GAFF atom typing; the molecules in the repo should just be switched back to sybyl type using something like antechamber -i molname.mol2 -fi mol2 -o new_molname.mol2 -fo mol2 -at sybyl.

(It's worth noting, tangentially, that the OpenEye toolkits DO support reading such molecules using the ForceField flavor mol2 reader, but in general we should not do so.)

I'd suggest we raise an exception if we encounter elements we don't expect in input molecules.

[j-wags]

Updated examples/SMIRNOFF_comparison/AlkEthOH_inputfiles.tar.gz to have a copy of each mol2 with sybyl atom types in https://github.com/openforcefield/openforcefield/pull/164/commits/0d8f0a757e830061c7d1524299409b307b97c580

[andrrizzi]

In the next PR, I'm going to add checks for Osmium and Holmium when parsing mol2 files with the OE toolkit.

I'll also clean up a little the AlkEthOH files spread across the repo.

• There are 3 identical files named differently in data/molecules: AlkEthOH-tripos.mol2, test_filt1_tripos.mol2, AlkEthOH_test_filt1_tripos.mol2, which correspond to a single files containing the AlkEthOH molecules in test_filt1/. I'm going to keep only 2 of these.
• If we are going to ship the whole AlkEthOH dataset with openforcefield anyway, we might as well make it accessible to all tests so I'm thinking about moving the file examples/SMIRNOFF_comparison to data/molecules/ and remove the duplicate files that are there.
• The data will be accessible with get_data_filename as usual, but I'll add a shortcut function in tests/utils.py:get_AlkEthOH_filepath('AlkEthOH_r51') to retrieve the file paths.
• I'm going to remove the leap_in scripts and the GAFF-type mol2 in the AlkEthOH directory for now. They won't be used in the repo and we can always retrieve them from the original source if we'll end up needing these files.

[j-wags]

There are 3 identical files named differently in data/molecules: AlkEthOH-tripos.mol2, test_filt1_tripos.mol2, AlkEthOH_test_filt1_tripos.mol2, which correspond to a single files containing the AlkEthOH molecules in test_filt1/. I'm going to keep only 2 of these.
If we are going to ship the whole AlkEthOH dataset with openforcefield anyway, we might as well make it accessible to all tests so I'm thinking about moving the file examples/SMIRNOFF_comparison to data/molecules/ and remove the duplicate files that are there.
The data will be accessible with get_data_filename as usual, but I'll add a shortcut function in tests/utils.py:get_AlkEthOH_filepath('AlkEthOH_r51') to retrieve the file paths.

These all sound good

I'm going to remove the leap_in scripts and the GAFF-type mol2 in the AlkEthOH directory for now. They won't be used in the repo and we can always retrieve them from the original source if we'll end up needing these files.

Could you clarify -- Is the "original source" the openforcefield-data repo?

[andrrizzi]

Could you clarify -- Is the "original source" the openforcefield-data repo?

Correct, that's what I meant.

[andrrizzi]

And by "retrieve" them, I meant we can find them there and put them back in openforcefield if we find out that we actually need the leap scripts and the GAFF-typed mol2 files.

[j-wags]

Sounds great!

[andrrizzi]

This was implemented in #168 and it's now merged on the development branch topology.