Add Unit Cell RDF capability

[Eric Harper]

as suggested by Julia:

Allow for freud to calculate the rdf out to a spec'd distance of the unit cell. This will require some thinking, but should be able to be done if we do not use the cell list and take advantage of the unwrap command, specifying the images. This method will need to calculate the number of images required to get the specified r_cut

[Joshua Anderson]

HPMC has an AABBTree implementation of multiple image interactions, and computes the image list needed to reach a specific r_cut.

[Matthew Spellings]

Maybe instead of adding iteration logic to each compute method in freud, we could just add a replicate function like hoomd uses? If we ever get around to that refactorization we discussed, that would also be able to handle this nicely (without the replicate function), I think.

[Bradley Dice]

Proposed solution:

1. Create a method Box.replicate(self, points, images=None, r_cut=None) that accepts an Nx3 list of points and 3-element array of integer images >= 0, [Ix, Iy, Iz], to replicate in the ±x, ±y, ±z direction. If r_cut is provided instead, it will compute the image counts needed to extend a distance of r_cut outside the box. The replicate method returns an 2-tuple containing an array of points of length (2*Ix + 1) * (2*Iy + 1) * (2*Iz + 1) * N x 3 and a larger box resized to fit the new points. I believe it would be most sensible to implement this in Cython.

2. Call RDF with the larger box, using the ref_points as the original points inside the box and points as the replicated points. (I might have it backward, not 100% sure)

[Vyas Ramasubramani]

That seems reasonable enough to me. Since the RDF currently takes r_max as a parameter on construct that (AFAIK) can't be modified, it would probably be fine to do this on construction as well. If we wanted, though, we could also retain the original system and have the RDF do this internally in the compute.

[Bradley Dice]

If it's worth noting, I know of several places where I've created a function that behaves like the Box.replicate method I described above. It may be valuable to create such a method, irrespective of how we choose to implement a unit cell RDF.

[Eric Harper]

I think the replicate method makes sense and would MinMax dev time with functionality

[Bradley Dice]

Upon further consideration, the replicate method already exists. It's called the VoronoiBuffer. This is currently limited to ±1 image in each dimension. I believe the best solution to this issue is:

1. Decide whether VoronoiBuffer should be renamed ParticleBuffer and moved to box.pyx or another module.
2. Make the VoronoiBuffer handle buffer distances greater than one image by computing the appropriate number of images to iterate over in each dimension Ix, Iy, Iz. When doing this, alter the loops over images to handle 2D and 3D boxes in the same loop structure (should be a simple modification).
3. Implement VoronoiBuffer.replicate(self, points, buffer=None, images=None) function described above. I prefer this set of arguments where buffer is the same as r_cut in the previous description.
4. The replication could be called automatically if the RDF r_max is greater than half of the shortest box side. This would guarantee correct results for periodic systems, I believe.

[Vyas Ramasubramani]

Addressed by Pull Request #192. Use the ParticleBuffer object in the box module. Also see the ParticleBuffer Unit Cell example in the freud-examples repository.