-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update for OEAssignCharges #255
Conversation
@nathanmlim : Looks good to me, except could you also address the other aspect of #252 at the same time? Specifically:
Or, if you'd prefer not to, then we need to NOT close the issue when this is resolved and just rename it/clarify what still needs to be done. The changes involved for this are obviously more involved. So, let me know what you prefer. |
Travis tests appear to be failing due to inactivity? |
That's odd. On occasion we've seen this if there is no output for a while. I think there is a setting to adjust how long it takes for the tests to time out? Or, adjust the verbosity level so it will produce more output? Have you run tests locally? |
openmoltools/openeye.py
Outdated
|
||
#Determine conformations to return | ||
if keep_confs == None: | ||
logger.warning( | ||
"keep_confs was set to None. Returned molecules will not be charged.") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think in this case the returned molecule is still charged, but the coordinates are reset to those of the passed molecules, or did something changed with the new OE?
Do you think it'll be ok to send these messages to logger.debug
instead of warning
? Otherwise it will be very hard to silent them in our applications.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nathanmlim - Andrea is right, unless you've changed it the warning message here is wrong. The behavior we'd implemented (as per the doc string) was that if keep_confs = None
then the computed charges are applied to the provided conformation of the molecule, rather than any of the generated conformations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@andrrizzi Thanks for catching that. I'll switch it to debug as well.
Travis tests are stalling
Any suggestions on what to do here? @davidlmobley @andrrizzi |
@andrrizzi - do you have advice on the "stalling tests" issue? |
That's a weird one. Is it possible that simply the new charge assigning scheme takes much longer than the old one? That test ends up calling In both cases, I'd make an experiment and temporarily revert to the old charge engine to see if it's a problem related to that or not. Is this something you can reproduce locally? |
So it looks like it's stalling because the new charging engine takes longer. Is there a way to make it so travis doesn't time out? |
Hmm. Maybe you could |
@andrrizzi @nathanmlim - is this the test where we charge a whole bunch of molecules? I recall wondering in the past why we were testing so many molecules. I don't see any reason to test charging many, many molecules. |
It's also not a bad idea to make the engine be an option, with the default to the new engine. Then you could just, say, test on charging a single molecule (?) with the new engine and another molecule or two with the old engine...? |
I think this is the problematic test. I think it calls The speed loss is actually quite significant. The same test took 22 second to complete with the old engine, so other tests could be affected by this. |
I've added a |
Sounds reasonable, @nathanmlim, but can you make sure the new charging option gets used in at least one test? We don't want to have it going untested. I can see it being significantly slower, as I believe it's doing more careful selection of conformed for charging and more charge calculations for averaging in certain cases. So there will be more cost, but also better charges resulting. |
@davidlmobley Valid point. BTW, do you know if there is a way to check the installed version of OEToolKits? That would be another way to make sure it ends up using the legacy charging engine. |
There is a way, but I don't offhand remember what it is. However, I'm
fairly certain I have code in this repo which does so, somewhere, as at
some point there were certain things we required a specific version to be
able to do.
…On Wed, May 10, 2017, 5:01 PM Nathan Lim ***@***.***> wrote:
Sounds reasonable, @nathanmlim <https://github.com/nathanmlim>, but can
you make sure the new charging option gets used in at least one test? We
don't want to have it going untested.
@davidlmobley <https://github.com/davidlmobley> Valid point. BTW, do you
know if there is a way to check the installed version of OEToolKits? That
would be another way to make sure it ends up using the legacy charging
engine.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#255 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGzUYX4LhycMeCP_Qtmxh7aIhBPCf9Ntks5r4k_NgaJpZM4NUyOv>
.
|
Ah found it in
|
Addition of tests are linked here Okay to merge? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, @nathanmlim . This looks excellent. Approving and will merge. Shall we do a release to incorporate this so we can push it out to Omnia?
Not a high priority right now but will eventually need it on a conda channel roughly mid-June. Thanks! |
Addressing issue #252 by replacing the line to call the
OEAssignCharges
from OEToolkits version 2017.02.01. Added some warning messages as well.