-
Notifications
You must be signed in to change notification settings - Fork 664
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
Fixed a bug that appear when there are no water molecules in selection. #1322
Conversation
Improved print to screen format. Fixed some orthography. CHANGELOG updated.
I'm having this error in Travis CI:
The build stop in one "Build Jobs" , but in my PC it builds OK. Any idea? |
We have been experiencing these stalled jobs recently and are not sure why. Restarting the job typically does it. (Given that your travis check passed, you or someone else probably restarted it, or you submitted another commit that triggered the tests again.) |
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.
- Please correct comments.
- Must add a test case for the specific problem that you are fixing.
@@ -820,7 +825,8 @@ def _selection_serial(self, universe, selection_str): | |||
selection = [] | |||
for ts in universe.trajectory: | |||
selection.append(universe.select_atoms(selection_str)) | |||
print(ts.frame) | |||
sys.stdout.write("\rSelecting atoms from frame: %i"%ts.frame) |
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.
Do not use sys.stdout.write
: if you want to show progress, use our own lib.log.ProgressMeter
class.
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.
Or a good old print.
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.
ProgressMeter is made for this use case. Bare prints are not good because you cannot switch them off easily (short of redirecting stdout).
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.
There should be a verbosity argument to the function. I honestly never look at the log and I'm not sure how many people know about it.
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.
Maybe we misunderstand each other (?): I am not advocating to use a logger but use the ProgressMeter
class which properly encapsulates the use case here: write status for every iteration in a loop. Under the hood it uses sys.stderr
and flushes but with added goodies like #928 / #960 (and some other neat things that @jbarnoud has shown or promised (IIRC... ;-) ) such as real progress bars, including nice ones in Jupyter notebooks) it makes sense to unify the way we show progress.
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.
And yes, add the standard verbose=True
argument and pass it to ProgressMeter
.
@@ -415,6 +415,7 @@ | |||
from six.moves import range, zip_longest | |||
|
|||
import numpy as np | |||
import sys |
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.
You should not need sys
for anything. For output, use lib.log.ProgressMeter
(see below comment).
return (valOH,valHH,valdip) | ||
|
||
if n == 0: | ||
return (0,0,0) |
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.
Use PEP 8 formatting (space after comma) – applies to the whole file.
Note: If you start formatting the whole file according to PEP 8 do this in a separate commit so that it is clear that this commit only contains formatting. However, any new code that you're adding/changing should already be formatted to PEP 8.
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.
Ok, I'll adapt the code to the PEP8 format, but is it necessary to have lines shorter than 80 column even if I lost readability of code?
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.
Try to keep a limit at 80-ish columns. There is no point at cutting lines at 79 for the sake of it, 82 or 85 as just as readable, but long lines are often the sign of other issues.
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.
We decided to go with 79 characters, see Style Guide: Coding Style – there was quite a bit of discussion preceding this decision. Generally speaking, I find that most code still looks fine when broken sensibly across lines.
A lot of old code still does not conform to PEP 8 but we are slowly working to making this more uniform so at least newly added/edited code should conform.
In the end, a unified appearance makes it easier for other people to understand the code and it can make merging easier, too.
valOH = valOH/n | ||
valHH = valHH/n | ||
valdip = valdip/n | ||
return (valOH,valHH,valdip) |
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.
How about leaving the return
at the end?
valOH, valHH, valdip = (valOH/n, valHHn, valdip/n) if n > 0 else (0, 0, 0)
return valOH, valHH, valdip
or even
return (valOH/n, valHH/n, valdip/n) if n > 0 else (0, 0, 0)
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.
Ok, I like it.
if n == 0: | ||
return (0,0,0) | ||
else: | ||
return (sumDeltaOH/n,sumDeltaHH/n,sumDeltadip/n) |
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 like return
at the end better than hidden in an if
/else
. But ultimately your choice.
if n == 0: | ||
return (0,0,0) | ||
else: | ||
return (sumDeltaO/n) |
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.
no parentheses, return
at end?
@@ -1102,7 +1119,8 @@ def _selection_serial(self,universe,selection_str): | |||
selection = [] | |||
for ts in universe.trajectory: | |||
selection.append(universe.select_atoms(selection_str)) | |||
print(ts.frame) | |||
sys.stdout.write("\rSelecting atoms from frame: %i"%ts.frame) |
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.
use ProgressMeter
|
||
#if no water molecules remain in selection, there is nothing to get the mean, so n = 0. | ||
if n == 0: | ||
return (0,0,0) |
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.
This is weird: isn't sumDeltaP
a scalar? Then why would you return a tuple for n==0
??
|
||
#if no water molecules remain in selection, there is nothing to get the mean, so n = 0. | ||
if n == 0: | ||
return (0,0,0) |
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.
Why a tuple for n==0
?? Isn't sumDelta0
a scalar?
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.
You're right, my mistake, next time I'll implement tests for this "little" changes.
@@ -1218,7 +1240,8 @@ def _selection_serial(self,universe,selection_str): | |||
selection = [] | |||
for ts in universe.trajectory: | |||
selection.append(universe.select_atoms(selection_str)) | |||
print(ts.frame) | |||
sys.stdout.write("\rSelecting atoms from frame: %i"%ts.frame) | |||
sys.stdout.flush() |
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.
ProgressMeter
instead
Thanks for all your comments, I'll work on this. |
Changed print to screen, now using ProgressMeter. Avoiding hidden return inside if/else. Added test to fixed bug.
Changes made in this Pull Request:
PR Checklist