[EXTERNAL] Re: Bugs in maintenance of shear history across restart files?

Kevin wrote:
In fact, I bodged the integration loop a bit to avoid this issue when
testing continuity of shear history across a restart file. If you want
identical restarts, I think that this could be achieved by writing the
restart file on the last timestep either before or after the force
computation (doesn't matter which because of shearupdate), but
certainly before the final_integrate step. On a restart, Verlet::setup
calculates the forces which will be the same as before. Then it is
necessary to complete the final timestep by running post_force,
final_integrate and the end_of_step functions (including the position
remapping within domain caused by fix_deform). By doing this, it is
possible to have perfect continuity across a restart file for these
particular fixes which move particles. As you might expect, the
differences are small though.

I just re-read this last paragarph of re-read Kevin's last email.

I think it is pointing out the same issue with the velocity-dependent
granular potentials. It is not specific to restart files
or fix deform. It is an issue with any continued run, e.g.

if you just do

run 100
run 100

instead of

run 200

you will have the same problem. The 2 runs won't match.

The solution is not as simple as moving the writing of the
restart file to earlier in the timestep. That would
be incorrect for any other kind of potential. And it's
conceptually incorrect to write out velocities that aren't
really at the end-of-timestep. Restart files could
be used for other things, like post-analysis or creating
a data file.

There are two other potentials in LAMMPS that have this issue,
DPD and lubricate, b/c they are both also velocity dependent.