LAMMPS vs HOOMD
ldpaniak
other mol-dyn simlutations). Is HOOMD aiming (in principle) to be a
GPU-based replacement for something like LAMMPS? Of course there are
many features to be implemented, but are there any show-stoppers in
such a programme? How important is double-precision in this business?
Scalability appears to be a bit of a difficulty at the moment, but the
physics of simulations cannot be changed. Hardware and (cuda)
software improvements should help out in that respect before long.
A related issue is the feasibility of a LAMMPS to HOOMD script
converter. From the lj_liquid benchmark example I asked about
previously, it seems that inputs for each system (in simple cases)
have a straightforward one-to-one equivalence that should be easy to
automate. Are there obvious problems (excluding input data) that I am
glossing over? Has anyone started such a project? Any recommendations
on what kind of framework to base such a converter? It might have to
run in Windows, so I'm thinking m4 won't be the best choice...
Joshua Anderson
> I am curious where the developers see HOOMD in relation to LAMMPS (or
> other mol-dyn simlutations). Is HOOMD aiming (in principle) to be a
> GPU-based replacement for something like LAMMPS?
simulations (i.e. < 64000 particles). LAMMPS will always be better at
large scale ones (that's what the L in LAMMPS stands for).
For a little more info: I've used LAMMPS for years and really like the
configurability it provides. So I designed HOOMD in the spirit of LAMMPS
so that it would have the same level of configurability and a small
learning curve for current LAMMPS users to switch over.
> Of course there are
> many features to be implemented, but are there any show-stoppers in
> such a programme?
A majority of the features in LAMMPS will translate to the GPU easily.
There will certainly be some challenges to solve, but no show-stoppers
that I'm aware of.
> How important is double-precision in this business?
That depends on who you ask. I've had some people tell me "it's not
double precision, so it is worthless". But my own rigorous tests
indicate that double vs. single doesn't make a single bit of
quantitative difference in the polymer simulations I research or in the
Lennard-Jones liquid.
If/when someone comes to me with a simulation that is demonstrated to
require double precision, I'll start work on adding double precision
into HOOMD. By only adding doubles where they are absolutely needed
(i.e. accumulation), the performance hits will be minor.
> A related issue is the feasibility of a LAMMPS to HOOMD script
> converter. From the lj_liquid benchmark example I asked about
> previously, it seems that inputs for each system (in simple cases)
> have a straightforward one-to-one equivalence that should be easy to
> automate. Are there obvious problems (excluding input data) that I am
> glossing over?
The biggest differences are:
1) HOOMD names particle types, LAMMPS indexes them (easy to solve: just
have the particle type name in HOOMD be '1', '2', ...)
2) Some HOOMD commands must be run before others (i.e. nlist.set_params
cannot be called until pair.something() has been specified where LAMMPS
would allow a neigh_modify before the pair force)
4) LAMMPS fixes and whatnot are labeled by number, whereas HOOMD has you
save them in variables. So you would need some way to generate variable
names.
The biggest problem I see would be maintaining the converter as both
HOOMD and LAMMPS evolve over time. LAMMPS in particular is notorious for
changing the order in which parameters are specified from one version to
the next (which is the reason HOOMD strongly encourages the use of named
parameters in scripts).
> Has anyone started such a project?
Not that I'm aware of.
> Any recommendations
> on what kind of framework to base such a converter? It might have to
> run in Windows, so I'm thinking m4 won't be the best choice...
No idea.