Skip to content
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

Hbond analysis #2237

Merged
merged 7 commits into from
Oct 29, 2019
Merged

Hbond analysis #2237

merged 7 commits into from
Oct 29, 2019

Conversation

p-j-smith
Copy link
Member

@p-j-smith p-j-smith commented Apr 5, 2019

A newly rewritten HydrogenBondAnalysis class.

Hi, I have written a new version of the current HydrogenBondAnalysis class that simplifies the class itself and especially the run() method. Currently, this is the only method from the original class that is implemented. I decided to write a new class after reading some of the issues surrounding the current hbonds module (#2177 #2181 #2198 ).

I realise this is an extremely popular analysis tool and so understand if there is no desire for a complete rewrite of the class. However, after reading @orbeckst comments in #2087 (regarding duplication of code across the hbonds module) and #2177 (regarding rewriting the module from scratch and returning DRY, tidy data), I thought I would like to at least create a discussion around the issues raised.

Another motivation for rewriting this class is that @bieniekmateusz and I have written a general autocorrelation function (mentioned in PR #2226 ) that can be used to replace the three different implementations currently in waterdynamics.HydrogenBondLifetimes, waterdynamics.SurvivalProbability and hbonds.hbond_autocorrelation, as suggested @richardjgowers in PR #1995 .

Changes made in this Pull Request:

  • Newly rewritten HydrogenBondAnalysis class
  • The code has been simplified significantly
  • The run() method has been optimised by using the MDAnalysis.lib.distances.capped_distance() method.
  • The capped_distance() method is used to both find D-H pairs and to find D-A pairs within a cutoff.
  • This results in a speed-up of 5 times for the small test WaterDCD system, and a speedup of around 55 times for a system containing around 7,000 water molecules.
  • Added a regression test for the current HydrogenBondAnalysis class to directly compare behaviour with the one submitted here.
  • Basic documentation of the new class.

PR Checklist

  • Tests?
  • Docs?
  • CHANGELOG updated?
  • Issue raised/referenced?

@codecov
Copy link

codecov bot commented Apr 6, 2019

Codecov Report

Merging #2237 into develop will increase coverage by 0.04%.
The diff coverage is 95.61%.

Impacted file tree graph

@@             Coverage Diff             @@
##           develop    #2237      +/-   ##
===========================================
+ Coverage    89.88%   89.92%   +0.04%     
===========================================
  Files          173      175       +2     
  Lines        21803    21916     +113     
  Branches      2865     2876      +11     
===========================================
+ Hits         19598    19709     +111     
  Misses        1612     1612              
- Partials       593      595       +2
Impacted Files Coverage Δ
package/MDAnalysis/analysis/__init__.py 100% <ø> (ø) ⬆️
...kage/MDAnalysis/analysis/hydrogenbonds/__init__.py 100% <100%> (ø)
...ckage/MDAnalysis/analysis/hbonds/hbond_analysis.py 80.75% <100%> (+0.11%) ⬆️
...DAnalysis/analysis/hydrogenbonds/hbond_analysis.py 95.37% <95.37%> (ø)
package/MDAnalysis/lib/transformations.py 78.62% <0%> (+0.43%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 54a7add...bdfdf15. Read the comment docs.

@orbeckst
Copy link
Member

orbeckst commented Apr 6, 2019

Make the linter happy (Job #954.8):

************* Module MDAnalysis.analysis.hbond_analysis
package/MDAnalysis/analysis/hbond_analysis.py:79: [W1618(no-absolute-import), ] import missing `from __future__ import absolute_import`

@orbeckst
Copy link
Member

orbeckst commented Apr 6, 2019

This looks interesting – I only had a very cursory glance, but (1) code clean-up and (2) performance improvements and (3) extensibility are all very good reasons.

There is a question how this will interact with @xiki-tempula 's water-bridging analysis; the issue text already references the pertinent issues/PRs so you're clearly aware of what's been done/discussed so far. I think we need to have a discussion how we want to move forward with the H-bonding module. Having actual code to discuss is great.

I'll add a few more initial comments on the code.

P.S.: @p-j-smith if you add your committer email address to GitHub then the commits will be properly attributed to you.

@xiki-tempula
Copy link
Contributor

xiki-tempula commented Apr 6, 2019

The code looks really nice, the capped distance is a very neat way of finding the atoms compared with the old neighbour search. I will try to use capped_distance in the water bridge we well. I guess the only problem is that the interface and the outputs are very different from the previous one. Personally, I hate the original representation as well.

Copy link
Member

@orbeckst orbeckst left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like much cleaner code with better performance because you sensibly eliminated loops and used capped_distance_array().

I initially would like to understand (with a view towards #2238 )

  • How does your algorithm differ from the original one?
  • Does it produce the same results?
  • What are the major differences between your implementation and the new one?
    • What are new capabilities?
    • What is missing compared to the old HydrogenBondAnalysis?
  • How much of the original HydrogenBondAnalysis API can be rebuild in this refactored class?

Most of the comments on the code are not super-important at this stage – you can address them, but answers to the above questions are more important at this stage.

testsuite/MDAnalysisTests/analysis/test_hbonds.py Outdated Show resolved Hide resolved
package/MDAnalysis/analysis/hbond_analysis.py Outdated Show resolved Hide resolved
package/MDAnalysis/analysis/hbond_analysis.py Outdated Show resolved Hide resolved
package/MDAnalysis/analysis/hbond_analysis.py Outdated Show resolved Hide resolved
package/MDAnalysis/analysis/hbond_analysis.py Outdated Show resolved Hide resolved
testsuite/MDAnalysisTests/analysis/test_hbond_analysis.py Outdated Show resolved Hide resolved
testsuite/MDAnalysisTests/analysis/test_hbonds.py Outdated Show resolved Hide resolved
testsuite/MDAnalysisTests/analysis/test_hbonds.py Outdated Show resolved Hide resolved
testsuite/MDAnalysisTests/analysis/test_hbonds.py Outdated Show resolved Hide resolved
@orbeckst
Copy link
Member

orbeckst commented Apr 6, 2019

More general discussion in #2238 .


# Select donors, hydrogens and acceptors
donors = all_donors[donors_indices]
hydrogens = all_hydrogens[hydrogen_indices]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’d be curious if it’s quicker to access via bonds (where possible)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What would be the best way to find hydrogens via the topology? It's not something I'm very familiar with.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just checked this in the test WaterPSF system and, if selecting all donors in the system, it is 10 times faster to select both groups and then use the capped_distance() method. However, if the donors and hydrogens selections are more complicated (such as involving and around 5 resid 7) then the distance based method is around 40% faster than using the topology. So as the complexity of the selection increases it may become faster to use the topology to find hydrogens, but generally it is faster using capped_distances().

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In principle, selecting via topology is the only correct way of finding the bonded hydrogens (assuming that the bonds were not guessed).

Do you have to find the hydrogens at every time step or can you do it for once and for all?

Options:
- *d_h_cutoff* (Å) [1.2] : Distance cutoff used for finding donor-hydrogen pairs
- *d_a_cutoff* (Å) [3.0] : Distance cutoff for hydrogen bonds. This cutoff refers to the D-A distance.
- *d_h_a_angle_cutoff* (degrees) [150] : D-H-A angle cutoff for hydrogen bonds.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’d maybe try and have an ascii showing this, some people get confused on the interior/exterior angle

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a nice idea.

universe : Universe
MDAnalysis Universe object
donors_sel : str
Selection string for the hydrogen bond donor atoms
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Be nice if these could be either AG or str, but possibly outside scope of this PR - should raise an issue

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Providing atom groups would definitely be nice, it's something to think about.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be neatly solved with Universe.selectAtoms(AG) returning AG. This way all interfaces would automatically accept str and AG selections.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought the same. Raise a separate issue. It looks like a simple change but this is such a fundamental method that it will require some careful testing. If it works consistently then it would be great. I think there was an old issue related to the "use AG where strings are allowed".

There are some cases where it won't just work, in particular anywhere where strings are used to create "updating AtomGroups" by executing the same selection every frame (I think the waterdyamics module does this and probably elsewhere, too). Anyway, separate issue!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@richardjgowers can you raise an issue for your idea that select_atoms should be able to pass through ags, please?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

raised #2369

MDAnalysis Universe object
donors_sel : str
Selection string for the hydrogen bond donor atoms
hydrogens_sel : str
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe with no sel it tries via bonds?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah that makes sense.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was also thinking that if donors_sel is not provided then it might be nice to implement a guess_donors() method that will return a list of potential donor atom names (and their hydrogens) based on the partial charges of the atoms. A similar guess_acceptors() method could also be implemented. Or, someone could call these methods before run() to help in quickly creating these lists if they have a large number of donors and acceptors in their system.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Such guess could be based on the mass of the atoms?

box=box
)
)
hbond_indices = np.where(d_h_a_angles > self.d_h_a_angle)[0]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is using a bool arr quicker than going via np where?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Most probably, I'll change this.

@richardjgowers
Copy link
Member

richardjgowers commented Apr 7, 2019 via email

@p-j-smith
Copy link
Member Author

Here's a little bit more information on the new class in response to @orbeckst questions above:

I initially would like to understand (with a view towards #2238 )

  • How does your algorithm differ from the original one?

  • Does it produce the same results?

  • What are the major differences between your implementation and the new one?

    • What are new capabilities?
    • What is missing compared to the old HydrogenBondAnalysis?
  • How much of the original HydrogenBondAnalysis API can be rebuild in this refactored class?

  • How does your algorithm differ from the original one?
    In general it is quite similar, but as I mentioned above:

    So currently the new analysis uses the same algorithm for finding hydrogen bonds as when the current class is instantiated with detect_hydrogens='distance', distance_type='heavy, pbc=True. The test cases I've added show that when using these parameters the results of the two classes are identical.

  • Does it produce the same results?
    If the current class is used with the parameters I mentioned in the point above, it does indeed produce the same results.

  • What are the major differences between your implementation and the new one?
    The main differences are that the for loops have been removed and capped_distances() is used to find potential donor-acceptor pairs.

  • What are new capabilities?
    The major improvements are in terms of speed, maintainability and extensibility. On a small test system of around 7000 water molecules it is around 55 times faster than the current code, and I expect that the performance boost will increase with system size. The code is much simpler and easier to read, so both maintaining it and add new features will likely be easier. For instance, the general autocorrelation function that @bieniekmateusz and I have written could be called inside a hbonds.autocorrelation() method, which will remove duplicate code.

  • What is missing compared to the old HydrogenBondAnalysis?
    As it is, the current class does not has all of the convenience functions that the old class has, nor does it have a method to generate a pandas dataframe. It also doesn't have a list of default donors and acceptors, but as I mentioned above I think this is not necessarily a bad thing:

    It can, but to be honest I find the call signature of the current class very confusing. When I first tried using current analysis tool I was put off by the large number of selections I had to provide and especially by the idea of having to create a new class if I wanted different donor or acceptor types. I actually preferred the idea of writing my own hydrogen bond analysis script, which forms the basis of the new class.

    I know there are now donor and acceptor keywords that can be used to add atom names not already included in the default selections, but there is no hydrogens keyword, meaning that a new class must be created if someone is using a different forcefield or if they are using LAMMPS (which has numbered atom types).

    I find using only donors_sel, acceptors_sel and hydrogens_sel much cleaner and easier to understand than the various combinations provided by selection1, selection2, selection1_type, forcefield, donors and acceptors. The other issue with the current default selections is that they only take into account protein atom names and not lipid or CGenFF names.

    I'm not sure how you feel about this, but if rewriting the class involves changing how the results are stored/returned then it might also be a good idea to simplify the signature call.

To avoid inconveniencing current users that rely on the default acceptors and donors, I though we could add methods to guess these:

I was also thinking that if donors_sel is not provided then it might be nice to implement a guess_donors() method that will return a list of potential donor atom names (and their hydrogens) based on the partial charges of the atoms. A similar guess_acceptors() method could also be implemented. Or, someone could call these methods before run() to help in quickly creating these lists if they have a large number of donors and acceptors in their system

If these changes are too drastic, then I'm sure it is possible to change the signature call to match the old class, but I haven't thought about how do it yet. Also, I have added a count_by_time() method and think it should be relatively straight forward to add the other convenience methods.

@p-j-smith
Copy link
Member Author

Apologies for the very slow reply, I have been pretty busy recently. I have made a few updates to the class:

  • If acceptors_sel is not provided, then it is guessed by considering the atomic charges.
  • If hydrogens_sel is not provided, then it is guessed by considering the atomic charges and masses.
  • If donors_sel is not provided, then the topology is used to find donor-hydrogen pairs.
  • Added an argument update_selections, which if False will not update atom groups at every step.
  • Added a count_by_ids method, which is equivalent to the count_by_type method in the original class.
  • Added a count_by_type method which returns a count of each type of hydrogen bond, where a unique type consists of a unique combination of donor resname, donor name, acceptor resname and acceptor name. This is therefore a coarser analysis of hydrogen bond types than the count_by_ids method.
  • Added test cases for the new methods.
  • Updated the documentation.

@p-j-smith
Copy link
Member Author

I'm just wondering whether there are any plans to update the version of numpy used by MDAnalysis, as the convenience functions I have written require numpy v.1.13 or later? If not, I can make some minor adjustments to fix it.

@richardjgowers
Copy link
Member

richardjgowers commented Apr 29, 2019 via email

@p-j-smith
Copy link
Member Author

I'm using np.unique() with the argument axis=0, but the axis argument was only introduced in version 1.13.0

@tylerjereddy
Copy link
Member

Oh yeah, np.unique with the axis argument is probably pretty powerful for simulation / coordinate analysis since you can i.e., filter out duplicate coordinates without using pandas.

I think I've forgotten what our policy is on minimum supported NumPy version, but I suspect we do have to be somewhat conscious of the slower adoption of new software that sometimes happens in academia.

@zemanj
Copy link
Member

zemanj commented Apr 30, 2019

I think I've forgotten what our policy is on minimum supported NumPy version

I'd also be interested in knowing on what basis such things are decided. Currently we have 1.10.2 (I think?) as a minimum requirement, and that misses quite a bunch of handy features such as isin() etc.

@p-j-smith We have lib.util.unique_rows() as a drop-in for 2d arrays, but you'd still have to make it return counts in order to work with the data structure you chose for storing hbond info etc. I'd prefer bumping the minimum NumPy version to 1.13 but I don't know if that's easily possible.

@orbeckst
Copy link
Member

"We" just decided that the minimum supported version of numpy will be 1.13.3. (see #2272). PR should be coming soon. Does this help?

@orbeckst
Copy link
Member

@VOD555 please have a look at this PR #2237 for the current work on the new H-bond analysis.

We need to get going/reviewing on this one – sorry to @p-j-smith and @bieniekmateusz for the stall.

@orbeckst
Copy link
Member

orbeckst commented Jul 16, 2019

@p-j-smith sorry for the long silence on this PR. Will you be able to pick it up again? I would like to move forward with it, especially with a view towards 1.0.

As @kain88-de said, the existing H-bond analysis is heavily used so we cannot just kill it. I would propose to put the existing H-bond module MDAnalysis.analysis.hbonds into legacy mode and see that we can get your new version up and running in parallel to the old version. If you also want to add correlations etc then we should have this in its own submodule, but just not named "hbonds". What would be a good name for the new submodule? "nonbonded", "interactions", "hydrogenbonds", ...?

@p-j-smith
Copy link
Member Author

@orbeckst no problem. I won't be able to do much for the next couple of weeks, but I'm definitely still keen to see this through.

I think that putting the current MDAnalysis.analysis.hbonds into legacy mode makes sense. @bieniekmateusz and I are planning to add hydrogen bond lifetimes to this new version, so it will indeed need to become a submodule. For the name of the submodule, I prefer "hydrogenbonds" but I'm open to other suggestions.

@orbeckst
Copy link
Member

orbeckst commented Jul 30, 2019

@p-j-smith @bieniekmateusz I rebased against develop and force-pushed (sorry about that). Pull your develop and then you should still be able to pull this branch – but better pull before making any edits and trying to push.

I moved your module into a new analysis.hydrogenbonds so that it can be cleanly developed in parallel to the old analysis.hbonds (see commit message for 5c72ed5).

@orbeckst
Copy link
Member

@VOD555 – if you want to try the new hbond analysis then you should be able to use this branch. I ran the tests locally and they passed.

Copy link
Member

@orbeckst orbeckst left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please

  • address comments as far as possible or state if you can't/don't want to address with a reason
  • make use of numpy >= 1.13 functionality (unique something or other, see comments)
  • add docs (make sure the docs build and show your docs – ask if you have questions how to do it)
  • update CHANGELOG

@orbeckst
Copy link
Member

Some of the tests fail, perhaps because an older version of numpy is being installed, see, e.g., https://travis-ci.com/MDAnalysis/mdanalysis/jobs/221063112 with error

>       indices, tmp_counts = np.unique(self.hbonds[:, 0], axis=0, return_counts=True)
E       TypeError: unique() got an unexpected keyword argument 'axis'

Under source ci-helpers/travis/setup_conda.sh:

UnsatisfiableError: The following specifications were found to be in conflict:
  - numpy=1.16 -> python[version='>=2.7,<2.8.0a0'] -> *[track_features=debug]
  - python=3.5
Use "conda info <package>" to see the dependencies for each package.
Installing numpy=1.16 with conda was unsuccessful, removing from conda install and adding numpy==1.16.*  to PIP_DEPENDENCIES instead.
...
...
numpy:                1.11.3-py35_blas_openblashd3ea46f_205 conda-forge [blas_openblas]

@VOD555
Copy link
Contributor

VOD555 commented Aug 2, 2019

@p-j-smith @bieniekmateusz @orbeckst It's a good idea to identify donors and acceptors using mass and charge information. But some of the topology files such as pdb and gro files don't have charge information. This will cause an error when using the 'new' HydrogenBondAnalysis.

I think we still need some pre-guess donor and acceptor atoms similar to the ones in the 'old' HydrogenBondAnalysis for these topology without charge information.

@VOD555
Copy link
Contributor

VOD555 commented Aug 2, 2019

@p-j-smith @orbeckst @bieniekmateusz Another problem is about the selection string.

Suppose my universe (topology) contains a protein and water molecules, and I want to find out the h-bonds between atoms of the protein. If I give the universe to the function without selection strings, HydrogenBondAnalysis will take all water molecules into account. If i give the universe with donor and acceptor selection protein, it will take all atoms in the protein as potential acceptors and donors. To get what I want, I have to generate a new topology without water or give detailed selection string (such as 'name O or OC1 or OC2 ...'). This is not friendly to users.

Maybe we need to define a pre-process function to generate such detailed donor and acceptor selection strings.

@orbeckst
Copy link
Member

ping @p-j-smith

@KCLPhysics
Copy link

Hi @orbeckst sorry for being so slow with this, I should have some time tomorrow evening to finish this of, or if not then definitely by the end of this week

@orbeckst
Copy link
Member

@richardjgowers do you want to do a quick 0.20.2 release before this gets merged?

@p-j-smith
Copy link
Member Author

So I think I have made all the changes:

I've added a simple test for the guess_donors() method

  • Very minor comments on the docs

I've updated the docs.

  • rebase against develop

I've rebased against develop (hopefully I did it correctly!)

  • add entry to CHANGELOG under 0.21.0

I've updated the CHANGELOG

Also, I was wondering whether it would be appropriate to add a reference for users of the class to cite? It would be for the paper for which I wrote a hydrogen bond analysis script on which this class is based.

@orbeckst
Copy link
Member

@KCLPhysics please ping me when ready to review.

Also, @bieniekmateusz / @p-j-smith you might have to add a previous email address to your GitHub account so that some of the older commits are attributed to a GutHub user – unless you don't care.

Should I add @KCLPhysics to the contributors – you seem to be using this account since recently.

@orbeckst
Copy link
Member

Also, I was wondering whether it would be appropriate to add a reference for users of the class to cite? It would be for the paper for which I wrote a hydrogen bond analysis script on which this class is based.

Absolutely!!!!

@p-j-smith
Copy link
Member Author

@KCLPhysics please ping me when ready to review.

Also, @bieniekmateusz / @p-j-smith you might have to add a previous email address to your GitHub account so that some of the older commits are attributed to a GutHub user – unless you don't care.

Should I add @KCLPhysics to the contributors – you seem to be using this account since recently.

Sorry for the confusion with the different accounts. I forgot that I was signed in as @KCLPhysics when I commented a couple of times. Thanks for the heads up about the previous commits, I'll add my other email address to my account.

@p-j-smith
Copy link
Member Author

Brilliant, thanks - I've added a reference to cite, and fixed a small error with the docs, so it looks like we're there!

@orbeckst
Copy link
Member

Don't merge until @richardjgowers has stated what he wants to do in terms of a 0.20.2 release or a 0.21.0 release. This new feature must go into a minor release and cannot go into a patch level release.

@orbeckst
Copy link
Member

@orbeckst
Copy link
Member

Yay! All green.

@p-j-smith do you have the time to clean up the history of this commit? We can't merge this right away (until I hear from @richardjgowers how we want to do the next release). The history of this PR would be much more readable if you could

  1. rebase against latest develop
  2. merge commits into largely independent units

By the latter I mean getting rid of little "I fixed this to make that work" commits. I use git rebase -i develop (interactive rebase). This is a completely new feature so in principle this can be reduced to the new code, new tests, changes to docs, changes in other code (eg deprecations).

Paul Smith added 6 commits October 26, 2019 15:06
The class itself and the run() method have both been simplified in
comparison to the original implementation.
The detection of hydrogen bonds has been optimised using the
MDAnalysis.lib.distances.capped_distance() method.
For loops have been replaced by vectorised numpy code.
The data from run() is stored in a numpy.ndarray in the 'tidy data'
format suggested in Issue MDAnalysis#2177.
The tests are based on those for the original implementation of the
hydrogen bond analysis, which allows for direct comparison of the
results to ensure the behaviour of the new class is correct.
New regression test added to directly compare the behaviour of the
original implementation with the new one.
Added warnings to :mod:`MDAnalysis.analysis.hbonds.hbond_analysis` and
:class:`MDAnalysis.analysis.hbonds.hbond_analysis.HydrogenBondAnalysis`
@p-j-smith
Copy link
Member Author

I've rebased against develop and cleaned up the commits. I hope I did it correctly. I squashed all of the commits into one, then reset the HEAD and grouped the commits roughly in the way you suggested. I had to force push the changes as my local branch was behind the remote hbond_analysis branch after rebasing, but there were no differences between any of the files on the local and remote branches, so I think everything should be fine...

@richardjgowers
Copy link
Member

richardjgowers commented Oct 27, 2019 via email

@orbeckst
Copy link
Member

I merged the CHANGELOG and switched it to 0.21.0.

@p-j-smith if your code has "versionadded" and similar things then please change to 0.21.0. Then just squash my merge and your version changes into a single "version update" commit.

Sorry, these are little tedious things but the heavy lifting is done!

@p-j-smith
Copy link
Member Author

Brilliant, thanks @orbeckst I think we're there!

@orbeckst orbeckst merged commit dc67acf into MDAnalysis:develop Oct 29, 2019
@orbeckst
Copy link
Member

Congratulations @p-j-smith and @bieniekmateusz – a major new analysis class. Well done.

@VOD555 – new H-bond analysis is now in develop, in case you want to add it to PMDA MDAnalysis/pmda#95

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants