Lots of OpenEye warnings #201

jchodera · 2016-03-06T13:01:27Z

I'm now seeing a ton of OpenEye warnings in travis:

test_openeye.test_charge_fail1 ... Warning: [4-(2,4-dichloro-5-methoxy-phenyl)iminio-6-methoxy-7-[3-(4-methylpiperazin-1-yl)propoxy]quinolin-1-ium-3-ylidene]methyleneazanide failed due to unspecified stereochemistry with strict stereo enabled
ok (0.0292s)
test_openeye.test_charge_fail2 ... Warning: [4-(2,4-dichloro-5-methoxy-phenyl)iminio-6-methoxy-7-[3-(4-methylpiperazin-1-yl)propoxy]quinolin-1-ium-3-ylidene]methyleneazanide failed due to unspecified stereochemistry with strict stereo enabled
ok (0.0284s)
test_openeye.test_charge_success1 ... Warning: BCIChargeCorrector: BCI charge corrections will not be done for
Warning: [4-(2,4-dichloro-5-methoxy-phenyl)iminio-6-methoxy-7-[3-(4-methylpiperazin-1-yl)propoxy]quinolin-1-ium-3-ylidene]methyleneazanide because the bcc parameter for the C33-N34 bond (BCIType 150225) is missing
Warning:  Getting BCCs for [4-(2,4-dichloro-5-methoxy-phenyl)iminio-6-methoxy-7-[3-(4-methylpiperazin-1-yl)propoxy]quinolin-1-ium-3-ylidene]methyleneazanide was unsuccessful; stopping the charging process for this molecule
Warning:  Getting BCCs for [4-(2,4-dichloro-5-methoxy-phenyl)iminio-6-methoxy-7-[3-(4-methylpiperazin-1-yl)propoxy]quinolin-1-ium-3-ylidene]methyleneazanide was unsuccessful; stopping the charging process for this molecule
ok (2.4720s)
test_openeye.test_charge_success2 ... Warning: BCIChargeCorrector: BCI charge corrections will not be done for
Warning: [4-(2,4-dichloro-5-methoxy-phenyl)iminio-6-methoxy-7-[3-(4-methylpiperazin-1-yl)propoxy]quinolin-1-ium-3-ylidene]methyleneazanide because the bcc parameter for the C33-N34 bond (BCIType 150225) is missing
Warning:  Getting BCCs for [4-(2,4-dichloro-5-methoxy-phenyl)iminio-6-methoxy-7-[3-(4-methylpiperazin-1-yl)propoxy]quinolin-1-ium-3-ylidene]methyleneazanide was unsuccessful; stopping the charging process for this molecule
Warning:  Getting BCCs for [4-(2,4-dichloro-5-methoxy-phenyl)iminio-6-methoxy-7-[3-(4-methylpiperazin-1-yl)propoxy]quinolin-1-ium-3-ylidene]methyleneazanide was unsuccessful; stopping the charging process for this molecule
ok (2.0829s)
test_openeye.test_binary_mixture_rename ... Warning: SelectElfDiverseConfs: elfPop.NumConfs 1 <= elfLimit 1
Warning: SelectElfDiverseConfs: elfPop.NumConfs 1 <= elfLimit 1

@davidlmobley: Have you noticed these before?

The text was updated successfully, but these errors were encountered:

davidlmobley · 2016-03-06T16:04:33Z

Those seem to be new.

On Sun, Mar 6, 2016, 5:01 AM John Chodera [email protected] wrote:

I'm now seeing a ton of OpenEye warnings in travis:

