.. index:: fix nve/limit
.. index:: fix nve/limit/kk

fix nve/limit command
=====================

Accelerator Variants: *nve/limit/kk*

Syntax
""""""

.. code-block:: LAMMPS

   fix ID group-ID nve/limit xmax

* ID, group-ID are documented in :doc:`fix <fix>` command
* nve = style name of this fix command
* xmax = maximum distance an atom can move in one timestep (distance units)

Examples
""""""""

.. code-block:: LAMMPS

   fix 1 all nve/limit 0.1

Description
"""""""""""

Perform constant NVE updates of position and velocity for atoms in the
group each timestep.  A limit is imposed on the maximum distance an
atom can move in one timestep.  This is useful when starting a
simulation with a configuration containing highly overlapped atoms.
Normally this would generate huge forces which would blow atoms out of
the simulation box, causing LAMMPS to stop with an error.

Using this fix can overcome that problem.  Forces on atoms must still
be computable (which typically means two atoms must have a separation
distance > 0.0).  But large velocities generated by large forces are
reset to a value that corresponds to a displacement of length *xmax*
in a single timestep.  *Xmax* is specified in distance units; see the
:doc:`units <units>` command for details.  The value of *xmax* should be
consistent with the neighbor skin distance and the frequency of
neighbor list re-building, so that pairwise interactions are not
missed on successive timesteps as atoms move.  See the
:doc:`neighbor <neighbor>` and :doc:`neigh_modify <neigh_modify>` commands
for details.

Note that if a velocity reset occurs the integrator will not conserve
energy.  On steps where no velocity resets occur, this integrator is
exactly like the :doc:`fix nve <fix_nve>` command.  Since forces are
unaltered, pressures computed by thermodynamic output will still be
very large for overlapped configurations.

.. note::

   You should not use :doc:`fix shake <fix_shake>` in conjunction
   with this fix.  That is because fix shake applies constraint forces
   based on the predicted positions of atoms after the next timestep.
   It has no way of knowing the timestep may change due to this fix,
   which will cause the constraint forces to be invalid.  A better
   strategy is to turn off fix shake when performing initial dynamics
   that need this fix, then turn fix shake on when doing normal dynamics
   with a fixed-size timestep.

Restart, fix_modify, output, run start/stop, minimize info
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""

No information about this fix is written to :doc:`binary restart files <restart>`.  None of the :doc:`fix_modify <fix_modify>` options
are relevant to this fix.

This fix computes a global scalar which can be accessed by various
:doc:`output commands <Howto_output>`.  The scalar is the count of how
many updates of atom's velocity/position were limited by the maximum
distance criterion.  This should be roughly the number of atoms so
affected, except that updates occur at both the beginning and end of a
timestep in a velocity Verlet timestepping algorithm.  This is a
cumulative quantity for the current run, but is re-initialized to zero
each time a run is performed.  The scalar value calculated by this fix
is "extensive".

No parameter of this fix can be used with the *start/stop* keywords of
the :doc:`run <run>` command.  This fix is not invoked during :doc:`energy minimization <minimize>`.

----------

.. include:: accel_styles.rst

----------

Restrictions
""""""""""""
 none

Related commands
""""""""""""""""

:doc:`fix nve <fix_nve>`, :doc:`fix nve/noforce <fix_nve_noforce>`,
:doc:`pair_style soft <pair_soft>`

Default
"""""""

none
