-
Notifications
You must be signed in to change notification settings - Fork 647
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
Handling AtomGroup arguments in analysis functions/classes #1074
Comments
Hbond analysis needs selection strings so that the selection can be recomputed for each frame. I agree that using AtomGroups instead of selection strings feels more pythonic. In principle the Universe can always be obtained from an AtomGroup so there is not really any need to provide a Universe except in order to make clear that an explicit selection is needed. Not sure yet what the cleanest approach is or if it is even sensible to try a one size fits all approach. |
How about a one size fits 90% approach? That's what my argument parsing in #888 is trying to do. For the other 10% like Hbond analysis we can still use explicit selection strings as they are the only viable option and throw a sensible error message explaining that a string is needed for this analysis in contrast to the common case. This goes well along with having a consistent API for analysis classes #719. |
We also had some discussion in #175 about this, mostly about creating an automatically updating AtomSelection. I think the tl;dr of that idea is: # needs some kwarg/different method to define that we don't want a regular AtomGroup
atom_sel = u.select_atoms('around 5.0 protein and resname SOL', dynamic_selection=True)
# find how many water atoms within 5.0 of protein
for ts in u.trajectory:
print len(atom_sel) It's maybe a little complicated, and could just be replaced by calling We should probably just accept either strings or |
Hey guys, I'm still working on this dynamic selection idea (it got held back because it depended heavily on the new topology system). I should have it out soon. |
* Added dynamically updating atomgroup selections (#175 and #1074) Cleaned up some selection docs Updated some uses of itertools.izip to six.zip Cleaned up some variable names in groups.py that could eventually clash with the six module. Made AtomGroup __repr__ fancier by inflecting with the number of elements.
So with |
See PR #1073 Issues: #888, #719
Connected #1029
@orbeckst asked if a AtomGroup is a valid argument to have for an analysis. I would say yes and I write most of my own analysis in terms of aomgroups. But there is also old code and some newer that works with a universe and selection strings.
Some example classes
Accepting Universe: AlignTraj, Contacts (That one is a mixed bag with the reference though).
Accepting Atomgroup: InterRDF
I'm personally in favor of giving using an atomgroup as a parameter. I'm actually writing all my own analysis classes like this. This also makes it easy to use atomgroups of the same system from different simulations in another universe. It also feels like more natural way to use a python library like this. The universe and selection string version is more along using a CLI tool.
I've actually written a small argument parsing function in #888 that would be able to allow both approaches. See #888 but that is connected to #1029 with the new system.
The question is how should we handle atomgroup arguments in the analysis classes. Do we want to allow them or should it be a strict universe/selection-string option?
The text was updated successfully, but these errors were encountered: