openmoltools.openeye.molecule_to_mol2 changes atom names

[jchodera]

molecule_to_mol2 uses the oechem high-level molecule writer, which modifies/normalizes many properties of the molecule. This means, for example, that atom names from a PDB residue (e.g. HH31, CH3, ND) will be renamed to Tripos standards (e.g. H1, C1, N1).

I would like to change this to use the low-level molecule writer, which would preserve the atom names.

Would this break anyone's code?

I can add this as an optional flag and retain the default behavior, but I think the default behavior should be to preserve existing information, rather than corrupt/normalize it.

[davidlmobley]

I agree with this.

On Fri, Apr 8, 2016 at 6:37 PM, John Chodera [email protected]
wrote:

molecule_to_mol2
https://github.com/choderalab/openmoltools/blob/master/openmoltools/openeye.py#L274-L326
uses the oechem high-level molecule writer, which modifies/normalizes
many properties of the molecule
https://docs.eyesopen.com/toolkits/python/oechemtk/molreadwrite.html#molecular-property-preservation.
This means, for example, that atom names from a PDB residue (e.g. HH31,
CH3, ND) will be renamed to Tripos standards (e.g. H1, C1, N1).

I would like to change this to use the low-level molecule writer
https://docs.eyesopen.com/toolkits/python/oechemtk/OEChemFunctions/OEWriteMol2File.html#OEChem::OEWriteMol2File,
which would preserve the atom names.

Would this break anyone's code?

I can add this as an optional flag and retain the default behavior, but I
think the default behavior should be to preserve existing information,
rather than corrupt/normalize it.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#215

David Mobley
Associate Professor
Department of Pharmaceutical Sciences
Department of Chemistry
3134B Natural Sciences I
University of California, Irvine
Irvine, CA 92697
[email protected]
work (949) 824-6383
cell (949) 385-2436

[andrrizzi]

I did not know that, thanks! I don't think this will break anything yank-related but I'd gladly fix the eventual errors than having the current behavior.

[andrrizzi]

I made few experiments and as far I can tell it is not possible to save a multi-structure OE molecule with a single call of OEWriteMol2File, while OEWriteMolecule handles it just fine. Maybe it is possible to work around this by appending all the conformers to an existing file in a for loop?

[davidlmobley]

Um, seems like you should be using the high-level writer with the
forcefield flavor, I believe -- i.e. a snipped from some code I was using
testing this:

ofs = oechem.oemolostream( os.path.join(outdir, cid+'_n.mol2'))
ofs.SetFlavor( oechem.OEFormat_MOL2, oechem.OEOFlavor_MOL2_Forcefield )
oechem.OEWriteMolecule( ofs, mol)
ofs.close()

As recommended in the document John linked to, OEWriteConstMolecule can
also be helpful.

A tangential issue we may need to think through - right now, quacpac
partial charge assignment modifies atom types. This is fine as long as the
molecules we are working with internally have Tripos atom types and are
"normal", but if we start working with and trying to charge forcefield
flavor molecules it becomes a problem. Currently when testing this, I did
the charge calculation but then just copied the new charges back to the
original molecule before writing (with the approach above).

This is a known issue at OpenEye (Christopher Bayly and others there are
aware) and they tell me it will be addressed eventually.

Thanks.

On Fri, Apr 15, 2016 at 3:15 PM, Andrea Rizzi [email protected]
wrote:

I made few experiments and as far I can tell it is not possible to save a
multi-structure OE molecule with a single call of OEWriteMol2File, while
OEWriteMolecule handles it just fine. Maybe it is possible to work around
this by appending all the conformers to an existing file in a for loop?

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#215 (comment)

David Mobley
[email protected]
949-385-2436

[andrrizzi]

Sorry if I wasn't clear (or if I don't understand). The problem is that we don't want use neither OEWriteMolecule() nor OEWriteConstMolecule() because they both change the atom type names. On the other hand, the low level OEWriteMol2File() doesn't change atom type name but it cannot handle multi-conformer OE molecules (while the high-level OEWriteMolecule() handles them automatically, no OEOFlavor_MOL2_Forcefield needed).

[davidlmobley]

The forcefield flavor high level writer does not change the atom type
names. It was designed specifically for this, so it CAN handle multiple
conformation molecules while preserving atom type names.

DM

On Fri, Apr 15, 2016 at 3:39 PM, Andrea Rizzi [email protected]
wrote:

Sorry if I wasn't clear (or if I don't understand). The problem is that we
don't want use neither OEWriteMolecule() nor OEWriteConstMolecule()
because they both change the atom type names. On the other hand, the low
level OEWriteMol2File() doesn't change atom type name but it cannot
handle multi-conformer OE molecules (while the high-level
OEWriteMolecule() handles them automatically, no OEOFlavor_MOL2_Forcefield
needed).

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#215 (comment)

David Mobley
[email protected]
949-385-2436

[andrrizzi]

Oh, cool! Sorry if I misunderstood.

[davidlmobley]

Do test it though. This is what it is SUPPOSED to do, and it seemed to work
properly when I tried it for that, but I haven't used it extensively yet.

On Fri, Apr 15, 2016 at 3:46 PM, Andrea Rizzi [email protected]
wrote:

Oh, cool! Sorry if I misunderstood.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#215 (comment)

David Mobley
[email protected]
949-385-2436