Pair queries for non-periodic boxes and dimensions

[justinGilmer]

Is your feature request related to a problem? Please describe.

Being able to identify pairs when in a fully non-periodic or slightly non-periodic (non-periodic in >=1 dimension(s)) would be extremely helpful for the mbuild users and developers when generating bonds in our systems. Routinely we have surfaces that might be periodic in X and Y, but not in Z (slab geometries). Using freud, we cannot do neighbor queries if some/all of the dimensions are non-periodic.

File locality.pyx:221, in freud.locality.NeighborQueryResult.toNeighborList()

ValueError: Pair queries in a non-periodic box are not implemented.

We can support this ourselves with pseudo-periodic boxes (where we take the non-periodic dimensions and add (2*max(box.lengths)) to the length in that non-periodic dimension. This essentially ensures that we will not generate periodic bonds across those dimensions, and we can then re-scale the box whenever freud is finished querying the pairs.

Note: At the commit of this permalink, there is a bug in this method, but this has a bugfix already in the works and the issue we are describing above happens after the bugfix.

Describe the solution you'd like

Create successful neighbor queries with non-periodic or slightly non-periodic systems without the need to exaggerate the box dimensions to create pseudo-periodicity.

Describe alternatives you've considered

We can create "pseudo- non-periodic" boxes by extending the box lengths of the non-periodic dimensions by a large amount, which will ensure we dont find neighbors in those directions, but this is quite hacky.

Additional context
N/A, tagging @daico007, @chrisiacovella who helped bring this issue up to me.

[bdice]

Official support for nonperiodic boxes via the Box.periodic flags for x/y/z is possible, but it would take a lot of testing to make sure we get it right. I have helped with some efforts in this direction but it hasn’t been high enough priority for anyone to implement it properly. Up to now, everyone has just done the large box workaround as you described. If someone is interested in taking on the project, I am happy to provide guidance and code review!

[justinGilmer]

The large box workaround has been working great for us as well and is something we routinely do in the group too.

At the moment, we are able to get the features we desire without major changes. Although this might be something im interested in later!

Thanks, @bdice !

[bdice]

Great to hear that is working for you.

One other note for ease of use: the Box object can be multiplied by a scalar. The lengths will be multiplied by that scalar and the shear factors are held constant. Example:

big_box = box * 2