Some questions about the usage of NeighborParticleContainer.

[Bowen0330]

Hello AMReX Team!

Recently I have wrtitten some code for simulating soft sphere collision, and I encountered some problems to be solved:

1. For efficient "contact search" among particles, I created my own class derived from NeighborParticleContainer class. If I use the periodic boundary conditions, will the neighbor particles update automatically according to the periodic bc?
2. Continuing from last one, if it will, should I set the nGrow >= 1 when I define the NeighborParticleContainer class?
3. Is there any way to get access to the Neighbor particles' SOA data? For improving efficiency, I think using SOA format maybe better?
4. I also found the fill/buildNeighborList cost a lot during the computation, and I can do nothing but decrease the times of fill/buildNeighborList. Is there other way to speed these processes up?

I refer to this tutorial to code: ExampleCodes/Particles

Thanks for any advice!

Regards,
Bowen

[atmyers]

Hi Bowen,

1. Yes
2. You should set nGrow to at least 1 if you need neighbors, the exact number depends on how many cells you need to search to be sure you've found all the possible neighbors of a given particle. For example, if the particle diameter is less than the cell size, you know that all potential neighbors of particle i are within 1 cell from the one containing the particle's cell center. You may want more depending on the particle interaction cutoff and on whether you want to reuse the same neighbor list for multiple time steps.
3. The neighbor particles are added to the end of the usual particle arrays, so you access the SOA data the same way you would for the regular particles, but with an index between numRealParticles and numTotalParticles-1.
4. What hardware are you running on? One way to speed this up is to use a half neighbor list, i.e. only add particle j to particle i's list if j < i, for example. If you do this, you need to use atomics for the force computation, but it may be worth it if the build time is dominating. You also might want to explore the above tradeoff of re-using the same neighbor list for multiple steps.

-Andrew

[Bowen0330]

Thank you for your detailed reply, Andrew!

Regarding the fourth question, I'm running the simulation on AMD CPUs.

Yes, I also considered using a half neighborhood list, as you mentioned above.

This way, each particle is only calculated once, and we can update both two particles simultaneously during each collision calculation. What I'm using now is a full neighborhood list, so I can only update one particle per calculation, without updating its neighboring particles, to avoid duplicate calculations.

I'm trying to decrease the frequency of fill/build neighbors, this indeed works.
I also want to know if the updateNeighbor() is necessary to call every step? I think the data of neighbors can be updated by my self, so this function is used to determine which particles should be current particle's neighbor?

[atmyers]

Hi Bowen,

updateNeighbor() is used to synchronize the neighbor particle's data based on what happens to the corresponding valid particle. If you're building in extra space in your neighbor list so that you don't have to rebuild every time step, you still need to call updateNeighbors() every step because the valid particles have been moved on other ranks, so the latest position data needs to be communicated to ranks that have ghosted copies of those particles.

-Andrew

[Bowen0330]

Thank you very much! I have no problem now.