Sticky particles modelling

130 views
Skip to first unread message

Rob Ward

unread,
Oct 7, 2015, 7:31:09 PM10/7/15
to hoomd-users, Sapna Ravindran
Hi everyone, I am just starting out with HOOMD so have a really basic question that I hope can just give me a slight push in the right direction.

I want to model using Brownian Dynamics (BD) rather than Molecular Dynamics (MD) some particles (~ 1 um diameter) that are sticky.  That means that when the particles touch each other, they stick together thereafter.

One caveat is that the particles will have a sticking probability that is a function of time, so the model needs to know how long they are touching each other.

So, my questions...

1. Is this a situation where using a plugin would be best?

2. Lots of computation would be required after each time step, to calculate whether any two particles are close together (O(n!) sets of calculations).  Is there an efficient way of doing this?  Is it built in to HOOMD?  How is this data accessed...? Via a plugin, or via the Python script?  I presume there are data structures inside HOOMD that are accessible?

3. Would using a modified potential be a better idea -- one that has (say) a delta function or square well potential to model the stuck-particles situation, in superposition with (say) a traditional LJ potential?

Many thanks,

Rob


Åsmund Ervik

unread,
Oct 8, 2015, 6:11:39 AM10/8/15
to hoomd-users, ssap...@gmail.com
Regarding your question 2: HOOMD constructs a neighbour list which will dramatically speed this up. You can find a good discussion of how neighbour lists in general work eg. in the classic book by Allen and Tildesley (which is a very good introduction to molecular dynamics).

To further enhance this: the typical neighbour list includes neighbouring particles which are a fair amount further away than actually touching. In the latest HOOMD v1.2 you can make "inhomogeneous" neighbour lists where the range of the neighbour list is different for different potentials. So you could make an additional "dummy" Lennard-Jones potential with epsilon=0 and the sigma set such that the range of the neighbour list is a tiny bit bigger than a particle diameter. This would then include only particles that will stick together.

Michael Howard

unread,
Oct 8, 2015, 9:34:03 AM10/8/15
to hoomd-users, ssap...@gmail.com
1. You probably want to write a plugin because you need to know how long certain particles are stuck together (basically, the time between when the particles first become neighbors and the the time they are no longer neighbors). This will require additional data, and the fastest way to do this is from the plugin level. Consider extending ForceCompute to do this.

2. I'm not sure where you get O(N!) from since in the worst case computing distances between all particles is O(N^2), but using neighbor lists as suggested is definitely the way that you want to go to identify particles that are close together. You can test whether nlist.cell or nlist.tree is faster for your problem -- it depends on how far away you need to search -- both are roughly O(N). If the distance is very short, I would think nlist.tree could be better.

3. I don't know what model would be best for your problem. Using a discontinuous potential is generally a bad idea because you have impulse forces. You might want to read up a little on MD to see why this is a problem.

--Mike

Rob Ward

unread,
Oct 8, 2015, 3:48:25 PM10/8/15
to hoomd-users, ssap...@gmail.com
Thanks Michael for the advice!  Very helpful :-)

Regarding the O(N!), perhaps I have this wrong.  Assuming 5 particles in the system, and I want to test for stickiness, I would check between particle "1" and the other 4, then particle "2" and the other three (since 1 and 2 have already been tested). Thus N!  This is different to measuring forces between all particles, in which case I can see it would be N^2.

Rob Ward

unread,
Oct 8, 2015, 3:49:10 PM10/8/15
to hoomd-users, ssap...@gmail.com
Thanks Asmund, appreciated!

Michael Howard

unread,
Oct 9, 2015, 8:38:06 AM10/9/15
to hoomd-users, ssap...@gmail.com
You need to sum not multiply :-)

(N-1) + (N-2) + ... + 1 + 0 = (1/2)N(N-1) ~ N^2

This is exactly the same as computing pair forces when you apply action-reaction on the CPU (i.e., you compute the force per pair, not per particle, and then apply the equal and opposite force to both particles in the pair).

Resonanz

unread,
Mar 13, 2016, 10:04:59 PM3/13/16
to hoomd-users
Gosh Michael, you are right.  Not sure what I was thinking..... thanks for pointing that out :-)  I appreciate your help.
Reply all
Reply to author
Forward
0 new messages