compute com/molecule -- artifactual drift in c.o.m. trajectory

version 2May11, running in parallel on 48 cores

I am using ‘compute com/molecule’ to follow the center of mass of a molecule diffusing through a polymer matrix. I have been encountering a problem with the c.o.m. values produced by the com/molecule compute. The c.o.m. appears to be subject to an artifactual drift, such that the diffusive motion is biased in a certain direction.

I have attached an image, ‘com_drift.png’ of the c.o.m. trajectory in the xy (black); xz (red); and yz (green) planes, in which the drift behavior is evident. *(see more info at end of email). I have also attached the input files required to produce such artifactual c.o.m. behavior (datafile and infile).

I have found this directed drift in c.o.m. values in most simulations I have run, although it sometimes does not show up until a few hundred thousand steps. It always shows up if the simulation is run long enough. I am aware of the repeated warnings in the manual about how one must be careful with image flags. I have tried resetting image flags between different fixes (langevin, npt, nvt, etc.) in the simulation, which doesn’t seem to help things. Further, I notice that the drift occurs in many cases where the com of the diffusant molecule does not cross a periodic boundary. Finally, the c.o.m. values don’t jump in value, but rather experience a continuous drift, which seems to suggest that the problem is not related to crossing a periodic boundary.

Finally, you’ll notice that I have a brief langevin equilibration stage preceding the production npt stage. While switching fixes does seem to encourage the artifactual com trajectories, it is not required. I had relented and simply run a very long fix nvt sim and the drift behavior kicked in after a couple of million steps. The point is that you can play around with different fixes and resetting image flags, but this behavior will always appear at some point. Does anyone have any idea what might be causing this artifact?

Chris

*FYI, this c.o.m. trajectory in the xy/xz/yz planes can be obtained by running the following shell command on the c.o.m. trajectory data file, ‘com.dat’, output by lammps as part of the fix print command issued in the infile:

cat com.dat | grep -v [a-z] | awk ‘{print $2 " " $3}’ >> comtraj.dat ; echo >> comtraj.dat; cat com.dat | grep -v [a-z] | awk ‘{print $2 " " $4}’ >> comtraj.dat; echo >> comtraj.dat; cat com.dat | grep -v [a-z] | awk ‘{print $3 " " $4}’ >> comtraj.dat; xmgrace -nxy comtraj.dat

com_drift.png

datafile.tar.gz (93.4 KB)

infile (1.15 KB)

chris,

version 2May11, running in parallel on 48 cores

[...]

I have found this directed drift in c.o.m. values in most simulations I have
run, although it sometimes does not show up until a few hundred thousand
steps. It always shows up if the simulation is run long enough. I am aware

yes, this kind of drift (of the total system c.o.m) is basically
unavoidable unless
some atoms of your system are "anchored" in some way.

of the repeated warnings in the manual about how one must be careful with
image flags. I have tried resetting image flags between different fixes

i don't think that this applies here.

(langevin, npt, nvt, etc.) in the simulation, which doesn't seem to help
things. Further, I notice that the drift occurs in many cases where the com
of the diffusant molecule does not cross a periodic boundary. Finally, the
c.o.m. values don't jump in value, but rather experience a continuous drift,
which seems to suggest that the problem is not related to crossing a
periodic boundary.

indeed, it is a result of truncation errors due to the nature of floating point
numbers. unless you have a dissipative component in your thermalization,
it will always manifest. you can use fix moment to remove it, but you have
to be careful to pick a suitable frequency as you don't want to remove
fluctuations, but also not too large redistribution of momentum.

Finally, you'll notice that I have a brief langevin equilibration stage
preceding the production npt stage. While switching fixes does seem to
encourage the artifactual com trajectories, it is not required. I had

when you do the switch, you should use the velocity command to
remove any leftover c.o.m. momentum.

relented and simply run a very long fix nvt sim and the drift behavior
kicked in after a couple of million steps. The point is that you can play
around with different fixes and resetting image flags, but this behavior
will always appear at some point. Does anyone have any idea what might be
causing this artifact?

yes, see above.

cheers,
    axel.