[lammps-users] Compute msd problem with stored coordinates

There’s something going on with compute_msd where if you call certain fixes in a certain way, it looses track of the stored initial coordinates and therefore reports the wrong msd. Or more precisely, it doesn’t lose the initial coordinates entirely but looks for them at the wrong index. I was messing with this because I thought it would be a fun way to learn a bit about how the fixes and computes work (which it was), but I got a bit stuck, so I am passing along this input file and script which yields the wrong MSD, at least on my computer. (I compiled by simply typing make mac_mpi and am using the 24Mar10 version of lammps.)

In this example, I have 10 atoms and am calculating the MSD of just the 10th one (of type 3). The output file msd.out shows the correct msd for 500 timesteps, then it jumps to a large value because it is being calculated as though the initial coordinates were 0 0 0. After you run and then call a different fix ave/time (not the fix ave/time that prints out the MSD) and run again, it looks like compute_msd’s store_coords fix now has its atoms sorted in a different order than compute_MSD does. To see the problem, it seems you have to define the other fix ave/time before the MSD fix initially, then call the fix ave/time again. It doesn’t matter if you run in between those calls to fix ave/time or if you call the MSD fix ave/time again.

Lisa

in.test (631 Bytes)

in.test (631 Bytes)

Can't run your in.test without the data file.

Steve

Yeah, I’m having some email issues; try this.
Lisa

input.lammps (1.08 KB)

This was a bug with how replacing a fix with a new one with the same ID
operated on some stored memory pointers. The 26Mar10 patch should
fix it. Note that your input script is odd, b/c you are re-defining several
fixes with different parameters. e.g. file names, so that will open/close
files. But you should now get expected MSD values.

Steve