assumed bug in fix deform erate upon restart

Hello list,

I’m using LAMMPS version 16Feb16, which isn’t the newest one available, but I checked and where I couldn’t find my issue, so I assume that it has not been reported so far, if it even is a bug.

The issue occurs in a script that runs for a number of steps before using the fix deform with erate as in this example:

restart 100 rs
run 1000
fix 1 all deform 1 xy erate ${rate}
run 5000 upto start 1000 stop 5000

Now, when I resume the run at some point within the second part (steps between 1000 and 5000), the box is loaded with a tilt, which is correct. However, in the next step the system is further sheared by the ammount it should have been sheared so far, effectively doubeling the tilt. When X(3000) is the tilt at step 3000, where I restart the calculation, that would mean that the system goes from X(3000) -> X(3000+(3001)). Multiple restarts add up the additional deformation every time.

“This fix can perform deformation over multiple runs, using the start and stop keywords of the run command.” (from the documentation page) led me to believe that the start/stop statement was needed here. But the simulation does not behave as expected with the statement; without start or stop the deformation is exactly as expected, though.

The formula for erate taken from the documentation page

T(t) = T0 + L0eratedt

leads me to suspect that T0 here is taken from the restart step 3000, instead of the start-step 1000. Of course step 1000 would not be known to the new instance of lammps, so the value of T0 would have to be calculated using that same equation backwards.

Again, I’m not sure if this would be considered a bug, or works as intended. Thank you for your help

Richard

Hello list,

I'm using LAMMPS version 16Feb16, which isn't the newest one available,
but I checked http://lammps.sandia.gov/bug.html and
http://lammps.sandia.gov/bug2016.html where I couldn't find my issue, so
I assume that it has not been reported so far, if it even is a bug.

The issue occurs in a script that runs for a number of steps before using
the fix deform with erate as in this example:

restart 100 rs
run 1000
fix 1 all deform 1 xy erate ${rate}
run 5000 upto start 1000 stop 5000

Now, when I resume the run at some point within the second part (steps
between 1000 and 5000), the box is loaded with a tilt, which is correct.
However, in the next step the system is further sheared by the ammount it
should have been sheared so far, effectively doubeling the tilt. When
X(3000) is the tilt at step 3000, where I restart the calculation, that
would mean that the system goes from X(3000) -> X(3000+(3001)). Multiple
restarts add up the additional deformation every time.

"This fix can perform deformation over multiple runs, using the *start*
and *stop* keywords of the *run* <http://lammps.sandia.gov/doc/run.html>
command." (from the documentation page) led me to believe that the
start/stop statement was needed here. But the simulation does not behave as
expected with the statement; without start or stop the deformation is
exactly as expected, though.

The formula for erate taken from the documentation page

T(t) = T0 + L0*erate*dt

leads me to suspect that T0 here is taken from the restart step 3000,
instead of the start-step 1000. Of course step 1000 would not be known to
the new instance of lammps, so the value of T0 would have to be calculated
using that same equation backwards.

Again, I'm not sure if this would be considered a bug, or works as
intended. Thank you for your help

​yes, this is a bug. if you don't mind, please file a formal bug report at
https://github.com/lammps/lammps/issues and, if possible, include a small
test example demonstrating the issue. please see, e.g., ​
https://github.com/lammps/lammps/issues/500 or
https://github.com/lammps/lammps/issues/523
as examples.

thanks,
      axel.

richard,

i’ve looked a bit at the source code for fix deform, and it seems cleaner to just add support for storing/restoring the initial box data from binary restart files.
you can see the necessary changes (and some related cleanup) here: https://github.com/lammps/lammps/pull/510/commits/daa77176add6f9edb3058a54584c398b0515898b

this change should be released with the new patch to LAMMPS, most likely early next week.

axel.