test_openeye.test_charge_fail1 ... Warning: [4-(2,4-dichloro-5-methoxy-phenyl)iminio-6-methoxy-7-[3-(4-methylpiperazin-1-yl)propoxy]quinolin-1-ium-3-ylidene]methyleneazanide failed due to unspecified stereochemistry with strict stereo enabled
ok (0.0292s)
test_openeye.test_charge_fail2 ... Warning: [4-(2,4-dichloro-5-methoxy-phenyl)iminio-6-methoxy-7-[3-(4-methylpiperazin-1-yl)propoxy]quinolin-1-ium-3-ylidene]methyleneazanide failed due to unspecified stereochemistry with strict stereo enabled
ok (0.0284s)
test_openeye.test_charge_success1 ... Warning: BCIChargeCorrector: BCI charge corrections will not be done for
Warning: [4-(2,4-dichloro-5-methoxy-phenyl)iminio-6-methoxy-7-[3-(4-methylpiperazin-1-yl)propoxy]quinolin-1-ium-3-ylidene]methyleneazanide because the bcc parameter for the C33-N34 bond (BCIType 150225) is missing
Warning: Getting BCCs for [4-(2,4-dichloro-5-methoxy-phenyl)iminio-6-methoxy-7-[3-(4-methylpiperazin-1-yl)propoxy]quinolin-1-ium-3-ylidene]methyleneazanide was unsuccessful; stopping the charging process for this molecule
Warning: Getting BCCs for [4-(2,4-dichloro-5-methoxy-phenyl)iminio-6-methoxy-7-[3-(4-methylpiperazin-1-yl)propoxy]quinolin-1-ium-3-ylidene]methyleneazanide was unsuccessful; stopping the charging process for this molecule
ok (2.4720s)
test_openeye.test_charge_success2 ... Warning: BCIChargeCorrector: BCI charge corrections will not be done for
Warning: [4-(2,4-dichloro-5-methoxy-phenyl)iminio-6-methoxy-7-[3-(4-methylpiperazin-1-yl)propoxy]quinolin-1-ium-3-ylidene]methyleneazanide because the bcc parameter for the C33-N34 bond (BCIType 150225) is missing
Warning: Getting BCCs for [4-(2,4-dichloro-5-methoxy-phenyl)iminio-6-methoxy-7-[3-(4-methylpiperazin-1-yl)propoxy]quinolin-1-ium-3-ylidene]methyleneazanide was unsuccessful; stopping the charging process for this molecule
Warning: Getting BCCs for [4-(2,4-dichloro-5-methoxy-phenyl)iminio-6-methoxy-7-[3-(4-methylpiperazin-1-yl)propoxy]quinolin-1-ium-3-ylidene]methyleneazanide was unsuccessful; stopping the charging process for this molecule
ok (2.0829s)
test_openeye.test_binary_mixture_rename ... Warning: SelectElfDiverseConfs: elfPop.NumConfs 1 <= elfLimit 1
Warning: SelectElfDiverseConfs: elfPop.NumConfs 1 <= elfLimit 1

@davidlmobley https://github.com/davidlmobley: Have you noticed these
before?

—
Reply to this email directly or view it on GitHub
#201.

andrrizzi · 2016-03-06T18:32:01Z

I'm not sure if this is the bit that is new, but I'm also getting a bunch of Warning: SelectElfDiverseConfs: elfPop.NumConfs 1 <= elfLimit 1. I'm investigating to understand if it is related to OpenEye version or if it's something in openmoltools.

jchodera · 2016-03-06T18:57:07Z

I am guessing that this warning has suddenly appeared due to an update of the OpenEye toolkits on PyPI. Might be worth submitting a ticket to OpenEye support to see if there's something that we should worry about in those messages.

andrrizzi · 2016-03-06T20:45:31Z

I've isolated the warnings in this code:

from openeye import oechem, oeomega, oequacpac

def test(smiles, rms, strict_stereo):
    print '\nParsing molecule {} with RMS={} and strict_stereo={}'.format(smiles, rms, strict_stereo)

    molecule = oechem.OEMol()
    if not oechem.OEParseSmiles(molecule, smiles):
        raise ValueError("The supplied SMILES '%s' could not be parsed." % smiles)

    omega = oeomega.OEOmega()
    omega.SetRMSThreshold(rms)  # Word to the wise: skipping this step can lead to significantly different charges!
    omega.SetStrictStereo(strict_stereo)

    status = omega(molecule)  # generate conformation
    if not status:
        raise RuntimeError("omega returned error code %d" % status)

    print 'OEAssignPartialCharges...'
    status = oequacpac.OEAssignPartialCharges(molecule, oequacpac.OECharges_AM1BCCSym)  # AM1BCCSym recommended by Chris Bayly to KAB+JDC, Oct. 20 2014.
    if not status:
        raise RuntimeError("OEAssignPartialCharges returned error code %d" % status)

