Continuing dynamics from restart file

Good day!

I am trying to run equilibration of 4 layered graphite (I have attached my input, log files). Since the walltime is limiited on the cluster, I am writing out a restart file periodically. I read in the lammps documentation

the fixes used for a simulation are not stored in the restart file. This means the new input script should specify all fixes it will use. However, note that some fixes store an internal “state” which is written to the restart file. This allows the fix to continue on with its calculations in a restarted simulation. To re-enable such a fix, the fix command in the new input script must use the same fix-ID and group-ID as was used in the input script that wrote the restart file. If a match is found, LAMMPS prints a message indicating that the fix is being re-enabled. If no match is found before the first run or minimization is performed by the new script, the “state” information for the saved fix is discarded.

I checked the documentation for fix npt and saw that it can be restarted in this manner. However, I notice that this is not the case. When I read in the restart file after 80000 ts, its temperature is about 580 K when it starts but it reduces to the Tstart temperature, without continuing the dynamics from where it stopped.

The reason why I am using reax and not reax/c is because I get a segmentation fault at around 19000 timesteps when I run the exact same input script.

Thank you for your help.

graphene.dat (28.1 KB)

in.equilibration (1.1 KB)

in.readrestart (745 Bytes)

log.equilibration (25.1 KB)

log.lammps (1.39 KB)

Good day!

I am trying to run equilibration of 4 layered graphite (I have attached my
input, log files). Since the walltime is limiited on the cluster, I am
writing out a restart file periodically. I read in the lammps documentation

the fixes used for a simulation are not stored in the restart file. This
means the new input script should specify all fixes it will use. However,
note that some fixes store an internal “state” which is written to the
restart file. This allows the fix to continue on with its calculations in a
restarted simulation. To re-enable such a fix, the fix command in the new
input script must use the same fix-ID and group-ID as was used in the input
script that wrote the restart file. If a match is found, LAMMPS prints a
message indicating that the fix is being re-enabled. If no match is found
before the first run or minimization is performed by the new script, the
“state” information for the saved fix is discarded.

I checked the documentation for fix npt and saw that it can be restarted in
this manner. However, I notice that this is not the case. When I read in the
restart file after 80000 ts, its temperature is about 580 K when it starts
but it reduces to the Tstart temperature, without continuing the dynamics
from where it stopped.

but that is because of the fix you specified:

fix ensemble2 all npt temp 300.0 677.0 10.0 iso 1.0 1.0 100.0

which starts a *new* ramp from 300K to 677K over all coming 80000 time
steps. as you can see the immediate restart works perfectly.

since your previous run was interrupted some time in between, you have
to use the start and stop keywords to run.

rather than "run 80000" try instead: "run 100000 upto start 20000 stop 100000"

The reason why I am using reax and not reax/c is because I get a
segmentation fault at around 19000 timesteps when I run the _exact_ same
input script.

which ffield.reax file did you use?

axel.

i also believe that using isotropic cell motion is not a good idea for
your setup. if at all, you should only couple x and y and leave z
unchanged.

1 Like

a few more comments.

with your setup, you're using the CPUs very inefficiently, since your
box is mostly empty, but the default processor distribution is by cell
volume.

you can change your boundary condition from p p p to p p s and then
shrink your box in z direction to -1 11

then i would run fix npt with x and y controlled independently and z
not coupled.

fix ensemble1 all npt temp 300.0 300.0 10.0 x 1.0 1.0 100.0 y 1.0 1.0 100.0

using reax/c is not a problem either, you just need to play a bit with
the safezone parameter.

with reax/c and the optimized processor distribution, i can run on my
dual core 1.8 GHz laptop faster than your machine with reax
the run is already beyond the 20k steps

axel.

Do you mean like this?

fix ensemble1 all npt temp 300.0 300.0 10.0 couple xy 1.0 1.0 100.0

Why exactly is this the case here? Also, is this the reason for the segmentation fault I get when using reax/c?

Thank you.

Okay. Thank you for your comments. I will implement them.

Dear Axel,

I would like to know why it is important to only couple x and y and leave z unchanged. In what situation would x,y and z be coupled? Could you please shed some light or direct me to some place I could read the theory behind it?

Thank you

Dear Axel,

I would like to know why it is important to only couple x and y and leave z
unchanged. In what situation would x,y and z be coupled? Could you please
shed some light or direct me to some place I could read the theory behind
it?

this is primarily just common sense.

you have basically a 2-d system and don't really want periodic
interactions in z, since you have set a long z length.
a) if you'd couple z independently, that part of the box will
eventually collapse and you get some form of graphite, which is
apparently not what you want.
b) if you couple x,y, and z isotropically, the desire of the system in
z-direction to collapse will cause unphysical compression in x and y
c) if you set z to be non-periodic, there is no need to couple z. in
fact, LAMMPS won't allow it.
d) in general, you only want to do isotropic coupling for systems
where compressibility is isotropic (e.g. liquids).

axel.

1 Like