Neighborlists? about nnpops HOT 3 OPEN

The current CPU code uses an O(N^2) algorithm to build a neighbor list that get used for computing angles. I plan to do the same for CUDA.

It would be straightforward to replace the O(N^2) search with a voxel algorithm or something similar. Whether that's a good idea depends on what we're optimizing for. Our initial requirements specified that it should be optimized for systems of around 100 atoms. At that size, the full search is quite fast and doing anything more complicated would likely end up being slower. As systems get larger, it will become more of a bottleneck. I expect that by around 1000 atoms it will be significant, but until I get the CUDA implementation done and profile it I won't know. Perhaps even at that size most of the time will still be spent in the angles. We'll see.

from nnpops.

Maybe we should consider more modularity. The neighbour list should be a separate operation from the featurizer by itself. So in the future, it is straightforward to replace it with a more efficient implementation if needed and reuse for other NNPs. For example, the SchNet implementation would benefit greatly from an efficient neighbour list operation.

from nnpops.

My goal in the ANI implementation is performance, not modularity. We can have a separate stand-alone neighbor list implementation if that would be useful. ANI has a few properties that make it best to handle separately. 1) It has separate cutoffs for radial and angular features. 2) Most of the time is spent computing the angular features, so it's important to have a neighbor list with the shorter cutoff just for them. 3) Combining the neighbor list building with the radial features lets us build the neighbor list at minimal extra cost.

from nnpops.