restart file, so that the operation of the fix continues in an

uninterrupted fashion.

Note that info about region definitions is NOT included in restart

files.  So you must re-define your region and if it is a moving

region, define its motion attributes in a way that is consistent with

the simulation that wrote the restart file.  In particular, if you

want to change its motion attributes (e.g. its velocity), then you

should insure the postition/orientation of the region at the initial

restart timestep is the same as it was on the timestep the restart

file was written.  If this is not possible, then you may need to

ignore info in the restart file by defining a new fix wall/gran/region

command in your restart script (e.g. with a different fix ID).

NOTE: Information about region definitions is NOT included in restart

files.  This means that in a restart script you must re-define a

region to associate with this fix in a consistent manner with how a

region was used in the original script (same style, ID, geometric

attributes).  If it is a moving region, you should also define its

motion attributes consistent with the original simulation that wrote

the restart file.  If you use a region that is a union or intersection

of sub-regions, LAMMPS will do some limited checking that the new

region is consistent with the one defined in the previous script

before reassigning the motion attributes, but does not currently check

recursively down a nested tree of union or intersection regions.  Note

that if you want to change the region's motion attributes in the

restart run (e.g. its velocity), then you should insure the

postition/orientation of the region at the initial restart timestep is

the same as it was on the timestep the restart file was written.

Otherwise the position of the region may make an instantanous jump

when the restart simulation begins.  If this is not easy or possible,

then you can just ignore info in the restart file by defining a new

fix wall/gran/region command in your restart script (e.g. with a

different fix ID).

None of the "fix_modify"_fix_modify.html options are relevant to this

fix.  No global or per-atom quantities are stored by this fix for

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.  LAMMPS will also print a list of

fixes for which the information is being discarded.  See the doc pages

for individual fixes for info on which ones can be restarted in this

manner.  Note that fixes which are created internally by other LAMMPS

commands (computes, fixes, etc) will have style names which are

all-capitalized, and IDs which are generated internally.

for the saved fix is discarded.  At the time the discard occurs,

LAMMPS will also print a list of fixes for which the information is

being discarded.  See the doc pages for individual fixes for info on

which ones can be restarted in this manner.  Note that fixes which are

created internally by other LAMMPS commands (computes, fixes, etc)

will have style names which are all-capitalized, and IDs which are

generated internally.

Likewise, the "computes"_fix.html used for a simulation are not stored

in the restart file.  This means the new input script should specify

its calculations in a consistent manner.

NOTE: There are a handful of commands which can be used before or

between runs which require a system initialization.  Examples include

the "balance", "displace_atoms", and "delete_atoms" commands.  This is

because they may migrate atoms to new processors.  Thus they will also

discard unused "state" information from fixes.  This means that, if

desired, you must re-specify the relevant fixes and computes (which

create fixes) before those commands are used.

between runs which may require a system initialization.  Examples

include the "balance", "displace_atoms", "delete_atoms", "set" (some

options), and "velocity" (some options) commands.  This is because

they can migrate atoms to new processors.  Thus they will also discard

unused "state" information from fixes.  You will know the discard has

occurred because a list of discarded fixes will be printed to the

screen and log file, as explained above.  This means that if you wish

to retain that info in a restarted run, you must re-specify the

relevant fixes and computes (which create fixes) before those commands

are used.

Some pair styles, like the "granular pair styles"_pair_gran.html, also

use a fix to store "state" information that persists from timestep to