modify write_restart command to repeat same simulation

Hi,

Since the neighbor lists will be rebuilt whenever lammps write a restart file, the result of two simulation with different write_restart tilmestep will be different statistically.
The material I simulated behaves differently because of this.
If I modify the write_restart.cpp file by deleting the following two lines, will I be able to repeat same simulation ?
comm->exchange();
comm->borders();

Regards,
Wenting

The reason LAMMPS rebuilds neighbor lists on a timestep

when a restart file is written is so that when you restart

you get as close as possible the original simulation had it

continued on. E.g. if you run a simulation for 2N steps

and write a restart file on step N, then read the restart

file and run for N more steps, it should be similar
to the 2N result of the first run. Of course if N is large,

or you perform the 2nd run on a different # of procs,

or you use random numbers (e.g. fix langevin) then

things will always diverge statistically.

So there is no simple answer to this Q:

If I modify the write_restart.cpp file by deleting the following two lines, will I be able to repeat same simulation ?
comm->exchange();
comm->borders();

So I don’t suggest you do that. Also re: this comment:

will be different statistically.
The material I simulated behaves differently because of this.

That’s a “feature” of MD and reality. If you do 2 runs

and they give different results (statistically only),

you can’t say either is right. “Right” is the average

of the statistical ensemble.

Steve

Hi Steve,

Thank you for your answer. I understand now. So even though I managed to delete the neighbor rebuild process somehow when the restart file is written, the restart file generated accordingly is meaningless and can’t be used to continue the simulation.

Regards,
Wenting

I didn’t say the restart file you wrote out was meaningless.

It could be fine to read it back in and continue on.

I said I think you are worrying about exact restarts when

you don’t need to be.

Steve