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
Survival probability: Intermittency, Step, Residues, Overlapping SP Selection Example #2226
Survival probability: Intermittency, Step, Residues, Overlapping SP Selection Example #2226
Conversation
…nalysis. Before, all frames were loaded (and selection was always applied). Now, the frames which are not used are not loaded, thus improving the performance. This only happens when the step is larger than the tau_max + 1. Test cases cover the situation where some frames are skipped. The test checks how many times the 'select_atoms' was called. This is to help with the large size MD simulations analysis.
was set up or not. Also, manually moving between the frames rather then using "for _ in trajectory[]". This removed unnecessary variables.
border condition for "tau_max" and "step".
which atoms are found.
as a gap: meaning that setting it to the value of 2 means that the atom id 7, when in the sequence 7,X,X,7, where X means absence, will be rewritten to 7,7,7,7. This way the intermittency does not affect the actual routines for SP calculation. The array of IDs should never be big so this should not add any significant computational time.
to the selected IDs, using the selected IDs to verify the behaviour of the intermittency.
parameter is complex and was accounted for here, together with new test cases. If necessary, we load extra frames for each window, to account for the borders: for the first and last frame in a window.
analysis. This requires several runs and averaging.
Codecov Report
@@ Coverage Diff @@
## develop #2226 +/- ##
===========================================
- Coverage 90.72% 89.59% -1.13%
===========================================
Files 15 158 +143
Lines 1983 19725 +17742
Branches 0 2780 +2780
===========================================
+ Hits 1799 17672 +15873
- Misses 184 1458 +1274
- Partials 0 595 +595
Continue to review full report at Codecov.
|
Hi there, I only modified two files, however, I worked on the "develop" branch by mistake. So I tried to rebase the code to bring my commits to the front, which is why the review picks up so many files. I'll see if I can move the commits differently to avoid what happened here. |
Hi again, I see that there are some functionalities which could help with organising the commits: git cherry-pick in particular. Let me know if it is necessary and then I'll further look into it. |
Looks like a clean diff, so no need to play more with |
…usz/mdanalysis into bieniekmateusz-survival_probability
I merged latest develop into your branch so that the docs build correctly and don't fail your build. |
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.
Primarily I have comments on the docs.
Also include an entry for CHANGELOG.
I would like to see a review by some of the original authors of SP, e.g., @alejob .
I like the idea of moving it into its own module. How about doing this as a separate PR once this one is merged? The smaller a PR the better. |
The requested changes have been introduced. I've built the documentation and it appears fine. Cheers |
It sounds good, but how could we avoid to broke the old code? There is people that has already implemented scripts with waterdynamics.survivalprobability(), so the idea is to avoid broke that code. Maybe some kind of link inside the MDA code. |
So moving it to another file would be a new PR in the future. We could say that the code is moved and simply point the user to import the new path - if someone tries to use it. Luckily the function itself and how it works has not changed so it should be a minor inconvinience for the users, hopefully. |
Breaking user code is not something that we do lightly.
In this case it will be easy: we just import the function into water dynamics and everything else will just be able to use it as before. The call signature did not change (?) and all the old tests for the function still pass, don't they?
In any case, that's all stuff we can discuss in a new issue/PR.
…--
Oliver Beckstein
email: orbeckst@gmail.com
Am Apr 3, 2019 um 15:18 schrieb Mateusz Bieniek ***@***.***>:
So moving it to another file would be a new PR in the future.
We could say that the code is moved and simply point the user to import the new path - if someone tries to use it. Luckily the function itself and how it works has not changed so it should be a minor inconvinience for the users, hopefully.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
…usz/mdanalysis into bieniekmateusz-survival_probability
Merged develop to get the travis fix from PR #2234 |
…alysis into survival_probability
I think I've corrected everything, please let me know if I missed anything. |
To give you heads up, after this is merged we will shortly send you another PR with a common autocorrelation function between the waterdynamics.HydrogenBondLifetimes and waterdynamics.SurvivalProbability. @richardjgowers noted that it would be good to formalise and extract the common autocorrelation code (PR #1995). After careful considerations with @p-j-smith we now have a separate autocorrelation function that has intermittency built into it, and being independent, is easily testable. The test cases will be well-defined in a similar manner to the ones we've used for the SurvivalProbability. We've already verified that waterdynamics.HydrogenBondLifetimes behaves exactly the same way our autocorrelation does (continuous). These changes should to a big extent simplify the module. In the case of HydrogenBondLifetimes it would mean a simple function call replacing the entire class. This will help simplifying the documentation too (PR #2181) Work done with @p-j-smith. |
@@ -15,7 +15,7 @@ The rules for this file: | |||
------------------------------------------------------------------------------ | |||
mm/dd/yy micaela-matta, xiki-tempula, zemanj, mattwthompson, orbeckst, aliehlen, | |||
dpadula85, jbarnoud, manuel.nuno.melo, richardjgowers, mattwthompson, | |||
ayushsuhane, picocentauri, NinadBhat | |||
ayushsuhane, picocentauri, NinadBhat, bieniekmateusz, p-j-smith |
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.
Are @bieniekmateusz and @p-j-smith in AUTHORS?
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, both of us. We're doing pair-programming.
@alejob if you're happy with the PR could you please also add a formal "approve" review? Thanks. |
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.
It looks a good extension to SP, and the new functionalities are clearly explained.
leave a region of interest for up to two consecutive frames yet be treated as being present at all frames. | ||
The default is continuous (0). | ||
verbose : Boolean, optional | ||
Print the progress to the console |
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 this, it gives great flexibility to SP.
Thanks @alejob ! I resolved the conflict in the CHANGELOG and we'll just let CI confirm that everything is still good. |
Congratulations @bieniekmateusz and @p-j-smith , merged! Thanks for your hard work (and patience). Thanks @alejob for reviewing. |
Fixes #
Changes made in this Pull Request:
PR Checklist
We generalised the code to be applicable to other situations which is why we would like to ask if we should move it out of waterdynamics.py to its own file (survivalprobability.py in analysis).
The intermittency, for the sake of simplicity, is defined in terms of consecutive absences. This is calculated in a single pass over the data.
We've used the new functionalities and plan to publish on the topic to discuss the usefulness of these small changes.
This request is done on behalf of me and @p-j-smith