Use OpenMM to calculate neighbors list?

[Peter Eastman]

It's now been merged into the master mdtraj repository. Try it out. The function is mdtraj.compute_neighborlist(). I did end up basing it on the OpenMM CPU version, so it's quite fast.

Peter

[Maxim Imakaev]

In my tests, it is fast, but does not beat Scipy.cKDTree. It also consumes all 20 CPUs and probably would be slower in single-thread testings. OpenMM also is often better. I would do some more realistic testing with actual trajectories from our simulations.

I put test results here: http://wiz.mit.edu/mdtrajTest.png

[Peter Eastman]

Yeah, it's somewhat simplified from the code in OpenMM. It operates on individual atoms, rather than on blocks of 4 or 8. That makes it slower, but also means it return an exact neighbor list. If two atoms are marked as neighbors in the output, that means they definitely are within the cutoff distance, which isn't true for the OpenMM version.

The mdtraj version is parallelized with OpenMP, so if you want to limit how many threads it uses, you can set the OMP_NUM_THREADS environment variable.

In your benchmarks of the scipy version, does that include the time to build the kd-tree, or just the time to query the neighbors after it's built? If the latter, that will of course be much faster.

Peter

[Maxim Imakaev]

In scipy tests, I do both creation of the tree and calculation of the list. For mdtraj code, I had to write a code that converts a list of np arrays to a single M-by-2 np array, but I tried to keep it maximally efficient.

Using blocks instead of single atoms probably gives a significant speedup. Going over a list of contacts and filtering the extra out should not be the time-limiting step.