Open jchodera opened 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.
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
.
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.
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
`OEAssignPartialCharges
SelectElfDiverseConfs
warning pops up only with the new OpenEye version and disappears when the number of conformations returned by Omega is bigI'll open a bug report about this on the OpenEye support page asking for clarification.
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!
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
Was the "canonical" charging method updated to? Maybe we should looking Christopher.
The online release notes may have clues.
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.
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
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.
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
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?
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
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.
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
We should capture the new Bayly-approved workflow for charging so we can eliminate these warnings.
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!
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
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.
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
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
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.
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?
I'm now seeing a ton of OpenEye warnings in travis:
@davidlmobley: Have you noticed these before?