Simplify and optimize coordination numbers

[giacomofiorin]

This PR contains several improvements:

• Condense the computation of multiple variants of coordination numbers: all classes are now derived from coordnum with the exception of h_bond
• Separate the pairlist update from the switching function computation
• Skip computing the switching function if pairwise distance is too large for the given tolerance
• Optionally, allow using an inline function to compute PBC distances instead of a virtual function

Fixes #908

[giacomofiorin]

Side note: an additional simplification I wanted to add would be to change the h_bond class so that it can handle multiple pairs (i.e. not just a single pair). The alpha variable at that point could just use a single child h_bond object instead of multiple ones (and the same could be done for the angles, at which point it's clearly way out of scope for this PR).

[HanatoK]

Looks good to me! Although I need to use inline for compute_pair_coordnum to restore the performance after refactoring.

[giacomofiorin]

Looks good to me! Although I need to use inline for compute_pair_coordnum to restore the performance after refactoring.

Thanks! I have been removing inline from template functions because it's generally redundant. But reading a bit more, that generally happens when the template functions are fully specialized: here, we have now four nested levels of template functions calling one another...

[giacomofiorin]

In the latest commits, I added partial support for skipping the virtual function (part of which could cause the 22% performance loss in #911).

I have not tested yet the code in NAMD: by default, the current PBC function is used.

[HanatoK]

In the latest commits, I added partial support for skipping the virtual function (part of which could cause the 22% performance loss in #911).

I have not tested yet the code in NAMD: by default, the current PBC function is used.

I just tested with the CUDAGM interface, and using useInternalPBC on is indeed much faster!

[giacomofiorin]

Commit df18a13 was cherry-picked from #913, but I also amended its message to reflect that the bug was not being triggered yet (I have just now pushed the same commit to master).

I had previously added the same change in the integrate_cudagm branch, but it's more complex there and not suitable for backporting. I'll now rebase the integrate_cudagm branch onto the current master and open it as a draft PR.

[jhenin]

@giacomofiorin Do you wish to merge this first, and then #913 into master, or merge #913 into this?

[giacomofiorin]

@giacomofiorin Do you wish to merge this first, and then #913 into master, or merge #913 into this?

I thought #913 was just for comments, based on the "[RFC]" tag

[HanatoK]

#913 is just for discussion and not in good shape. I think it is better to merge this one at first.

[giacomofiorin]

@jhenin Okay with you to merge?