Add physical search radius to NeighborParticleContainer

[desjardi]

Summary

Add fillNeighbors(Real search_radius) and buildNeighborList(check_pair, Real bin_size) overloads for efficient short-range particle interactions when the interaction radius is much smaller than the mesh cell size. fillNeighbors(Real search_radius):

• Stores m_search_radius; computes m_num_neighbor_cells from it
• getNeighborTags: position-based early exit for interior particles; per-level grow via ceil(search_radius / dx[lev])
• GetCommTagsBox: per-level grow via ceil(search_radius / dx[lev]) buildNeighborList(check_pair, Real bin_size):
• Spatial binning at bin_size resolution, independent of mesh dx
• Searches +/-1 bin when bin_size ~ interaction radius fillNeighbors() modified to reset m_search_radius to zero. When m_search_radius == 0, all existing code paths are unchanged.

Additional background

Ref: #5243

Checklist

The proposed changes:

• fix a bug or incorrect behavior in AMReX
• add new capabilities to AMReX
• changes answers in the test suite to more than roundoff level
• are likely to significantly affect the results of downstream AMReX users
• include documentation in the code and/or rst files, if appropriate

[atmyers]

Hi @desjardi,

Thank you for adding this capability! There are two issues I'm concerned about with the current PR:

1. As it stands, if a user calls the version of fillNeighbors with the physical cutoff argument, the default m_num_neighbor_cells will be over-ridden and used for subsequent calls to the version of fillNeighbors without that argument. I think that if we want to allow the flexibility of the physical cutoff distance changing from call-to-call, we should treat the number of cutoff cells to use and the cutoff distance as specific to that call, rather than modifying m_num_neighbor_cells. Alternatively, if we don't want to allow that flexibility, then I think putting the cutoff distance in the constructor makes more sense.
2. Since this only effects the CPU code path for now, could you add an assertion using AMREX_ALWAYS_ASSERT_WITH_MESSAGE that fails if a user tries to call the new version of fillNeighbors while AMREX_USE_GPU is defined?

Thanks,
Andrew