Bug with set command and/or library interface's "set/get coords"

If one uses the "set" command to give an atom an "unreasonable" position,
LAMMPS will "lose" the atom. For example,
   units metal
   lattice bcc 2.80
   region simbox block 0 20 0 20 0 20
   create_box 1 simbox
   create_atoms 1 box
   pair_style lj/cut 2.5 # just for demo purposes; happens w/ anything
   pair_coeff * * 1.0 1.0
   mass 1 55 # also not important
   run 1
   set atom 1 x 28.5 y 28.5 z 28.5 # Right near the center of simbox
   run 1
will reproduce the problem if run on, say, 5 MPI processes. Ten will also
trigger it. I think the problem exists because the atom in question is
moved from one process's domain, /through/ another process's domain, and
into a third domain that is not connected to that of the first process.
The same script run on 1, 2, 4, or 8 processes works fine, because there
is a direct connection between domains for most possible moves.

This problem is magnified when run through the library interface; in that,
atoms can be moved fairly far by external dynamics (if the user so
chooses) before dumping their coordinates back to LAMMPS, and LAMMPS will
then decide that the atoms are lost. Swapping two atoms during a Monte
Carlo step, for example, will trigger this fairly quickly.

I don't know if there's an easy fix to this one, other than issuing an
error message about moving atoms too far using the "set" command.

Karl D. Hammond
University of Tennessee, Knoxville
[email protected]...

"You can never know everything, and part of what you know is always
   wrong. A portion of wisdom lies in knowing that. A portion of courage
   lies in going on anyway."
"Nothing ever goes as you expect. Expect nothing, and you will not be

LAMMPS could provide an option with the
"set x" command or thru the lib interface
to do an optional (expensive) communicate
after the atom coord(s) changed to insure
atoms are assigned to the correct processor.
The method for this exists in LAMMPS, we just
didn't envision people would use set or the lib
to move atoms to arbitrary new positions.


If it's an easily callable method (something like "comm->reassign_atoms"),
I could simply call that procedure if I ever envision that problem. I
can think of a couple of ways around it for the particular problem I
tripped this with that might get around it for the case I had in mind,
too. I suspect it would be difficult/expensive to reassign the atom
to the "right" process every time, and doing so might break the lost atoms
functionality (which is very helpful in such situations as accidentally
creating atoms on top of each other or choosing a time step that is way
too big).

I might suggest a warning in the documentation that the arguments to x,
y, and z for the "set atom" command are not completely arbitrary; atoms
cannot move too far beyond their local process's domain or LAMMPS
will consider them lost.

Thanks for your help!