Accessing neighbor list from python (also, setting rigid body velocities)

[Yan Wong]

Hi

I'm using HOOMD-blue v0.10.1 on Mac OS X 10.6, and trying to write an Analyzer to collect information on clusters of particles in a Hoomd simulation (where a cluster is defined as all adjoining particles - that is, particles within a distance r_cut from any other in the cluster). For this it would be helpful to access the individual items in the neighbor list, but I can't see how to do that from within python. For example, from within an interactive session, I can do:

>>> dir(nlist.cpp_nlist)

['__class__', '__delattr__', '__dict__', '__doc__', '__format__', '__getattribute__', '__hash__', '__init__', '__instance_size__', '__module__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__', 'addExclusion', 'addExclusionsFromAngles', 'addExclusionsFromBonds', 'addExclusionsFromDihedrals', 'addOneFourExclusionsFromTopology', 'addOneThreeExclusionsFromTopology', 'benchmark', 'clearExclusions', 'compute', 'countExclusions', 'estimateNNeigh', 'forceUpdate', 'getSmallestRebuild', 'printStats', 'setEvery', 'setFilterBody', 'setFilterDiameter', 'setMaximumDiameter', 'setProfiler', 'setRCut', 'setStorageMode', 'storageMode']

But none of these give me access to the elements of the neighbor list itself (the dev docs suggest there are functions such as getNListIndexer() for this, but it's not obvious if they are meant to be exposed to Python. Nevertheless, at the end of libhoomd/computes/NeighborList.cc, there is a comment

//! helper function for accessing an elemeng of the neighb rlist: python __getitem__

which seems to imply I should be able to access elements of the actual list from some python object. Any idea how I do it?

Also a completely different aside: I'm trying to set the initial velocities of various rigid bodies in my simulation. The documentation implies that I should be able to set, e.g.

>>> system.bodies[0].velocity = (1,-1,0)

But if I do this, then recheck on the value, It hasn't changed, e.g.:

>>> system.bodies[0].velocity
(0.0, 0.0, 0.0)

What am I doing wrong?

Cheers

Yan Wong

[Joshua A. Anderson]

On Apr 18, 2012, at 10:08 AM, Yan Wong wrote:

> Hi
>
> I'm using HOOMD-blue v0.10.1 on Mac OS X 10.6, and trying to write an Analyzer to collect information on clusters of particles in a Hoomd simulation (where a cluster is defined as all adjoining particles - that is, particles within a distance r_cut from any other in the cluster). For this it would be helpful to access the individual items in the neighbor list, but I can't see how to do that from within python. For example, from within an interactive session, I can do:

In the current code, there is no way to access the neighbor list data from python. If this feature is desirable, I could enable it trivially. However, it would have the same low performance as the particle data access methods (one function call per particle). Higher performance read access to the particle data via numpy is on the todo list for 0.11.0.

In everything I've worked on, if it was a big enough analysis task to require a neighbor list, then I wrote it in C++ so it would run in a reasonable amount of time.

One issue with exposing the nlist to python is the use case of r_cut values. I find that the r_cut value for the analysis (i.e. rdf for a semi-large maximum r) is often very different from the simulation r_cut. 1) Right now, only force computes are queried to determine the maximum r_cut. 2) Another issue is that the simulation will be artificially slowed by larger r_cuts than are needed. Again, I've always worked around this with a cell list specific to the analysis tools.

> //! helper function for accessing an elemeng of the neighb rlist: python __getitem__
>
> which seems to imply I should be able to access elements of the actual list from some python object. Any idea how I do it?

This is from an old version of the nlist code and is now unused. The old version did allow python to access the neighbor list, but this feature was unused so I didn't implement it in the new one.

> Also a completely different aside: I'm trying to set the initial velocities of various rigid bodies in my simulation. The documentation implies that I should be able to set, e.g.
>
>>>> system.bodies[0].velocity = (1,-1,0)
>
> But if I do this, then recheck on the value, It hasn't changed, e.g.:
>
>>>> system.bodies[0].velocity
> (0.0, 0.0, 0.0)
>
> What am I doing wrong?

You are doing nothing wrong. It appears that there is a bug the prevents the velocity set from working at all. I've fixed the bug in the latest revision of master.

--------
Joshua A. Anderson, Ph.D.
Chemical Engineering Department, University of Michigan

[Yan]

On Wednesday, April 18, 2012 3:34:10 PM UTC+1, Joshua Anderson wrote:

In the current code, there is no way to access the neighbor list data from python. If this feature is desirable, I could enable it trivially. However, it would have the same low performance as the particle data access methods (one function call per particle). Higher performance read access to the particle data via numpy is on the todo list for 0.11.0.

Ah - thanks. I'll probably end up doing it in C++, but I thought I'd get the logic working in Python first, as I find it easier to mess around with.

 

One issue with exposing the nlist to python is the use case of r_cut values. ... Again, I've always worked around this with a cell list specific to the analysis tools.

That's a good point, thanks. In my case, I'm only looking for very local particles, so I suspect it'll be OK. But it's worth bearing in mind.

 

This is from an old version of the nlist code and is now unused. The old version did allow python to access the neighbor list, but this feature was unused so I didn't implement it in the new one.

Thanks for clarifying.

 

> Also a completely different aside: I'm trying to set the initial velocities of various rigid bodies in my simulation... 

You are doing nothing wrong. It appears that there is a bug the prevents the velocity set from working at all. I've fixed the bug in the latest revision of master.

Oh - good. Thanks a lot for all your help.

Yan