+If you get an error message about an invalid command in your input
+script, you can determine what command is causing the problem by
+looking in the log.lammps file or using the :doc:`echo command <echo>`
+to see it on the screen. If you get an error like "Invalid ...
+style", with ... being fix, compute, pair, etc, it means that you
+mistyped the style name or that the command is part of an optional
+package which was not compiled into your executable. The list of
+available styles in your executable can be listed by using :ref:`the -h command-line argument <start_7>`. The installation
+and compilation of optional packages is explained in the :ref:`installation instructions <start_3>`.
+
+For a given command, LAMMPS expects certain arguments in a specified
+order. If you mess this up, LAMMPS will often flag the error, but it
+may also simply read a bogus argument and assign a value that is
+valid, but not what you wanted. E.g. trying to read the string "abc"
+as an integer value of 0. Careful reading of the associated doc page
+for the command should allow you to fix these problems. Note that
+some commands allow for variables to be specified in place of numeric
+constants so that the value can be evaluated and change over the
+course of a run. This is typically done with the syntax *v_name* for
+a parameter, where name is the name of the variable. This is only
+allowed if the command documentation says it is.
+
+Generally, LAMMPS will print a message to the screen and logfile and
+exit gracefully when it encounters a fatal error. Sometimes it will
+print a WARNING to the screen and logfile and continue on; you can
+decide if the WARNING is important or not. A WARNING message that is
+generated in the middle of a run is only printed to the screen, not to
+the logfile, to avoid cluttering up thermodynamic output. If LAMMPS
+crashes or hangs without spitting out an error message first then it
+could be a bug (see :ref:`this section <err_2>`) or one of the following
+cases:
+
+LAMMPS runs in the available memory a processor allows to be
+allocated. Most reasonable MD runs are compute limited, not memory
+limited, so this shouldn't be a bottleneck on most platforms. Almost
+all large memory allocations in the code are done via C-style malloc's
+which will generate an error message if you run out of memory.
+Smaller chunks of memory are allocated via C++ "new" statements. If
+you are unlucky you could run out of memory just when one of these
+small requests is made, in which case the code will crash or hang (in
+parallel), since LAMMPS doesn't trap on those errors.
+
+Illegal arithmetic can cause LAMMPS to run slow or crash. This is
+typically due to invalid physics and numerics that your simulation is
+computing. If you see wild thermodynamic values or NaN values in your
+LAMMPS output, something is wrong with your simulation. If you
+suspect this is happening, it is a good idea to print out
+thermodynamic info frequently (e.g. every timestep) via the
+:doc:`thermo <thermo>` so you can monitor what is happening.
+Visualizing the atom movement is also a good idea to insure your model
+is behaving as you expect.
+
+In parallel, one way LAMMPS can hang is due to how different MPI
+implementations handle buffering of messages. If the code hangs
+without an error message, it may be that you need to specify an MPI
+setting or two (usually via an environment variable) to enable
+buffering or boost the sizes of messages that can be buffered.
+
+
+----------
+
+
+.. _err_2:
+
+Reporting bugs
+--------------
+
+If you are confident that you have found a bug in LAMMPS, follow these
+steps.
+
+Check the `New features and bug fixes <http://lammps.sandia.gov/bug.html>`_ section of the `LAMMPS WWW site <lws_>`_ to see if the bug has already been reported or fixed or the
+`Unfixed bug <http://lammps.sandia.gov/unbug.html>`_ to see if a fix is
+pending.
+
+Check the `mailing list <http://lammps.sandia.gov/mail.html>`_
+to see if it has been discussed before.
+
+If not, send an email to the mailing list describing the problem with
+any ideas you have as to what is causing it or where in the code the
+problem might be. The developers will ask for more info if needed,
+such as an input script or data files.
+
+The most useful thing you can do to help us fix the bug is to isolate
+the problem. Run it on the smallest number of atoms and fewest number
+of processors and with the simplest input script that reproduces the
+bug and try to identify what command or combination of commands is
+causing the problem.
+
+As a last resort, you can send an email directly to the
+ This is not allowed if the kspace_modify overlap setting is no.
+
+*PPPM order < minimum allowed order*
+ The default minimum order is 2. This can be reset by the
+ kspace_modify minorder command.
+
+*PPPM order cannot be < 2 or > than %d*
+ This is a limitation of the PPPM implementation in LAMMPS.
+
+*PPPMDisp Coulomb grid is too large*
+ The global PPPM grid is larger than OFFSET in one or more dimensions.
+ OFFSET is currently set to 4096. You likely need to decrease the
+ requested accuracy.
+
+*PPPMDisp Dispersion grid is too large*
+ The global PPPM grid is larger than OFFSET in one or more dimensions.
+ OFFSET is currently set to 4096. You likely need to decrease the
+ requested accuracy.
+
+*PPPMDisp can only currently be used with comm_style brick*
+ This is a current restriction in LAMMPS.
+
+*PPPMDisp coulomb order cannot be greater than %d*
+ This is a limitation of the PPPM implementation in LAMMPS.
+
+*PPPMDisp used but no parameters set, for further information please see the pppm/disp documentation*
+ An efficient and accurate usage of the pppm/disp requires settings via the kspace_modify command. Please see the pppm/disp documentation for further instructions.
+
+*PRD command before simulation box is defined*
+ The prd command cannot be used before a read_data,
+ read_restart, or create_box command.
+
+*PRD nsteps must be multiple of t_event*
+ Self-explanatory.
+
+*PRD t_corr must be multiple of t_event*
+ Self-explanatory.
+
+*Package command after simulation box is defined*
+ The package command cannot be used afer a read_data, read_restart, or
+ create_box command.
+
+*Package cuda command without USER-CUDA package enabled*
+ The USER-CUDA package must be installed via "make yes-user-cuda"
+ before LAMMPS is built, and the "-c on" must be used to enable the
+ package.
+
+*Package gpu command without GPU package installed*
+ The GPU package must be installed via "make yes-gpu" before LAMMPS is
+ built.
+
+*Package intel command without USER-INTEL package installed*
+ The USER-INTEL package must be installed via "make yes-user-intel"
+ before LAMMPS is built.
+
+*Package kokkos command without KOKKOS package enabled*
+ The KOKKOS package must be installed via "make yes-kokkos" before
+ LAMMPS is built, and the "-k on" must be used to enable the package.
+
+*Package omp command without USER-OMP package installed*
+ The USER-OMP package must be installed via "make yes-user-omp" before
+ LAMMPS is built.
+
+*Pair body requires atom style body*
+ Self-explanatory.
+
+*Pair body requires body style nparticle*
+ This pair style is specific to the nparticle body style.
+
+*Pair brownian requires atom style sphere*
+ Self-explanatory.
+
+*Pair brownian requires extended particles*
+ One of the particles has radius 0.0.
+
+*Pair brownian requires monodisperse particles*
+ All particles must be the same finite size.
+
+*Pair brownian/poly requires atom style sphere*
+ Self-explanatory.
+
+*Pair brownian/poly requires extended particles*
+ One of the particles has radius 0.0.
+
+*Pair brownian/poly requires newton pair off*
+ Self-explanatory.
+
+*Pair coeff for hybrid has invalid style*
+ Style in pair coeff must have been listed in pair_style command.
+
+*Pair coul/wolf requires atom attribute q*
+ The atom style defined does not have this attribute.
+
+*Pair cutoff < Respa interior cutoff*
+ One or more pairwise cutoffs are too short to use with the specified
+ rRESPA cutoffs.
+
+*Pair dipole/cut requires atom attributes q, mu, torque*
+ The atom style defined does not have these attributes.
+
+*Pair dipole/cut/gpu requires atom attributes q, mu, torque*
+ The atom style defined does not have this attribute.
+
+*Pair dipole/long requires atom attributes q, mu, torque*
+ The atom style defined does not have these attributes.
+
+*Pair distance < table inner cutoff*
+ Two atoms are closer together than the pairwise table allows.
+
+*Pair distance > table outer cutoff*
+ Two atoms are further apart than the pairwise table allows.
+
+*Pair dpd requires ghost atoms store velocity*
+ Use the comm_modify vel yes command to enable this.
+
+*Pair gayberne epsilon a,b,c coeffs are not all set*
+ Each atom type involved in pair_style gayberne must
+ have these 3 coefficients set at least once.
+
+*Pair gayberne requires atom style ellipsoid*
+ Self-explanatory.
+
+*Pair gayberne requires atoms with same type have same shape*
+ Self-explanatory.
+
+*Pair gayberne/gpu requires atom style ellipsoid*
+ Self-explanatory.
+
+*Pair gayberne/gpu requires atoms with same type have same shape*
+ Self-explanatory.
+
+*Pair granular requires atom style sphere*
+ Self-explanatory.
+
+*Pair granular requires ghost atoms store velocity*
+ Use the comm_modify vel yes command to enable this.
+
+*Pair granular with shear history requires newton pair off*
+ This is a current restriction of the implementation of pair
+ granular styles with history.
+
+*Pair hybrid sub-style does not support single call*
+ You are attempting to invoke a single() call on a pair style
+ that doesn't support it.
+
+*Pair hybrid sub-style is not used*
+ No pair_coeff command used a sub-style specified in the pair_style
+ command.
+
+*Pair inner cutoff < Respa interior cutoff*
+ One or more pairwise cutoffs are too short to use with the specified
+ rRESPA cutoffs.
+
+*Pair inner cutoff >= Pair outer cutoff*
+ The specified cutoffs for the pair style are inconsistent.
+
+*Pair line/lj requires atom style line*
+ Self-explanatory.
+
+*Pair lj/long/dipole/long requires atom attributes mu, torque*
+ The atom style defined does not have these attributes.
+
+*Pair lubricate requires atom style sphere*
+ Self-explanatory.
+
+*Pair lubricate requires ghost atoms store velocity*
+ Use the comm_modify vel yes command to enable this.
+*Pair style hbond/dreiding requires newton pair on*
+ See the newton command for details.
+
+*Pair style hybrid cannot have hybrid as an argument*
+ Self-explanatory.
+
+*Pair style hybrid cannot have none as an argument*
+ Self-explanatory.
+
+*Pair style is incompatible with TIP4P KSpace style*
+ The pair style does not have the requires TIP4P settings.
+
+*Pair style lj/charmm/coul/charmm requires atom attribute q*
+ The atom style defined does not have these attributes.
+
+*Pair style lj/charmm/coul/long requires atom attribute q*
+ The atom style defined does not have these attributes.
+
+*Pair style lj/charmm/coul/long/gpu requires atom attribute q*
+ The atom style defined does not have this attribute.
+
+*Pair style lj/class2/coul/cut requires atom attribute q*
+ The atom style defined does not have this attribute.
+
+*Pair style lj/class2/coul/long requires atom attribute q*
+ The atom style defined does not have this attribute.
+
+*Pair style lj/class2/coul/long/gpu requires atom attribute q*
+ The atom style defined does not have this attribute.
+
+*Pair style lj/cut/coul/cut requires atom attribute q*
+ The atom style defined does not have this attribute.
+
+*Pair style lj/cut/coul/cut/gpu requires atom attribute q*
+ The atom style defined does not have this attribute.
+
+*Pair style lj/cut/coul/debye/gpu requires atom attribute q*
+ The atom style defined does not have this attribute.
+
+*Pair style lj/cut/coul/dsf requires atom attribute q*
+ The atom style defined does not have these attributes.
+
+*Pair style lj/cut/coul/dsf/gpu requires atom attribute q*
+ The atom style defined does not have this attribute.
+
+*Pair style lj/cut/coul/long requires atom attribute q*
+ The atom style defined does not have this attribute.
+
+*Pair style lj/cut/coul/long/gpu requires atom attribute q*
+ The atom style defined does not have this attribute.
+
+*Pair style lj/cut/tip4p/cut requires atom IDs*
+ This is a requirement to use this potential.
+
+*Pair style lj/cut/tip4p/cut requires atom attribute q*
+ The atom style defined does not have this attribute.
+
+*Pair style lj/cut/tip4p/cut requires newton pair on*
+ See the newton command. This is a restriction to use this
+ potential.
+
+*Pair style lj/cut/tip4p/long requires atom IDs*
+ There are no atom IDs defined in the system and the TIP4P potential
+ requires them to find O,H atoms with a water molecule.
+
+*Pair style lj/cut/tip4p/long requires atom attribute q*
+ The atom style defined does not have these attributes.
+
+*Pair style lj/cut/tip4p/long requires newton pair on*
+ This is because the computation of constraint forces within a water
+ molecule adds forces to atoms owned by other processors.
+
+*Pair style lj/gromacs/coul/gromacs requires atom attribute q*
+ An atom_style with this attribute is needed.
+
+*Pair style lj/long/dipole/long does not currently support respa*
+ This feature is not yet supported.
+
+*Pair style lj/long/tip4p/long requires atom IDs*
+ There are no atom IDs defined in the system and the TIP4P potential
+ requires them to find O,H atoms with a water molecule.
+
+*Pair style lj/long/tip4p/long requires atom attribute q*
+ The atom style defined does not have these attributes.
+
+*Pair style lj/long/tip4p/long requires newton pair on*
+ This is because the computation of constraint forces within a water
+ molecule adds forces to atoms owned by other processors.
+
+*Pair style nb3b/harmonic requires atom IDs*
+ This is a requirement to use this potential.
+
+*Pair style nb3b/harmonic requires newton pair on*
+ See the newton command. This is a restriction to use this potential.
+
+*Pair style nm/cut/coul/cut requires atom attribute q*
+ The atom style defined does not have this attribute.
+
+*Pair style nm/cut/coul/long requires atom attribute q*
+ The atom style defined does not have this attribute.
+
+*Pair style peri requires atom style peri*
+ Self-explanatory.
+
+*Pair style reax requires atom IDs*
+ This is a requirement to use the ReaxFF potential.
+
+*Pair style reax requires atom attribute q*
+ The atom style defined does not have this attribute.
+
+*Pair style reax requires newton pair on*
+ This is a requirement to use the ReaxFF potential.
+
+*Pair style requires a KSpace style*
+ No kspace style is defined.
+
+*Pair style requires use of kspace_style ewald/disp*
+ Self-explanatory.
+
+*Pair style sw/gpu requires atom IDs*
+ This is a requirement to use this potential.
+
+*Pair style sw/gpu requires newton pair off*
+ See the newton command. This is a restriction to use this potential.
+
+*Pair style tip4p/cut requires atom IDs*
+ This is a requirement to use this potential.
+
+*Pair style tip4p/cut requires atom attribute q*
+ The atom style defined does not have this attribute.
+
+*Pair style tip4p/cut requires newton pair on*
+ See the newton command. This is a restriction to use this potential.
+
+*Pair style tip4p/long requires atom IDs*
+ There are no atom IDs defined in the system and the TIP4P potential
+ requires them to find O,H atoms with a water molecule.
+
+*Pair style tip4p/long requires atom attribute q*
+ The atom style defined does not have these attributes.
+
+*Pair style tip4p/long requires newton pair on*
+ This is because the computation of constraint forces within a water
+ molecule adds forces to atoms owned by other processors.
+
+*Pair table cutoffs must all be equal to use with KSpace*
+ When using pair style table with a long-range KSpace solver, the
+ cutoffs for all atom type pairs must all be the same, since the
+ long-range solver starts at that cutoff.
+
+*Pair table parameters did not set N*
+ List of pair table parameters must include N setting.
+
+*Pair tersoff/zbl requires metal or real units*
+ This is a current restriction of this pair potential.
+
+*Pair tri/lj requires atom style tri*
+ Self-explanatory.
+
+*Pair yukawa/colloid requires atom style sphere*
+ Self-explantory.
+
+*Pair yukawa/colloid requires atoms with same type have same radius*
+ Self-explantory.
+
+*Pair yukawa/colloid/gpu requires atom style sphere*
+ Self-explanatory.
+
+*PairKIM only works with 3D problems*
+ This is a current limitation.
+
+*Pair_coeff command before pair_style is defined*
+ Self-explanatory.
+
+*Pair_coeff command before simulation box is defined*
+ The pair_coeff command cannot be used before a read_data,
+ read_restart, or create_box command.
+
+*Pair_modify command before pair_style is defined*
+ Self-explanatory.
+
+*Pair_write command before pair_style is defined*
+ Self-explanatory.
+
+*Particle on or inside fix wall surface*
+ Particles must be "exterior" to the wall in order for energy/force to
+ be calculated.
+
+*Particle on or inside surface of region used in fix wall/region*
+ Particles must be "exterior" to the region surface in order for
+ energy/force to be calculated.
+
+*Per-atom compute in equal-style variable formula*
+ Equal-style variables cannot use per-atom quantities.
+
+*Per-atom energy was not tallied on needed timestep*
+ You are using a thermo keyword that requires potentials to
+ have tallied energy, but they didn't on this timestep. See the
+ variable doc page for ideas on how to make this work.
+
+*Per-atom fix in equal-style variable formula*
+ Equal-style variables cannot use per-atom quantities.
+
+*Per-atom virial was not tallied on needed timestep*
+ You are using a thermo keyword that requires potentials to have
+ tallied the virial, but they didn't on this timestep. See the
+ variable doc page for ideas on how to make this work.
+
+*Per-processor system is too big*
+ The number of owned atoms plus ghost atoms on a single
+ processor must fit in 32-bit integer.
+
+*Potential energy ID for fix neb does not exist*
+ Self-explanatory.
+
+*Potential energy ID for fix nvt/nph/npt does not exist*
+ A compute for potential energy must be defined.
+
+*Potential file has duplicate entry*
+ The potential file has more than one entry for the same element.
+
+*Potential file is missing an entry*
+ The potential file does not have a needed entry.
+
+*Power by 0 in variable formula*
+ Self-explanatory.
+
+*Pressure ID for fix box/relax does not exist*
+ The compute ID needed to compute pressure for the fix does not
+ exist.
+
+*Pressure ID for fix modify does not exist*
+ Self-explanatory.
+
+*Pressure ID for fix npt/nph does not exist*
+ Self-explanatory.
+
+*Pressure ID for fix press/berendsen does not exist*
+ The compute ID needed to compute pressure for the fix does not
+ exist.
+
+*Pressure ID for fix rigid npt/nph does not exist*
+ Self-explanatory.
+
+*Pressure ID for thermo does not exist*
+ The compute ID needed to compute pressure for thermodynamics does not
+ exist.
+
+*Pressure control can not be used with fix nvt*
+ Self-explanatory.
+
+*Pressure control can not be used with fix nvt/asphere*
+ Self-explanatory.
+
+*Pressure control can not be used with fix nvt/sllod*
+ Self-explanatory.
+
+*Pressure control can not be used with fix nvt/sphere*
+ Self-explanatory.
+
+*Pressure control must be used with fix nph*
+ Self-explanatory.
+
+*Pressure control must be used with fix nph/asphere*
+ Self-explanatory.
+
+*Pressure control must be used with fix nph/small*
+ Self-explanatory.
+
+*Pressure control must be used with fix nph/sphere*
+ Self-explanatory.
+
+*Pressure control must be used with fix nphug*
+ A pressure control keyword (iso, aniso, tri, x, y, or z) must be
+ provided.
+
+*Pressure control must be used with fix npt*
+ Self-explanatory.
+
+*Pressure control must be used with fix npt/asphere*
+ Self-explanatory.
+
+*Pressure control must be used with fix npt/sphere*
+ Self-explanatory.
+
+*Processor count in z must be 1 for 2d simulation*
+ Self-explanatory.
+
+*Processor partitions do not match number of allocated processors*
+ The total number of processors in all partitions must match the number
+ of processors LAMMPS is running on.
+
+*Processors command after simulation box is defined*
+ The processors command cannot be used after a read_data, read_restart,
+ or create_box command.
+
+*Processors custom grid file is inconsistent*
+ The vales in the custom file are not consistent with the number of
+ processors you are running on or the Px,Py,Pz settings of the
+ processors command. Or there was not a setting for every processor.
+
+*Processors grid numa and map style are incompatible*
+ Using numa for gstyle in the processors command requires using
+ cart for the map option.
+
+*Processors part option and grid style are incompatible*
+ Cannot use gstyle numa or custom with the part option.
+
+*Processors twogrid requires proc count be a multiple of core count*
+ Self-explanatory.
+
+*Pstart and Pstop must have the same value*
+ Self-explanatory.
+
+*Python function evaluation failed*
+ The Python function did not run succesfully and/or did not return a
+ value (if it is supposed to return a value). This is probably due to
+ some error condition in the function.
+
+*Python function is not callable*
+ The provided Python code was run successfully, but it not
+ define a callable function with the required name.
+
+*Python invoke of undefined function*
+ Cannot invoke a function that has not been previously defined.
+
+*Python variable does not match Python function*
+ This matching is defined by the python-style variable and the python
+ command.
+
+*Python variable has no function*
+ No python command was used to define the function associated with the
+ python-style variable.
+
+*QEQ with 'newton pair off' not supported*
+ See the newton command. This is a restriction to use the QEQ fixes.
+
+*R0 < 0 for fix spring command*
+ Equilibrium spring length is invalid.
+
+*RATTLE coordinate constraints are not satisfied up to desired tolerance*
+ Self-explanatory.
+
+*RATTLE determinant = 0.0*
+ The determinant of the matrix being solved for a single cluster
+ specified by the fix rattle command is numerically invalid.
+
+*RATTLE failed*
+ Certain constraints were not satisfied.
+
+*RATTLE velocity constraints are not satisfied up to desired tolerance*
+ Self-explanatory.
+
+*Read dump of atom property that isn't allocated*
+ Self-explanatory.
+
+*Read rerun dump file timestep > specified stop*
+ Self-explanatory.
+
+*Read restart MPI-IO input not allowed with % in filename*
+ This is because a % signifies one file per processor and MPI-IO
+ creates one large file for all processors.
+
+*Read_data shrink wrap did not assign all atoms correctly*
+ This is typically because the box-size specified in the data file is
+ large compared to the actual extent of atoms in a shrink-wrapped
+ dimension. When LAMMPS shrink-wraps the box atoms will be lost if the
+ processor they are re-assigned to is too far away. Choose a box
+ size closer to the actual extent of the atoms.
+
+*Read_dump command before simulation box is defined*
+ The read_dump command cannot be used before a read_data, read_restart,
+ or create_box command.
+
+*Read_dump field not found in dump file*
+ Self-explanatory.
+
+*Read_dump triclinic status does not match simulation*
+ Both the dump snapshot and the current LAMMPS simulation must
+ be using either an orthogonal or triclinic box.
+
+*Read_dump xyz fields do not have consistent scaling/wrapping*
+ Self-explanatory.
+
+*Reading from MPI-IO filename when MPIIO package is not installed*
+ Self-explanatory.
+
+*Reax_defs.h setting for NATDEF is too small*
+ Edit the setting in the ReaxFF library and re-compile the
+ library and re-build LAMMPS.
+
+*Reax_defs.h setting for NNEIGHMAXDEF is too small*
+ Edit the setting in the ReaxFF library and re-compile the
+ library and re-build LAMMPS.
+
+*Receiving partition in processors part command is already a receiver*
+ Cannot specify a partition to be a receiver twice.
+
+*Region ID for compute chunk/atom does not exist*
+ Self-explanatory.
+
+*Region ID for compute reduce/region does not exist*
+ Self-explanatory.
+
+*Region ID for compute temp/region does not exist*
+ Self-explanatory.
+
+*Region ID for dump custom does not exist*
+ Self-explanatory.
+
+*Region ID for fix addforce does not exist*
+ Self-explanatory.
+
+*Region ID for fix atom/swap does not exist*
+ Self-explanatory.
+
+*Region ID for fix ave/spatial does not exist*
+ Self-explanatory.
+
+*Region ID for fix aveforce does not exist*
+ Self-explanatory.
+
+*Region ID for fix deposit does not exist*
+ Self-explanatory.
+
+*Region ID for fix efield does not exist*
+ Self-explanatory.
+
+*Region ID for fix evaporate does not exist*
+ Self-explanatory.
+
+*Region ID for fix gcmc does not exist*
+ Self-explanatory.
+
+*Region ID for fix heat does not exist*
+ Self-explanatory.
+
+*Region ID for fix setforce does not exist*
+ Self-explanatory.
+
+*Region ID for fix wall/region does not exist*
+ Self-explanatory.
+
+*Region ID for group dynamic does not exist*
+ Self-explanatory.
+
+*Region ID in variable formula does not exist*
+ Self-explanatory.
+
+*Region cannot have 0 length rotation vector*
+ Self-explanatory.
+
+*Region for fix oneway does not exist*
+ Self-explanatory.
+
+*Region intersect region ID does not exist*
+ Self-explanatory.
+
+*Region union or intersect cannot be dynamic*
+ The sub-regions can be dynamic, but not the combined region.
+
+*Region union region ID does not exist*
+ One or more of the region IDs specified by the region union command
+ does not exist.
+
+*Replacing a fix, but new style != old style*
+ A fix ID can be used a 2nd time, but only if the style matches the
+ previous fix. In this case it is assumed you with to reset a fix's
+ parameters. This error may mean you are mistakenly re-using a fix ID
+ when you do not intend to.
+
+*Replicate command before simulation box is defined*
+ The replicate command cannot be used before a read_data, read_restart,
+ or create_box command.
+
+*Replicate did not assign all atoms correctly*
+ Atoms replicated by the replicate command were not assigned correctly
+ to processors. This is likely due to some atom coordinates being
+ outside a non-periodic simulation box.
+
+*Replicated system atom IDs are too big*
+ See the setting for tagint in the src/lmptype.h file.
+
+*Replicated system is too big*
+ See the setting for bigint in the src/lmptype.h file.
+
+*Required border comm not yet implemented with Kokkos*
+ There are various limitations in the communication options supported
+ by Kokkos.
+
+*Rerun command before simulation box is defined*
+ The rerun command cannot be used before a read_data, read_restart, or
+ create_box command.
+
+*Rerun dump file does not contain requested snapshot*
+ Self-explanatory.
+
+*Resetting timestep size is not allowed with fix move*
+ This is because fix move is moving atoms based on elapsed time.
+
+*Respa inner cutoffs are invalid*
+ The first cutoff must be <= the second cutoff.
+
+*Respa levels must be >= 1*
+ Self-explanatory.
+
+*Respa middle cutoffs are invalid*
+ The first cutoff must be <= the second cutoff.
+
+*Restart file MPI-IO output not allowed with % in filename*
+ This is because a % signifies one file per processor and MPI-IO
+ creates one large file for all processors.
+
+*Restart file byte ordering is not recognized*
+ The file does not appear to be a LAMMPS restart file since it doesn't
+ contain a recognized byte-orderomg flag at the beginning.
+
+*Restart file byte ordering is swapped*
+ The file was written on a machine with different byte-ordering than
+ the machine you are reading it on. Convert it to a text data file
+ instead, on the machine you wrote it on.
+
+*Restart file incompatible with current version*
+ This is probably because you are trying to read a file created with a
+ version of LAMMPS that is too old compared to the current version.
+ Use your older version of LAMMPS and convert the restart file
+ to a data file.
+
+*Restart file is a MPI-IO file*
+ The file is inconsistent with the filename you specified for it.
+
+*Restart file is a multi-proc file*
+ The file is inconsistent with the filename you specified for it.
+
+*Restart file is not a MPI-IO file*
+ The file is inconsistent with the filename you specified for it.
+
+*Restart file is not a multi-proc file*
+ The file is inconsistent with the filename you specified for it.
+
+*Restart variable returned a bad timestep*
+ The variable must return a timestep greater than the current timestep.
+
+*Restrain atoms %d %d %d %d missing on proc %d at step %ld*
+ The 4 atoms in a restrain dihedral specified by the fix restrain
+ command are not all accessible to a processor. This probably means an
+ atom has moved too far.
+
+*Restrain atoms %d %d %d missing on proc %d at step %ld*
+ The 3 atoms in a restrain angle specified by the fix restrain
+ command are not all accessible to a processor. This probably means an
+ atom has moved too far.
+
+*Restrain atoms %d %d missing on proc %d at step %ld*
+ The 2 atoms in a restrain bond specified by the fix restrain
+ command are not all accessible to a processor. This probably means an
+ atom has moved too far.
+
+*Reuse of compute ID*
+ A compute ID cannot be used twice.
+
+*Reuse of dump ID*
+ A dump ID cannot be used twice.
+
+*Reuse of molecule template ID*
+ The template IDs must be unique.
+
+*Reuse of region ID*
+ A region ID cannot be used twice.
+
+*Rigid body atoms %d %d missing on proc %d at step %ld*
+ This means that an atom cannot find the atom that owns the rigid body
+ it is part of, or vice versa. The solution is to use the communicate
+ cutoff command to insure ghost atoms are acquired from far enough away
+ to encompass the max distance printed when the fix rigid/small command
+ was invoked.
+
+*Rigid body has degenerate moment of inertia*
+ Fix poems will only work with bodies (collections of atoms) that have
+ non-zero principal moments of inertia. This means they must be 3 or
+ more non-collinear atoms, even with joint atoms removed.
+
+*Rigid fix must come before NPT/NPH fix*
+ NPT/NPH fix must be defined in input script after all rigid fixes,
+ else the rigid fix contribution to the pressure virial is
+ incorrect.
+
+*Rmask function in equal-style variable formula*
+ Rmask is per-atom operation.
+
+*Run command before simulation box is defined*
+ The run command cannot be used before a read_data, read_restart, or
+ create_box command.
+
+*Run command start value is after start of run*
+ Self-explanatory.
+
+*Run command stop value is before end of run*
+ Self-explanatory.
+
+*Run_style command before simulation box is defined*
+ The run_style command cannot be used before a read_data,
+ read_restart, or create_box command.
+
+*SRD bin size for fix srd differs from user request*
+ Fix SRD had to adjust the bin size to fit the simulation box. See the
+ cubic keyword if you want this message to be an error vs warning.
+
+*SRD bins for fix srd are not cubic enough*
+ The bin shape is not within tolerance of cubic. See the cubic
+ keyword if you want this message to be an error vs warning.
+
+*SRD particle %d started inside big particle %d on step %ld bounce %d*
+ See the inside keyword if you want this message to be an error vs
+ warning.
+
+*SRD particle %d started inside wall %d on step %ld bounce %d*
+ See the inside keyword if you want this message to be an error vs
+ warning.
+
+*Same dimension twice in fix ave/spatial*
+ Self-explanatory.
+
+*Sending partition in processors part command is already a sender*
+ Cannot specify a partition to be a sender twice.
+
+*Set command before simulation box is defined*
+ The set command cannot be used before a read_data, read_restart,
+ or create_box command.
+
+*Set command floating point vector does not exist*
+ Self-explanatory.
+
+*Set command integer vector does not exist*
+ Self-explanatory.
+
+*Set command with no atoms existing*
+ No atoms are yet defined so the set command cannot be used.
+
+*Set region ID does not exist*
+ Region ID specified in set command does not exist.
+
+*Shake angles have different bond types*
+ All 3-atom angle-constrained SHAKE clusters specified by the fix shake
+ command that are the same angle type, must also have the same bond
+ types for the 2 bonds in the angle.
+
+*Shake atoms %d %d %d %d missing on proc %d at step %ld*
+ The 4 atoms in a single shake cluster specified by the fix shake
+ command are not all accessible to a processor. This probably means
+ an atom has moved too far.
+
+*Shake atoms %d %d %d missing on proc %d at step %ld*
+ The 3 atoms in a single shake cluster specified by the fix shake
+ command are not all accessible to a processor. This probably means
+ an atom has moved too far.
+
+*Shake atoms %d %d missing on proc %d at step %ld*
+ The 2 atoms in a single shake cluster specified by the fix shake
+ command are not all accessible to a processor. This probably means
+ an atom has moved too far.
+
+*Shake cluster of more than 4 atoms*
+ A single cluster specified by the fix shake command can have no more
+ than 4 atoms.
+
+*Shake clusters are connected*
+ A single cluster specified by the fix shake command must have a single
+ central atom with up to 3 other atoms bonded to it.
+
+*Shake determinant = 0.0*
+ The determinant of the matrix being solved for a single cluster
+ specified by the fix shake command is numerically invalid.
+
+*Shake fix must come before NPT/NPH fix*
+ NPT fix must be defined in input script after SHAKE fix, else the
+ SHAKE fix contribution to the pressure virial is incorrect.
+
+*Shear history overflow, boost neigh_modify one*
+ There are too many neighbors of a single atom. Use the neigh_modify
+ command to increase the max number of neighbors allowed for one atom.
+ You may also want to boost the page size.
+
+*Small to big integers are not sized correctly*
+ This error occurs whenthe sizes of smallint, imageint, tagint, bigint,
+ as defined in src/lmptype.h are not what is expected. Contact
+ the developers if this occurs.
+
+*Smallint setting in lmptype.h is invalid*
+ It has to be the size of an integer.
+
+*Smallint setting in lmptype.h is not compatible*
+ Smallint stored in restart file is not consistent with LAMMPS version
+ you are running.
+
+*Special list size exceeded in fix bond/create*
+ See the read_data command for info on setting the "extra special per
+ atom" header value to allow for additional special values to be
+ stored.
+
+*Specified processors != physical processors*
+ The 3d grid of processors defined by the processors command does not
+ match the number of processors LAMMPS is being run on.
+
+*Specified target stress must be uniaxial or hydrostatic*
+ Self-explanatory.
+
+*Sqrt of negative value in variable formula*
+ Self-explanatory.
+
+*Substitution for illegal variable*
+ Input script line contained a variable that could not be substituted
+ for.
+
+*Support for writing images in JPEG format not included*
+ LAMMPS was not built with the -DLAMMPS_JPEG switch in the Makefile.
+
+*Support for writing images in PNG format not included*
+ LAMMPS was not built with the -DLAMMPS_PNG switch in the Makefile.
+
+*Support for writing movies not included*
+ LAMMPS was not built with the -DLAMMPS_FFMPEG switch in the Makefile
+
+*System in data file is too big*
+ See the setting for bigint in the src/lmptype.h file.
+
+*System is not charge neutral, net charge = %g*
+ The total charge on all atoms on the system is not 0.0, which
+ is not valid for the long-range Coulombic solvers.
+
+*TAD nsteps must be multiple of t_event*
+ Self-explanatory.
+
+*TIP4P hydrogen has incorrect atom type*
+ The TIP4P pairwise computation found an H atom whose type does not
+ agree with the specified H type.
+
+*TIP4P hydrogen is missing*
+ The TIP4P pairwise computation failed to find the correct H atom
+ within a water molecule.
+
+*TMD target file did not list all group atoms*
+ The target file for the fix tmd command did not list all atoms in the
+ fix group.
+
+*Tad command before simulation box is defined*
+ Self-explanatory.
+
+*Tagint setting in lmptype.h is invalid*
+ Tagint must be as large or larger than smallint.
+
+*Tagint setting in lmptype.h is not compatible*
+ Format of tagint stored in restart file is not consistent with LAMMPS
+ version you are running. See the settings in src/lmptype.h
+
+*Target pressure for fix rigid/nph cannot be < 0.0*
+ Self-explanatory.
+
+*Target pressure for fix rigid/npt/small cannot be < 0.0*
+ Self-explanatory.
+
+*Target temperature for fix nvt/npt/nph cannot be 0.0*
+ Self-explanatory.
+
+*Target temperature for fix rigid/npt cannot be 0.0*
+ Self-explanatory.
+
+*Target temperature for fix rigid/npt/small cannot be 0.0*
+ Self-explanatory.
+
+*Target temperature for fix rigid/nvt cannot be 0.0*
+ Self-explanatory.
+
+*Target temperature for fix rigid/nvt/small cannot be 0.0*
+ Self-explanatory.
+
+*Temper command before simulation box is defined*
+ The temper command cannot be used before a read_data, read_restart, or
+ create_box command.
+
+*Temperature ID for fix bond/swap does not exist*
+ Self-explanatory.
+
+*Temperature ID for fix box/relax does not exist*
+ Self-explanatory.
+
+*Temperature ID for fix nvt/npt does not exist*
+ Self-explanatory.
+
+*Temperature ID for fix press/berendsen does not exist*
+ Self-explanatory.
+
+*Temperature ID for fix rigid nvt/npt/nph does not exist*
+ Self-explanatory.
+
+*Temperature ID for fix temp/berendsen does not exist*
+ Self-explanatory.
+
+*Temperature ID for fix temp/csvr does not exist*
+ Self-explanatory.
+
+*Temperature ID for fix temp/rescale does not exist*
+ Self-explanatory.
+
+*Temperature control can not be used with fix nph*
+ Self-explanatory.
+
+*Temperature control can not be used with fix nph/asphere*
+ Self-explanatory.
+
+*Temperature control can not be used with fix nph/sphere*
+ Self-explanatory.
+
+*Temperature control must be used with fix nphug*
+ The temp keyword must be provided.
+
+*Temperature control must be used with fix npt*
+ Self-explanatory.
+
+*Temperature control must be used with fix npt/asphere*
+ Self-explanatory.
+
+*Temperature control must be used with fix npt/sphere*
+ Self-explanatory.
+
+*Temperature control must be used with fix nvt*
+ Self-explanatory.
+
+*Temperature control must be used with fix nvt/asphere*
+ Self-explanatory.
+
+*Temperature control must be used with fix nvt/sllod*
+ Self-explanatory.
+
+*Temperature control must be used with fix nvt/sphere*
+ Self-explanatory.
+
+*Temperature control must not be used with fix nph/small*
+ Self-explanatory.
+
+*Temperature for fix nvt/sllod does not have a bias*
+ The specified compute must compute temperature with a bias.
+
+*Tempering could not find thermo_pe compute*
+ This compute is created by the thermo command. It must have been
+ explicitly deleted by a uncompute command.
+
+*Tempering fix ID is not defined*
+ The fix ID specified by the temper command does not exist.
+
+*Tempering temperature fix is not valid*
+ The fix specified by the temper command is not one that controls
+ temperature (nvt or langevin).
+
+*Test_descriptor_string already allocated*
+ This is an internal error. Contact the developers.
+
+*The package gpu command is required for gpu styles*
+ Self-explanatory.
+
+*Thermo and fix not computed at compatible times*
+ Fixes generate values on specific timesteps. The thermo output
+ does not match these timesteps.
+
+*Thermo compute array is accessed out-of-range*
+ Self-explanatory.
+
+*Thermo compute does not compute array*
+ Self-explanatory.
+
+*Thermo compute does not compute scalar*
+ Self-explanatory.
+
+*Thermo compute does not compute vector*
+ Self-explanatory.
+
+*Thermo compute vector is accessed out-of-range*
+ Self-explanatory.
+
+*Thermo custom variable cannot be indexed*
+ Self-explanatory.
+
+*Thermo custom variable is not equal-style variable*
+ Only equal-style variables can be output with thermodynamics, not
+ atom-style variables.
+
+*Thermo every variable returned a bad timestep*
+ The variable must return a timestep greater than the current timestep.
+
+*Thermo fix array is accessed out-of-range*
+ Self-explanatory.
+
+*Thermo fix does not compute array*
+ Self-explanatory.
+
+*Thermo fix does not compute scalar*
+ Self-explanatory.
+
+*Thermo fix does not compute vector*
+ Self-explanatory.
+
+*Thermo fix vector is accessed out-of-range*
+ Self-explanatory.
+
+*Thermo keyword in variable requires thermo to use/init pe*
+ You are using a thermo keyword in a variable that requires
+ potential energy to be calculated, but your thermo output
+ does not use it. Add it to your thermo output.
+
+*Thermo keyword in variable requires thermo to use/init press*
+ You are using a thermo keyword in a variable that requires pressure to
+ be calculated, but your thermo output does not use it. Add it to your
+ thermo output.
+
+*Thermo keyword in variable requires thermo to use/init temp*
+ You are using a thermo keyword in a variable that requires temperature
+ to be calculated, but your thermo output does not use it. Add it to
+ your thermo output.
+
+*Thermo style does not use press*
+ Cannot use thermo_modify to set this parameter since the thermo_style
+ is not computing this quantity.
+
+*Thermo style does not use temp*
+ Cannot use thermo_modify to set this parameter since the thermo_style
+ is not computing this quantity.
+
+*Thermo_modify every variable returned a bad timestep*
+ The returned timestep is less than or equal to the current timestep.
+
+*Thermo_modify int format does not contain d character*
+ Self-explanatory.
+
+*Thermo_modify pressure ID does not compute pressure*
+ The specified compute ID does not compute pressure.
+
+*Thermo_modify temperature ID does not compute temperature*
+ The specified compute ID does not compute temperature.
+
+*Thermo_style command before simulation box is defined*
+ The thermo_style command cannot be used before a read_data,
+ read_restart, or create_box command.
+
+*This variable thermo keyword cannot be used between runs*
+ Keywords that refer to time (such as cpu, elapsed) do not
+ make sense in between runs.
+
+*Threshhold for an atom property that isn't allocated*
+ A dump threshhold has been requested on a quantity that is
+ not defined by the atom style used in this simulation.
+
+*Timestep must be >= 0*
+ Specified timestep is invalid.
+
+*Too big a problem to use velocity create loop all*
+ The system size must fit in a 32-bit integer to use this option.
+
+*Too big a timestep*
+ Specified timestep is too large.
+
+*Too big a timestep for dump dcd*
+ The timestep must fit in a 32-bit integer to use this dump style.
+
+*Too big a timestep for dump xtc*
+ The timestep must fit in a 32-bit integer to use this dump style.
+
+*Too few bits for lookup table*
+ Table size specified via pair_modify command does not work with your
+ machine's floating point representation.
+
+*Too many -pk arguments in command line*
+ The string formed by concatenating the arguments is too long. Use a
+ package command in the input script instead.
+
+*Too many MSM grid levels*
+ The max number of MSM grid levels is hardwired to 10.
+
+*Too many args in variable function*
+ More args are used than any variable function allows.
+
+*Too many atom pairs for pair bop*
+ The number of atomic pairs exceeds the expected number. Check your
+ atomic structure to ensure that it is realistic.
+
+*Too many atom sorting bins*
+ This is likely due to an immense simulation box that has blown up
+ to a large size.
+
+*Too many atom triplets for pair bop*
+ The number of three atom groups for angle determinations exceeds the
+ expected number. Check your atomic structrure to ensure that it is
+ realistic.
+
+*Too many atoms for dump dcd*
+ The system size must fit in a 32-bit integer to use this dump
+ style.
+
+*Too many atoms for dump xtc*
+ The system size must fit in a 32-bit integer to use this dump
+ style.
+
+*Too many atoms to dump sort*
+ Cannot sort when running with more than 2^31 atoms.
+
+*Too many exponent bits for lookup table*
+ Table size specified via pair_modify command does not work with your
+ machine's floating point representation.
+
+*Too many groups*
+ The maximum number of atom groups (including the "all" group) is
+ given by MAX_GROUP in group.cpp and is 32.
+
+*Too many iterations*
+ You must use a number of iterations that fit in a 32-bit integer
+ for minimization.
+
+*Too many lines in one body in data file - boost MAXBODY*
+ MAXBODY is a setting at the top of the src/read_data.cpp file.
+ Set it larger and re-compile the code.
+
+*Too many local+ghost atoms for neighbor list*
+ The number of nlocal + nghost atoms on a processor
+ is limited by the size of a 32-bit integer with 2 bits
+ removed for masking 1-2, 1-3, 1-4 neighbors.
+
+*Too many mantissa bits for lookup table*
+ Table size specified via pair_modify command does not work with your
+ machine's floating point representation.
+
+*Too many masses for fix shake*
+ The fix shake command cannot list more masses than there are atom
+ types.
+
+*Too many molecules for fix poems*
+ The limit is 2^31 = ~2 billion molecules.
+
+*Too many molecules for fix rigid*
+ The limit is 2^31 = ~2 billion molecules.
+
+*Too many neighbor bins*
+ This is likely due to an immense simulation box that has blown up
+ to a large size.
+
+*Too many timesteps*
+ The cummulative timesteps must fit in a 64-bit integer.
+
+*Too many timesteps for NEB*
+ You must use a number of timesteps that fit in a 32-bit integer
+ for NEB.
+
+*Too many total atoms*
+ See the setting for bigint in the src/lmptype.h file.
+
+*Too many total bits for bitmapped lookup table*
+ Table size specified via pair_modify command is too large. Note that
+ a value of N generates a 2^N size table.
+
+*Too much buffered per-proc info for dump*
+ The size of the buffered string must fit in a 32-bit integer for a
+ dump.
+
+*Too much per-proc info for dump*
+ Number of local atoms times number of columns must fit in a 32-bit
+ integer for dump.
+
+*Tree structure in joint connections*
+ Fix poems cannot (yet) work with coupled bodies whose joints connect
+ the bodies in a tree structure.
+
+*Triclinic box skew is too large*
+ The displacement in a skewed direction must be less than half the box
+ length in that dimension. E.g. the xy tilt must be between -half and
+ +half of the x box length. This constraint can be relaxed by using
+ the box tilt command.
+
+*Tried to convert a double to int, but input_double > INT_MAX*
+ Self-explanatory.
+
+*Trying to build an occasional neighbor list before initialization completed*
+ This is not allowed. Source code caller needs to be modified.
+
+*Two fix ave commands using same compute chunk/atom command in incompatible ways*
+ They are both attempting to "lock" the chunk/atom command so that the
+ chunk assignments persist for some number of timesteps, but are doing
+ it in different ways.
+
+*Two groups cannot be the same in fix spring couple*
+ Self-explanatory.
+
+*USER-CUDA mode requires CUDA variant of min style*
+ CUDA mode is enabled, so the min style must include a cuda suffix.
+
+*USER-CUDA mode requires CUDA variant of run style*
+ CUDA mode is enabled, so the run style must include a cuda suffix.
+
+*USER-CUDA package does not yet support comm_style tiled*
+ Self-explanatory.
+
+*USER-CUDA package requires a cuda enabled atom_style*
+ Self-explanatory.
+
+*Unable to initialize accelerator for use*
+ There was a problem initializing an accelerator for the gpu package
+
+*Unbalanced quotes in input line*
+ No matching end double quote was found following a leading double
+ quote.
+
+*Unexpected end of -reorder file*
+ Self-explanatory.
+
+*Unexpected end of AngleCoeffs section*
+ Read a blank line.
+
+*Unexpected end of BondCoeffs section*
+ Read a blank line.
+
+*Unexpected end of DihedralCoeffs section*
+ Read a blank line.
+
+*Unexpected end of ImproperCoeffs section*
+ Read a blank line.
+
+*Unexpected end of PairCoeffs section*
+ Read a blank line.
+
+*Unexpected end of custom file*
+ Self-explanatory.
+
+*Unexpected end of data file*
+ LAMMPS hit the end of the data file while attempting to read a
+ section. Something is wrong with the format of the data file.
+
+*Unexpected end of dump file*
+ A read operation from the file failed.
+
+*Unexpected end of fix rigid file*
+ A read operation from the file failed.
+
+*Unexpected end of fix rigid/small file*
+ A read operation from the file failed.
+
+*Unexpected end of molecule file*
+ Self-explanatory.
+
+*Unexpected end of neb file*
+ A read operation from the file failed.
+
+*Units command after simulation box is defined*
+ The units command cannot be used after a read_data, read_restart, or
+ create_box command.
+
+*Universe/uloop variable count < # of partitions*
+ A universe or uloop style variable must specify a number of values >= to the
+ number of processor partitions.
+
+*Unknown angle style*
+ The choice of angle style is unknown.
+
+*Unknown atom style*
+ The choice of atom style is unknown.
+
+*Unknown body style*
+ The choice of body style is unknown.
+
+*Unknown bond style*
+ The choice of bond style is unknown.
+
+*Unknown command: %s*
+ The command is not known to LAMMPS. Check the input script.
+
+*Unknown compute style*
+ The choice of compute style is unknown.
+
+*Unknown dihedral style*
+ The choice of dihedral style is unknown.
+
+*Unknown dump reader style*
+ The choice of dump reader style via the format keyword is unknown.
+
+*Unknown dump style*
+ The choice of dump style is unknown.
+
+*Unknown error in GPU library*
+ Self-explanatory.
+
+*Unknown fix style*
+ The choice of fix style is unknown.
+
+*Unknown identifier in data file: %s*
+ A section of the data file cannot be read by LAMMPS.
+
+*Unknown improper style*
+ The choice of improper style is unknown.
+
+*Unknown keyword in thermo_style custom command*
+ One or more specified keywords are not recognized.
+
+*Unknown kspace style*
+ The choice of kspace style is unknown.
+
+*Unknown pair style*
+ The choice of pair style is unknown.
+
+*Unknown pair_modify hybrid sub-style*
+ The choice of sub-style is unknown.
+
+*Unknown region style*
+ The choice of region style is unknown.
+
+*Unknown section in molecule file*
+ Self-explanatory.
+
+*Unknown table style in angle style table*
+ Self-explanatory.
+
+*Unknown table style in bond style table*
+ Self-explanatory.
+
+*Unknown table style in pair_style command*
+ Style of table is invalid for use with pair_style table command.
+
+*Unknown unit_style*
+ Self-explanatory. Check the input script or data file.
+
+*Unrecognized lattice type in MEAM file 1*
+ The lattice type in an entry of the MEAM library file is not
+ valid.
+
+*Unrecognized lattice type in MEAM file 2*
+ The lattice type in an entry of the MEAM parameter file is not
+ valid.
+
+*Unrecognized pair style in compute pair command*
+ Self-explanatory.
+
+*Unrecognized virial argument in pair_style command*
+ Only two options are supported: LAMMPSvirial and KIMvirial
+
+*Unsupported mixing rule in kspace_style ewald/disp*
+ Only geometric mixing is supported.
+
+*Unsupported order in kspace_style ewald/disp*
+ Only 1/r^6 dispersion or dipole terms are supported.
+
+*Unsupported order in kspace_style pppm/disp, pair_style %s*
+ Only pair styles with 1/r and 1/r^6 dependence are currently supported.
+
+*Using fix nvt/sllod with inconsistent fix deform remap option*
+ Fix nvt/sllod requires that deforming atoms have a velocity profile
+ provided by "remap v" as a fix deform option.
+
+*Using fix nvt/sllod with no fix deform defined*
+ Self-explanatory.
+
+*Using fix srd with inconsistent fix deform remap option*
+ When shearing the box in an SRD simulation, the remap v option for fix
+ deform needs to be used.
+
+*Using pair lubricate with inconsistent fix deform remap option*
+ Must use remap v option with fix deform with this pair style.
+
+*Using pair lubricate/poly with inconsistent fix deform remap option*
+ If fix deform is used, the remap v option is required.
+
+*Using suffix cuda without USER-CUDA package enabled*
+ Self-explanatory.
+
+*Using suffix gpu without GPU package installed*
+ Self-explanatory.
+
+*Using suffix intel without USER-INTEL package installed*
+ Self-explanatory.
+
+*Using suffix kk without KOKKOS package enabled*
+ Self-explanatory.
+
+*Using suffix omp without USER-OMP package installed*
+ Self-explanatory.
+
+*Variable ID in variable formula does not exist*
+ Self-explanatory.
+
+*Variable atom ID is too large*
+ Specified ID is larger than the maximum allowed atom ID.
+
+*Variable evaluation before simulation box is defined*
+ Cannot evaluate a compute or fix or atom-based value in a variable
+ before the simulation has been setup.
+
+*Variable evaluation in fix wall gave bad value*
+ The returned value for epsilon or sigma < 0.0.
+
+*Variable evaluation in region gave bad value*
+ Variable returned a radius < 0.0.
+
+*Variable for compute ti is invalid style*
+ Self-explanatory.
+
+*Variable for create_atoms is invalid style*
+ The variables must be equal-style variables.
+
+*Variable for dump every is invalid style*
+ Only equal-style variables can be used.
+
+*Variable for dump image center is invalid style*
+ Must be an equal-style variable.
+
+*Variable for dump image persp is invalid style*
+ Must be an equal-style variable.
+
+*Variable for dump image phi is invalid style*
+ Must be an equal-style variable.
+
+*Variable for dump image theta is invalid style*
+ Must be an equal-style variable.
+
+*Variable for dump image zoom is invalid style*
+ Must be an equal-style variable.
+
+*Variable for fix adapt is invalid style*
+ Only equal-style variables can be used.
+
+*Variable for fix addforce is invalid style*
+ Self-explanatory.
+
+*Variable for fix aveforce is invalid style*
+ Only equal-style variables can be used.
+
+*Variable for fix deform is invalid style*
+ The variable must be an equal-style variable.
+
+*Variable for fix efield is invalid style*
+ The variable must be an equal- or atom-style variable.
+
+*Variable for fix gravity is invalid style*
+ Only equal-style variables can be used.
+
+*Variable for fix heat is invalid style*
+ Only equal-style or atom-style variables can be used.
+
+*Variable for fix indent is invalid style*
+ Only equal-style variables can be used.
+
+*Variable for fix indent is not equal style*
+ Only equal-style variables can be used.
+
+*Variable for fix langevin is invalid style*
+ It must be an equal-style variable.
+
+*Variable for fix move is invalid style*
+ Only equal-style variables can be used.
+
+*Variable for fix setforce is invalid style*
+ Only equal-style variables can be used.
+
+*Variable for fix temp/berendsen is invalid style*
+ Only equal-style variables can be used.
+
+*Variable for fix temp/csvr is invalid style*
+ Only equal-style variables can be used.
+
+*Variable for fix temp/rescale is invalid style*
+ Only equal-style variables can be used.
+
+*Variable for fix wall is invalid style*
+ Only equal-style variables can be used.
+
+*Variable for fix wall/reflect is invalid style*
+ Only equal-style variables can be used.
+
+*Variable for fix wall/srd is invalid style*
+ Only equal-style variables can be used.
+
+*Variable for group dynamic is invalid style*
+ The variable must be an atom-style variable.
+
+*Variable for group is invalid style*
+ Only atom-style variables can be used.
+
+*Variable for region cylinder is invalid style*
+ Only equal-style varaibles are allowed.
+
+*Variable for region is invalid style*
+ Only equal-style variables can be used.
+
+*Variable for region is not equal style*
+ Self-explanatory.
+
+*Variable for region sphere is invalid style*
+ Only equal-style varaibles are allowed.
+
+*Variable for restart is invalid style*
+ Only equal-style variables can be used.
+
+*Variable for set command is invalid style*
+ Only atom-style variables can be used.
+
+*Variable for thermo every is invalid style*
+ Only equal-style variables can be used.
+
+*Variable for velocity set is invalid style*
+ Only atom-style variables can be used.
+
+*Variable for voronoi radius is not atom style*
+ Self-explanatory.
+
+*Variable formula compute array is accessed out-of-range*
+ Self-explanatory.
+
+*Variable formula compute vector is accessed out-of-range*
+ Self-explanatory.
+
+*Variable formula fix array is accessed out-of-range*
+ Self-explanatory.
+
+*Variable formula fix vector is accessed out-of-range*
+ Self-explanatory.
+
+*Variable has circular dependency*
+ A circular dependency is when variable "a" in used by variable "b" and
+ variable "b" is also used by varaible "a". Circular dependencies with
+ longer chains of dependence are also not allowed.
+
+*Variable name between brackets must be alphanumeric or underscore characters*
+ Self-explanatory.
+
+*Variable name for compute chunk/atom does not exist*
+ Self-explanatory.
+
+*Variable name for compute reduce does not exist*
+ Self-explanatory.
+
+*Variable name for compute ti does not exist*
+ Self-explanatory.
+
+*Variable name for create_atoms does not exist*
+ Self-explanatory.
+
+*Variable name for dump every does not exist*
+ Self-explanatory.
+
+*Variable name for dump image center does not exist*
+ Self-explanatory.
+
+*Variable name for dump image persp does not exist*
+ Self-explanatory.
+
+*Variable name for dump image phi does not exist*
+ Self-explanatory.
+
+*Variable name for dump image theta does not exist*
+ Self-explanatory.
+
+*Variable name for dump image zoom does not exist*
+ Self-explanatory.
+
+*Variable name for fix adapt does not exist*
+ Self-explanatory.
+
+*Variable name for fix addforce does not exist*
+ Self-explanatory.
+
+*Variable name for fix ave/atom does not exist*
+ Self-explanatory.
+
+*Variable name for fix ave/chunk does not exist*
+ Self-explanatory.
+
+*Variable name for fix ave/correlate does not exist*
+ Self-explanatory.
+
+*Variable name for fix ave/histo does not exist*
+ Self-explanatory.
+
+*Variable name for fix ave/spatial does not exist*
+ Self-explanatory.
+
+*Variable name for fix ave/time does not exist*
+ Self-explanatory.
+
+*Variable name for fix aveforce does not exist*
+ Self-explanatory.
+
+*Variable name for fix deform does not exist*
+ Self-explantory.
+
+*Variable name for fix efield does not exist*
+ Self-explanatory.
+
+*Variable name for fix gravity does not exist*
+ Self-explanatory.
+
+*Variable name for fix heat does not exist*
+ Self-explanatory.
+
+*Variable name for fix indent does not exist*
+ Self-explanatory.
+
+*Variable name for fix langevin does not exist*
+ Self-explanatory.
+
+*Variable name for fix move does not exist*
+ Self-explanatory.
+
+*Variable name for fix setforce does not exist*
+ Self-explanatory.
+
+*Variable name for fix store/state does not exist*
+ Self-explanatory.
+
+*Variable name for fix temp/berendsen does not exist*
+ Self-explanatory.
+
+*Variable name for fix temp/csvr does not exist*
+ Self-explanatory.
+
+*Variable name for fix temp/rescale does not exist*
+ Self-explanatory.
+
+*Variable name for fix vector does not exist*
+ Self-explanatory.
+
+*Variable name for fix wall does not exist*
+ Self-explanatory.
+
+*Variable name for fix wall/reflect does not exist*
+ Self-explanatory.
+
+*Variable name for fix wall/srd does not exist*
+ Self-explanatory.
+
+*Variable name for group does not exist*
+ Self-explanatory.
+
+*Variable name for group dynamic does not exist*
+ Self-explanatory.
+
+*Variable name for region cylinder does not exist*
+ Self-explanatory.
+
+*Variable name for region does not exist*
+ Self-explanatory.
+
+*Variable name for region sphere does not exist*
+ Self-explanatory.
+
+*Variable name for restart does not exist*
+ Self-explanatory.
+
+*Variable name for set command does not exist*
+ Self-explanatory.
+
+*Variable name for thermo every does not exist*
+ Self-explanatory.
+
+*Variable name for velocity set does not exist*
+ Self-explanatory.
+
+*Variable name for voronoi radius does not exist*
+ Self-explanatory.
+
+*Variable name must be alphanumeric or underscore characters*
+ Self-explanatory.
+
+*Variable uses atom property that isn't allocated*
+ Self-explanatory.
+
+*Velocity command before simulation box is defined*
+ The velocity command cannot be used before a read_data, read_restart,
+ or create_box command.
+
+*Velocity command with no atoms existing*
+ A velocity command has been used, but no atoms yet exist.
+
+*Velocity ramp in z for a 2d problem*
+ Self-explanatory.
+
+*Velocity rigid used with non-rigid fix-ID*
+ Self-explanatory.
+
+*Velocity temperature ID does calculate a velocity bias*
+ The specified compute must compute a bias for temperature.
+
+*Velocity temperature ID does not compute temperature*
+ The compute ID given to the velocity command must compute
+ temperature.
+
+*Verlet/split can only currently be used with comm_style brick*
+ This is a current restriction in LAMMPS.
+
+*Verlet/split does not yet support TIP4P*
+ This is a current limitation.
+
+*Verlet/split requires 2 partitions*
+ See the -partition command-line switch.
+
+*Verlet/split requires Rspace partition layout be multiple of Kspace partition layout in each dim*
+ This is controlled by the processors command.
+
+*Verlet/split requires Rspace partition size be multiple of Kspace partition size*
+ This is so there is an equal number of Rspace processors for every
+ Kspace processor.
+
+*Virial was not tallied on needed timestep*
+ You are using a thermo keyword that requires potentials to
+ have tallied the virial, but they didn't on this timestep. See the
+ variable doc page for ideas on how to make this work.
+
+*Voro++ error: narea and neigh have a different size*
+ This error is returned by the Voro++ library.
+
+*Wall defined twice in fix wall command*
+ Self-explanatory.
+
+*Wall defined twice in fix wall/reflect command*
+ Self-explanatory.
+
+*Wall defined twice in fix wall/srd command*
+ Self-explanatory.
+
+*Water H epsilon must be 0.0 for pair style lj/cut/tip4p/cut*
+ This is because LAMMPS does not compute the Lennard-Jones interactions
+ with these particles for efficiency reasons.
+
+*Water H epsilon must be 0.0 for pair style lj/cut/tip4p/long*
+ This is because LAMMPS does not compute the Lennard-Jones interactions
+ with these particles for efficiency reasons.
+
+*Water H epsilon must be 0.0 for pair style lj/long/tip4p/long*
+ This is because LAMMPS does not compute the Lennard-Jones interactions
+ with these particles for efficiency reasons.
+
+*World variable count doesn't match # of partitions*
+ A world-style variable must specify a number of values equal to the
+ number of processor partitions.
+
+*Write_data command before simulation box is defined*
+ Self-explanatory.
+
+*Write_restart command before simulation box is defined*
+ The write_restart command cannot be used before a read_data,
+ read_restart, or create_box command.
+
+*Writing to MPI-IO filename when MPIIO package is not installed*
+ Self-explanatory.
+
+*Zero length rotation vector with displace_atoms*
+ Self-explanatory.
+
+*Zero length rotation vector with fix move*
+ Self-explanatory.
+
+*Zero-length lattice orient vector*
+ Self-explanatory.
+
+
+
+.. _warn:
+
+Warnings:
+--------------------
+
+
+
+*Adjusting Coulombic cutoff for MSM, new cutoff = %g*
+ The adjust/cutoff command is turned on and the Coulombic cutoff has been
+ adjusted to match the user-specified accuracy.
+
+*Angle atoms missing at step %ld*
+ One or more of 3 atoms needed to compute a particular angle are
+ missing on this processor. Typically this is because the pairwise
+ cutoff is set too short or the angle has blown apart and an atom is
+ too far away.
+
+*Angle style in data file differs from currently defined angle style*
+ Self-explanatory.
+
+*Atom style in data file differs from currently defined atom style*
+ Self-explanatory.
+
+*Bond atom missing in box size check*
+ The 2nd atoms needed to compute a particular bond is missing on this
+ processor. Typically this is because the pairwise cutoff is set too
+ short or the bond has blown apart and an atom is too far away.
+
+*Bond atom missing in image check*
+ The 2nd atom in a particular bond is missing on this processor.
+ Typically this is because the pairwise cutoff is set too short or the
+ bond has blown apart and an atom is too far away.
+
+*Bond atoms missing at step %ld*
+ The 2nd atom needed to compute a particular bond is missing on this
+ processor. Typically this is because the pairwise cutoff is set too
+ short or the bond has blown apart and an atom is too far away.
+
+*Bond style in data file differs from currently defined bond style*
+ Self-explanatory.
+
+*Bond/angle/dihedral extent > half of periodic box length*
+ This is a restriction because LAMMPS can be confused about which image
+ of an atom in the bonded interaction is the correct one to use.
+ "Extent" in this context means the maximum end-to-end length of the
+ bond/angle/dihedral. LAMMPS computes this by taking the maximum bond
+ length, multiplying by the number of bonds in the interaction (e.g. 3
+ for a dihedral) and adding a small amount of stretch.
+
+*Both groups in compute group/group have a net charge; the Kspace boundary correction to energy will be non-zero*
+ Self-explantory.
+
+*Cannot count rigid body degrees-of-freedom before bodies are fully initialized*
+ This means the temperature associated with the rigid bodies may be
+ incorrect on this timestep.
+
+*Cannot count rigid body degrees-of-freedom before bodies are initialized*
+ This means the temperature associated with the rigid bodies may be
+ incorrect on this timestep.
+
+*Cannot include log terms without 1/r terms; setting flagHI to 1*
+ Self-explanatory.
+
+*Cannot include log terms without 1/r terms; setting flagHI to 1.*
+ Self-explanatory.
+
+*Charges are set, but coulombic solver is not used*
+ Self-explanatory.
+
+*Charges did not converge at step %ld: %lg*
+ Self-explanatory.
+
+*Communication cutoff is too small for SNAP micro load balancing, increased to %lf*
+ Self-explanatory.
+
+*Compute cna/atom cutoff may be too large to find ghost atom neighbors*
+ The neighbor cutoff used may not encompass enough ghost atoms
+ to perform this operation correctly.
+
+*Computing temperature of portions of rigid bodies*
+ The group defined by the temperature compute does not encompass all
+ the atoms in one or more rigid bodies, so the change in
+ degrees-of-freedom for the atoms in those partial rigid bodies will
+ not be accounted for.
+
+*Create_bonds max distance > minimum neighbor cutoff*
+ This means atom pairs for some atom types may not be in the neighbor
+ list and thus no bond can be created between them.
+
+*Delete_atoms cutoff > minimum neighbor cutoff*
+ This means atom pairs for some atom types may not be in the neighbor
+ list and thus an atom in that pair cannot be deleted.
+
+*Dihedral atoms missing at step %ld*
+ One or more of 4 atoms needed to compute a particular dihedral are
+ missing on this processor. Typically this is because the pairwise
+ cutoff is set too short or the dihedral has blown apart and an atom is
+ too far away.
+
+*Dihedral problem*
+ Conformation of the 4 listed dihedral atoms is extreme; you may want
+ to check your simulation geometry.
+
+*Dihedral problem: %d %ld %d %d %d %d*
+ Conformation of the 4 listed dihedral atoms is extreme; you may want
+ to check your simulation geometry.
+
+*Dihedral style in data file differs from currently defined dihedral style*
+ Self-explanatory.
+
+*Dump dcd/xtc timestamp may be wrong with fix dt/reset*
+ If the fix changes the timestep, the dump dcd file will not
+ reflect the change.
+
+*Estimated error in splitting of dispersion coeffs is %g*
+ Error is greater than 0.0001 percent.
+
+*Ewald/disp Newton solver failed, using old method to estimate g_ewald*
+ Self-explanatory. Choosing a different cutoff value may help.
+
+*FENE bond too long*
+ A FENE bond has stretched dangerously far. It's interaction strength
+ will be truncated to attempt to prevent the bond from blowing up.
+
+*FENE bond too long: %ld %d %d %g*
+ A FENE bond has stretched dangerously far. It's interaction strength
+ will be truncated to attempt to prevent the bond from blowing up.
+
+*FENE bond too long: %ld %g*
+ A FENE bond has stretched dangerously far. It's interaction strength
+ will be truncated to attempt to prevent the bond from blowing up.
+
+*Fix SRD walls overlap but fix srd overlap not set*
+ You likely want to set this in your input script.
+
+*Fix bond/swap will ignore defined angles*
+ See the doc page for fix bond/swap for more info on this
+ restriction.
+
+*Fix evaporate may delete atom with non-zero molecule ID*
+ This is probably an error, since you should not delete only one atom
+ of a molecule.
+
+*Fix gcmc using full_energy option*
+ Fix gcmc has automatically turned on the full_energy option since it
+ is required for systems like the one specified by the user. User input
+ included one or more of the following: kspace, triclinic, a hybrid
+ pair style, an eam pair style, or no "single" function for the pair
+ style.
+
+*Fix move does not update angular momentum*
+ Atoms store this quantity, but fix move does not (yet) update it.
+
+*Fix move does not update quaternions*
+ Atoms store this quantity, but fix move does not (yet) update it.
+
+*Fix qeq CG convergence failed (%g) after %d iterations at %ld step*
+ Self-explanatory.
+
+*Fix qeq has non-zero lower Taper radius cutoff*
+ Absolute value must be <= 0.01.
+
+*Fix qeq has very low Taper radius cutoff*
+ Value should typically be >= 5.0.
+
+*Fix qeq/dynamic tolerance may be too small for damped dynamics*
+ Self-explanatory.
+
+*Fix rattle should come after all other integration fixes*
+ This fix is designed to work after all other integration fixes change
+ atom positions. Thus it should be the last integration fix specified.
+ If not, it will not satisfy the desired constraints as well as it
+ otherwise would.
+
+*Fix recenter should come after all other integration fixes*
+ Other fixes may change the position of the center-of-mass, so
+ fix recenter should come last.
+
+*Fix srd SRD moves may trigger frequent reneighboring*
+ This is because the SRD particles may move long distances.
+
+*Fix srd grid size > 1/4 of big particle diameter*
+ This may cause accuracy problems.
+
+*Fix srd particle moved outside valid domain*
+ This may indicate a problem with your simulation parameters.
+
+*Fix srd particles may move > big particle diameter*
+ This may cause accuracy problems.
+
+*Fix srd viscosity < 0.0 due to low SRD density*
+ This may cause accuracy problems.
+
+*Fix thermal/conductivity comes before fix ave/spatial*
+ The order of these 2 fixes in your input script is such that fix
+ thermal/conductivity comes first. If you are using fix ave/spatial to
+ measure the temperature profile induced by fix viscosity, then this
+ may cause a glitch in the profile since you are averaging immediately
+ after swaps have occurred. Flipping the order of the 2 fixes
+ typically helps.
+
+*Fix viscosity comes before fix ave/spatial*
+ The order of these 2 fixes in your input script is such that
+ fix viscosity comes first. If you are using fix ave/spatial
+ to measure the velocity profile induced by fix viscosity, then
+ this may cause a glitch in the profile since you are averaging
+ immediately after swaps have occurred. Flipping the order
+ of the 2 fixes typically helps.
+
+*Fixes cannot send data in Kokkos communication, switching to classic communication*
+ This is current restriction with Kokkos.
+
+*For better accuracy use 'pair_modify table 0'*
+ The user-specified force accuracy cannot be achieved unless the table
+ feature is disabled by using 'pair_modify table 0'.
+
+*Geometric mixing assumed for 1/r^6 coefficients*
+ Self-explanatory.
+
+*Group for fix_modify temp != fix group*
+ The fix_modify command is specifying a temperature computation that
+ computes a temperature on a different group of atoms than the fix
+ itself operates on. This is probably not what you want to do.
+
+*H matrix size has been exceeded: m_fill=%d H.m=%d\n*
+ This is the size of the matrix.
+
+*Improper atoms missing at step %ld*
+ One or more of 4 atoms needed to compute a particular improper are
+ missing on this processor. Typically this is because the pairwise
+ cutoff is set too short or the improper has blown apart and an atom is
+ too far away.
+
+*Improper problem: %d %ld %d %d %d %d*
+ Conformation of the 4 listed improper atoms is extreme; you may want
+ to check your simulation geometry.
+
+*Improper style in data file differs from currently defined improper style*
+ Self-explanatory.
+
+*Inconsistent image flags*
+ The image flags for a pair on bonded atoms appear to be inconsistent.
+ Inconsistent means that when the coordinates of the two atoms are
+ unwrapped using the image flags, the two atoms are far apart.
+ Specifically they are further apart than half a periodic box length.
+ Or they are more than a box length apart in a non-periodic dimension.
+ This is usually due to the initial data file not having correct image
+ flags for the 2 atoms in a bond that straddles a periodic boundary.
+ They should be different by 1 in that case. This is a warning because
+ inconsistent image flags will not cause problems for dynamics or most
+ LAMMPS simulations. However they can cause problems when such atoms
+ are used with the fix rigid or replicate commands.
+
+*KIM Model does not provide `energy'; Potential energy will be zero*
+ Self-explanatory.
+
+*KIM Model does not provide `forces'; Forces will be zero*
+ Self-explanatory.
+
+*KIM Model does not provide `particleEnergy'; energy per atom will be zero*
+ Self-explanatory.
+
+*KIM Model does not provide `particleVirial'; virial per atom will be zero*
+ Self-explanatory.
+
+*Kspace_modify slab param < 2.0 may cause unphysical behavior*
+ The kspace_modify slab parameter should be larger to insure periodic
+ grids padded with empty space do not overlap.
+
+*Less insertions than requested*
+ The fix pour command was unsuccessful at finding open space
+ for as many particles as it tried to insert.
+
+*Library error in lammps_gather_atoms*
+ This library function cannot be used if atom IDs are not defined
+ or are not consecutively numbered.
+
+*Library error in lammps_scatter_atoms*
+ This library function cannot be used if atom IDs are not defined or
+ are not consecutively numbered, or if no atom map is defined. See the
+ atom_modify command for details about atom maps.
+
+*Lost atoms via change_box: original %ld current %ld*
+ The command options you have used caused atoms to be lost.
+
+*Lost atoms via displace_atoms: original %ld current %ld*
+ The command options you have used caused atoms to be lost.
+
+*Lost atoms: original %ld current %ld*
+ Lost atoms are checked for each time thermo output is done. See the
+ thermo_modify lost command for options. Lost atoms usually indicate
+ bad dynamics, e.g. atoms have been blown far out of the simulation
+ box, or moved futher than one processor's sub-domain away before
+ reneighboring.
+
+*MSM mesh too small, increasing to 2 points in each direction*
+ Self-explanatory.
+
+*Mismatch between velocity and compute groups*
+ The temperature computation used by the velocity command will not be
+ on the same group of atoms that velocities are being set for.
+
+*Mixing forced for lj coefficients*
+ Self-explanatory.
+
+*Molecule attributes do not match system attributes*
+ An attribute is specified (e.g. diameter, charge) that is
+ not defined for the specified atom style.
+
+*Molecule has bond topology but no special bond settings*
+ This means the bonded atoms will not be excluded in pair-wise
+ interactions.
+
+*Molecule template for create_atoms has multiple molecules*
+ The create_atoms command will only create molecules of a single type,
+ i.e. the first molecule in the template.
+
+*Molecule template for fix gcmc has multiple molecules*
+ The fix gcmc command will only create molecules of a single type,
+ i.e. the first molecule in the template.
+
+*Molecule template for fix shake has multiple molecules*
+ The fix shake command will only recoginze molecules of a single
+ type, i.e. the first molecule in the template.
+
+*More than one compute centro/atom*
+ It is not efficient to use compute centro/atom more than once.
+
+*More than one compute cluster/atom*
+ It is not efficient to use compute cluster/atom more than once.
+
+*More than one compute cna/atom defined*
+ It is not efficient to use compute cna/atom more than once.
+
+*More than one compute contact/atom*
+ It is not efficient to use compute contact/atom more than once.
+
+*More than one compute coord/atom*
+ It is not efficient to use compute coord/atom more than once.
+
+*More than one compute damage/atom*
+ It is not efficient to use compute ke/atom more than once.
+
+*More than one compute dilatation/atom*
+ Self-explanatory.
+
+*More than one compute erotate/sphere/atom*
+ It is not efficient to use compute erorate/sphere/atom more than once.
+
+*More than one compute ke/atom*
+ It is not efficient to use compute ke/atom more than once.
+
+*More than one compute plasticity/atom*
+ Self-explanatory.
+
+*More than one compute sna/atom*
+ Self-explanatory.
+
+*More than one compute snad/atom*
+ Self-explanatory.
+
+*More than one compute snav/atom*
+ Self-explanatory.
+
+*More than one fix poems*
+ It is not efficient to use fix poems more than once.
+
+*More than one fix rigid*
+ It is not efficient to use fix rigid more than once.
+
+*Neighbor exclusions used with KSpace solver may give inconsistent Coulombic energies*
+ This is because excluding specific pair interactions also excludes
+ them from long-range interactions which may not be the desired effect.
+ The special_bonds command handles this consistently by insuring
+ excluded (or weighted) 1-2, 1-3, 1-4 interactions are treated
+ consistently by both the short-range pair style and the long-range
+ solver. This is not done for exclusions of charged atom pairs via the
+ neigh_modify exclude command.
+
+*New thermo_style command, previous thermo_modify settings will be lost*
+ If a thermo_style command is used after a thermo_modify command, the
+ settings changed by the thermo_modify command will be reset to their
+ default values. This is because the thermo_modify commmand acts on
+ the currently defined thermo style, and a thermo_style command creates
+ a new style.
+
+*No Kspace calculation with verlet/split*
+ The 2nd partition performs a kspace calculation so the kspace_style
+ command must be used.
+
+*No automatic unit conversion to XTC file format conventions possible for units lj*
+ This means no scaling will be performed.
+
+*No fixes defined, atoms won't move*
+ If you are not using a fix like nve, nvt, npt then atom velocities and
+ coordinates will not be updated during timestepping.
+
+*No joints between rigid bodies, use fix rigid instead*
+ The bodies defined by fix poems are not connected by joints. POEMS
+ will integrate the body motion, but it would be more efficient to use
+ fix rigid.
+
+*Not using real units with pair reax*
+ This is most likely an error, unless you have created your own ReaxFF
+ parameter file in a different set of units.
+
+*Number of MSM mesh points changed to be a multiple of 2*
+ MSM requires that the number of grid points in each direction be a multiple
+ of two and the number of grid points in one or more directions have been
+ adjusted to meet this requirement.
+
+*OMP_NUM_THREADS environment is not set.*
+ This environment variable must be set appropriately to use the
+ USER-OMP pacakge.
+
+*One or more atoms are time integrated more than once*
+ This is probably an error since you typically do not want to
+ advance the positions or velocities of an atom more than once
+ per timestep.
+
+*One or more chunks do not contain all atoms in molecule*
+ This may not be what you intended.
+
+*One or more dynamic groups may not be updated at correct point in timestep*
+ If there are other fixes that act immediately after the intitial stage
+ of time integration within a timestep (i.e. after atoms move), then
+ the command that sets up the dynamic group should appear after those
+ fixes. This will insure that dynamic group assignements are made
+ after all atoms have moved.
+
+*One or more respa levels compute no forces*
+ This is computationally inefficient.
+
+*Pair COMB charge %.10f with force %.10f hit max barrier*
+ Something is possibly wrong with your model.
+
+*Pair COMB charge %.10f with force %.10f hit min barrier*
+ Something is possibly wrong with your model.
+
+*Pair brownian needs newton pair on for momentum conservation*
+ Self-explanatory.
+
+*Pair dpd needs newton pair on for momentum conservation*
+ Self-explanatory.
+
+*Pair dsmc: num_of_collisions > number_of_A*
+ Collision model in DSMC is breaking down.
+
+*Pair dsmc: num_of_collisions > number_of_B*
+ Collision model in DSMC is breaking down.
+
+*Pair style in data file differs from currently defined pair style*
+ Self-explanatory.
+
+*Particle deposition was unsuccessful*
+ The fix deposit command was not able to insert as many atoms as
+ needed. The requested volume fraction may be too high, or other atoms
+ may be in the insertion region.
+
+*Proc sub-domain size < neighbor skin, could lead to lost atoms*
+ The decomposition of the physical domain (likely due to load
+ balancing) has led to a processor's sub-domain being smaller than the
+ neighbor skin in one or more dimensions. Since reneighboring is
+ triggered by atoms moving the skin distance, this may lead to lost
+ atoms, if an atom moves all the way across a neighboring processor's
+ sub-domain before reneighboring is triggered.
+
+*Reducing PPPM order b/c stencil extends beyond nearest neighbor processor*
+ This may lead to a larger grid than desired. See the kspace_modify overlap
+ command to prevent changing of the PPPM order.
+
+*Reducing PPPMDisp Coulomb order b/c stencil extends beyond neighbor processor*
+ This may lead to a larger grid than desired. See the kspace_modify overlap
+ command to prevent changing of the PPPM order.
+
+*Reducing PPPMDisp dispersion order b/c stencil extends beyond neighbor processor*
+ This may lead to a larger grid than desired. See the kspace_modify overlap
+ command to prevent changing of the PPPM order.
+
+*Replacing a fix, but new group != old group*
+ The ID and style of a fix match for a fix you are changing with a fix
+ command, but the new group you are specifying does not match the old
+ group.
+
+*Replicating in a non-periodic dimension*
+ The parameters for a replicate command will cause a non-periodic
+ dimension to be replicated; this may cause unwanted behavior.
+
+*Resetting reneighboring criteria during PRD*
+ A PRD simulation requires that neigh_modify settings be delay = 0,
+ every = 1, check = yes. Since these settings were not in place,
+ LAMMPS changed them and will restore them to their original values
+ after the PRD simulation.
+
+*Resetting reneighboring criteria during TAD*
+ A TAD simulation requires that neigh_modify settings be delay = 0,
+ every = 1, check = yes. Since these settings were not in place,
+ LAMMPS changed them and will restore them to their original values
+ after the PRD simulation.
+
+*Resetting reneighboring criteria during minimization*
+ Minimization requires that neigh_modify settings be delay = 0, every =
+ 1, check = yes. Since these settings were not in place, LAMMPS
+ changed them and will restore them to their original values after the
+ minimization.
+
+*Restart file used different # of processors*
+ The restart file was written out by a LAMMPS simulation running on a
+ different number of processors. Due to round-off, the trajectories of
+ your restarted simulation may diverge a little more quickly than if
+ you ran on the same # of processors.
+
+*Restart file used different 3d processor grid*
+ The restart file was written out by a LAMMPS simulation running on a
+ different 3d grid of processors. Due to round-off, the trajectories
+ of your restarted simulation may diverge a little more quickly than if
+ you ran on the same # of processors.
+
+*Restart file used different boundary settings, using restart file values*
+ Your input script cannot change these restart file settings.
+
+*Restart file used different newton bond setting, using restart file value*
+ The restart file value will override the setting in the input script.
+
+*Restart file used different newton pair setting, using input script value*
+ The input script value will override the setting in the restart file.
+
+*Restrain problem: %d %ld %d %d %d %d*
+ Conformation of the 4 listed dihedral atoms is extreme; you may want
+ to check your simulation geometry.
+
+*Running PRD with only one replica*
+ This is allowed, but you will get no parallel speed-up.
+
+*SRD bin shifting turned on due to small lamda*
+ This is done to try to preserve accuracy.
+
+*SRD bin size for fix srd differs from user request*
+ Fix SRD had to adjust the bin size to fit the simulation box. See the
+ cubic keyword if you want this message to be an error vs warning.
+
+*SRD bins for fix srd are not cubic enough*
+ The bin shape is not within tolerance of cubic. See the cubic
+ keyword if you want this message to be an error vs warning.
+
+*SRD particle %d started inside big particle %d on step %ld bounce %d*
+ See the inside keyword if you want this message to be an error vs
+ warning.
+
+*SRD particle %d started inside wall %d on step %ld bounce %d*
+ See the inside keyword if you want this message to be an error vs
+ warning.
+
+*Shake determinant < 0.0*
+ The determinant of the quadratic equation being solved for a single
+ cluster specified by the fix shake command is numerically suspect. LAMMPS
+ will set it to 0.0 and continue.
+
+*Should not allow rigid bodies to bounce off relecting walls*
+ LAMMPS allows this, but their dynamics are not computed correctly.
+
+*Should not use fix nve/limit with fix shake*
+ This will lead to invalid constraint forces in the SHAKE computation.
+
+*Simulations might be very slow because of large number of structure factors*
+ Self-explanatory.
+
+*Slab correction not needed for MSM*
+ Slab correction is intended to be used with Ewald or PPPM and is not needed by MSM.
+
+*System is not charge neutral, net charge = %g*
+ The total charge on all atoms on the system is not 0.0, which
+ is not valid for the long-range Coulombic solvers.
+
+*Table inner cutoff >= outer cutoff*
+ You specified an inner cutoff for a Coulombic table that is longer
+ than the global cutoff. Probably not what you wanted.
+
+*Temperature for MSST is not for group all*
+ User-assigned temperature to MSST fix does not compute temperature for
+ all atoms. Since MSST computes a global pressure, the kinetic energy
+ contribution from the temperature is assumed to also be for all atoms.
+ Thus the pressure used by MSST could be inaccurate.
+
+*Temperature for NPT is not for group all*
+ User-assigned temperature to NPT fix does not compute temperature for
+ all atoms. Since NPT computes a global pressure, the kinetic energy
+ contribution from the temperature is assumed to also be for all atoms.
+ Thus the pressure used by NPT could be inaccurate.
+
+*Temperature for fix modify is not for group all*
+ The temperature compute is being used with a pressure calculation
+ which does operate on group all, so this may be inconsistent.
+
+*Temperature for thermo pressure is not for group all*
+ User-assigned temperature to thermo via the thermo_modify command does
+ not compute temperature for all atoms. Since thermo computes a global
+ pressure, the kinetic energy contribution from the temperature is
+ assumed to also be for all atoms. Thus the pressure printed by thermo
+ could be inaccurate.
+
+*The fix ave/spatial command has been replaced by the more flexible fix ave/chunk and compute chunk/atom commands -- fix ave/spatial will be removed in the summer of 2015*
+ Self-explanatory.
+
+*The minimizer does not re-orient dipoles when using fix efield*
+ This means that only the atom coordinates will be minimized,
+ not the orientation of the dipoles.
+
+*Too many common neighbors in CNA %d times*
+ More than the maximum # of neighbors was found multiple times. This
+ was unexpected.
+
+*Too many inner timesteps in fix ttm*
+ Self-explanatory.
+
+*Too many neighbors in CNA for %d atoms*
+ More than the maximum # of neighbors was found multiple times. This
+ was unexpected.
+
+*Triclinic box skew is large*
+ The displacement in a skewed direction is normally required to be less
+ than half the box length in that dimension. E.g. the xy tilt must be
+ between -half and +half of the x box length. You have relaxed the
+ constraint using the box tilt command, but the warning means that a
+ LAMMPS simulation may be inefficient as a result.
+
+*Use special bonds = 0,1,1 with bond style fene*
+ Most FENE models need this setting for the special_bonds command.
+
+*Use special bonds = 0,1,1 with bond style fene/expand*
+ Most FENE models need this setting for the special_bonds command.
+
+*Using a manybody potential with bonds/angles/dihedrals and special_bond exclusions*
+ This is likely not what you want to do. The exclusion settings will
+ eliminate neighbors in the neighbor list, which the manybody potential
+ needs to calculated its terms correctly.
+
+*Using compute temp/deform with inconsistent fix deform remap option*
+ Fix nvt/sllod assumes deforming atoms have a velocity profile provided
+ by "remap v" or "remap none" as a fix deform option.
+
+*Using compute temp/deform with no fix deform defined*
+ This is probably an error, since it makes little sense to use
+ compute temp/deform in this case.
+
+*Using fix srd with box deformation but no SRD thermostat*
+ The deformation will heat the SRD particles so this can
+ be dangerous.
+
+*Using kspace solver on system with no charge*
+ Self-explanatory.
+
+*Using largest cut-off for lj/long/dipole/long long long*
+ Self-explanatory.
+
+*Using largest cutoff for buck/long/coul/long*
+ Self-exlanatory.
+
+*Using largest cutoff for lj/long/coul/long*
+ Self-explanatory.
+
+*Using largest cutoff for pair_style lj/long/tip4p/long*
+ Self-explanatory.
+
+*Using package gpu without any pair style defined*
+ Self-explanatory.
+
+*Using pair tail corrections with nonperiodic system*
+ This is probably a bogus thing to do, since tail corrections are
+ computed by integrating the density of a periodic system out to
+* :doc:`Thermodynamic output <thermo_style>`, which is a list
+ of quantities printed every few timesteps to the screen and logfile.
+* :doc:`Dump files <dump>`, which contain snapshots of atoms and various
+ per-atom values and are written at a specified frequency.
+* Certain fixes can output user-specified quantities to files: :doc:`fix ave/time <fix_ave_time>` for time averaging, :doc:`fix ave/spatial <fix_ave_spatial>` for spatial averaging, and :doc:`fix print <fix_print>` for single-line output of
+ :doc:`variables <variable>`. Fix print can also output to the
+ screen.
+* :doc:`Restart files <restart>`.
+A simulation prints one set of thermodynamic output and (optionally)
+restart files. It can generate any number of dump files and fix
+output files, depending on what :doc:`dump <dump>` and :doc:`fix <fix>`
+commands you specify.
+
+As discussed below, LAMMPS gives you a variety of ways to determine
+what quantities are computed and printed when the thermodynamics,
+dump, or fix commands listed above perform output. Throughout this
+discussion, note that users can also :doc:`add their own computes and fixes to LAMMPS <Section_modify>` which can then generate values that can
+then be output with these commands.
+
+The following sub-sections discuss different LAMMPS command related
+to output and the kind of data they operate on and produce:
+
+* :ref:`Global/per-atom/local data <global>`
+* :ref:`Scalar/vector/array data <scalar>`
+* :ref:`Thermodynamic output <thermo>`
+* :ref:`Dump file output <dump>`
+* :ref:`Fixes that write output files <fixoutput>`
+* :ref:`Computes that process output quantities <computeoutput>`
+* :ref:`Fixes that process output quantities <fixoutput>`
+* :ref:`Computes that generate values to output <compute>`
+* :ref:`Fixes that generate values to output <fix>`
+* :ref:`Variables that generate values to output <variable>`
+* :ref:`Summary table of output options and data flow between commands <table>`
+
+.. _global:
+
+Global/per-atom/local data
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Various output-related commands work with three different styles of
+data: global, per-atom, or local. A global datum is one or more
+system-wide values, e.g. the temperature of the system. A per-atom
+datum is one or more values per atom, e.g. the kinetic energy of each
+atom. Local datums are calculated by each processor based on the
+atoms it owns, but there may be zero or more per atom, e.g. a list of
+bond distances.
+
+.. _scalar:
+
+Scalar/vector/array data
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Global, per-atom, and local datums can each come in three kinds: a
+single scalar value, a vector of values, or a 2d array of values. The
+doc page for a "compute" or "fix" or "variable" that generates data
+will specify both the style and kind of data it produces, e.g. a
+per-atom vector.
+
+When a quantity is accessed, as in many of the output commands
+discussed below, it can be referenced via the following bracket
+notation, where ID in this case is the ID of a compute. The leading
+"c_" would be replaced by "f_" for a fix, or "v_" for a variable:
+Thermostatting means controlling the temperature of particles in an MD
+simulation. Barostatting means controlling the pressure. Since the
+pressure includes a kinetic component due to particle velocities, both
+these operations require calculation of the temperature. Typically a
+target temperature (T) and/or pressure (P) is specified by the user,
+and the thermostat or barostat attempts to equilibrate the system to
+the requested T and/or P.
+
+Temperature is computed as kinetic energy divided by some number of
+degrees of freedom (and the Boltzmann constant). Since kinetic energy
+is a function of particle velocity, there is often a need to
+distinguish between a particle's advection velocity (due to some
+aggregate motiion of particles) and its thermal velocity. The sum of
+the two is the particle's total velocity, but the latter is often what
+is wanted to compute a temperature.
+
+LAMMPS has several options for computing temperatures, any of which
+can be used in thermostatting and barostatting. These :doc:`compute commands <compute>` calculate temperature, and the :doc:`compute pressure <compute_pressure>` command calculates pressure.
+:doc:`Fix nvt <fix_nh>` only thermostats the translational velocity of
+particles. :doc:`Fix nvt/sllod <fix_nvt_sllod>` also does this, except
+that it subtracts out a velocity bias due to a deforming box and
+integrates the SLLOD equations of motion. See the :ref:`NEMD simulations <howto_13>` section of this page for further details. :doc:`Fix nvt/sphere <fix_nvt_sphere>` and :doc:`fix nvt/asphere <fix_nvt_asphere>` thermostat not only translation
+velocities but also rotational velocities for spherical and aspherical
+particles.
+
+DPD thermostatting alters pairwise interactions in a manner analagous
+to the per-particle thermostatting of :doc:`fix langevin <fix_langevin>`.
+
+Any of the thermostatting fixes can use temperature computes that
+remove bias which has two effects. First, the current calculated
+temperature, which is compared to the requested target temperature, is
+caluclated with the velocity bias removed. Second, the thermostat
+adjusts only the thermal temperature component of the particle's
+velocities, which are the velocities with the bias removed. The
+removed bias is then added back to the adjusted velocities. See the
+doc pages for the individual fixes and for the
+:doc:`fix_modify <fix_modify>` command for instructions on how to assign
+a temperature compute to a thermostatting fix. For example, you can
+apply a thermostat to only the x and z components of velocity by using
+it in conjunction with :doc:`compute temp/partial <compute_temp_partial>`. Of you could thermostat only
+the thermal temperature of a streaming flow of particles without
+affecting the streaming velocity, by using :doc:`compute temp/profile <compute_temp_profile>`.
+
+.. warning::
+
+ Only the nvt fixes perform time integration, meaning
+ they update the velocities and positions of particles due to forces
+ and velocities respectively. The other thermostat fixes only adjust
+ velocities; they do NOT perform time integration updates. Thus they
+ should be used in conjunction with a constant NVE integration fix such
+ as these:
+
+* :doc:`fix nve <fix_nve>`
+* :doc:`fix nve/sphere <fix_nve_sphere>`
+* :doc:`fix nve/asphere <fix_nve_asphere>`
+
+Barostatting in LAMMPS is also performed by :doc:`fixes <fix>`. Two
+barosttating methods are currently available: Nose-Hoover (npt and
+The :doc:`fix npt <fix_nh>` commands include a Nose-Hoover thermostat
+and barostat. :doc:`Fix nph <fix_nh>` is just a Nose/Hoover barostat;
+it does no thermostatting. Both :doc:`fix nph <fix_nh>` and :doc:`fix press/bernendsen <fix_press_berendsen>` can be used in conjunction
+with any of the thermostatting fixes.
+
+As with the thermostats, :doc:`fix npt <fix_nh>` and :doc:`fix nph <fix_nh>` only use translational motion of the particles in
+computing T and P and performing thermo/barostatting. :doc:`Fix npt/sphere <fix_npt_sphere>` and :doc:`fix npt/asphere <fix_npt_asphere>` thermo/barostat using not only
+translation velocities but also rotational velocities for spherical
+and aspherical particles.
+
+All of the barostatting fixes use the :doc:`compute pressure <compute_pressure>` compute to calculate a current
+pressure. By default, this compute is created with a simple :doc:`compute temp <compute_temp>` (see the last argument of the :doc:`compute pressure <compute_pressure>` command), which is used to calculated
+the kinetic componenet of the pressure. The barostatting fixes can
+also use temperature computes that remove bias for the purpose of
+computing the kinetic componenet which contributes to the current
+pressure. See the doc pages for the individual fixes and for the
+:doc:`fix_modify <fix_modify>` command for instructions on how to assign
+a temperature or pressure compute to a barostatting fix.
+
+.. warning::
+
+ As with the thermostats, the Nose/Hoover methods (:doc:`fix npt <fix_nh>` and :doc:`fix nph <fix_nh>`) perform time
+ integration. :doc:`Fix press/berendsen <fix_press_berendsen>` does NOT,
+ so it should be used with one of the constant NVE fixes or with one of
+ the NVT fixes.
+
+Finally, thermodynamic output, which can be setup via the
+:doc:`thermo_style <thermo_style>` command, often includes temperature
+and pressure values. As explained on the doc page for the
+:doc:`thermo_style <thermo_style>` command, the default T and P are
+setup by the thermo command itself. They are NOT the ones associated
+with any thermostatting or barostatting fix you have defined or with
+any compute that calculates a temperature or pressure. Thus if you
+want to view these values of T and P, you need to specify them
+explicitly via a :doc:`thermo_style custom <thermo_style>` command. Or
+you can use the :doc:`thermo_modify <thermo_modify>` command to
+re-define what temperature or pressure compute is used for default
+thermodynamic output.
+
+
+----------
+
+
+.. _howto_17:
+
+Walls
+-----
+
+Walls in an MD simulation are typically used to bound particle motion,
+i.e. to serve as a boundary condition.
+
+Walls in LAMMPS can be of rough (made of particles) or idealized
+surfaces. Ideal walls can be smooth, generating forces only in the
+normal direction, or frictional, generating forces also in the
+tangential direction.
+
+Rough walls, built of particles, can be created in various ways. The
+particles themselves can be generated like any other particle, via the
+:doc:`lattice <lattice>` and :doc:`create_atoms <create_atoms>` commands,
+or read in via the :doc:`read_data <read_data>` command.
+
+Their motion can be constrained by many different commands, so that
+they do not move at all, move together as a group at constant velocity
+or in response to a net force acting on them, move in a prescribed
+fashion (e.g. rotate around a point), etc. Note that if a time
+integration fix like :doc:`fix nve <fix_nve>` or :doc:`fix nvt <fix_nh>`
+is not used with the group that contains wall particles, their
+positions and velocities will not be updated.
+
+* :doc:`fix aveforce <fix_aveforce>` - set force on particles to average value, so they move together
+* :doc:`fix setforce <fix_setforce>` - set force on particles to a value, e.g. 0.0
+* :doc:`fix freeze <fix_freeze>` - freeze particles for use as granular walls
+* :doc:`fix nve/noforce <fix_nve_noforce>` - advect particles by their velocity, but without force
+* :doc:`fix move <fix_move>` - prescribe motion of particles by a linear velocity, oscillation, rotation, variable
+
+The :doc:`fix move <fix_move>` command offers the most generality, since
+the motion of individual particles can be specified with
+:doc:`variable <variable>` formula which depends on time and/or the
+particle position.
+
+For rough walls, it may be useful to turn off pairwise interactions
+between wall particles via the :doc:`neigh_modify exclude <neigh_modify>` command.
+
+Rough walls can also be created by specifying frozen particles that do
+not move and do not interact with mobile particles, and then tethering
+other particles to the fixed particles, via a :doc:`bond <bond_style>`.
+The bonded particles do interact with other mobile particles.
+
+Idealized walls can be specified via several fix commands. :doc:`Fix wall/gran <fix_wall_gran>` creates frictional walls for use with
+granular particles; all the other commands create smooth walls.
+These can extract various global or per-atom quantities from LAMMPS as
+well as values calculated by a compute, fix, or variable. The
+"set_variable" function can set an existing string-style variable to a
+new value, so that subsequent LAMMPS commands can access the variable.
+The "get" and "put" operations can retrieve and reset atom
+coordinates. See the library.cpp file and its associated header file
+library.h for details.
+
+The key idea of the library interface is that you can write any
+functions you wish to define how your code talks to LAMMPS and add
+them to src/library.cpp and src/library.h, as well as to the :doc:`Python interface <Section_python>`. The routines you add can access or
+change any LAMMPS data you wish. The examples/COUPLE and python
+directories have example C++ and C and Python codes which show how a
+driver code can link to LAMMPS as a library, run LAMMPS on a subset of
+processors, grab data from LAMMPS, change it, and put it back into
+LAMMPS.
+
+
+----------
+
+
+.. _howto_20:
+
+Calculating thermal conductivity
+--------------------------------
+
+The thermal conductivity kappa of a material can be measured in at
+least 4 ways using various options in LAMMPS. See the examples/KAPPA
+directory for scripts that implement the 4 methods discussed here for
+a simple Lennard-Jones fluid model. Also, see :ref:`this section <howto_21>` of the manual for an analogous
+discussion for viscosity.
+
+The thermal conducitivity tensor kappa is a measure of the propensity
+of a material to transmit heat energy in a diffusive manner as given
+by Fourier's law
+
+J = -kappa grad(T)
+
+where J is the heat flux in units of energy per area per time and
+grad(T) is the spatial gradient of temperature. The thermal
+conductivity thus has units of energy per distance per time per degree
+K and is often approximated as an isotropic quantity, i.e. as a
+scalar.
+
+The first method is to setup two thermostatted regions at opposite
+ends of a simulation box, or one in the middle and one at the end of a
+periodic box. By holding the two regions at different temperatures
+with a :ref:`thermostatting fix <howto_13>`, the energy
+added to the hot region should equal the energy subtracted from the
+cold region and be proportional to the heat flux moving between the
+regions. See the paper by :ref:`Ikeshoji and Hafskjold <Ikeshoji>` for
+details of this idea. Note that thermostatting fixes such as :doc:`fix nvt <fix_nh>`, :doc:`fix langevin <fix_langevin>`, and :doc:`fix temp/rescale <fix_temp_rescale>` store the cumulative energy they
+add/subtract.
+
+Alternatively, as a second method, the :doc:`fix heat <fix_heat>`
+command can used in place of thermostats on each of two regions to
+add/subtract specified amounts of energy to both regions. In both
+cases, the resulting temperatures of the two regions can be monitored
+with the "compute temp/region" command and the temperature profile of
+the intermediate region can be monitored with the :doc:`fix ave/spatial <fix_ave_spatial>` and :doc:`compute ke/atom <compute_ke_atom>` commands.
+
+The third method is to perform a reverse non-equilibrium MD simulation
+using the :doc:`fix thermal/conductivity <fix_thermal_conductivity>`
+command which implements the rNEMD algorithm of Muller-Plathe.
+Kinetic energy is swapped between atoms in two different layers of the
+simulation box. This induces a temperature gradient between the two
+layers which can be monitored with the :doc:`fix ave/spatial <fix_ave_spatial>` and :doc:`compute ke/atom <compute_ke_atom>` commands. The fix tallies the
+cumulative energy transfer that it performs. See the :doc:`fix thermal/conductivity <fix_thermal_conductivity>` command for
+details.
+
+The fourth method is based on the Green-Kubo (GK) formula which
+relates the ensemble average of the auto-correlation of the heat flux
+to kappa. The heat flux can be calculated from the fluctuations of
+per-atom potential and kinetic energies and per-atom stress tensor in
+a steady-state equilibrated simulation. This is in contrast to the
+two preceding non-equilibrium methods, where energy flows continuously
+between hot and cold regions of the simulation box.
+
+The :doc:`compute heat/flux <compute_heat_flux>` command can calculate
+the needed heat flux and describes how to implement the Green_Kubo
+formalism using additional LAMMPS commands, such as the :doc:`fix ave/correlate <fix_ave_correlate>` command to calculate the needed
+auto-correlation. See the doc page for the :doc:`compute heat/flux <compute_heat_flux>` command for an example input script
+that calculates the thermal conductivity of solid Ar via the GK
+formalism.
+
+
+----------
+
+
+.. _howto_21:
+
+Calculating viscosity
+---------------------
+
+The shear viscosity eta of a fluid can be measured in at least 4 ways
+using various options in LAMMPS. See the examples/VISCOSITY directory
+for scripts that implement the 4 methods discussed here for a simple
+Lennard-Jones fluid model. Also, see :ref:`this section <howto_20>` of the manual for an analogous
+discussion for thermal conductivity.
+
+Eta is a measure of the propensity of a fluid to transmit momentum in
+a direction perpendicular to the direction of velocity or momentum
+flow. Alternatively it is the resistance the fluid has to being
+sheared. It is given by
+
+J = -eta grad(Vstream)
+
+where J is the momentum flux in units of momentum per area per time.
+and grad(Vstream) is the spatial gradient of the velocity of the fluid
+moving in another direction, normal to the area through which the
+momentum flows. Viscosity thus has units of pressure-time.
+
+The first method is to perform a non-equlibrium MD (NEMD) simulation
+by shearing the simulation box via the :doc:`fix deform <fix_deform>`
+command, and using the :doc:`fix nvt/sllod <fix_nvt_sllod>` command to
+thermostat the fluid via the SLLOD equations of motion.
+Alternatively, as a second method, one or more moving walls can be
+used to shear the fluid in between them, again with some kind of
+thermostat that modifies only the thermal (non-shearing) components of
+velocity to prevent the fluid from heating up.
+
+In both cases, the velocity profile setup in the fluid by this
+procedure can be monitored by the :doc:`fix ave/spatial <fix_ave_spatial>` command, which determines
+grad(Vstream) in the equation above. E.g. the derivative in the
+y-direction of the Vx component of fluid motion or grad(Vstream) =
+dVx/dy. The Pxy off-diagonal component of the pressure or stress
+tensor, as calculated by the :doc:`compute pressure <compute_pressure>`
+command, can also be monitored, which is the J term in the equation
+above. See :ref:`this section <howto_13>` of the manual
+for details on NEMD simulations.
+
+The third method is to perform a reverse non-equilibrium MD simulation
+using the :doc:`fix viscosity <fix_viscosity>` command which implements
+the rNEMD algorithm of Muller-Plathe. Momentum in one dimension is
+swapped between atoms in two different layers of the simulation box in
+a different dimension. This induces a velocity gradient which can be
+monitored with the :doc:`fix ave/spatial <fix_ave_spatial>` command.
+The fix tallies the cummulative momentum transfer that it performs.
+See the :doc:`fix viscosity <fix_viscosity>` command for details.
+
+The fourth method is based on the Green-Kubo (GK) formula which
+relates the ensemble average of the auto-correlation of the
+stress/pressure tensor to eta. This can be done in a steady-state
+equilibrated simulation which is in contrast to the two preceding
+non-equilibrium methods, where momentum flows continuously through the
+simulation box.
+
+Here is an example input script that calculates the viscosity of
+liquid Ar via the GK formalism:
+
+.. parsed-literal::
+
+ # Sample LAMMPS input script for viscosity of liquid Ar
+| atoms with same local defect structure | chunk ID = output of :doc:`compute centro/atom <compute_centro_atom>` or :doc:`compute coord/atom <compute_coord_atom>` command |
+When running dynamics with the adiabatic core/shell model, the
+following issues should be considered. Since the relative motion of
+the core and shell particles corresponds to the polarization, typical
+thermostats can alter the polarization behaviour, meaining the shell
+will not react freely to its electrostatic environment. Therefore
+it's typically desirable to decouple the relative motion of the
+core/shell pair, which is an imaginary degree of freedom, from the
+real physical system. To do that, the :doc:`compute temp/cs <compute_temp_cs>` command can be used, in conjunction with
+any of the thermostat fixes, such as :doc:`fix nvt <fix_nh>` or `fix langevin <fix_langevin>`_. This compute uses the center-of-mass velocity
+of the core/shell pairs to calculate a temperature, and insures that
+velocity is what is rescaled for thermostatting purposes. The
+:doc:`compute temp/cs <compute_temp_cs>` command requires input of two
+groups, one for the core atoms, another for the shell atoms. These
+can be defined using the :doc:`group *type* <group>` command. Note that
+to perform thermostatting using this definition of temperature, the
+:doc:`fix modify temp <fix_modify>` command should be used to assign the
+comptue to the thermostat fix. Likewise the :doc:`thermo_modify temp <thermo_modify>` command can be used to make this temperature
+be output for the overall system.
+
+For the NaCl example, this can be done as follows:
+
+.. parsed-literal::
+
+ group cores type 1 2
+ group shells type 3 4
+ compute CSequ all temp/cs cores shells
+ fix thermoberendsen all temp/berendsen 1427 1427 0.4 # thermostat for the true physical system
+ fix thermostatequ all nve # integrator as needed for the berendsen thermostat
+ fix_modify thermoberendsen temp CSequ
+ thermo_modify temp CSequ # output of center-of-mass derived temperature
+
+When intializing the velocities of a system with core/shell pairs, it
+is also desirable to not introduce energy into the relative motion of
+the core/shell particles, but only assign a center-of-mass velocity to
+the pairs. This can be done by using the *bias* keyword of the
+:doc:`velocity create <velocity>` command and assigning the :doc:`compute temp/cs <compute_temp_cs>` command to the *temp* keyword of the
+:doc:`velocity <velocity>` commmand, e.g.
+
+.. parsed-literal::
+
+ velocity all create 1427 134 bias yes temp CSequ
+ velocity all scale 1427 temp CSequ
+
+It is important to note that the polarizability of the core/shell
+pairs is based on their relative motion. Therefore the choice of
+spring force and mass ratio need to ensure much faster relative motion
+of the 2 atoms within the core/shell pair than their center-of-mass
+velocity. This allow the shells to effectively react instantaneously
+to the electrostatic environment. This fast movement also limits the
+timestep size that can be used.
+
+Additionally, the mass mismatch of the core and shell particles means
+that only a small amount of energy is transfered to the decoupled
+imaginary degrees of freedom. However, this transfer will typically
+lead to a a small drift in total energy over time. This internal
+energy can be monitored using the :doc:`compute chunk/atom <compute_chunk_atom>` and :doc:`compute temp/chunk <compute_temp_chunk>` commands. The internal kinetic
+energies of each core/shell pair can then be summed using the sum()
+special functino of the :doc:`variable <variable>` command. Or they can
+be time/averaged and output using the :doc:`fix ave/time <fix_ave_time>`
+command. To use these commands, each core/shell pair must be defined
+as a "chunk". If each core/shell pair is defined as its own molecule,
+the molecule ID can be used to define the chunks. If cores are bonded
+to each other to form larger molecules, then another way to define the
+chunks is to use the :doc:`fix property/atom <fix_property_atom>` to
+assign a core/shell ID to each atom via a special field in the data
+file read by the :doc:`read_data <read_data>` command. This field can
+then be accessed by the :doc:`compute property/atom <compute_property_atom>` command, to use as input to
+the :doc:`compute chunk/atom <compute_chunk_atom>` command to define the
+core/shell pairs as chunks.
+
+For example,
+
+.. parsed-literal::
+
+ fix csinfo all property/atom i_CSID # property/atom command
+ read_data NaCl_CS_x0.1_prop.data fix csinfo NULL CS-Info # atom property added in the data-file
+ compute prop all property/atom i_CSID
+ compute cs_chunk all chunk/atom c_prop
+ compute cstherm all temp/chunk cs_chunk temp internal com yes cdof 3.0 # note the chosen degrees of freedom for the core/shell pairs
+| 10.6 :ref:`Fix styles <mod_6>` which include integrators, temperature and pressure control, force constraints, boundary conditions, diagnostic output, etc
+| USER-INTEL | Vectorized CPU and Intel(R) coprocessor styles | W. Michael Brown (Intel) | :doc:`Section accelerate <accelerate_intel>` | examples/intel | - | - |
+Note that if the "-sf omp" switch is used, it also issues a default
+:doc:`package omp 0 <package>` command, which sets the number of threads
+per MPI task via the OMP_NUM_THREADS environment variable.
+
+Using the "-pk" switch explicitly allows for direct setting of the
+number of threads and additional options. Its syntax is the same as
+the "package omp" command. See the :doc:`package <package>` command doc
+page for details, including the default values used for all its
+options if it is not specified, and how to set the number of threads
+via the OMP_NUM_THREADS environment variable if desired.
+
+**Or run with the USER-OMP package by editing an input script:**
+
+The discussion above for the mpirun/mpiexec command, MPI tasks/node,
+and threads/MPI task is the same.
+
+Use the :doc:`suffix omp <suffix>` command, or you can explicitly add an
+"omp" suffix to individual styles in your input script, e.g.
+
+.. parsed-literal::
+
+ pair_style lj/cut/omp 2.5
+
+You must also use the :doc:`package omp <package>` command to enable the
+USER-OMP package, unless the "-sf omp" or "-pk omp" :ref:`command-line switches <start_7>` were used. It specifies how many
+threads per MPI task to use, as well as other options. Its doc page
+explains how to set the number of threads via an environment variable
+if desired.
+
+**Speed-ups to expect:**
+
+Depending on which styles are accelerated, you should look for a
+reduction in the "Pair time", "Bond time", "KSpace time", and "Loop
+time" values printed at the end of a run.
+
+You may see a small performance advantage (5 to 20%) when running a
+USER-OMP style (in serial or parallel) with a single thread per MPI
+task, versus running standard LAMMPS with its standard
+(un-accelerated) styles (in serial or all-MPI parallelization with 1
+task/core). This is because many of the USER-OMP styles contain
+similar optimizations to those used in the OPT package, as described
+above.
+
+With multiple threads/task, the optimal choice of MPI tasks/node and
+OpenMP threads/task can vary a lot and should always be tested via
+benchmark runs for a specific simulation running on a specific
+machine, paying attention to guidelines discussed in the next
+sub-section.
+
+A description of the multi-threading strategy used in the USER-OMP
+package and some performance examples are `presented here <http://sites.google.com/site/akohlmey/software/lammps-icms/lammps-icms-tms2011-talk.pdf?attredirects=0&d=1>`_
+
+**Guidelines for best performance:**
+
+For many problems on current generation CPUs, running the USER-OMP
+package with a single thread/task is faster than running with multiple
+threads/task. This is because the MPI parallelization in LAMMPS is
+often more efficient than multi-threading as implemented in the
+USER-OMP package. The parallel efficiency (in a threaded sense) also
+varies for different USER-OMP styles.
+
+Using multiple threads/task can be more effective under the following
+circumstances:
+
+* Individual compute nodes have a significant number of CPU cores but
+ the CPU itself has limited memory bandwidth, e.g. for Intel Xeon 53xx
+ (Clovertown) and 54xx (Harpertown) quad core processors. Running one
+ MPI task per CPU core will result in significant performance
+ degradation, so that running with 4 or even only 2 MPI tasks per node
+ is faster. Running in hybrid MPI+OpenMP mode will reduce the
+ inter-node communication bandwidth contention in the same way, but
+ offers an additional speedup by utilizing the otherwise idle CPU
+ cores.
+* The interconnect used for MPI communication does not provide
+ sufficient bandwidth for a large number of MPI tasks per node. For
+ example, this applies to running over gigabit ethernet or on Cray XT4
+ or XT5 series supercomputers. As in the aforementioned case, this
+ effect worsens when using an increasing number of nodes.
+* The system has a spatially inhomogeneous particle density which does
+ not map well to the :doc:`domain decomposition scheme <processors>` or
+ :doc:`load-balancing <balance>` options that LAMMPS provides. This is
+ because multi-threading achives parallelism over the number of
+ particles, not via their distribution in space.
+* A machine is being used in "capability mode", i.e. near the point
+ where MPI parallelism is maxed out. For example, this can happen when
+ using the :doc:`PPPM solver <kspace_style>` for long-range
+ electrostatics on large numbers of nodes. The scaling of the KSpace
+ calculation (see the :doc:`kspace_style <kspace_style>` command) becomes
+ the performance-limiting factor. Using multi-threading allows less
+ MPI tasks to be invoked and can speed-up the long-range solver, while
+ increasing overall performance by parallelizing the pairwise and
+ bonded calculations via OpenMP. Likewise additional speedup can be
+ sometimes be achived by increasing the length of the Coulombic cutoff
+ and thus reducing the work done by the long-range solver. Using the
+ :doc:`run_style verlet/split <run_style>` command, which is compatible
+ with the USER-OMP package, is an alternative way to reduce the number
+ of MPI tasks assigned to the KSpace calculation.
+Additional performance tips are as follows:
+
+* The best parallel efficiency from *omp* styles is typically achieved
+ when there is at least one MPI task per physical processor,
+ i.e. socket or die.
+* It is usually most efficient to restrict threading to a single
+ socket, i.e. use one or more MPI task per socket.
+* Several current MPI implementation by default use a processor affinity
+ setting that restricts each MPI task to a single CPU core. Using
+ multi-threading in this mode will force the threads to share that core
+ and thus is likely to be counterproductive. Instead, binding MPI
+ tasks to a (multi-core) socket, should solve this issue.
+* style = *angle* or *atomic* or *body* or *bond* or *charge* or *dipole* or *electron* or *ellipsoid* or *full* or *line* or *meso* or *molecular* or *peri* or *sphere* or *tri* or *template* or *hybrid*
+.. parsed-literal::
+
+ args = none for any style except *body* and *hybrid*
+ *body* args = bstyle bstyle-args
+ bstyle = style of body particles
+ bstyle-args = additional arguments specific to the bstyle
+ see the :doc:`body <body>` doc page for details
+ *template* args = template-ID
+ template-ID = ID of molecule template specified in a separate :doc:`molecule <molecule>` command
+ *hybrid* args = list of one or more sub-styles, each with their args
+
+* accelerated styles (with same args) = *angle/cuda* or *angle/kk* or *atomic/cuda* or *atomic/kk* or *bond/kk* or *charge/cuda* or *charge/kk* or *full/cuda* or *full/kk* or *molecular/kk*
+
+
+Examples
+""""""""
+
+.. parsed-literal::
+
+ atom_style atomic
+ atom_style bond
+ atom_style full
+ atom_style full/cuda
+ atom_style body nparticle 2 10
+ atom_style hybrid charge bond
+ atom_style hybrid charge body nparticle 2 5
+ atom_style template myMols
+
+Description
+"""""""""""
+
+Define what style of atoms to use in a simulation. This determines
+what attributes are associated with the atoms. This command must be
+used before a simulation is setup via a :doc:`read_data <read_data>`,
+:doc:`read_restart <read_restart>`, or :doc:`create_box <create_box>`
+command.
+
+Once a style is assigned, it cannot be changed, so use a style general
+enough to encompass all attributes. E.g. with style *bond*, angular
+terms cannot be used or added later to the model. It is OK to use a
+style more general than needed, though it may be slightly inefficient.
+
+The choice of style affects what quantities are stored by each atom,
+what quantities are communicated between processors to enable forces
+to be computed, and what quantities are listed in the data file read
+by the :doc:`read_data <read_data>` command.
+
+These are the additional attributes of each style and the typical
+kinds of physical systems they are used to model. All styles store
+coordinates, velocities, atom IDs and types. See the
+:doc:`read_data <read_data>`, :doc:`create_atoms <create_atoms>`, and
+:doc:`set <set>` commands for info on how to set these various
+In other words, using one bracket reduces the dimension of the
+quantity once (vector -> scalar, array -> vector). Using two brackets
+reduces the dimension twice (array -> scalar). Thus a command that
+uses scalar compute values as input can also process elements of a
+vector or array.
+
+Note that commands and :doc:`variables <variable>` which use compute
+quantities typically do not allow for all kinds, e.g. a command may
+require a vector of values, not a scalar. This means there is no
+ambiguity about referring to a compute quantity as c_ID even if it
+produces, for example, both a scalar and vector. The doc pages for
+various commands explain the details.
+
+
+----------
+
+
+In LAMMPS, the values generated by a compute can be used in several
+ways:
+
+* The results of computes that calculate a global temperature or
+ pressure can be used by fixes that do thermostatting or barostatting
+ or when atom velocities are created.
+* Global values can be output via the :doc:`thermo_style custom <thermo_style>` or :doc:`fix ave/time <fix_ave_time>` command.
+ Or the values can be referenced in a :doc:`variable equal <variable>` or
+ :doc:`variable atom <variable>` command.
+* Per-atom values can be output via the :doc:`dump custom <dump>` command
+ or the :doc:`fix ave/spatial <fix_ave_spatial>` command. Or they can be
+ time-averaged via the :doc:`fix ave/atom <fix_ave_atom>` command or
+ reduced by the :doc:`compute reduce <compute_reduce>` command. Or the
+ per-atom values can be referenced in an :doc:`atom-style variable <variable>`.
+* Local values can be reduced by the :doc:`compute reduce <compute_reduce>` command, or histogrammed by the :doc:`fix ave/histo <fix_ave_histo>` command, or output by the :doc:`dump local <dump>` command.
+The results of computes that calculate global quantities can be either
+"intensive" or "extensive" values. Intensive means the value is
+independent of the number of atoms in the simulation,
+e.g. temperature. Extensive means the value scales with the number of
+atoms in the simulation, e.g. total rotational kinetic energy.
+:doc:`Thermodynamic output <thermo_style>` will normalize extensive
+values by the number of atoms in the system, depending on the
+"thermo_modify norm" setting. It will not normalize intensive values.
+If a compute value is accessed in another way, e.g. by a
+:doc:`variable <variable>`, you may want to know whether it is an
+intensive or extensive value. See the doc page for individual
+computes for further info.
+
+
+----------
+
+
+LAMMPS creates its own computes internally for thermodynamic output.
+Three computes are always created, named "thermo_temp",
+"thermo_press", and "thermo_pe", as if these commands had been invoked
+in the input script:
+
+.. parsed-literal::
+
+ compute thermo_temp all temp
+ compute thermo_press all pressure thermo_temp
+ compute thermo_pe all pe
+
+Additional computes for other quantities are created if the thermo
+style requires it. See the documentation for the
+:doc:`thermo_style <thermo_style>` command.
+
+Fixes that calculate temperature or pressure, i.e. for thermostatting
+or barostatting, may also create computes. These are discussed in the
+documentation for specific :doc:`fix <fix>` commands.
+
+In all these cases, the default computes LAMMPS creates can be
+replaced by computes defined by the user in the input script, as
+described by the :doc:`thermo_modify <thermo_modify>` and :doc:`fix modify <fix_modify>` commands.
+
+Properties of either a default or user-defined compute can be modified
+via the :doc:`compute_modify <compute_modify>` command.
+
+Computes can be deleted with the :doc:`uncompute <uncompute>` command.
+
+Code for new computes can be added to LAMMPS (see :doc:`this section <Section_modify>` of the manual) and the results of their
+calculations accessed in the various ways described above.
+
+
+----------
+
+
+Each compute style has its own doc page which describes its arguments
+and what it does. Here is an alphabetic list of compute styles
+available in LAMMPS. They are also given in more compact form in the
+compute section of :ref:`this page <cmd_5>`.
+
+There are also additional compute styles (not listed here) submitted
+by users which are included in the LAMMPS distribution. The list of
+these with links to the individual styles are given in the compute
+section of :ref:`this page <cmd_5>`.
+
+There are also additional accelerated compute styles (note listed
+here) included in the LAMMPS distribution for faster performance on
+CPUs and GPUs. The list of these with links to the individual styles
+are given in the compute section of :ref:`this page <cmd_5>`.
+
+* :doc:`angle/local <compute_bond_local>` - theta and energy of each angle
+* :doc:`body/local <compute_body_local>` - attributes of body sub-particles
+* :doc:`bond/local <compute_bond_local>` - distance and energy of each bond
+* :doc:`centro/atom <compute_centro_atom>` - centro-symmetry parameter for each atom
+* :doc:`cluster/atom <compute_cluster_atom>` - cluster ID for each atom
+* :doc:`cna/atom <compute_cna_atom>` - common neighbor analysis (CNA) for each atom
+* :doc:`com <compute_com>` - center-of-mass of group of atoms
+* :doc:`com/chunk <compute_com_chunk>` - center-of-mass for each chunk
+* :doc:`contact/atom <compute_contact_atom>` - contact count for each spherical particle
+* :doc:`coord/atom <compute_coord_atom>` - coordination number for each atom
+* :doc:`damage/atom <compute_damage_atom>` - Peridynamic damage for each atom
+* :doc:`dihedral/local <compute_dihedral_local>` - angle of each dihedral
+* :doc:`dilatation/atom <compute_dilatation_atom>` - Peridynamic dilatation for each atom
+* :doc:`displace/atom <compute_displace_atom>` - displacement of each atom
+* :doc:`erotate/asphere <compute_erotate_asphere>` - rotational energy of aspherical particles
+* :doc:`erotate/rigid <compute_erotate_rigid>` - rotational energy of rigid bodies
+* :doc:`erotate/sphere <compute_erotate_sphere>` - rotational energy of spherical particles
+* :doc:`erotate/sphere/atom <compute_erotate_sphere>` - rotational energy for each spherical particle
+* :doc:`event/displace <compute_event_displace>` - detect event on atom displacement
+* :doc:`group/group <compute_group_group>` - energy/force between two groups of atoms
+* :doc:`gyration <compute_gyration>` - radius of gyration of group of atoms
+* :doc:`gyration/chunk <compute_gyration_chunk>` - radius of gyration for each chunk
+* :doc:`heat/flux <compute_heat_flux>` - heat flux through a group of atoms
+* :doc:`improper/local <compute_improper_local>` - angle of each improper
+* :doc:`inertia/chunk <compute_inertia_chunk>` - inertia tensor for each chunk
+* :doc:`ke <compute_ke>` - translational kinetic energy
+* :doc:`ke/atom <compute_ke_atom>` - kinetic energy for each atom
+* :doc:`ke/rigid <compute_ke_rigid>` - translational kinetic energy of rigid bodies
+* :doc:`msd <compute_msd>` - mean-squared displacement of group of atoms
+* :doc:`msd/chunk <compute_msd_chunk>` - mean-squared displacement for each chunk
+* :doc:`msd/nongauss <compute_msd_nongauss>` - MSD and non-Gaussian parameter of group of atoms
+* :doc:`pair <compute_pair>` - values computed by a pair style
+* :doc:`pair/local <compute_pair_local>` - distance/energy/force of each pairwise interaction
+* :doc:`pe <compute_pe>` - potential energy
+* :doc:`pe/atom <compute_pe_atom>` - potential energy for each atom
+* :doc:`plasticity/atom <compute_plasticity_atom>` - Peridynamic plasticity for each atom
+* :doc:`pressure <compute_pressure>` - total pressure and pressure tensor
+* :doc:`property/atom <compute_property_atom>` - convert atom attributes to per-atom vectors/arrays
+* :doc:`property/local <compute_property_local>` - convert local attributes to localvectors/arrays
+* :doc:`property/chunk <compute_property_chunk>` - extract various per-chunk attributes
+* :doc:`rdf <compute_rdf>` - radial distribution function g(r) histogram of group of atoms
+* :doc:`reduce <compute_reduce>` - combine per-atom quantities into a single global value
+* :doc:`reduce/region <compute_reduce>` - same as compute reduce, within a region
+* :doc:`slice <compute_slice>` - extract values from global vector or array
+* :doc:`sna/atom <compute_sna>` - calculate bispectrum coefficients for each atom
+* :doc:`snad/atom <compute_sna>` - derivative of bispectrum coefficients for each atom
+* :doc:`snav/atom <compute_sna>` - virial contribution from bispectrum coefficients for each atom
+* :doc:`stress/atom <compute_stress_atom>` - stress tensor for each atom
+* :doc:`temp <compute_temp>` - temperature of group of atoms
+* :doc:`temp/asphere <compute_temp_asphere>` - temperature of aspherical particles
+* :doc:`temp/chunk <compute_temp_chunk>` - temperature of each chunk
+* :doc:`temp/com <compute_temp_com>` - temperature after subtracting center-of-mass velocity
+* :doc:`temp/deform <compute_temp_deform>` - temperature excluding box deformation velocity
+* :doc:`temp/partial <compute_temp_partial>` - temperature excluding one or more dimensions of velocity
+* :doc:`temp/profile <compute_temp_profile>` - temperature excluding a binned velocity profile
+* :doc:`temp/ramp <compute_temp_ramp>` - temperature excluding ramped velocity component
+* :doc:`temp/region <compute_temp_region>` - temperature of a region of atoms
+* :doc:`temp/sphere <compute_temp_sphere>` - temperature of spherical particles
+* :doc:`ti <compute_ti>` - thermodyanmic integration free energy values
+* :doc:`torque/chunk <compute_torque_chunk>` - torque applied on each chunk
+* :doc:`vacf <compute_vacf>` - velocity-autocorrelation function of group of atoms
+* :doc:`vcm/chunk <compute_vcm_chunk>` - velocity of center-of-mass for each chunk
+* :doc:`voronoi/atom <compute_voronoi_atom>` - Voronoi volume and neighbors for each atom
+
+There are also additional compute styles submitted by users which are
+included in the LAMMPS distribution. The list of these with links to
+the individual styles are given in the compute section of :ref:`this page <cmd_5>`.
+
+There are also additional accelerated compute styles included in the
+LAMMPS distribution for faster performance on CPUs and GPUs. The list
+of these with links to the individual styles are given in the pair
+* ID, group-ID are documented in :doc:`compute <compute>` command
+* angmom/chunk = style name of this compute command
+* chunkID = ID of :doc:`compute chunk/atom <compute_chunk_atom>` command
+
+Examples
+""""""""
+
+.. parsed-literal::
+
+ compute 1 fluid angmom/chunk molchunk
+
+Description
+"""""""""""
+
+Define a computation that calculates the angular momemtum of multiple
+chunks of atoms.
+
+In LAMMPS, chunks are collections of atoms defined by a :doc:`compute chunk/atom <compute_chunk_atom>` command, which assigns each atom
+to a single chunk (or no chunk). The ID for this command is specified
+as chunkID. For example, a single chunk could be the atoms in a
+molecule or atoms in a spatial bin. See the :doc:`compute chunk/atom <compute_chunk_atom>` doc page and ":ref:`Section_howto 23 <howto_23>` for details of how chunks can be
+defined and examples of how they can be used to measure properties of
+a system.
+
+This compute calculates the 3 components of the angular momentum
+vector for each chunk, due to the velocity/momentum of the individual
+atoms in the chunk around the center-of-mass of the chunk. The
+calculation includes all effects due to atoms passing thru periodic
+boundaries.
+
+Note that only atoms in the specified group contribute to the
+calculation. The :doc:`compute chunk/atom <compute_chunk_atom>` command
+defines its own group; atoms will have a chunk ID = 0 if they are not
+in that group, signifying they are not assigned to a chunk, and will
+thus also not contribute to this calculation. You can specify the
+"all" group for this command if you simply want to include atoms with
+non-zero chunk IDs.
+
+.. warning::
+
+ The coordinates of an atom contribute to the chunk's
+ angular momentum in "unwrapped" form, by using the image flags
+ associated with each atom. See the :doc:`dump custom <dump>` command
+ for a discussion of "unwrapped" coordinates. See the Atoms section of
+ the :doc:`read_data <read_data>` command for a discussion of image flags
+ and how they are set for each atom. You can reset the image flags
+ (e.g. to 0) before invoking this compute by using the :doc:`set image <set>` command.
+
+The simplest way to output the results of the compute angmom/chunk
+calculation to a file is to use the :doc:`fix ave/time <fix_ave_time>`
+ compute ID group-ID chunk/atom style args keyword values ...
+
+* ID, group-ID are documented in :doc:`compute <compute>` command
+* chunk/atom = style name of this compute command
+.. parsed-literal::
+
+ style = *bin/1d* or *bin/2d* or *bin/3d* or *type* or *molecule* or *compute/fix/variable*
+ *bin/1d* args = dim origin delta
+ dim = *x* or *y* or *z*
+ origin = *lower* or *center* or *upper* or coordinate value (distance units)
+ delta = thickness of spatial bins in dim (distance units)
+ *bin/2d* args = dim origin delta dim origin delta
+ dim = *x* or *y* or *z*
+ origin = *lower* or *center* or *upper* or coordinate value (distance units)
+ delta = thickness of spatial bins in dim (distance units)
+ *bin/3d* args = dim origin delta dim origin delta dim origin delta
+ dim = *x* or *y* or *z*
+ origin = *lower* or *center* or *upper* or coordinate value (distance units)
+ delta = thickness of spatial bins in dim (distance units)
+ *type* args = none
+ *molecule* args = none
+ *compute/fix/variable* = c_ID, c_ID[I], f_ID, f_ID[I], v_name with no args
+ c_ID = per-atom vector calculated by a compute with ID
+ c_ID[I] = Ith column of per-atom array calculated by a compute with ID
+ f_ID = per-atom vector calculated by a fix with ID
+ f_ID[I] = Ith column of per-atom array calculated by a fix with ID
+ v_name = per-atom vector calculated by an atom-style variable with name
+
+* zero or more keyword/values pairs may be appended
+* keyword = *region* or *nchunk* or *static* or *compress* or *bound* or *discard* or *units*
+.. parsed-literal::
+
+ *region* value = region-ID
+ region-ID = ID of region atoms must be in to be part of a chunk
+ *nchunk* value = *once* or *every*
+ once = only compute the number of chunks once
+ every = re-compute the number of chunks whenever invoked
+ *limit* values = 0 or Nc max or Nc exact
+ 0 = no limit on the number of chunks
+ Nc max = limit number of chunks to be <= Nc
+ Nc exact = set number of chunks to exactly Nc
+ *ids* value = *once* or *nfreq* or *every*
+ once = assign chunk IDs to atoms only once, they persist thereafter
+ nfreq = assign chunk IDs to atoms only once every Nfreq steps (if invoked by :doc:`fix ave/chunk <fix_ave_chunk>` which sets Nfreq)
+ every = assign chunk IDs to atoms whenever invoked
+ *compress* value = *yes* or *no*
+ yes = compress chunk IDs to eliminate IDs with no atoms
+ no = do not compress chunk IDs even if some IDs have no atoms
+ *discard* value = *yes* or *no* or *mixed*
+ yes = discard atoms with out-of-range chunk IDs by assigning a chunk ID = 0
+ no = keep atoms with out-of-range chunk IDs by assigning a valid chunk ID
+ mixed = keep or discard such atoms according to spatial binning rule
+ *bound* values = x/y/z lo hi
+ x/y/z = *x* or *y* or *z* to bound sptial bins in this dimension
+ lo = *lower* or coordinate value (distance units)
+ hi = *upper* or coordinate value (distance units)
+ *units* value = *box* or *lattice* or *reduced*
+
+
+
+Examples
+""""""""
+
+.. parsed-literal::
+
+ compute 1 all chunk/atom type
+ compute 1 all chunk/atom bin/1d z lower 0.02 units reduced
+ compute 1 all chunk/atom bin/2d z lower 1.0 y 0.0 2.5
+ compute 1 all chunk/atom molecule region sphere nchunk once ids once compress yes
+
+Description
+"""""""""""
+
+Define a computation that calculates an integer chunk ID from 1 to
+Nchunk for each atom in the group. Values of chunk IDs are determined
+by the *style* of chunk, which can be based on atom type or molecule
+ID or spatial binning or a per-atom property or value calculated by
+another :doc:`compute <compute>`, :doc:`fix <fix>`, or :doc:`atom-style variable <variable>`. Per-atom chunk IDs can be used by other
+computes with "chunk" in their style name, such as :doc:`compute com/chunk <compute_com_chunk>` or :doc:`compute msd/chunk <compute_msd_chunk>`. Or they can be used by the :doc:`fix ave/chunk <fix_ave_chunk>` command to sum and time average a
+variety of per-atom properties over the atoms in each chunk. Or they
+can simply be accessed by any command that uses per-atom values from a
+compute as input, as discussed in :ref:`Section_howto 15 <howto_15>`.
+
+See :ref:`Section_howto 23 <howto_23>` for an overview of
+how this compute can be used with a variety of other commands to
+tabulate properties of a simulation. The howto section gives several
+examples of input script commands that can be used to calculate
+interesting properties.
+
+Conceptually it is important to realize that this compute does two
+simple things. First, it sets the value of *Nchunk* = the number of
+chunks, which can be a constant value or change over time. Second, it
+assigns each atom to a chunk via a chunk ID. Chunk IDs range from 1
+to *Nchunk* inclusive; some chunks may have no atoms assigned to them.
+Atoms that do not belong to any chunk are assigned a value of 0. Note
+that the two operations are not always performed together. For
+example, spatial bins can be setup once (which sets *Nchunk*), and
+atoms assigned to those bins many times thereafter (setting their
+chunk IDs).
+
+All other commands in LAMMPS that use chunk IDs assume there are
+*Nchunk* number of chunks, and that every atom is assigned to one of
+those chunks, or not assigned to any chunk.
+
+There are many options for specifying for how and when *Nchunk* is
+calculated, and how and when chunk IDs are assigned to atoms. The
+details depend on the chunk *style* and its *args*, as well as
+optional keyword settings. They can also depend on whether a :doc:`fix ave/chunk <fix_ave_chunk>` command is using this compute, since
+that command requires *Nchunk* to remain static across windows of
+timesteps it specifies, while it accumulates per-chunk averages.
+
+The details are described below.
+
+
+
+
+
+The different chunk styles operate as follows. For each style, how it
+calculates *Nchunk* and assigns chunk IDs to atoms is explained. Note
+that using the optional keywords can change both of those actions, as
+described further below where the keywords are discussed.
+
+
+----------
+
+
+The *binning* styles perform a spatial binning of atoms, and assign an
+atom the chunk ID corresponding to the bin number it is in. *Nchunk*
+is set to the number of bins, which can change if the simulation box
+size changes.
+
+The *bin/1d*, *bin/2d*, and *bin/3d* styles define bins as 1d layers
+(slabs), 2d pencils, or 3d boxes. The *dim*, *origin*, and *delta*
+settings are specified 1, 2, or 3 times. For 2d or 3d bins, there is
+no restriction on specifying dim = x before dim = y or z, or dim = y
+before dim = z. Bins in a particular *dim* have a bin size in that
+dimension given by *delta*. In each dimension, bins are defined
+relative to a specified *origin*, which may be the lower/upper edge of
+the simulation box (in that dimension), or its center point, or a
+specified coordinate value. Starting at the origin, sufficient bins
+are created in both directions to completely span the simulation box
+or the bounds specified by the optional *bounds* keyword.
+
+For orthogonal simulation boxes, the bins are layers, pencils, or
+boxes aligned with the xyz coordinate axes. For triclinic
+(non-orthogonal) simulation boxes, the bin faces are parallel to the
+tilted faces of the simulation box. See :ref:`this section <howto_12>` of the manual for a discussion of
+the geometry of triclinic boxes in LAMMPS. As described there, a
+tilted simulation box has edge vectors a,b,c. In that nomenclature,
+bins in the x dimension have faces with normals in the "b" cross "c"
+direction. Bins in y have faces normal to the "a" cross "c"
+direction. And bins in z have faces normal to the "a" cross "b"
+direction. Note that in order to define the size and position of
+these bins in an unambiguous fashion, the *units* option must be set
+to *reduced* when using a triclinic simulation box, as noted below.
+
+The meaning of *origin* and *delta* for triclinic boxes is as follows.
+Consider a triclinic box with bins that are 1d layers or slabs in the
+x dimension. No matter how the box is tilted, an *origin* of 0.0
+means start layers at the lower "b" cross "c" plane of the simulation
+box and an *origin* of 1.0 means to start layers at the upper "b"
+cross "c" face of the box. A *delta* value of 0.1 in *reduced* units
+means there will be 10 layers from 0.0 to 1.0, regardless of the
+current size or shape of the simulation box.
+
+The created bins (and hence the chunk IDs) are numbered consecutively
+from 1 to the number of bins = *Nchunk*. For 2d and 3d bins, the
+numbering varies most rapidly in the first dimension (which could be
+x, y, or z), next rapidly in the 2nd dimension, and most slowly in the
+3rd dimension.
+
+Each time this compute is invoked, each atom is mapped to a bin based
+on its current position. Note that between reneighboring timesteps,
+atoms can move outside the current simulation box. If the box is
+periodic (in that dimension) the atom is remapping into the periodic
+box for purposes of binning. If the box in not periodic, the atom may
+have moved outside the bounds of all bins. If an atom is not inside
+any bin, the *discard* keyword is used to determine how a chunk ID is
+assigned to the atom.
+
+
+----------
+
+
+The *type* style uses the atom type as the chunk ID. *Nchunk* is set
+to the number of atom types defined for the simulation, e.g. via the
+:doc:`create_box <create_box>` or :doc:`read_data <read_data>` commands.
+
+
+----------
+
+
+The *molecule* style uses the molecule ID of each atom as its chunk
+ID. *Nchunk* is set to the largest chunk ID. Note that this excludes
+molecule IDs for atoms which are not in the specified group or
+optional region.
+
+There is no requirement that all atoms in a particular molecule are
+assigned the same chunk ID (zero or non-zero), though you probably
+want that to be the case, if you wish to compute a per-molecule
+property. LAMMPS will issue a warning if that is not the case, but
+only the first time that *Nchunk* is calculated.
+
+Note that atoms with a molecule ID = 0, which may be non-molecular
+solvent atoms, have an out-of-range chunk ID. These atoms are
+discarded (not assigned to any chunk) or assigned to *Nchunk*,
+depending on the value of the *discard* keyword.
+
+
+----------
+
+
+The *compute/fix/variable* styles set the chunk ID of each atom based
+on a quantity calculated and stored by a compute, fix, or variable.
+In each case, it must be a per-atom quantity. In each case the
+referenced floating point values are converted to an integer chunk ID
+as follows. The floating point value is truncated (rounded down) to
+an integer value. If the integer value is <= 0, then a chunk ID of 0
+is assigned to the atom. If the integer value is > 0, it becomes the
+chunk ID to the atom. *Nchunk* is set to the largest chunk ID. Note
+that this excludes atoms which are not in the specified group or
+optional region.
+
+If the style begins with "c_", a compute ID must follow which has been
+previously defined in the input script. If no bracketed integer is
+appended, the per-atom vector calculated by the compute is used. If a
+bracketed integer is appended, the Ith column of the per-atom array
+calculated by the compute is used. Users can also write code for
+their own compute styles and :doc:`add them to LAMMPS <Section_modify>`.
+
+If the style begins with "f_", a fix ID must follow which has been
+previously defined in the input script. If no bracketed integer is
+appended, the per-atom vector calculated by the fix is used. If a
+bracketed integer is appended, the Ith column of the per-atom array
+calculated by the fix is used. Note that some fixes only produce
+their values on certain timesteps, which must be compatible with the
+timestep on which this compute accesses the fix, else an error
+results. Users can also write code for their own fix styles and :doc:`add them to LAMMPS <Section_modify>`.
+
+If a value begins with "v_", a variable name for an *atom* or
+*atomfile* style :doc:`variable <variable>` must follow which has been
+previously defined in the input script. Variables of style *atom* can
+reference thermodynamic keywords and various per-atom attributes, or
+invoke other computes, fixes, or variables when they are evaluated, so
+this is a very general means of generating per-atom quantities to
+treat as a chunk ID.
+
+
+
+
+
+Normally, *Nchunk* = the number of chunks, is re-calculated every time
+this fix is invoked, though the value may or may not change. As
+explained below, the *nchunk* keyword can be set to *once* which means
+*Nchunk* will never change.
+
+If a :doc:`fix ave/chunk <fix_ave_chunk>` command uses this compute, it
+can also turn off the re-calculation of *Nchunk* for one or more
+windows of timesteps. The extent of the windows, during which Nchunk
+is held constant, are determined by the *Nevery*, *Nrepeat*, *Nfreq*
+values and the *ave* keyword setting that are used by the :doc:`fix ave/chunk <fix_ave_chunk>` command.
+
+Specifically, if *ave* = *one*, then for each span of *Nfreq*
+timesteps, *Nchunk* is held constant between the first timestep when
+averaging is done (within the Nfreq-length window), and the last
+timestep when averaging is done (multiple of Nfreq). If *ave* =
+*running* or *window*, then *Nchunk* is held constant forever,
+starting on the first timestep when the :doc:`fix ave/chunk <fix_ave_chunk>` command invokes this compute.
+
+Note that multiple :doc:`fix ave/chunk <fix_ave_chunk>` commands can use
+the same compute chunk/atom compute. However, the time windows they
+induce for holding *Nchunk* constant must be identical, else an error
+will be generated.
+
+
+
+
+
+The various optional keywords operate as follows. Note that some of
+them function differently or are ignored by different chunk styles.
+Some of them also have different default values, depending on
+the chunk style, as listed below.
+
+The *region* keyword applies to all chunk styles. If used, an atom
+must be in both the specified group and the specified geometric
+:doc:`region <region>` to be assigned to a chunk.
+
+
+----------
+
+
+The *nchunk* keyword applies to all chunk styles. It specifies how
+often *Nchunk* is recalculated, which in turn can affect the chunk IDs
+assigned to individual atoms.
+
+If *nchunk* is set to *once*, then *Nchunk* is only calculated once,
+the first time this compute is invoked. If *nchunk* is set to
+*every*, then *Nchunk* is re-calculated every time the compute is
+invoked. Note that, as described above, the use of this compute
+by the :doc:`fix ave/chunk <fix_ave_chunk>` command can override
+the *every* setting.
+
+The default values for *nchunk* are listed below and depend on the
+chunk style and other system and keyword settings. They attempt to
+represent typical use cases for the various chunk styles. The
+*nchunk* value can always be set explicitly if desired.
+
+
+----------
+
+
+The *limit* keyword can be used to limit the calculated value of
+*Nchunk* = the number of chunks. The limit is applied each time
+*Nchunk* is calculated, which also limits the chunk IDs assigned to
+any atom. The *limit* keyword is used by all chunk styles except the
+*binning* styles, which ignore it. This is because the number of bins
+can be tailored using the *bound* keyword (described below) which
+effectively limits the size of *Nchunk*.
+
+If *limit* is set to *Nc* = 0, then no limit is imposed on *Nchunk*,
+though the *compress* keyword can still be used to reduce *Nchunk*, as
+described below.
+
+If *Nc* > 0, then the effect of the *limit* keyword depends on whether
+the *compress* keyword is also used with a setting of *yes*, and
+whether the *compress* keyword is specified before the *limit* keyword
+or after.
+
+In all cases, *Nchunk* is first calculated in the usual way for each
+chunk style, as described above.
+
+First, here is what occurs if *compress yes* is not set. If *limit*
+is set to *Nc max*, then *Nchunk* is reset to the smaller of *Nchunk*
+and *Nc*. If *limit* is set to *Nc exact*, then *Nchunk* is reset to
+*Nc*, whether the original *Nchunk* was larger or smaller than *Nc*.
+If *Nchunk* shrank due to the *limit* setting, then atom chunk IDs >
+*Nchunk* will be reset to 0 or *Nchunk*, depending on the setting of
+the *discard* keyword. If *Nchunk* grew, there will simply be some
+chunks with no atoms assigned to them.
+
+If *compress yes* is set, and the *compress* keyword comes before the
+*limit* keyword, the compression operation is performed first, as
+described below, which resets *Nchunk*. The *limit* keyword is then
+applied to the new *Nchunk* value, exactly as described in the
+preceeding paragraph. Note that in this case, all atoms will end up
+with chunk IDs <= *Nc*, but their original values (e.g. molecule ID or
+compute/fix/variable value) may have been > *Nc*, because of the
+compression operation.
+
+If *compress yes* is set, and the *compress* keyword comes after the
+*limit* keyword, then the *limit* value of *Nc* is applied first to
+the uncompressed value of *Nchunk*, but only if *Nc* < *Nchunk*
+(whether *Nc max* or *Nc exact* is used). This effectively means all
+atoms with chunk IDs > *Nc* have their chunk IDs reset to 0 or *Nc*,
+depending on the setting of the *discard* keyword. The compression
+operation is then performed, which may shrink *Nchunk* further. If
+the new *Nchunk* < *Nc* and *limit* = *Nc exact* is specified, then
+*Nchunk* is reset to *Nc*, which results in extra chunks with no atoms
+assigned to them. Note that in this case, all atoms will end up with
+chunk IDs <= *Nc*, and their original values (e.g. molecule ID or
+compute/fix/variable value) will also have been <= *Nc*.
+
+
+----------
+
+
+The *ids* keyword applies to all chunk styles. If the setting is
+*once* then the chunk IDs assigned to atoms the first time this
+compute is invoked will be permanent, and never be re-computed.
+
+If the setting is *nfreq* and if a :doc:`fix ave/chunk <fix_ave_chunk>`
+command is using this compute, then in each of the *Nchunk* = constant
+time windows (discussed above), the chunk ID's assigned to atoms on
+the first step of the time window will persist until the end of the
+time window.
+
+If the setting is *every*, which is the default, then chunk IDs are
+re-calculated on any timestep this compute is invoked.
+
+.. warning::
+
+ If you want the persistent chunk-IDs calculated by
+ this compute to be continuous when running from a :doc:`restart file <read_restart>`, then you should use the same ID for this
+ compute, as in the original run. This is so that the fix this compute
+ creates to store per-atom quantities will also have the same ID, and
+ thus be initialized correctly with chunk IDs from the restart file.
+
+
+----------
+
+
+The *compress* keyword applies to all chunk styles and affects how
+*Nchunk* is calculated, which in turn affects the chunk IDs assigned
+to each atom. It is useful for converting a "sparse" set of chunk IDs
+(with many IDs that have no atoms assigned to them), into a "dense"
+set of IDs, where every chunk has one or more atoms assigned to it.
+
+Two possible use cases are as follows. If a large simulation box is
+mostly empty space, then the *binning* style may produce many bins
+with no atoms. If *compress* is set to *yes*, only bins with atoms
+will be contribute to *Nchunk*. Likewise, the *molecule* or
+*compute/fix/variable* styles may produce large *Nchunk* values. For
+example, the :doc:`compute cluster/atom <compute_cluster_atom>` command
+assigns every atom an atom ID for one of the atoms it is clustered
+with. For a million-atom system with 5 clusters, there would only be
+5 unique chunk IDs, but the largest chunk ID might be 1 million,
+resulting in *Nchunk* = 1 million. If *compress* is set to *yes*,
+*Nchunk* will be reset to 5.
+
+If *compress* is set to *no*, which is the default, no compression is
+done. If it is set to *yes*, all chunk IDs with no atoms are removed
+from the list of chunk IDs, and the list is sorted. The remaining
+chunk IDs are renumbered from 1 to *Nchunk* where *Nchunk* is the new
+length of the list. The chunk IDs assigned to each atom reflect
+the new renumbering from 1 to *Nchunk*.
+
+The original chunk IDs (before renumbering) can be accessed by the
+:doc:`compute property/chunk <compute_property_chunk>` command and its
+*id* keyword, or by the :doc:`fix ave/chunk <fix_ave_chunk>` command
+which outputs the original IDs as one of the columns in its global
+output array. For example, using the "compute cluster/atom" command
+discussed above, the original 5 unique chunk IDs might be atom IDs
+(27,4982,58374,857838,1000000). After compresion, these will be
+renumbered to (1,2,3,4,5). The original values (27,...,1000000) can
+be output to a file by the :doc:`fix ave/chunk <fix_ave_chunk>` command,
+or by using the :doc:`fix ave/time <fix_ave_time>` command in
+conjunction with the :doc:`compute property/chunk <compute_property_chunk>` command.
+
+.. warning::
+
+ The compression operation requires global
+ communication across all processors to share their chunk ID values.
+ It can require large memory on every processor to store them, even
+ after they are compressed, if there are are a large number of unique
+ chunk IDs with atoms assigned to them. It uses a STL map to find
+ unique chunk IDs and store them in sorted order. Each time an atom is
+ assigned a compressed chunk ID, it must access the STL map. All of
+ this means that compression can be expensive, both in memory and CPU
+ time. The use of the *limit* keyword in conjunction with the
+ *compress* keyword can affect these costs, depending on which keyword
+ is used first. So use this option with care.
+
+
+----------
+
+
+The *discard* keyword applies to all chunk styles. It affects what
+chunk IDs are assigned to atoms that do not match one of the valid
+chunk IDs from 1 to *Nchunk*. Note that it does not apply to atoms
+that are not in the specified group or optionally specified region.
+Those atoms are always assigned a chunk ID = 0.
+
+If the calculated chunk ID for an atom is not within the range 1 to
+*Nchunk* then it is a "discard" atom. Note that *Nchunk* may have
+been shrunk by the *limit* keyword. Or the *compress* keyword may
+have eliminated chunk IDs that were valid before the compression took
+place, and are now not in the compressed list. Also note that for the
+*molecule* chunk style, if new molecules are added to the system,
+their chunk IDs may exceed a previously calculated *Nchunk*.
+Likewise, evaluation of a compute/fix/variable on a later timestep may
+return chunk IDs that are invalid for the previously calculated
+*Nchunk*.
+
+All the chunk styles except the *binning* styles, must use *discard*
+set to either *yes* or *no*. If *discard* is set to *yes*, which is
+the default, then every "discard" atom has its chunk ID set to 0. If
+*discard* is set to *no*, every "discard" atom has its chunk ID set to
+*Nchunk*. I.e. it becomes part of the last chunk.
+
+The *binning* styles use the *discard* keyword to decide whether to
+discard atoms outside the spatial domain covered by bins, or to assign
+them to the bin they are nearest to. Details are as follows.
+
+If *discard* is set to *yes*, an out-of-domain atom will have its
+chunk ID set to 0. If *discard* is set to *no*, the atom will have
+its chunk ID set to the first or last bin in that dimension. If
+(discard* is set to *mixed*, which is the default, it will only have
+its chunk ID set to the first or last bin if bins extend to the
+simulation box boundary in that dimension. This is the case if the
+*bound* keyword settings are *lower* and *upper*, which is the
+default. If the *bound* keyword settings are numeric values, then the
+atom will have its chunk ID set to 0 if it is outside the bounds of
+any bin. Note that in this case, it is possible that the first or
+last bin extends beyond the numeric *bounds* settings, depending on
+the specified *origin*. If this is the case, the chunk ID of the atom
+is only set to 0 if it is outside the first or last bin, not if it is
+simply outside the numeric *bounds* setting.
+
+
+----------
+
+
+The *bound* keyword only applies to the *binning* styles; otherwise it
+is ignored. It can be used one or more times to limit the extent of
+bin coverage in a specified dimension, i.e. to only bin a portion of
+the box. If the *lo* setting is *lower* or the *hi* setting is
+*upper*, the bin extent in that direction extends to the box boundary.
+If a numeric value is used for *lo* and/or *hi*, then the bin extent
+in the *lo* or *hi* direction extends only to that value, which is
+assumed to be inside (or at least near) the simulation box boundaries,
+though LAMMPS does not check for this. Note that using the *bound*
+keyword typically reduces the total number of bins and thus the number
+of chunks *Nchunk*.
+
+The *units* keyword only applies to the *binning* styles; otherwise it
+is ignored. It determines the meaning of the distance units used for
+the bin sizes *delta* and for *origin* and *bounds* values if they are
+coordinate values. For orthogonal simulation boxes, any of the 3
+options may be used. For non-orthogonal (triclinic) simulation boxes,
+only the *reduced* option may be used.
+
+A *box* value selects standard distance units as defined by the
+:doc:`units <units>` command, e.g. Angstroms for units = real or metal.
+A *lattice* value means the distance units are in lattice spacings.
+The :doc:`lattice <lattice>` command must have been previously used to
+define the lattice spacing. A *reduced* value means normalized
+unitless values between 0 and 1, which represent the lower and upper
+faces of the simulation box respectively. Thus an *origin* value of
+0.5 means the center of the box in any dimension. A *delta* value of
+0.1 means 10 bins span the box in that dimension.
+
+
+
+
+
+**Output info:**
+
+This compute calculates a per-atom vector, which can be accessed by
+any command that uses per-atom values from a compute as input. See
+:ref:`Section_howto 15 <howto_15>` for an overview of
+LAMMPS output options.
+
+The per-atom vector values are unitless chunk IDs, ranging from 1 to
+*Nchunk* (inclusive) for atoms assigned to chunks, and 0 for atoms not
+belonging to a chunk.
+
+Restrictions
+""""""""""""
+
+
+Even if the *nchunk* keyword is set to *once*, the chunk IDs assigned
+to each atom are not stored in a restart files. This means you cannot
+expect those assignments to persist in a restarted simulation.
+Instead you must re-specify this command and assign atoms to chunks when
+the restarted simulation begins.
+
+Related commands
+""""""""""""""""
+
+:doc:`fix ave/chunk <fix_ave_chunk>`
+
+Default
+"""""""
+
+The option defaults are as follows:
+
+* region = none
+* nchunk = every if compress is yes, overriding other defaults listed here
+* nchunk = once for type style
+* nchunk = once for mol style if region is none
+* nchunk = every for mol style if region is set
+* nchunk = once for binning style if the simulation box size is static or units = reduced
+* nchunk = every for binning style if the simulation box size is dynamic and units is lattice or box
+* ID, group-ID are documented in :doc:`compute <compute>` command
+* com/chunk = style name of this compute command
+* chunkID = ID of :doc:`compute chunk/atom <compute_chunk_atom>` command
+
+Examples
+""""""""
+
+.. parsed-literal::
+
+ compute 1 fluid com/chunk molchunk
+
+Description
+"""""""""""
+
+Define a computation that calculates the center-of-mass for multiple
+chunks of atoms.
+
+In LAMMPS, chunks are collections of atoms defined by a :doc:`compute chunk/atom <compute_chunk_atom>` command, which assigns each atom
+to a single chunk (or no chunk). The ID for this command is specified
+as chunkID. For example, a single chunk could be the atoms in a
+molecule or atoms in a spatial bin. See the :doc:`compute chunk/atom <compute_chunk_atom>` doc page and ":ref:`Section_howto 23 <howto_23>` for details of how chunks can be
+defined and examples of how they can be used to measure properties of
+a system.
+
+This compute calculates the x,y,z coordinates of the center-of-mass
+for each chunk, which includes all effects due to atoms passing thru
+periodic boundaries.
+
+Note that only atoms in the specified group contribute to the
+calculation. The :doc:`compute chunk/atom <compute_chunk_atom>` command
+defines its own group; atoms will have a chunk ID = 0 if they are not
+in that group, signifying they are not assigned to a chunk, and will
+thus also not contribute to this calculation. You can specify the
+"all" group for this command if you simply want to include atoms with
+non-zero chunk IDs.
+
+.. warning::
+
+ The coordinates of an atom contribute to the chunk's
+ center-of-mass in "unwrapped" form, by using the image flags
+ associated with each atom. See the :doc:`dump custom <dump>` command
+ for a discussion of "unwrapped" coordinates. See the Atoms section of
+ the :doc:`read_data <read_data>` command for a discussion of image flags
+ and how they are set for each atom. You can reset the image flags
+ (e.g. to 0) before invoking this compute by using the :doc:`set image <set>` command.
+
+The simplest way to output the results of the compute com/chunk
+calculation to a file is to use the :doc:`fix ave/time <fix_ave_time>`
+Define a computation that calculates the radius of gyration Rg for
+multiple chunks of atoms.
+
+In LAMMPS, chunks are collections of atoms defined by a :doc:`compute chunk/atom <compute_chunk_atom>` command, which assigns each atom
+to a single chunk (or no chunk). The ID for this command is specified
+as chunkID. For example, a single chunk could be the atoms in a
+molecule or atoms in a spatial bin. See the :doc:`compute chunk/atom <compute_chunk_atom>` doc page and ":ref:`Section_howto 23 <howto_23>` for details of how chunks can be
+defined and examples of how they can be used to measure properties of
+a system.
+
+This compute calculates the radius of gyration Rg for each chunk,
+which includes all effects due to atoms passing thru periodic
+boundaries.
+
+Rg is a measure of the size of a chunk, and is computed by this
+formula
+
+.. image:: Eqs/compute_gyration.jpg
+ :align: center
+
+where M is the total mass of the chunk, Rcm is the center-of-mass
+position of the chunk, and the sum is over all atoms in the
+chunk.
+
+Note that only atoms in the specified group contribute to the
+calculation. The :doc:`compute chunk/atom <compute_chunk_atom>` command
+defines its own group; atoms will have a chunk ID = 0 if they are not
+in that group, signifying they are not assigned to a chunk, and will
+thus also not contribute to this calculation. You can specify the
+"all" group for this command if you simply want to include atoms with
+non-zero chunk IDs.
+
+If the *tensor* keyword is specified, then the scalar Rg value is not
+calculated, but an Rg tensor is instead calculated for each chunk.
+The formula for the components of the tensor is the same as the above
+formula, except that (Ri - Rcm)^2 is replaced by (Rix - Rcmx) * (Riy -
+Rcmy) for the xy component, etc. The 6 components of the tensor are
+ordered xx, yy, zz, xy, xz, yz.
+
+.. warning::
+
+ The coordinates of an atom contribute to Rg in
+ "unwrapped" form, by using the image flags associated with each atom.
+ See the :doc:`dump custom <dump>` command for a discussion of
+ "unwrapped" coordinates. See the Atoms section of the
+ :doc:`read_data <read_data>` command for a discussion of image flags and
+ how they are set for each atom. You can reset the image flags
+ (e.g. to 0) before invoking this compute by using the :doc:`set image <set>` command.
+
+The simplest way to output the results of the compute gyration/chunk
+calculation to a file is to use the :doc:`fix ave/time <fix_ave_time>`
+* ID, group-ID are documented in :doc:`compute <compute>` command
+* inertia/chunk = style name of this compute command
+* chunkID = ID of :doc:`compute chunk/atom <compute_chunk_atom>` command
+
+Examples
+""""""""
+
+.. parsed-literal::
+
+ compute 1 fluid inertia/chunk molchunk
+
+Description
+"""""""""""
+
+Define a computation that calculates the inertia tensor for multiple
+chunks of atoms.
+
+In LAMMPS, chunks are collections of atoms defined by a :doc:`compute chunk/atom <compute_chunk_atom>` command, which assigns each atom
+to a single chunk (or no chunk). The ID for this command is specified
+as chunkID. For example, a single chunk could be the atoms in a
+molecule or atoms in a spatial bin. See the :doc:`compute chunk/atom <compute_chunk_atom>` doc page and ":ref:`Section_howto 23 <howto_23>` for details of how chunks can be
+defined and examples of how they can be used to measure properties of
+a system.
+
+This compute calculates the 6 components of the symmetric intertia
+tensor for each chunk, ordered Ixx,Iyy,Izz,Ixy,Iyz,Ixz. The
+calculation includes all effects due to atoms passing thru periodic
+boundaries.
+
+Note that only atoms in the specified group contribute to the
+calculation. The :doc:`compute chunk/atom <compute_chunk_atom>` command
+defines its own group; atoms will have a chunk ID = 0 if they are not
+in that group, signifying they are not assigned to a chunk, and will
+thus also not contribute to this calculation. You can specify the
+"all" group for this command if you simply want to include atoms with
+non-zero chunk IDs.
+
+.. warning::
+
+ The coordinates of an atom contribute to the chunk's
+ inertia tensor in "unwrapped" form, by using the image flags
+ associated with each atom. See the :doc:`dump custom <dump>` command
+ for a discussion of "unwrapped" coordinates. See the Atoms section of
+ the :doc:`read_data <read_data>` command for a discussion of image flags
+ and how they are set for each atom. You can reset the image flags
+ (e.g. to 0) before invoking this compute by using the :doc:`set image <set>` command.
+
+The simplest way to output the results of the compute inertia/chunk
+calculation to a file is to use the :doc:`fix ave/time <fix_ave_time>`
+* ID, group-ID are documented in :doc:`compute <compute>` command
+* msd/chunk = style name of this compute command
+* chunkID = ID of :doc:`compute chunk/atom <compute_chunk_atom>` command
+
+Examples
+""""""""
+
+.. parsed-literal::
+
+ compute 1 all msd/chunk molchunk
+
+Description
+"""""""""""
+
+Define a computation that calculates the mean-squared displacement
+(MSD) for multiple chunks of atoms.
+
+In LAMMPS, chunks are collections of atoms defined by a :doc:`compute chunk/atom <compute_chunk_atom>` command, which assigns each atom
+to a single chunk (or no chunk). The ID for this command is specified
+as chunkID. For example, a single chunk could be the atoms in a
+molecule or atoms in a spatial bin. See the :doc:`compute chunk/atom <compute_chunk_atom>` doc page and ":ref:`Section_howto 23 <howto_23>` for details of how chunks can be
+defined and examples of how they can be used to measure properties of
+a system.
+
+Four quantites are calculated by this compute for each chunk. The
+first 3 quantities are the squared dx,dy,dz displacements of the
+center-of-mass. The 4th component is the total squared displacement,
+i.e. (dx*dx + dy*dy + dz*dz) of the center-of-mass. These
+calculations include all effects due to atoms passing thru periodic
+boundaries.
+
+Note that only atoms in the specified group contribute to the
+calculation. The :doc:`compute chunk/atom <compute_chunk_atom>` command
+defines its own group; atoms will have a chunk ID = 0 if they are not
+in that group, signifying they are not assigned to a chunk, and will
+thus also not contribute to this calculation. You can specify the
+"all" group for this command if you simply want to include atoms with
+non-zero chunk IDs.
+
+The slope of the mean-squared displacement (MSD) versus time is
+proportional to the diffusion coefficient of the diffusing chunks.
+
+The displacement of the center-of-mass of the chunk is from its
+original center-of-mass position, calculated on the timestep this
+compute command was first invoked.
+
+.. warning::
+
+ The number of chunks *Nchunk* calculated by the
+ :doc:`compute chunk/atom <compute_chunk_atom>` command must remain
+ constant each time this compute is invoked, so that the displacement
+ for each chunk from its original position can be computed
+ consistently. If *Nchunk* does not remain constant, an error will be
+ generated. If needed, you can enforce a constant *Nchunk* by using
+ the *nchunk once* or *ids once* options when specifying the :doc:`compute chunk/atom <compute_chunk_atom>` command.
+
+.. warning::
+
+ This compute stores the original position (of the
+ center-of-mass) of each chunk. When a displacement is calculated on a
+ later timestep, it is assumed that the same atoms are assigned to the
+ same chunk ID. However LAMMPS has no simple way to insure this is the
+ case, though you can use the *ids once* option when specifying the
+ :doc:`compute chunk/atom <compute_chunk_atom>` command. Note that if
+ this is not the case, the MSD calculation does not have a sensible
+ meaning.
+
+.. warning::
+
+ The initial coordinates of the atoms in each chunk are
+ stored in "unwrapped" form, by using the image flags associated with
+ each atom. See the :doc:`dump custom <dump>` command for a discussion
+ of "unwrapped" coordinates. See the Atoms section of the
+ :doc:`read_data <read_data>` command for a discussion of image flags and
+ how they are set for each atom. You can reset the image flags
+ (e.g. to 0) before invoking this compute by using the :doc:`set image <set>` command.
+
+.. warning::
+
+ Unlike the :doc:`compute msd <compute_msd>` command,
+ this compute does not store the initial center-of-mass coorindates of
+ its molecules in a restart file. Thus you cannot continue the MSD per
+ chunk calculation of this compute when running from a :doc:`restart file <read_restart>`.
+
+The simplest way to output the results of the compute com/msd
+calculation to a file is to use the :doc:`fix ave/time <fix_ave_time>`
+* ID, group-ID are documented in :doc:`compute <compute>` command
+* omega/chunk = style name of this compute command
+* chunkID = ID of :doc:`compute chunk/atom <compute_chunk_atom>` command
+
+Examples
+""""""""
+
+.. parsed-literal::
+
+ compute 1 fluid omega/chunk molchunk
+
+Description
+"""""""""""
+
+Define a computation that calculates the angular velocity (omega) of
+multiple chunks of atoms.
+
+In LAMMPS, chunks are collections of atoms defined by a :doc:`compute chunk/atom <compute_chunk_atom>` command, which assigns each atom
+to a single chunk (or no chunk). The ID for this command is specified
+as chunkID. For example, a single chunk could be the atoms in a
+molecule or atoms in a spatial bin. See the :doc:`compute chunk/atom <compute_chunk_atom>` doc page and ":ref:`Section_howto 23 <howto_23>` for details of how chunks can be
+defined and examples of how they can be used to measure properties of
+a system.
+
+This compute calculates the 3 components of the angular velocity
+vector for each chunk, via the formula L = Iw where L is the angular
+momentum vector of the chunk, I is its moment of inertia tensor, and w
+is omega = angular velocity of the chunk. The calculation includes
+all effects due to atoms passing thru periodic boundaries.
+
+Note that only atoms in the specified group contribute to the
+calculation. The :doc:`compute chunk/atom <compute_chunk_atom>` command
+defines its own group; atoms will have a chunk ID = 0 if they are not
+in that group, signifying they are not assigned to a chunk, and will
+thus also not contribute to this calculation. You can specify the
+"all" group for this command if you simply want to include atoms with
+non-zero chunk IDs.
+
+.. warning::
+
+ The coordinates of an atom contribute to the chunk's
+ angular velocity in "unwrapped" form, by using the image flags
+ associated with each atom. See the :doc:`dump custom <dump>` command
+ for a discussion of "unwrapped" coordinates. See the Atoms section of
+ the :doc:`read_data <read_data>` command for a discussion of image flags
+ and how they are set for each atom. You can reset the image flags
+ (e.g. to 0) before invoking this compute by using the :doc:`set image <set>` command.
+
+The simplest way to output the results of the compute omega/chunk
+calculation to a file is to use the :doc:`fix ave/time <fix_ave_time>`
+ compute ID group-ID property/chunk chunkID input1 input2 ...
+
+* ID, group-ID are documented in :doc:`compute <compute>` command
+* property/chunk = style name of this compute command
+* input = one or more attributes
+.. parsed-literal::
+
+ attributes = count, id, coord1, coord2, coord3
+ count = # of atoms in chunk
+ id = original chunk IDs before compression by :doc:`compute chunk/atom <compute_chunk_atom>`
+ coord123 = coordinates for spatial bins calculated by :doc:`compute chunk/atom <compute_chunk_atom>`
+
+
+
+Examples
+""""""""
+
+.. parsed-literal::
+
+ compute 1 all property/chunk count
+ compute 1 all property/chunk ID coord1
+
+Description
+"""""""""""
+
+Define a computation that stores the specified attributes of chunks of
+atoms.
+
+In LAMMPS, chunks are collections of atoms defined by a :doc:`compute chunk/atom <compute_chunk_atom>` command, which assigns each atom
+to a single chunk (or no chunk). The ID for this command is specified
+as chunkID. For example, a single chunk could be the atoms in a
+molecule or atoms in a spatial bin. See the :doc:`compute chunk/atom <compute_chunk_atom>` doc page and ":ref:`Section_howto 23 <howto_23>` for details of how chunks can be
+defined and examples of how they can be used to measure properties of
+a system.
+
+This compute calculates and stores the specified attributes of chunks
+as global data so they can be accessed by other :ref:`output commands <howto_15>` and used in conjunction with
+other commands that generate per-chunk data, such as :doc:`compute com/chunk <compute_com_chunk>` or :doc:`compute msd/chunk <compute_msd_chunk>`.
+
+Note that only atoms in the specified group contribute to the
+calculation of the *count* attribute. The :doc:`compute chunk/atom <compute_chunk_atom>` command defines its own group;
+atoms will have a chunk ID = 0 if they are not in that group,
+signifying they are not assigned to a chunk, and will thus also not
+contribute to this calculation. You can specify the "all" group for
+this command if you simply want to include atoms with non-zero chunk
+IDs.
+
+The *count* attribute is the number of atoms in the chunk.
+
+The *id* attribute stores the original chunk ID for each chunk. It
+can only be used if the *compress* keyword was set to *yes* for the
+:doc:`compute chunk/atom <compute_chunk_atom>` command referenced by
+chunkID. This means that the original chunk IDs (e.g. molecule IDs)
+will have been compressed to remove chunk IDs with no atoms assigned
+to them. Thus a compresed chunk ID of 3 may correspond to an original
+chunk ID (molecule ID in this case) of 415. The *id* attribute will
+then be 415 for the 3rd chunk.
+
+The *coordN* attributes can only be used if a *binning* style was used
+in the :doc:`compute chunk/atom <compute_chunk_atom>` command referenced
+by chunkID. For *bin/1d*, *bin/2d*, and *bin/3d* styles the attribute
+is the center point of the bin in the corresponding dimension. Style
+*bin/1d* only defines a *coord1* attribute. Style *bin/2d* adds a
+*coord2* attribute. Style *bin/3d* adds a *coord3* attribute.
+
+Note that if the value of the *units* keyword used in the :doc:`compute chunk/atom command <compute_chunk_atom>` is *box* or *lattice*, the
+*coordN* attributes will be in distance :doc:`units <units>`. If the
+value of the *units* keyword is *reduced*, the *coordN* attributes
+will be in unitless reduced units (0-1).
+
+The simplest way to output the results of the compute property/chunk
+calculation to a file is to use the :doc:`fix ave/time <fix_ave_time>`
+The first two input values in the compute reduce command are vectors
+with the IDs of the 2 atoms in each bond, using the :doc:`compute property/local <compute_property_local>` command. The last input
+value is bond distance, using the :doc:`compute bond/local <compute_bond_local>` command. Instead of taking the
+max of the two atom ID vectors, which does not yield useful
+information in this context, the *replace* keywords will extract the
+atom IDs for the two atoms in the bond of maximum stretch. These atom
+IDs and the bond stretch will be printed with thermodynamic output.
+
+
+----------
+
+
+If a single input is specified this compute produces a global scalar
+value. If multiple inputs are specified, this compute produces a
+global vector of values, the length of which is equal to the number of
+inputs specified.
+
+As discussed below, for the *sum* and *sumsq* modes, the value(s)
+produced by this compute are all "extensive", meaning their value
+scales linearly with the number of atoms involved. If normalized
+values are desired, this compute can be accessed by the :doc:`thermo_style custom <thermo_style>` command with :doc:`thermo_modify norm yes <thermo_modify>` set as an option. Or it can be accessed by a
+:doc:`variable <variable>` that divides by the appropriate atom count.
+
+
+----------
+
+
+**Output info:**
+
+This compute calculates a global scalar if a single input value is
+specified or a global vector of length N where N is the number of
+inputs, and which can be accessed by indices 1 to N. These values can
+be used by any command that uses global scalar or vector values from a
+compute as input. See :ref:`Section_howto 15 <howto_15>`
+for an overview of LAMMPS output options.
+
+All the scalar or vector values calculated by this compute are
+"intensive", except when the *sum* or *sumsq* modes are used on
+per-atom or local vectors, in which case the calculated values are
+"extensive".
+
+The scalar or vector values will be in whatever :doc:`units <units>` the
+Define a computation that calculates the temperature of a group of
+atoms that are also in chunks, after optionally subtracting out the
+center-of-mass velocity of each chunk. By specifying optional values,
+it can also calulate the per-chunk temperature or energies of the
+multiple chunks of atoms.
+
+In LAMMPS, chunks are collections of atoms defined by a :doc:`compute chunk/atom <compute_chunk_atom>` command, which assigns each atom
+to a single chunk (or no chunk). The ID for this command is specified
+as chunkID. For example, a single chunk could be the atoms in a
+molecule or atoms in a spatial bin. See the :doc:`compute chunk/atom <compute_chunk_atom>` doc page and ":ref:`Section_howto 23 <howto_23>` for details of how chunks can be
+defined and examples of how they can be used to measure properties of
+a system.
+
+The temperature is calculated by the formula KE = DOF/2 k T, where KE =
+total kinetic energy of all atoms assigned to chunks (sum of 1/2 m
+v^2), DOF = the total number of degrees of freedom for those atoms, k
+= Boltzmann constant, and T = temperature.
+
+The DOF is calculated as N*adof + Nchunk*cdof, where N = number of
+atoms contributing to the KE, adof = degrees of freedom per atom, and
+cdof = degrees of freedom per chunk. By default adof = 2 or 3 =
+dimensionality of system, as set via the :doc:`dimension <dimension>`
+command, and cdof = 0.0. This gives the usual formula for
+temperature.
+
+A kinetic energy tensor, stored as a 6-element vector, is also
+calculated by this compute for use in the computation of a pressure
+tensor. The formula for the components of the tensor is the same as
+the above formula, except that v^2 is replaced by vx*vy for the xy
+component, etc. The 6 components of the vector are ordered xx, yy,
+zz, xy, xz, yz.
+
+Note that the number of atoms contributing to the temperature is
+calculated each time the temperature is evaluated since it is assumed
+the atoms may be dynamically assigned to chunks. Thus there is no
+need to use the *dynamic* option of the
+:doc:`compute_modify <compute_modify>` command for this compute style.
+
+If any optional values are specified, then per-chunk quantities are
+also calculated and stored in a global array, as described below.
+
+The *temp* value calculates the temperature for each chunk by the
+formula KE = DOF/2 k T, where KE = total kinetic energy of the chunk
+of atoms (sum of 1/2 m v^2), DOF = the total number of degrees of
+freedom for all atoms in the chunk, k = Boltzmann constant, and T =
+temperature.
+
+The DOF in this case is calculated as N*adof + cdof, where N = number
+of atoms in the chunk, adof = degrees of freedom per atom, and cdof =
+degrees of freedom per chunk. By default adof = 2 or 3 =
+dimensionality of system, as set via the :doc:`dimension <dimension>`
+command, and cdof = 0.0. This gives the usual formula for
+temperature.
+
+The *kecom* value calculates the kinetic energy of each chunk as if
+all its atoms were moving with the velocity of the center-of-mass of
+the chunk.
+
+The *internal* value calculates the internal kinetic energy of each
+chunk. The interal KE is summed over the atoms in the chunk using an
+internal "thermal" velocity for each atom, which is its velocity minus
+the center-of-mass velocity of the chunk.
+
+
+----------
+
+
+Note that currently the global and per-chunk temperatures calculated
+by this compute only include translational degrees of freedom for each
+atom. No rotational degrees of freedom are included for finite-size
+particles. Also no degrees of freedom are subtracted for any velocity
+bias or constraints that are applied, such as :doc:`compute temp/partial <compute_temp_partial>`, or :doc:`fix shake <fix_shake>`
+or :doc:`fix rigid <fix_rigid>`. This is because those degrees of
+freedom (e.g. a constrained bond) could apply to sets of atoms that
+are both included and excluded from a specific chunk, and hence the
+concept is somewhat ill-defined. In some cases, you can use the
+*adof* and *cdof* keywords to adjust the calculated degress of freedom
+appropriately, as explained below.
+
+Note that the per-chunk temperature calulated by this compute and the
+:doc:`fix ave/chunk temp <fix_ave_chunk>` command can be different.
+This compute calculates the temperature for each chunk for a single
+snapshot. Fix ave/chunk can do that but can also time average those
+values over many snapshots, or it can compute a temperature as if the
+atoms in the chunk on different timesteps were collected together as
+one set of atoms to calculate their temperature. This compute allows
+the center-of-mass velocity of each chunk to be subtracted before
+calculating the temperature; fix ave/chunk does not.
+
+.. warning::
+
+ Only atoms in the specified group contribute to the
+ calculations performed by this compute. The :doc:`compute chunk/atom <compute_chunk_atom>` command defines its own group;
+ atoms will have a chunk ID = 0 if they are not in that group,
+ signifying they are not assigned to a chunk, and will thus also not
+ contribute to this calculation. You can specify the "all" group for
+ this command if you simply want to include atoms with non-zero chunk
+ IDs.
+
+The simplest way to output the per-chunk results of the compute
+temp/chunk calculation to a file is to use the :doc:`fix ave/time <fix_ave_time>` command, for example:
+* ID, group-ID are documented in :doc:`compute <compute>` command
+* temp/com = style name of this compute command
+
+Examples
+""""""""
+
+.. parsed-literal::
+
+ compute 1 all temp/com
+ compute myTemp mobile temp/com
+
+Description
+"""""""""""
+
+Define a computation that calculates the temperature of a group of
+atoms, after subtracting out the center-of-mass velocity of the group.
+This is useful if the group is expected to have a non-zero net
+velocity for some reason. A compute of this style can be used by any
+command that computes a temperature,
+e.g. :doc:`thermo_modify <thermo_modify>`, :doc:`fix temp/rescale <fix_temp_rescale>`, :doc:`fix npt <fix_nh>`, etc.
+
+After the center-of-mass velocity has been subtracted from each atom,
+the temperature is calculated by the formula KE = dim/2 N k T, where
+KE = total kinetic energy of the group of atoms (sum of 1/2 m v^2),
+dim = 2 or 3 = dimensionality of the simulation, N = number of atoms
+in the group, k = Boltzmann constant, and T = temperature.
+
+A kinetic energy tensor, stored as a 6-element vector, is also
+calculated by this compute for use in the computation of a pressure
+tensor. The formula for the components of the tensor is the same as
+the above formula, except that v^2 is replaced by vx*vy for the xy
+component, etc. The 6 components of the vector are ordered xx, yy,
+zz, xy, xz, yz.
+
+The number of atoms contributing to the temperature is assumed to be
+constant for the duration of the run; use the *dynamic* option of the
+:doc:`compute_modify <compute_modify>` command if this is not the case.
+
+The removal of the center-of-mass velocity by this fix is essentially
+computing the temperature after a "bias" has been removed from the
+velocity of the atoms. If this compute is used with a fix command
+that performs thermostatting then this bias will be subtracted from
+each atom, thermostatting of the remaining thermal velocity will be
+performed, and the bias will be added back in. Thermostatting fixes
+that work in this way include :doc:`fix nvt <fix_nh>`, :doc:`fix temp/rescale <fix_temp_rescale>`, :doc:`fix temp/berendsen <fix_temp_berendsen>`, and :doc:`fix langevin <fix_langevin>`.
+
+This compute subtracts out degrees-of-freedom due to fixes that
+constrain molecular motion, such as :doc:`fix shake <fix_shake>` and
+:doc:`fix rigid <fix_rigid>`. This means the temperature of groups of
+atoms that include these constraints will be computed correctly. If
+needed, the subtracted degrees-of-freedom can be altered using the
+*extra* option of the :doc:`compute_modify <compute_modify>` command.
+
+See :ref:`this howto section <howto_16>` of the manual for
+a discussion of different ways to compute temperature and perform
+thermostatting.
+
+**Output info:**
+
+This compute calculates a global scalar (the temperature) and a global
+vector of length 6 (KE tensor), which can be accessed by indices 1-6.
+These values can be used by any command that uses global scalar or
+vector values from a compute as input. See :ref:`this section <howto_15>` for an overview of LAMMPS output
+options.
+
+The scalar value calculated by this compute is "intensive". The
+vector values are "extensive".
+
+The scalar value will be in temperature :doc:`units <units>`. The
+vector values will be in energy :doc:`units <units>`.
+* ID, group-ID are documented in :doc:`compute <compute>` command
+* temp/cs = style name of this compute command
+* group1 = group-ID of either cores or shells
+* group2 = group-ID of either shells or cores
+
+Examples
+""""""""
+
+.. parsed-literal::
+
+ compute oxygen_c-s all temp/cs O_core O_shell
+ compute core_shells all temp/cs cores shells
+
+Description
+"""""""""""
+
+Define a computation that calculates the temperature of a system based
+on the center-of-mass velocity of atom pairs that are bonded to each
+other. This compute is designed to be used with the adiabatic
+core/shell model of :ref:`(Mitchell and Finchham) <MitchellFinchham>`. See
+:ref:`Section_howto 25 <howto_25>` of the manual for an
+overview of the model as implemented in LAMMPS. Specifically, this
+compute enables correct temperature calculation and thermostatting of
+core/shell pairs where it is desirable for the internal degrees of
+freedom of the core/shell pairs to not be influenced by a thermostat.
+A compute of this style can be used by any command that computes a
+temperature via :doc:`fix_modify <fix_modify>` e.g. :doc:`fix temp/rescale <fix_temp_rescale>`, :doc:`fix npt <fix_nh>`, etc.
+
+For this compute, core and shell particles are specified by two
+respective group IDs, which can be defined using the
+:doc:`group <group>` command. The number of atoms in the two groups
+must be the same and there should be one bond defined between a pair
+of atoms in the two groups.
+
+The temperature is calculated by the formula KE = dim/2 N k T, where
+KE = total kinetic energy of the group of atoms (sum of 1/2 m v^2),
+dim = 2 or 3 = dimensionality of the simulation, N = number of atoms
+in the group, k = Boltzmann constant, and T = temperature. Note that
+the velocity of each core or shell atom used in the KE calculation is
+the velocity of the center-of-mass (COM) of the core/shell pair the
+atom is part of.
+
+A kinetic energy tensor, stored as a 6-element vector, is also
+calculated by this compute for use in the computation of a pressure
+tensor. The formula for the components of the tensor is the same as
+the above formula, except that v^2 is replaced by vx*vy for the xy
+component, etc. The 6 components of the vector are ordered xx, yy,
+zz, xy, xz, yz. Again, the velocity of each core or shell atom is its
+COM velocity.
+
+The change this fix makes to core/shell atom velocities is essentially
+computing the temperature after a "bias" has been removed from the
+velocity of the atoms. This "bias" is the velocity of the atom
+relative to the COM velocity of the core/shell pair. If this compute
+is used with a fix command that performs thermostatting then this bias
+will be subtracted from each atom, thermostatting of the remaining COM
+velocity will be performed, and the bias will be added back in. This
+means the thermostating will effectively be performed on the
+core/shell pairs, instead of on the individual core and shell atoms.
+Thermostatting fixes that work in this way include :doc:`fix nvt <fix_nh>`, :doc:`fix temp/rescale <fix_temp_rescale>`, :doc:`fix temp/berendsen <fix_temp_berendsen>`, and :doc:`fix langevin <fix_langevin>`.
+
+The internal energy of core/shell pairs can be calculated by the
+:doc:`compute temp/chunk <compute_temp_chunk>` command, if chunks are
+defined as core/shell pairs. See :ref:`Section_howto 25 <howto_25>` for more discussion on how to do this.
+
+**Output info:**
+
+This compute calculates a global scalar (the temperature) and a global
+vector of length 6 (KE tensor), which can be accessed by indices 1-6.
+These values can be used by any command that uses global scalar or
+vector values from a compute as input.
+
+The scalar value calculated by this compute is "intensive". The
+vector values are "extensive".
+
+The scalar value will be in temperature :doc:`units <units>`. The
+vector values will be in energy :doc:`units <units>`.
+
+Restrictions
+""""""""""""
+
+
+The number of core/shell pairs contributing to the temperature is
+assumed to be constant for the duration of the run. No fixes should
+be used which generate new molecules or atoms during a simulation.
+* ID, group-ID are documented in :doc:`compute <compute>` command
+* temp/deform = style name of this compute command
+
+Examples
+""""""""
+
+.. parsed-literal::
+
+ compute myTemp all temp/deform
+
+Description
+"""""""""""
+
+Define a computation that calculates the temperature of a group of
+atoms, after subtracting out a streaming velocity induced by the
+simulation box changing size and/or shape, for example in a
+non-equilibrium MD (NEMD) simulation. The size/shape change is
+induced by use of the :doc:`fix deform <fix_deform>` command. A compute
+of this style is created by the :doc:`fix nvt/sllod <fix_nvt_sllod>`
+command to compute the thermal temperature of atoms for thermostatting
+purposes. A compute of this style can also be used by any command
+that computes a temperature, e.g. :doc:`thermo_modify <thermo_modify>`,
+:doc:`fix temp/rescale <fix_temp_rescale>`, :doc:`fix npt <fix_nh>`, etc.
+
+The deformation fix changes the box size and/or shape over time, so
+each atom in the simulation box can be thought of as having a
+"streaming" velocity. For example, if the box is being sheared in x,
+relative to y, then atoms at the bottom of the box (low y) have a
+small x velocity, while atoms at the top of the box (hi y) have a
+large x velocity. This position-dependent streaming velocity is
+subtracted from each atom's actual velocity to yield a thermal
+velocity which is used to compute the temperature.
+
+.. warning::
+
+ :doc:`Fix deform <fix_deform>` has an option for
+ remapping either atom coordinates or velocities to the changing
+ simulation box. When using this compute in conjunction with a
+ deforming box, fix deform should NOT remap atom positions, but rather
+ should let atoms respond to the changing box by adjusting their own
+ velocities (or let :doc:`fix deform <fix_deform>` remap the atom
+ velocities, see it's remap option). If fix deform does remap atom
+ positions, then they appear to move with the box but their velocity is
+ not changed, and thus they do NOT have the streaming velocity assumed
+ by this compute. LAMMPS will warn you if fix deform is defined and
+ its remap setting is not consistent with this compute.
+
+After the streaming velocity has been subtracted from each atom, the
+temperature is calculated by the formula KE = dim/2 N k T, where KE =
+total kinetic energy of the group of atoms (sum of 1/2 m v^2), dim = 2
+or 3 = dimensionality of the simulation, N = number of atoms in the
+group, k = Boltzmann constant, and T = temperature. Note that v in
+the kinetic energy formula is the atom's thermal velocity.
+
+A kinetic energy tensor, stored as a 6-element vector, is also
+calculated by this compute for use in the computation of a pressure
+tensor. The formula for the components of the tensor is the same as
+the above formula, except that v^2 is replaced by vx*vy for the xy
+component, etc. The 6 components of the vector are ordered xx, yy,
+zz, xy, xz, yz.
+
+The number of atoms contributing to the temperature is assumed to be
+constant for the duration of the run; use the *dynamic* option of the
+:doc:`compute_modify <compute_modify>` command if this is not the case.
+
+The removal of the box deformation velocity component by this fix is
+essentially computing the temperature after a "bias" has been removed
+from the velocity of the atoms. If this compute is used with a fix
+command that performs thermostatting then this bias will be subtracted
+from each atom, thermostatting of the remaining thermal velocity will
+be performed, and the bias will be added back in. Thermostatting
+fixes that work in this way include :doc:`fix nvt <fix_nh>`, :doc:`fix temp/rescale <fix_temp_rescale>`, :doc:`fix temp/berendsen <fix_temp_berendsen>`, and :doc:`fix langevin <fix_langevin>`.
+
+.. warning::
+
+ The temperature calculated by this compute is only
+ accurate if the atoms are indeed moving with a stream velocity profile
+ that matches the box deformation. If not, then the compute will
+ subtract off an incorrect stream velocity, yielding a bogus thermal
+ temperature. You should NOT assume that your atoms are streaming at
+ the same rate the box is deforming. Rather, you should monitor their
+ velocity profile, e.g. via the :doc:`fix ave/spatial <fix_ave_spatial>`
+ command. And you can compare the results of this compute to :doc:`compute temp/profile <compute_temp_profile>`, which actually calculates the
+ stream profile before subtracting it. If the two computes do not give
+ roughly the same temperature, then your atoms are not streaming
+ consistent with the box deformation. See the :doc:`fix deform <fix_deform>` command for more details on ways to get atoms
+ to stream consistently with the box deformation.
+
+This compute subtracts out degrees-of-freedom due to fixes that
+constrain molecular motion, such as :doc:`fix shake <fix_shake>` and
+:doc:`fix rigid <fix_rigid>`. This means the temperature of groups of
+atoms that include these constraints will be computed correctly. If
+needed, the subtracted degrees-of-freedom can be altered using the
+*extra* option of the :doc:`compute_modify <compute_modify>` command.
+
+See :ref:`this howto section <howto_16>` of the manual for
+a discussion of different ways to compute temperature and perform
+thermostatting.
+
+**Output info:**
+
+This compute calculates a global scalar (the temperature) and a global
+vector of length 6 (KE tensor), which can be accessed by indices 1-6.
+These values can be used by any command that uses global scalar or
+vector values from a compute as input. See :ref:`this section <howto_15>` for an overview of LAMMPS output
+options.
+
+The scalar value calculated by this compute is "intensive". The
+vector values are "extensive".
+
+The scalar value will be in temperature :doc:`units <units>`. The
+vector values will be in energy :doc:`units <units>`.
+ compute ID group-ID temp/partial xflag yflag zflag
+
+* ID, group-ID are documented in :doc:`compute <compute>` command
+* temp/partial = style name of this compute command
+* xflag,yflag,zflag = 0/1 for whether to exclude/include this dimension
+
+Examples
+""""""""
+
+.. parsed-literal::
+
+ compute newT flow temp/partial 1 1 0
+
+Description
+"""""""""""
+
+Define a computation that calculates the temperature of a group of
+atoms, after excluding one or more velocity components. A compute of
+this style can be used by any command that computes a temperature,
+e.g. :doc:`thermo_modify <thermo_modify>`, :doc:`fix temp/rescale <fix_temp_rescale>`, :doc:`fix npt <fix_nh>`, etc.
+
+The temperature is calculated by the formula KE = dim/2 N k T, where
+KE = total kinetic energy of the group of atoms (sum of 1/2 m v^2),
+dim = dimensionality of the simulation, N = number of atoms in the
+group, k = Boltzmann constant, and T = temperature. The calculation
+of KE excludes the x, y, or z dimensions if xflag, yflag, or zflag =
+0. The dim parameter is adjusted to give the correct number of
+degrees of freedom.
+
+A kinetic energy tensor, stored as a 6-element vector, is also
+calculated by this compute for use in the calculation of a pressure
+tensor. The formula for the components of the tensor is the same as
+the above formula, except that v^2 is replaced by vx*vy for the xy
+component, etc. The 6 components of the vector are ordered xx, yy,
+zz, xy, xz, yz.
+
+The number of atoms contributing to the temperature is assumed to be
+constant for the duration of the run; use the *dynamic* option of the
+:doc:`compute_modify <compute_modify>` command if this is not the case.
+
+The removal of velocity components by this fix is essentially
+computing the temperature after a "bias" has been removed from the
+velocity of the atoms. If this compute is used with a fix command
+that performs thermostatting then this bias will be subtracted from
+each atom, thermostatting of the remaining thermal velocity will be
+performed, and the bias will be added back in. Thermostatting fixes
+that work in this way include :doc:`fix nvt <fix_nh>`, :doc:`fix temp/rescale <fix_temp_rescale>`, :doc:`fix temp/berendsen <fix_temp_berendsen>`, and :doc:`fix langevin <fix_langevin>`.
+
+This compute subtracts out degrees-of-freedom due to fixes that
+constrain molecular motion, such as :doc:`fix shake <fix_shake>` and
+:doc:`fix rigid <fix_rigid>`. This means the temperature of groups of
+atoms that include these constraints will be computed correctly. If
+needed, the subtracted degrees-of-freedom can be altered using the
+*extra* option of the :doc:`compute_modify <compute_modify>` command.
+
+See :ref:`this howto section <howto_16>` of the manual for
+a discussion of different ways to compute temperature and perform
+thermostatting.
+
+
+----------
+
+
+Styles with a *cuda* suffix are functionally the same as the
+corresponding style without the suffix. They have been optimized to
+run faster, depending on your available hardware, as discussed in
+:doc:`Section_accelerate <Section_accelerate>` of the manual. The
+accelerated styles take the same arguments and should produce the same
+results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA package. They are
+only enabled if LAMMPS was built with that package. See the :ref:`Making LAMMPS <start_3>` section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the :ref:`-suffix command-line switch <start_7>` when you invoke LAMMPS, or you can
+use the :doc:`suffix <suffix>` command in your input script.
+
+See :doc:`Section_accelerate <Section_accelerate>` of the manual for
+more instructions on how to use the accelerated styles effectively.
+
+
+----------
+
+
+**Output info:**
+
+This compute calculates a global scalar (the temperature) and a global
+vector of length 6 (KE tensor), which can be accessed by indices 1-6.
+These values can be used by any command that uses global scalar or
+vector values from a compute as input. See :ref:`this section <howto_15>` for an overview of LAMMPS output
+options.
+
+The scalar value calculated by this compute is "intensive". The
+vector values are "extensive".
+
+The scalar value will be in temperature :doc:`units <units>`. The
+vector values will be in energy :doc:`units <units>`.
+Define a computation that calculates the temperature of a group of
+atoms, after subtracting out a spatially-averaged center-of-mass
+velocity field, before computing the kinetic energy. This can be
+useful for thermostatting a collection of atoms undergoing a complex
+flow, e.g. via a profile-unbiased thermostat (PUT) as described in
+:ref:`(Evans) <Evans>`. A compute of this style can be used by any command
+that computes a temperature, e.g. :doc:`thermo_modify <thermo_modify>`,
+:doc:`fix temp/rescale <fix_temp_rescale>`, :doc:`fix npt <fix_nh>`, etc.
+
+The *xflag*, *yflag*, *zflag* settings determine which components of
+average velocity are subtracted out.
+
+The *binstyle* setting and its *Nx*, *Ny*, *Nz* arguments determine
+how bins are setup to perform spatial averaging. "Bins" can be 1d
+slabs, 2d pencils, or 3d bricks depending on which *binstyle* is used.
+The simulation box is partitioned conceptually into *Nx* by *Ny* by
+*Nz* bins. Depending on the *binstyle*, you may only specify one or
+two of these values; the others are effectively set to 1 (no binning
+in that dimension). For non-orthogonal (triclinic) simulation boxes,
+the bins are "tilted" slabs or pencils or bricks that are parallel to
+the tilted faces of the box. See the :doc:`region prism <region>`
+command for a discussion of the geometry of tilted boxes in LAMMPS.
+
+When a temperature is computed, the center-of-mass velocity for the
+set of atoms that are both in the compute group and in the same
+spatial bin is calculated. This bias velocity is then subtracted from
+the velocities of individual atoms in the bin to yield a thermal
+velocity for each atom. Note that if there is only one atom in the
+bin, its thermal velocity will thus be 0.0.
+
+After the spatially-averaged velocity field has been subtracted from
+each atom, the temperature is calculated by the formula KE = (dim/2 N
+- dim*Nx*Ny*Nz) k T, where KE = total kinetic energy of the group of
+atoms (sum of 1/2 m v^2), dim = 2 or 3 = dimensionality of the
+simulation, N = number of atoms in the group, k = Boltzmann constant,
+and T = temperature. The dim*Nx*Ny*Nz term are degrees of freedom
+subtracted to adjust for the removal of the center-of-mass velocity in
+each of Nx*Ny*Nz bins, as discussed in the :ref:`(Evans) <Evans>` paper.
+
+If the *out* keyword is used with a *tensor* value, which is the
+default, a kinetic energy tensor, stored as a 6-element vector, is
+also calculated by this compute for use in the computation of a
+pressure tensor. The formula for the components of the tensor is the
+same as the above formula, except that v^2 is replaced by vx*vy for
+the xy component, etc. The 6 components of the vector are ordered xx,
+yy, zz, xy, xz, yz.
+
+If the *out* keyword is used with a *bin* value, the count of atoms
+and computed temperature for each bin are stored for output, as an
+array of values, as described below. The temperature of each bin is
+calculated as described above, where the bias velocity is subtracted
+and only the remaining thermal velocity of atoms in the bin
+contributes to the temperature. See the note below for how the
+temperature is normalized by the degrees-of-freedom of atoms in the
+bin.
+
+The number of atoms contributing to the temperature is assumed to be
+constant for the duration of the run; use the *dynamic* option of the
+:doc:`compute_modify <compute_modify>` command if this is not the case.
+
+The removal of the spatially-averaged velocity field by this fix is
+essentially computing the temperature after a "bias" has been removed
+from the velocity of the atoms. If this compute is used with a fix
+command that performs thermostatting then this bias will be subtracted
+from each atom, thermostatting of the remaining thermal velocity will
+be performed, and the bias will be added back in. Thermostatting
+fixes that work in this way include :doc:`fix nvt <fix_nh>`, :doc:`fix temp/rescale <fix_temp_rescale>`, :doc:`fix temp/berendsen <fix_temp_berendsen>`, and :doc:`fix langevin <fix_langevin>`.
+
+This compute subtracts out degrees-of-freedom due to fixes that
+constrain molecular motion, such as :doc:`fix shake <fix_shake>` and
+:doc:`fix rigid <fix_rigid>`. This means the temperature of groups of
+atoms that include these constraints will be computed correctly. If
+needed, the subtracted degrees-of-freedom can be altered using the
+*extra* option of the :doc:`compute_modify <compute_modify>` command.
+
+.. warning::
+
+ When using the *out* keyword with a value of *bin*,
+ the calculated temperature for each bin does not include the
+ degrees-of-freedom adjustment described in the preceeding paragraph,
+ for fixes that constrain molecular motion. It does include the
+ adjustment due to the *extra* option, which is applied to each bin.
+
+See :ref:`this howto section <howto_16>` of the manual for
+a discussion of different ways to compute temperature and perform
+thermostatting. Using this compute in conjunction with a
+thermostatting fix, as explained there, will effectively implement a
+profile-unbiased thermostat (PUT), as described in :ref:`(Evans) <Evans>`.
+
+**Output info:**
+
+This compute calculates a global scalar (the temperature). Depending
+on the setting of the *out* keyword, it also calculates a global
+vector or array. For *out* = *tensor*, it calculates a vector of
+length 6 (KE tensor), which can be accessed by indices 1-6. For *out*
+= *bin* it calculates a global array which has 2 columns and N rows,
+where N is the number of bins. The first column contains the number
+of atoms in that bin. The second contains the temperature of that
+bin, calculated as described above. The ordering of rows in the array
+is as follows. Bins in x vary fastest, then y, then z. Thus for a
+10x10x10 3d array of bins, there will be 1000 rows. The bin with
+indices ix,iy,iz = 2,3,4 would map to row M = (iz-1)*10*10 + (iy-1)*10
++ ix = 322, where the rows are numbered from 1 to 1000 and the bin
+indices are numbered from 1 to 10 in each dimension.
+
+These values can be used by any command that uses global scalar or
+vector or array values from a compute as input. See :ref:`this section <howto_15>` for an overview of LAMMPS output
+options.
+
+The scalar value calculated by this compute is "intensive". The
+vector values are "extensive". The array values are "intensive".
+
+The scalar value will be in temperature :doc:`units <units>`. The
+vector values will be in energy :doc:`units <units>`. The first column
+of array values are counts; the values in the second column will be in
+temperature :doc:`units <units>`.
+
+Restrictions
+""""""""""""
+
+
+You should not use too large a velocity-binning grid, especially in
+3d. In the current implementation, the binned velocity averages are
+summed across all processors, so this will be inefficient if the grid
+is too large, and the operation is performed every timestep, as it
+ compute ID group-ID temp/ramp vdim vlo vhi dim clo chi keyword value ...
+
+* ID, group-ID are documented in :doc:`compute <compute>` command
+* temp/ramp = style name of this compute command
+* vdim = *vx* or *vy* or *vz*
+* vlo,vhi = subtract velocities between vlo and vhi (velocity units)
+* dim = *x* or *y* or *z*
+* clo,chi = lower and upper bound of domain to subtract from (distance units)
+* zero or more keyword/value pairs may be appended
+* keyword = *units*
+
+.. parsed-literal::
+
+ *units* value = *lattice* or *box*
+
+Examples
+""""""""
+
+.. parsed-literal::
+
+ compute 2nd middle temp/ramp vx 0 8 y 2 12 units lattice
+
+Description
+"""""""""""
+
+Define a computation that calculates the temperature of a group of
+atoms, after subtracting out an ramped velocity profile before
+computing the kinetic energy. A compute of this style can be used by
+any command that computes a temperature,
+e.g. :doc:`thermo_modify <thermo_modify>`, :doc:`fix temp/rescale <fix_temp_rescale>`, :doc:`fix npt <fix_nh>`, etc.
+
+The meaning of the arguments for this command which define the
+velocity ramp are the same as for the :doc:`velocity ramp <velocity>`
+command which was presumably used to impose the velocity.
+
+After the ramp velocity has been subtracted from the specified
+dimension for each atom, the temperature is calculated by the formula
+KE = dim/2 N k T, where KE = total kinetic energy of the group of
+atoms (sum of 1/2 m v^2), dim = 2 or 3 = dimensionality of the
+simulation, N = number of atoms in the group, k = Boltzmann constant,
+and T = temperature.
+
+The *units* keyword determines the meaning of the distance units used
+for coordinates (c1,c2) and velocities (vlo,vhi). A *box* value
+selects standard distance units as defined by the :doc:`units <units>`
+command, e.g. Angstroms for units = real or metal. A *lattice* value
+means the distance units are in lattice spacings; e.g. velocity =
+lattice spacings / tau. The :doc:`lattice <lattice>` command must have
+been previously used to define the lattice spacing.
+
+A kinetic energy tensor, stored as a 6-element vector, is also
+calculated by this compute for use in the computation of a pressure
+tensor. The formula for the components of the tensor is the same as
+the above formula, except that v^2 is replaced by vx*vy for the xy
+component, etc. The 6 components of the vector are ordered xx, yy,
+zz, xy, xz, yz.
+
+The number of atoms contributing to the temperature is assumed to be
+constant for the duration of the run; use the *dynamic* option of the
+:doc:`compute_modify <compute_modify>` command if this is not the case.
+
+The removal of the ramped velocity component by this fix is
+essentially computing the temperature after a "bias" has been removed
+from the velocity of the atoms. If this compute is used with a fix
+command that performs thermostatting then this bias will be subtracted
+from each atom, thermostatting of the remaining thermal velocity will
+be performed, and the bias will be added back in. Thermostatting
+fixes that work in this way include :doc:`fix nvt <fix_nh>`, :doc:`fix temp/rescale <fix_temp_rescale>`, :doc:`fix temp/berendsen <fix_temp_berendsen>`, and :doc:`fix langevin <fix_langevin>`.
+
+This compute subtracts out degrees-of-freedom due to fixes that
+constrain molecular motion, such as :doc:`fix shake <fix_shake>` and
+:doc:`fix rigid <fix_rigid>`. This means the temperature of groups of
+atoms that include these constraints will be computed correctly. If
+needed, the subtracted degrees-of-freedom can be altered using the
+*extra* option of the :doc:`compute_modify <compute_modify>` command.
+
+See :ref:`this howto section <howto_16>` of the manual for
+a discussion of different ways to compute temperature and perform
+thermostatting.
+
+**Output info:**
+
+This compute calculates a global scalar (the temperature) and a global
+vector of length 6 (KE tensor), which can be accessed by indices 1-6.
+These values can be used by any command that uses global scalar or
+vector values from a compute as input. See :ref:`this section <howto_15>` for an overview of LAMMPS output
+options.
+
+The scalar value calculated by this compute is "intensive". The
+vector values are "extensive".
+
+The scalar value will be in temperature :doc:`units <units>`. The
+vector values will be in energy :doc:`units <units>`.
+* ID, group-ID are documented in :doc:`compute <compute>` command
+* temp/region = style name of this compute command
+* region-ID = ID of region to use for choosing atoms
+
+Examples
+""""""""
+
+.. parsed-literal::
+
+ compute mine flow temp/region boundary
+
+Description
+"""""""""""
+
+Define a computation that calculates the temperature of a group of
+atoms in a geometric region. This can be useful for thermostatting
+one portion of the simulation box. E.g. a McDLT simulation where one
+side is cooled, and the other side is heated. A compute of this style
+can be used by any command that computes a temperature,
+e.g. :doc:`thermo_modify <thermo_modify>`, :doc:`fix temp/rescale <fix_temp_rescale>`, etc.
+
+Note that a *region*-style temperature can be used to thermostat with
+:doc:`fix temp/rescale <fix_temp_rescale>` or :doc:`fix langevin <fix_langevin>`, but should probably not be used with
+Nose/Hoover style fixes (:doc:`fix nvt <fix_nh>`, :doc:`fix npt <fix_nh>`, or :doc:`fix nph <fix_nh>`), if the
+degrees-of-freedom included in the computed T varies with time.
+
+The temperature is calculated by the formula KE = dim/2 N k T, where
+KE = total kinetic energy of the group of atoms (sum of 1/2 m v^2),
+dim = 2 or 3 = dimensionality of the simulation, N = number of atoms
+in both the group and region, k = Boltzmann constant, and T =
+temperature.
+
+A kinetic energy tensor, stored as a 6-element vector, is also
+calculated by this compute for use in the computation of a pressure
+tensor. The formula for the components of the tensor is the same as
+the above formula, except that v^2 is replaced by vx*vy for the xy
+component, etc. The 6 components of the vector are ordered xx, yy,
+zz, xy, xz, yz.
+
+The number of atoms contributing to the temperature is calculated each
+time the temperature is evaluated since it is assumed atoms can
+enter/leave the region. Thus there is no need to use the *dynamic*
+option of the :doc:`compute_modify <compute_modify>` command for this
+compute style.
+
+The removal of atoms outside the region by this fix is essentially
+computing the temperature after a "bias" has been removed, which in
+this case is the velocity of any atoms outside the region. If this
+compute is used with a fix command that performs thermostatting then
+this bias will be subtracted from each atom, thermostatting of the
+remaining thermal velocity will be performed, and the bias will be
+added back in. Thermostatting fixes that work in this way include
+:doc:`fix nvt <fix_nh>`, :doc:`fix temp/rescale <fix_temp_rescale>`, :doc:`fix temp/berendsen <fix_temp_berendsen>`, and :doc:`fix langevin <fix_langevin>`. This means any of the thermostatting
+fixes can operate on a geometric region of atoms, as defined by this
+compute.
+
+Unlike other compute styles that calculate temperature, this compute
+does not subtract out degrees-of-freedom due to fixes that constrain
+motion, such as :doc:`fix shake <fix_shake>` and :doc:`fix rigid <fix_rigid>`. This is because those degrees of freedom
+(e.g. a constrained bond) could apply to sets of atoms that straddle
+the region boundary, and hence the concept is somewhat ill-defined.
+If needed the number of subtracted degrees-of-freedom can be set
+explicitly using the *extra* option of the
+:doc:`compute_modify <compute_modify>` command.
+
+See :ref:`this howto section <howto_16>` of the manual for
+a discussion of different ways to compute temperature and perform
+thermostatting.
+
+**Output info:**
+
+This compute calculates a global scalar (the temperature) and a global
+vector of length 6 (KE tensor), which can be accessed by indices 1-6.
+These values can be used by any command that uses global scalar or
+vector values from a compute as input. See :ref:`this section <howto_15>` for an overview of LAMMPS output
+options.
+
+The scalar value calculated by this compute is "intensive". The
+vector values are "extensive".
+
+The scalar value will be in temperature :doc:`units <units>`. The
+vector values will be in energy :doc:`units <units>`.
+* ID, group-ID are documented in :doc:`compute <compute>` command
+* temp/rotate = style name of this compute command
+
+Examples
+""""""""
+
+.. parsed-literal::
+
+ compute Tbead bead temp/rotate
+
+Description
+"""""""""""
+
+Define a computation that calculates the temperature of a group of
+atoms, after subtracting out the center-of-mass velocity and angular velocity of the group.
+This is useful if the group is expected to have a non-zero net
+velocity and/or global rotation motion for some reason. A compute of this style can be used by any
+command that computes a temperature,
+e.g. :doc:`thermo_modify <thermo_modify>`, :doc:`fix temp/rescale <fix_temp_rescale>`, :doc:`fix npt <fix_nh>`, etc.
+
+After the center-of-mass velocity and angular velocity has been subtracted from each atom,
+the temperature is calculated by the formula KE = dim/2 N k T, where
+KE = total kinetic energy of the group of atoms (sum of 1/2 m v^2),
+dim = 2 or 3 = dimensionality of the simulation, N = number of atoms
+in the group, k = Boltzmann constant, and T = temperature.
+
+A kinetic energy tensor, stored as a 6-element vector, is also
+calculated by this compute for use in the computation of a pressure
+tensor. The formula for the components of the tensor is the same as
+the above formula, except that v^2 is replaced by vx*vy for the xy
+component, etc. The 6 components of the vector are ordered xx, yy,
+zz, xy, xz, yz.
+
+The number of atoms contributing to the temperature is assumed to be
+constant for the duration of the run; use the *dynamic* option of the
+:doc:`compute_modify <compute_modify>` command if this is not the case.
+
+The removal of the center-of-mass velocity and angular velocity by this fix is essentially
+computing the temperature after a "bias" has been removed from the
+velocity of the atoms. If this compute is used with a fix command
+that performs thermostatting then this bias will be subtracted from
+each atom, thermostatting of the remaining thermal velocity will be
+performed, and the bias will be added back in. Thermostatting fixes
+that work in this way include :doc:`fix nvt <fix_nh>`, :doc:`fix temp/rescale <fix_temp_rescale>`, :doc:`fix temp/berendsen <fix_temp_berendsen>`, and :doc:`fix langevin <fix_langevin>`.
+
+This compute subtracts out degrees-of-freedom due to fixes that
+constrain molecular motion, such as :doc:`fix shake <fix_shake>` and
+:doc:`fix rigid <fix_rigid>`. This means the temperature of groups of
+atoms that include these constraints will be computed correctly. If
+needed, the subtracted degrees-of-freedom can be altered using the
+*extra* option of the :doc:`compute_modify <compute_modify>` command.
+
+See :ref:`this howto section <howto_16>` of the manual for
+a discussion of different ways to compute temperature and perform
+thermostatting.
+
+**Output info:**
+
+This compute calculates a global scalar (the temperature) and a global
+vector of length 6 (KE tensor), which can be accessed by indices 1-6.
+These values can be used by any command that uses global scalar or
+vector values from a compute as input. See :ref:`this section <howto_15>` for an overview of LAMMPS output
+options.
+
+The scalar value calculated by this compute is "intensive". The
+vector values are "extensive".
+
+The scalar value will be in temperature :doc:`units <units>`. The
+vector values will be in energy :doc:`units <units>`.
+
+Restrictions
+""""""""""""
+
+
+This compute is part of the USER-MISC package. It is only enabled if
+LAMMPS was built with that package. See the :ref:`Making LAMMPS <start_3>` section for more info.
+* ID, group-ID are documented in :doc:`compute <compute>` command
+* torque/chunk = style name of this compute command
+* chunkID = ID of :doc:`compute chunk/atom <compute_chunk_atom>` command
+
+Examples
+""""""""
+
+.. parsed-literal::
+
+ compute 1 fluid torque/chunk molchunk
+
+Description
+"""""""""""
+
+Define a computation that calculates the torque on multiple chunks of
+atoms.
+
+In LAMMPS, chunks are collections of atoms defined by a :doc:`compute chunk/atom <compute_chunk_atom>` command, which assigns each atom
+to a single chunk (or no chunk). The ID for this command is specified
+as chunkID. For example, a single chunk could be the atoms in a
+molecule or atoms in a spatial bin. See the :doc:`compute chunk/atom <compute_chunk_atom>` doc page and ":ref:`Section_howto 23 <howto_23>` for details of how chunks can be
+defined and examples of how they can be used to measure properties of
+a system.
+
+This compute calculates the 3 components of the torque vector for eqch
+chunk, due to the forces on the individual atoms in the chunk around
+the center-of-mass of the chunk. The calculation includes all effects
+due to atoms passing thru periodic boundaries.
+
+Note that only atoms in the specified group contribute to the
+calculation. The :doc:`compute chunk/atom <compute_chunk_atom>` command
+defines its own group; atoms will have a chunk ID = 0 if they are not
+in that group, signifying they are not assigned to a chunk, and will
+thus also not contribute to this calculation. You can specify the
+"all" group for this command if you simply want to include atoms with
+non-zero chunk IDs.
+
+.. warning::
+
+ The coordinates of an atom contribute to the chunk's
+ torque in "unwrapped" form, by using the image flags associated with
+ each atom. See the :doc:`dump custom <dump>` command for a discussion
+ of "unwrapped" coordinates. See the Atoms section of the
+ :doc:`read_data <read_data>` command for a discussion of image flags and
+ how they are set for each atom. You can reset the image flags
+ (e.g. to 0) before invoking this compute by using the :doc:`set image <set>` command.
+
+The simplest way to output the results of the compute torque/chunk
+calculation to a file is to use the :doc:`fix ave/time <fix_ave_time>`
+* ID, group-ID are documented in :doc:`compute <compute>` command
+* vcm/chunk = style name of this compute command
+* chunkID = ID of :doc:`compute chunk/atom <compute_chunk_atom>` command
+
+Examples
+""""""""
+
+.. parsed-literal::
+
+ compute 1 fluid vcm/chunk molchunk
+
+Description
+"""""""""""
+
+Define a computation that calculates the center-of-mass velocity for
+multiple chunks of atoms.
+
+In LAMMPS, chunks are collections of atoms defined by a :doc:`compute chunk/atom <compute_chunk_atom>` command, which assigns each atom
+to a single chunk (or no chunk). The ID for this command is specified
+as chunkID. For example, a single chunk could be the atoms in a
+molecule or atoms in a spatial bin. See the :doc:`compute chunk/atom <compute_chunk_atom>` doc page and ":ref:`Section_howto 23 <howto_23>` for details of how chunks can be
+defined and examples of how they can be used to measure properties of
+a system.
+
+This compute calculates the x,y,z components of the center-of-mass
+velocity for each chunk. This is done by summing mass*velocity for
+each atom in the chunk and dividing the sum by the total mass of the
+chunk.
+
+Note that only atoms in the specified group contribute to the
+calculation. The :doc:`compute chunk/atom <compute_chunk_atom>` command
+defines its own group; atoms will have a chunk ID = 0 if they are not
+in that group, signifying they are not assigned to a chunk, and will
+thus also not contribute to this calculation. You can specify the
+"all" group for this command if you simply want to include atoms with
+non-zero chunk IDs.
+
+The simplest way to output the results of the compute vcm/chunk
+calculation to a file is to use the :doc:`fix ave/time <fix_ave_time>`
+* region-ID = ID of region to use as simulation domain
+* zero or more keyword/value pairs may be appended
+* keyword = *bond/types* or *angle/types* or *dihedral/types* or *improper/types* or *extra/bond/per/atom* or *extra/angle/per/atom* or *extra/dihedral/per/atom* or *extra/improper/per/atom*
+.. parsed-literal::
+
+ *bond/types* value = # of bond types
+ *angle/types* value = # of angle types
+ *dihedral/types* value = # of dihedral types
+ *improper/types* value = # of improper types
+ *extra/bond/per/atom* value = # of bonds per atom
+ *extra/angle/per/atom* value = # of angles per atom
+ *extra/dihedral/per/atom* value = # of dihedrals per atom
+ *extra/improper/per/atom* value = # of impropers per atom
+ *extra/special/per/atom* value = # of special neighbors per atom
+* group-ID = ID of the group of atoms to be dumped
+* style = *atom* or *atom/mpiio* or *cfg* or *cfg/mpiio* or *dcd* or *xtc* or *xyz* or *xyz/mpiio* or *image* or *movie* or *molfile* or *local* or *custom* or *custom/mpiio*
+* N = dump every this many timesteps
+* file = name of file to write dump info to
+* args = list of arguments for a particular style
+.. parsed-literal::
+
+ *atom* args = none
+ *atom/mpiio* args = none
+ *cfg* args = same as *custom* args, see below
+ *cfg/mpiio* args = same as *custom* args, see below
+ dump ID group-ID style N file color diameter keyword value ...
+
+* ID = user-assigned name for the dump
+* group-ID = ID of the group of atoms to be imaged
+* style = *image* or *movie* = style of dump command (other styles *atom* or *cfg* or *dcd* or *xtc* or *xyz* or *local* or *custom* are discussed on the :doc:`dump <dump>` doc page)
+* N = dump every this many timesteps
+* file = name of file to write image to
+* color = atom attribute that determines color of each atom
+* diameter = atom attribute that determines size of each atom
+* zero or more keyword/value pairs may be appended
+* keyword = *adiam* or *atom* or *bond* or *size* or *view* or *center* or *up* or *zoom* or *persp* or *box* or *axes* or *subbox* or *shiny* or *ssao*
+.. parsed-literal::
+
+ *adiam* value = number = numeric value for atom diameter (distance units)
+ *atom* = yes/no = do or do not draw atoms
+ *bond* values = color width = color and width of bonds
+ color = *atom* or *type* or *none*
+ width = number or *atom* or *type* or *none*
+ number = numeric value for bond width (distance units)
+* one or more keyword/value pairs may be appended
+* these keywords apply to various dump styles
+* keyword = *append* or *buffer* or *element* or *every* or *fileper* or *first* or *flush* or *format* or *image* or *label* or *nfile* or *pad* or *precision* or *region* or *scale* or *sort* or *thresh* or *unwrap*
+.. parsed-literal::
+
+ *append* arg = *yes* or *no*
+ *buffer* arg = *yes* or *no*
+ *element* args = E1 E2 ... EN, where N = # of atom types
+ E1,...,EN = element name, e.g. C or Fe or Ga
+ *every* arg = N
+ N = dump every this many timesteps
+ N can be a variable (see below)
+ *fileper* arg = Np
+ Np = write one file for every this many processors
+ *first* arg = *yes* or *no*
+ *format* arg = C-style format string for one line of output
+ *flush* arg = *yes* or *no*
+ *image* arg = *yes* or *no*
+ *label* arg = string
+ string = character string (e.g. BONDS) to use in header of dump local file
+ *nfile* arg = Nf
+ Nf = write this many files, one from each of Nf processors
+ *pad* arg = Nchar = # of characters to convert timestep to
+ *precision* arg = power-of-10 value from 10 to 1000000
+* group-ID = ID of the group of atoms to be imaged
+* molfile = style of dump command (other styles *atom* or *cfg* or *dcd* or *xtc* or *xyz* or *local* or *custom* are discussed on the :doc:`dump <dump>` doc page)
+* N = dump every this many timesteps
+* file = name of file to write to
+* format = file format to be used
+* path = file path with plugins (optional)
+
+
+Examples
+""""""""
+
+.. parsed-literal::
+
+ dump mf1 all molfile 10 melt1.xml hoomd
+ dump mf2 all molfile 10 melt2-*.pdb pdb .
+ dump mf3 all molfile 50 melt3.xyz xyz .:/home/akohlmey/vmd/plugins/LINUX/molfile
+
+Description
+"""""""""""
+
+Dump a snapshot of atom coordinates and selected additional quantities
+to one or more files every N timesteps in one of several formats.
+Only information for atoms in the specified group is dumped. This
+specific dump style uses molfile plugins that are bundled with the
+`VMD <http://www.ks.uiuc.edu/Research/vmd>`_ molecular visualization and
+analysis program. See :ref:`Section tools <vmd>` of the
+manual and the tools/lmp2vmd/README.txt file for more information
+about support in VMD for reading and visualizing native LAMMPS dump
+files.
+
+Unless the filename contains a * character, the output will be written
+to one single file with the specified format. Otherwise there will be
+one file per snapshot and the * will be replaced by the time step number
+when the snapshot is written.
+
+.. warning::
+
+ Because periodic boundary conditions are enforced only
+ on timesteps when neighbor lists are rebuilt, the coordinates of an
+ atom written to a dump file may be slightly outside the simulation
+ box.
+
+The molfile plugin API has a few restrictions that have to be honored
+by this dump style: the number of atoms must not change, the atoms
+must be sorted, outside of the coordinates no change in atom properties
+(like type, mass, charge) will be recorded.
+
+
+----------
+
+
+The *format* keyword determines what format is used to write out the
+dump. For this to work, LAMMPS must be able to find and load a
+compatible molfile plugin that supports this format. Settings made via
+the :doc:`dump_modify <dump_modify>` command can alter per atom properties
+like element names.
+
+The *path* keyword determines which in directories. This is a "path"
+like other search paths, i.e. it can contain multiple directories
+separated by a colon (or semi-colon on windows). This keyword is
+optional and default to ".", the current directory.
+
+The *unwrap* option of the :doc:`dump_modify <dump_modify>` command allows
+coordinates to be written "unwrapped" by the image flags for each atom.
+Unwrapped means that if the atom has passed through a periodic boundary
+one or more times, the value is printed for what the coordinate would be
+if it had not been wrapped back into the periodic box. Note that these
+coordinates may thus be far outside the box size stored with the
+snapshot.
+
+
+----------
+
+
+Dumps are performed on timesteps that are a multiple of N (including
+timestep 0) and on the last timestep of a minimization if the
+minimization converges. Note that this means a dump will not be
+performed on the initial timestep after the dump command is invoked,
+if the current timestep is not a multiple of N. This behavior can be
+changed via the :doc:`dump_modify first <dump_modify>` command, which can
+be useful if the dump command is invoked after a minimization ended on
+an arbitrary timestep. N can be changed between runs by using the
+:doc:`dump_modify every <dump_modify>` command. The :doc:`dump_modify every <dump_modify>` command also allows a variable to be used to
+determine the sequence of timesteps on which dump files are written.
+
+
+----------
+
+
+Restrictions
+""""""""""""
+
+
+The *molfile* dump style is part of the USER-MOLFILE package. It is
+only enabled if LAMMPS was built with that package. See the :ref:`Making LAMMPS <start_3>` section for more info.
+
+Molfile plugins provide a consistent programming interface to read and
+write file formats commonly used in molecular simulations. The
+USER-MOLFILE package only provides the interface code, not the plugins.
+These can be obtained from a VMD installation which has to match the
+platform that you are using to compile LAMMPS for. By adding plugins
+to VMD, support for new file formats can be added to LAMMPS (or VMD
+or other programs that use them) without having to recompile the
+application itself. The plugins are installed in the directory:
+<VMDHOME>/plugins/<VMDARCH>/molfile
+
+.. note::
+
+ while the programming interface (API) to the plugins is backward
+ compatible, the binary interface (ABI) has been changing over time, so
+ it is necessary to compile this package with the plugin header files
+ from VMD that match the binary plugins. These header files in the
+ directory: <VMDHOME>/plugins/include For convenience, the package ships
+ with a set of header files that are compatible with VMD 1.9 and 1.9.1
+In other words, using one bracket reduces the dimension of the
+quantity once (vector -> scalar, array -> vector). Using two brackets
+reduces the dimension twice (array -> scalar). Thus a command that
+uses scalar fix values as input can also process elements of a vector
+or array.
+
+Note that commands and :doc:`variables <variable>` which use fix
+quantities typically do not allow for all kinds, e.g. a command may
+require a vector of values, not a scalar. This means there is no
+ambiguity about referring to a fix quantity as f_ID even if it
+produces, for example, both a scalar and vector. The doc pages for
+various commands explain the details.
+
+
+----------
+
+
+In LAMMPS, the values generated by a fix can be used in several ways:
+
+* Global values can be output via the :doc:`thermo_style custom <thermo_style>` or :doc:`fix ave/time <fix_ave_time>` command.
+ Or the values can be referenced in a :doc:`variable equal <variable>` or
+ :doc:`variable atom <variable>` command.
+* Per-atom values can be output via the :doc:`dump custom <dump>` command
+ or the :doc:`fix ave/spatial <fix_ave_spatial>` command. Or they can be
+ time-averaged via the :doc:`fix ave/atom <fix_ave_atom>` command or
+ reduced by the :doc:`compute reduce <compute_reduce>` command. Or the
+ per-atom values can be referenced in an :doc:`atom-style variable <variable>`.
+* Local values can be reduced by the :doc:`compute reduce <compute_reduce>` command, or histogrammed by the :doc:`fix ave/histo <fix_ave_histo>` command.
+See this :ref:`howto section <howto_15>` for a summary of
+various LAMMPS output options, many of which involve fixes.
+
+The results of fixes that calculate global quantities can be either
+"intensive" or "extensive" values. Intensive means the value is
+independent of the number of atoms in the simulation,
+e.g. temperature. Extensive means the value scales with the number of
+atoms in the simulation, e.g. total rotational kinetic energy.
+:doc:`Thermodynamic output <thermo_style>` will normalize extensive
+values by the number of atoms in the system, depending on the
+"thermo_modify norm" setting. It will not normalize intensive values.
+If a fix value is accessed in another way, e.g. by a
+:doc:`variable <variable>`, you may want to know whether it is an
+intensive or extensive value. See the doc page for individual fixes
+for further info.
+
+
+----------
+
+
+Each fix style has its own documentation page which describes its
+arguments and what it does, as listed below. Here is an alphabetic
+list of fix styles available in LAMMPS. They are also given in more
+compact form in the fix section of :ref:`this page <cmd_5>`.
+
+There are also additional fix styles (not listed here) submitted by
+users which are included in the LAMMPS distribution. The list of
+these with links to the individual styles are given in the fix section
+of :ref:`this page <cmd_5>`.
+
+There are also additional accelerated fix styles (not listed here)
+included in the LAMMPS distribution for faster performance on CPUs and
+GPUs. The list of these with links to the individual styles are given
+in the fix section of :ref:`this page <cmd_5>`.
+
+* :doc:`adapt <fix_adapt>` - change a simulation parameter over time
+* :doc:`addforce <fix_addforce>` - add a force to each atom
+* :doc:`append/atoms <fix_append_atoms>` - append atoms to a running simulation
+* :doc:`aveforce <fix_aveforce>` - add an averaged force to each atom
+* :doc:`qeq/comb <fix_qeq_comb>` - charge equilibration for COMB potential :doc:`qeq/dynamic <fix_qeq>` - charge equilibration via dynamic method :doc:`qeq/point <fix_qeq>` - charge equilibration via point method :doc:`qeq/shielded <fix_qeq>` - charge equilibration via shielded method :doc:`qeq/slater <fix_qeq>` - charge equilibration via Slater method :doc:`reax/bonds <fix_reax_bonds>` - write out ReaxFF bond information :doc:`recenter <fix_recenter>` - constrain the center-of-mass position of a group of atoms
+* :doc:`restrain <fix_restrain>` - constrain a bond, angle, dihedral
+* :doc:`rigid <fix_rigid>` - constrain one or more clusters of atoms to move as a rigid body with NVE integration
+* :doc:`rigid/nph <fix_rigid>` - constrain one or more clusters of atoms to move as a rigid body with NPH integration
+* :doc:`rigid/npt <fix_rigid>` - constrain one or more clusters of atoms to move as a rigid body with NPT integration
+* :doc:`rigid/nve <fix_rigid>` - constrain one or more clusters of atoms to move as a rigid body with alternate NVE integration
+* :doc:`rigid/nvt <fix_rigid>` - constrain one or more clusters of atoms to move as a rigid body with NVT integration
+* :doc:`rigid/small <fix_rigid>` - constrain many small clusters of atoms to move as a rigid body with NVE integration
+* :doc:`setforce <fix_setforce>` - set the force on each atom
+* :doc:`shake <fix_shake>` - SHAKE constraints on bonds and/or angles
+* :doc:`spring <fix_spring>` - apply harmonic spring force to group of atoms
+* :doc:`spring/rg <fix_spring_rg>` - spring on radius of gyration of group of atoms
+* :doc:`spring/self <fix_spring_self>` - spring from each atom to its origin
+* type = *thermal* or *two_temperature* or *hardy* or *field*
+.. parsed-literal::
+
+ *thermal* = thermal coupling with fields: temperature
+ *two_temperature* = electron-phonon coupling with field: temperature and electron_temperature
+ *hardy* = on-the-fly post-processing using kernel localization functions (see "related" section for possible fields)
+ *field* = on-the-fly post-processing using mesh-based localization functions (see "related" section for possible fields)
+
+* parameter_file = name of the file with material parameters. Note: Neither hardy nor field requires a parameter file
+Examples
+""""""""
+
+.. parsed-literal::
+
+ fix AtC internal atc thermal Ar_thermal.dat
+ fix AtC internal atc two_temperature Ar_ttm.mat
+ fix AtC internal atc hardy
+ fix AtC internal atc field
+
+Description
+"""""""""""
+
+This fix is the beginning to creating a coupled FE/MD simulation and/or an on-the-fly estimation of continuum fields. The coupled versions of this fix do Verlet integration and the post-processing does not. After instantiating this fix, several other fix_modify commands will be needed to set up the problem, e.g. define the finite element mesh and prescribe initial and boundary conditions.
+
+.. image:: JPG/atc_nanotube.jpg
+ :align: center
+
+.. parsed-literal::
+
+ The following coupling example is typical, but non-exhaustive:
+ # ... commands to create and initialize the MD system
+
+.. parsed-literal::
+
+ # initial fix to designate coupling type and group to apply it to
+ # tag group physics material_file
+ fix AtC internal atc thermal Ar_thermal.mat
+
+.. parsed-literal::
+
+ # create a uniform 12 x 2 x 2 mesh that covers region contain the group
+ # nx ny nz region periodicity
+ fix_modify AtC mesh create 12 2 2 mdRegion f p p
+
+.. parsed-literal::
+
+ # specify the control method for the type of coupling
+ # physics control_type
+ fix_modify AtC thermal control flux
+
+.. parsed-literal::
+
+ # specify the initial values for the empirical field "temperature"
+ # field node_group value
+ fix_modify AtC initial temperature all 30
+
+.. parsed-literal::
+
+ # create an output stream for nodal fields
+ # filename output_frequency
+ fix_modify AtC output atc_fe_output 100
+
+.. parsed-literal::
+
+ run 1000
+
+likewise for this post-processing example:
+
+.. parsed-literal::
+
+ # ... commands to create and initialize the MD system
+
+.. parsed-literal::
+
+ # initial fix to designate post-processing and the group to apply it to
+ # no material file is allowed nor required
+ fix AtC internal atc hardy
+
+.. parsed-literal::
+
+ # for hardy fix, specific kernel function (function type and range) to # be used as a localization function
+ fix AtC kernel quartic_sphere 10.0
+
+.. parsed-literal::
+
+ # create a uniform 1 x 1 x 1 mesh that covers region contain the group
+ # with periodicity this effectively creats a system average
+ fix_modify AtC mesh create 1 1 1 box p p p
+
+.. parsed-literal::
+
+ # change from default lagrangian map to eulerian
+ # refreshed every 100 steps
+ fix_modify AtC atom_element_map eulerian 100
+
+.. parsed-literal::
+
+ # start with no field defined
+ # add mass density, potential energy density, stress and temperature
+ fix_modify AtC fields add density energy stress temperature
+
+.. parsed-literal::
+
+ # create an output stream for nodal fields
+ # filename output_frequency
+ fix_modify AtC output nvtFE 100 text
+
+.. parsed-literal::
+
+ run 1000
+
+the mesh's linear interpolation functions can be used as the localization function
+ by using the field option:
+
+fix AtC internal atc field
+
+fix_modify AtC mesh create 1 1 1 box p p p
+
+...
+
+Note coupling and post-processing can be combined in the same simulations using separate fixes.
+
+
+----------
+
+
+Restart, fix_modify, output, run start/stop, minimize info
+No information about this fix is written to :doc:`binary restart files <restart>`. The :doc:`fix_modify <fix_modify>` options relevant to this fix are listed below. No global scalar or vector or per-atom quantities are stored by this fix for access by various :ref:`output commands <howto_15>`. 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>`.
+
+Restrictions
+""""""""""""
+
+
+Thermal and two_temperature (coupling) types use a Verlet time-integration algorithm. The hardy type does not contain its own time-integrator and must be used with a separate fix that does contain one, e.g. nve, nvt, etc.
+
+* Currently,
+* - the coupling is restricted to thermal physics
+* - the FE computations are done in serial on each processor.
+
+Related commands
+""""""""""""""""
+
+After specifying this fix in your input script, several other :doc:`fix_modify <fix_modify>` commands are used to setup the problem, e.g. define the finite element mesh and prescribe initial and boundary conditions.
+Note: a set of example input files with the attendant material files are included with this package
+
+Default
+"""""""
+None
+
+
+----------
+
+
+For detailed exposition of the theory and algorithms please see:
+
+.. _Wagner:
+
+
+
+**(Wagner)** Wagner, GJ; Jones, RE; Templeton, JA; Parks, MA, "An atomistic-to-continuum coupling method for heat transfer in solids." Special Issue of Computer Methods and Applied Mechanics (2008) 197:3351.
+
+.. _Zimmeman2004:
+
+
+
+**(Zimmerman2004)** Zimmerman, JA; Webb, EB; Hoyt, JJ;. Jones, RE; Klein, PA; Bammann, DJ, "Calculation of stress in atomistic simulation." Special Issue of Modelling and Simulation in Materials Science and Engineering (2004), 12:S319.
+
+.. _Zimmerman2010:
+
+
+
+**(Zimmerman2010)** Zimmerman, JA; Jones, RE; Templeton, JA, "A material frame approach for evaluating continuum variables in atomistic simulations." Journal of Computational Physics (2010), 229:2364.
+
+.. _Templeton2010:
+
+
+
+**(Templeton2010)** Templeton, JA; Jones, RE; Wagner, GJ, "Application of a field-based method to spatially varying thermal transport problems in molecular dynamics." Modelling and Simulation in Materials Science and Engineering (2010), 18:085007.
+
+.. _Jones:
+
+
+
+**(Jones)** Jones, RE; Templeton, JA; Wagner, GJ; Olmsted, D; Modine, JA, "Electron transport enhanced molecular dynamics for metals and semi-metals." International Journal for Numerical Methods in Engineering (2010), 83:940.
+
+.. _Templeton2011:
+
+
+
+**(Templeton2011)** Templeton, JA; Jones, RE; Lee, JW; Zimmerman, JA; Wong, BM, "A long-range electric field solver for molecular dynamics based on atomistic-to-continuum modeling." Journal of Chemical Theory and Computation (2011), 7:1736.
+
+.. _Mandadapu:
+
+
+
+**(Mandadapu)** Mandadapu, KK; Templeton, JA; Lee, JW, "Polarization as a field variable from molecular dynamics simulations." Journal of Chemical Physics (2013), 139:054115.
+
+Please refer to the standard finite element (FE) texts, e.g. T.J.R Hughes " The finite element method ", Dover 2003, for the basics of FE simulation.
+* ID, group-ID are documented in :doc:`fix <fix>` command
+* ave/atom = style name of this fix command
+* Nevery = use input values every this many timesteps
+* Nrepeat = # of times to use input values for calculating averages
+* Nfreq = calculate averages every this many timesteps
+ one or more input values can be listed
+* value = x, y, z, vx, vy, vz, fx, fy, fz, c_ID, c_ID[i], f_ID, f_ID[i], v_name
+.. parsed-literal::
+
+ x,y,z,vx,vy,vz,fx,fy,fz = atom attribute (position, velocity, force component)
+ c_ID = per-atom vector calculated by a compute with ID
+ c_ID[I] = Ith column of per-atom array calculated by a compute with ID
+ f_ID = per-atom vector calculated by a fix with ID
+ f_ID[I] = Ith column of per-atom array calculated by a fix with ID
+ v_name = per-atom vector calculated by an atom-style variable with name
+
+
+
+Examples
+""""""""
+
+.. parsed-literal::
+
+ fix 1 all ave/atom 1 100 100 vx vy vz
+ fix 1 all ave/atom 10 20 1000 c_my_stress[1]
+
+Description
+"""""""""""
+
+Use one or more per-atom vectors as inputs every few timesteps, and
+average them atom by atom over longer timescales. The resulting
+per-atom averages can be used by other :ref:`output commands <howto_15>` such as the :doc:`fix ave/spatial <fix_ave_spatial>` or :doc:`dump custom <dump>` commands.
+
+The group specified with the command means only atoms within the group
+have their averages computed. Results are set to 0.0 for atoms not in
+the group.
+
+Each input value can be an atom attribute (position, velocity, force
+component) or can be the result of a :doc:`compute <compute>` or
+:doc:`fix <fix>` or the evaluation of an atom-style
+:doc:`variable <variable>`. In the latter cases, the compute, fix, or
+variable must produce a per-atom vector, not a global quantity or
+local quantity. If you wish to time-average global quantities from a
+compute, fix, or variable, then see the :doc:`fix ave/time <fix_ave_time>` command.
+
+:doc:`Computes <compute>` that produce per-atom vectors or arrays are
+those which have the word *atom* in their style name. See the doc
+pages for individual :doc:`fixes <fix>` to determine which ones produce
+per-atom vectors or arrays. :doc:`Variables <variable>` of style *atom*
+are the only ones that can be used with this fix since they produce
+per-atom vectors.
+
+Each per-atom value of each input vector is averaged independently.
+
+
+----------
+
+
+The *Nevery*, *Nrepeat*, and *Nfreq* arguments specify on what
+timesteps the input values will be used in order to contribute to the
+average. The final averaged quantities are generated on timesteps
+that are a multiple of *Nfreq*. The average is over *Nrepeat*
+quantities, computed in the preceding portion of the simulation every
+*Nevery* timesteps. *Nfreq* must be a multiple of *Nevery* and
+*Nevery* must be non-zero even if *Nrepeat* is 1. Also, the timesteps
+contributing to the average value cannot overlap, i.e. Nfreq >
+(Nrepeat-1)*Nevery is required.
+
+For example, if Nevery=2, Nrepeat=6, and Nfreq=100, then values on
+timesteps 90,92,94,96,98,100 will be used to compute the final average
+on timestep 100. Similarly for timesteps 190,192,194,196,198,200 on
+timestep 200, etc.
+
+
+----------
+
+
+The atom attribute values (x,y,z,vx,vy,vz,fx,fy,fz) are
+self-explanatory. Note that other atom attributes can be used as
+inputs to this fix by using the :doc:`compute property/atom <compute_property_atom>` command and then specifying
+an input value from that compute.
+
+.. warning::
+
+ The x,y,z attributes are values that are re-wrapped
+ inside the periodic box whenever an atom crosses a periodic boundary.
+ Thus if you time average an atom that spends half its time on either
+ side of the periodic box, you will get a value in the middle of the
+ box. If this is not what you want, consider averaging unwrapped
+ coordinates, which can be provided by the :doc:`compute property/atom <compute_property_atom>` command via its xu,yu,zu
+ attributes.
+
+If a value begins with "c_", a compute ID must follow which has been
+previously defined in the input script. If no bracketed term is
+appended, the per-atom vector calculated by the compute is used. If a
+bracketed term containing an index I is appended, the Ith column of
+the per-atom array calculated by the compute is used. Users can also
+write code for their own compute styles and :doc:`add them to LAMMPS <Section_modify>`.
+
+If a value begins with "f_", a fix ID must follow which has been
+previously defined in the input script. If no bracketed term is
+appended, the per-atom vector calculated by the fix is used. If a
+bracketed term containing an index I is appended, the Ith column of
+the per-atom array calculated by the fix is used. Note that some
+fixes only produce their values on certain timesteps, which must be
+compatible with *Nevery*, else an error will result. Users can also
+write code for their own fix styles and :doc:`add them to LAMMPS <Section_modify>`.
+
+If a value begins with "v_", a variable name must follow which has
+been previously defined in the input script as an :doc:`atom-style variable <variable>` Variables of style *atom* can reference
+thermodynamic keywords, or invoke other computes, fixes, or variables
+when they are evaluated, so this is a very general means of generating
+per-atom quantities to time average.
+
+
+----------
+
+
+Restart, fix_modify, output, run start/stop, minimize info
+Use one or more per-atom vectors as inputs every few timesteps, sum
+the values over the atoms in each chunk at each timestep, then average
+the per-chunk values over longer timescales. The resulting chunk
+averages can be used by other :ref:`output commands <howto_15>` such as :doc:`thermo_style custom <thermo_style>`, and can also be written to a file.
+
+In LAMMPS, chunks are collections of atoms defined by a :doc:`compute chunk/atom <compute_chunk_atom>` command, which assigns each atom
+to a single chunk (or no chunk). The ID for this command is specified
+as chunkID. For example, a single chunk could be the atoms in a
+molecule or atoms in a spatial bin. See the :doc:`compute chunk/atom <compute_chunk_atom>` doc page and ":ref:`Section_howto 23 <howto_23>` for details of how chunks can be
+defined and examples of how they can be used to measure properties of
+a system.
+
+Note that only atoms in the specified group contribute to the summing
+and averaging calculations. The :doc:`compute chunk/atom <compute_chunk_atom>` command defines its own group as
+well as an optional region. Atoms will have a chunk ID = 0, meaning
+they belong to no chunk, if they are not in that group or region.
+Thus you can specify the "all" group for this command if you simply
+want to use the chunk definitions provided by chunkID.
+
+Each specified per-atom value can be an atom attribute (position,
+velocity, force component), a mass or number density, or the result of
+a :doc:`compute <compute>` or :doc:`fix <fix>` or the evaluation of an
+atom-style :doc:`variable <variable>`. In the latter cases, the
+compute, fix, or variable must produce a per-atom quantity, not a
+global quantity. Note that the :doc:`compute property/atom <compute_property_atom>` command provides access to
+any attribute defined and stored by atoms. If you wish to
+time-average global quantities from a compute, fix, or variable, then
+see the :doc:`fix ave/time <fix_ave_time>` command.
+
+:doc:`Computes <compute>` that produce per-atom quantities are those
+which have the word *atom* in their style name. See the doc pages for
+individual :doc:`fixes <fix>` to determine which ones produce per-atom
+quantities. :doc:`Variables <variable>` of style *atom* are the only
+ones that can be used with this fix since all other styles of variable
+produce global quantities.
+
+The per-atom values of each input vector are summed and averaged
+independently of the per-atom values in other input vectors.
+
+.. warning::
+
+ This fix works by creating an array of size *Nchunk*
+ by Nvalues on each processor. *Nchunk* is the number of chunks which
+ is defined by the :doc:`compute chunk/atom <doc/compute_chunk_atom>`
+ command. Nvalues is the number of input values specified. Each
+ processor loops over its atoms, tallying its values to the appropriate
+ chunk. Then the entire array is summed across all processors. This
+ means that using a large number of chunks will incur an overhead in
+ memory and computational cost (summing across processors), so be
+ careful to define a reasonable number of chunks.
+
+
+----------
+
+
+The *Nevery*, *Nrepeat*, and *Nfreq* arguments specify on what
+timesteps the input values will be accessed and contribute to the
+average. The final averaged quantities are generated on timesteps
+that are a multiples of *Nfreq*. The average is over *Nrepeat*
+quantities, computed in the preceding portion of the simulation every
+*Nevery* timesteps. *Nfreq* must be a multiple of *Nevery* and
+*Nevery* must be non-zero even if *Nrepeat* is 1. Also, the timesteps
+contributing to the average value cannot overlap, i.e. Nfreq >
+(Nrepeat-1)*Nevery is required.
+
+For example, if Nevery=2, Nrepeat=6, and Nfreq=100, then values on
+timesteps 90,92,94,96,98,100 will be used to compute the final average
+on timestep 100. Similarly for timesteps 190,192,194,196,198,200 on
+timestep 200, etc. If Nrepeat=1 and Nfreq = 100, then no time
+averaging is done; values are simply generated on timesteps
+100,200,etc.
+
+Each input value can also be averaged over the atoms in each chunk.
+The way the averaging is done across the *Nrepeat* timesteps to
+produce output on the *Nfreq* timesteps, and across multiple *Nfreq*
+outputs, is determined by the *norm* and *ave* keyword settings, as
+discussed below.
+
+.. warning::
+
+ To perform per-chunk averaging within a *Nfreq* time
+ window, the number of chunks *Nchunk* defined by the :doc:`compute chunk/atom <compute_chunk_atom>` command must remain constant. If
+ the *ave* keyword is set to *running* or *window* then *Nchunk* must
+ remain constant for the duration of the simulation. This fix forces
+ the chunk/atom compute specified by chunkID to hold *Nchunk* constant
+ for the appropriate time windows, by not allowing it to re-calcualte
+ *Nchunk*, which can also affect how it assigns chunk IDs to atoms.
+ More details are given on the :doc:`compute chunk/atom <compute_chunk_atom>` doc page.
+
+
+----------
+
+
+The atom attribute values (vx,vy,vz,fx,fy,fz) are self-explanatory.
+As noted above, any other atom attributes can be used as input values
+to this fix by using the :doc:`compute property/atom <compute_property_atom>` command and then specifying
+an input value from that compute.
+
+The *density/number* value means the number density is computed for
+each chunk, i.e. number/volume. The *density/mass* value means the
+mass density is computed for each chunk, i.e. total-mass/volume. The
+output values are in units of 1/volume or density (mass/volume). See
+the :doc:`units <units>` command doc page for the definition of density
+for each choice of units, e.g. gram/cm^3. If the chunks defined by
+the :doc:`compute chunk/atom <compute_chunk_atom>` command are spatial
+bins, the volume is the bin volume. Otherwise it is the volume of the
+entire simulation box.
+
+The *temp* value means the temperature is computed for each chunk, by
+the formula KE = DOF/2 k T, where KE = total kinetic energy of the
+chunk of atoms (sum of 1/2 m v^2), DOF = the total number of degrees
+of freedom for all atoms in the chunk, k = Boltzmann constant, and T =
+temperature.
+
+The DOF is calculated as N*adof + cdof, where N = number of atoms in
+the chunk, adof = degrees of freedom per atom, and cdof = degrees of
+freedom per chunk. By default adof = 2 or 3 = dimensionality of
+system, as set via the :doc:`dimension <dimension>` command, and cdof =
+0.0. This gives the usual formula for temperature.
+
+Note that currently this temperature only includes translational
+degrees of freedom for each atom. No rotational degrees of freedom
+are included for finite-size particles. Also no degrees of freedom
+are subtracted for any velocity bias or constraints that are applied,
+such as :doc:`compute temp/partial <compute_temp_partial>`, or :doc:`fix shake <fix_shake>` or :doc:`fix rigid <fix_rigid>`. This is because
+those degrees of freedom (e.g. a constrained bond) could apply to sets
+of atoms that are both included and excluded from a specific chunk,
+and hence the concept is somewhat ill-defined. In some cases, you can
+use the *adof* and *cdof* keywords to adjust the calculated degress of
+freedom appropriately, as explained below.
+
+Also note that a bias can be subtracted from atom velocities before
+they are used in the above formula for KE, by using the *bias*
+keyword. This allows, for example, a thermal temperature to be
+computed after removal of a flow velocity profile.
+
+Note that the per-chunk temperature calculated by this fix and the
+:doc:`compute temp/chunk <compute_temp_chunk>` command can be different.
+The compute calculates the temperature for each chunk for a single
+snapshot. This fix can do that but can also time average those values
+over many snapshots, or it can compute a temperature as if the atoms
+in the chunk on different timesteps were collected together as one set
+of atoms to calculate their temperature. The compute allows the
+center-of-mass velocity of each chunk to be subtracted before
+calculating the temperature; this fix does not.
+
+If a value begins with "c_", a compute ID must follow which has been
+previously defined in the input script. If no bracketed integer is
+appended, the per-atom vector calculated by the compute is used. If a
+bracketed integer is appended, the Ith column of the per-atom array
+calculated by the compute is used. Users can also write code for
+their own compute styles and :doc:`add them to LAMMPS <Section_modify>`.
+
+If a value begins with "f_", a fix ID must follow which has been
+previously defined in the input script. If no bracketed integer is
+appended, the per-atom vector calculated by the fix is used. If a
+bracketed integer is appended, the Ith column of the per-atom array
+calculated by the fix is used. Note that some fixes only produce
+their values on certain timesteps, which must be compatible with
+*Nevery*, else an error results. Users can also write code for their
+own fix styles and :doc:`add them to LAMMPS <Section_modify>`.
+
+If a value begins with "v_", a variable name must follow which has
+been previously defined in the input script. Variables of style
+*atom* can reference thermodynamic keywords and various per-atom
+attributes, or invoke other computes, fixes, or variables when they
+are evaluated, so this is a very general means of generating per-atom
+quantities to average within chunks.
+
+
+----------
+
+
+Additional optional keywords also affect the operation of this fix
+and its outputs.
+
+The *norm* keyword affects how averaging is done for the per-chunk
+values that are output every *Nfreq* timesteps.
+
+It the *norm* setting is *all*, which is the default, a chunk value is
+summed over all atoms in all *Nrepeat* samples, as is the count of
+atoms in the chunk. The averaged output value for the chunk on the
+*Nfreq* timesteps is Total-sum / Total-count. In other words it is an
+average over atoms across the entire *Nfreq* timescale.
+
+If the *norm* setting is *sample*, the chunk value is summed over atoms
+for each sample, as is the count, and an "average sample value" is
+computed for each sample, i.e. Sample-sum / Sample-count. The outuput
+value for the chunk on the *Nfreq* timesteps is the average of the
+*Nrepeat* "average sample values", i.e. the sum of *Nrepeat* "average
+sample values" divided by *Nrepeat*. In other words it is an average
+of an average.
+
+If the *norm* setting is *none*, a similar computation as for the
+*sample* seting is done, except the individual "average sample values"
+are "summed sample values". A summed sample value is simply the chunk
+value summed over atoms in the sample, without dividing by the number
+of atoms in the sample. The outuput value for the chunk on the
+*Nfreq* timesteps is the average of the *Nrepeat* "summed sample
+values", i.e. the sum of *Nrepeat* "summed sample values" divided by
+*Nrepeat*.
+
+The *ave* keyword determines how the per-chunk values produced every
+*Nfreq* steps are averaged with values produced on previous steps that
+were multiples of *Nfreq*, before they are accessed by another output
+command or written to a file.
+
+If the *ave* setting is *one*, which is the default, then the chunk
+values produced on timesteps that are multiples of *Nfreq* are
+independent of each other; they are output as-is without further
+averaging.
+
+If the *ave* setting is *running*, then the chunk values produced on
+timesteps that are multiples of *Nfreq* are summed and averaged in a
+cumulative sense before being output. Each output chunk value is thus
+the average of the chunk value produced on that timestep with all
+preceding values for the same chunk. This running average begins when
+the fix is defined; it can only be restarted by deleting the fix via
+the :doc:`unfix <unfix>` command, or re-defining the fix by
+re-specifying it.
+
+If the *ave* setting is *window*, then the chunk values produced on
+timesteps that are multiples of *Nfreq* are summed and averaged within
+a moving "window" of time, so that the last M values for the same
+chunk are used to produce the output. E.g. if M = 3 and Nfreq = 1000,
+then the output on step 10000 will be the average of the individual
+chunk values on steps 8000,9000,10000. Outputs on early steps will
+average over less than M values if they are not available.
+
+The *bias* keyword specifies the ID of a temperature compute that
+removes a "bias" velocity from each atom, specified as *bias-ID*. It
+is only used when the *temp* value is calculated, to compute the
+thermal temperature of each chunk after the translational kinetic
+energy components have been altered in a prescribed way, e.g. to
+remove a flow velocity profile. See the doc pages for individual
+computes that calculate a temperature to see which ones implement a
+bias.
+
+The *adof* and *cdof* keywords define the values used in the degree of
+freedom (DOF) formula described above for for temperature calculation
+for each chunk. They are only used when the *temp* value is
+calculated. They can be used to calculate a more appropriate
+temperature for some kinds of chunks. Here are 3 examples:
+
+If spatially binned chunks contain some number of water molecules and
+:doc:`fix shake <fix_shake>` is used to make each molecule rigid, then
+you could calculate a temperature with 6 degrees of freedom (DOF) (3
+translational, 3 rotational) per molecule by setting *adof* to 2.0.
+
+If :doc:`compute temp/partial <compute_temp_partial>` is used with the
+*bias* keyword to only allow the x component of velocity to contribute
+to the temperature, then *adof* = 1.0 would be appropriate.
+
+If each chunk consists of a large molecule, with some number of its
+bonds constrained by :doc:`fix shake <fix_shake>` or the entire molecule
+by :doc:`fix rigid/small <fix_rigid>`, *adof* = 0.0 and *cdof* could be
+set to the remaining degrees of freedom for the entire molecule
+(entire chunk in this case), e.g. 6 for 3d, or 3 for 2d, for a rigid
+molecule.
+
+The *file* keyword allows a filename to be specified. Every *Nfreq*
+timesteps, a section of chunk info will be written to a text file in
+the following format. A line with the timestep and number of chunks
+is written. Then one line per chunk is written, containing the chunk
+ID (1-Nchunk), an optional original ID value, optional coordinate
+values for chunks that represent spatial bins, the number of atoms in
+the chunk, and one or more calculated values. More explanation of the
+optional values is given below. The number of values in each line
+corresponds to the number of values specified in the fix ave/chunk
+command. The number of atoms and the value(s) are summed or average
+quantities, as explained above.
+
+The *overwrite* keyword will continuously overwrite the output file
+with the latest output, so that it only contains one timestep worth of
+output. This option can only be used with the *ave running* setting.
+
+The *title1* and *title2* and *title3* keywords allow specification of
+the strings that will be printed as the first 3 lines of the output
+file, assuming the *file* keyword was used. LAMMPS uses default
+values for each of these, so they do not need to be specified.
+ type upper ave running title1 "My correlation data"
+
+Description
+"""""""""""
+
+Use one or more global scalar values as inputs every few timesteps,
+calculate time correlations bewteen them at varying time intervals,
+and average the correlation data over longer timescales. The
+resulting correlation values can be time integrated by
+:doc:`variables <variable>` or used by other :ref:`output commands <howto_15>` such as :doc:`thermo_style custom <thermo_style>`, and can also be written to a file.
+
+The group specified with this command is ignored. However, note that
+specified values may represent calculations performed by computes and
+fixes which store their own "group" definitions.
+
+Each listed value can be the result of a :doc:`compute <compute>` or
+:doc:`fix <fix>` or the evaluation of an equal-style
+:doc:`variable <variable>`. In each case, the compute, fix, or variable
+must produce a global quantity, not a per-atom or local quantity. If
+you wish to spatial- or time-average or histogram per-atom quantities
+from a compute, fix, or variable, then see the :doc:`fix ave/spatial <fix_ave_spatial>`, :doc:`fix ave/atom <fix_ave_atom>`,
+or :doc:`fix ave/histo <fix_ave_histo>` commands. If you wish to sum a
+per-atom quantity into a single global quantity, see the :doc:`compute reduce <compute_reduce>` command.
+
+:doc:`Computes <compute>` that produce global quantities are those which
+do not have the word *atom* in their style name. Only a few
+:doc:`fixes <fix>` produce global quantities. See the doc pages for
+individual fixes for info on which ones produce such values.
+:doc:`Variables <variable>` of style *equal* are the only ones that can
+be used with this fix. Variables of style *atom* cannot be used,
+since they produce per-atom values.
+
+The input values must either be all scalars. What kinds of
+correlations between input values are calculated is determined by the
+*type* keyword as discussed below.
+
+
+----------
+
+
+The *Nevery*, *Nrepeat*, and *Nfreq* arguments specify on what
+timesteps the input values will be used to calculate correlation data.
+The input values are sampled every *Nevery* timesteps. The
+correlation data for the preceding samples is computed on timesteps
+that are a multiple of *Nfreq*. Consider a set of samples from some
+initial time up to an output timestep. The initial time could be the
+beginning of the simulation or the last output time; see the *ave*
+keyword for options. For the set of samples, the correlation value
+Cij is calculated as:
+
+.. parsed-literal::
+
+ Cij(delta) = ave(Vi(t)*Vj(t+delta))
+
+which is the correlation value between input values Vi and Vj,
+separated by time delta. Note that the second value Vj in the pair is
+always the one sampled at the later time. The ave() represents an
+average over every pair of samples in the set that are separated by
+time delta. The maximum delta used is of size (*Nrepeat*-1)**Nevery*.
+Thus the correlation between a pair of input values yields *Nrepeat*
+If the fix ave/histo/weight command is used, exactly two values must
+be specified. If the values are vectors, they must be the same
+length. The first value (a scalar or vector) is what is histogrammed
+into bins, in the same manner the fix ave/histo command operates. The
+second value (a scalar or vector) is used as a "weight". This means
+that instead of each value tallying a "1" to its bin, the
+corresponding weight is tallied. E.g. the Nth entry in the first
+vector tallies the Nth entry (weight) in the second vector.
+
+
+----------
+
+
+The *Nevery*, *Nrepeat*, and *Nfreq* arguments specify on what
+timesteps the input values will be used in order to contribute to the
+histogram. The final histogram is generated on timesteps that are
+multiple of *Nfreq*. It is averaged over *Nrepeat* histograms,
+computed in the preceding portion of the simulation every *Nevery*
+timesteps. *Nfreq* must be a multiple of *Nevery* and *Nevery* must
+be non-zero even if *Nrepeat* is 1. Also, the timesteps contributing
+to the histogram cannot overlap, i.e. Nfreq > (Nrepeat-1)*Nevery is
+required.
+
+For example, if Nevery=2, Nrepeat=6, and Nfreq=100, then input values
+on timesteps 90,92,94,96,98,100 will be used to compute the final
+histogram on timestep 100. Similarly for timesteps
+190,192,194,196,198,200 on timestep 200, etc. If Nrepeat=1 and Nfreq
+= 100, then no time averaging of the histogram is done; a histogram is
+simply generated on timesteps 100,200,etc.
+
+
+----------
+
+
+The atom attribute values (x,y,z,vx,vy,vz,fx,fy,fz) are
+self-explanatory. Note that other atom attributes can be used as
+inputs to this fix by using the :doc:`compute property/atom <compute_property_atom>` command and then specifying
+an input value from that compute.
+
+If a value begins with "c_", a compute ID must follow which has been
+previously defined in the input script. If *mode* = scalar, then if
+no bracketed term is appended, the global scalar calculated by the
+compute is used. If a bracketed term is appended, the Ith element of
+the global vector calculated by the compute is used. If *mode* =
+vector, then if no bracketed term is appended, the global or per-atom
+or local vector calculated by the compute is used. Or if the compute
+calculates an array, all of the columns of the array are used as if
+they had been specified as individual vectors (see description above).
+If a bracketed term is appended, the Ith column of the global or
+per-atom or local array calculated by the compute is used.
+
+Note that there is a :doc:`compute reduce <compute_reduce>` command
+which can sum per-atom quantities into a global scalar or vector which
+can thus be accessed by fix ave/histo. Or it can be a compute defined
+not in your input script, but by :doc:`thermodynamic output <thermo_style>` or other fixes such as :doc:`fix nvt <fix_nh>` or :doc:`fix temp/rescale <fix_temp_rescale>`. See
+the doc pages for these commands which give the IDs of these computes.
+Users can also write code for their own compute styles and :doc:`add them to LAMMPS <Section_modify>`.
+
+If a value begins with "f_", a fix ID must follow which has been
+previously defined in the input script. If *mode* = scalar, then if
+no bracketed term is appended, the global scalar calculated by the fix
+is used. If a bracketed term is appended, the Ith element of the
+global vector calculated by the fix is used. If *mode* = vector, then
+if no bracketed term is appended, the global or per-atom or local
+vector calculated by the fix is used. Or if the fix calculates an
+array, all of the columns of the array are used as if they had been
+specified as individual vectors (see description above). If a
+bracketed term is appended, the Ith column of the global or per-atom
+or local array calculated by the fix is used.
+
+Note that some fixes only produce their values on certain timesteps,
+which must be compatible with *Nevery*, else an error will result.
+Users can also write code for their own fix styles and :doc:`add them to LAMMPS <Section_modify>`.
+
+If a value begins with "v_", a variable name must follow which has
+been previously defined in the input script. If *mode* = scalar, then
+only equal-style variables can be used, which produce a global value.
+If *mode* = vector, then only atom-style variables can be used, which
+produce a per-atom vector. See the :doc:`variable <variable>` command
+for details. Note that variables of style *equal* and *atom* define a
+formula which can reference individual atom properties or
+thermodynamic keywords, or they can invoke other computes, fixes, or
+variables when they are evaluated, so this is a very general means of
+specifying quantities to histogram.
+
+
+----------
+
+
+Additional optional keywords also affect the operation of this fix.
+
+If the *mode* keyword is set to *scalar*, then all input values must
+be global scalars, or elements of global vectors. If the *mode*
+keyword is set to *vector*, then all input values must be global or
+per-atom or local vectors, or columns of global or per-atom or local
+arrays.
+
+The *beyond* keyword determines how input values that fall outside the
+*lo* to *hi* bounds are treated. Values such that *lo* <= value <=
+*hi* are assigned to one bin. Values on a bin boundary are assigned
+to the lower of the 2 bins. If *beyond* is set to *ignore* then
+values < *lo* and values > *hi* are ignored, i.e. they are not binned.
+If *beyond* is set to *end* then values < *lo* are counted in the
+first bin and values > *hi* are counted in the last bin. If *beyond*
+is set to *extend* then two extra bins are created, so that there are
+Nbins+2 total bins. Values < *lo* are counted in the first bin and
+values > *hi* are counted in the last bin (Nbins+1). Values between
+*lo* and *hi* (inclusive) are counted in bins 2 thru Nbins+1. The
+"coordinate" stored and printed for these two extra bins is *lo* and
+*hi*.
+
+The *ave* keyword determines how the histogram produced every *Nfreq*
+steps are averaged with histograms produced on previous steps that
+were multiples of *Nfreq*, before they are accessed by another output
+command or written to a file.
+
+If the *ave* setting is *one*, then the histograms produced on
+timesteps that are multiples of *Nfreq* are independent of each other;
+they are output as-is without further averaging.
+
+If the *ave* setting is *running*, then the histograms produced on
+timesteps that are multiples of *Nfreq* are summed and averaged in a
+cumulative sense before being output. Each bin value in the histogram
+is thus the average of the bin value produced on that timestep with
+all preceding values for the same bin. This running average begins
+when the fix is defined; it can only be restarted by deleting the fix
+via the :doc:`unfix <unfix>` command, or by re-defining the fix by
+re-specifying it.
+
+If the *ave* setting is *window*, then the histograms produced on
+timesteps that are multiples of *Nfreq* are summed within a moving
+"window" of time, so that the last M histograms are used to produce
+the output. E.g. if M = 3 and Nfreq = 1000, then the output on step
+10000 will be the combined histogram of the individual histograms on
+steps 8000,9000,10000. Outputs on early steps will be sums over less
+than M histograms if they are not available.
+
+The *start* keyword specifies what timestep histogramming will begin
+on. The default is step 0. Often input values can be 0.0 at time 0,
+so setting *start* to a larger value can avoid including a 0.0 in
+a running or windowed histogram.
+
+The *file* keyword allows a filename to be specified. Every *Nfreq*
+steps, one histogram is written to the file. This includes a leading
+line that contains the timestep, number of bins, the total count of
+values contributing to the histogram, the count of values that were
+not histogrammed (see the *beyond* keyword), the minimum value
+encountered, and the maximum value encountered. The min/max values
+include values that were not histogrammed. Following the leading
+line, one line per bin is written into the file. Each line contains
+the bin #, the coordinate for the center of the bin (between *lo* and
+*hi*), the count of values in the bin, and the normalized count. The
+normalized count is the bin count divided by the total count (not
+including values not histogrammed), so that the normalized values sum
+to 1.0 across all bins.
+
+The *overwrite* keyword will continuously overwrite the output file
+with the latest output, so that it only contains one timestep worth of
+output. This option can only be used with the *ave running* setting.
+
+The *title1* and *title2* and *title3* keywords allow specification of
+the strings that will be printed as the first 3 lines of the output
+file, assuming the *file* keyword was used. LAMMPS uses default
+values for each of these, so they do not need to be specified.
+Use one or more per-atom vectors as inputs every few timesteps, bin
+their values spatially into 1d, 2d, or 3d bins based on current atom
+coordinates, and average the bin values over longer timescales. The
+resulting bin averages can be used by other :ref:`output commands <howto_15>` such as :doc:`thermo_style custom <thermo_style>`, and can also be written to a file.
+
+The group specified with the command means only atoms within the group
+contribute to bin averages. If the *region* keyword is used, the atom
+must be in both the specified group and the specified geometric
+:doc:`region <region>` in order to contribute to bin averages.
+
+Each listed value can be an atom attribute (position, velocity, force
+component), a mass or number density, or the result of a
+:doc:`compute <compute>` or :doc:`fix <fix>` or the evaluation of an
+atom-style :doc:`variable <variable>`. In the latter cases, the
+compute, fix, or variable must produce a per-atom quantity, not a
+global quantity. If you wish to time-average global quantities from a
+compute, fix, or variable, then see the :doc:`fix ave/time <fix_ave_time>` command.
+
+:doc:`Computes <compute>` that produce per-atom quantities are those
+which have the word *atom* in their style name. See the doc pages for
+individual :doc:`fixes <fix>` to determine which ones produce per-atom
+quantities. :doc:`Variables <variable>` of style *atom* are the only
+ones that can be used with this fix since all other styles of variable
+produce global quantities.
+
+The per-atom values of each input vector are binned and averaged
+independently of the per-atom values in other input vectors.
+
+The size and dimensionality of the bins (1d = layers or slabs, 2d =
+pencils, 3d = boxes) are determined by the *dim*, *origin*, and
+*delta* settings and how many times they are specified (1, 2, or 3).
+See details below.
+
+.. warning::
+
+ This fix works by creating an array of size Nbins by
+ Nvalues on each processor. Nbins is the total number of bins; Nvalues
+ is the number of input values specified. Each processor loops over
+ its atoms, tallying its values to the appropriate bin. Then the
+ entire array is summed across all processors. This means that using a
+ large number of bins (easy to do for 2d or 3d bins) will incur an
+ overhead in memory and computational cost (summing across processors),
+ so be careful to use reasonable numbers of bins.
+
+
+----------
+
+
+The *Nevery*, *Nrepeat*, and *Nfreq* arguments specify on what
+timesteps the input values will be used to bin them and contribute to
+the average. The final averaged quantities are generated on timesteps
+that are a multiples of *Nfreq*. The average is over *Nrepeat*
+quantities, computed in the preceding portion of the simulation every
+*Nevery* timesteps. *Nfreq* must be a multiple of *Nevery* and
+*Nevery* must be non-zero even if *Nrepeat* is 1. Also, the timesteps
+contributing to the average value cannot overlap, i.e. Nfreq >
+(Nrepeat-1)*Nevery is required.
+
+For example, if Nevery=2, Nrepeat=6, and Nfreq=100, then values on
+timesteps 90,92,94,96,98,100 will be used to compute the final average
+on timestep 100. Similarly for timesteps 190,192,194,196,198,200 on
+timestep 200, etc. If Nrepeat=1 and Nfreq = 100, then no time
+averaging is done; values are simply generated on timesteps
+100,200,etc.
+
+
+----------
+
+
+Each per-atom property is also averaged over atoms in each bin. The
+way the averaging is one across the *Nrepeat* timesteps to produce
+output on the *Nfreq* timesteps, and across multiple *Nfreq* outputs,
+is determined by the *norm* and *av* keyword settings, as discussed
+below.
+
+Bins can be 1d layers or slabs, 2d pencils, or 3d boxes. This depends
+on how many times (1, 2, or 3) the *dim*, *origin*, and *delta*
+settings are specified in the fix ave/spatial command. For 2d or 3d
+bins, there is no restriction on specifying dim = x before dim = y, or
+dim = y before dim = z. Bins in a particular *dim* have a bin size in
+that dimension given by *delta*. Every Nfreq steps, when averaging is
+being performed and the per-atom property is calculated for the first
+time, the number of bins and the bin sizes and boundaries are
+computed. Thus if the simulation box changes size during a
+simulation, the number of bins and their boundaries may also change.
+In each dimension, bins are defined relative to a specified *origin*,
+which may be the lower/upper edge of the simulation box in that
+dimension, or its center point, or a specified coordinate value.
+Starting at the origin, sufficient bins are created in both directions
+to completely span the bin extent in that dimension. By default the
+bin extent is the entire simulation box.
+
+The *bound* keyword can be used one or more times to limit the extent
+of bin coverage in specified dimensions, i.e. to only bin a portion of
+the box. If the *lo* setting is *lower* or the *hi* setting is
+*upper*, the bin extent in that direction extends to the box boundary.
+If a numeric value is used for *lo* and/or *hi*, then the bin extent
+in the *lo* or *hi* direction extends only to that value, which is
+assumed to be inside (or at least near) the simulation box boundaries,
+though LAMMPS does not check for this.
+
+On each sampling timestep, each atom is mapped to the bin it currently
+belongs to, based on its current position. Note that the group-ID and
+region keyword can exclude specific atoms from this operation, as
+discussed above. Note that between reneighboring timesteps, atoms can
+move outside the current simulation box. If the box is periodic (in
+that dimension) the atom is remapping into the periodic box for
+purposes of binning. If the box in not periodic, the atom may have
+moved outside the bounds of any bin.
+
+The *discard* keyword determines what is done with any atom which is
+outside the bounds of any bin. If *discard* is set to *yes*, the atom
+will be ignored and not contribute to any bin averages. If *discard*
+is set to *no*, the atom will be counted as if it were in the first or
+last bin in that dimension. If (discard* is set to *mixed*, which is
+the default, it will only be counted in the first or last bin if bins
+extend to the box boundary in that dimension. This is the case if the
+*bound* keyword settings are *lower* and *upper*, which is the
+default. If the *bound* keyword settings are numeric values, then the
+atom will be ignored if it is outside the bounds of any bin. Note
+that in this case, it is possible that the first or last bin extends
+beyond the numeric *bounds* settings, depending on the specified
+*origin*. If this is the case, the atom is only ignored if it is
+outside the first or last bin, not if it is simply outside the numeric
+*bounds* setting.
+
+For orthogonal simulation boxes, the bins are also layers, pencils, or
+boxes aligned with the xyz coordinate axes. For triclinic
+(non-orthogonal) simulation boxes, the bins are so that they are
+parallel to the tilted faces of the simulation box. See :ref:`this section <howto_12>` of the manual for a discussion of
+the geometry of triclinic boxes in LAMMPS. As described there, a
+tilted simulation box has edge vectors a,b,c. In that nomenclature,
+bins in the x dimension have faces with normals in the "b" cross "c"
+direction. Bins in y have faces normal to the "a" cross "c"
+direction. And bins in z have faces normal to the "a" cross "b"
+direction. Note that in order to define the size and position of
+these bins in an unambiguous fashion, the *units* option must be set
+to *reduced* when using a triclinic simulation box, as noted below.
+
+
+----------
+
+
+The atom attribute values (vx,vy,vz,fx,fy,fz) are self-explanatory.
+Note that other atom attributes (including atom postitions x,y,z) can
+be used as inputs to this fix by using the :doc:`compute property/atom <compute_property_atom>` command and then specifying
+an input value from that compute.
+
+The *density/number* value means the number density is computed in
+each bin, i.e. a weighting of 1 for each atom. The *density/mass*
+value means the mass density is computed in each bind, i.e. each atom
+is weighted by its mass. The resulting density is normalized by the
+volume of the bin so that units of number/volume or density are
+output. See the :doc:`units <units>` command doc page for the
+definition of density for each choice of units, e.g. gram/cm^3.
+
+If a value begins with "c_", a compute ID must follow which has been
+previously defined in the input script. If no bracketed integer is
+appended, the per-atom vector calculated by the compute is used. If a
+bracketed integer is appended, the Ith column of the per-atom array
+calculated by the compute is used. Users can also write code for
+their own compute styles and :doc:`add them to LAMMPS <Section_modify>`.
+
+If a value begins with "f_", a fix ID must follow which has been
+previously defined in the input script. If no bracketed integer is
+appended, the per-atom vector calculated by the fix is used. If a
+bracketed integer is appended, the Ith column of the per-atom array
+calculated by the fix is used. Note that some fixes only produce
+their values on certain timesteps, which must be compatible with
+*Nevery*, else an error results. Users can also write code for their
+own fix styles and :doc:`add them to LAMMPS <Section_modify>`.
+
+If a value begins with "v_", a variable name must follow which has
+been previously defined in the input script. Variables of style
+*atom* can reference thermodynamic keywords and various per-atom
+attributes, or invoke other computes, fixes, or variables when they
+are evaluated, so this is a very general means of generating per-atom
+quantities to spatially average.
+
+
+----------
+
+
+Additional optional keywords also affect the operation of this fix.
+The *region*, *bound*, and *discard* keywords were discussed above.
+
+The *norm* keyword affects how averaging is done for the output
+produced every *Nfreq* timesteps. For an *all* setting, a bin
+quantity is summed over all atoms in all *Nrepeat* samples, as is the
+count of atoms in the bin. The printed value for the bin is
+Total-quantity / Total-count. In other words it is an average over
+the entire *Nfreq* timescale.
+
+For a *sample* setting, the bin quantity is summed over atoms for only
+a single sample, as is the count, and a "average sample value" is
+computed, i.e. Sample-quantity / Sample-count. The printed value for
+the bin is the average of the *Nrepeat* "average sample values", In
+other words it is an average of an average.
+
+The *ave* keyword determines how the bin values produced every *Nfreq*
+steps are averaged with bin values produced on previous steps that
+were multiples of *Nfreq*, before they are accessed by another output
+command or written to a file.
+
+If the *ave* setting is *one*, then the bin values produced on
+timesteps that are multiples of *Nfreq* are independent of each other;
+they are output as-is without further averaging.
+
+If the *ave* setting is *running*, then the bin values produced on
+timesteps that are multiples of *Nfreq* are summed and averaged in a
+cumulative sense before being output. Each output bin value is thus
+the average of the bin value produced on that timestep with all
+preceding values for the same bin. This running average begins when
+the fix is defined; it can only be restarted by deleting the fix via
+the :doc:`unfix <unfix>` command, or re-defining the fix by
+re-specifying it.
+
+If the *ave* setting is *window*, then the bin values produced on
+timesteps that are multiples of *Nfreq* are summed and averaged within
+a moving "window" of time, so that the last M values for the same bin
+are used to produce the output. E.g. if M = 3 and Nfreq = 1000, then
+the output on step 10000 will be the average of the individual bin
+values on steps 8000,9000,10000. Outputs on early steps will average
+over less than M values if they are not available.
+
+The *units* keyword determines the meaning of the distance units used
+for the bin size *delta* and for *origin* and *bounds* values if they
+are coordinate value. For orthogonal simulation boxes, any of the 3
+options may be used. For non-orthogonal (triclinic) simulation boxes,
+only the *reduced* option may be used.
+
+A *box* value selects standard distance units as defined by the
+:doc:`units <units>` command, e.g. Angstroms for units = real or metal.
+A *lattice* value means the distance units are in lattice spacings.
+The :doc:`lattice <lattice>` command must have been previously used to
+define the lattice spacing. A *reduced* value means normalized
+unitless values between 0 and 1, which represent the lower and upper
+faces of the simulation box respectively. Thus an *origin* value of
+0.5 means the center of the box in any dimension. A *delta* value of
+0.1 means 10 bins span the box in that dimension.
+
+Consider a non-orthogonal box, with bins that are 1d layers or slabs
+in the x dimension. No matter how the box is tilted, an *origin* of
+0.0 means start layers at the lower "b" cross "c" plane of the
+simulation box and an *origin* of 1.0 means to start layers at the
+upper "b" cross "c" face of the box. A *delta* value of 0.1 means
+there will be 10 layers from 0.0 to 1.0, regardless of the current
+size or shape of the simulation box.
+
+The *file* keyword allows a filename to be specified. Every *Nfreq*
+timesteps, a section of bin info will be written to a text file in the
+following format. A line with the timestep and number of bin is
+written. Then one line per bin is written, containing the bin ID
+(1-N), the coordinate of the center of the bin, the number of atoms
+in the bin, and one or more calculated values. The number of values
+in each line corresponds to the number of values specified in the fix
+ave/spatial command. The number of atoms and the value(s) are average
+quantities. If the value of the *units* keyword is *box* or
+*lattice*, the "coord" is printed in box units. If the value of the
+*units* keyword is *reduced*, the "coord" is printed in reduced units
+(0-1).
+
+The *overwrite* keyword will continuously overwrite the output file
+with the latest output, so that it only contains one timestep worth of
+output. This option can only be used with the *ave running* setting.
+
+The *title1* and *title2* and *title3* keywords allow specification of
+the strings that will be printed as the first 3 lines of the output
+file, assuming the *file* keyword was used. LAMMPS uses default
+values for each of these, so they do not need to be specified.
+
+By default, these header lines are as follows:
+
+.. parsed-literal::
+
+ # Spatial-averaged data for fix ID and group name
+ # Timestep Number-of-bins
+ # Bin Coord1 Coord2 Coord3 Count value1 value2 ...
+
+In the first line, ID and name are replaced with the fix-ID and group
+name. The second line describes the two values that are printed at
+the first of each section of output. In the third line the values are
+replaced with the appropriate fields from the fix ave/spatial command.
+The Coord2 and Coord3 entries in the third line only appear for 2d and
+3d bins respectively. For 1d bins, the word Coord1 is replaced by
+just Coord.
+
+
+----------
+
+
+Restart, fix_modify, output, run start/stop, minimize info
+Use one or more per-atom vectors as inputs every few timesteps, bin
+their values spatially into spherical shells based on current atom
+coordinates, and average the bin values over longer timescales. The
+resulting bin averages can be used by other :ref:`output commands <howto_15>` such as :doc:`thermo_style custom <thermo_style>`, and can also be written to a file.
+
+The group specified with the command means only atoms within the group
+contribute to bin averages. If the *region* keyword is used, the atom
+must be in both the group and the specified geometric
+:doc:`region <region>` in order to contribute to bin averages.
+
+Each listed value can be an atom attribute (position, velocity, force
+component), a mass or number density, or the result of a
+:doc:`compute <compute>` or :doc:`fix <fix>` or the evaluation of an
+atom-style :doc:`variable <variable>`. In the latter cases, the
+compute, fix, or variable must produce a per-atom quantity, not a
+global quantity. If you wish to time-average global quantities from a
+compute, fix, or variable, then see the :doc:`fix ave/time <fix_ave_time>` command.
+
+:doc:`Computes <compute>` that produce per-atom quantities are those
+which have the word *atom* in their style name. See the doc pages for
+individual :doc:`fixes <fix>` to determine which ones produce per-atom
+quantities. :doc:`Variables <variable>` of style *atom* are the only
+ones that can be used with this fix since all other styles of variable
+produce global quantities.
+
+The per-atom values of each input vector are binned and averaged
+independently of the per-atom values in other input vectors.
+
+*Nbins* specifies the number of spherical shells which will be created
+between r_min and r_max centered at (origin_x, origin_y, origin_z).
+
+.. warning::
+
+ This fix works by creating an array of size Nbins by
+ Nvalues on each processor. Nbins is the total number of bins; Nvalues
+ is the number of input values specified. Each processor loops over
+ its atoms, tallying its values to the appropriate bin. Then the
+ entire array is summed across all processors. This means that using a
+ large number of bins will incur an overhead in memory and computational
+ cost (summing across processors), so be careful to use reasonable numbers
+ of bins.
+
+
+----------
+
+
+The *Nevery*, *Nrepeat*, and *Nfreq* arguments specify on what
+timesteps the input values will be used to bin them and contribute to
+the average. The final averaged quantities are generated on timesteps
+that are a multiples of *Nfreq*. The average is over *Nrepeat*
+quantities, computed in the preceding portion of the simulation every
+*Nevery* timesteps. *Nfreq* must be a multiple of *Nevery* and
+*Nevery* must be non-zero even if *Nrepeat* is 1. Also, the timesteps
+contributing to the average value cannot overlap, i.e. Nfreq >
+(Nrepeat-1)*Nevery is required.
+
+For example, if Nevery=2, Nrepeat=6, and Nfreq=100, then values on
+timesteps 90,92,94,96,98,100 will be used to compute the final average
+on timestep 100. Similarly for timesteps 190,192,194,196,198,200 on
+timestep 200, etc. If Nrepeat=1 and Nfreq = 100, then no time
+averaging is done; values are simply generated on timesteps
+100,200,etc.
+
+
+----------
+
+
+The *origin_x*, *origin_y*, and *origin_z* parameters may be specified
+by either a compute or a variable. This allows, for example, the
+center of the spherical bins to be attached to the center of mass of a
+group of atoms. If a variable origin is used and periodic boundary
+conditions are in effect, then the origin will be wrapped across
+periodic boundaries whenever it changes so that it is always inside
+the simulation box.
+
+
+----------
+
+
+The atom attribute values (vx,vy,vz,fx,fy,fz) are self-explanatory.
+Note that other atom attributes (including atom postitions x,y,z) can
+be used as inputs to this fix by using the :doc:`compute property/atom <compute_property_atom>` command and then specifying
+an input value from that compute.
+
+The *density/number* value means the number density is computed in
+each bin, i.e. a weighting of 1 for each atom. The *density/mass*
+value means the mass density is computed in each bin, i.e. each atom
+is weighted by its mass. The resulting density is normalized by the
+volume of the bin so that units of number/volume or density are
+output. See the :doc:`units <units>` command doc page for the
+definition of density for each choice of units, e.g. gram/cm^3.
+The bin volume will always be calculated in box units, independent
+of the use of the *units* keyword in this command.
+
+If a value begins with "c_", a compute ID must follow which has been
+previously defined in the input script. If no bracketed integer is
+appended, the per-atom vector calculated by the compute is used. If a
+bracketed integer is appended, the Ith column of the per-atom array
+calculated by the compute is used. Users can also write code for
+their own compute styles and :doc:`add them to LAMMPS <Section_modify>`.
+
+If a value begins with "f_", a fix ID must follow which has been
+previously defined in the input script. If no bracketed integer is
+appended, the per-atom vector calculated by the fix is used. If a
+bracketed integer is appended, the Ith column of the per-atom array
+calculated by the fix is used. Note that some fixes only produce
+their values on certain timesteps, which must be compatible with
+*Nevery*, else an error results. Users can also write code for their
+own fix styles and :doc:`add them to LAMMPS <Section_modify>`.
+
+If a value begins with "v_", a variable name must follow which has
+been previously defined in the input script. Variables of style
+*atom* can reference thermodynamic keywords and various per-atom
+attributes, or invoke other computes, fixes, or variables when they
+are evaluated, so this is a very general means of generating per-atom
+quantities to spatially average.
+
+
+----------
+
+
+Additional optional keywords also affect the operation of this fix.
+The *region* keyword was discussed above.
+
+The *norm* keyword affects how averaging is done for the output
+produced every *Nfreq* timesteps. For an *all* setting, a bin
+quantity is summed over all atoms in all *Nrepeat* samples, as is the
+count of atoms in the bin. The printed value for the bin is
+Total-quantity / Total-count. In other words it is an average over
+the entire *Nfreq* timescale.
+
+For a *sample* setting, the bin quantity is summed over atoms for only
+a single sample, as is the count, and a "average sample value" is
+computed, i.e. Sample-quantity / Sample-count. The printed value for
+the bin is the average of the *Nrepeat* "average sample values", In
+other words it is an average of an average.
+
+The *ave* keyword determines how the bin values produced every *Nfreq*
+steps are averaged with bin values produced on previous steps that
+were multiples of *Nfreq*, before they are accessed by another output
+command or written to a file.
+
+If the *ave* setting is *one*, then the bin values produced on
+timesteps that are multiples of *Nfreq* are independent of each other;
+they are output as-is without further averaging.
+
+If the *ave* setting is *running*, then the bin values produced on
+timesteps that are multiples of *Nfreq* are summed and averaged in a
+cumulative sense before being output. Each output bin value is thus
+the average of the bin value produced on that timestep with all
+preceding values for the same bin. This running average begins when
+the fix is defined; it can only be restarted by deleting the fix via
+the :doc:`unfix <unfix>` command, or re-defining the fix by
+re-specifying it.
+
+If the *ave* setting is *window*, then the bin values produced on
+timesteps that are multiples of *Nfreq* are summed and averaged within
+a moving "window" of time, so that the last M values for the same bin
+are used to produce the output. E.g. if M = 3 and Nfreq = 1000, then
+the output on step 10000 will be the average of the individual bin
+values on steps 8000,9000,10000. Outputs on early steps will average
+over less than M values if they are not available.
+
+The *units* keyword determines the meaning of the distance units used
+for the sphere origin and the two radial lengths. For orthogonal
+simulation boxes, any of the 3 options may be used. For
+non-orthogonal (triclinic) simulation boxes, only the *reduced* option
+may be used.
+
+A *box* value selects standard distance units as defined by the
+:doc:`units <units>` command, e.g. Angstroms for units = real or metal.
+A *lattice* value means the distance units are in lattice spacings.
+The :doc:`lattice <lattice>` command must have been previously used to
+define the lattice spacing.
+
+.. warning::
+
+ The *lattice* style may only be used if the lattice
+ spacing is the same in each direction.
+
+A *reduced* value means normalized unitless values between 0 and 1,
+which represent the lower and upper faces of the simulation box
+respectively. Thus an *origin* value of 0.5 means the center of the
+box in any dimension.
+
+The *file* keyword allows a filename to be specified. Every *Nfreq*
+timesteps, a section of bin info will be written to a text file in the
+following format. A line with the timestep and number of bin is
+written. Then one line per bin is written, containing the bin ID
+(1-N), the coordinate of the center of the bin, the number of atoms in
+the bin, and one or more calculated values. The number of values in
+each line corresponds to the number of values specified in the fix
+ave/spatial command. The number of atoms and the value(s) are average
+quantities. If the value of the *units* keyword is *box* or
+*lattice*, the "coord" is printed in box units. If the value of the
+*units* keyword is *reduced*, the "coord" is printed in reduced units
+(0-1).
+
+The *overwrite* keyword will continuously overwrite the output file
+with the latest output, so that it only contains one timestep worth of
+output. This option can only be used with the *ave running* setting.
+
+The *title1* and *title2* and *title3* keywords allow specification of
+the strings that will be printed as the first 3 lines of the output
+file, assuming the *file* keyword was used. LAMMPS uses default
+values for each of these, so they do not need to be specified.
+
+By default, these header lines are as follows:
+
+.. parsed-literal::
+
+ # Spatial-averaged data for fix ID and group name
+ # Timestep Number-of-bins
+ # Bin r Count value1 value2 ...
+
+In the first line, ID and name are replaced with the fix-ID and group
+name. The second line describes the two values that are printed at
+the first of each section of output. In the third line the values are
+replaced with the appropriate fields from the fix ave/spatial command.
+The Coord2 and Coord3 entries in the third line only appear for 2d and
+3d bins respectively. For 1d bins, the word Coord1 is replaced by
+just Coord.
+
+
+----------
+
+
+Restart, fix_modify, output, run start/stop, minimize info
+The *Nevery*, *Nrepeat*, and *Nfreq* arguments specify on what
+timesteps the input values will be used in order to contribute to the
+average. The final averaged quantities are generated on timesteps
+that are a mlutiple of *Nfreq*. The average is over *Nrepeat*
+quantities, computed in the preceding portion of the simulation every
+*Nevery* timesteps. *Nfreq* must be a multiple of *Nevery* and
+*Nevery* must be non-zero even if *Nrepeat* is 1. Also, the timesteps
+contributing to the average value cannot overlap, i.e. Nfreq >
+(Nrepeat-1)*Nevery is required.
+
+For example, if Nevery=2, Nrepeat=6, and Nfreq=100, then values on
+timesteps 90,92,94,96,98,100 will be used to compute the final average
+on timestep 100. Similarly for timesteps 190,192,194,196,198,200 on
+timestep 200, etc. If Nrepeat=1 and Nfreq = 100, then no time
+averaging is done; values are simply generated on timesteps
+100,200,etc.
+
+
+----------
+
+
+If a value begins with "c_", a compute ID must follow which has been
+previously defined in the input script. If *mode* = scalar, then if
+no bracketed term is appended, the global scalar calculated by the
+compute is used. If a bracketed term is appended, the Ith element of
+the global vector calculated by the compute is used. If *mode* =
+vector, then if no bracketed term is appended, the global vector
+calculated by the compute is used. Or if the compute calculates an
+array, all of the columns of the global array are used as if they had
+been specified as individual vectors (see description above). If a
+bracketed term is appended, the Ith column of the global array
+calculated by the compute is used.
+
+Note that there is a :doc:`compute reduce <compute_reduce>` command
+which can sum per-atom quantities into a global scalar or vector which
+can thus be accessed by fix ave/time. Or it can be a compute defined
+not in your input script, but by :doc:`thermodynamic output <thermo_style>` or other fixes such as :doc:`fix nvt <fix_nh>` or :doc:`fix temp/rescale <fix_temp_rescale>`. See
+the doc pages for these commands which give the IDs of these computes.
+Users can also write code for their own compute styles and :doc:`add them to LAMMPS <Section_modify>`.
+
+If a value begins with "f_", a fix ID must follow which has been
+previously defined in the input script. If *mode* = scalar, then if
+no bracketed term is appended, the global scalar calculated by the fix
+is used. If a bracketed term is appended, the Ith element of the
+global vector calculated by the fix is used. If *mode* = vector, then
+if no bracketed term is appended, the global vector calculated by the
+fix is used. Or if the fix calculates an array, all of the columns of
+the global array are used as if they had been specified as individual
+vectors (see description above). If a bracketed term is appended, the
+Ith column of the global array calculated by the fix is used.
+
+Note that some fixes only produce their values on certain timesteps,
+which must be compatible with *Nevery*, else an error will result.
+Users can also write code for their own fix styles and :doc:`add them to LAMMPS <Section_modify>`.
+
+If a value begins with "v_", a variable name must follow which has
+been previously defined in the input script. Variables can only be
+used as input for *mode* = scalar. Only equal-style variables can be
+referenced. See the :doc:`variable <variable>` command for details.
+Note that variables of style *equal* define a formula which can
+reference individual atom properties or thermodynamic keywords, or
+they can invoke other computes, fixes, or variables when they are
+evaluated, so this is a very general means of specifying quantities to
+time average.
+
+
+----------
+
+
+Additional optional keywords also affect the operation of this fix.
+
+If the *mode* keyword is set to *scalar*, then all input values must
+be global scalars, or elements of global vectors. If the *mode*
+keyword is set to *vector*, then all input values must be global
+vectors, or columns of global arrays. They can also be global arrays,
+which are converted into a series of global vectors (one per column),
+as explained above.
+
+The *ave* keyword determines how the values produced every *Nfreq*
+steps are averaged with values produced on previous steps that were
+multiples of *Nfreq*, before they are accessed by another output
+command or written to a file.
+
+If the *ave* setting is *one*, then the values produced on timesteps
+that are multiples of *Nfreq* are independent of each other; they are
+output as-is without further averaging.
+
+If the *ave* setting is *running*, then the values produced on
+timesteps that are multiples of *Nfreq* are summed and averaged in a
+cummulative sense before being output. Each output value is thus the
+average of the value produced on that timestep with all preceding
+values. This running average begins when the fix is defined; it can
+only be restarted by deleting the fix via the :doc:`unfix <unfix>`
+command, or by re-defining the fix by re-specifying it.
+
+If the *ave* setting is *window*, then the values produced on
+timesteps that are multiples of *Nfreq* are summed and averaged within
+a moving "window" of time, so that the last M values are used to
+produce the output. E.g. if M = 3 and Nfreq = 1000, then the output
+on step 10000 will be the average of the individual values on steps
+8000,9000,10000. Outputs on early steps will average over less than M
+values if they are not available.
+
+The *start* keyword specifies what timestep averaging will begin on.
+The default is step 0. Often input values can be 0.0 at time 0, so
+setting *start* to a larger value can avoid including a 0.0 in a
+running or windowed average.
+
+The *off* keyword can be used to flag any of the input values. If a
+value is flagged, it will not be time averaged. Instead the most
+recent input value will always be stored and output. This is useful
+if one of more of the inputs produced by a compute or fix or variable
+are effectively constant or are simply current values. E.g. they are
+being written to a file with other time-averaged values for purposes
+of creating well-formatted output.
+
+The *file* keyword allows a filename to be specified. Every *Nfreq*
+steps, one quantity or vector of quantities is written to the file for
+each input value specified in the fix ave/time command. For *mode* =
+scalar, this means a single line is written each time output is
+performed. Thus the file ends up to be a series of lines, i.e. one
+column of numbers for each input value. For *mode* = vector, an array
+of numbers is written each time output is performed. The number of
+rows is the length of the input vectors, and the number of columns is
+the number of values. Thus the file ends up to be a series of these
+array sections.
+
+The *overwrite* keyword will continuously overwrite the output file
+with the latest output, so that it only contains one timestep worth of
+output. This option can only be used with the *ave running* setting.
+
+The *title1* and *title2* and *title3* keywords allow specification of
+the strings that will be printed as the first 2 or 3 lines of the
+output file, assuming the *file* keyword was used. LAMMPS uses
+default values for each of these, so they do not need to be specified.
+
+By default, these header lines are as follows for *mode* = scalar:
+
+.. parsed-literal::
+
+ # Time-averaged data for fix ID
+ # TimeStep value1 value2 ...
+
+In the first line, ID is replaced with the fix-ID. In the second line
+the values are replaced with the appropriate fields from the fix
+ave/time command. There is no third line in the header of the file,
+so the *title3* setting is ignored when *mode* = scalar.
+
+By default, these header lines are as follows for *mode* = vector:
+
+.. parsed-literal::
+
+ # Time-averaged data for fix ID
+ # TimeStep Number-of-rows
+ # Row value1 value2 ...
+
+In the first line, ID is replaced with the fix-ID. The second line
+describes the two values that are printed at the first of each section
+of output. In the third line the values are replaced with the
+appropriate fields from the fix ave/time command.
+
+
+----------
+
+
+Restart, fix_modify, output, run start/stop, minimize info
+* ID, group-ID are documented in :doc:`fix <fix>` command
+* box/relax = style name of this fix command
+.. parsed-literal::
+
+ one or more keyword value pairs may be appended
+ keyword = *iso* or *aniso* or *tri* or *x* or *y* or *z* or *xy* or *yz* or *xz* or *couple* or *nreset* or *vmax* or *dilate* or *scaleyz* or *scalexz* or *scalexy* or *fixedpoint*
+ *iso* or *aniso* or *tri* value = Ptarget = desired pressure (pressure units)
+ *x* or *y* or *z* or *xy* or *yz* or *xz* value = Ptarget = desired pressure (pressure units)
+ *couple* = *none* or *xyz* or *xy* or *yz* or *xz*
+ *nreset* value = reset reference cell every this many minimizer iterations
+ *vmax* value = fraction = max allowed volume change in one iteration
+ *dilate* value = *all* or *partial*
+ *scaleyz* value = *yes* or *no* = scale yz with lz
+ *scalexz* value = *yes* or *no* = scale xz with lz
+ *scalexy* value = *yes* or *no* = scale xy with ly
+ *fixedpoint* values = x y z
+ x,y,z = perform relaxation dilation/contraction around this point (distance units)
+ fix ID group-ID deform N parameter args ... keyword value ...
+
+* ID, group-ID are documented in :doc:`fix <fix>` command
+* deform = style name of this fix command
+* N = perform box deformation every this many timesteps
+* one or more parameter/arg pairs may be appended
+.. parsed-literal::
+
+ parameter = *x* or *y* or *z* or *xy* or *xz* or *yz*
+ *x*, *y*, *z* args = style value(s)
+ style = *final* or *delta* or *scale* or *vel* or *erate* or *trate* or *volume* or *wiggle* or *variable*
+ *final* values = lo hi
+ lo hi = box boundaries at end of run (distance units)
+ *delta* values = dlo dhi
+ dlo dhi = change in box boundaries at end of run (distance units)
+ *scale* values = factor
+ factor = multiplicative factor for change in box length at end of run
+ *vel* value = V
+ V = change box length at this velocity (distance/time units),
+ effectively an engineering strain rate
+ *erate* value = R
+ R = engineering strain rate (1/time units)
+ *trate* value = R
+ R = true strain rate (1/time units)
+ *volume* value = none = adjust this dim to preserve volume of system
+ *wiggle* values = A Tp
+ A = amplitude of oscillation (distance units)
+ Tp = period of oscillation (time units)
+ *variable* values = v_name1 v_name2
+ v_name1 = variable with name1 for box length change as function of time
+ v_name2 = variable with name2 for change rate as function of time
+ *xy*, *xz*, *yz* args = style value
+ style = *final* or *delta* or *vel* or *erate* or *trate* or *wiggle*
+ *final* value = tilt
+ tilt = tilt factor at end of run (distance units)
+ *delta* value = dtilt
+ dtilt = change in tilt factor at end of run (distance units)
+ *vel* value = V
+ V = change tilt factor at this velocity (distance/time units),
+ effectively an engineering shear strain rate
+ *erate* value = R
+ R = engineering shear strain rate (1/time units)
+ *trate* value = R
+ R = true shear strain rate (1/time units)
+ *wiggle* values = A Tp
+ A = amplitude of oscillation (distance units)
+ Tp = period of oscillation (time units)
+ *variable* values = v_name1 v_name2
+ v_name1 = variable with name1 for tilt change as function of time
+ v_name2 = variable with name2 for change rate as function of time
+
+* zero or more keyword/value pairs may be appended
+* keyword = *remap* or *flip* or *units*
+.. parsed-literal::
+
+ *remap* value = *x* or *v* or *none*
+ x = remap coords of atoms in group into deforming box
+ v = remap velocities of all atoms when they cross periodic boundaries
+ none = no remapping of x or v
+ *flip* value = *yes* or *no*
+ allow or disallow box flips when it becomes highly skewed
+ *units* value = *lattice* or *box*
+ lattice = distances are defined in lattice units
+ box = distances are defined in simulation box units
+
+
+
+Examples
+""""""""
+
+.. parsed-literal::
+
+ fix 1 all deform 1 x final 0.0 9.0 z final 0.0 5.0 units box
+ fix 1 all deform 1 x trate 0.1 y volume z volume
+ fix 1 all deform 1 xy erate 0.001 remap v
+ fix 1 all deform 10 y delta -0.5 0.5 xz vel 1.0
+
+Description
+"""""""""""
+
+Change the volume and/or shape of the simulation box during a dynamics
+run. Orthogonal simulation boxes have 3 adjustable parameters
+(x,y,z). Triclinic (non-orthogonal) simulation boxes have 6
+adjustable parameters (x,y,z,xy,xz,yz). Any or all of them can be
+adjusted independently and simultaneously by this command. This fix
+can be used to perform non-equilibrium MD (NEMD) simulations of a
+continuously strained system. See the :doc:`fix nvt/sllod <fix_nvt_sllod>` and :doc:`compute temp/deform <compute_temp_deform>` commands for more details.
+
+For the *x*, *y*, *z* parameters, the associated dimension cannot be
+shrink-wrapped. For the *xy*, *yz*, *xz* parameters, the associated
+2nd dimension cannot be shrink-wrapped. Dimensions not varied by this
+command can be periodic or non-periodic. Dimensions corresponding to
+unspecified parameters can also be controlled by a :doc:`fix npt <fix_nh>` or :doc:`fix nph <fix_nh>` command.
+
+The size and shape of the simulation box at the beginning of the
+simulation run were either specified by the
+:doc:`create_box <create_box>` or :doc:`read_data <read_data>` or
+:doc:`read_restart <read_restart>` command used to setup the simulation
+initially if it is the first run, or they are the values from the end
+of the previous run. The :doc:`create_box <create_box>`, :doc:`read data <read_data>`, and :doc:`read_restart <read_restart>` commands
+specify whether the simulation box is orthogonal or non-orthogonal
+(triclinic) and explain the meaning of the xy,xz,yz tilt factors. If
+fix deform changes the xy,xz,yz tilt factors, then the simulation box
+must be triclinic, even if its initial tilt factors are 0.0.
+
+As described below, the desired simulation box size and shape at the
+end of the run are determined by the parameters of the fix deform
+command. Every Nth timestep during the run, the simulation box is
+expanded, contracted, or tilted to ramped values between the initial
+and final values.
+
+
+----------
+
+
+For the *x*, *y*, and *z* parameters, this is the meaning of their
+styles and values.
+
+The *final*, *delta*, *scale*, *vel*, and *erate* styles all change
+the specified dimension of the box via "constant displacement" which
+is effectively a "constant engineering strain rate". This means the
+box dimension changes linearly with time from its initial to final
+value.
+
+For style *final*, the final lo and hi box boundaries of a dimension
+are specified. The values can be in lattice or box distance units.
+See the discussion of the units keyword below.
+
+For style *delta*, plus or minus changes in the lo/hi box boundaries
+of a dimension are specified. The values can be in lattice or box
+distance units. See the discussion of the units keyword below.
+
+For style *scale*, a multiplicative factor to apply to the box length
+of a dimension is specified. For example, if the initial box length
+is 10, and the factor is 1.1, then the final box length will be 11. A
+factor less than 1.0 means compression.
+
+For style *vel*, a velocity at which the box length changes is
+specified in units of distance/time. This is effectively a "constant
+engineering strain rate", where rate = V/L0 and L0 is the initial box
+length. The distance can be in lattice or box distance units. See
+the discussion of the units keyword below. For example, if the
+initial box length is 100 Angstroms, and V is 10 Angstroms/psec, then
+after 10 psec, the box length will have doubled. After 20 psec, it
+will have tripled.
+
+The *erate* style changes a dimension of the the box at a "constant
+engineering strain rate". The units of the specified strain rate are
+1/time. See the :doc:`units <units>` command for the time units
+associated with different choices of simulation units,
+e.g. picoseconds for "metal" units). Tensile strain is unitless and
+is defined as delta/L0, where L0 is the original box length and delta
+is the change relative to the original length. The box length L as a
+function of time will change as
+
+.. parsed-literal::
+
+ L(t) = L0 (1 + erate*dt)
+
+where dt is the elapsed time (in time units). Thus if *erate* R is
+specified as 0.1 and time units are picoseconds, this means the box
+length will increase by 10% of its original length every picosecond.
+I.e. strain after 1 psec = 0.1, strain after 2 psec = 0.2, etc. R =
+-0.01 means the box length will shrink by 1% of its original length
+every picosecond. Note that for an "engineering" rate the change is
+based on the original box length, so running with R = 1 for 10
+picoseconds expands the box length by a factor of 11 (strain of 10),
+which is different that what the *trate* style would induce.
+
+The *trate* style changes a dimension of the box at a "constant true
+strain rate". Note that this is not an "engineering strain rate", as
+the other styles are. Rather, for a "true" rate, the rate of change
+is constant, which means the box dimension changes non-linearly with
+time from its initial to final value. The units of the specified
+strain rate are 1/time. See the :doc:`units <units>` command for the
+time units associated with different choices of simulation units,
+e.g. picoseconds for "metal" units). Tensile strain is unitless and
+is defined as delta/L0, where L0 is the original box length and delta
+is the change relative to the original length.
+
+The box length L as a function of time will change as
+
+.. parsed-literal::
+
+ L(t) = L0 exp(trate*dt)
+
+where dt is the elapsed time (in time units). Thus if *trate* R is
+specified as ln(1.1) and time units are picoseconds, this means the
+box length will increase by 10% of its current (not original) length
+every picosecond. I.e. strain after 1 psec = 0.1, strain after 2 psec
+= 0.21, etc. R = ln(2) or ln(3) means the box length will double or
+triple every picosecond. R = ln(0.99) means the box length will
+shrink by 1% of its current length every picosecond. Note that for a
+"true" rate the change is continuous and based on the current length,
+so running with R = ln(2) for 10 picoseconds does not expand the box
+length by a factor of 11 as it would with *erate*, but by a factor of
+1024 since the box length will double every picosecond.
+
+Note that to change the volume (or cross-sectional area) of the
+simulation box at a constant rate, you can change multiple dimensions
+via *erate* or *trate*. E.g. to double the box volume in a picosecond
+picosecond, you could set "x erate M", "y erate M", "z erate M", with
+M = pow(2,1/3) - 1 = 0.26, since if each box dimension grows by 26%,
+the box volume doubles. Or you could set "x trate M", "y trate M", "z
+trate M", with M = ln(1.26) = 0.231, and the box volume would double
+every picosecond.
+
+The *volume* style changes the specified dimension in such a way that
+the box volume remains constant while other box dimensions are changed
+explicitly via the styles discussed above. For example, "x scale 1.1
+y scale 1.1 z volume" will shrink the z box length as the x,y box
+lengths increase, to keep the volume constant (product of x,y,z
+lengths). If "x scale 1.1 z volume" is specified and parameter *y* is
+unspecified, then the z box length will shrink as x increases to keep
+the product of x,z lengths constant. If "x scale 1.1 y volume z
+volume" is specified, then both the y,z box lengths will shrink as x
+increases to keep the volume constant (product of x,y,z lengths). In
+this case, the y,z box lengths shrink so as to keep their relative
+aspect ratio constant.
+
+For solids or liquids, note that when one dimension of the box is
+expanded via fix deform (i.e. tensile strain), it may be physically
+undesirable to hold the other 2 box lengths constant (unspecified by
+fix deform) since that implies a density change. Using the *volume*
+style for those 2 dimensions to keep the box volume constant may make
+more physical sense, but may also not be correct for materials and
+potentials whose Poisson ratio is not 0.5. An alternative is to use
+:doc:`fix npt aniso <fix_nh>` with zero applied pressure on those 2
+dimensions, so that they respond to the tensile strain dynamically.
+
+The *wiggle* style oscillates the specified box length dimension
+sinusoidally with the specified amplitude and period. I.e. the box
+length L as a function of time is given by
+
+.. parsed-literal::
+
+ L(t) = L0 + A sin(2*pi t/Tp)
+
+where L0 is its initial length. If the amplitude A is a positive
+number the box initially expands, then contracts, etc. If A is
+negative then the box initially contracts, then expands, etc. The
+amplitude can be in lattice or box distance units. See the discussion
+of the units keyword below.
+
+The *variable* style changes the specified box length dimension by
+evaluating a variable, which presumably is a function of time. The
+variable with *name1* must be an :doc:`equal-style variable <variable>`
+and should calculate a change in box length in units of distance.
+Note that this distance is in box units, not lattice units; see the
+discussion of the *units* keyword below. The formula associated with
+variable *name1* can reference the current timestep. Note that it
+should return the "change" in box length, not the absolute box length.
+This means it should evaluate to 0.0 when invoked on the initial
+timestep of the run following the definition of fix deform. It should
+evaluate to a value > 0.0 to dilate the box at future times, or a
+value < 0.0 to compress the box.
+
+The variable *name2* must also be an :doc:`equal-style variable <variable>` and should calculate the rate of box length
+change, in units of distance/time, i.e. the time-derivative of the
+*name1* variable. This quantity is used internally by LAMMPS to reset
+atom velocities when they cross periodic boundaries. It is computed
+internally for the other styles, but you must provide it when using an
+arbitrary variable.
+
+Here is an example of using the *variable* style to perform the same
+box deformation as the *wiggle* style formula listed above, where we
+ fix 2 all deform 1 xy variable v_displace v_rate remap v
+
+
+----------
+
+
+All of the tilt styles change the xy, xz, yz tilt factors during a
+simulation. In LAMMPS, tilt factors (xy,xz,yz) for triclinic boxes
+are normally bounded by half the distance of the parallel box length.
+See the discussion of the *flip* keyword below, to allow this bound to
+be exceeded, if desired.
+
+For example, if xlo = 2 and xhi = 12, then the x box length is 10 and
+the xy tilt factor must be between -5 and 5. Similarly, both xz and
+yz must be between -(xhi-xlo)/2 and +(yhi-ylo)/2. Note that this is
+not a limitation, since if the maximum tilt factor is 5 (as in this
+example), then configurations with tilt = ..., -15, -5, 5, 15, 25,
+... are all equivalent.
+
+To obey this constraint and allow for large shear deformations to be
+applied via the *xy*, *xz*, or *yz* parameters, the following
+algorithm is used. If *prd* is the associated parallel box length (10
+in the example above), then if the tilt factor exceeds the accepted
+range of -5 to 5 during the simulation, then the box is flipped to the
+other limit (an equivalent box) and the simulation continues. Thus
+for this example, if the initial xy tilt factor was 0.0 and "xy final
+100.0" was specified, then during the simulation the xy tilt factor
+would increase from 0.0 to 5.0, the box would be flipped so that the
+tilt factor becomes -5.0, the tilt factor would increase from -5.0 to
+5.0, the box would be flipped again, etc. The flip occurs 10 times
+and the final tilt factor at the end of the simulation would be 0.0.
+During each flip event, atoms are remapped into the new box in the
+appropriate manner.
+
+The one exception to this rule is if the 1st dimension in the tilt
+factor (x for xy) is non-periodic. In that case, the limits on the
+tilt factor are not enforced, since flipping the box in that dimension
+does not change the atom positions due to non-periodicity. In this
+mode, if you tilt the system to extreme angles, the simulation will
+simply become inefficient due to the highly skewed simulation box.
+
+
+----------
+
+
+Each time the box size or shape is changed, the *remap* keyword
+determines whether atom positions are remapped to the new box. If
+*remap* is set to *x* (the default), atoms in the fix group are
+remapped; otherwise they are not. Note that their velocities are not
+changed, just their positions are altered. If *remap* is set to *v*,
+then any atom in the fix group that crosses a periodic boundary will
+have a delta added to its velocity equal to the difference in
+velocities between the lo and hi boundaries. Note that this velocity
+difference can include tilt components, e.g. a delta in the x velocity
+when an atom crosses the y periodic boundary. If *remap* is set to
+*none*, then neither of these remappings take place.
+
+Conceptually, setting *remap* to *x* forces the atoms to deform via an
+affine transformation that exactly matches the box deformation. This
+setting is typically appropriate for solids. Note that though the
+atoms are effectively "moving" with the box over time, it is not due
+to their having a velocity that tracks the box change, but only due to
+the remapping. By contrast, setting *remap* to *v* is typically
+appropriate for fluids, where you want the atoms to respond to the
+change in box size/shape on their own and acquire a velocity that
+matches the box change, so that their motion will naturally track the
+box without explicit remapping of their coordinates.
+
+.. warning::
+
+ When non-equilibrium MD (NEMD) simulations are
+ performed using this fix, the option "remap v" should normally be
+ used. This is because :doc:`fix nvt/sllod <fix_nvt_sllod>` adjusts the
+ atom positions and velocities to induce a velocity profile that
+ matches the changing box size/shape. Thus atom coordinates should NOT
+ be remapped by fix deform, but velocities SHOULD be when atoms cross
+ periodic boundaries, since that is consistent with maintaining the
+ velocity profile already created by fix nvt/sllod. LAMMPS will warn
+ you if the *remap* setting is not consistent with fix nvt/sllod.
+
+.. warning::
+
+ For non-equilibrium MD (NEMD) simulations using "remap
+ v" it is usually desirable that the fluid (or flowing material,
+ e.g. granular particles) stream with a velocity profile consistent
+ with the deforming box. As mentioned above, using a thermostat such
+ as :doc:`fix nvt/sllod <fix_nvt_sllod>` or :doc:`fix lavgevin <doc/fix_langevin>` (with a bias provided by :doc:`compute temp/deform <compute_temp_deform>`), will typically accomplish
+ that. If you do not use a thermostat, then there is no driving force
+ pushing the atoms to flow in a manner consistent with the deforming
+ box. E.g. for a shearing system the box deformation velocity may vary
+ from 0 at the bottom to 10 at the top of the box. But the stream
+ velocity profile of the atoms may vary from -5 at the bottom to +5 at
+ the top. You can monitor these effects using the :doc:`fix ave/spatial <fix_ave_spatial>`, :doc:`compute temp/deform <compute_temp_deform>`, and :doc:`compute temp/profile <compute_temp_profile>` commands. One way to induce
+ atoms to stream consistent with the box deformation is to give them an
+ initial velocity profile, via the :doc:`velocity ramp <velocity>`
+ command, that matches the box deformation rate. This also typically
+ helps the system come to equilibrium more quickly, even if a
+ thermostat is used.
+
+.. warning::
+
+ If a :doc:`fix rigid <fix_rigid>` is defined for rigid
+ bodies, and *remap* is set to *x*, then the center-of-mass coordinates
+ of rigid bodies will be remapped to the changing simulation box. This
+ will be done regardless of whether atoms in the rigid bodies are in
+ the fix deform group or not. The velocity of the centers of mass are
+ not remapped even if *remap* is set to *v*, since :doc:`fix nvt/sllod <fix_nvt_sllod>` does not currently do anything special
+ for rigid particles. If you wish to perform a NEMD simulation of
+ rigid particles, you can either thermostat them independently or
+ include a background fluid and thermostat the fluid via :doc:`fix nvt/sllod <fix_nvt_sllod>`.
+
+The *flip* keyword allows the tilt factors for a triclinic box to
+exceed half the distance of the parallel box length, as discussed
+above. If the *flip* value is set to *yes*, the bound is enforced by
+flipping the box when it is exceeded. If the *flip* value is set to
+*no*, the tilt will continue to change without flipping. Note that if
+you apply large deformations, this means the box shape can tilt
+dramatically LAMMPS will run less efficiently, due to the large volume
+of communication needed to acquire ghost atoms around a processor's
+irregular-shaped sub-domain. For extreme values of tilt, LAMMPS may
+also lose atoms and generate an error.
+
+The *units* keyword determines the meaning of the distance units used
+to define various arguments. A *box* value selects standard distance
+units as defined by the :doc:`units <units>` command, e.g. Angstroms for
+units = real or metal. A *lattice* value means the distance units are
+in lattice spacings. The :doc:`lattice <lattice>` command must have
+been previously used to define the lattice spacing. Note that the
+units choice also affects the *vel* style parameters since it is
+defined in terms of distance/time. Also note that the units keyword
+does not affect the *variable* style. You should use the *xlat*,
+*ylat*, *zlat* keywords of the :doc:`thermo_style <thermo_style>`
+command if you want to include lattice spacings in a variable formula.
+
+Restart, fix_modify, output, run start/stop, minimize info
+ fix ID group-ID deposit N type M seed keyword values ...
+
+* ID, group-ID are documented in :doc:`fix <fix>` command
+* deposit = style name of this fix command
+* N = # of atoms or molecules to insert
+* type = atom type to assign to inserted atoms (offset for moleclue insertion)
+* M = insert a single atom or molecule every M steps
+* seed = random # seed (positive integer)
+* one or more keyword/value pairs may be appended to args
+* keyword = *region* or *id* or *global* or *local* or *near* or *attempt* or *rate* or *vx* or *vy* or *vz* or *mol* or *rigid* or *shake* or *units*
+.. parsed-literal::
+
+ *region* value = region-ID
+ region-ID = ID of region to use as insertion volume
+ *id* value = *max* or *next*
+ max = atom ID for new atom(s) is max ID of all current atoms plus one
+ next = atom ID for new atom(s) increments by one for every deposition
+ *global* values = lo hi
+ lo,hi = put new atom/molecule a distance lo-hi above all other atoms (distance units)
+ *local* values = lo hi delta
+ lo,hi = put new atom/molecule a distance lo-hi above any nearby atom beneath it (distance units)
+ delta = lateral distance within which a neighbor is considered "nearby" (distance units)
+ *near* value = R
+ R = only insert atom/molecule if further than R from existing particles (distance units)
+ *attempt* value = Q
+ Q = attempt a single insertion up to Q times
+ *rate* value = V
+ V = z velocity (y in 2d) at which insertion volume moves (velocity units)
+ *vx* values = vxlo vxhi
+ vxlo,vxhi = range of x velocities for inserted atom/molecule (velocity units)
+ *vy* values = vylo vyhi
+ vylo,vyhi = range of y velocities for inserted atom/molecule (velocity units)
+ *vz* values = vzlo vzhi
+ vzlo,vzhi = range of z velocities for inserted atom/molecule (velocity units)
+ *target* values = tx ty tz
+ tx,ty,tz = location of target point (distance units)
+ *mol* value = template-ID
+ template-ID = ID of molecule template specified in a separate :doc:`molecule <molecule>` command
+ *molfrac* values = f1 f2 ... fN
+ f1 to fN = relative probability of creating each of N molecules in template-ID
+ *rigid* value = fix-ID
+ fix-ID = ID of :doc:`fix rigid/small <fix_rigid>` command
+ *shake* value = fix-ID
+ fix-ID = ID of :doc:`fix shake <fix_shake>` command
+ *units* value = *lattice* or *box*
+ lattice = the geometry is defined in lattice units
+ box = the geometry is defined in simulation box units
+
+
+
+Examples
+""""""""
+
+.. parsed-literal::
+
+ fix 3 all deposit 1000 2 100 29494 region myblock local 1.0 1.0 1.0 units box
+ fix 2 newatoms deposit 10000 1 500 12345 region disk near 2.0 vz -1.0 -0.8
+ fix 4 sputter deposit 1000 2 500 12235 region sphere vz -1.0 -1.0 target 5.0 5.0 0.0 units lattice
+
+Description
+"""""""""""
+
+Insert a single atom or molecule into the simulation domain every M
+timesteps until N atoms or molecules have been inserted. This is
+useful for simulating deposition onto a surface. For the remainder of
+this doc page, a single inserted atom or molecule is referred to as a
+"particle".
+
+If inserted particles are individual atoms, they are assigned the
+specified atom type. If they are molecules, the type of each atom in
+the inserted molecule is specified in the file read by the
+:doc:`molecule <molecule>` command, and those values are added to the
+specified atom type. E.g. if the file specifies atom types 1,2,3, and
+those are the atom types you want for inserted molecules, then specify
+*type* = 0. If you specify *type* = 2, the in the inserted molecule
+will have atom types 3,4,5.
+
+All atoms in the inserted particle are assigned to two groups: the
+default group "all" and the group specified in the fix deposit command
+(which can also be "all").
+
+If you are computing temperature values which include inserted
+particles, you will want to use the
+:doc:`compute_modify <compute_modify>` dynamic option, which insures the
+current number of atoms is used as a normalizing factor each time the
+temperature is computed.
+
+Care must be taken that inserted particles are not too near existing
+atoms, using the options described below. When inserting particles
+above a surface in a non-periodic box (see the
+:doc:`boundary <boundary>` command), the possibility of a particle
+escaping the surface and flying upward should be considered, since the
+particle may be lost or the box size may grow infinitely large. A
+:doc:`fix wall/reflect <fix_wall_reflect>` command can be used to
+prevent this behavior. Note that if a shrink-wrap boundary is used,
+it is OK to insert the new particle outside the box, however the box
+will immediately be expanded to include the new particle. When
+simulating a sputtering experiment it is probably more realistic to
+ignore those atoms using the :doc:`thermo_modify <thermo_modify>`
+command with the *lost ignore* option and a fixed
+:doc:`boundary <boundary>`.
+
+The fix deposit command must use the *region* keyword to define an
+insertion volume. The specified region must have been previously
+defined with a :doc:`region <region>` command. It must be defined with
+side = *in*.
+
+.. warning::
+
+ LAMMPS checks that the specified region is wholly
+ inside the simulation box. It can do this correctly for orthonormal
+ simulation boxes. However for :ref:`triclinic boxes <howto_12>`, it only tests against the larger
+ orthonormal box that bounds the tilted simulation box. If the
+ specified region includes volume outside the tilted box, then an
+ insertion will likely fail, leading to a "lost atoms" error. Thus for
+ triclinic boxes you should insure the specified region is wholly
+ inside the simulation box.
+
+Individual atoms are inserted, unless the *mol* keyword is used. It
+specifies a *template-ID* previously defined using the
+:doc:`molecule <molecule>` command, which reads files that define one or
+more molecules. The coordinates, atom types, charges, etc, as well as
+any bond/angle/etc and special neighbor information for the molecule
+can be specified in the molecule file. See the
+:doc:`molecule <molecule>` command for details. The only settings
+required to be in each file are the coordinates and types of atoms in
+the molecule.
+
+If the molecule template contains more than one molecule, the relative
+probability of depositing each molecule can be specified by the
+*molfrac* keyword. N relative probablities, each from 0.0 to 1.0, are
+specified, where N is the number of molecules in the template. Each
+time a molecule is deposited, a random number is used to sample from
+the list of relative probabilities. The N values must sum to 1.0.
+
+If you wish to insert molecules via the *mol* keyword, that will be
+treated as rigid bodies, use the *rigid* keyword, specifying as its
+value the ID of a separate :doc:`fix rigid/small <fix_rigid_small>`
+command which also appears in your input script.
+
+If you wish to insert molecules via the *mol* keyword, that will have
+their bonds or angles constrained via SHAKE, use the *shake* keyword,
+specifying as its value the ID of a separate :doc:`fix shake <fix_shake>` command which also appears in your input script.
+
+Each timestep a particle is inserted, the coordinates for its atoms
+are chosen as follows. For insertion of individual atoms, the
+"position" referred to in the following description is the coordinate
+of the atom. For insertion of molecule, the "position" is the
+geometric center of the molecule; see the :doc:`molecule <molecule>` doc
+page for details. A random rotation of the molecule around its center
+point is performed, which determines the coordinates all the
+individual atoms.
+
+A random position within the region insertion volume is generated. If
+neither the *global* or *local* keyword is used, the random position
+is the trial position. If the *global* keyword is used, the random
+x,y values are used, but the z position of the new particle is set
+above the highest current atom in the simulation by a distance
+randomly chosen between lo/hi. (For a 2d simulation, this is done for
+the y position.) If the *local* keyword is used, the z position is
+set a distance between lo/hi above the highest current atom in the
+simulation that is "nearby" the chosen x,y position. In this context,
+"nearby" means the lateral distance (in x,y) between the new and old
+particles is less than the *delta* setting.
+
+Once a trial x,y,z position has been selected, the insertion is only
+performed if no current atom in the simulation is within a distance R
+of any atom in the new particle, including the effect of periodic
+boundary conditions if applicable. R is defined by the *near*
+keyword. Note that the default value for R is 0.0, which will allow
+atoms to strongly overlap if you are inserting where other atoms are
+present. This distance test is performed independently for each atom
+in an inserted molecule, based on the randomly rotated configuration
+of the molecule. If this test fails, a new random position within the
+insertion volume is chosen and another trial is made. Up to Q
+attempts are made. If the particle is not successfully inserted,
+LAMMPS prints a warning message.
+
+.. warning::
+
+ If you are inserting finite size particles or a
+ molecule or rigid body consisting of finite-size particles, then you
+ should typically set R larger than the distance at which any inserted
+ particle may overlap with either a previouly inserted particle or an
+ existing particle. LAMMPS will issue a warning if R is smaller than
+ this value, based on the radii of existing and inserted particles.
+
+The *rate* option moves the insertion volume in the z direction (3d)
+or y direction (2d). This enables particles to be inserted from a
+successively higher height over time. Note that this parameter is
+ignored if the *global* or *local* keywords are used, since those
+options choose a z-coordinate for insertion independently.
+
+The vx, vy, and vz components of velocity for the inserted particle
+are set using the values specified for the *vx*, *vy*, and *vz*
+keywords. Note that normally, new particles should be a assigned a
+negative vertical velocity so that they move towards the surface. For
+molecules, the same velocity is given to every particle (no rotation
+or bond vibration).
+
+If the *target* option is used, the velocity vector of the inserted
+particle is changed so that it points from the insertion position
+towards the specified target point. The magnitude of the velocity is
+unchanged. This can be useful, for example, for simulating a
+sputtering process. E.g. the target point can be far away, so that
+all incident particles strike the surface as if they are in an
+incident beam of particles at a prescribed angle.
+
+The *id* keyword determines how atom IDs and molecule IDs are assigned
+to newly deposited particles. Molecule IDs are only assigned if
+molecules are being inserted. For the *max* setting, the atom and
+molecule IDs of all current atoms are checked. Atoms in the new
+particle are assigned IDs starting with the current maximum plus one.
+If a molecule is inserted it is assigned an ID = current maximum plus
+one. This means that if particles leave the system, the new IDs may
+replace the lost ones. For the *next* setting, the maximum ID of any
+atom and molecule is stored at the time the fix is defined. Each time
+a new particle is added, this value is incremented to assign IDs to
+the new atom(s) or molecule. Thus atom and molecule IDs for deposited
+particles will be consecutive even if particles leave the system over
+time.
+
+The *units* keyword determines the meaning of the distance units used
+for the other deposition parameters. A *box* value selects standard
+distance units as defined by the :doc:`units <units>` command,
+e.g. Angstroms for units = real or metal. A *lattice* value means the
+distance units are in lattice spacings. The :doc:`lattice <lattice>`
+command must have been previously used to define the lattice spacing.
+Note that the units choice affects all the keyword values that have
+units of distance or velocity.
+
+.. warning::
+
+ If you are monitoring the temperature of a system
+ where the atom count is changing due to adding particles, you
+ typically should use the :doc:`compute_modify dynamic yes <compute_modify>` command for the temperature compute you are
+ using.
+
+Restart, fix_modify, output, run start/stop, minimize info
+ fix ID group-ID lb/fluid nevery LBtype viscosity density keyword values ...
+
+* ID, group-ID are documented in :doc:`fix <fix>` command
+* lb/fluid = style name of this fix command
+* nevery = update the lattice-Boltzmann fluid every this many timesteps
+* LBtype = 1 to use the standard finite difference LB integrator,
+ 2 to use the LB integrator of :ref:`Ollila et al. <Ollila>`
+* viscosity = the fluid viscosity (units of mass/(time*length)).
+* density = the fluid density.
+* zero or more keyword/value pairs may be appended
+* keyword = *setArea* or *setGamma* or *scaleGamma* or *dx* or *dm* or *a0* or *noise* or *calcforce* or *trilinear* or *D3Q19* or *read_restart* or *write_restart* or *zwall_velocity* or *bodyforce* or *printfluid*
+.. parsed-literal::
+
+ *setArea* values = type node_area
+ type = atom type (1-N)
+ node_area = portion of the surface area of the composite object associated with the particular atom type (used when the force coupling constant is set by default).
+ *setGamma* values = gamma
+ gamma = user set value for the force coupling constant.
+ *scaleGamma* values = type gammaFactor
+ type = atom type (1-N)
+ gammaFactor = factor to scale the *setGamma* gamma value by, for the specified atom type.
+ *dx* values = dx_LB = the lattice spacing.
+ *dm* values = dm_LB = the lattice-Boltzmann mass unit.
+ *a0* values = a_0_real = the square of the speed of sound in the fluid.
+ *noise* values = Temperature seed
+ Temperature = fluid temperature.
+ seed = random number generator seed (positive integer)
+ *calcforce* values = N forcegroup-ID
+ N = output the force and torque every N timesteps
+ forcegroup-ID = ID of the particle group to calculate the force and torque of
+ *trilinear* values = none (used to switch from the default Peskin interpolation stencil to the trilinear stencil).
+ *D3Q19* values = none (used to switch from the default D3Q15, 15 velocity lattice, to the D3Q19, 19 velocity lattice).
+ *read_restart* values = restart file = name of the restart file to use to restart a fluid run.
+ *write_restart* values = N = write a restart file every N MD timesteps.
+ *zwall_velocity* values = velocity_bottom velocity_top = velocities along the y-direction of the bottom and top walls (located at z=zmin and z=zmax).
+ *bodyforce* values = bodyforcex bodyforcey bodyforcez = the x,y and z components of a constant body force added to the fluid.
+ *printfluid* values = N = print the fluid density and velocity at each grid point every N timesteps.
+Implement a lattice-Boltzmann fluid on a uniform mesh covering the LAMMPS
+simulation domain. The MD particles described by *group-ID* apply a velocity
+dependent force to the fluid.
+
+The lattice-Boltzmann algorithm solves for the fluid motion governed by
+the Navier Stokes equations,
+
+.. image:: Eqs/fix_lb_fluid_navierstokes.jpg
+ :align: center
+
+with,
+
+.. image:: Eqs/fix_lb_fluid_viscosity.jpg
+ :align: center
+
+where rho is the fluid density, u is the local fluid velocity, sigma
+is the stress tensor, F is a local external force, and eta and Lambda
+are the shear and bulk viscosities respectively. Here, we have
+implemented
+
+.. image:: Eqs/fix_lb_fluid_stress.jpg
+ :align: center
+
+with a_0 set to 1/3 (dx/dt)^2 by default.
+
+The algorithm involves tracking the time evolution of a set of partial
+distribution functions which evolve according to a velocity
+discretized version of the Boltzmann equation,
+
+.. image:: Eqs/fix_lb_fluid_boltzmann.jpg
+ :align: center
+
+where the first term on the right hand side represents a single time
+relaxation towards the equilibrium distribution function, and tau is a
+parameter physically related to the viscosity. On a technical note,
+we have implemented a 15 velocity model (D3Q15) as default; however,
+the user can switch to a 19 velocity model (D3Q19) through the use of
+the *D3Q19* keyword. This fix provides the user with the choice of
+two algorithms to solve this equation, through the specification of
+the keyword *LBtype*. If *LBtype* is set equal to 1, the standard
+finite difference LB integrator is used. If *LBtype* is set equal to
+2, the algorithm of :ref:`Ollila et al. <Ollila>` is used.
+
+Physical variables are then defined in terms of moments of the distribution
+functions,
+
+.. image:: Eqs/fix_lb_fluid_properties.jpg
+ :align: center
+
+Full details of the lattice-Boltzmann algorithm used can be found in
+:ref:`Mackay et al. <Mackay>`.
+
+The fluid is coupled to the MD particles described by *group-ID*
+through a velocity dependent force. The contribution to the fluid
+force on a given lattice mesh site j due to MD particle alpha is
+calculated as:
+
+.. image:: Eqs/fix_lb_fluid_fluidforce.jpg
+ :align: center
+
+where v_n is the velocity of the MD particle, u_f is the fluid
+velocity interpolated to the particle location, and gamma is the force
+coupling constant. Zeta is a weight assigned to the grid point,
+obtained by distributing the particle to the nearest lattice sites.
+For this, the user has the choice between a trilinear stencil, which
+provides a support of 8 lattice sites, or the immersed boundary method
+Peskin stencil, which provides a support of 64 lattice sites. While
+the Peskin stencil is seen to provide more stable results, the
+trilinear stencil may be better suited for simulation of objects close
+to walls, due to its smaller support. Therefore, by default, the
+Peskin stencil is used; however the user may switch to the trilinear
+stencil by specifying the keyword, *trilinear*.
+
+By default, the force coupling constant, gamma, is calculated according to
+
+.. image:: Eqs/fix_lb_fluid_gammadefault.jpg
+ :align: center
+
+Here, m_v is the mass of the MD particle, m_u is a representative
+fluid mass at the particle location, and dt_collision is a collision
+time, chosen such that tau/dt_collision = 1 (see :ref:`Mackay and Denniston <Mackay2>` for full details). In order to calculate m_u, the
+fluid density is interpolated to the MD particle location, and
+multiplied by a volume, node_area*dx_lb, where node_area represents
+the portion of the surface area of the composite object associated
+with a given MD particle. By default, node_area is set equal to
+dx_lb*dx_lb; however specific values for given atom types can be set
+using the *setArea* keyword.
+
+The user also has the option of specifying their own value for the
+force coupling constant, for all the MD particles associated with the
+fix, through the use of the *setGamma* keyword. This may be useful
+when modelling porous particles. See :ref:`Mackay et al. <Mackay>` for a
+detailed description of the method by which the user can choose an
+appropriate gamma value.
+
+.. warning::
+
+ while this fix applies the force of the particles on
+ the fluid, it does not apply the force of the fluid to the particles.
+ When the force coupling constant is set using the default method,
+ there is only one option to include this hydrodynamic force on the
+ particles, and that is through the use of the
+ :doc:`lb/viscous <fix_lb_viscous>` fix. This fix adds the hydrodynamic
+ force to the total force acting on the particles, after which any of
+ the built-in LAMMPS integrators can be used to integrate the particle
+ motion. However, if the user specifies their own value for the force
+ coupling constant, as mentioned in :ref:`Mackay et al. <Mackay>`, the
+ built-in LAMMPS integrators may prove to be unstable. Therefore, we
+ have included our own integrators :doc:`fix lb/rigid/pc/sphere <fix_lb_rigid_pc_sphere>`, and :doc:`fix lb/pc <fix_lb_pc>`, to solve for the particle motion in these
+ cases. These integrators should not be used with the
+ :doc:`lb/viscous <fix_lb_viscous>` fix, as they add hydrodynamic forces
+ to the particles directly. In addition, they can not be used if the
+ force coupling constant has been set the default way.
+
+.. warning::
+
+ if the force coupling constant is set using the
+ default method, and the :doc:`lb/viscous <fix_lb_viscous>` fix is NOT
+ used to add the hydrodynamic force to the total force acting on the
+ particles, this physically corresponds to a situation in which an
+ infinitely massive particle is moving through the fluid (since
+ collisions between the particle and the fluid do not act to change the
+ particle's velocity). Therefore, the user should set the mass of the
+ particle to be significantly larger than the mass of the fluid at the
+ particle location, in order to approximate an infinitely massive
+ particle (see the dragforce test run for an example).
+
+
+----------
+
+
+Inside the fix, parameters are scaled by the lattice-Boltzmann
+timestep, dt, grid spacing, dx, and mass unit, dm. dt is set equal to
+(nevery*dt_MD), where dt_MD is the MD timestep. By default, dm is set
+equal to 1.0, and dx is chosen so that tau/(dt) =
+(3*eta*dt)/(rho*dx^2) is approximately equal to 1. However, the user
+has the option of specifying their own values for dm, and dx, by using
+the optional keywords *dm*, and *dx* respectively.
+
+.. warning::
+
+ Care must be taken when choosing both a value for dx,
+ and a simulation domain size. This fix uses the same subdivision of
+ the simulation domain among processors as the main LAMMPS program. In
+ order to uniformly cover the simulation domain with lattice sites, the
+ lengths of the individual LAMMPS subdomains must all be evenly
+ divisible by dx. If the simulation domain size is cubic, with equal
+ lengths in all dimensions, and the default value for dx is used, this
+ will automatically be satisfied.
+
+Physical parameters describing the fluid are specified through
+*viscosity*, *density*, and *a0*. If the force coupling constant is
+set the default way, the surface area associated with the MD particles
+is specified using the *setArea* keyword. If the user chooses to
+specify a value for the force coupling constant, this is set using the
+*setGamma* keyword. These parameters should all be given in terms of
+the mass, distance, and time units chosen for the main LAMMPS run, as
+they are scaled by the LB timestep, lattice spacing, and mass unit,
+inside the fix.
+
+
+----------
+
+
+The *setArea* keyword allows the user to associate a surface area with
+a given atom type. For example if a spherical composite object of
+radius R is represented as a spherical shell of N evenly distributed
+MD particles, all of the same type, the surface area per particle
+associated with that atom type should be set equal to 4*pi*R^2/N.
+This keyword should only be used if the force coupling constant,
+gamma, is set the default way.
+
+The *setGamma* keyword allows the user to specify their own value for
+the force coupling constant, gamma, instead of using the default
+value.
+
+The *scaleGamma* keyword should be used in conjunction with the
+*setGamma* keyword, when the user wishes to specify different gamma
+values for different atom types. This keyword allows the user to
+scale the *setGamma* gamma value by a factor, gammaFactor, for a given
+atom type.
+
+The *dx* keyword allows the user to specify a value for the LB grid
+spacing.
+
+The *dm* keyword allows the user to specify the LB mass unit.
+
+If the *a0* keyword is used, the value specified is used for the
+square of the speed of sound in the fluid. If this keyword is not
+present, the speed of sound squared is set equal to (1/3)*(dx/dt)^2.
+Setting a0 > (dx/dt)^2 is not allowed, as this may lead to
+instabilities.
+
+If the *noise* keyword is used, followed by a a positive temperature
+value, and a positive integer random number seed, a thermal
+lattice-Boltzmann algorithm is used. If *LBtype* is set equal to 1
+(i.e. the standard LB integrator is chosen), the thermal LB algorithm
+of :ref:`Adhikari et al. <Adhikari>` is used; however if *LBtype* is set
+equal to 2 both the LB integrator, and thermal LB algorithm described
+in :ref:`Ollila et al. <Ollila>` are used.
+
+If the *calcforce* keyword is used, both the fluid force and torque
+acting on the specified particle group are printed to the screen every
+N timesteps.
+
+If the keyword *trilinear* is used, the trilinear stencil is used to
+interpolate the particle nodes onto the fluid mesh. By default, the
+immersed boundary method, Peskin stencil is used. Both of these
+interpolation methods are described in :ref:`Mackay et al. <Mackay>`.
+
+If the keyword *D3Q19* is used, the 19 velocity (D3Q19) lattice is
+used by the lattice-Boltzmann algorithm. By default, the 15 velocity
+(D3Q15) lattice is used.
+
+If the keyword *write_restart* is used, followed by a positive
+integer, N, a binary restart file is printed every N LB timesteps.
+This restart file only contains information about the fluid.
+Therefore, a LAMMPS restart file should also be written in order to
+print out full details of the simulation.
+
+.. warning::
+
+ When a large number of lattice grid points are used,
+ the restart files may become quite large.
+
+In order to restart the fluid portion of the simulation, the keyword
+*read_restart* is specified, followed by the name of the binary
+lb_fluid restart file to be used.
+
+If the *zwall_velocity* keyword is used y-velocities are assigned to
+the lower and upper walls. This keyword requires the presence of
+walls in the z-direction. This is set by assigning fixed boundary
+conditions in the z-direction. If fixed boundary conditions are
+present in the z-direction, and this keyword is not used, the walls
+are assumed to be stationary.
+
+If the *bodyforce* keyword is used, a constant body force is added to
+the fluid, defined by it's x, y and z components.
+
+If the *printfluid* keyword is used, followed by a positive integer, N,
+the fluid densities and velocities at each lattice site are printed to the
+screen every N timesteps.
+
+
+----------
+
+
+For further details, as well as descriptions and results of several
+test runs, see :ref:`Mackay et al. <Mackay>`. Please include a citation to
+this paper if the lb_fluid fix is used in work contributing to
+published research.
+
+
+----------
+
+
+Restart, fix_modify, output, run start/stop, minimize info
+Due to the large size of the fluid data, this fix writes it's own
+binary restart files, if requested, independent of the main LAMMPS
+:doc:`binary restart files <restart>`; no information about *lb_fluid*
+is written to the main LAMMPS :doc:`binary restart files <restart>`.
+
+None of the :doc:`fix_modify <fix_modify>` options are relevant to this
+fix. No global or per-atom quantities are stored by this fix for
+access by various :ref:`output commands <4_15>`. 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>`.
+
+Restrictions
+""""""""""""
+
+
+This fix is part of the USER-LB package. It is only enabled if LAMMPS
+was built with that package. See the :ref:`Making LAMMPS <start_3>` section for more info.
+
+This fix can only be used with an orthogonal simulation domain.
+
+Walls have only been implemented in the z-direction. Therefore, the
+boundary conditions, as specified via the main LAMMPS boundary command
+must be periodic for x and y, and either fixed or periodic for z.
+Shrink-wrapped boundary conditions are not permitted with this fix.
+
+This fix must be used before any of :doc:`fix lb/viscous <fix_lb_viscous>`, :doc:`fix lb/momentum <fix_lb_momentum>`, :doc:`fix lb/rigid/pc/sphere <fix_lb_rigid_pc_sphere>`, and/ or :doc:`fix lb/pc <fix_lb_pc>` , as the fluid needs to be initialized before
+any of these routines try to access its properties. In addition, in
+order for the hydrodynamic forces to be added to the particles, this
+fix must be used in conjunction with the
+:doc:`lb/viscous <fix_lb_viscous>` fix if the force coupling constant is
+set by default, or either the :doc:`lb/viscous <fix_lb_viscous>` fix or
+one of the :doc:`lb/rigid/pc/sphere <fix_lb_rigid_pc_sphere>` or
+:doc:`lb/pc <fix_lb_pc>` integrators, if the user chooses to specifiy
+By default, the force coupling constant is set according to
+
+.. image:: Eqs/fix_lb_fluid_gammadefault.jpg
+ :align: center
+
+and an area of dx_lb^2 per node, used to calculate the fluid mass at
+the particle node location, is assumed.
+
+dx is chosen such that tau/(delta t_LB) =
+(3 eta dt_LB)/(rho dx_lb^2) is approximately equal to 1.
+dm is set equal to 1.0.
+a0 is set equal to (1/3)*(dx_lb/dt_lb)^2.
+The Peskin stencil is used as the default interpolation method.
+The D3Q15 lattice is used for the lattice-Boltzmann algorithm.
+If walls are present, they are assumed to be stationary.
+
+
+----------
+
+
+.. _Ollila:
+
+
+
+**(Ollila et al.)** Ollila, S.T.T., Denniston, C., Karttunen, M., and Ala-Nissila, T., Fluctuating lattice-Boltzmann model for complex fluids, J. Chem. Phys. 134 (2011) 064902.
+
+.. _Mackay:
+
+
+
+**(Mackay et al.)** Mackay, F. E., Ollila, S.T.T., and Denniston, C., Hydrodynamic Forces Implemented into LAMMPS through a lattice-Boltzmann fluid, Computer Physics Communications 184 (2013) 2021-2031.
+
+.. _Mackay2:
+
+
+
+**(Mackay and Denniston)** Mackay, F. E., and Denniston, C., Coupling MD particles to a lattice-Boltzmann fluid through the use of conservative forces, J. Comput. Phys. 237 (2013) 289-298.
+
+.. _Adhikari:
+
+
+
+**(Adhikari et al.)** Adhikari, R., Stratford, K., Cates, M. E., and Wagner, A. J., Fluctuating lattice Boltzmann, Europhys. Lett. 71 (2005) 473-479.
+**(Mackay et al.)** Mackay, F. E., Ollila, S.T.T., and Denniston, C., Hydrodynamic Forces Implemented into LAMMPS through a lattice-Boltzmann fluid, Computer Physics Communications 184 (2013) 2021-2031.
+The defaults are force * on on on, and torque * on on on.
+
+
+----------
+
+
+.. _Mackay:
+
+
+
+**(Mackay et al.)** Mackay, F. E., Ollila, S.T.T., and Denniston, C., Hydrodynamic Forces Implemented into LAMMPS through a lattice-Boltzmann fluid, Computer Physics Communications 184 (2013) 2021-2031.
+**(Mackay et al.)** Mackay, F. E., Ollila, S.T.T., and Denniston, C., Hydrodynamic Forces Implemented into LAMMPS through a lattice-Boltzmann fluid, Computer Physics Communications 184 (2013) 2021-2031.
+1. *dhugoniot* is the departure from the Hugoniot (temperature units).
+2. *drayleigh* is the departure from the Rayleigh line (pressure units).
+3. *lagrangian_speed* is the laboratory-frame Lagrangian speed (particle velocity) of the computational cell (velocity units).
+4. *lagrangian_position* is the computational cell position in the reference frame moving at the shock speed. This is usually a good estimate of distance of the computational cell behind the shock front.
+
+To print these quantities to the log file with descriptive column
+headers, the following LAMMPS commands are suggested:
+
+.. parsed-literal::
+
+ fix msst all msst z
+ fix_modify msst energy yes
+ variable dhug equal f_msst[1]
+ variable dray equal f_msst[2]
+ variable lgr_vel equal f_msst[3]
+ variable lgr_pos equal f_msst[4]
+ thermo_style custom step temp ke pe lz pzz etotal v_dhug v_dray v_lgr_vel v_lgr_pos f_msst
+
+These fixes compute a global scalar and a global vector of 4
+quantities, which can be accessed by various :ref:`output commands <howto_15>`. The scalar values calculated
+by this fix are "extensive"; the vector values are "intensive".
+
+Restrictions
+""""""""""""
+
+
+This fix style is part of the SHOCK package. It is only enabled if
+LAMMPS was built with that package. See the :ref:`Making LAMMPS <start_3>` section for more info.
+
+All cell dimensions must be periodic. This fix can not be used with a
+triclinic cell. The MSST fix has been tested only for the group-ID
+* ID, group-ID are documented in :doc:`fix <fix>` command
+* style_name = *nvt* or *npt* or *nph*
+* one or more keyword/value pairs may be appended
+.. parsed-literal::
+
+ keyword = *temp* or *iso* or *aniso* or *tri* or *x* or *y* or *z* or *xy* or *yz* or *xz* or *couple* or *tchain* or *pchain* or *mtk* or *tloop* or *ploop* or *nreset* or *drag* or *dilate* or *scalexy* or *scaleyz* or *scalexz* or *flip* or *fixedpoint*
+ *temp* values = Tstart Tstop Tdamp
+ Tstart,Tstop = external temperature at start/end of run
+ Tdamp = temperature damping parameter (time units)
+ *iso* or *aniso* or *tri* values = Pstart Pstop Pdamp
+ Pstart,Pstop = scalar external pressure at start/end of run (pressure units)
+ Pdamp = pressure damping parameter (time units)
+ *x* or *y* or *z* or *xy* or *yz* or *xz* values = Pstart Pstop Pdamp
+ Pstart,Pstop = external stress tensor component at start/end of run (pressure units)
+ Pdamp = stress damping parameter (time units)
+ *couple* = *none* or *xyz* or *xy* or *yz* or *xz*
+ *tchain* value = N
+ N = length of thermostat chain (1 = single thermostat)
+ *pchain* values = N
+ N length of thermostat chain on barostat (0 = no thermostat)
+ *mtk* value = *yes* or *no* = add in MTK adjustment term or not
+ *tloop* value = M
+ M = number of sub-cycles to perform on thermostat
+ *ploop* value = M
+ M = number of sub-cycles to perform on barostat thermostat
+ *nreset* value = reset reference cell every this many timesteps
+ *drag* value = Df
+ Df = drag factor added to barostat/thermostat (0.0 = no drag)
+ *dilate* value = dilate-group-ID
+ dilate-group-ID = only dilate atoms in this group due to barostat volume changes
+ *scalexy* value = *yes* or *no* = scale xy with ly
+ *scaleyz* value = *yes* or *no* = scale yz with lz
+ *scalexz* value = *yes* or *no* = scale xz with lz
+ *flip* value = *yes* or *no* = allow or disallow box flips when it becomes highly skewed
+ *fixedpoint* values = x y z
+ x,y,z = perform barostat dilation/contraction around this point (distance units)
+
+
+
+Examples
+""""""""
+
+.. parsed-literal::
+
+ fix 1 all nvt temp 300.0 300.0 100.0
+ fix 1 water npt temp 300.0 300.0 100.0 iso 0.0 0.0 1000.0
+* ID, group-ID are documented in :doc:`fix <fix>` command
+* style_name = *nvt/eff* or *npt/eff* or *nph/eff*
+.. parsed-literal::
+
+ one or more keyword value pairs may be appended
+ keyword = *temp* or *iso* or *aniso* or *tri* or *x* or *y* or *z* or *xy* or *yz* or *xz* or *couple* or *tchain* or *pchain* or *mtk* or *tloop* or *ploop* or *nreset* or *drag* or *dilate*
+ *temp* values = Tstart Tstop Tdamp
+ Tstart,Tstop = external temperature at start/end of run
+ Tdamp = temperature damping parameter (time units)
+ *iso* or *aniso* or *tri* values = Pstart Pstop Pdamp
+ Pstart,Pstop = scalar external pressure at start/end of run (pressure units)
+ Pdamp = pressure damping parameter (time units)
+ *x* or *y* or *z* or *xy* or *yz* or *xz* values = Pstart Pstop Pdamp
+ Pstart,Pstop = external stress tensor component at start/end of run (pressure units)
+ Pdamp = stress damping parameter (time units)
+ *couple* = *none* or *xyz* or *xy* or *yz* or *xz*
+ *tchain* value = length of thermostat chain (1 = single thermostat)
+ *pchain* values = length of thermostat chain on barostat (0 = no thermostat)
+ *mtk* value = *yes* or *no* = add in MTK adjustment term or not
+ *tloop* value = number of sub-cycles to perform on thermostat
+ *ploop* value = number of sub-cycles to perform on barostat thermostat
+ *nreset* value = reset reference cell every this many timesteps
+ *drag* value = drag factor added to barostat/thermostat (0.0 = no drag)
+ *dilate* value = *all* or *partial*
+
+
+
+Examples
+""""""""
+
+.. parsed-literal::
+
+ fix 1 all nvt/eff temp 300.0 300.0 0.1
+ fix 1 part npt/eff temp 300.0 300.0 0.1 iso 0.0 0.0 1.0
+ fix 2 part npt/eff temp 300.0 300.0 0.1 tri 5.0 5.0 1.0
+ fix 2 ice nph/eff x 1.0 1.0 0.5 y 2.0 2.0 0.5 z 3.0 3.0 0.5 yz 0.1 0.1 0.5 xz 0.2 0.2 0.5 xy 0.3 0.3 0.5 nreset 1000
+
+Description
+"""""""""""
+
+These commands perform time integration on Nose-Hoover style
+non-Hamiltonian equations of motion for nuclei and electrons in the
+group for the :doc:`electron force field <pair_eff>` model. The fixes
+are designed to generate positions and velocities sampled from the
+canonical (nvt), isothermal-isobaric (npt), and isenthalpic (nph)
+ensembles. This is achieved by adding some dynamic variables which
+are coupled to the particle velocities (thermostatting) and simulation
+domain dimensions (barostatting). In addition to basic thermostatting
+and barostatting, these fixes can also create a chain of thermostats
+coupled to the particle thermostat, and another chain of thermostats
+coupled to the barostat variables. The barostat can be coupled to the
+overall box volume, or to individual dimensions, including the *xy*,
+*xz* and *yz* tilt dimensions. The external pressure of the barostat
+can be specified as either a scalar pressure (isobaric ensemble) or as
+components of a symmetric stress tensor (constant stress ensemble).
+When used correctly, the time-averaged temperature and stress tensor
+of the particles will match the target values specified by
+Tstart/Tstop and Pstart/Pstop.
+
+The operation of these fixes is exactly like that described by the
+:doc:`fix nvt, npt, and nph <fix_nh>` commands, except that the radius
+and radial velocity of electrons are also updated. Likewise the
+temperature and pressure calculated by the fix, using the computes it
+creates (as discussed in the :doc:`fix nvt, npt, and nph <fix_nh>`
+doc page), are performed with computes that include the eFF contribution
+to the temperature or kinetic energy from the electron radial velocity.
+
+.. warning::
+
+ there are two different pressures that can be reported
+ for eFF when defining the pair_style (see :doc:`pair eff/cut <pair_eff_cut>` to understand these settings), one
+ (default) that considers electrons do not contribute radial virial
+ components (i.e. electrons treated as incompressible 'rigid' spheres)
+ and one that does. The radial electronic contributions to the virials
+ are only tallied if the flexible pressure option is set, and this will
+ affect both global and per-atom quantities. In principle, the true
+ pressure of a system is somewhere in between the rigid and the
+ flexible eFF pressures, but, for most cases, the difference between
+ these two pressures will not be significant over long-term averaged
+ runs (i.e. even though the energy partitioning changes, the total
+ energy remains similar).
+
+.. warning::
+
+ currently, there is no available option for the user
+ to set or create temperature distributions that include the radial
+ electronic degrees of freedom with the :doc:`velocity <velocity>`
+ command, so the the user must allow for these degrees of freedom to
+ equilibrate (i.e. equi-partitioning of energy) through time
+ integration.
+
+Restart, fix_modify, output, run start/stop, minimize info
+* ID, group-ID are documented in :doc:`fix <fix>` command
+.. parsed-literal::
+
+ one or more keyword value pairs may be appended
+ keyword = *temp* or *iso* or *aniso* or *tri* or *x* or *y* or *z* or *couple* or *tchain* or *pchain* or *mtk* or *tloop* or *ploop* or *nreset* or *drag* or *dilate* or *scaleyz* or *scalexz* or *scalexy*
+ *temp* values = Value1 Value2 Tdamp
+ Value1, Value2 = Nose-Hoover target temperatures, ignored by Hugoniostat
+ Tdamp = temperature damping parameter (time units)
+ *iso* or *aniso* or *tri* values = Pstart Pstop Pdamp
+ Pstart,Pstop = scalar external pressures, must be equal (pressure units)
+ Pdamp = pressure damping parameter (time units)
+ *x* or *y* or *z* or *xy* or *yz* or *xz* values = Pstart Pstop Pdamp
+ Pstart,Pstop = external stress tensor components, must be equal (pressure units)
+ Pdamp = stress damping parameter (time units)
+ *couple* = *none* or *xyz* or *xy* or *yz* or *xz*
+ *tchain* value = length of thermostat chain (1 = single thermostat)
+ *pchain* values = length of thermostat chain on barostat (0 = no thermostat)
+ *mtk* value = *yes* or *no* = add in MTK adjustment term or not
+ *tloop* value = number of sub-cycles to perform on thermostat
+ *ploop* value = number of sub-cycles to perform on barostat thermostat
+ *nreset* value = reset reference cell every this many timesteps
+ *drag* value = drag factor added to barostat/thermostat (0.0 = no drag)
+ *dilate* value = *all* or *partial*
+ *scaleyz* value = *yes* or *no* = scale yz with lz
+ *scalexz* value = *yes* or *no* = scale xz with lz
+ *scalexy* value = *yes* or *no* = scale xy with ly
+
+
+
+Examples
+""""""""
+
+.. parsed-literal::
+
+ fix myhug all nphug temp 1.0 1.0 10.0 z 40.0 40.0 70.0
+ fix myhug all nphug temp 1.0 1.0 10.0 iso 40.0 40.0 70.0 drag 200.0 tchain 1 pchain 0
+
+Description
+"""""""""""
+
+This command is a variant of the Nose-Hoover
+:doc:`fix npt <fix_nh>` fix style.
+It performs time integration of the Hugoniostat equations
+of motion developed by Ravelo et al. :ref:`(Ravelo) <Ravelo>`.
+These equations compress the system to a state with average
+axial stress or pressure equal to the specified target value
+and that satisfies the Rankine-Hugoniot (RH)
+jump conditions for steady shocks.
+
+The compression can be performed
+either
+hydrostatically (using keyword *iso*, *aniso*, or *tri*) or uniaxially
+(using keywords *x*, *y*, or *z*). In the hydrostatic case,
+the cell dimensions change dynamically so that the average axial stress
+in all three directions converges towards the specified target value.
+In the uniaxial case, the chosen cell dimension changes dynamically
+so that the average
+axial stress in that direction converges towards the target value. The
+other two cell dimensions are kept fixed (zero lateral strain).
+
+This leads to the following additional restrictions on the keywords:
+
+* One and only one of the following keywords should be used: *iso*, *aniso*, *tri*, *x*, *y*, *z*
+* The specified initial and final target pressures must be the same.
+* The keywords *xy*, *xz*, *yz* may not be used.
+* The only admissible value for the couple keyword is *xyz*, which has the same effect as keyword *iso*
+* The *temp* keyword must be used to specify the time constant for kinetic energy relaxation, but initial and final target temperature values are ignored.
+
+Essentially, a Hugoniostat simulation is an NPT simulation in which the
+user-specified target temperature is replaced with a time-dependent
+target temperature Tt obtained from the following equation:
+
+.. image:: Eqs/fix_nphug.jpg
+ :align: center
+
+where T and Tt are the instantaneous and target temperatures,
+P and P0 are the instantaneous and reference pressures or axial stresses,
+depending on whether hydrostatic or uniaxial compression is being
+performed, V and V0 are the instantaneous and reference volumes,
+E and E0 are the instantaneous and reference internal energy (potential
+plus kinetic), Ndof is the number of degrees of freedom used in the
+definition of temperature, and kB is the Boltzmann constant. Delta is the
+negative deviation of the instantaneous temperature from the target temperature.
+When the system reaches a stable equilibrium, the value of Delta should
+fluctuate about zero.
+
+The values of E0, V0, and P0 are the instantaneous values at the start of
+the simulation. These can be overridden using the fix_modify keywords *e0*,
+*v0*, and *p0* described below.
+
+
+----------
+
+
+.. warning::
+
+ Unlike the :doc:`fix temp/berendsen <fix_temp_berendsen>` command which performs
+ thermostatting but NO time integration, this fix performs
+ thermostatting/barostatting AND time integration. Thus you should not
+ use any other time integration fix, such as :doc:`fix nve <fix_nve>` on
+ atoms to which this fix is applied. Likewise, this fix should not be
+ used on atoms that have their temperature controlled by another fix
+ - e.g. by :doc:`fix langevin <fix_nh>` or :doc:`fix temp/rescale <fix_temp_rescale>`
+ commands.
+
+
+----------
+
+
+This fix computes a temperature and pressure at each timestep. To do
+this, the fix creates its own computes of style "temp" and "pressure",
+as if one of these two sets of commands had been issued:
+ fix ID group-ID property/atom vec1 vec2 ... keyword value ...
+
+* ID, group-ID are documented in :doc:`fix <fix>` command
+* property/atom = style name of this fix command
+* vec1,vec2,... = *mol* or *q* or *i_name* or *d_name*
+.. parsed-literal::
+
+ *mol* = molecule IDs
+ *q* = charge
+ *i_name* = new integer vector referenced by name
+ *d_name* = new floating-point vector referenced by name
+
+* zero of more keyword/value pairs may be appended
+* keyword = *ghost*
+.. parsed-literal::
+
+ *ghost* value = *no* or *yes* for whether ghost atom info in communicated
+
+
+
+Examples
+""""""""
+
+.. parsed-literal::
+
+ fix 1 all property/atom mol
+ fix 1 all property/atom i_myflag1 i_myflag2
+ fix 1 all property/atom d_sx d_sy d_sz
+
+Description
+"""""""""""
+
+Create one or more additional per-atom vectors to store information
+about atoms and to use during a simulation. The specified *group-ID*
+is ignored by this fix.
+
+The atom style used for a simulation defines a set of per-atom
+properties, as explained on the :doc:`atom_style <atom_style>` and
+:doc:`read_data <read_data>` doc pages. The latter command allows these
+properties to be defined for each atom in the system when a data file
+is read. This fix will augment the set of properties with new custom
+ones.
+
+This can be useful in at least two scenarios.
+
+If the atom style does not define molecule IDs or per-atom charge,
+they can be added using the *mol* or *q* keywords. This can be
+useful, e.g, to define "molecules" to use as rigid bodies with the
+:doc:`fix rigid <fix_rigid>` command, or just to carry around an extra
+flag with the atoms (stored as a molecule ID). An alternative is to
+use an atom style that does define molecule IDs or charge or to use a
+hybrid atom style that combines two styles to allow for molecule IDs
+or charge, but that has 2 practical drawbacks. First it typically
+necessitates changing the format of the data file. And it may define
+additional properties that aren't needed such as bond lists, which has
+some overhead when there are no bonds.
+
+In the future, we may add additional per-atom properties similar to
+*mol* or *q*, which "turn-on" specific properties defined by some atom
+styles, so they can be used by atom styles that don't define them.
+
+More generally, the *i_name* and *d_name* vectors allow one or more
+new custom per-atom properties to be defined. Each name must be
+unique and can use alphanumeric or underscore characters. These
+vectors can store whatever values you decide are useful in your
+simulation. As explained below there are several ways to initialize
+and access and output these values, both via input script commands and
+in new code that you add to LAMMPS.
+
+This is effectively a simple way to add per-atom properties to a model
+without needing to write code for a new :doc:`atom style <atom_style>`
+that defines the properties. Note however that implementing a new
+atom style allows new atom properties to be more tightly and
+seamlessly integrated with the rest of the code.
+
+The new atom properties encode values that migrate with atoms to new
+processors and are written to restart files. If you want the new
+properties to also be defined for ghost atoms, then use the *ghost*
+keyword with a value of *yes*. This will invoke extra communication
+when ghost atoms are created (at every re-neighboring) to insure the
+new properties are also defined for the ghost atoms.
+
+.. warning::
+
+ If you use this command with the *mol* or *charge*
+ vectors than you most likely want to set *ghost* yes, since these
+ properties are stored with ghost atoms if you use an
+ :doc:`atom_style <atom_style>` that defines them, and many LAMMPS
+ operations that use molecule IDs or charge, such as neighbor lists and
+ pair styles, will expect ghost atoms to have these valuse. LAMMPS
+ will issue a warning it you define those vectors but do not set
+ *ghost* yes.
+
+.. warning::
+
+ The properties for ghost atoms are not updated every
+ timestep, but only once every few steps when neighbor lists are
+ re-built. Thus the *ghost* keyword is suitable for static properties,
+ like molecule IDs, but not for dynamic properties that change every
+ step. For the latter, the code you add to LAMMPS to change the
+ properties will also need to communicate their new values to/from
+ ghost atoms, an operation that can be invoked from within a :doc:`pair style <pair_style>` or :doc:`fix <fix>` or :doc:`compute <compute>`
+ that you write.
+
+
+----------
+
+
+This fix is one of a small number that can be defined in an input
+script before the simulation box is created or atoms are defined.
+This is so it can be used with the :doc:`read_data <read_data>` command
+as described below.
+
+Per-atom properties that are defined by the :doc:`atom style <atom_style>` are initialized when atoms are created, e.g. by
+the :doc:`read_data <read_data>` or :doc:`create_atoms <create_atoms>`
+commands. The per-atom properaties defined by this fix are not. So
+you need to initialize them explicitly. This can be done by the
+:doc:`read_data <read_data>` command, using its *fix* keyword and
+passing it the fix-ID of this fix.
+
+Thus these commands:
+
+.. parsed-literal::
+
+ fix prop all property/atom mol d_flag
+ read_data data.txt fix prop NULL Molecules
+
+would allow a data file to have a section like this:
+
+.. parsed-literal::
+
+ Molecules
+
+.. parsed-literal::
+
+ 1 4 1.5
+ 2 4 3.0
+ 3 10 1.0
+ 4 10 1.0
+ 5 10 1.0
+ ...
+ N 763 4.5
+
+where N is the number of atoms, and the first field on each line is
+the atom-ID, followed by a molecule-ID and a floating point value that
+will be stored in a new property called "flag". Note that the list of
+per-atom properties can be in any order.
+
+Another way of initializing the new properties is via the
+:doc:`set <set>` command. For example, if you wanted molecules
+defined for every set of 10 atoms, based on their atom-IDs,
+these commands could be used:
+
+.. parsed-literal::
+
+ fix prop all property/atom mol
+ variable cluster atom ((id-1)/10)+1
+ set id * mol v_cluster
+
+The :doc:`atom-style variable <variable>` will create values for atoms
+with IDs 31,32,33,...40 that are 4.0,4.1,4.2,...,4.9. When the
+:doc:`set <set>` commands assigns them to the molecule ID for each atom,
+they will be truncated to an integer value, so atoms 31-40 will all be
+assigned a molecule ID of 4.
+
+Note that :doc:`atomfile-style variables <variable>` can also be used in
+place of atom-style variables, which means in this case that the
+molecule IDs could be read-in from a separate file and assinged by the
+:doc:`set <set>` command. This allows you to initialize new per-atom
+properties in a completely general fashion.
+
+
+----------
+
+
+For new atom properties specified as *i_name* or *d_name*, the
+:doc:`compute property/atom <compute_property_atom>` command can access
+their values. This means that the values can be output via the :doc:`dump custom <dump>` command, accessed by fixes like :doc:`fix ave/atom <fix_ave_atom>`, accessed by other computes like :doc:`compute reduce <compute_reduce>`, or used in `atom-style variables <variables>`_.
+
+For example, these commands will output two new properties to a custom
+dump file:
+
+.. parsed-literal::
+
+ fix prop all property/atom i_flag1 d_flag2
+ compute 1 all property/atom i_flag1 d_flag2
+ dump 1 all custom 100 tmp.dump id x y z c_1[1] c_1[2]
+
+
+----------
+
+
+If you wish to add new :doc:`pair styles <pair_style>`,
+:doc:`fixes <fix>`, or :doc:`computes <compute>` that use the per-atom
+properties defined by this fix, see :ref:`Section modify <mod_1>` of the manual which has some details
+on how the properties can be accessed from added classes.
+
+
+----------
+
+
+Restart, fix_modify, output, run start/stop, minimize info
+* zero or more keyword/value pairs may be appended
+* keyword = *q* or *mu* or *p0* or *v0* or *e0* or *tscale* or *damp* or *seed*or *f_max* or *N_f* or *eta* or *beta* or *T_init*
+.. parsed-literal::
+
+ *q* value = cell mass-like parameter (mass^2/distance^4 units)
+ *mu* value = artificial viscosity (mass/distance/time units)
+ *p0* value = initial pressure in the shock equations (pressure units)
+ *v0* value = initial simulation cell volume in the shock equations (distance^3 units)
+ *e0* value = initial total energy (energy units)
+ *tscale* value = reduction in initial temperature (unitless fraction between 0.0 and 1.0)
+ *damp* value = damping parameter (time units) inverse of friction <i>γ</i>
+ *seed* value = random number seed (positive integer)
+ *f_max* value = upper cutoff frequency of the vibration spectrum (1/time units)
+ *N_f* value = number of frequency bins (positive integer)
+ *eta* value = coupling constant between the shock system and the quantum thermal bath (positive unitless)
+ *beta* value = the quantum temperature is updated every beta time steps (positive integer)
+ *T_init* value = quantum temperature for the initial state (temperature units)
+
+
+
+Examples
+""""""""
+
+.. parsed-literal::
+
+ fix 1 all qbmsst z 0.122 q 25 mu 0.9 tscale 0.01 damp 200 seed 35082 f_max 0.3 N_f 100 eta 1 beta 400 T_init 110 (liquid methane modeled with the REAX force field, real units)
+ fix 2 all qbmsst z 72 q 40 tscale 0.05 damp 1 seed 47508 f_max 120.0 N_f 100 eta 1.0 beta 500 T_init 300 (quartz modeled with the BKS force field, metal units)
+
+Two example input scripts are given, including shocked alpha quartz
+and shocked liquid methane. The input script first equilibrate an
+initial state with the quantum thermal bath at the target temperature
+and then apply the qbmsst to simulate shock compression with quantum
+nuclear correction. The following two figures plot related quantities
+for shocked alpha quartz.
+
+.. image:: JPG/qbmsst_init.jpg
+ :align: center
+
+Figure 1. Classical temperature <i>T</i><sup>cl</sup> = ∑
+<i>m<sub>i</sub>v<sub>i</sub><sup>2</sup>/3Nk</i><sub>B</sub> vs. time
+for coupling the alpha quartz initial state with the quantum thermal
+bath at target quantum temperature <i>T</i><sup>qm</sup> = 300 K. The
+NpH ensemble is used for time integration while QTB provides the
+colored random force. <i>T</i><sup>cl</sup> converges at the timescale
+of *damp* which is set to be 1 ps.
+
+.. image:: JPG/qbmsst_shock.jpg
+ :align: center
+
+Figure 2. Quantum temperature and pressure vs. time for simulating
+shocked alpha quartz with the QBMSST. The shock propagates along the z
+direction. Restart of the QBMSST command is demonstrated in the
+example input script. Thermodynamic quantities stay continuous before
+and after the restart.
+
+Description
+"""""""""""
+
+This command performs the Quantum-Bath coupled Multi-Scale Shock
+Technique (QBMSST) integration. See :ref:`(Qi) <Qi>` for a detailed
+description of this method. The QBMSST provides description of the
+thermodynamics and kinetics of shock processes while incorporating
+quantum nuclear effects. The *shockvel* setting determines the steady
+shock velocity that will be simulated along direction *dir*.
+
+Quantum nuclear effects :doc:`(fix qtb) <fix_qtb>` can be crucial
+especially when the temperature of the initial state is below the
+classical limit or there is a great change in the zero point energies
+between the initial and final states. Theoretical post processing
+quantum corrections of shock compressed water and methane have been
+reported as much as 30% of the temperatures :ref:`(Goldman) <Goldman>`. A
+self-consistent method that couples the shock to a quantum thermal
+bath described by a colored noise Langevin thermostat has been
+developed by Qi et al :ref:`(Qi) <Qi>` and applied to shocked methane. The
+onset of chemistry is reported to be at a pressure on the shock
+Hugoniot that is 40% lower than observed with classical molecular
+dynamics.
+
+It is highly recommended that the system be already in an equilibrium
+state with a quantum thermal bath at temperature of *T_init*. The fix
+command :doc:`fix qtb <fix_qtb>` at constant temperature *T_init* could
+be used before applying this command to introduce self-consistent
+quantum nuclear effects into the initial state.
+
+The parameters *q*, *mu*, *e0*, *p0*, *v0* and *tscale* are described
+in the command :doc:`fix msst <fix_msst>`. The values of *e0*, *p0*, or
+*v0* will be calculated on the first step if not specified. The
+parameter of *damp*, *f_max*, and *N_f* are described in the command
+:doc:`fix qtb <fix_qtb>`.
+
+The fix qbmsst command couples the shock system to a quantum thermal
+bath with a rate that is proportional to the change of the total
+energy of the shock system, <i>etot</i> - <i>etot</i><sub>0</sub>.
+Here <i>etot</i> consists of both the system energy and a thermal
+term, see :ref:`(Qi) <Qi>`, and <i>etot</i><sub>0</sub> = *e0* is the
+initial total energy.
+
+The *eta* (<i>η</i>) parameter is a unitless coupling constant
+between the shock system and the quantum thermal bath. A small *eta*
+value cannot adjust the quantum temperature fast enough during the
+temperature ramping period of shock compression while large *eta*
+leads to big temperature oscillation. A value of *eta* between 0.3 and
+1 is usually appropriate for simulating most systems under shock
+compression. We observe that different values of *eta* lead to almost
+the same final thermodynamic state behind the shock, as expected.
+
+The quantum temperature is updated every *beta* (<i>β</i>) steps
+with an integration time interval *beta* times longer than the
+simulation time step. In that case, <i>etot</i> is taken as its
+average over the past *beta* steps. The temperature of the quantum
+thermal bath <i>T</i><sup>qm</sup> changes dynamically according to
+the following equation where Δ<i>t</i> is the MD time step and
+<i>γ</i> is the friction constant which is equal to the inverse
+1. *dhugoniot* is the departure from the Hugoniot (temperature units).
+2. *drayleigh* is the departure from the Rayleigh line (pressure units).
+3. *lagrangian_speed* is the laboratory-frame Lagrangian speed (particle velocity) of the computational cell (velocity units).
+4. *lagrangian_position* is the computational cell position in the reference frame moving at the shock speed. This is the distance of the computational cell behind the shock front.
+5. *quantum_temperature* is the temperature of the quantum thermal bath <i>T</i><sup>qm</sup>.
+
+To print these quantities to the log file with descriptive column
+headers, the following LAMMPS commands are suggested. Here the
+:doc:`fix_modify <fix_modify>` energy command is also enabled to allow
+the thermo keyword *etotal* to print the quantity <i>etot</i>. See
+also the :doc:`thermo_style <thermo_style>` command.
+
+.. parsed-literal::
+
+ fix fix_id all msst z
+ fix_modify fix_id energy yes
+ variable dhug equal f_fix_id[1]
+ variable dray equal f_fix_id[2]
+ variable lgr_vel equal f_fix_id[3]
+ variable lgr_pos equal f_fix_id[4]
+ variable T_qm equal f_fix_id[5]
+ thermo_style custom step temp ke pe lz pzz etotal v_dhug v_dray v_lgr_vel v_lgr_pos v_T_qm f_fix_id
+
+The global scalar under the entry f_fix_id is the quantity of thermo
+energy as an extra part of <i>etot</i>. This global scalar and the
+vector of 5 quantities can be accessed by various :ref:`output commands <howto_15>`. It is worth noting that the
+temp keyword under the :doc:`thermo_style <thermo_style>` command print
+the instantaneous classical temperature <i>T</i><sup>cl</sup> as
+described in the command :doc:`fix qtb <fix_qtb>`.
+
+
+----------
+
+
+Restrictions
+""""""""""""
+
+
+This fix style is part of the USER-QTB package. It is only enabled if
+LAMMPS was built with that package. See the :ref:`Making LAMMPS <start_3>` section for more info.
+
+All cell dimensions must be periodic. This fix can not be used with a
+triclinic cell. The QBMSST fix has been tested only for the group-ID
+Perform the charge equilibration (QEq) method as described in :ref:`(Rappe and Goddard) <Rappe>` and formulated in :ref:`(Nakano) <Nakano>` (also known
+as the matrix inversion method) and in :ref:`(Rick and Stuart) <Rick>` (also
+known as the extended Lagrangian method) based on the
+electronegativity equilization principle.
+
+These fixes can be used with any :doc:`pair style <pair_style>` in
+LAMMPS, so long as per-atom charges are defined. The most typical
+use-case is in conjunction with a :doc:`pair style <pair_style>` that
+performs charge equilibration periodically (e.g. every timestep), such
+as the ReaxFF or Streitz-Mintmire potential (the latter is not yet
+implemented in LAMMPS). But these fixes can also be used with
+potentials that normally assume per-atom charges are fixed, e.g. a
+:doc:`Buckingham <pair_buck>` or :doc:`LJ/Coulombic <pair_lj>` potential.
+
+Because the charge equilibration calculation is effectively
+independent of the pair style, these fixes can also be used to perform
+a one-time assignment of charges to atoms. For example, you could
+define the QEq fix, perform a zero-timestep run via the :doc:`run <run>`
+command without any pair style defined which would set per-atom
+charges (based on the current atom configuration), then remove the fix
+via the :doc:`unfix <unfix>` command before performing further dynamics.
+
+.. warning::
+
+ Computing and using charge values different from
+ published values defined for a fixed-charge potential like Buckingham
+ or CHARMM or AMBER, can have a strong effect on energies and forces,
+ and produces a different model than the published versions.
+
+.. warning::
+
+ The :doc:`fix qeq/comb <fix_qeq_comb>` command must
+ still be used to perform charge equliibration with the :doc:`COMB potential <pair_comb>`. The :doc:`fix qeq/reax <fix_qeq_reax>`
+ command can be used to perform charge equilibration with the :doc:`ReaxFF force field <pair_reax_c>`, although fix qeq/shielded yields the
+ same results as fix qeq/reax if *Nevery*, *cutoff*, and *tolerance* are
+ the same. Eventually the fix qeq/reax command will be deprecated.
+
+The QEq method minimizes the electrostatic energy of the system (or
+equalizes the derivative of energy with respect to charge of all the
+atoms) by adjusting the partial charge on individual atoms based on
+interactions with their neighbors within *cutoff*. It reqires a few
+parameters, in *metal* units, for each atom type which provided in a
+file specified by *qfile*. The file has the following format
+
+.. parsed-literal::
+
+ 1 chi eta gamma zeta qcore
+ 2 chi eta gamma zeta qcore
+ ...
+ Ntype chi eta gamma zeta qcore
+
+There is one line per atom type with the following parameters.
+Only a subset of the parameters is used by each QEq style as descibed
+below, thus the others can be set to 0.0 if desired.
+
+* *chi* = electronegativity in energy units
+* *eta* = self-Coulomb potential in energy units
+* *gamma* = shielded Coulomb constant defined by :ref:`ReaxFF force field <vanDuin>` in distance units
+* *zeta* = Slater type orbital exponent defined by the :ref:`Streitz-Mintmire <Streitz>` potential in reverse distance units
+* *qcore* = charge of the nucleus defined by the :ref:`Streitz-Mintmire potential <Streitz>` potential in charge units
+
+The *qeq/point* style describes partial charges on atoms as point
+charges. Interaction between a pair of charged particles is 1/r,
+which is the simplest description of the interaction between charges.
+Only the *chi* and *eta* parameters from the *qfile* file are used.
+Note that Coulomb catastrophe can occur if repulsion between the pair
+of charged particles is too weak. This style solves partial charges
+on atoms via the matrix inversion method. A tolerance of 1.0e-6 is
+usually a good number.
+
+The *qeq/shielded* style describes partial charges on atoms also as
+point charges, but uses a shielded Coulomb potential to describe the
+interaction between a pair of charged particles. Interaction through
+the shielded Coulomb is given by equation (13) of the :ref:`ReaxFF force field <vanDuin>` paper. The shielding accounts for charge overlap
+between charged particles at small separation. This style is the same
+as :doc:`fix qeq/reax <fix_qeq_reax>`, and can be used with :doc:`pair_style reax/c <pair_reax_c>`. Only the *chi*, *eta*, and *gamma*
+parameters from the *qfile* file are used. This style solves partial
+charges on atoms via the matrix inversion method. A tolerance of
+1.0e-6 is usually a good number.
+
+The *qeq/slater* style describes partial charges on atoms as spherical
+charge densities centered around atoms via the Slater 1*s* orbital, so
+that the interaction between a pair of charged particles is the
+product of two Slater 1*s* orbitals. The expression for the Slater
+1*s* orbital is given under equation (6) of the
+:ref:`Streitz-Mintmire <Streitz>` paper. Only the *chi*, *eta*, *zeta*, and
+*qcore* parameters from the *qfile* file are used. This style solves
+partial charges on atoms via the matrix inversion method. A tolerance
+of 1.0e-6 is usually a good number.
+
+The *qeq/dynamic* style describes partial charges on atoms as point
+charges that interact through 1/r, but the extended Lagrangian method
+is used to solve partial charges on atoms. Only the *chi* and *eta*
+parameters from the *qfile* file are used. Note that Coulomb
+catastrophe can occur if repulsion between the pair of charged
+particles is too weak. A tolerance of 1.0e-3 is usually a good
+number.
+
+Note that *qeq/point*, *qeq/shielded*, and *qeq/slater* describe
+different charge models, whereas the matrix inversion method and the
+extended Lagrangian method (*qeq/dynamic*) are different solvers.
+
+Note that the *qeq/point* and the *qeq/dynamic* styles both describe
+charges as point charges that interact through 1/r relationship, but
+solve partial charges on atoms using different solvers. Styles
+*qeq/point* and the *qeq/dynamic* should yield comparable results if
+the QEq parameters and *Nevery*, *cutoff*, and *tolerance* are the
+same. Style *qeq/point* is typically faster, but *qeq/dynamic* scales
+better on larger sizes.
+
+.. warning::
+
+ To avoid the evaluation of the derivative of charge
+ with respect to position, which is typically ill-defined, the system
+ should have a zero net charge.
+
+.. warning::
+
+ Developing QEq parameters (chi, eta, gamma, zeta, and
+ qcore) is an "art". Charges on atoms are not guaranteed to
+ equilibrate with arbitrary choices of these parameters. We do not
+ develop these QEq paramters. See the examples/qeq directory for some
+ examples.
+
+Restart, fix_modify, output, run start/stop, minimize info
+ fix ID group-ID style bodystyle args keyword values ...
+
+* ID, group-ID are documented in :doc:`fix <fix>` command
+* style = *rigid* or *rigid/nve* or *rigid/nvt* or *rigid/npt* or *rigid/nph* or *rigid/small* or *rigid/nve/small* or *rigid/nvt/small* or *rigid/npt/small* or *rigid/nph/small*
+* bodystyle = *single* or *molecule* or *group*
+.. parsed-literal::
+
+ *single* args = none
+ *molecule* args = none
+ *group* args = N groupID1 groupID2 ...
+ N = # of groups
+ groupID1, groupID2, ... = list of N group IDs
+
+* zero or more keyword/value pairs may be appended
+* keyword = *langevin* or *temp* or *iso* or *aniso* or *x* or *y* or *z* or *couple* or *tparam* or *pchain* or *dilate* or *force* or *torque* or *infile*
+.. parsed-literal::
+
+ *langevin* values = Tstart Tstop Tperiod seed
+ Tstart,Tstop = desired temperature at start/stop of run (temperature units)
+ Tdamp = temperature damping parameter (time units)
+ seed = random number seed to use for white noise (positive integer)
+ *temp* values = Tstart Tstop Tdamp
+ Tstart,Tstop = desired temperature at start/stop of run (temperature units)
+ Tdamp = temperature damping parameter (time units)
+ *iso* or *aniso* values = Pstart Pstop Pdamp
+ Pstart,Pstop = scalar external pressure at start/end of run (pressure units)
+ Pdamp = pressure damping parameter (time units)
+ *x* or *y* or *z* values = Pstart Pstop Pdamp
+ Pstart,Pstop = external stress tensor component at start/end of run (pressure units)
+ Pdamp = stress damping parameter (time units)
+ *couple* = *none* or *xyz* or *xy* or *yz* or *xz*
+ *tparam* values = Tchain Titer Torder
+ Tchain = length of Nose/Hoover thermostat chain
+ Titer = number of thermostat iterations performed
+ Torder = 3 or 5 = Yoshida-Suzuki integration parameters
+ *pchain* values = Pchain
+ Pchain = length of the Nose/Hoover thermostat chain coupled with the barostat
+ *dilate* value = dilate-group-ID
+ dilate-group-ID = only dilate atoms in this group due to barostat volume changes
+ *force* values = M xflag yflag zflag
+ M = which rigid body from 1-Nbody (see asterisk form below)
+ xflag,yflag,zflag = off/on if component of center-of-mass force is active
+ *torque* values = M xflag yflag zflag
+ M = which rigid body from 1-Nbody (see asterisk form below)
+ xflag,yflag,zflag = off/on if component of center-of-mass torque is active
+ *infile* filename
+ filename = file with per-body values of mass, center-of-mass, moments of inertia
+ *mol* value = template-ID
+ template-ID = ID of molecule template specified in a separate :doc:`molecule <molecule>` command
+
+
+
+Examples
+""""""""
+
+.. parsed-literal::
+
+ fix 1 clump rigid single
+ fix 1 clump rigid/small molecule
+ fix 1 clump rigid single force 1 off off on langevin 1.0 1.0 1.0 428984
+ fix ID group-ID srd N groupbig-ID Tsrd hgrid seed keyword value ...
+
+* ID, group-ID are documented in :doc:`fix <fix>` command
+* srd = style name of this fix command
+* N = reset SRD particle velocities every this many timesteps
+* groupbig-ID = ID of group of large particles that SRDs interact with
+* Tsrd = temperature of SRD particles (temperature units)
+* hgrid = grid spacing for SRD grouping (distance units)
+* seed = random # seed (positive integer)
+
+* zero or more keyword/value pairs may be appended
+* keyword = *lamda* or *collision* or *overlap* or *inside* or *exact* or *radius* or *bounce* or *search* or *cubic* or *shift* or *tstat* or *rescale*
+.. parsed-literal::
+
+ *lamda* value = mean free path of SRD particles (distance units)
+ *collision* value = *noslip* or *slip* = collision model
+ *overlap* value = *yes* or *no* = whether big particles may overlap
+ *inside* value = *error* or *warn* or *ignore* = how SRD particles which end up inside a big particle are treated
+ *exact* value = *yes* or *no*
+ *radius* value = rfactor = scale collision radius by this factor
+ *bounce* value = Nbounce = max # of collisions an SRD particle can undergo in one timestep
+ *search* value = sgrid = grid spacing for collision partner searching (distance units)
+* zero or more keyword/value pairs may be appended
+* keyword = *com*
+.. parsed-literal::
+
+ *com* value = *yes* or *no*
+
+
+
+Examples
+""""""""
+
+.. parsed-literal::
+
+ fix 1 all store/state 0 x y z
+ fix 1 all store/state 0 xu yu zu com yes
+ fix 2 all store/state 1000 vx vy vz
+
+Description
+"""""""""""
+
+Define a fix that stores attributes for each atom in the group at the
+time the fix is defined. If *N* is 0, then the values are never
+updated, so this is a way of archiving an atom attribute at a given
+time for future use in a calculation or output. See the discussion of
+:ref:`output commands <howto_15>` that take fixes as
+inputs. And see for example, the :doc:`compute reduce <compute_reduce>`, :doc:`fix ave/atom <fix_ave_atom>`, :doc:`fix ave/histo <fix_ave_histo>`, :doc:`fix ave/spatial <fix_ave_spatial>`,
+ xflag,yflag,zflag = 0/1 to exclude/include each dimension
+ *rot* args = none
+
+
+
+Examples
+""""""""
+
+.. parsed-literal::
+
+ fix 1 all tfmc 0.1 1000.0 159345
+ fix 1 all tfmc 0.05 600.0 658943 com 1 1 0
+ fix 1 all tfmc 0.1 750.0 387068 com 1 1 1 rot
+
+Description
+"""""""""""
+
+Perform uniform-acceptance force-bias Monte Carlo (fbMC) simulations,
+using the time-stamped force-bias Monte Carlo (tfMC) algorithm
+described in :ref:`(Mees) <Mees>` and :ref:`(Bal) <Bal>`.
+
+One successful use case of force-bias Monte Carlo methods is that they
+can be used to extend the time scale of atomistic simulations, in
+particular when long time scale relaxation effects must be considered;
+some interesting examples are given in the review by :ref:`(Neyts) <Neyts>`.
+An example of a typical use case would be the modelling of chemical
+vapour deposition (CVD) processes on a surface, in which impacts by
+gas-phase species can be performed using MD, but subsequent relaxation
+of the surface is too slow to be done using MD only. Using tfMC can
+allow for a much faster relaxation of the surface, so that higher
+fluxes can be used, effectively extending the time scale of the
+simulation. (Such an alternating simulation approach could be set up
+using a :doc:`loop <jump>`.)
+
+The initial version of tfMC algorithm in :ref:`(Mees) <Mees>` contained an
+estimation of the effective time scale of such a simulation, but it
+was later shown that the speed-up one can gain from a tfMC simulation
+is system- and process-dependent, ranging from none to several orders
+of magnitude. In general, solid-state processes such as
+(re)crystallisation or growth can be accelerated by up to two or three
+orders of magnitude, whereas diffusion in the liquid phase is not
+accelerated at all. The observed pseudodynamics when using the tfMC
+method is not the actual dynamics one would obtain using MD, but the
+relative importance of processes can match the actual relative
+dynamics of the system quite well, provided *Delta* is chosen with
+care. Thus, the system's equilibrium is reached faster than in MD,
+along a path that is generally roughly similar to a typical MD
+simulation (but not necessarily so). See :ref:`(Bal) <Bal>` for details.
+
+Each step, all atoms in the selected group are displaced using the
+stochastic tfMC algorithm, which is designed to sample the canonical
+(NVT) ensemble at the temperature *Temp*. Although tfMC is a Monte
+Carlo algorithm and thus strictly speaking does not perform time
+integration, it is similar in the sense that it uses the forces on all
+atoms in order to update their positions. Therefore, it is implemented
+as a time integration fix, and no other fixes of this type (such as
+:doc:`fix nve <fix_nve>`) should be used at the same time. Because
+velocities do not play a role in this kind of Monte Carlo simulations,
+instantaneous temperatures as calculated by :doc:`temperature computes <compute_temp>` or :doc:`thermodynamic output <thermo_style>` have no meaning: the only relevant
+temperature is the sampling temperature *Temp*. Similarly, performing
+tfMC simulations does not require setting a :doc:`timestep <timestep>`
+and the :doc:`simulated time <thermo_style>` as calculated by LAMMPS is
+meaningless.
+
+The critical parameter determining the success of a tfMC simulation is
+*Delta*, the maximal displacement length of the lightest element in
+the system: the larger it is, the longer the effective time scale of
+the simulation will be (there is an approximately quadratic
+dependence). However, *Delta* must also be chosen sufficiently small
+in order to comply with detailed balance; in general values between 5
+and 10 % of the nearest neighbor distance are found to be a good
+choice. For a more extensive discussion with specific examples, please
+refer to :ref:`(Bal) <Bal>`, which also describes how the code calculates
+element-specific maximal displacements from *Delta*, based on the
+fourth root of their mass.
+
+Because of the uncorrelated movements of the atoms, the center-of-mass
+of the fix group will not necessarily be stationary, just like its
+orientation. When the *com* keyword is used, all atom positions will
+be shifted (after every tfMC iteration) in order to fix the position
+of the center-of-mass along the included directions, by setting the
+corresponding flag to 1. The *rot* keyword does the same for the
+rotational component of the tfMC displacements after every iteration.
+
+.. warning::
+
+ the *com* and *rot* keywords should not be used if an
+ external force is acting on the specified fix group, along the
+ included directions. This can be either a true external force (e.g.
+ through :doc:`fix wall <fix_wall>`) or forces due to the interaction
+ with atoms not included in the fix group. This is because in such
+ cases, translations or rotations of the fix group could be induced by
+ these external forces, and removing them will lead to a violation of
+ detailed balance.
+
+
+----------
+
+
+Restart, fix_modify, output, run start/stop, minimize info
+* style = *delete* or *region* or *type* or *id* or *molecule* or *variable* or *include* or *subtract* or *union* or *intersect* or *dynamic* or *static*
+.. parsed-literal::
+
+ *delete* = no args
+ *clear* = no args
+ *region* args = region-ID
+ *type* or *id* or *molecule*
+ args = list of one or more atom types, atom IDs, or molecule IDs
+ any entry in list can be a sequence formatted as A:B or A:B:C where
+ A = starting index, B = ending index,
+ C = increment between indices, 1 if not specified
+ args = logical value
+ logical = "<" or "<=" or ">" or ">=" or "==" or "!="
+ value = an atom type or atom ID or molecule ID (depending on *style*)
+ args = logical value1 value2
+ logical = "<>"
+ value1,value2 = atom types or atom IDs or molecule IDs (depending on *style*)
+ *variable* args = variable-name
+ *include* args = molecule
+ molecule = add atoms to group with same molecule ID as atoms already in group
+ *subtract* args = two or more group IDs
+ *union* args = one or more group IDs
+ *intersect* args = two or more group IDs
+ *dynamic* args = parent-ID keyword value ...
+ one or more keyword/value pairs may be appended
+ keyword = *region* or *var* or *every*
+ *region* value = region-ID
+ *var* value = name of variable
+ *every* value = N = update group every this many timesteps
+ *static* = no args
+
+
+
+Examples
+""""""""
+
+.. parsed-literal::
+
+ group edge region regstrip
+ group water type 3 4
+ group sub id 10 25 50
+ group sub id 10 25 50 500:1000
+ group sub id 100:10000:10
+ group sub id <= 150
+ group polyA molecule <> 50 250
+ group hienergy variable eng
+ group hienergy include molecule
+ group boundary subtract all a2 a3
+ group boundary union lower upper
+ group boundary intersect upper flow
+ group boundary delete
+ group mine dynamic all region myRegion every 100
+
+Description
+"""""""""""
+
+Identify a collection of atoms as belonging to a group. The group ID
+can then be used in other commands such as :doc:`fix <fix>`,
+:doc:`compute <compute>`, :doc:`dump <dump>`, or :doc:`velocity <velocity>`
+to act on those atoms together.
+
+If the group ID already exists, the group command adds the specified
+atoms to the group.
+
+.. warning::
+
+ By default groups are static, meaning the atoms are
+ permanently assigned to the group. For example, if the *region* style
+ is used to assign atoms to a group, the atoms will remain in the group
+ even if they later move out of the region. As explained below, the
+ *dynamic* style can be used to make a group dynamic so that a periodic
+ determination is made as to which atoms are in the group. Since many
+ LAMMPS commands operate on groups of atoms, you should think carefully
+ about whether making a group dynamic makes sense for your model.
+
+A group with the ID *all* is predefined. All atoms belong to this
+group. This group cannot be deleted, or made dynamic.
+
+The *delete* style removes the named group and un-assigns all atoms
+that were assigned to that group. Since there is a restriction (see
+below) that no more than 32 groups can be defined at any time, the
+*delete* style allows you to remove groups that are no longer needed,
+so that more can be specified. You cannot delete a group if it has
+been used to define a current :doc:`fix <fix>` or :doc:`compute <compute>`
+or :doc:`dump <dump>`.
+
+The *clear* style un-assigns all atoms that were assigned to that
+group. This may be dangerous to do during a simulation run,
+e.g. using the :doc:`run every <run>` command if a fix or compute or
+other operation expects the atoms in the group to remain constant, but
+LAMMPS does not check for this.
+
+The *region* style puts all atoms in the region volume into the group.
+Note that this is a static one-time assignment. The atoms remain
+assigned (or not assigned) to the group even in they later move out of
+the region volume.
+
+The *type*, *id*, and *molecule* styles put all atoms with the
+specified atom types, atom IDs, or molecule IDs into the group. These
+3 styles can use arguments specified in one of two formats.
+
+The first format is a list of values (types or IDs). For example, the
+2nd command in the examples above puts all atoms of type 3 or 4 into
+the group named *water*. Each entry in the list can be a
+colon-separated sequence A:B or A:B:C, as in two of the examples
+above. A "sequence" generates a sequence of values (types or IDs),
+with an optional increment. The first example with 500:1000 has the
+default increment of 1 and would add all atom IDs from 500 to 1000
+(inclusive) to the group sub, along with 10,25,50 since they also
+appear in the list of values. The second example with 100:10000:10
+uses an increment of 10 and would thus would add atoms IDs
+100,110,120, ... 9990,10000 to the group sub.
+
+The second format is a *logical* followed by one or two values (type
+or ID). The 7 valid logicals are listed above. All the logicals
+except <> take a single argument. The 3rd example above adds all
+atoms with IDs from 1 to 150 to the group named *sub*. The logical <>
+means "between" and takes 2 arguments. The 4th example above adds all
+atoms belonging to molecules with IDs from 50 to 250 (inclusive) to
+the group named polyA.
+
+The *variable* style evaluates a variable to determine which atoms to
+add to the group. It must be an :doc:`atom-style variable <variable>`
+previously defined in the input script. If the variable evaluates
+to a non-zero value for a particular atom, then that atom is added
+to the specified group.
+
+Atom-style variables can specify formulas that include thermodynamic
+quantities, per-atom values such as atom coordinates, or per-atom
+quantities calculated by computes, fixes, or other variables. They
+can also include Boolean logic where 2 numeric values are compared to
+yield a 1 or 0 (effectively a true or false). Thus using the
+*variable* style, is a general way to flag specific atoms to include
+or exclude from a group.
+
+For example, these lines define a variable "eatom" that calculates the
+potential energy of each atom and includes it in the group if its
+potential energy is above the threshhold value -3.0.
+
+.. parsed-literal::
+
+ compute 1 all pe/atom
+ compute 2 all reduce sum c_1
+ thermo_style custom step temp pe c_2
+ run 0
+
+.. parsed-literal::
+
+ variable eatom atom "c_1 > -3.0"
+ group hienergy variable eatom
+
+Note that these lines
+
+.. parsed-literal::
+
+ compute 2 all reduce sum c_1
+ thermo_style custom step temp pe c_2
+ run 0
+
+are necessary to insure that the "eatom" variable is current when the
+group command invokes it. Because the eatom variable computes the
+per-atom energy via the pe/atom compute, it will only be current if a
+run has been performed which evaluated pairwise energies, and the
+pe/atom compute was actually invoked during the run. Printing the
+thermodyanmic info for compute 2 insures that this is the case, since
+it sums the pe/atom compute values (in the reduce compute) to output
+them to the screen. See the "Variable Accuracy" section of the
+:doc:`variable <variable>` doc page for more details on insuring that
+variables are current when they are evaluated between runs.
+
+The *include* style with its arg *molecule* adds atoms to a group that
+have the same molecule ID as atoms already in the group. The molecule
+ID = 0 is ignored in this operation, since it is assumed to flag
+isolated atoms that are not part of molecules. An example of where
+this operation is useful is if the *region* style has been used
+previously to add atoms to a group that are within a geometric region.
+If molecules straddle the region boundary, then atoms outside the
+region that are part of molecules with atoms inside the region will
+not be in the group. Using the group command a 2nd time with *include
+molecule* will add those atoms that are outside the region to the
+group.
+
+.. warning::
+
+ The *include molecule* operation is relatively
+ expensive in a parallel sense. This is because it requires
+ communication of relevant molecule IDs between all the processors and
+ each processor to loop over its atoms once per processor, to compare
+ its atoms to the list of molecule IDs from every other processor.
+ Hence it scales as N, rather than N/P as most of the group operations
+ do, where N is the number of atoms, and P is the number of processors.
+
+The *subtract* style takes a list of two or more existing group names
+as arguments. All atoms that belong to the 1st group, but not to any
+of the other groups are added to the specified group.
+
+The *union* style takes a list of one or more existing group names as
+arguments. All atoms that belong to any of the listed groups are
+added to the specified group.
+
+The *intersect* style takes a list of two or more existing group names
+as arguments. Atoms that belong to every one of the listed groups are
+added to the specified group.
+
+
+----------
+
+
+The *dynamic* style flags an existing or new group as dynamic. This
+means atoms will be (re)assigned to the group periodically as a
+simulation runs. This is in contrast to static groups where atoms are
+permanently assigned to the group. The way the assignment occurs is
+as follows. Only atoms in the group specified as the parent group via
+the parent-ID are assigned to the dynamic group before the following
+conditions are applied. If the *region* keyword is used, atoms not in
+the specified region are removed from the dynamic group. If the *var*
+keyword is used, the variable name must be an atom-style or
+atomfile-style variable. The variable is evaluated and atoms whose
+per-atom values are 0.0, are removed from the dynamic group.
+
+The assignment of atoms to a dynamic group is done at the beginning of
+each run and on every timestep that is a multiple of *N*, which is the
+argument for the *every* keyword (N = 1 is the default). For an
+energy minimization, via the :doc:`minimize <minimize>` command, an
+assignement is made at the beginning of the minimization, but not
+during the iterations of the minimizer.
+
+The point in the timestep at which atoms are assigned to a dynamic
+group is after the initial stage of velocity Verlet time integration
+has been performed, and before neighbor lists or forces are computed.
+This is the point in the timestep where atom positions have just
+changed due to the time integration, so the region criterion should be
+accurate, if applied.
+
+.. warning::
+
+ If the *region* keyword is used to determine what
+ atoms are in the dynamic group, atoms can move outside of the
+ simulation box between reneighboring events. Thus if you want to
+ include all atoms on the left side of the simulation box, you probably
+ want to set the left boundary of the region to be outside the
+ simulation box by some reasonable amount (e.g. up to the cutoff of the
+ potential), else they may be excluded from the dynamic region.
+
+Here is an example of using a dynamic group to shrink the set of atoms
+being integrated by using a spherical region with a variable radius
+(shrinking from 18 to 5 over the course of the run). This could be
+used to model a quench of the system, freezing atoms outside the
+shrinking sphere, then converting the remaining atoms to a static
+group and running further.
+
+.. parsed-literal::
+
+ variable nsteps equal 5000
+ variable rad equal 18-(step/v_nsteps)*(18-5)
+ region ss sphere 20 20 0 v_rad
+ group mobile dynamic all region ss
+ fix 1 mobile nve
+ run ${nsteps}
+ group mobile static
+ run ${nsteps}
+
+.. warning::
+
+ All fixes and computes take a group ID as an argument,
+ but they do not all allow for use of a dynamic group. If you get an
+ error message that this is not allowed, but feel that it should be for
+ the fix or compute in question, then please post your reasoning to the
+ LAMMPS mail list and we can change it.
+
+The *static* style removes the setting for a dynamic group, converting
+it to a static group (the default). The atoms in the static group are
+those currently in the dynamic group.
+
+
+----------
+
+
+Restrictions
+""""""""""""
+
+
+There can be no more than 32 groups defined at one time, including
+"all".
+
+The parent group of a dynamic group cannot itself be a dynamic group.
+args = one or more of the following keywords: *out*, *all*, *system*, *computes*, *dumps*, *fixes*, *groups*, *regions*, *variables*, *time*, or *configuration*
+ keyword = *mesh* or *order* or *order/disp* or *mix/disp* or *overlap* or *minorder* or *force* or *gewald* or *gewald/disp* or *slab* or (nozforce* or *compute* or *cutoff/adjust* or *fftbench* or *collective* or *diff* or *kmax/ewald* or *force/disp/real* or *force/disp/kspace* or *splittol* or *disp/auto*:l
+ *mesh* value = x y z
+ x,y,z = grid size in each dimension for long-range Coulombics
+ *mesh/disp* value = x y z
+ x,y,z = grid size in each dimension for 1/r^6 dispersion
+ *order* value = N
+ N = extent of Gaussian for PPPM or MSM mapping of charge to grid
+ *order/disp* value = N
+ N = extent of Gaussian for PPPM mapping of dispersion term to grid
+ *mix/disp* value = *pair* or *geom* or *none*
+ *overlap* = *yes* or *no* = whether the grid stencil for PPPM is allowed to overlap into more than the nearest-neighbor processor
+ *minorder* value = M
+ M = min allowed extent of Gaussian when auto-adjusting to minimize grid communication
+ *force* value = accuracy (force units)
+ *gewald* value = rinv (1/distance units)
+ rinv = G-ewald parameter for Coulombics
+ *gewald/disp* value = rinv (1/distance units)
+ rinv = G-ewald parameter for dispersion
+ *slab* value = volfactor or *nozforce*
+ volfactor = ratio of the total extended volume used in the
+ 2d approximation compared with the volume of the simulation domain
+ *nozforce* turns off kspace forces in the z direction
+ *compute* value = *yes* or *no*
+ *cutoff/adjust* value = *yes* or *no*
+ *pressure/scalar* value = *yes* or *no*
+ *fftbench* value = *yes* or *no*
+ *collective* value = *yes* or *no*
+ *diff* value = *ad* or *ik* = 2 or 4 FFTs for PPPM in smoothed or non-smoothed mode
+ *kmax/ewald* value = kx ky kz
+ kx,ky,kz = number of Ewald sum kspace vectors in each dimension
+ *force/disp/real* value = accuracy (force units)
+ *force/disp/kspace* value = accuracy (force units)
+ *splittol* value = tol
+ tol = relative size of two eigenvalues (see discussion below)
+ *disp/auto* value = yes or no
+
+
+
+Examples
+""""""""
+
+.. parsed-literal::
+
+ kspace_modify mesh 24 24 30 order 6
+ kspace_modify slab 3.0
+
+Description
+"""""""""""
+
+Set parameters used by the kspace solvers defined by the
+:doc:`kspace_style <kspace_style>` command. Not all parameters are
+relevant to all kspace styles.
+
+The *mesh* keyword sets the grid size for kspace style *pppm* or
+*msm*. In the case of PPPM, this is the FFT mesh, and each dimension
+must be factorizable into powers of 2, 3, and 5. In the case of MSM,
+this is the finest scale real-space mesh, and each dimension must be
+factorizable into powers of 2. When this option is not set, the PPPM
+or MSM solver chooses its own grid size, consistent with the
+user-specified accuracy and pairwise cutoff. Values for x,y,z of
+0,0,0 unset the option.
+
+The *mesh/disp* keyword sets the grid size for kspace style
+*pppm/disp*. This is the FFT mesh for long-range dispersion and ach
+dimension must be factorizable into powers of 2, 3, and 5. When this
+option is not set, the PPPM solver chooses its own grid size,
+consistent with the user-specified accuracy and pairwise cutoff.
+Values for x,y,z of 0,0,0 unset the option.
+
+The *order* keyword determines how many grid spacings an atom's charge
+extends when it is mapped to the grid in kspace style *pppm* or *msm*.
+The default for this parameter is 5 for PPPM and 8 for MSM, which
+means each charge spans 5 or 8 grid cells in each dimension,
+respectively. For the LAMMPS implementation of MSM, the order can
+range from 4 to 10 and must be even. For PPPM, the minimum allowed
+setting is 2 and the maximum allowed setting is 7. The larger the
+value of this parameter, the smaller that LAMMPS will set the grid
+size, to achieve the requested accuracy. Conversely, the smaller the
+order value, the larger the grid size will be. Note that there is an
+inherent trade-off involved: a small grid will lower the cost of FFTs
+or MSM direct sum, but a larger order parameter will increase the cost
+of interpolating charge/fields to/from the grid.
+
+The *order/disp* keyword determines how many grid spacings an atom's
+dispersion term extends when it is mapped to the grid in kspace style
+*pppm/disp*. It has the same meaning as the *order* setting for
+Coulombics.
+
+The *overlap* keyword can be used in conjunction with the *minorder*
+keyword with the PPPM styles to adjust the amount of communication
+that occurs when values on the FFT grid are exchangeed between
+processors. This communication is distinct from the communication
+inherent in the parallel FFTs themselves, and is required because
+processors interpolate charge and field values using grid point values
+owned by neighboring processors (i.e. ghost point communication). If
+the *overlap* keyword is set to *yes* then this communication is
+allowed to extend beyond nearest-neighbor processors, e.g. when using
+lots of processors on a small problem. If it is set to *no* then the
+communication will be limited to nearest-neighbor processors and the
+*order* setting will be reduced if necessary, as explained by the
+*minorder* keyword discussion. The *overlap* keyword is always set to
+*yes* in MSM.
+
+The *minorder* keyword allows LAMMPS to reduce the *order* setting if
+necessary to keep the communication of ghost grid point limited to
+exchanges between nearest-neighbor processors. See the discussion of
+the *overlap* keyword for details. If the *overlap* keyword is set to
+*yes*, which is the default, this is never needed. If it set to *no*
+and overlap occurs, then LAMMPS will reduce the order setting, one
+step at a time, until the ghost grid overlap only extends to nearest
+neighbor processors. The *minorder* keyword limits how small the
+*order* setting can become. The minimum allowed value for PPPM is 2,
+which is the default. If *minorder* is set to the same value as
+*order* then no reduction is allowed, and LAMMPS will generate an
+error if the grid communcation is non-nearest-neighbor and *overlap*
+is set to *no*. The *minorder* keyword is not currently supported in
+MSM.
+
+The PPPM order parameter may be reset by LAMMPS when it sets up the
+FFT grid if the implied grid stencil extends beyond the grid cells
+owned by neighboring processors. Typically this will only occur when
+small problems are run on large numbers of processors. A warning will
+be generated indicating the order parameter is being reduced to allow
+LAMMPS to run the problem. Automatic adjustment of the order parameter
+is not supported in MSM.
+
+The *force* keyword overrides the relative accuracy parameter set by
+the :doc:`kspace_style <kspace_style>` command with an absolute
+accuracy. The accuracy determines the RMS error in per-atom forces
+calculated by the long-range solver and is thus specified in force
+units. A negative value for the accuracy setting means to use the
+relative accuracy parameter. The accuracy setting is used in
+conjunction with the pairwise cutoff to determine the number of
+K-space vectors for style *ewald*, the FFT grid size for style
+*pppm*, or the real space grid size for style *msm*.
+
+The *gewald* keyword sets the value of the Ewald or PPPM G-ewald
+parameter for charge as *rinv* in reciprocal distance units. Without
+this setting, LAMMPS chooses the parameter automatically as a function
+of cutoff, precision, grid spacing, etc. This means it can vary from
+one simulation to the next which may not be desirable for matching a
+KSpace solver to a pre-tabulated pairwise potential. This setting can
+also be useful if Ewald or PPPM fails to choose a good grid spacing
+and G-ewald parameter automatically. If the value is set to 0.0,
+LAMMPS will choose the G-ewald parameter automatically. MSM does not
+use the *gewald* parameter.
+
+The *gewald/disp* keyword sets the value of the Ewald or PPPM G-ewald
+parameter for dispersion as *rinv* in reciprocal distance units. It
+has the same meaning as the *gewald* setting for Coulombics.
+
+The *slab* keyword allows an Ewald or PPPM solver to be used for a
+systems that are periodic in x,y but non-periodic in z - a
+:doc:`boundary <boundary>` setting of "boundary p p f". This is done by
+treating the system as if it were periodic in z, but inserting empty
+volume between atom slabs and removing dipole inter-slab interactions
+so that slab-slab interactions are effectively turned off. The
+volfactor value sets the ratio of the extended dimension in z divided
+by the actual dimension in z. The recommended value is 3.0. A larger
+value is inefficient; a smaller value introduces unwanted slab-slab
+interactions. The use of fixed boundaries in z means that the user
+must prevent particle migration beyond the initial z-bounds, typically
+by providing a wall-style fix. The methodology behind the *slab*
+option is explained in the paper by :ref:`(Yeh) <Yeh>`. The *slab* option
+is also extended to non-neutral systems
+:ref:`(Ballenegger) <Ballenegger>`. An alternative slab option can be
+invoked with the *nozforce* keyword in lieu of the volfactor. This
+turns off all kspace forces in the z direction. The *nozforce* option
+is not supported by MSM. For MSM, any combination of periodic,
+non-periodic, or shrink-wrapped boundaries can be set using
+:doc:`boundary <boundary>` (the slab approximation in not needed). The
+*slab* keyword is not currently supported by Ewald or PPPM when using
+a triclinic simulation cell. The slab correction has also been
+extended to point dipole interactions :ref:`(Klapp) <Klapp>` in
+:doc:`kspace_style <kspace_style>` *ewald/disp*.
+
+The *compute* keyword allows Kspace computations to be turned off,
+even though a :doc:`kspace_style <kspace_style>` is defined. This is
+not useful for running a real simulation, but can be useful for
+debugging purposes or for computing only partial forces that do not
+include the Kspace contribution. You can also do this by simply not
+defining a :doc:`kspace_style <kspace_style>`, but a Kspace-compatible
+:doc:`pair_style <pair_style>` requires a kspace style to be defined.
+This keyword gives you that option.
+
+The *cutoff/adjust* keyword applies only to MSM. If this option is
+turned on, the Coulombic cutoff will be automatically adjusted at the
+beginning of the run to give the desired estimated error. Other
+cutoffs such as LJ will not be affected. If the grid is not set using
+the *mesh* command, this command will also attempt to use the optimal
+grid that minimizes cost using an estimate given by
+:ref:`(Hardy) <Hardy>`. Note that this cost estimate is not exact, somewhat
+experimental, and still may not yield the optimal parameters.
+
+The *pressure/scalar* keyword applies only to MSM. If this option is
+turned on, only the scalar pressure (i.e. (Pxx + Pyy + Pzz)/3.0) will
+be computed, which can be used, for example, to run an isotropic barostat.
+Computing the full pressure tensor with MSM is expensive, and this option
+provides a faster alternative. The scalar pressure is computed using a
+relationship between the Coulombic energy and pressure :ref:`(Hummer) <Hummer>`
+instead of using the virial equation. This option cannot be used to access
+individual components of the pressure tensor, to compute per-atom virial,
+or with suffix kspace/pair styles of MSM, like OMP or GPU.
+
+The *fftbench* keyword applies only to PPPM. It is on by default. If
+this option is turned off, LAMMPS will not take the time at the end
+of a run to give FFT benchmark timings, and will finish a few seconds
+faster than it would if this option were on.
+
+The *collective* keyword applies only to PPPM. It is set to *no* by
+default, except on IBM BlueGene machines. If this option is set to
+*yes*, LAMMPS will use MPI collective operations to remap data for
+3d-FFT operations instead of the default point-to-point communication.
+This is faster on IBM BlueGene machines, and may also be faster on
+other machines if they have an efficient implementation of MPI
+collective operations and adequate hardware.
+
+The *diff* keyword specifies the differentiation scheme used by the
+PPPM method to compute forces on particles given electrostatic
+potentials on the PPPM mesh. The *ik* approach is the default for
+PPPM and is the original formulation used in :ref:`(Hockney) <Hockney>`. It
+performs differentiation in Kspace, and uses 3 FFTs to transfer each
+component of the computed fields back to real space for total of 4
+FFTs per timestep.
+
+The analytic differentiation *ad* approach uses only 1 FFT to transfer
+information back to real space for a total of 2 FFTs per timestep. It
+then performs analytic differentiation on the single quantity to
+generate the 3 components of the electric field at each grid point.
+This is sometimes referred to as "smoothed" PPPM. This approach
+requires a somewhat larger PPPM mesh to achieve the same accuracy as
+the *ik* method. Currently, only the *ik* method (default) can be
+used for a triclinic simulation cell with PPPM. The *ad* method is
+always used for MSM.
+
+.. warning::
+
+ Currently, not all PPPM styles support the *ad*
+ option. Support for those PPPM variants will be added later.
+
+The *kmax/ewald* keyword sets the number of kspace vectors in each
+dimension for kspace style *ewald*. The three values must be positive
+integers, or else (0,0,0), which unsets the option. When this option
+is not set, the Ewald sum scheme chooses its own kspace vectors,
+consistent with the user-specified accuracy and pairwise cutoff. In
+any case, if kspace style *ewald* is invoked, the values used are
+printed to the screen and the log file at the start of the run.
+
+With the *mix/disp* keyword one can select the mixing rule for the
+dispersion coefficients. With *pair*, the dispersion coefficients of
+unlike types are computed as indicated with
+:doc:`pair_modify <pair_modify>`. With *geom*, geometric mixing is
+enforced on the dispersion coefficients in the kspace
+coefficients. When using the arithmetic mixing rule, this will
+speed-up the simulations but introduces some error in the force
+computations, as shown in :ref:`(Wennberg) <Wennberg>`. With *none*, it is
+assumed that no mixing rule is applicable. Splitting of the dispersion
+coefficients will be performed as described in
+:ref:`(Isele-Holder) <Isele-Holder>`. This splitting can be influenced with
+the *splittol* keywords. Only the eigenvalues that are larger than tol
+compared to the largest eigenvalues are included. Using this keywords
+the original matrix of dispersion coefficients is approximated. This
+leads to faster computations, but the accuracy in the reciprocal space
+computations of the dispersion part is decreased.
+
+The *force/disp/real* and *force/disp/kspace* keywords set the force
+accuracy for the real and space computations for the dispersion part
+of pppm/disp. As shown in :ref:`(Isele-Holder) <Isele-Holder>`, optimal
+performance and accuracy in the results is obtained when these values
+are different.
+
+The *disp/auto* option controlls whether the pppm/disp is allowed to
+generate PPPM parameters automatically. If set to *no*, parameters have
+to be specified using the *gewald/disp*, *mesh/disp*,
+*force/disp/real* or *force/disp/kspace* keywords, or
+the code will stop with an error message. When this option is set to
+*yes*, the error message will not appear and the simulation will start.
+For a typical application, using the automatic parameter generation will provide
+simulations that are either inaccurate or slow. Using this option is thus not
+recommended. For guidelines on how to obtain good parameters, see the :ref:`How-To <howto_23>` discussion.
+* style = *none* or *ewald* or *ewald/disp* or *ewald/omp* or *pppm* or *pppm/cg* or *pppm/disp* or *pppm/tip4p* or *pppm/stagger* or *pppm/disp/tip4p* or *pppm/gpu* or *pppm/omp* or *pppm/cg/omp* or *pppm/tip4p/omp* or *msm* or *msm/cg* or *msm/omp* or *msm/cg/omp*
+.. parsed-literal::
+
+ *none* value = none
+ *ewald* value = accuracy
+ accuracy = desired relative error in forces
+ *ewald/disp* value = accuracy
+ accuracy = desired relative error in forces
+ *ewald/omp* value = accuracy
+ accuracy = desired relative error in forces
+ *pppm* value = accuracy
+ accuracy = desired relative error in forces
+ *pppm/cg* value = accuracy (smallq)
+ accuracy = desired relative error in forces
+ smallq = cutoff for charges to be considered (optional) (charge units)
+ *pppm/disp* value = accuracy
+ accuracy = desired relative error in forces
+ *pppm/tip4p* value = accuracy
+ accuracy = desired relative error in forces
+ *pppm/disp/tip4p* value = accuracy
+ accuracy = desired relative error in forces
+ *pppm/gpu* value = accuracy
+ accuracy = desired relative error in forces
+ *pppm/omp* value = accuracy
+ accuracy = desired relative error in forces
+ *pppm/cg/omp* value = accuracy
+ accuracy = desired relative error in forces
+ *pppm/tip4p/omp* value = accuracy
+ accuracy = desired relative error in forces
+ *pppm/stagger* value = accuracy
+ accuracy = desired relative error in forces
+ *msm* value = accuracy
+ accuracy = desired relative error in forces
+ *msm/cg* value = accuracy (smallq)
+ accuracy = desired relative error in forces
+ smallq = cutoff for charges to be considered (optional) (charge units)
+ *msm/omp* value = accuracy
+ accuracy = desired relative error in forces
+ *msm/cg/omp* value = accuracy (smallq)
+ accuracy = desired relative error in forces
+ smallq = cutoff for charges to be considered (optional) (charge units)
+
+
+
+Examples
+""""""""
+
+.. parsed-literal::
+
+ kspace_style pppm 1.0e-4
+ kspace_style pppm/cg 1.0e-5 1.0e-6
+ kspace style msm 1.0e-4
+ kspace_style none
+
+Description
+"""""""""""
+
+Define a long-range solver for LAMMPS to use each timestep to compute
+long-range Coulombic interactions or long-range 1/r^6 interactions.
+Most of the long-range solvers perform their computation in K-space,
+hence the name of this command.
+
+When such a solver is used in conjunction with an appropriate pair
+style, the cutoff for Coulombic or 1/r^N interactions is effectively
+infinite. If the Coulombic case, this means each charge in the system
+interacts with charges in an infinite array of periodic images of the
+simulation domain.
+
+Note that using a long-range solver requires use of a matching :doc:`pair style <pair>` to perform consistent short-range pairwise
+calculations. This means that the name of the pair style contains a
+matching keyword to the name of the KSpace style, as in this table:
+
++----------------------+-----------------------+
+| Pair style | KSpace style |
++----------------------+-----------------------+
+| coul/long | ewald or pppm |
++----------------------+-----------------------+
+| coul/msm | msm |
++----------------------+-----------------------+
+| lj/long or buck/long | disp (for dispersion) |
++----------------------+-----------------------+
+| tip4p/long | tip4p |
++----------------------+-----------------------+
+
+
+----------
+
+
+The *ewald* style performs a standard Ewald summation as described in
+any solid-state physics text.
+
+The *ewald/disp* style adds a long-range dispersion sum option for
+1/r^6 potentials and is useful for simulation of interfaces
+:ref:`(Veld) <Veld>`. It also performs standard Coulombic Ewald summations,
+but in a more efficient manner than the *ewald* style. The 1/r^6
+capability means that Lennard-Jones or Buckingham potentials can be
+used without a cutoff, i.e. they become full long-range potentials.
+The *ewald/disp* style can also be used with point-dipoles
+:ref:`(Toukmaji) <Toukmaji>` and is currently the only kspace solver in
+LAMMPS with this capability.
+
+
+----------
+
+
+The *pppm* style invokes a particle-particle particle-mesh solver
+:ref:`(Hockney) <Hockney>` which maps atom charge to a 3d mesh, uses 3d FFTs
+to solve Poisson's equation on the mesh, then interpolates electric
+fields on the mesh points back to the atoms. It is closely related to
+the particle-mesh Ewald technique (PME) :ref:`(Darden) <Darden>` used in
+AMBER and CHARMM. The cost of traditional Ewald summation scales as
+N^(3/2) where N is the number of atoms in the system. The PPPM solver
+scales as Nlog(N) due to the FFTs, so it is almost always a faster
+choice :ref:`(Pollock) <Pollock>`.
+
+The *pppm/cg* style is identical to the *pppm* style except that it
+has an optimization for systems where most particles are uncharged.
+Similarly the *msm/cg* style implements the same optimization for *msm*.
+The optional *smallq* argument defines the cutoff for the absolute
+charge value which determines whether a particle is considered charged
+or not. Its default value is 1.0e-5.
+
+The *pppm/tip4p* style is identical to the *pppm* style except that it
+adds a charge at the massless 4th site in each TIP4P water molecule.
+It should be used with :doc:`pair styles <pair_style>` with a
+*tip4p/long* in their style name.
+
+The *pppm/stagger* style performs calculations using two different
+meshes, one shifted slightly with respect to the other. This can
+reduce force aliasing errors and increase the accuracy of the method
+for a given mesh size. Or a coarser mesh can be used for the same
+target accuracy, which saves CPU time. However, there is a trade-off
+since FFTs on two meshes are now performed which increases the
+compuation required. See :ref:`(Cerutti) <Cerutti>`, :ref:`(Neelov) <Neelov>`,
+and :ref:`(Hockney) <Hockney>` for details of the method.
+
+For high relative accuracy, using staggered PPPM allows the mesh size
+to be reduced by a factor of 2 in each dimension as compared to
+regular PPPM (for the same target accuracy). This can give up to a 4x
+speedup in the KSpace time (8x less mesh points, 2x more expensive).
+However, for low relative accuracy, the staggered PPPM mesh size may
+be essentially the same as for regular PPPM, which means the method
+will be up to 2x slower in the KSpace time (simply 2x more expensive).
+For more details and timings, see
+:doc:`Section_accelerate <Section_accelerate>`.
+
+.. warning::
+
+ Using *pppm/stagger* may not give the same increase in
+ the accuracy of energy and pressure as it does in forces, so some
+ caution must be used if energy and/or pressure are quantities of
+ interest, such as when using a barostat.
+
+
+----------
+
+
+The *pppm/disp* and *pppm/disp/tip4p* styles add a mesh-based long-range
+dispersion sum option for 1/r^6 potentials :ref:`(Isele-Holder) <Isele-Holder>`,
+similar to the *ewald/disp* style. The 1/r^6 capability means
+that Lennard-Jones or Buckingham potentials can be used without a cutoff,
+i.e. they become full long-range potentials.
+
+For these styles, you will possibly want to adjust the default choice of
+parameters by using the :doc:`kspace_modify <kspace_modify>` command.
+This can be done by either choosing the Ewald and grid parameters, or
+by specifying separate accuracies for the real and kspace
+calculations. When not making any settings, the simulation will stop with
+an error message. Further information on the influence of the parameters
+and how to choose them is described in :ref:`(Isele-Holder) <Isele-Holder>`,
+:ref:`(Isele-Holder2) <Isele-Holder2>` and the
+:ref:`How-To <howto_24>` discussion.
+
+
+----------
+
+
+.. warning::
+
+ All of the PPPM styles can be used with
+ single-precision FFTs by using the compiler switch -DFFT_SINGLE for
+ the FFT_INC setting in your lo-level Makefile. This setting also
+ changes some of the PPPM operations (e.g. mapping charge to mesh and
+ interpolating electric fields to particles) to be performed in single
+ precision. This option can speed-up long-range calulations,
+ particularly in parallel or on GPUs. The use of the -DFFT_SINGLE flag
+ is discussed in :ref:`this section <start_2_4>` of the
+ manual. MSM does not currently support the -DFFT_SINGLE compiler switch.
+
+
+----------
+
+
+The *msm* style invokes a multi-level summation method MSM solver,
+:ref:`(Hardy) <Hardy>` or :ref:`(Hardy2) <Hardy2>`, which maps atom charge to a 3d
+mesh, and uses a multi-level hierarchy of coarser and coarser meshes
+on which direct coulomb solves are done. This method does not use
+FFTs and scales as N. It may therefore be faster than the other
+K-space solvers for relatively large problems when running on large
+core counts. MSM can also be used for non-periodic boundary conditions and
+for mixed periodic and non-periodic boundaries.
+
+MSM is most competitive versus Ewald and PPPM when only relatively
+low accuracy forces, about 1e-4 relative error or less accurate,
+are needed. Note that use of a larger coulomb cutoff (i.e. 15
+angstroms instead of 10 angstroms) provides better MSM accuracy for
+both the real space and grid computed forces.
+
+Currently calculation of the full pressure tensor in MSM is expensive.
+Using the :doc:`kspace_modify <kspace_modify>` *pressure/scalar yes*
+command provides a less expensive way to compute the scalar pressure
+(Pxx + Pyy + Pzz)/3.0. The scalar pressure can be used, for example,
+to run an isotropic barostat. If the full pressure tensor is needed,
+then calculating the pressure at every timestep or using a fixed
+pressure simulation with MSM will cause the code to run slower.
+
+
+----------
+
+
+The specified *accuracy* determines the relative RMS error in per-atom
+forces calculated by the long-range solver. It is set as a
+dimensionless number, relative to the force that two unit point
+charges (e.g. 2 monovalent ions) exert on each other at a distance of
+1 Angstrom. This reference value was chosen as representative of the
+magnitude of electrostatic forces in atomic systems. Thus an accuracy
+value of 1.0e-4 means that the RMS error will be a factor of 10000
+smaller than the reference force.
+
+The accuracy setting is used in conjunction with the pairwise cutoff
+to determine the number of K-space vectors for style *ewald* or the
+grid size for style *pppm* or *msm*.
+
+Note that style *pppm* only computes the grid size at the beginning of
+a simulation, so if the length or triclinic tilt of the simulation
+cell increases dramatically during the course of the simulation, the
+accuracy of the simulation may degrade. Likewise, if the
+:doc:`kspace_modify slab <kspace_modify>` option is used with
+shrink-wrap boundaries in the z-dimension, and the box size changes
+dramatically in z. For example, for a triclinic system with all three
+tilt factors set to the maximum limit, the PPPM grid should be
+increased roughly by a factor of 1.5 in the y direction and 2.0 in the
+z direction as compared to the same system using a cubic orthogonal
+simulation cell. One way to ensure the accuracy requirement is being
+met is to run a short simulation at the maximum expected tilt or
+length, note the required grid size, and then use the
+:doc:`kspace_modify <kspace_modify>` *mesh* command to manually set the
+PPPM grid size to this value.
+
+RMS force errors in real space for *ewald* and *pppm* are estimated
+using equation 18 of :ref:`(Kolafa) <Kolafa>`, which is also referenced as
+equation 9 of :ref:`(Petersen) <Petersen>`. RMS force errors in K-space for
+*ewald* are estimated using equation 11 of :ref:`(Petersen) <Petersen>`,
+which is similar to equation 32 of :ref:`(Kolafa) <Kolafa>`. RMS force
+errors in K-space for *pppm* are estimated using equation 38 of
+:ref:`(Deserno) <Deserno>`. RMS force errors for *msm* are estimated
+using ideas from chapter 3 of :ref:`(Hardy) <Hardy>`, with equation 3.197
+of particular note. When using *msm* with non-periodic boundary
+conditions, it is expected that the error estimation will be too
+pessimistic. RMS force errors for dipoles when using *ewald/disp*
+are estimated using equations 33 and 46 of :ref:`(Wang) <Wang>`.
+
+See the :doc:`kspace_modify <kspace_modify>` command for additional
+options of the K-space solvers that can be set, including a *force*
+option for setting an absoulte RMS error in forces, as opposed to a
+relative RMS error.
+
+
+----------
+
+
+Styles with a *cuda*, *gpu*, *intel*, *kk*, *omp*, or *opt* suffix are
+functionally the same as the corresponding style without the suffix.
+They have been optimized to run faster, depending on your available
+hardware, as discussed in :doc:`Section_accelerate <Section_accelerate>`
+of the manual. The accelerated styles take the same arguments and
+should produce the same results, except for round-off and precision
+issues.
+
+More specifically, the *pppm/gpu* style performs charge assignment and
+force interpolation calculations on the GPU. These processes are
+performed either in single or double precision, depending on whether
+the -DFFT_SINGLE setting was specified in your lo-level Makefile, as
+discussed above. The FFTs themselves are still calculated on the CPU.
+If *pppm/gpu* is used with a GPU-enabled pair style, part of the PPPM
+calculation can be performed concurrently on the GPU while other
+calculations for non-bonded and bonded force calculation are performed
+on the CPU.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
+KOKKOS, USER-OMP, and OPT packages respectively. They are only
+enabled if LAMMPS was built with those packages. See the :ref:`Making LAMMPS <start_3>` section for more info.
+
+See :doc:`Section_accelerate <Section_accelerate>` of the manual for
+more instructions on how to use the accelerated styles effectively.
+
+Restrictions
+""""""""""""
+
+
+Note that the long-range electrostatic solvers in LAMMPS assume conducting
+metal (tinfoil) boundary conditions for both charge and dipole
+interactions. Vacuum boundary conditions are not currently supported.
+
+The *ewald/disp*, *ewald*, *pppm*, and *msm* styles support
+non-orthogonal (triclinic symmetry) simulation boxes. However, triclinic
+simulation cells may not yet be supported by suffix versions of these
+styles (such as *pppm/cuda*).
+
+All of the kspace styles are part of the KSPACE package. They are
+only enabled if LAMMPS was built with that package. See the :ref:`Making LAMMPS <start_3>` section for more info. Note that
+the KSPACE package is installed by default.
+
+For MSM, a simulation must be 3d and one can use any combination of
+periodic, non-periodic, or shrink-wrapped boundaries (specified using
+the :doc:`boundary <boundary>` command).
+
+For Ewald and PPPM, a simulation must be 3d and periodic in all dimensions.
+The only exception is if the slab option is set with :doc:`kspace_modify <kspace_modify>`,
+in which case the xy dimensions must be periodic and the z dimension must be
+* etol = stopping tolerance for energy (unitless)
+* ftol = stopping tolerance for force (force units)
+* maxiter = max iterations of minimizer
+* maxeval = max number of force/energy evaluations
+
+Examples
+""""""""
+
+.. parsed-literal::
+
+ minimize 1.0e-4 1.0e-6 100 1000
+ minimize 0.0 1.0e-8 1000 100000
+
+Description
+"""""""""""
+
+Perform an energy minimization of the system, by iteratively adjusting
+atom coordinates. Iterations are terminated when one of the stopping
+criteria is satisfied. At that point the configuration will hopefully
+be in local potential energy minimum. More precisely, the
+configuration should approximate a critical point for the objective
+function (see below), which may or may not be a local minimum.
+
+The minimization algorithm used is set by the
+:doc:`min_style <min_style>` command. Other options are set by the
+:doc:`min_modify <min_modify>` command. Minimize commands can be
+interspersed with :doc:`run <run>` commands to alternate between
+relaxation and dynamics. The minimizers bound the distance atoms move
+in one iteration, so that you can relax systems with highly overlapped
+atoms (large energies and forces) by pushing the atoms off of each
+other.
+
+Alternate means of relaxing a system are to run dynamics with a small
+or :doc:`limited timestep <fix_nve_limit>`. Or dynamics can be run
+using :doc:`fix viscous <fix_viscous>` to impose a damping force that
+slowly drains all kinetic energy from the system. The :doc:`pair_style soft <pair_soft>` potential can be used to un-overlap atoms while
+running dynamics.
+
+Note that you can minimize some atoms in the system while holding the
+coordiates of other atoms fixed by applying :doc:`fix setforce <fix_setforce>` to the other atoms. See a fuller
+discussion of using fixes while minimizing below.
+
+The :doc:`minimization styles <min_style>` *cg*, *sd*, and *hftn*
+involves an outer iteration loop which sets the search direction along
+which atom coordinates are changed. An inner iteration is then
+performed using a line search algorithm. The line search typically
+evaluates forces and energies several times to set new coordinates.
+Currently, a backtracking algorithm is used which may not be optimal
+in terms of the number of force evaulations performed, but appears to
+be more robust than previous line searches we've tried. The
+backtracking method is described in Nocedal and Wright's Numerical
+Optimization (Procedure 3.1 on p 41).
+
+The :doc:`minimization styles <min_style>` *quickmin* and *fire* perform
+damped dynamics using an Euler integration step. Thus they require a
+:doc:`timestep <timestep>` be defined.
+
+.. warning::
+
+ The damped dynamic minimizers use whatever timestep
+ you have defined via the :doc:`timestep <timestep>` command. Often they
+ will converge more quickly if you use a timestep about 10x larger than
+ you would normally use for dynamics simulations.
+
+
+----------
+
+
+In all cases, the objective function being minimized is the total
+potential energy of the system as a function of the N atom
+coordinates:
+
+.. image:: Eqs/min_energy.jpg
+ :align: center
+
+where the first term is the sum of all non-bonded :doc:`pairwise interactions <pair_style>` including :doc:`long-range Coulombic interactions <kspace_style>`, the 2nd thru 5th terms are
+as do the GROMACS potentials (e.g. :doc:`pair_style lj/gromacs <pair_gromacs>`).
+
+If a soft potential (:doc:`pair_style soft <pair_soft>`) is used the
+Astop value is used for the prefactor (no time dependence).
+
+The :doc:`fix box/relax <fix_box_relax>` command can be used to apply an
+external pressure to the simulation box and allow it to shrink/expand
+during the minimization.
+
+Only a few other fixes (typically those that apply force constraints)
+are invoked during minimization. See the doc pages for individual
+:doc:`fix <fix>` commands to see which ones are relevant. Current
+examples of fixes that can be used include:
+
+* :doc:`fix addforce <fix_addforce>`
+* :doc:`fix addtorque <fix_addtorque>`
+* :doc:`fix efield <fix_efield>`
+* :doc:`fix enforce2d <fix_enforce2d>`
+* :doc:`fix indent <fix_indent>`
+* :doc:`fix lineforce <fix_lineforce>`
+* :doc:`fix planeforce <fix_planeforce>`
+* :doc:`fix setforce <fix_setforce>`
+* :doc:`fix spring <fix_spring>`
+* :doc:`fix spring/self <fix_spring_self>`
+* :doc:`fix viscous <fix_viscous>`
+* :doc:`fix wall <fix_wall>`
+* :doc:`fix wall/region <fix_wall_region>`
+
+.. warning::
+
+ Some fixes which are invoked during minimization have
+ an associated potential energy. For that energy to be included in the
+ total potential energy of the system (the quantity being minimized),
+ you MUST enable the :doc:`fix_modify <fix_modify>` *energy* option for
+ that fix. The doc pages for individual :doc:`fix <fix>` commands
+ specify if this should be done.
+
+
+----------
+
+
+Restrictions
+""""""""""""
+
+
+Features that are not yet implemented are listed here, in case someone
+knows how they could be coded:
+
+It is an error to use :doc:`fix shake <fix_shake>` with minimization
+because it turns off bonds that should be included in the potential
+energy of the system. The effect of a fix shake can be approximated
+during a minimization by using stiff spring constants for the bonds
+and/or angles that would normally be constrained by the SHAKE
+algorithm.
+
+:doc:`Fix rigid <fix_rigid>` is also not supported by minimization. It
+is not an error to have it defined, but the energy minimization will
+not keep the defined body(s) rigid during the minimization. Note that
+if bonds, angles, etc internal to a rigid body have been turned off
+(e.g. via :doc:`neigh_modify exclude <neigh_modify>`), they will not
+contribute to the potential energy which is probably not what is
+desired.
+
+Pair potentials that produce torque on a particle (e.g. :doc:`granular potentials <pair_gran>` or the :doc:`GayBerne potential <pair_gayberne>` for ellipsoidal particles) are not
+relaxed by a minimization. More specifically, radial relaxations are
+induced, but no rotations are induced by a minimization, so such a
+* etol = stopping tolerance for energy (energy units)
+* ftol = stopping tolerance for force (force units)
+* N1 = max # of iterations (timesteps) to run initial NEB
+* N2 = max # of iterations (timesteps) to run barrier-climbing NEB
+* Nevery = print replica energies and reaction coordinates every this many timesteps
+* file-style= *final* or *each* or *none*
+.. parsed-literal::
+
+ *final* arg = filename
+ filename = file with initial coords for final replica
+ coords for intermediate replicas are linearly interpolated between first and last replica
+ *each* arg = filename
+ filename = unique filename for each replica (except first) with its initial coords
+ *none* arg = no argument
+ all replicas assumed to already have their initial coords
+
+
+
+Examples
+""""""""
+
+.. parsed-literal::
+
+ neb 0.1 0.0 1000 500 50 final coords.final
+ neb 0.0 0.001 1000 500 50 each coords.initial.$i
+ neb 0.0 0.001 1000 500 50 none
+
+Description
+"""""""""""
+
+Perform a nudged elastic band (NEB) calculation using multiple
+replicas of a system. Two or more replicas must be used; the first
+and last are the end points of the transition path.
+
+NEB is a method for finding both the atomic configurations and height
+of the energy barrier associated with a transition state, e.g. for an
+atom to perform a diffusive hop from one energy basin to another in a
+coordinated fashion with its neighbors. The implementation in LAMMPS
+follows the discussion in these 3 papers: :ref:`(Henkelman1) <Henkelman1>`,
+:ref:`(Henkelman2) <Henkelman2>`, and :ref:`(Nakano) <Nakano>`.
+
+Each replica runs on a partition of one or more processors. Processor
+partitions are defined at run-time using the -partition command-line
+switch; see :ref:`Section_start 7 <start_7>` of the
+manual. Note that if you have MPI installed, you can run a
+multi-replica simulation with more replicas (partitions) than you have
+physical processors, e.g you can run a 10-replica simulation on just
+one or two processors. You will simply not get the performance
+speed-up you would see with one or more physical processors per
+replica. See :ref:`this section <howto_5>` of the manual
+for further discussion.
+
+.. warning::
+
+ The current NEB implementation in LAMMPS only allows
+ there to be one processor per replica.
+
+.. warning::
+
+ As explained below, a NEB calculation perfoms a damped
+ dynamics minimization across all the replicas. The mimimizer uses
+ whatever timestep you have defined in your input script, via the
+ :doc:`timestep <timestep>` command. Often NEB will converge more
+ quickly if you use a timestep about 10x larger than you would normally
+ use for dynamics simulations.
+
+When a NEB calculation is performed, it is assumed that each replica
+is running the same system, though LAMMPS does not check for this.
+I.e. the simulation domain, the number of atoms, the interaction
+potentials, and the starting configuration when the neb command is
+issued should be the same for every replica.
+
+In a NEB calculation each atom in a replica is connected to the same
+atom in adjacent replicas by springs, which induce inter-replica
+forces. These forces are imposed by the :doc:`fix neb <fix_neb>`
+command, which must be used in conjunction with the neb command. The
+group used to define the fix neb command defines the NEB atoms which
+are the only ones that inter-replica springs are applied to. If the
+group does not include all atoms, then non-NEB atoms have no
+inter-replica springs and the forces they feel and their motion is
+computed in the usual way due only to other atoms within their
+replica. Conceptually, the non-NEB atoms provide a background force
+field for the NEB atoms. They can be allowed to move during the NEB
+minimiation procedure (which will typically induce different
+coordinates for non-NEB atoms in different replicas), or held fixed
+using other LAMMPS commands such as `fix setforce <fix_setforce>`_. Note
+that the :doc:`partition <partition>` command can be used to invoke a
+command on a subset of the replicas, e.g. if you wish to hold NEB or
+non-NEB atoms fixed in only the end-point replicas.
+
+The initial atomic configuration for each of the replicas can be
+specified in different manners via the *file-style* setting, as
+discussed below. Only atoms whose initial coordinates should differ
+from the current configuration need be specified.
+
+Conceptually, the initial configuration for the first replica should
+be a state with all the atoms (NEB and non-NEB) having coordinates on
+one side of the energy barrier. A perfect energy minimum is not
+required, since atoms in the first replica experience no spring forces
+from the 2nd replica. Thus the damped dynamics minimizaiton will
+drive the first replica to an energy minimum if it is not already
+there. However, you will typically get better convergence if the
+initial state is already at a minimum. For example, for a system with
+a free surface, the surface should be fully relaxed before attempting
+a NEB calculation.
+
+Likewise, the initial configuration of the final replica should be a
+state with all the atoms (NEB and non-NEB) on the other side of the
+energy barrier. Again, a perfect energy minimum is not required,
+since the atoms in the last replica also experience no spring forces
+from the next-to-last replica, and thus the damped dynamics
+minimization will drive it to an energy minimum.
+
+As explained below, the initial configurations of intermediate
+replicas can be atomic coordinates interpolated in a linear fashion
+between the first and last replicas. This is often adequate state for
+simple transitions. For more complex transitions, it may lead to slow
+convergence or even bad results if the minimum energy path (MEP, see
+below) of states over the barrier cannot be correctly converged to
+from such an initial configuration. In this case, you will want to
+generate initial states for the intermediate replicas that are
+geometrically closer to the MEP and read them in.
+
+
+----------
+
+
+For a *file-style* setting of *final*, a filename is specified which
+contains atomic coordinates for zero or more atoms, in the format
+described below. For each atom that appears in the file, the new
+coordinates are assigned to that atom in the final replica. Each
+intermediate replica also assigns a new position to that atom in an
+interpolated manner. This is done by using the current position of
+the atom as the starting point and the read-in position as the final
+point. The distance between them is calculated, and the new position
+is assigned to be a fraction of the distance. E.g. if there are 10
+replicas, the 2nd replica will assign a position that is 10% of the
+distance along a line between the starting and final point, and the
+9th replica will assign a position that is 90% of the distance along
+the line. Note that this procedure to produce consistent coordinates
+across all the replicas, the current coordinates need to be the same
+in all replicas. LAMMPS does not check for this, but invalid initial
+configurations will likely result if it is not the case.
+
+.. note::
+
+ The "distance" between the starting and final point is
+ calculated in a minimum-image sense for a periodic simulation box.
+ This means that if the two positions are on opposite sides of a box
+ (periodic in that dimension), the distance between them will be small,
+ because the periodic image of one of the atoms is close to the other.
+ Similarly, even if the assigned position resulting from the
+ interpolation is outside the periodic box, the atom will be wrapped
+ back into the box when the NEB calculation begins.
+
+For a *file-style* setting of *each*, a filename is specified which is
+assumed to be unique to each replica. This can be done by
+using a variable in the filename, e.g.
+
+.. parsed-literal::
+
+ variable i equal part
+ neb 0.0 0.001 1000 500 50 each coords.initial.$i
+
+which in this case will substitute the partition ID (0 to N-1) for the
+variable I, which is also effectively the replica ID. See the
+:doc:`variable <variable>` command for other options, such as using
+world-, universe-, or uloop-style variables.
+
+Each replica (except the first replica) will read its file, formatted
+as described below, and for any atom that appears in the file, assign
+the specified coordinates to its atom. The various files do not need
+to contain the same set of atoms.
+
+For a *file-style* setting of *none*, no filename is specified. Each
+replica is assumed to already be in its initial configuration at the
+time the neb command is issued. This allows each replica to define
+its own configuration by reading a replica-specific data or restart or
+dump file, via the :doc:`read_data <read_data>`,
+:doc:`read_restart <read_restart>`, or :doc:`read_dump <read_dump>`
+commands. The replica-specific names of these files can be specified
+as in the discussion above for the *each* file-style. Also see the
+section below for how a NEB calculation can produce restart files, so
+that a long calculation can be restarted if needed.
+
+.. warning::
+
+ None of the *file-style* settings change the initial
+ configuration of any atom in the first replica. The first replica
+ must thus be in the correct initial configuration at the time the neb
+ command is issued.
+
+
+----------
+
+
+A NEB calculation proceeds in two stages, each of which is a
+minimization procedure, performed via damped dynamics. To enable
+this, you must first define a damped dynamics
+:doc:`min_style <min_style>`, such as *quickmin* or *fire*. The *cg*,
+*sd*, and *hftn* styles cannot be used, since they perform iterative
+line searches in their inner loop, which cannot be easily synchronized
+across multiple replicas.
+
+The minimizer tolerances for energy and force are set by *etol* and
+*ftol*, the same as for the :doc:`minimize <minimize>` command.
+
+A non-zero *etol* means that the NEB calculation will terminate if the
+energy criterion is met by every replica. The energies being compared
+to *etol* do not include any contribution from the inter-replica
+forces, since these are non-conservative. A non-zero *ftol* means
+that the NEB calculation will terminate if the force criterion is met
+by every replica. The forces being compared to *ftol* include the
+inter-replica forces between an atom and its images in adjacent
+replicas.
+
+The maximum number of iterations in each stage is set by *N1* and
+*N2*. These are effectively timestep counts since each iteration of
+damped dynamics is like a single timestep in a dynamics
+:doc:`run <run>`. During both stages, the potential energy of each
+replica and its normalized distance along the reaction path (reaction
+coordinate RD) will be printed to the screen and log file every
+*Nevery* timesteps. The RD is 0 and 1 for the first and last replica.
+For intermediate replicas, it is the cumulative distance (normalized
+by the total cumulative distance) between adjacent replicas, where
+"distance" is defined as the length of the 3N-vector of differences in
+atomic coordinates, where N is the number of NEB atoms involved in the
+transition. These outputs allow you to monitor NEB's progress in
+finding a good energy barrier. *N1* and *N2* must both be multiples
+of *Nevery*.
+
+In the first stage of NEB, the set of replicas should converge toward
+the minimum energy path (MEP) of conformational states that transition
+over the barrier. The MEP for a barrier is defined as a sequence of
+3N-dimensional states that cross the barrier at its saddle point, each
+of which has a potential energy gradient parallel to the MEP itself.
+The replica states will also be roughly equally spaced along the MEP
+due to the inter-replica spring force added by the :doc:`fix neb <fix_neb>` command.
+
+In the second stage of NEB, the replica with the highest energy
+is selected and the inter-replica forces on it are converted to a
+force that drives its atom coordinates to the top or saddle point of
+the barrier, via the barrier-climbing calculation described in
+:ref:`(Henkelman2) <Hinkelman2>`. As before, the other replicas rearrange
+themselves along the MEP so as to be roughly equally spaced.
+
+When both stages are complete, if the NEB calculation was successful,
+one of the replicas should be an atomic configuration at the top or
+saddle point of the barrier, the potential energies for the set of
+replicas should represent the energy profile of the barrier along the
+MEP, and the configurations of the replicas should be a sequence of
+configurations along the MEP.
+
+
+----------
+
+
+A few other settings in your input script are required or advised to
+perform a NEB calculation. See the IMPORTANT NOTE about the choice of
+timestep at the beginning of this doc page.
+
+An atom map must be defined which it is not by default for :doc:`atom_style atomic <atom_style>` problems. The :doc:`atom_modify map <atom_modify>` command can be used to do this.
+
+The "atom_modify sort 0 0.0" command should be used to turn off atom
+sorting.
+
+.. note::
+
+ This sorting restriction will be removed in a future version of
+ NEB in LAMMPS.
+
+The minimizers in LAMMPS operate on all atoms in your system, even
+non-NEB atoms, as defined above. To prevent non-NEB atoms from moving
+during the minimization, you should use the :doc:`fix setforce <fix_setforce>` command to set the force on each of those
+atoms to 0.0. This is not required, and may not even be desired in
+some cases, but if those atoms move too far (e.g. because the initial
+state of your system was not well-minimized), it can cause problems
+for the NEB procedure.
+
+The damped dynamics :doc:`minimizers <min_style>`, such as *quickmin*
+and *fire*), adjust the position and velocity of the atoms via an
+Euler integration step. Thus you must define an appropriate
+:doc:`timestep <timestep>` to use with NEB. As mentioned above, NEB
+will often converge more quickly if you use a timestep about 10x
+larger than you would normally use for dynamics simulations.
+
+
+----------
+
+
+Each file read by the neb command containing atomic coordinates used
+to initialize one or more replicas must be formatted as follows.
+
+The file can be ASCII text or a gzipped text file (detected by a .gz
+suffix). The file can contain initial blank lines or comment lines
+starting with "#" which are ignored. The first non-blank, non-comment
+line should list N = the number of lines to follow. The N successive
+lines contain the following information:
+
+.. parsed-literal::
+
+ ID1 x1 y1 z1
+ ID2 x2 y2 z2
+ ...
+ IDN xN yN zN
+
+The fields are the the atom ID, followed by the x,y,z coordinates.
+The lines can be listed in any order. Additional trailing information
+on the line is OK, such as a comment.
+
+Note that for a typical NEB calculation you do not need to specify
+initial coordinates for very many atoms to produce differing starting
+and final replicas whose intermediate replicas will converge to the
+energy barrier. Typically only new coordinates for atoms
+geometrically near the barrier need be specified.
+
+Also note there is no requirement that the atoms in the file
+correspond to the NEB atoms in the group defined by the :doc:`fix neb <fix_neb>` command. Not every NEB atom need be in the file,
+and non-NEB atoms can be listed in the file.
+
+
+----------
+
+
+Four kinds of output can be generated during a NEB calculation: energy
+barrier statistics, thermodynamic output by each replica, dump files,
+and restart files.
+
+When running with multiple partitions (each of which is a replica in
+this case), the print-out to the screen and master log.lammps file
+contains a line of output, printed once every *Nevery* timesteps. It
+contains the timestep, the maximum force per replica, the maximum
+force per atom (in any replica), potential gradients in the initial,
+ final, and climbing replicas,
+the forward and backward energy barriers,
+the total reaction coordinate (RDT), and
+the normalized reaction coordinate and potential energy of each replica.
+
+The "maximum force per replica" is
+the two-norm of the 3N-length force vector for the atoms in each
+replica, maximized across replicas, which is what the *ftol* setting
+is checking against. In this case, N is all the atoms in each
+replica. The "maximum force per atom" is the maximum force component
+of any atom in any replica. The potential gradients are the two-norm
+of the 3N-length force vector solely due to the interaction potential i.e.
+without adding in inter-replica forces. Note that inter-replica forces
+are zero in the initial and final replicas, and only affect
+the direction in the climbing replica. For this reason, the "maximum
+force per replica" is often equal to the potential gradient in the
+climbing replica. In the first stage of NEB, there is no climbing
+replica, and so the potential gradient in the highest energy replica
+is reported, since this replica will become the climbing replica
+in the second stage of NEB.
+
+The "reaction coordinate" (RD) for each
+replica is the two-norm of the 3N-length vector of distances between
+its atoms and the preceding replica's atoms, added to the RD of the
+preceding replica. The RD of the first replica RD1 = 0.0;
+the RD of the final replica RDN = RDT, the total reaction coordinate.
+The normalized RDs are divided by RDT,
+so that they form a monotonically increasing sequence
+from zero to one. When computing RD, N only includes the atoms
+being operated on by the fix neb command.
+
+The forward (reverse) energy barrier is the potential energy of the highest
+replica minus the energy of the first (last) replica.
+
+When running on multiple partitions, LAMMPS produces additional log
+files for each partition, e.g. log.lammps.0, log.lammps.1, etc. For a
+NEB calculation, these contain the thermodynamic output for each
+replica.
+
+If :doc:`dump <dump>` commands in the input script define a filename
+that includes a *universe* or *uloop* style :doc:`variable <variable>`,
+then one dump file (per dump command) will be created for each
+replica. At the end of the NEB calculation, the final snapshot in
+each file will contain the sequence of snapshots that transition the
+system over the energy barrier. Earlier snapshots will show the
+convergence of the replicas to the MEP.
+
+Likewise, :doc:`restart <restart>` filenames can be specified with a
+*universe* or *uloop* style :doc:`variable <variable>`, to generate
+restart files for each replica. These may be useful if the NEB
+calculation fails to converge properly to the MEP, and you wish to
+restart the calculation from an intermediate point with altered
+parameters.
+
+There are 2 Python scripts provided in the tools/python directory,
+neb_combine.py and neb_final.py, which are useful in analyzing output
+from a NEB calculation. Assume a NEB simulation with M replicas, and
+the NEB atoms labelled with a specific atom type.
+
+The neb_combine.py script extracts atom coords for the NEB atoms from
+all M dump files and creates a single dump file where each snapshot
+contains the NEB atoms from all the replicas and one copy of non-NEB
+atoms from the first replica (presumed to be identical in other
+replicas). This can be visualized/animated to see how the NEB atoms
+relax as the NEB calculation proceeds.
+
+The neb_final.py script extracts the final snapshot from each of the M
+dump files to create a single dump file with M snapshots. This can be
+visualized to watch the system make its transition over the energy
+barrier.
+
+To illustrate, here are images from the final snapshot produced by the
+neb_combine.py script run on the dump files produced by the two
+example input scripts in examples/neb. Click on them to see a larger
+image.
+
+.. thumbnail:: JPG/hop1.jpg
+
+.. thumbnail:: JPG/hop2.jpg
+
+
+----------
+
+
+Restrictions
+""""""""""""
+
+
+This command can only be used if LAMMPS was built with the REPLICA
+package. See the :ref:`Making LAMMPS <start_3>` section
+Styles *brownian* and *brownain/poly* compute Brownian forces and
+torques on finite-size particles. The former requires monodisperse
+spherical particles; the latter allows for polydisperse spherical
+particles.
+
+These pair styles are designed to be used with either the :doc:`pair_style lubricate <pair_lubricate>` or :doc:`pair_style lubricateU <pair_lubricateU>` commands to provide thermostatting
+when dissipative lubrication forces are acting. Thus the parameters
+*mu*, *flaglog*, *flagfld*, *cutinner*, and *cutoff* should be
+specified consistent with the settings in the lubrication pair styles.
+For details, refer to either of the lubrication pair styles.
+
+The *t_target* setting is used to specify the target temperature of
+the system. The random number *seed* is used to generate random
+numbers for the thermostatting procedure.
+
+The *flagHI* and *flagVF* settings are optional. Neither should be
+used, or both must be defined.
+
+
+----------
+
+
+The following coefficients must be defined for each pair of atoms
+types via the :doc:`pair_coeff <pair_coeff>` command as in the examples
+above, or in the data file or restart files read by the
+:doc:`read_data <read_data>` or :doc:`read_restart <read_restart>`
+commands, or by mixing as described below:
+
+* cutinner (distance units)
+* cutoff (distance units)
+
+The two coefficients are optional. If neither is specified, the two
+cutoffs specified in the pair_style command are used. Otherwise both
+must be specified.
+
+
+----------
+
+
+Styles with a *cuda*, *gpu*, *intel*, *kk*, *omp*, or *opt* suffix are
+functionally the same as the corresponding style without the suffix.
+They have been optimized to run faster, depending on your available
+hardware, as discussed in :doc:`this section <Section_accelerate>` of
+the manual. The accelerated styles take the same arguments and should
+produce the same results, except for round-off and precision issues.
+
+These accelerated styles are part of the USER-CUDA, GPU, USER-INTEL,
+KOKKOS, USER-OMP and OPT packages, respectively. They are only
+enabled if LAMMPS was built with those packages. See the :ref:`Making LAMMPS <start_3>` section for more info.
+
+You can specify the accelerated styles explicitly in your input script
+by including their suffix, or you can use the :ref:`-suffix command-line switch <start_7>` when you invoke LAMMPS, or you can
+use the :doc:`suffix <suffix>` command in your input script.
+
+See :doc:`this section <Section_accelerate>` of the manual for more
+instructions on how to use the accelerated styles effectively.
+* style = *born/coul/long/cs* or *buck/coul/long/cs*
+* args = list of arguments for a particular style
+
+.. parsed-literal::
+
+ *born/coul/long/cs* args = cutoff (cutoff2)
+ cutoff = global cutoff for non-Coulombic (and Coulombic if only 1 arg) (distance units)
+ cutoff2 = global cutoff for Coulombic (optional) (distance units)
+ *buck/coul/long/cs* args = cutoff (cutoff2)
+ cutoff = global cutoff for Buckingham (and Coulombic if only 1 arg) (distance units)
+ cutoff2 = global cutoff for Coulombic (optional) (distance units)
+
+Examples
+""""""""
+
+.. parsed-literal::
+
+ pair_style born/coul/long/cs 10.0 8.0
+ pair_coeff 1 1 6.08 0.317 2.340 24.18 11.51
+
+.. parsed-literal::
+
+ pair_style buck/coul/long/cs 10.0
+ pair_style buck/coul/long/cs 10.0 8.0
+ pair_coeff * * 100.0 1.5 200.0
+ pair_coeff 1 1 100.0 1.5 200.0 9.0
+
+Description
+"""""""""""
+
+These pair styles are designed to be used with the adiabatic
+core/shell model of :ref:`(Mitchell and Finchham) <MitchellFinchham>`. See
+:ref:`Section_howto 25 <howto_25>` of the manual for an
+overview of the model as implemented in LAMMPS.
+
+These pair styles are identical to the :doc:`pair_style born/coul/long <pair_born>` and :doc:`pair_style buck/coul/long <pair_buck>` styles, except they correctly treat the
+special case where the distance between two charged core and shell
+atoms in the same core/shell pair approach r = 0.0. This needs
+special treatment when a long-range solver for Coulombic interactions
+is also used, i.e. via the :doc:`kspace_style <kspace_style>` command.
+
+More specifically, the short-range Coulomb interaction between a core
+and its shell should be turned off using the
+:doc:`special_bonds <special_bonds>` command by setting the 1-2 weight
+to 0.0, which works because the core and shell atoms are bonded to
+each other. This induces a long-range correction approximation which
+fails at small distances (~< 10e-8). Therefore, the Coulomb term which
+is used to calculate the correction factor is extended by a minimal
+distance (r_min = 1.0-6) when the interaction between a core/shell
+pair is treated, as follows
+
+.. image:: Eqs/pair_cs.jpg
+ :align: center
+
+where C is an energy-conversion constant, Qi and Qj are the charges on
+the core and shell, epsilon is the dielectric constant and r_min is the
+minimal distance.
+
+Restrictions
+""""""""""""
+
+
+These pair styles are part of the CORESHELL package. They are only
+enabled if LAMMPS was built with that package. See the :ref:`Making LAMMPS <start_3>` section for more info.
+
+Related commands
+""""""""""""""""
+
+:doc:`pair_coeff <pair_coeff>`, :doc:`pair_style born <pair_born>`,
+:doc:`pair_style buck <pair_buck>`
+
+**Default:** none
+
+
+----------
+
+
+.. _MitchellFinchham:
+
+
+
+**(Mitchell and Finchham)** Mitchell, Finchham, J Phys Condensed Matter,
+* style = *lj/cut/soft* or *lj/cut/coul/cut/soft* or *lj/cut/coul/long/soft* or *lj/cut/tip4p/long/soft* or *lj/charmm/coul/long/soft* or *coul/cut/soft* or *coul/long/soft* or *tip4p/long/soft*
+* args = list of arguments for a particular style
+
+.. parsed-literal::
+
+ *lj/cut/soft* args = n alpha_lj cutoff
+ n, alpha_LJ = parameters of soft-core potential
+ cutoff = global cutoff for Lennard-Jones interactions (distance units)
+ *lj/cut/coul/cut/soft* args = n alpha_LJ alpha_C cutoff (cutoff2)
+ n, alpha_LJ, alpha_C = parameters of soft-core potential
+ cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
+ cutoff2 = global cutoff for Coulombic (optional) (distance units)
+ *lj/cut/coul/long/soft* args = n alpha_LJ alpha_C cutoff
+ n, alpha_LJ, alpha_C = parameters of the soft-core potential
+ cutoff = global cutoff for LJ (and Coulombic if only 1 arg) (distance units)
+ cutoff2 = global cutoff for Coulombic (optional) (distance units)
+* cutoff = outer cutoff for interactions (distance units)
+* flagHI (optional) = 0/1 to exclude/include 1/r hydrodynamic interactions
+* flagVF (optional) = 0/1 to exclude/include volume fraction corrections in the long-range isotropic terms
+
+**Examples:** (all assume radius = 1)
+
+.. parsed-literal::
+
+ pair_style lubricate 1.5 1 1 2.01 2.5
+ pair_coeff 1 1 2.05 2.8
+ pair_coeff * *
+
+.. parsed-literal::
+
+ pair_style lubricate 1.5 1 1 2.01 2.5
+ pair_coeff * *
+ variable mu equal ramp(1,2)
+ fix 1 all adapt 1 pair lubricate mu * * v_mu
+
+Description
+"""""""""""
+
+Styles *lubricate* and *lubricate/poly* compute hydrodynamic
+interactions between mono-disperse spherical particles in a pairwise
+fashion. The interactions have 2 components. The first is
+Ball-Melrose lubrication terms via the formulas in :ref:`(Ball and Melrose) <Ball>`
+
+.. image:: Eqs/pair_lubricate.jpg
+ :align: center
+
+which represents the dissipation W between two nearby particles due to
+their relative velocities in the presence of a background solvent with
+viscosity *mu*. Note that this is dynamic viscosity which has units of
+mass/distance/time, not kinematic viscosity.
+
+The Asq (squeeze) term is the strongest and is included if *flagHI* is
+set to 1 (default). It scales as 1/gap where gap is the separation
+between the surfaces of the 2 particles. The Ash (shear) and Apu
+(pump) terms are only included if *flaglog* is set to 1. They are the
+next strongest interactions, and the only other singular interaction,
+and scale as log(gap). Note that *flaglog* = 1 and *flagHI* = 0 is
+invalid, and will result in a warning message, after which *flagHI* will
+be set to 1. The Atw (twist) term is currently not included. It is
+typically a very small contribution to the lubrication forces.
+
+The *flagHI* and *flagVF* settings are optional. Neither should be
+used, or both must be defined.
+
+*Cutinner* sets the minimum center-to-center separation that will be
+used in calculations irrespective of the actual separation. *Cutoff*
+is the maximum center-to-center separation at which an interaction is
+computed. Using a *cutoff* less than 3 radii is recommended if
+*flaglog* is set to 1.
+
+The other component is due to the Fast Lubrication Dynamics (FLD)
+approximation, described in :ref:`(Kumar) <Kumar>`, which can be
+represented by the following equation
+
+.. image:: Eqs/fld.jpg
+ :align: center
+
+where U represents the velocities and angular velocities of the
+particles, U^*infty* represents the velocity and the angular velocity
+of the undisturbed fluid, and E^*infty* represents the rate of strain
+tensor of the undisturbed fluid with viscosity *mu*. Again, note that
+this is dynamic viscosity which has units of mass/distance/time, not
+kinematic viscosity. Volume fraction corrections to R_FU are included
+as long as *flagVF* is set to 1 (default).
+
+.. warning::
+
+ When using the FLD terms, these pair styles are
+ designed to be used with explicit time integration and a
+ correspondingly small timestep. Thus either :doc:`fix nve/sphere <fix_nve_sphere>` or :doc:`fix nve/asphere <fix_nve_asphere>` should be used for time integration.
+ To perform implicit FLD, see the :doc:`pair_style lubricateU <pair_lubricateU>` command.
+This pair style does not support the :doc:`pair_modify <pair_modify>`
+shift option for the energy of the pair interaction. Note that as
+discussed above, the energy term is already shifted to be 0.0 at the
+cutoff distance *rc*.
+
+The :doc:`pair_modify <pair_modify>` table option is not relevant for
+this pair style.
+
+This pair style does not support the :doc:`pair_modify <pair_modify>`
+tail option for adding long-range tail corrections to energy and
+pressure.
+
+This pair style writes global and per-atom information to :doc:`binary restart files <restart>`. Pair srp should be used with :doc:`pair_style hybrid <pair_hybrid>`, thus the pair_coeff commands need to be
+specified in the input script when reading a restart file.
+
+This pair style can only be used via the *pair* keyword of the
+:doc:`run_style respa <run_style>` command. It does not support the
+*inner*, *middle*, *outer* keywords.
+
+
+----------
+
+
+Restrictions
+""""""""""""
+
+
+This pair style is part of the USER-MISC package. It is only enabled
+if LAMMPS was built with that package. See the Making LAMMPS section
+for more info.
+
+This pair style must be used with :doc:`pair_style hybrid <pair_hybrid>`.
+
+This pair style requires the :doc:`newton <newton>` command to be *on*
+Run a parallel replica dynamics (PRD) simulation using multiple
+replicas of a system. One or more replicas can be used. The total
+number of steps *N* to run can be interpreted in one of two ways; see
+discussion of the *time* keyword below.
+
+PRD is described in :ref:`this paper <Voter>` by Art Voter. It is a method
+for performing accelerated dynamics that is suitable for
+infrequent-event systems that obey first-order kinetics. A good
+overview of accelerated dynamics methods for such systems in given in
+:ref:`this review paper <Voter2>` from the same group. To quote from the
+paper: "The dynamical evolution is characterized by vibrational
+excursions within a potential basin, punctuated by occasional
+transitions between basins." The transition probability is
+characterized by p(t) = k*exp(-kt) where k is the rate constant.
+Running multiple replicas gives an effective enhancement in the
+timescale spanned by the multiple simulations, while waiting for an
+event to occur.
+
+Each replica runs on a partition of one or more processors. Processor
+partitions are defined at run-time using the -partition command-line
+switch; see :ref:`Section_start 6 <start_7>` of the
+manual. Note that if you have MPI installed, you can run a
+multi-replica simulation with more replicas (partitions) than you have
+physical processors, e.g you can run a 10-replica simulation on one or
+two processors. For PRD, this makes little sense, since this offers
+no effective parallel speed-up in searching for infrequent events. See
+:ref:`Section_howto 5 <howto_5>` of the manual for further
+discussion.
+
+When a PRD simulation is performed, it is assumed that each replica is
+running the same model, though LAMMPS does not check for this.
+I.e. the simulation domain, the number of atoms, the interaction
+potentials, etc should be the same for every replica.
+
+A PRD run has several stages, which are repeated each time an "event"
+occurs in one of the replicas, as defined below. The logic for a PRD
+run is as follows:
+
+.. parsed-literal::
+
+ while (time remains):
+ dephase for n_dephase*t_dephase steps
+ until (event occurs on some replica):
+ run dynamics for t_event steps
+ quench
+ check for uncorrelated event on any replica
+ until (no correlated event occurs):
+ run dynamics for t_correlate steps
+ quench
+ check for correlated event on this replica
+ event replica shares state with all replicas
+
+Before this loop begins, the state of the system on replica 0 is
+shared with all replicas, so that all replicas begin from the same
+initial state. The first potential energy basin is identified by
+quenching (an energy minimization, see below) the initial state and
+storing the resulting coordinates for reference.
+
+In the first stage, dephasing is performed by each replica
+independently to eliminate correlations between replicas. This is
+done by choosing a random set of velocities, based on the
+*random_seed* that is specified, and running *t_dephase* timesteps of
+dynamics. This is repeated *n_dephase* times. At each of the
+*n_dephase* stages, if an event occurs during the *t_dephase* steps of
+dynamics for a particular replica, the replica repeats the stage until
+no event occurs.
+
+If the *temp* keyword is not specified, the target temperature for
+velocity randomization for each replica is the current temperature of
+that replica. Otherwise, it is the specified *Tdephase* temperature.
+The style of velocity randomization is controlled using the keyword
+*vel* with arguments that have the same meaning as their counterparts
+in the :doc:`velocity <velocity>` command.
+
+In the second stage, each replica runs dynamics continuously, stopping
+every *t_event* steps to check if a transition event has occurred.
+This check is performed by quenching the system and comparing the
+resulting atom coordinates to the coordinates from the previous basin.
+The first time through the PRD loop, the "previous basin" is the set
+of quenched coordinates from the initial state of the system.
+
+A quench is an energy minimization and is performed by whichever
+algorithm has been defined by the :doc:`min_style <min_style>` command.
+Minimization parameters may be set via the
+:doc:`min_modify <min_modify>` command and by the *min* keyword of the
+PRD command. The latter are the settings that would be used with the
+:doc:`minimize <minimize>` command. Note that typically, you do not
+need to perform a highly-converged minimization to detect a transition
+event.
+
+The event check is performed by a compute with the specified
+*compute-ID*. Currently there is only one compute that works with the
+PRD commmand, which is the :doc:`compute event/displace <compute_event_displace>` command. Other
+event-checking computes may be added. :doc:`Compute event/displace <compute_event_displace>` checks whether any atom in
+the compute group has moved further than a specified threshold
+distance. If so, an "event" has occurred.
+
+In the third stage, the replica on which the event occurred (event
+replica) continues to run dynamics to search for correlated events.
+This is done by running dynamics for *t_correlate* steps, quenching
+every *t_event* steps, and checking if another event has occurred.
+
+The first time no correlated event occurs, the final state of the
+event replica is shared with all replicas, the new basin reference
+coordinates are updated with the quenched state, and the outer loop
+begins again. While the replica event is searching for correlated
+events, all the other replicas also run dynamics and event checking
+with the same schedule, but the final states are always overwritten by
+the state of the event replica.
+
+The outer loop of the pseudo-code above continues until *N* steps of
+dynamics have been performed. Note that *N* only includes the
+dynamics of stages 2 and 3, not the steps taken during dephasing or
+the minimization iterations of quenching. The specified *N* is
+interpreted in one of two ways, depending on the *time* keyword. If
+the *time* value is *step*, which is the default, then each replica
+runs for *N* timesteps. If the *time* value is *clock*, then the
+simulation runs until *N* aggregate timesteps across all replicas have
+elapsed. This aggregate time is the "clock" time defined below, which
+typically advances nearly M times faster than the timestepping on a
+single replica.
+
+
+----------
+
+
+Four kinds of output can be generated during a PRD run: event
+statistics, thermodynamic output by each replica, dump files, and
+restart files.
+
+When running with multiple partitions (each of which is a replica in
+this case), the print-out to the screen and master log.lammps file is
+limited to event statistics. Note that if a PRD run is performed on
+only a single replica then the event statistics will be intermixed
+with the usual thermodynamic output discussed below.
+
+The quantities printed each time an event occurs are the timestep, CPU
+time, clock, event number, a correlation flag, the number of
+coincident events, and the replica number of the chosen event.
+
+The timestep is the usual LAMMPS timestep, except that time does not
+advance during dephasing or quenches, but only during dynamics. Note
+that are two kinds of dynamics in the PRD loop listed above. The
+first is when all replicas are performing independent dynamics,
+waiting for an event to occur. The second is when correlated events
+are being searched for and only one replica is running dynamics.
+
+The CPU time is the total processor time since the start of the PRD
+run.
+
+The clock is the same as the timestep except that it advances by M
+steps every timestep during the first kind of dynamics when the M
+replicas are running independently. The clock advances by only 1 step
+per timestep during the second kind of dynamics, since only a single
+replica is checking for a correlated event. Thus "clock" time
+represents the aggregate time (in steps) that effectively elapses
+during a PRD simulation on M replicas. If most of the PRD run is
+spent in the second stage of the loop above, searching for infrequent
+events, then the clock will advance nearly M times faster than it
+would if a single replica was running. Note the clock time between
+events will be drawn from p(t).
+
+The event number is a counter that increments with each event, whether
+it is uncorrelated or correlated.
+
+The correlation flag will be 0 when an uncorrelated event occurs
+during the second stage of the loop listed above, i.e. when all
+replicas are running independently. The correlation flag will be 1
+when a correlated event occurs during the third stage of the loop
+listed above, i.e. when only one replica is running dynamics.
+
+When more than one replica detects an event at the end of the second
+stage, then one of them is chosen at random. The number of coincident
+events is the number of replicas that detected an event. Normally, we
+expect this value to be 1. If it is often greater than 1, then either
+the number of replicas is too large, or *t_event* is too large.
+
+The replica number is the ID of the replica (from 0 to M-1) that
+found the event.
+
+
+----------
+
+
+When running on multiple partitions, LAMMPS produces additional log
+files for each partition, e.g. log.lammps.0, log.lammps.1, etc. For
+the PRD command, these contain the thermodynamic output for each
+replica. You will see short runs and minimizations corresponding to
+the dynamics and quench operations of the loop listed above. The
+timestep will be reset aprpopriately depending on whether the
+operation advances time or not.
+
+After the PRD command completes, timing statistics for the PRD run are
+printed in each replica's log file, giving a breakdown of how much CPU
+time was spent in each stage (dephasing, dynamics, quenching, etc).
+
+
+----------
+
+
+Any :doc:`dump files <dump>` defined in the input script, will be
+written to during a PRD run at timesteps corresponding to both
+uncorrelated and correlated events. This means the the requested dump
+frequency in the :doc:`dump <dump>` command is ignored. There will be
+one dump file (per dump command) created for all partitions.
+
+The atom coordinates of the dump snapshot are those of the minimum
+energy configuration resulting from quenching following a transition
+event. The timesteps written into the dump files correspond to the
+timestep at which the event occurred and NOT the clock. A dump
+snapshot corresponding to the initial minimum state used for event
+detection is written to the dump file at the beginning of each PRD
+run.
+
+
+----------
+
+
+If the :doc:`restart <restart>` command is used, a single restart file
+for all the partitions is generated, which allows a PRD run to be
+continued by a new input script in the usual manner.
+
+The restart file is generated at the end of the loop listed above. If
+no correlated events are found, this means it contains a snapshot of
+the system at time T + *t_correlate*, where T is the time at which the
+uncorrelated event occurred. If correlated events were found, then it
+contains a snapshot of the system at time T + *t_correlate*, where T
+is the time of the last correlated event.
+
+The restart frequency specified in the :doc:`restart <restart>` command
+is interpreted differently when performing a PRD run. It does not
+mean the timestep interval between restart files. Instead it means an
+event interval for uncorrelated events. Thus a frequency of 1 means
+write a restart file every time an uncorrelated event occurs. A
+frequency of 10 means write a restart file every 10th uncorrelated
+event.
+
+When an input script reads a restart file from a previous PRD run, the
+new script can be run on a different number of replicas or processors.
+However, it is assumed that *t_correlate* in the new PRD command is
+the same as it was previously. If not, the calculation of the "clock"
+value for the first event in the new run will be slightly off.
+
+
+----------
+
+
+Restrictions
+""""""""""""
+
+
+This command can only be used if LAMMPS was built with the REPLICA
+package. See the :ref:`Making LAMMPS <start_3>` section
+for more info on packages.
+
+*N* and *t_correlate* settings must be integer multiples of
+*t_event*.
+
+Runs restarted from restart file written during a PRD run will not
+produce identical results due to changes in the random numbers used
+for dephasing.
+
+This command cannot be used when any fixes are defined that keep track
+of elapsed time to perform time-dependent operations. Examples
+include the "ave" fixes such as :doc:`fix ave/spatial <fix_ave_spatial>`. Also :doc:`fix dt/reset <fix_dt_reset>` and :doc:`fix deposit <fix_deposit>`.
+* keyword = *add* or *offset* or *shift* or *extra/atom/types* or *extra/bond/types* or *extra/angle/types* or *extra/dihedral/types* or *extra/improper/types* or *group* or *fix*
+.. parsed-literal::
+
+ *add* arg = *append* or *Nstart* or *merge*
+ append = add new atoms with IDs appended to current IDs
+ Nstart = add new atoms with IDs starting with Nstart
+ merge = add new atoms with their IDs unchanged
+ *offset* args = toff boff aoff doff ioff
+ toff = offset to add to atom types
+ boff = offset to add to bond types
+ aoff = offset to add to angle types
+ doff = offset to add to dihedral types
+ ioff = offset to add to improper types
+ *shift* args = Sx Sy Sz
+ Sx,Sy,Sz = distance to shift atoms when adding to system (distance units)
+ *extra/atom/types* arg = # of extra atom types
+ *extra/bond/types* arg = # of extra bond types
+ *extra/angle/types* arg = # of extra angle types
+ *extra/dihedral/types* arg = # of extra dihedral types
+ *extra/improper/types* arg = # of extra improper types
+* style = *atom* or *type* or *mol* or *group* or *region*
+* ID = atom ID range or type range or mol ID range or group ID or region ID
+* one or more keyword/value pairs may be appended
+* keyword = *type* or *type/fraction* or *mol* or *x* or *y* or *z* or *charge* or *dipole* or *dipole/random* or *quat* or *quat/random* or *diameter* or *shape* or *length* or *tri* or *theta* or *angmom* or *mass* or *density* or *volume* or *image* or
+ *bond* or *angle* or *dihedral* or *improper* or
+ *meso_e* or *meso_cv* or *meso_rho* or *i_name* or *d_name*
+.. parsed-literal::
+
+ *type* value = atom type
+ value can be an atom-style variable (see below)
+ *type/fraction* values = type fraction seed
+ type = new atom type
+ fraction = fraction of selected atoms to set to new atom type
+ seed = random # seed (positive integer)
+ *mol* value = molecule ID
+ value can be an atom-style variable (see below)
+ *x*,*y*,*z* value = atom coordinate (distance units)
+ value can be an atom-style variable (see below)
+ *charge* value = atomic charge (charge units)
+ value can be an atom-style variable (see below)
+ *dipole* values = x y z
+ x,y,z = orientation of dipole moment vector
+ any of x,y,z can be an atom-style variable (see below)
+ *dipole/random* value = seed Dlen
+ seed = random # seed (positive integer) for dipole moment orientations
+ Dlen = magnitude of dipole moment (dipole units)
+ *quat* values = a b c theta
+ a,b,c = unit vector to rotate particle around via right-hand rule
+ theta = rotation angle (degrees)
+ any of a,b,c,theta can be an atom-style variable (see below)
+ *quat/random* value = seed
+ seed = random # seed (positive integer) for quaternion orientations
+ *diameter* value = diameter of spherical particle (distance units)
+ value can be an atom-style variable (see below)
+ *shape* value = Sx Sy Sz
+ Sx,Sy,Sz = 3 diameters of ellipsoid (distance units)
+ *length* value = len
+ len = length of line segment (distance units)
+ len can be an atom-style variable (see below)
+ *tri* value = side
+ side = side length of equilateral triangle (distance units)
+ side can be an atom-style variable (see below)
+ *theta* value = angle (degrees)
+ angle = orientation of line segment with respect to x-axis
+ angle can be an atom-style variable (see below)
+ *angmom* values = Lx Ly Lz
+ Lx,Ly,Lz = components of angular momentum vector (distance-mass-velocity units)
+ any of Lx,Ly,Lz can be an atom-style variable (see below)
+ *mass* value = per-atom mass (mass units)
+ value can be an atom-style variable (see below)
+ *density* value = particle density for sphere or ellipsoid (mass/distance^3 or mass/distance^2 or mass/distance units, depending on dimensionality of particle)
+ value can be an atom-style variable (see below)
+ *volume* value = particle volume for Peridynamic particle (distance^3 units)
+ value can be an atom-style variable (see below)
+ *image* nx ny nz
+ nx,ny,nz = which periodic image of the simulation box the atom is in
+ *bond* value = bond type for all bonds between selected atoms
+ *angle* value = angle type for all angles between selected atoms
+ *dihedral* value = dihedral type for all dihedrals between selected atoms
+ *improper* value = improper type for all impropers between selected atoms
+ *meso_e* value = energy of SPH particles (need units)
+ value can be an atom-style variable (see below)
+ *meso_cv* value = heat capacity of SPH particles (need units)
+ value can be an atom-style variable (see below)
+ *meso_rho* value = density of SPH particles (need units)
+ value can be an atom-style variable (see below)
+ *i_name* value = value for custom integer vector with name
+ value can be an atom-style variable (see below)
+ *d_name* value = value for custom floating-point vector with name
+ value can be an atom-style variable (see below)
+
+
+
+Examples
+""""""""
+
+.. parsed-literal::
+
+ set group solvent type 2
+ set group solvent type/fraction 2 0.5 12393
+ set group edge bond 4
+ set region half charge 0.5
+ set type 3 charge 0.5
+ set type 1*3 charge 0.5
+ set atom * charge v_atomfile
+ set atom 100*200 x 0.5 y 1.0
+ set atom 1492 type 3
+
+Description
+"""""""""""
+
+Set one or more properties of one or more atoms. Since atom
+properties are initially assigned by the :doc:`read_data <read_data>`,
+:doc:`read_restart <read_restart>` or :doc:`create_atoms <create_atoms>`
+commands, this command changes those assignments. This can be useful
+for overriding the default values assigned by the
+:doc:`create_atoms <create_atoms>` command (e.g. charge = 0.0). It can
+be useful for altering pairwise and molecular force interactions,
+since force-field coefficients are defined in terms of types. It can
+be used to change the labeling of atoms by atom type or molecule ID
+when they are output in :doc:`dump <dump>` files. It can also be useful
+for debugging purposes; i.e. positioning an atom at a precise location
+to compute subsequent forces or energy.
+
+Note that the *style* and *ID* arguments determine which atoms have
+their properties reset. The remaining keywords specify which
+properties to reset and what the new values are. Some strings like
+*type* or *mol* can be used as a style and/or a keyword.
+
+
+----------
+
+
+This section describes how to select which atoms to change
+the properties of, via the *style* and *ID* arguments.
+
+The style *atom* selects all the atoms in a range of atom IDs. The
+style *type* selects all the atoms in a range of types. The style
+*mol* selects all the atoms in a range of molecule IDs.
+
+In each of the range cases, the range can be specified as a single
+numeric value, or a wildcard asterisk can be used to specify a range
+of values. This takes the form "*" or "*n" or "n*" or "m*n". For
+example, for the style *type*, if N = the number of atom types, then
+an asterisk with no numeric values means all types from 1 to N. A
+leading asterisk means all types from 1 to n (inclusive). A trailing
+asterisk means all types from n to N (inclusive). A middle asterisk
+means all types from m to n (inclusive). For all the styles except
+*mol*, the lowest value for the wildcard is 1; for *mol* it is 0.
+
+The style *group* selects all the atoms in the specified group. The
+style *region* selects all the atoms in the specified geometric
+region. See the :doc:`group <group>` and :doc:`region <region>` commands
+for details of how to specify a group or region.
+
+
+----------
+
+
+This section describes the keyword options for which properties to
+change, for the selected atoms.
+
+Note that except where explicitly prohibited below, all of the
+keywords allow an :doc:`atom-style or atomfile-style variable <variable>` to be used as the specified value(s). If the
+value is a variable, it should be specified as v_name, where name is
+the variable name. In this case, the variable will be evaluated, and
+its resulting per-atom value used to determine the value assigned to
+each selected atom. Note that the per-atom value from the variable
+will be ignored for atoms that are not selected via the *style* and
+*ID* settings explained above. A simple way to use per-atom values
+from the variable to reset a property for all atoms is to use style
+*atom* with *ID* = "*"; this selects all atom IDs.
+
+Atom-style variables can specify formulas with various mathematical
+functions, and include :doc:`thermo_style <thermo_style>` command
+keywords for the simulation box parameters and timestep and elapsed
+time. They can also include per-atom values, such as atom
+coordinates. Thus it is easy to specify a time-dependent or
+spatially-dependent set of per-atom values. As explained on the
+:doc:`variable <variable>` doc page, atomfile-style variables can be
+used in place of atom-style variables, and thus as arguments to the
+set command. Atomfile-style variables read their per-atoms values
+from a file.
+
+.. warning::
+
+ Atom-style and atomfile-style variables return
+ floating point per-atom values. If the values are assigned to an
+ integer variable, such as the molecule ID, then the floating point
+ value is truncated to its integer portion, e.g. a value of 2.6 would
+ become 2.
+
+Keyword *type* sets the atom type for all selected atoms. The
+specified value must be from 1 to ntypes, where ntypes was set by the
+:doc:`create_box <create_box>` command or the *atom types* field in the
+header of the data file read by the :doc:`read_data <read_data>`
+command.
+
+Keyword *type/fraction* sets the atom type for a fraction of the
+selected atoms. The actual number of atoms changed is not guaranteed
+to be exactly the requested fraction, but should be statistically
+close. Random numbers are used in such a way that a particular atom
+is changed or not changed, regardless of how many processors are being
+used. This keyword does not allow use of an atom-style variable.
+
+Keyword *mol* sets the molecule ID for all selected atoms. The :doc:`atom style <atom_style>` being used must support the use of molecule
+IDs.
+
+Keywords *x*, *y*, *z*, and *charge* set the coordinates or charge of
+all selected atoms. For *charge*, the :doc:`atom style <atom_style>`
+being used must support the use of atomic charge.
+
+Keyword *dipole* uses the specified x,y,z values as components of a
+vector to set as the orientation of the dipole moment vectors of the
+selected atoms. The magnitude of the dipole moment is set
+by the length of this orientation vector.
+
+Keyword *dipole/random* randomizes the orientation of the dipole
+moment vectors of the selected atoms and sets the magnitude of each to
+the specified *Dlen* value. For 2d systems, the z component of the
+orientation is set to 0.0. Random numbers are used in such a way that
+the orientation of a particular atom is the same, regardless of how
+many processors are being used. This keyword does not allow use of an
+atom-style variable.
+
+Keyword *quat* uses the specified values to create a quaternion
+(4-vector) that represents the orientation of the selected atoms. The
+particles must be ellipsoids as defined by the :doc:`atom_style ellipsoid <atom_style>` command or triangles as defined by the
+:doc:`atom_style tri <atom_style>` command. Note that particles defined
+by :doc:`atom_style ellipsoid <atom_style>` have 3 shape parameters.
+The 3 values must be non-zero for each particle set by this command.
+They are used to specify the aspect ratios of an ellipsoidal particle,
+which is oriented by default with its x-axis along the simulation
+box's x-axis, and similarly for y and z. If this body is rotated (via
+the right-hand rule) by an angle theta around a unit rotation vector
+(a,b,c), then the quaternion that represents its new orientation is
+given by (cos(theta/2), a*sin(theta/2), b*sin(theta/2),
+c*sin(theta/2)). The theta and a,b,c values are the arguments to the
+*quat* keyword. LAMMPS normalizes the quaternion in case (a,b,c) was
+not specified as a unit vector. For 2d systems, the a,b,c values are
+ignored, since a rotation vector of (0,0,1) is the only valid choice.
+
+Keyword *quat/random* randomizes the orientation of the quaternion of
+the selected atoms. The particles must be ellipsoids as defined by
+the :doc:`atom_style ellipsoid <atom_style>` command or triangles as
+defined by the :doc:`atom_style tri <atom_style>` command. Random
+numbers are used in such a way that the orientation of a particular
+atom is the same, regardless of how many processors are being used.
+For 2d systems, only orientations in the xy plane are generated. As
+with keyword *quat*, for ellipsoidal particles, the 3 shape values
+must be non-zero for each particle set by this command. This keyword
+does not allow use of an atom-style variable.
+
+Keyword *diameter* sets the size of the selected atoms. The particles
+must be finite-size spheres as defined by the :doc:`atom_style sphere <atom_style>` command. The diameter of a particle can be
+set to 0.0, which means they will be treated as point particles. Note
+that this command does not adjust the particle mass, even if it was
+defined with a density, e.g. via the :doc:`read_data <read_data>`
+command.
+
+Keyword *shape* sets the size and shape of the selected atoms. The
+particles must be ellipsoids as defined by the :doc:`atom_style ellipsoid <atom_style>` command. The *Sx*, *Sy*, *Sz* settings are
+the 3 diameters of the ellipsoid in each direction. All 3 can be set
+to the same value, which means the ellipsoid is effectively a sphere.
+They can also all be set to 0.0 which means the particle will be
+treated as a point particle. Note that this command does not adjust
+the particle mass, even if it was defined with a density, e.g. via the
+:doc:`read_data <read_data>` command.
+
+Keyword *length* sets the length of selected atoms. The particles
+must be line segments as defined by the :doc:`atom_style line <atom_style>` command. If the specified value is non-zero the
+line segment is (re)set to a length = the specified value, centered
+around the particle position, with an orientation along the x-axis.
+If the specified value is 0.0, the particle will become a point
+particle. Note that this command does not adjust the particle mass,
+even if it was defined with a density, e.g. via the
+:doc:`read_data <read_data>` command.
+
+Keyword *tri* sets the size of selected atoms. The particles must be
+triangles as defined by the :doc:`atom_style tri <atom_style>` command.
+If the specified value is non-zero the triangle is (re)set to be an
+equilateral triangle in the xy plane with side length = the specified
+value, with a centroid at the particle position, with its base
+parallel to the x axis, and the y-axis running from the center of the
+base to the top point of the triangle. If the specified value is 0.0,
+the particle will become a point particle. Note that this command
+does not adjust the particle mass, even if it was defined with a
+density, e.g. via the :doc:`read_data <read_data>` command.
+
+Keyword *theta* sets the orientation of selected atoms. The particles
+must be line segments as defined by the :doc:`atom_style line <atom_style>` command. The specified value is used to set the
+orientation angle of the line segments with respect to the x axis.
+
+Keyword *angmom* sets the angular momentum of selected atoms. The
+particles must be ellipsoids as defined by the :doc:`atom_style ellipsoid <atom_style>` command or triangles as defined by the
+:doc:`atom_style tri <atom_style>` command. The angular momentum vector
+of the particles is set to the 3 specified components.
+
+Keyword *mass* sets the mass of all selected particles. The particles
+must have a per-atom mass attribute, as defined by the
+:doc:`atom_style <atom_style>` command. See the "mass" command for how
+to set mass values on a per-type basis.
+
+Keyword *density* also sets the mass of all selected particles, but in
+a different way. The particles must have a per-atom mass attribute,
+as defined by the :doc:`atom_style <atom_style>` command. If the atom
+has a radius attribute (see :doc:`atom_style sphere <atom_style>`) and
+its radius is non-zero, its mass is set from the density and particle
+volume. If the atom has a shape attribute (see :doc:`atom_style ellipsoid <atom_style>`) and its 3 shape parameters are non-zero,
+then its mass is set from the density and particle volume. If the
+atom has a length attribute (see :doc:`atom_style line <atom_style>`)
+and its length is non-zero, then its mass is set from the density and
+line segment length (the input density is assumed to be in
+mass/distance units). If the atom has an area attribute (see
+:doc:`atom_style tri <atom_style>`) and its area is non-zero, then its
+mass is set from the density and triangle area (the input density is
+assumed to be in mass/distance^2 units). If none of these cases are
+valid, then the mass is set to the density value directly (the input
+density is assumed to be in mass units).
+
+Keyword *volume* sets the volume of all selected particles.
+Currently, only the :doc:`atom_style peri <atom_style>` command defines
+particles with a volume attribute. Note that this command does not
+adjust the particle mass.
+
+Keyword *image* sets which image of the simulation box the atom is
+considered to be in. An image of 0 means it is inside the box as
+defined. A value of 2 means add 2 box lengths to get the true value.
+A value of -1 means subtract 1 box length to get the true value.
+LAMMPS updates these flags as atoms cross periodic boundaries during
+the simulation. The flags can be output with atom snapshots via the
+:doc:`dump <dump>` command. If a value of NULL is specified for any of
+nx,ny,nz, then the current image value for that dimension is
+unchanged. For non-periodic dimensions only a value of 0 can be
+specified. This keyword does not allow use of atom-style variables.
+
+This command can be useful after a system has been equilibrated and
+atoms have diffused one or more box lengths in various directions.
+This command can then reset the image values for atoms so that they
+are effectively inside the simulation box, e.g if a diffusion
+coefficient is about to be measured via the :doc:`compute msd <compute_msd>` command. Care should be taken not to reset the
+image flags of two atoms in a bond to the same value if the bond
+straddles a periodic boundary (rather they should be different by +/-
+1). This will not affect the dynamics of a simulation, but may mess
+up analysis of the trajectories if a LAMMPS diagnostic or your own
+analysis relies on the image flags to unwrap a molecule which
+straddles the periodic box.
+
+Keywords *bond*, *angle*, *dihedral*, and *improper*, set the bond
+type (angle type, etc) of all bonds (angles, etc) of selected atoms to
+the specified value from 1 to nbondtypes (nangletypes, etc). All
+atoms in a particular bond (angle, etc) must be selected atoms in
+order for the change to be made. The value of nbondtype (nangletypes,
+etc) was set by the *bond types* (*angle types*, etc) field in the
+header of the data file read by the :doc:`read_data <read_data>`
+command. These keywords do not allow use of an atom-style variable.
+
+Keywords *meso_e*, *meso_cv*, and *meso_rho* set the energy, heat
+capacity, and density of smmothed particle hydrodynamics (SPH)
+particles. See `this PDF guide <USER/sph/SPH_LAMMPS_userguide.pdf>`_ to
+using SPH in LAMMPS.
+
+Keywords *i_name* and *d_name* refer to custom integer and
+floating-point properties that have been added to each atom via the
+:doc:`fix property/atom <fix_property_atom>` command. When that command
+is used specific names are given to each attribute which are what is
+specified as the "name" portion of *i_name* or *d_name*.
+
+Restrictions
+""""""""""""
+
+
+You cannot set an atom attribute (e.g. *mol* or *q* or *volume*) if
+the :doc:`atom_style <atom_style>` does not have that attribute.
+
+This command requires inter-processor communication to coordinate the
+setting of bond types (angle types, etc). This means that your system
+must be ready to perform a simulation before using one of these
+keywords (force fields set, atom mass set, etc). This is not
+necessary for other keywords.
+
+Using the *region* style with the bond (angle, etc) keywords can give
+unpredictable results if there are bonds (angles, etc) that straddle
+periodic boundaries. This is because the region may only extend up to
+the boundary and partner atoms in the bond (angle, etc) may have
+coordinates outside the simulation box if they are ghost atoms.
+* compute-ID = ID of the compute used for event detection
+* zero or more keyword/value pairs may be appended
+* keyword = *min* or *neb* or *min_style* or *neb_style* or *neb_log*
+.. parsed-literal::
+
+ *min* values = etol ftol maxiter maxeval
+ etol = stopping tolerance for energy (energy units)
+ ftol = stopping tolerance for force (force units)
+ maxiter = max iterations of minimize
+ maxeval = max number of force/energy evaluations
+ *neb* values = ftol N1 N2 Nevery
+ etol = stopping tolerance for energy (energy units)
+ ftol = stopping tolerance for force (force units)
+ N1 = max # of iterations (timesteps) to run initial NEB
+ N2 = max # of iterations (timesteps) to run barrier-climbing NEB
+ Nevery = print NEB statistics every this many timesteps
+ *neb_style* value = *quickmin* or *fire*
+ *neb_step* value = dtneb
+ dtneb = timestep for NEB damped dynamics minimization
+ *neb_log* value = file where NEB statistics are printed
+
+
+
+Examples
+""""""""
+
+.. parsed-literal::
+
+ tad 2000 50 1800 2300 0.01 0.01 event
+ tad 2000 50 1800 2300 0.01 0.01 event &
+ min 1e-05 1e-05 100 100 &
+ neb 0.0 0.01 200 200 20 &
+ min_style cg &
+ neb_style fire &
+ neb_log log.neb
+
+Description
+"""""""""""
+
+Run a temperature accelerated dynamics (TAD) simulation. This method
+requires two or more partitions to perform NEB transition state
+searches.
+
+TAD is described in :ref:`this paper <Voter>` by Art Voter. It is a method
+that uses accelerated dynamics at an elevated temperature to generate
+results at a specified lower temperature. A good overview of
+accelerated dynamics methods for such systems is given in :ref:`this review paper <Voter2>` from the same group. In general, these methods assume
+that the long-time dynamics is dominated by infrequent events i.e. the
+system is is confined to low energy basins for long periods,
+punctuated by brief, randomly-occurring transitions to adjacent
+basins. TAD is suitable for infrequent-event systems, where in
+addition, the transition kinetics are well-approximated by harmonic
+transition state theory (hTST). In hTST, the temperature dependence of
+transition rates follows the Arrhenius relation. As a consequence a
+set of event times generated in a high-temperature simulation can be
+mapped to a set of much longer estimated times in the low-temperature
+system. However, because this mapping involves the energy barrier of
+the transition event, which is different for each event, the first
+event at the high temperature may not be the earliest event at the low
+temperature. TAD handles this by first generating a set of possible
+events from the current basin. After each event, the simulation is
+reflected backwards into the current basin. This is repeated until
+the stopping criterion is satisfied, at which point the event with the
+earliest low-temperature occurrence time is selected. The stopping
+criterion is that the confidence measure be greater than
+1-*delta*. The confidence measure is the probability that no earlier
+low-temperature event will occur at some later time in the
+high-temperature simulation. hTST provides an lower bound for this
+probability, based on the user-specified minimum pre-exponential
+factor (reciprocal of *tmax*).
+
+In order to estimate the energy barrier for each event, the TAD method
+invokes the :doc:`NEB <neb>` method. Each NEB replica runs on a
+partition of processors. The current NEB implementation in LAMMPS
+restricts you to having exactly one processor per replica. For more
+information, see the documentation for the :doc:`neb <neb>` command. In
+the current LAMMPS implementation of TAD, all the non-NEB TAD
+operations are performed on the first partition, while the other
+partitions remain idle. See :ref:`Section_howto 5 <howto_5>` of the manual for further discussion of
+multi-replica simulations.
+
+A TAD run has several stages, which are repeated each time an event is
+performed. The logic for a TAD run is as follows:
+
+.. parsed-literal::
+
+ while (time remains):
+ while (time < tstop):
+ until (event occurs):
+ run dynamics for t_event steps
+ quench
+ run neb calculation using all replicas
+ compute tlo from energy barrier
+ update earliest event
+ update tstop
+ reflect back into current basin
+ execute earliest event
+
+Before this outer loop begins, the initial potential energy basin is
+identified by quenching (an energy minimization, see below) the
+initial state and storing the resulting coordinates for reference.
+
+Inside the inner loop, dynamics is run continuously according to
+whatever integrator has been specified by the user, stopping every
+*t_event* steps to check if a transition event has occurred. This
+check is performed by quenching the system and comparing the resulting
+atom coordinates to the coordinates from the previous basin.
+
+A quench is an energy minimization and is performed by whichever
+algorithm has been defined by the :doc:`min_style <min_style>` command;
+its default is the CG minimizer. The tolerances and limits for each
+quench can be set by the *min* keyword. Note that typically, you do
+not need to perform a highly-converged minimization to detect a
+transition event.
+
+The event check is performed by a compute with the specified
+*compute-ID*. Currently there is only one compute that works with the
+TAD commmand, which is the :doc:`compute event/displace <compute_event_displace>` command. Other
+event-checking computes may be added. :doc:`Compute event/displace <compute_event_displace>` checks whether any atom in
+the compute group has moved further than a specified threshold
+distance. If so, an "event" has occurred.
+
+The NEB calculation is similar to that invoked by the :doc:`neb <neb>`
+command, except that the final state is generated internally, instead
+of being read in from a file. The style of minimization performed by
+NEB is determined by the *neb_style* keyword and must be a damped
+dynamics minimizer. The tolerances and limits for each NEB
+calculation can be set by the *neb* keyword. As discussed on the
+:doc:`neb <neb>`, it is often advantageous to use a larger timestep for
+NEB than for normal dyanmics. Since the size of the timestep set by
+the :doc:`timestep <timestep>` command is used by TAD for performing
+dynamics, there is a *neb_step* keyword which can be used to set a
+larger timestep for each NEB calculation if desired.
+
+
+----------
+
+
+A key aspect of the TAD method is setting the stopping criterion
+appropriately. If this criterion is too conservative, then many
+events must be generated before one is finally executed. Conversely,
+if this criterion is too aggressive, high-entropy high-barrier events
+will be over-sampled, while low-entropy low-barrier events will be
+under-sampled. If the lowest pre-exponential factor is known fairly
+accurately, then it can be used to estimate *tmax*, and the value of
+*delta* can be set to the desired confidence level e.g. *delta* = 0.05
+corresponds to 95% confidence. However, for systems where the dynamics
+are not well characterized (the most common case), it will be
+necessary to experiment with the values of *delta* and *tmax* to get a
+good trade-off between accuracy and performance.
+
+A second key aspect is the choice of *t_hi*. A larger value greatly
+increases the rate at which new events are generated. However, too
+large a value introduces errors due to anharmonicity (not accounted
+for within hTST). Once again, for any given system, experimentation is
+necessary to determine the best value of *t_hi*.
+
+
+----------
+
+
+Five kinds of output can be generated during a TAD run: event
+statistics, NEB statistics, thermodynamic output by each replica, dump
+files, and restart files.
+
+Event statistics are printed to the screen and master log.lammps file
+each time an event is executed. The quantities are the timestep, CPU
+time, global event number *N*, local event number *M*, event status,
+energy barrier, time margin, *t_lo* and *delt_lo*. The timestep is
+the usual LAMMPS timestep, which corresponds to the high-temperature
+time at which the event was detected, in units of timestep. The CPU
+time is the total processor time since the start of the TAD run. The
+global event number *N* is a counter that increments with each
+executed event. The local event number *M* is a counter that resets to
+zero upon entering each new basin. The event status is *E* when an
+event is executed, and is *D* for an event that is detected, while
+*DF* is for a detected event that is also the earliest (first) event
+at the low temperature.
+
+The time margin is the ratio of the high temperature time in the
+current basin to the stopping time. This last number can be used to
+judge whether the stopping time is too short or too long (see above).
+
+*t_lo* is the low-temperature event time when the current basin was
+entered, in units of timestep. del*t_lo* is the time of each detected
+event, measured relative to *t_lo*. *delt_lo* is equal to the
+high-temperature time since entering the current basin, scaled by an
+exponential factor that depends on the hi/lo temperature ratio and the
+energy barrier for that event.
+
+On lines for executed events, with status *E*, the global event number
+is incremented by one,
+the local event number and time margin are reset to zero,
+while the global event number, energy barrier, and
+*delt_lo* match the last event with status *DF*
+in the immediately preceding block of detected events.
+The low-temperature event time *t_lo* is incremented by *delt_lo*.
+
+NEB statistics are written to the file specified by the *neb_log*
+keyword. If the keyword value is "none", then no NEB statistics are
+printed out. The statistics are written every *Nevery* timesteps. See
+the :doc:`neb <neb>` command for a full description of the NEB
+statistics. When invoked from TAD, NEB statistics are never printed to
+the screen.
+
+Because the NEB calculation must run on multiple partitions, LAMMPS
+produces additional screen and log files for each partition,
+e.g. log.lammps.0, log.lammps.1, etc. For the TAD command, these
+contain the thermodynamic output of each NEB replica. In addition, the
+log file for the first partition, log.lammps.0, will contain
+thermodynamic output from short runs and minimizations corresponding
+to the dynamics and quench operations, as well as a line for each new
+detected event, as described above.
+
+After the TAD command completes, timing statistics for the TAD run are
+printed in each replica's log file, giving a breakdown of how much CPU
+time was spent in each stage (NEB, dynamics, quenching, etc).
+
+Any :doc:`dump files <dump>` defined in the input script will be written
+to during a TAD run at timesteps when an event is executed. This
+means the the requested dump frequency in the :doc:`dump <dump>` command
+is ignored. There will be one dump file (per dump command) created
+for all partitions. The atom coordinates of the dump snapshot are
+those of the minimum energy configuration resulting from quenching
+following the executed event. The timesteps written into the dump
+files correspond to the timestep at which the event occurred and NOT
+the clock. A dump snapshot corresponding to the initial minimum state
+used for event detection is written to the dump file at the beginning
+of each TAD run.
+
+If the :doc:`restart <restart>` command is used, a single restart file
+for all the partitions is generated, which allows a TAD run to be
+continued by a new input script in the usual manner. The restart file
+is generated after an event is executed. The restart file contains a
+snapshot of the system in the new quenched state, including the event
+number and the low-temperature time. The restart frequency specified
+in the :doc:`restart <restart>` command is interpreted differently when
+performing a TAD run. It does not mean the timestep interval between
+restart files. Instead it means an event interval for executed
+events. Thus a frequency of 1 means write a restart file every time
+an event is executed. A frequency of 10 means write a restart file
+every 10th executed event. When an input script reads a restart file
+from a previous TAD run, the new script can be run on a different
+number of replicas or processors.
+
+Note that within a single state, the dynamics will typically
+temporarily continue beyond the event that is ultimately chosen, until
+the stopping criterionis satisfied. When the event is eventually
+executed, the timestep counter is reset to the value when the event
+was detected. Similarly, after each quench and NEB minimization, the
+timestep counter is reset to the value at the start of the
+minimization. This means that the timesteps listed in the replica log
+files do not always increase monotonically. However, the timestep
+values printed to the master log file, dump files, and restart files
+are always monotonically increasing.
+
+
+----------
+
+
+Restrictions
+""""""""""""
+
+
+This command can only be used if LAMMPS was built with the REPLICA
+package. See the :ref:`Making LAMMPS <start_3>` section
+for more info on packages.
+
+*N* setting must be integer multiple of *t_event*.
+
+Runs restarted from restart files written during a TAD run will only
+produce identical results if the user-specified integrator supports
+exact restarts. So :doc:`fix nvt <fix_nh>` will produce an exact
+restart, but :doc:`fix langevin <fix_langevin>` will not.
+
+This command cannot be used when any fixes are defined that keep track
+of elapsed time to perform time-dependent operations. Examples
+include the "ave" fixes such as :doc:`fix ave/spatial <fix_ave_spatial>`. Also :doc:`fix dt/reset <fix_dt_reset>` and :doc:`fix deposit <fix_deposit>`.
+* style = *delete* or *index* or *loop* or *world* or *universe* or
+ *uloop* or *string* or *format* or *getenv* or *file* or *atomfile* or *python* or *equal* or *atom*
+.. parsed-literal::
+
+ *delete* = no args
+ *index* args = one or more strings
+ *loop* args = N
+ N = integer size of loop, loop from 1 to N inclusive
+ *loop* args = N pad
+ N = integer size of loop, loop from 1 to N inclusive
+ pad = all values will be same length, e.g. 001, 002, ..., 100
+ *loop* args = N1 N2
+ N1,N2 = loop from N1 to N2 inclusive
+ *loop* args = N1 N2 pad
+ N1,N2 = loop from N1 to N2 inclusive
+ pad = all values will be same length, e.g. 050, 051, ..., 100
+ *world* args = one string for each partition of processors
+ *universe* args = one or more strings
+ *uloop* args = N
+ N = integer size of loop
+ *uloop* args = N pad
+ N = integer size of loop
+ pad = all values will be same length, e.g. 001, 002, ..., 100
+ *string* arg = one string
+ *format* args = vname fstr
+ vname = name of equal-style variable to evaluate
+ fstr = C-style format string
+ *getenv* arg = one string
+ *file* arg = filename
+ *atomfile* arg = filename
+ *python* arg = function
+ *equal* or *atom* args = one formula containing numbers, thermo keywords, math operations, group functions, atom values and vectors, compute/fix/variable references
+ * execute search (requires search index to be loaded)
+ */
+ query : function(query) {
+ var i;
+ var stopwords = ["a","and","are","as","at","be","but","by","for","if","in","into","is","it","near","no","not","of","on","or","such","that","the","their","then","there","these","they","this","to","was","will","with"];
+
+ // stem the searchterms and add them to the correct list
+ var stemmer = new Stemmer();
+ var searchterms = [];
+ var excluded = [];
+ var hlterms = [];
+ var tmp = query.split(/\s+/);
+ var objectterms = [];
+ for (i = 0; i < tmp.length; i++) {
+ if (tmp[i] !== "") {
+ objectterms.push(tmp[i].toLowerCase());
+ }
+
+ if ($u.indexOf(stopwords, tmp[i].toLowerCase()) != -1 || tmp[i].match(/^\d+$/) ||
+ tmp[i] === "") {
+ // skip this "word"
+ continue;
+ }
+ // stem the word
+ var word = stemmer.stemWord(tmp[i].toLowerCase());
+ var toAppend;
+ // select the correct list
+ if (word[0] == '-') {
+ toAppend = excluded;
+ word = word.substr(1);
+ }
+ else {
+ toAppend = searchterms;
+ hlterms.push(tmp[i].toLowerCase());
+ }
+ // only add if not already in the list
+ if (!$u.contains(toAppend, word))
+ toAppend.push(word);
+ }
+ var highlightstring = '?highlight=' + $.urlencode(hlterms.join(" "));
+
+ // console.debug('SEARCH: searching for:');
+ // console.info('required: ', searchterms);
+ // console.info('excluded: ', excluded);
+
+ // prepare search
+ var terms = this._index.terms;
+ var titleterms = this._index.titleterms;
+
+ // array of [filename, title, anchor, descr, score]
+ // search finished, update title and status message
+ else {
+ Search.stopPulse();
+ Search.title.text(_('Search Results'));
+ if (!resultCount)
+ Search.status.text(_('Your search did not match any documents. Please make sure that all words are spelled correctly and that you\'ve selected enough categories.'));
+ else
+ Search.status.text(_('Search finished, found %s page(s) matching the search query.').replace('%s', resultCount));
+c.source&&a.global==c.global&&a.multiline==c.multiline&&a.ignoreCase==c.ignoreCase}if(typeof a!="object"||typeof c!="object")return false;for(var f=d.length;f--;)if(d[f]==a)return true;d.push(a);var f=0,g=true;if(e=="[object Array]"){if(f=a.length,g=f==c.length)for(;f--;)if(!(g=f in a==f in c&&q(a[f],c[f],d)))break}else{if("constructor"in a!="constructor"in c||a.constructor!=c.constructor)return false;for(var h in a)if(b.has(a,h)&&(f++,!(g=b.has(c,h)&&q(a[h],c[h],d))))break;if(g){for(h in c)if(b.has(c,
+h)&&!f--)break;g=!f}}d.pop();return g}var r=this,G=r._,n={},k=Array.prototype,o=Object.prototype,i=k.slice,H=k.unshift,l=o.toString,I=o.hasOwnProperty,w=k.forEach,x=k.map,y=k.reduce,z=k.reduceRight,A=k.filter,B=k.every,C=k.some,p=k.indexOf,D=k.lastIndexOf,o=Array.isArray,J=Object.keys,s=Function.prototype.bind,b=function(a){return new m(a)};if(typeof exports!=="undefined"){if(typeof module!=="undefined"&&module.exports)exports=module.exports=b;exports._=b}else r._=b;b.VERSION="1.3.1";var j=b.each=
+b.forEach=function(a,c,d){if(a!=null)if(w&&a.forEach===w)a.forEach(c,d);else if(a.length===+a.length)for(var e=0,f=a.length;e<f;e++){if(e in a&&c.call(d,a[e],e,a)===n)break}else for(e in a)if(b.has(a,e)&&c.call(d,a[e],e,a)===n)break};b.map=b.collect=function(a,c,b){var e=[];if(a==null)return e;if(x&&a.map===x)return a.map(c,b);j(a,function(a,g,h){e[e.length]=c.call(b,a,g,h)});if(a.length===+a.length)e.length=a.length;return e};b.reduce=b.foldl=b.inject=function(a,c,d,e){var f=arguments.length>2;a==
+null&&(a=[]);if(y&&a.reduce===y)return e&&(c=b.bind(c,e)),f?a.reduce(c,d):a.reduce(c);j(a,function(a,b,i){f?d=c.call(e,d,a,b,i):(d=a,f=true)});if(!f)throw new TypeError("Reduce of empty array with no initial value");return d};b.reduceRight=b.foldr=function(a,c,d,e){var f=arguments.length>2;a==null&&(a=[]);if(z&&a.reduceRight===z)return e&&(c=b.bind(c,e)),f?a.reduceRight(c,d):a.reduceRight(c);var g=b.toArray(a).reverse();e&&!f&&(c=b.bind(c,e));return f?b.reduce(g,c,d,e):b.reduce(g,c)};b.find=b.detect=
+b.after=function(a,b){return a<=0?b():function(){if(--a<1)return b.apply(this,arguments)}};b.keys=J||function(a){if(a!==Object(a))throw new TypeError("Invalid object");var c=[],d;for(d in a)b.has(a,d)&&(c[c.length]=d);return c};b.values=function(a){return b.map(a,b.identity)};b.functions=b.methods=function(a){var c=[],d;for(d in a)b.isFunction(a[d])&&c.push(d);return c.sort()};b.extend=function(a){j(i.call(arguments,1),function(b){for(var d in b)a[d]=b[d]});return a};b.defaults=function(a){j(i.call(arguments,
+1),function(b){for(var d in b)a[d]==null&&(a[d]=b[d])});return a};b.clone=function(a){return!b.isObject(a)?a:b.isArray(a)?a.slice():b.extend({},a)};b.tap=function(a,b){b(a);return a};b.isEqual=function(a,b){return q(a,b,[])};b.isEmpty=function(a){if(b.isArray(a)||b.isString(a))return a.length===0;for(var c in a)if(b.has(a,c))return false;return true};b.isElement=function(a){return!!(a&&a.nodeType==1)};b.isArray=o||function(a){return l.call(a)=="[object Array]"};b.isObject=function(a){return a===Object(a)};