fix/move on restart file

Hello LAMMPS users,

I am encountering some strange behavior when trying to use fix/move on an input which begins from a restart file.

Quick simulation description:

My ensemble is non-periodic and first equilibrated under NVT conditions. Some atomic motions are constrained to prevent things from “flying apart”. A restart file is written at the conclusion of the equilibration. Beginning from this restart file, I then want to impose a motion on a group of atoms using fix/move linear.

My problem:

I am imposing fix/move as

fix MOVE moveatoms move linear 0.0 0.0 ${vel} units box # units are real

${vel} is the velocity I want to impose, which I want to vary in a series of runs.

When I use this fix, atoms in the group are moving in the opposite direction than desired on the first time step of the simulation (confirmed through visualization). On subsequent time steps, they move with the correct velocity and in the correct direction. The distance the atoms move in the wrong direction on the first step seems to be proportional to the magnitude of the velocity prescribed (e.g., vel = 1 moves then much farther in the wrong direction on the first step than vel = 0.1).

If instead of fix/move on these atoms, I try an alternative fix (e.g, fix nve or fix nvt), then the simulation proceeds as it should. I’ve also tried deleting all previous fixes at the end of the equilibration run, so that the restart file does not contain any information on these, but there was no change in simulation results.

Is there anything tricky about using the fix/move command when starting from a restart file? I’ve ran this exact input script by reading the original data file (where the equilibration starts from) rather than the restart, and the fix/move error does not occur in this case. I am using the 12-Apr-2013 version of LAMMPS.

Any help or insight is appreciated!

Thanks,

Brian

If your restart script re-defines any fixes that were in the original
script, their info can get carried over. See the read_restart command
for how to use or avoid this feature. Fix move does store
info in the restart file (see its doc page). If your original
script had a fix move, then it would be important
that the new command (if it used the same ID, else no issue),

was consistent with the old one (timestep and velocity you are applying).

Other than that I can’t think of any way that reading a data file
vs a restart file is different. Once you start the new run,

fix move knows nothing about where the atoms came from.

If this doesn’t help, please post a simple (as possible) example
that reproduces the problem, and we can take a look.

Steve

So I figured out quite that resetting the time step via

reset_timestep 0

was causing the problem when using the restart file as the starting point. Omitting this line makes the problem proceed as expected.

Resetting the timestep is a convenience (rather than a necessity) for me, so I’d say my problem is solved at the moment. But out of curiosity, is this a normal or expected outcome? Why would the reset influence the behavior of fix/move linear?

So I figured out quite that resetting the time step via

reset_timestep 0

was causing the problem when using the restart file as the starting point.
Omitting this line makes the problem proceed as expected.

Resetting the timestep is a convenience (rather than a necessity) for me, so
I’d say my problem is solved at the moment. But out of curiosity, is this a
normal or expected outcome? Why would the reset influence the behavior of
fix/move linear?

because after a restart fix move has to figure out how far down the
prescribed movement LAMMPS has already progressed. this is done by
storing the time step number, where the movement began. so for a
perfect continuation, you may also need to set the "upto" option to
run, depending on what kind of movement you are implementing.

axel.

yes, that is normal behavior. As Axel says, the restart info
for fix move includes the timestep, so it can continue to update
the atom positions consistent with the reference initial time.

So if you reset_timestep you screw that up. The doc page

should state this explicitly.

Steve