Fix deform output influenced by run time

Hello LAMMPS users,

I have a question about some behavior I’m seeing with fix deform.

I’m trying to run a uniaxial tension simulation at constant strain rate for a bead-spring polymer model. The ensemble is periodic and is first equilibrated via fix npt at 0 pressure and 300K in a separate run. The tensile-test run starts by reading the resulting restart file.

I’m using fix deform to stretch the ensemble in the z direction. I’m also using fix npt for zero pressure conditions in the x and y directions. The commands I’m using are

fix STRETCH all deform 1 z vel ${vel} units box

fix NPT all npt temp 300 300 100 x 0 0 1000 y 0 0 1000

where ${vel} is a specified stretch velocity.

What I’m seeing is that if I run the simulation for two different lengths of time (e.g., 200,000 steps vs 400,000 steps), the simulation evolves slightly differently in each run. What might be causing this result? If I’m stretching the unit cell at the same velocity in each case, I would expect the simulations to exactly match at all the time points they have in common.

I’m running version April 12 2013. The issue occurs both on a single processor and in parallel.

Thanks,

Brian

First, I would try the current version to see if the behaviour
changes. If they only diverge after some large # of timesteps (1000s) and
the divergence grows slowly, then I wouldn’t worry about it.

There could be some other setting in your script that depends on the

the length of run (200K vs 400K) where LAMMPS is calculating
some intermediate value based on that time delta. Even though
the calculations are algebraically identical, there could be numerical
round-off which makes them not numerically identical. Which will

lead to grandual divergence of the 2 runs.

Steve

Thanks for the reply, Steve. The latest version produces identical behavior. However, it is true that the divergence only becomes noticeable after about 20K steps. I mainly wanted to make sure I wasn’t somehow using fix deform incorrectly between cases. Sounds like it’s just some sort of internal round-off error, which is OK with me.

Brian