if __name__ == '__main__':
    smiles1 = 'Cc1ccc(cc1C#Cc2cnc3n2nccc3)C(=O)Nc4ccc(c(c4)C(F)(F)F)CN5CCN(CC5)C'  # ponatinib inhibitor
    smiles2 = "CN1CCN(CC1)CCCOc2cc3c(cc2OC)C(=[NH+]c4cc(c(cc4Cl)Cl)OC)C(=C=[N-])C=[NH+]3"  # fails with strict stereo

    test(smiles1, rms=1.0, strict_stereo=True)
    test(smiles1, rms=0.5, strict_stereo=True)
    test(smiles2, rms=1.0, strict_stereo=False)

with openeye-2016.2.1 this produces

Parsing molecule Cc1ccc(cc1C#Cc2cnc3n2nccc3)C(=O)Nc4ccc(c(c4)C(F)(F)F)CN5CCN(CC5)C with RMS=1.0 and strict_stereo=True
OEAssignPartialCharges...
Warning: SelectElfDiverseConfs: elfPop.NumConfs 1 <= elfLimit 1

Parsing molecule Cc1ccc(cc1C#Cc2cnc3n2nccc3)C(=O)Nc4ccc(c(c4)C(F)(F)F)CN5CCN(CC5)C with RMS=0.5 and strict_stereo=True
OEAssignPartialCharges...

Parsing molecule CN1CCN(CC1)CCCOc2cc3c(cc2OC)C(=[NH+]c4cc(c(cc4Cl)Cl)OC)C(=C=[N-])C=[NH+]3 with RMS=1.0 and strict_stereo=False
OEAssignPartialCharges...
Warning: BCIChargeCorrector: BCI charge corrections will not be done for
Warning:  because the bcc parameter for the C1-N27 bond (BCIType 150225) is missing
Warning:  Getting BCCs for  was unsuccessful; stopping the charging process for this molecule
Warning:  Getting BCCs for  was unsuccessful; stopping the charging process for this molecule

with openeye-2015.6.5 the output is

Parsing molecule Cc1ccc(cc1C#Cc2cnc3n2nccc3)C(=O)Nc4ccc(c(c4)C(F)(F)F)CN5CCN(CC5)C with RMS=1.0 and strict_stereo=True
OEAssignPartialCharges...

Parsing molecule Cc1ccc(cc1C#Cc2cnc3n2nccc3)C(=O)Nc4ccc(c(c4)C(F)(F)F)CN5CCN(CC5)C with RMS=0.5 and strict_stereo=True
OEAssignPartialCharges...

Parsing molecule CN1CCN(CC1)CCCOc2cc3c(cc2OC)C(=[NH+]c4cc(c(cc4Cl)Cl)OC)C(=C=[N-])C=[NH+]3 with RMS=1.0 and strict_stereo=False
OEAssignPartialCharges...
Warning: BCC charge corrections will not be done for molecule 
         because bcc parameters for C1--N27 bond can't be assigned

so

the warnings come both from ``OEAssignPartialCharges`
SelectElfDiverseConfs warning pops up only with the new OpenEye version and disappears when the number of conformations returned by Omega is big
the other warning is old

I'll open a bug report about this on the OpenEye support page asking for clarification.

jchodera · 2016-03-06T21:59:06Z

Thanks! Some of these may be problems with our input rather than bugs, but it works be useful to know if either is the case!

davidlmobley · 2016-03-07T04:10:34Z

It's possible they have changed the default OE charging protocol in this
version. Chris was working on a new version of his charge ELF stuff, I
think, and this newer version is best behaved with more conformers. That
sounds suspiciously consistent with these warnings.

Thanks.

On Sun, Mar 6, 2016 at 1:59 PM, John Chodera [email protected]
wrote:

Thanks! Some of these may be problems with our input rather than bugs, but
it works be useful to know if either is the case!

—
Reply to this email directly or view it on GitHub
#201 (comment)
.

David Mobley
[email protected]
949-385-2436

jchodera · 2016-03-07T08:24:06Z

Was the "canonical" charging method updated to? Maybe we should looking Christopher.

jchodera · 2016-03-07T08:24:27Z

The online release notes may have clues.

jchodera · 2016-03-07T11:53:05Z

No clues in the online release notes: https://docs.eyesopen.com/toolkits/python/releasenotes/releasenotes/index.html I'd suggest we email Christopher Bayly if we don't get a response back from OE support.

davidlmobley · 2016-03-07T17:14:08Z

I think he was making changes to the canonical charging method, yes -
basically at the level of improving how conformer selection for charging is
handled. My recollection is that the overall protocol is similar but now he
uses multiple conformations rather than just one (?).

DM

On Mon, Mar 7, 2016 at 3:53 AM, John Chodera [email protected]
wrote:

No clues in the online release notes:

https://docs.eyesopen.com/toolkits/python/releasenotes/releasenotes/index.html

I'd suggest we email Christopher Bayly if we don't get a response back from
OE support.

—
Reply to this email directly or view it on GitHub
#201 (comment)
.

David Mobley
[email protected]
949-385-2436

jchodera · 2016-03-07T17:44:38Z

Well, we have to figure out (1) how to ensure the old protocol is still reproducible, and (2) what the new protocol is and how to implement it correctly.

davidlmobley · 2016-03-07T17:47:17Z

Indeed.

On Mon, Mar 7, 2016 at 9:44 AM, John Chodera [email protected]
wrote:

Well, we have to figure out (1) how to ensure the old protocol is still
reproducible, and (2) what the new protocol is and how to implement it
correctly.

—
Reply to this email directly or view it on GitHub
#201 (comment)
.

David Mobley
[email protected]
949-385-2436

andrrizzi · 2016-03-10T22:50:44Z

After discussion with OE support, we can safely ignore Warning: SelectElfDiverseConfs: elfPop.NumConfs 1 <= elfLimit 1 as this warning should not have been included with the latest release.

The BCIChargeCorrector warning looks like a problem though. As far as I understand, when OE doesn't find a BCC parameter for a certain group it automatically tries to find a matching type. There is no current way to raise an exception through OE's API when this happens but James Haigh suggested this work-around:

    errs = oechem.oeosstream()
    oechem.OEThrow.SetOutputStream(errs)
    status = oequacpac.OEAssignPartialCharges(molecule, oequacpac.OECharges_AM1BCCSym)  # AM1BCCSym recommended by Chris Bayly to KAB+JDC, Oct. 20 2014.
    if 'BCIChargeCorrector: BCI charge corrections will not be done for' in errs.str():
        raise RuntimeError('Warning thrown:\n%s' % errs.str())
    if not status:
        raise RuntimeError("OEAssignPartialCharges returned error code %d" % status)
    oechem.OEThrow.SetOutputStream(oechem.oeerr)

Should we handle this case with an exception in openeye.get_charges()? It will probably make several tests fail. If yes, do we want to fix it before the 0.7.0 release?

davidlmobley · 2016-03-15T17:08:41Z

Is this really something to raise an exception for, or should it be a
warning (a vehement one)?

To put it another way, is this assigning a "reasonable guess" value so that
we can proceed with a warning, or is it an "all bets are off, better not to
do anything" type problem?

I'm at a meeting with Christopher Bayly so I can perhaps ask him if this is
still unclear.

On Thu, Mar 10, 2016 at 2:50 PM, Andrea Rizzi [email protected]
wrote:

After discussion with OE support, we can safely ignore Warning:
SelectElfDiverseConfs: elfPop.NumConfs 1 <= elfLimit 1 as this warning
should not have been included with the last release.

The BCIChargeCorrector warning is a problem though. As far as I
understand, when OE doesn't find a BCC parameter for a certain group it
automatically tries to find a matching type. There is no current way to
raise an exception through OE's API when this happens but James Haigh
suggested this work-around:
errs = oechem.oeosstream()
oechem.OEThrow.SetOutputStream(errs)
status = oequacpac.OEAssignPartialCharges(molecule, oequacpac.OECharges_AM1BCCSym)  # AM1BCCSym recommended by Chris Bayly to KAB+JDC, Oct. 20 2014.
if 'BCIChargeCorrector: BCI charge corrections will not be done for' in errs.str():
    raise RuntimeError('Warning thrown:\n%s' % errs.str())
if not status:
    raise RuntimeError("OEAssignPartialCharges returned error code %d" % status)
oechem.OEThrow.SetOutputStream(oechem.oeerr)
Should we handle this case with an exception in openeye.get_charges()? It
will probably make several tests fail. If yes, do we want to fix it before
the 0.7.0 release?

—
Reply to this email directly or view it on GitHub
#201 (comment)
.

David Mobley
[email protected]
949-385-2436

andrrizzi · 2016-03-15T17:17:08Z

Yes, thank you, this is still unclear.

I don't think I'm expert enough about this topic to judge, but the N in the group =C=[N-] was being assigned a positive partial charge. I understand that the group is not an acceptable tautomeric form. I'd like to know if it safe to go ahead and run the simulation with the partial charges of the reasonable guess, or if it better for the user perspective to stop (i.e. to raise an exception) and ask the user to clarify better the molecule's form.

davidlmobley · 2016-03-15T17:40:38Z

Can you provide files so I can go over them with him?

Thanks.

On Tue, Mar 15, 2016 at 10:17 AM, Andrea Rizzi [email protected]
wrote:

Yes, thank you, this is still unclear.

I don't think I'm expert enough about this topic to judge, but the N in
the group =C=[N-] was being assigned a positive partial charge. I
understand that the group is not an acceptable tautomeric form. I'd like to
know if it safe to go ahead and run the simulation with the partial charges
of the reasonable guess, or if it better for the user perspective to stop
(i.e. to raise an exception) and ask the user to clarify better the
molecule's form.

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

David Mobley
[email protected]
949-385-2436

jchodera · 2016-03-15T17:53:01Z

We should capture the new Bayly-approved workflow for charging so we can eliminate these warnings.

andrrizzi · 2016-03-15T17:53:06Z

Everything I have (code and results) is in my comments above. I think I also forwarded you all the conversation with OE support by mail. Let me know if you need more. Thanks!

davidlmobley · 2016-03-15T17:57:27Z

I don't think using his workflow will fix the issue with the BCC correction
not being available for this case. It sounds like we're using a tautomer
that they don't think should be used or something along those lines. Will
try and bring up with him.

On Tue, Mar 15, 2016 at 10:53 AM, John Chodera [email protected]
wrote:

We should capture the new Bayly-approved workflow for charging so we can
eliminate these warnings.

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

David Mobley
[email protected]
949-385-2436

andrrizzi · 2016-03-15T18:00:40Z

It sounds like we're using a tautomer that they don't think should be used or something along those lines.

Yep. That's why I proposed to raise an exception when that warning appears. We can decide about this after your meeting anyway.

Will try and bring up with him.

Thanks so much.

davidlmobley · 2016-03-15T18:10:24Z

I wonder if a better solution would be to do some sort of tautomer checking
earlier, before getting to this stage. Will try and bring that up too.

On Tue, Mar 15, 2016 at 11:00 AM, Andrea Rizzi [email protected]
wrote:

It sounds like we're using a tautomer that they don't think should be used
or something along those lines.

Yep. That's why I proposed to raise an exception when that warning
appears. We can decide about this after your meeting anyway.

Will try and bring up with him.

Thanks so much.

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

David Mobley
[email protected]
949-385-2436

davidlmobley · 2016-03-16T04:38:41Z

So I talked to Christopher about this, and the conclusion basically was
that at this point, you ought to catch the BCC warning/error and raise an
exception if it happens. The longer term solution is a checking earlier in
the process to make sure that the SMILES string not only parses properly
but makes chemical sense (as opposed to being a high energy resonance
structure as he thinks these cases are), but this will take him some
development time to make work. So, for now, we are basically stuck with
just catching the BCC issue and taking it as indicating a likely problem
with the starting point (i.e. SMILES).

DM

On Tue, Mar 15, 2016 at 11:10 AM, David Mobley [email protected] wrote:

I wonder if a better solution would be to do some sort of tautomer
checking earlier, before getting to this stage. Will try and bring that up
too.

On Tue, Mar 15, 2016 at 11:00 AM, Andrea Rizzi [email protected]
wrote:

It sounds like we're using a tautomer that they don't think should be
used or something along those lines.

Yep. That's why I proposed to raise an exception when that warning
appears. We can decide about this after your meeting anyway.

Will try and bring up with him.

Thanks so much.

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

David Mobley
[email protected]
949-385-2436

David Mobley
[email protected]
949-385-2436

jchodera · 2016-03-16T05:51:05Z

These are structures generated from Epik, I believe, so they are actually higher-energy tautomers/protomers that we would like to include in free energy calculations.

andrrizzi · 2016-03-16T05:59:42Z

These are structures generated from Epik

As far as I know, the structures generated from Epik only showed the warning Warning: SelectElfDiverseConfs: elfPop.NumConfs 1 <= elfLimit 1. The BCIChargeCorrector warning popped up only when charging directly SMILES molecules. So it could be this won't be a problem for epik.

So, for now, we are basically stuck with just catching the BCC issue

I guess I can implement this before releasing 0.7.0 in #206?

andrrizzi mentioned this issue Mar 10, 2016

Prepare setup.py for release 0.7.0 #206

Merged

pgrinaway mentioned this issue Mar 18, 2016

Allow charge generation to fail gracefully #208

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Lots of OpenEye warnings #201

Lots of OpenEye warnings #201

jchodera commented Mar 6, 2016

davidlmobley commented Mar 6, 2016

andrrizzi commented Mar 6, 2016

jchodera commented Mar 6, 2016

andrrizzi commented Mar 6, 2016

jchodera commented Mar 6, 2016 via email

davidlmobley commented Mar 7, 2016

jchodera commented Mar 7, 2016 via email

jchodera commented Mar 7, 2016 via email

jchodera commented Mar 7, 2016 via email

davidlmobley commented Mar 7, 2016

jchodera commented Mar 7, 2016

davidlmobley commented Mar 7, 2016

andrrizzi commented Mar 10, 2016

davidlmobley commented Mar 15, 2016

andrrizzi commented Mar 15, 2016

davidlmobley commented Mar 15, 2016

jchodera commented Mar 15, 2016

andrrizzi commented Mar 15, 2016

davidlmobley commented Mar 15, 2016

andrrizzi commented Mar 15, 2016

davidlmobley commented Mar 15, 2016

davidlmobley commented Mar 16, 2016

jchodera commented Mar 16, 2016

andrrizzi commented Mar 16, 2016

Lots of OpenEye warnings #201

Lots of OpenEye warnings #201

Comments

jchodera commented Mar 6, 2016

davidlmobley commented Mar 6, 2016

andrrizzi commented Mar 6, 2016

jchodera commented Mar 6, 2016

andrrizzi commented Mar 6, 2016

jchodera commented Mar 6, 2016 via email

davidlmobley commented Mar 7, 2016

jchodera commented Mar 7, 2016 via email

jchodera commented Mar 7, 2016 via email

jchodera commented Mar 7, 2016 via email

davidlmobley commented Mar 7, 2016

jchodera commented Mar 7, 2016

davidlmobley commented Mar 7, 2016

andrrizzi commented Mar 10, 2016

davidlmobley commented Mar 15, 2016

andrrizzi commented Mar 15, 2016

davidlmobley commented Mar 15, 2016

jchodera commented Mar 15, 2016

andrrizzi commented Mar 15, 2016

davidlmobley commented Mar 15, 2016

andrrizzi commented Mar 15, 2016

davidlmobley commented Mar 15, 2016

davidlmobley commented Mar 16, 2016

jchodera commented Mar 16, 2016

andrrizzi commented Mar 16, 2016