Proper way to trigger reneighbouring

Dear LAMMPS users and developers,

I was trying to implement the free energy computation scheme described by Schmid and Schilling in http://arxiv.org/abs/1008.3456. Basically, it is thermodynamic integration to a reference state with the original interaction plus some local potential energy well for each particle. The absolute free energy can be obtained of this reference state can be obtained through another, almost trivial, way described in the paper.

To quickly make the system reach equilibrium in the reference state, they add two MC moves: One where particles are allowed to exchange their interaction well, and another where particles are relocated with a bias to their local well.

The first type of move is implemented and appears to work properly, but the second one seems to cause lost atoms. This is not so strange as I am just modifying the array atom->x. I would assume that, after a succesful move, I should force neighbour lists to be updated. In fix_gcmc the displacements are only small, so I suppose there is no need for explicit reneighboring after every step. So the question is: What would be the best way to do this? Can I just modify the atom->x array and then call some member function of neighbor? Are there other technicalities I should be aware of?

A second question is about how to parallelise this. Right now everything I do is in serial, but I suppose to properly implement these moves, there should be some way for a particle to exchange it’s tethered coordinate with another one that can be on a different processor. Is there a way to deal with this? If I just copy-paste/follow the same programming style as in fix gcmc, would I run into difficulties or should that in principle work?

Many thanks in advance,

Stefan

Dear LAMMPS users and developers,

I was trying to implement the free energy computation scheme described by
Schmid and Schilling in http://arxiv.org/abs/1008.3456. Basically, it is
thermodynamic integration to a reference state with the original interaction
plus some local potential energy well for each particle. The absolute free
energy can be obtained of this reference state can be obtained through
another, almost trivial, way described in the paper.

To quickly make the system reach equilibrium in the reference state, they
add two MC moves: One where particles are allowed to exchange their
interaction well, and another where particles are relocated with a bias to
their local well.

The first type of move is implemented and appears to work properly, but the
second one seems to cause lost atoms. This is not so strange as I am just
modifying the array atom->x. I would assume that, after a succesful move, I
should force neighbour lists to be updated. In fix_gcmc the displacements

not only the neighbor lists, you also need a forward communication to
update the positions of all corresponding ghost atom copies of this
atom.

are only small, so I suppose there is no need for explicit reneighboring
after every step. So the question is: What would be the best way to do this?
Can I just modify the atom->x array and then call some member function of
neighbor? Are there other technicalities I should be aware of?

if the move can be longer than ~half the communication cutoff, you'll
have to treat it like removing and inserting a particle.

A second question is about how to parallelise this. Right now everything I
do is in serial, but I suppose to properly implement these moves, there
should be some way for a particle to exchange it's tethered coordinate with
another one that can be on a different processor. Is there a way to deal
with this? If I just copy-paste/follow the same programming style as in fix
gcmc, would I run into difficulties or should that in principle work?

MC moves are intrinsically serial. but to do the operation in
parallel, you probably have to treat this like a particle delete/add,
as i was alluding to before. this also requires that you generate
exactly the same sequence of pseudo random numbers for the coordinated
operations on multiple processors. so looking at fix gcmc, and
particularly the full energy option with particle insertion seems like
the right strategy to me.

axel.