Add check based on maximum number of pairs

[RMeli]

The maximum number of pairs that can be handled is limited by VESIN_CUDA_MAX_PAIRS_PER_POINT. The following tests was failing with a large cutoff:

import cupy as cp
import numpy as np

from vesin import NeighborList

dtype = cp.float64

box = cp.eye(3, dtype=dtype) * 3.0
points = cp.array(np.random.default_rng(0).random((100, 3), dtype=dtype) * 3.0)
print(len(points))

calculator = NeighborList(cutoff=4.0, full_list=True, algorithm="cell_list")
i, j, s, D, d = calculator.compute(points, box, True, "ijSDd")

This PR introduces bound checks preventing out of bound accesses.

[Luthaf]

Thanks, this looks very good! I think the example with cutoff=4 and 100 points should work, so we might have to also increase VESIN_CUDA_MAX_PAIRS_PER_POINT anyway.

[RMeli]

Thant can be done easily. What do you think would be a reasonable threshold? In this case the length of the neighbor list was about 100k.

[Luthaf]

So thinking a bit more about it, the density in this example was kinda insane. A more reasonable example, with the density of osmium, gives me around 200 pairs per atom for a cutoff equal to the cell size. Since the number of pairs will scale with the cutoff cube, I guess something like

max_pairs = 256 * (cutoff / smallest_distance_between_box_faces)**3

Should be fine? It seems to always be larger than the number of pairs for some tests I ran.

[Luthaf]

And then we can change the example to use a cell of 11A, with a cutoff of 14 A

[RMeli]

So thinking a bit more about it, the density in this example was kinda insane.

Yes, exactly. But was not sure what your requirement are (like doing some crazy high-pressure stuff...).

It seems to always be larger than the number of pairs for some tests I ran.

Currently, max_pairs is computed using the hard-coded VESIN_CUDA_MAX_PAIRS_PER_POINT. Are you suggesting to make the maximum number of pairs flexible at runtime?

[Luthaf]

Are you suggesting to make the maximum number of pairs flexible at runtime?

I think this makes more sense, no? This way we don't waste VRAM when we have a small cutoff, but we don't crash unless something very wrong is going on

[Luthaf]

Merging this for now, and we can add a dynamic max_pair in a separate PR