Lots of OpenEye warnings

jchodera commented 8 years ago

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?

davidlmobley commented 8 years ago

Those seem to be new.

On Sun, Mar 6, 2016, 5:01 AM John Chodera notifications@github.com 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 https://github.com/choderalab/openmoltools/issues/201.

andrrizzi commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 notifications@github.com 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 https://github.com/choderalab/openmoltools/issues/201#issuecomment-193004769 .

David Mobley dmobley@gmail.com 949-385-2436

jchodera commented 8 years ago

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

jchodera commented 8 years ago

The online release notes may have clues.

jchodera commented 8 years ago

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 commented 8 years ago

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 notifications@github.com 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 https://github.com/choderalab/openmoltools/issues/201#issuecomment-193219556 .

David Mobley dmobley@gmail.com 949-385-2436

jchodera commented 8 years ago

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 commented 8 years ago

Indeed.

On Mon, Mar 7, 2016 at 9:44 AM, John Chodera notifications@github.com 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 https://github.com/choderalab/openmoltools/issues/201#issuecomment-193366013 .

David Mobley dmobley@gmail.com 949-385-2436

andrrizzi commented 8 years ago

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 commented 8 years ago

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 notifications@github.com 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 https://github.com/choderalab/openmoltools/issues/201#issuecomment-195085748 .

David Mobley dmobley@gmail.com 949-385-2436

andrrizzi commented 8 years ago

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 commented 8 years ago

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

Thanks.

On Tue, Mar 15, 2016 at 10:17 AM, Andrea Rizzi notifications@github.com 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 https://github.com/choderalab/openmoltools/issues/201#issuecomment-196931255

David Mobley dmobley@gmail.com 949-385-2436

jchodera commented 8 years ago

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

andrrizzi commented 8 years ago

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 commented 8 years ago

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 notifications@github.com 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 https://github.com/choderalab/openmoltools/issues/201#issuecomment-196946795

David Mobley dmobley@gmail.com 949-385-2436

andrrizzi commented 8 years ago

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 commented 8 years ago

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 notifications@github.com 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 https://github.com/choderalab/openmoltools/issues/201#issuecomment-196950104

David Mobley dmobley@gmail.com 949-385-2436

davidlmobley commented 8 years ago

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 dmobley@gmail.com 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 notifications@github.com 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 https://github.com/choderalab/openmoltools/issues/201#issuecomment-196950104

David Mobley dmobley@gmail.com 949-385-2436

David Mobley dmobley@gmail.com 949-385-2436

jchodera commented 8 years ago

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 commented 8 years ago

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?

choderalab / openmoltools

Lots of OpenEye warnings #201