Add Unit Cell RDF capability
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
Comments (11)
-
-
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.
-
- changed component to density
-
Proposed solution:
-
Create a method
Box.replicate(self, points, images=None, r_cut=None)
that accepts anNx3
list of points and 3-element array of integer images >= 0,[Ix, Iy, Iz]
, to replicate in the ±x, ±y, ±z direction. Ifr_cut
is provided instead, it will compute the image counts needed to extend a distance ofr_cut
outside the box. Thereplicate
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. -
Call RDF with the larger box, using the
ref_points
as the original points inside the box andpoints
as the replicated points. (I might have it backward, not 100% sure)
-
-
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.
-
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. -
reporter I think the replicate method makes sense and would MinMax dev time with functionality
-
Upon further consideration, the
replicate
method already exists. It's called theVoronoiBuffer
. This is currently limited to ±1 image in each dimension. I believe the best solution to this issue is:- Decide whether
VoronoiBuffer
should be renamedParticleBuffer
and moved tobox.pyx
or another module. - Make the
VoronoiBuffer
handle buffer distances greater than one image by computing the appropriate number of images to iterate over in each dimensionIx
,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). - Implement
VoronoiBuffer.replicate(self, points, buffer=None, images=None)
function described above. I prefer this set of arguments wherebuffer
is the same asr_cut
in the previous description. - 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.
- Decide whether
-
- attached VoronoiBufferTest.ipynb
-
- changed status to open
-
- changed status to resolved
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.
- Log in to comment
HPMC has an AABBTree implementation of multiple image interactions, and computes the image list needed to reach a specific r_cut.