Question about the generation of NEIBSLIST and its iterator

I study the code recently, and i think NEIBSLIST and its iterator (neibs_iteration.cuh) are quite important. i wanna find out how they work.
i draw a diagram base on my understanting. As shown below

If my understanding if wrong, even a small one, please point out.
And more question

  1. d_neibslist_stride equal to m_numAllocatedParticles, is that right?

  2. i found these in simparams.h, if neiblistsize and neiboundpos both equal to 256, where to store vertex and textpoint. Moreover, i found the function resize_neiblist are called in some, not all testcase, but i can not find the default assignment of neiblistsize and neiboundpos, and the marco PVAL, its really hard to understand…
    Absolutely i miss something.
  3. Is there any limite on these value (neiblistsize and neiboundpos)? maximum or something else.

Hello @JoJo,

you seem on the right path. You can find some additional information about the neighbors list structure in the SPHERIC 2019 paper “Bigger, cleaner, faster”. See also the slides here. Note that TESTPOINT are never in the neighbors list of other particles, so the split is only for FLUID (from first location up), BOUNDARY (from d_neibboundpos down) and —only for the SA_BOUNDARY case— VERTEX neighbors (after d_neibboundpos, up).

Concerning your additional questions:

  1. this is currently the case (see setconstants in src/cuda/; the reason for this (as explained in the SPHERIC paper I mentioned) is that this ensures coalescence / better cache hit rates on GPU;
  2. the default neighbors list size is computed in check_neiblistsize (src/, based on the user settings for the kernel radius and smoothing length; the user can override the autocomputed value (this may be needed in case of strange geometries or if one wants to optimize for size by selecting a slightly more conservative value, such as 96 instead of 128 for the default settings);
  3. the only condition is that the neighbors list size must be no less than the boundary position; in the SA_BOUNDARY case is should be strictly larger, since otherwise there’s no room to store the VERTEX particles. And of course there’s limits based on the physical memory available on a GPU.