Second design issue – Particle objects?

In my last post I touched on the question of data structures for particle systems. It boils down to the question of whether the basic data structure is an individual particle, or a system of particles.

The code you find scattered about the web from the graphics community prefers for the basic data structure to be a particle. I think I’ll find differently when I look at molecular dynamics codes. I’m compiling a list here of the design approach taken by several codes. They are all either production quality publicly available codes, or archetypal design patterns detailed in published work.

First up, NAMD. There is an atom data structure. However neither position or velocity appear to be contained in it. I have to say the comments are pretty bloody sparse!

Next, GADGET uses structures for particles, such that they are referenced in the form particle.position[dimension]. They copy the data (or pointers, not sure) before doing computations though – the force calculation for particle i goes something like

pos = particle(i).position
vel = particle(i).velocity
force = do_something_with(pos,vel)

Not sure why, there is probably a reason.

For now, the group of particles will be one object, with the arrays of various properties as vectors. This leaves scope to introduce multiple groups (e.g. for two mixing fluids). However some of the C functions I need to wrap take arrays of positions, masses etc as arguments, so some scattering will be required. If it turns out the scattering costs too much, I’ll move to a simple r[],v[] type system.



  1. Naveen said

    Hi Andrew, I found your blog through your reference to my debugging comment (I’m infinite8s) :) Anyway, I’m also a computational scientist (studying biology using molecular dynamics, however) and suggest you look at LAMMPS (, which is a general particle simulator with which you can set up detailed all-atom biological simulations, or coarse-grained granular simulations that let you model flow, etc.

  2. ac12 said

    LAMMPS looks very comprehensive – that’s quite a feature list.

    It doesn’t look like it does SPH, although DPD these days, as far as i can tell, it mostly just SPH with thermal fluctuations.

    I tried to tack SPAM onto my supervisor’s MD code, but it seemed easier at the time to build a new base, reusing neighbour list modules and so on. I’ll need to take a look at the LAMMPS source code and have a think about how straightforward it would be to extend it with the flavour of SPH we’re using.

RSS feed for comments on this post · TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: