The following sections describe what commands can be used to perform certain kinds of LAMMPS simulations.
4.1 Restarting a simulationThe example input scripts included in the LAMMPS distribution and highlighted in this section also show how to setup and run various kinds of problems.
There are 3 ways to continue a long LAMMPS simulation. Multiple run commands can be used in the same input script. Each run will continue from where the previous run left off. Or binary restart files can be saved to disk using the restart command. At a later time, these binary files can be read via a read_restart command in a new script. Or they can be converted to text data files and read by a read_data command in a new script. This section discusses the restart2data tool that is used to perform the conversion.
Here we give examples of 2 scripts that read either a binary restart file or a converted data file and then issue a new run command to continue where the previous run left off. They illustrate what settings must be made in the new script. Details are discussed in the documentation for the read_restart and read_data commands.
Look at the in.chain input script provided in the bench directory of the LAMMPS distribution to see the original script that these 2 scripts are based on. If that script had the line
restart 50 tmp.restart
added to it, it would produce 2 binary restart files (tmp.restart.50 and tmp.restart.100) as it ran.
This script could be used to read the 1st restart file and re-run the last 50 timesteps:
read_restart tmp.restart.50
neighbor 0.4 bin neigh_modify every 1 delay 1
fix 1 all nve fix 2 all langevin 1.0 1.0 10.0 904297
timestep 0.012
run 50
Note that the following commands do not need to be repeated because their settings are included in the restart file: units, atom_style, special_bonds, pair_style, bond_style. However these commands do need to be used, since their settings are not in the restart file: neighbor, fix, timestep.
If you actually use this script to perform a restarted run, you will notice that the thermodynamic data match at step 50 (if you also put a "thermo 50" command in the original script), but do not match at step 100. This is because the fix langevin command uses random numbers in a way that does not allow for perfect restarts.
As an alternate approach, the restart file could be converted to a data file using this tool:
restart2data tmp.restart.50 tmp.restart.data
Then, this script could be used to re-run the last 50 steps:
units lj atom_style bond pair_style lj/cut 1.12 pair_modify shift yes bond_style fene special_bonds 0.0 1.0 1.0
read_data tmp.restart.data
neighbor 0.4 bin neigh_modify every 1 delay 1
fix 1 all nve fix 2 all langevin 1.0 1.0 10.0 904297
timestep 0.012
reset_timestep 50 run 50
Note that nearly all the settings specified in the original in.chain script must be repeated, except the pair_coeff and bond_coeff commands since the new data file lists the force field coefficients. Also, the reset_timestep command is used to tell LAMMPS the current timestep. This value is stored in restart files, but not in data files.
Use the dimension command to specify a 2d simulation.
Make the simulation box periodic in z via the boundary command. This is the default.
If using the create box command to define a simulation box, set the z dimensions narrow, but finite, so that the create_atoms command will tile the 3d simulation box with a single z plane of atoms - e.g.
create box 1 -10 10 -10 10 -0.25 0.25
If using the read data command to read in a file of atom coordinates, set the "zlo zhi" values to be finite but narrow, similar to the create_box command settings just described. For each atom in the file, assign a z coordinate so it falls inside the z-boundaries of the box - e.g. 0.0.
Use the fix enforce2d command as the last defined fix to insure that the z-components of velocities and forces are zeroed out every timestep. The reason to make it the last fix is so that any forces induced by other fixes will be zeroed out.
Many of the example input scripts included in the LAMMPS distribution are for 2d models.
IMPORTANT NOTE: Some models in LAMMPS treat particles as extended spheres, as opposed to point particles. In 2d, the particles will still be spheres, not disks, meaning their moment of inertia will be the same as in 3d.
There are many different ways to compute forces in the CHARMM and AMBER molecular dynamics codes, only some of which are available as options in LAMMPS. A force field has 2 parts: the formulas that define it and the coefficients used for a particular system. Here we only discuss formulas implemented in LAMMPS. Setting coefficients is done in the input data file via the read_data command or in the input script with commands like pair_coeff or bond_coeff. See this section for additional tools that can use CHARMM or AMBER to assign force field coefficients and convert their output into LAMMPS input.
See (MacKerell) for a description of the CHARMM force field. See (Cornell) for a description of the AMBER force field.
These style choices compute force field formulas that are consistent with common options in CHARMM or AMBER. See each command's documentation for the formula it computes.
This can be done in several ways. See the documentation for individual commands for more details on how these examples work.
If "multiple simulations" means continue a previous simulation for more timesteps, then you simply use the run command multiple times. For example, this script
units lj atom_style atomic read_data data.lj run 10000 run 10000 run 10000 run 10000 run 10000
would run 5 successive simulations of the same system for a total of 50,000 timesteps.
If you wish to run totally different simulations, one after the other, the clear command can be used in between them to re-initialize LAMMPS. For example, this script
units lj atom_style atomic read_data data.lj run 10000 clear units lj atom_style atomic read_data data.lj.new run 10000
would run 2 independent simulations, one after the other.
For large numbers of independent simulations, you can use variables and the next and jump commands to loop over the same input script multiple times with different settings. For example, this script, named in.polymer
variable d index run1 run2 run3 run4 run5 run6 run7 run8 shell cd $d read_data data.polymer run 10000 shell cd .. clear next d jump in.polymer
would run 8 simulations in different directories, using a data.polymer file in each directory. The same concept could be used to run the same system at 8 different temperatures, using a temperature variable and storing the output in different log and dump files, for example
variable a loop 8 variable t index 0.8 0.85 0.9 0.95 1.0 1.05 1.1 1.15 log log.$a read data.polymer velocity all create $t 352839 fix 1 all nvt $t $t 100.0 dump 1 all atom 1000 dump.$a run 100000 next t next a jump in.polymer
All of the above examples work whether you are running on 1 or multiple processors, but assumed you are running LAMMPS on a single partition of processors. LAMMPS can be run on multiple partitions via the "-partition" command-line switch as described in this section of the manual.
In the last 2 examples, if LAMMPS were run on 3 partitions, the same scripts could be used if the "index" and "loop" variables were replaced with universe-style variables, as described in the variable command. Also, the "next t" and "next a" commands would need to be replaced with a single "next a t" command. With these modifications, the 8 simulations of each script would run on the 3 partitions one after the other until all were finished. Initially, 3 simulations would be started simultaneously, one on each partition. When one finished, that partition would then start the 4th simulation, and so forth, until all 8 were completed.
The temper command can be used to perform a parallel tempering or replica-exchange simulation where multiple copies of a simulation are run at different temperatures on different sets of processors, and Monte Carlo temperature swaps are performed between pairs of copies.
Use the -procs and -in command-line switches to launch LAMMPS on multiple partitions.
In your input script, define a set of temperatures, one for each processor partition, using the variable command:
variable t world 300.0 310.0 320.0 330.0
Define a fix of style nvt or langevin to control the temperature of each simulation:
fix myfix all nvt $t $t 100.0
Use the temper command in place of a run command to perform a simulation where tempering exchanges will take place:
temper 100000 100 $t myfix 3847 58382
Granular system are composed of spherical particles with a diameter, as opposed to point particles. This means they have an angular velocity and torque can be imparted to them to cause them to rotate.
To run a simulation of a granular model, you will want to use the following commands:
This compute
calculates rotational kinetic energy which can be output with thermodynamic info.
Use one of these 3 pair potentials, which compute forces and torques between interacting pairs of particles:
These commands implement fix options specific to granular systems:
The fix style freeze zeroes both the force and torque of frozen atoms, and should be used for granular system instead of the fix style setforce.
For computational efficiency, you can eliminate needless pairwise computations between frozen atoms by using this command:
The TIP3P water model as implemented in CHARMM (MacKerell) specifies a 3-site rigid water molecule with charges and Lennard-Jones parameters assigned to each of the 3 atoms. In LAMMPS the fix shake command can be used to hold the two O-H bonds and the H-O-H angle rigid. A bond style of harmonic and an angle style of harmonic or charmm should also be used.
These are the additional parameters (in real units) to set for O and H atoms and the water molecule to run a rigid TIP3P-CHARMM model with a cutoff. The K values can be used if a flexible TIP3P model (without fix shake) is desired. If the LJ epsilon and sigma for HH and OH are set to 0.0, it corresponds to the original 1983 TIP3P model (Jorgensen).
O mass = 15.9994
H mass = 1.008
O charge = -0.834
H charge = 0.417
LJ epsilon of OO = 0.1521
LJ sigma of OO = 3.1507
LJ epsilon of HH = 0.0460
LJ sigma of HH = 0.4000
LJ epsilon of OH = 0.0836
LJ sigma of OH = 1.7753
K of OH bond = 450
r0 of OH bond = 0.9572
K of HOH angle = 55
theta of HOH angle = 104.52
These are the parameters to use for TIP3P with a long-range Coulombic solver (Ewald or PPPM in LAMMPS):
O mass = 15.9994
H mass = 1.008
O charge = -0.830
H charge = 0.415
LJ epsilon of OO = 0.102
LJ sigma of OO = 3.188
LJ epsilon, sigma of OH, HH = 0.0
K of OH bond = 450
r0 of OH bond = 0.9572
K of HOH angle = 55
theta of HOH angle = 104.52
The four-point TIP4P rigid water model extends the traditional three-point TIP3P model by adding an additional site, usually massless, where the charge associated with the oxygen atom is placed. This site M is located at a fixed distance away from the oxygen along the bisector of the HOH bond angle. A bond style of harmonic and an angle style of harmonic or charmm should also be used.
Currently, only a four-point model for long-range Coulombics is implemented via the LAMMPS pair style lj/cut/coul/long/tip4p. A cutoff version may be added the future. For both models, the bond lengths and bond angles should be held fixed using the fix shake command.
These are the additional parameters (in real units) to set for O and H atoms and the water molecule to run a rigid TIP4P model with a cutoff (Jorgensen). Note that the OM distance is specified in the pair_style command, not as part of the pair coefficients.
O mass = 15.9994
H mass = 1.008
O charge = -1.040
H charge = 0.520
r0 of OH bond = 0.9572
theta of HOH angle = 104.52
OM distance = 0.15
LJ epsilon of O-O = 0.1550
LJ sigma of O-O = 3.1536
LJ epsilon, sigma of OH, HH = 0.0
These are the parameters to use for TIP4P with a long-range Coulombic solver (Ewald or PPPM in LAMMPS):
O mass = 15.9994
H mass = 1.008
O charge = -1.0484
H charge = 0.5242
r0 of OH bond = 0.9572
theta of HOH angle = 104.52
OM distance = 0.1250
LJ epsilon of O-O = 0.16275
LJ sigma of O-O = 3.16435
LJ epsilon, sigma of OH, HH = 0.0
The SPC water model specifies a 3-site rigid water molecule with charges and Lennard-Jones parameters assigned to each of the 3 atoms. In LAMMPS the fix shake command can be used to hold the two O-H bonds and the H-O-H angle rigid. A bond style of harmonic and an angle style of harmonic or charmm should also be used.
These are the additional parameters (in real units) to set for O and H atoms and the water molecule to run a rigid SPC model with long-range Coulombics (Ewald or PPPM in LAMMPS).
O mass = 15.9994
H mass = 1.008
O charge = -0.820
H charge = 0.410
LJ epsilon of OO = 0.1553
LJ sigma of OO = 3.166
LJ epsilon, sigma of OH, HH = 0.0
r0 of OH bond = 1.0
theta of HOH angle = 109.47
To use SPC with a long-range Coulombic solver (Ewald or PPPM in LAMMPS), the only parameters that change are the partial charge assignments:
O charge = -0.8476
H charge = 0.4238
LAMMPS is designed to allow it to be coupled to other codes. For example, a quantum mechanics code might compute forces on a subset of atoms and pass those forces to LAMMPS. Or a continuum finite element (FE) simulation might use atom positions as boundary conditions on FE nodal points, compute a FE solution, and return interpolated forces on MD atoms.
LAMMPS can be coupled to other codes in at least 3 ways. Each has advantages and disadvantages, which you'll have to think about in the context of your application.
(1) Define a new fix command that calls the other code. In this scenario, LAMMPS is the driver code. During its timestepping, the fix is invoked, and can make library calls to the other code, which has been linked to LAMMPS as a library. This is the way the POEMS package that performs constrained rigid-body motion on groups of atoms is hooked to LAMMPS. See the fix_poems command for more details. See this section of the documentation for info on how to add a new fix to LAMMPS.
(2) Define a new LAMMPS command that calls the other code. This is conceptually similar to method (1), but in this case LAMMPS and the other code are on a more equal footing. Note that now the other code is not called during the timestepping of a LAMMPS run, but between runs. The LAMMPS input script can be used to alternate LAMMPS runs with calls to the other code, invoked via the new command. The run command facilitates this with its every option, which makes it easy to run a few steps, invoke the command, run a few steps, invoke the command, etc.
In this scenario, the other code can be called as a library, as in (1), or it could be a stand-alone code, invoked by a system() call made by the command (assuming your parallel machine allows one or more processors to start up another program). In the latter case the stand-alone code could communicate with LAMMPS thru files that the command writes and reads.
See this section of the documentation for how to add a new command to LAMMPS.
(3) Use LAMMPS as a library called by another code. In this case the other code is the driver and calls LAMMPS as needed. Or a wrapper code could link and call both LAMMPS and another code as libraries. Again, the run command has options that allow it to be invoked with minimal overhead (no setup or clean-up) if you wish to do multiple short runs, driven by another program.
This section of the documentation describes how to build LAMMPS as a library. Once this is done, you can interface with LAMMPS either via C++, C, or Fortran (or any other language that supports a vanilla C-like interface, e.g. a scripting language). For example, from C++ you could create one (or more) "instances" of LAMMPS, pass it an input script to process, or execute individual commands, all by invoking the correct class methods in LAMMPS. From C or Fortran you can make function calls to do the same things. Library.cpp and library.h contain such a C interface with the functions:
void lammps_open(int, char **, MPI_Comm, void **); void lammps_close(void *); void lammps_file(void *, char *); char *lammps_command(void *, char *);
The functions contain C++ code you could write in a C++ application that was invoking LAMMPS directly. Note that LAMMPS classes are defined within a LAMMPS namespace (LAMMPS_NS) if you use them from another C++ application.
Two of the routines in library.cpp are of particular note. The lammps_open() function initiates LAMMPS and takes an MPI communicator as an argument. It returns a pointer to a LAMMPS "object". As with C++, the lammps_open() function can be called multiple times, to create multiple instances of LAMMPS.
LAMMPS will run on the set of processors in the communicator. This means the calling code can run LAMMPS on all or a subset of processors. For example, a wrapper script might decide to alternate between LAMMPS and another code, allowing them both to run on all the processors. Or it might allocate half the processors to LAMMPS and half to the other code and run both codes simultaneously before syncing them up periodically.
Library.cpp contains a lammps_command() function to which the caller passes a single LAMMPS command (a string). Thus the calling code can read or generate a series of LAMMPS commands (e.g. an input script) one line at a time and pass it thru the library interface to setup a problem and then run it.
A few other sample functions are included in library.cpp, but the key idea is that you can write any functions you wish to define an interface for how your code talks to LAMMPS and add them to library.cpp and library.h. The routines you add can access any LAMMPS data. The examples/couple directory has example C++ and C codes which show how a stand-alone code can link LAMMPS as a library, run LAMMPS on a subset of processors, grab data from LAMMPS, change it, and put it back into LAMMPS.
LAMMPS itself does not do visualization, but snapshots from LAMMPS simulations can be visualized (and analyzed) in a variety of ways.
LAMMPS snapshots are created by the dump command which can create files in several formats. The native LAMMPS dump format is a text file (see "dump atom" or "dump custom") which can be visualized by the xmovie program, included with the LAMMPS package. This produces simple, fast 2d projections of 3d systems, and can be useful for rapid debugging of simulation geometry and atom trajectories.
Several programs included with LAMMPS as auxiliary tools can convert native LAMMPS dump files to other formats. See the Section_tools doc page for details. The first is the ch2lmp tool, which contains a lammps2pdb Perl script which converts LAMMPS dump files into PDB files. The second is the lmp2arc tool which converts LAMMPS dump files into Accelrys' Insight MD program files. The third is the lmp2cfg tool which converts LAMMPS dump files into CFG files which can be read into the AtomEye visualizer.
A Python-based toolkit distributed by our group can read native LAMMPS dump files, including custom dump files with additional columns of user-specified atom information, and convert them to various formats or pipe them into visualization software directly. See the Pizza.py WWW site for details. Specifically, Pizza.py can convert LAMMPS dump files into PDB, XYZ, Ensight, and VTK formats. Pizza.py can pipe LAMMPS dump files directly into the Raster3d and RasMol visualization programs. Pizza.py has tools that do interactive 3d OpenGL visualization and one that creates SVG images of dump file snapshots.
LAMMPS can create XYZ files directly (via "dump xyz") which is a simple text-based file format used by many visualization programs including VMD.
LAMMPS can create DCD files directly (via "dump dcd") which can be read by VMD in conjunction with a CHARMM PSF file. Using this form of output avoids the need to convert LAMMPS snapshots to PDB files. See the dump command for more information on DCD files.
LAMMPS can create XTC files directly (via "dump xtc") which is GROMACS file format which can also be read by VMD for visualization. See the dump command for more information on XTC files.
By default, LAMMPS uses an orthogonal simulation box to encompass the particles. The boundary command sets the boundary conditions of the box (periodic, non-periodic, etc). If the box size is xprd by yprd by zprd then the 3 mutually orthogonal edge vectors of an orthogonal simulation box are a = (xprd,0,0), b = (0,yprd,0), and c = (0,0,zprd).
LAMMPS also allows non-orthogonal simulation boxes (triclinic symmetry) to be defined with 3 additional "tilt" parameters which change the edge vectors of the simulation box to be a = (xprd,0,0), b = (xy,yprd,0), and c = (xz,yz,zprd). The xy, xz, and yz parameters can be positive or negative. The simulation box must be periodic in both dimensions associated with a tilt factor. For example, if xz != 0.0, then the x and z dimensions must be periodic.
To avoid extremely tilted boxes (which would be computationally inefficient), no tilt factor can skew the box more than half the distance of the parallel box length, which is the 1st dimension in the tilt factor (x for xz). 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.
You tell LAMMPS to use a non-orthogonal box when the simulation box is defined. This happens in one of 3 ways. If the create_box command is used with a region of style prism, then a non-orthogonal domain is setup. See the region command for details. If the read_data command is used to define the simulation box, and the header of the data file contains a line with the "xy xz yz" keyword, then a non-orthogonal domain is setup. See the read_data command for details. Finally, if the read_restart command reads a restart file which was written from a simulation using a triclinic box, then a non-orthogonal box will be enabled for the restarted simulation.
Note that you can define a non-orthogonal box with all 3 tilt factors = 0.0, so that it is initially orthogonal. This is necessary if the box will become non-orthogonal. Alternatively, you can use the change_box command to convert a simulation box from orthogonal to non-orthogonal and vice versa.
One use of non-orthogonal boxes is to model solid-state crystals with triclinic symmetry. The lattice command can be used with non-orthogonal basis vectors to define a lattice that will tile a non-orthogonal simulation box via the create_atoms command. Note that while the box edge vectors a,b,c cannot be arbitrary vectors (e.g. a must be aligned with the x axis), it is possible to rotate any crystal's basis vectors so that they meet these restrictions.
A second use of non-orthogonal boxes is to shear a bulk solid to study the response of the material. The fix deform command can be used for this purpose. It allows dynamic control of the xy, xz, and yz tilt factors as a simulation runs.
Another use of non-orthogonal boxes is to perform non-equilibrium MD (NEMD) simulations, as discussed in the next section.
Non-equilibrium molecular dynamics or NEMD simulations are typically used to measure a fluid's rheological properties such as viscosity. In LAMMPS, such simulations can be performed by first setting up a non-orthogonal simulation box (see the preceding Howto section).
A shear strain can be applied to the simulation box at a desired strain rate by using the fix deform command. The fix nvt/sllod command can be used to thermostat the sheared fluid and integrate the SLLOD equations of motion for the system. Fix nvt/sllod uses compute temp/deform to compute a thermal temperature by subtracting out the streaming velocity of the shearing atoms. The velocity profile or other properties of the fluid can be monitored via the fix ave/spatial command.
As discussed in the previous section on non-orthogonal simulation boxes, the amount of tilt or skew that can be applied is limited by LAMMPS for computational efficiency to be 1/2 of the parallel box length. However, fix deform can continuously strain a box by an arbitrary amount. As discussed in the fix deform command, when the tilt value reaches a limit, the box is re-shaped to the opposite limit which is an equivalent tiling of periodic space. The strain rate can then continue to change as before. In a long NEMD simulation these box re-shaping events may occur many times.
In a NEMD simulation, the "remap" option of fix deform should be set to "remap v", since that is what fix nvt/sllod assumes to generate a velocity profile consistent with the applied shear strain rate.
An alternative method for calculating viscosities is provided via the fix viscosity command.
Typical MD models treat atoms or particles as point masses. Sometimes, however, it is desirable to have a model where the particles are extended spherioids or extended aspherical paticles such as an ellipsoid. The difference is that such particles have a moment of inertia, rotational energy, and angular momentum. Rotation is induced by torque from interactions with other particles.
LAMMPS has several options for running simulations with these kinds of particles. The following aspects are discussed in turn:
There are 3 atom styles that define extended particles: granular, dipole, ellipsoid.
Granular particles are extended spheriods and each particle can have a unique diameter and mass (or density). These particles store an angular velocity (omega) and can be acted upon by torque.
Dipole particles are extended spheriods with a point dipole and each particle type has a diamater and mass, set by the shape and mass commands. These particles store an angular velocity (omega) and can be acted upon by torque. They also store an orientation for the point dipole (mu) which has a length set by the dipole command. The set command can be used to initialize the orientation of dipole moments.
Ellipsoid particles are aspherical. Each particle type has an ellipsoidal shape and mass, defined by the shape and mass commands. These particles store an angular momentum and their orientation (quaternion), and can be acted upon by torque. They do not store an angular velocity (omega) which can be in a different direction than angular momentum. The set command can be used to initialize the orientation of ellipsoidal particles and has a brief explanation of quaternions.
Note that if one of these atom styles is used (or multiple styles via the atom_style hybrid command), not all particles in the system are required to be extended or aspherical. For example, if the 3 shape parameters are set to the same value, the particle will be a spheroid rather than an ellipsoid. If the dipole moment is set to zero, the particle will not have a point dipole associated with it. The pair styles used to compute pairwise interactions will typically compute the correct interaction in these simplified (cheaper) cases. Pair_style hybrid can be used to insure the correct interactions are computed for the appropriate style of interactions. Likewise, using groups to partition particles (ellipsoid versus spheroid versus point particles) will allow you to use the appropriate time integrators and temperature computations for each class of particles. See the doc pages for various commands for details.
Also note that for 2d simulations, extended spheroids and ellipsoids are still treated as 3d particles, rather than as disks or ellipses. This means they still have a moment of inertia for a 3d extended object. When their temperature is coomputed, the correct degrees of freedom are used for rotation in a 2d versus 3d system.
When a system with extended particles is defined, the particles will only rotate and experience torque if the force field computes such interactions. These are the various pair styles that generate torque:
The granular pair styles are used with atom_style granular. The dipole pair style is used with atom_style dipole. The GayBerne and REsquared potentials require particles have a shape and are designed for ellipsoidal particles. The lubrication potential requires that particles have a shape. It can currently only be used with extended spherical particles.
There are 3 fixes that perform time integration on extended spherical particles, meaning the integrators update the rotational orientation and angular velocity or angular momentum of the particles:
Likewise, there are 3 fixes that perform time integration on extended aspherical particles:
The advantage of these fixes is that those which thermostat the particles include the rotational degrees of freedom in the temperature calculation and thermostatting. Other thermostats can be used with fix nve/sphere or fix nve/asphere, such as fix langevin or fix temp/berendsen, but those thermostats only operate on the translational kinetic energy of the extended particles.
Note that for mixtures of point and extended particles, you should only use these integration fixes on groups which contain extended particles.
There are 4 computes that calculate the temperature or rotational energy of extended spherical or aspherical particles:
These include rotational degrees of freedom in their computation. If you wish the thermodynamic output of temperature or pressure to use one of these computes (e.g. for a system entirely composed of extended particles), then the compute can be defined and the thermo_modify command used. Note that by default thermodynamic quantities will be calculated with a temperature that only includes translational degrees of freedom. See the thermo_style command for details.
The dump custom command can output various attributes of extended particles, including the dipole moment (mu), the angular velocity (omega), the angular momentum (angmom), the quaternion (quat), and the torque (tq) on the particle.
The fix rigid command treats a collection of particles as a rigid body, computes its inertia tensor, sums the total force and torque on the rigid body each timestep due to forces on its constituent particles, and integrates the motion of the rigid body.
(NOTE: 6/08 the feature described in the following paragraph has not yet been released. It will be soon.)
If any of the constituent particles of a rigid body are extended particles (spheroids or ellipsoids), then their contribution to the inertia tensor of the body is different than if they were point particles. This means the rotational dynamics of the rigid body will be different. Thus a model of a dimer is different if the dimer consists of two point masses versus two extended sphereoids, even if the two particles have the same mass. Extended particles that experience torque due to their interaction with other particles will also impart that torque to a rigid body they are part of.
See the "fix rigid" command for example of complex rigid-body models it is possible to define in LAMMPS.
Note that the fix shake command can also be used to treat 2, 3, or 4 particles as a rigid body, but it always assumes the particles are point masses.
Aside from restart files, there are two basic kinds of LAMMPS output. The first is thermodynamic output, which is a list of quantities printed every few timesteps to the screen and logfile. The second is dump files, which contain snapshots of atoms and various per-atom values and are written at a specified frequency. A simulation prints one set of thermodynamic output; it may generate any number of dump files. As discussed below, LAMMPS gives you a variety of ways to determine what quantities are computed and printed when thermodynamic info or dump files are output. There are also three fixes which can do their own output of user-chosen quantities: fix ave/time for time averaging, fix ave/spatial for spatial averaging, and fix print. These are also described below. Throughout this discussion, note that users can add their own computes and fixes to LAMMPS which can then generate values that can be output with these commands.
The frequency and format of thermodynamic output is set by the thermo, thermo_style, and thermo_modify commands. The thermo_style command also specifies what values are calculated and written out. Pre-defined keywords can be specified (e.g. press, etotal, etc). Three additional kinds of keywords can also be specified (c_ID, f_ID, v_name), where a compute or fix or variable provides the value to be output. Each of these are described in turn.
In LAMMPS, a compute comes in two flavors: ones that compute global values (e.g. temperature, pressure tensor) and ones that compute per-atom values. Only global quantities from a compute can be used for thermodynamic output. The user-defined ID of the compute is used along with an optional subscript as part of the thermo_style command. E.g. c_myTemp outputs the single scalar value generated by the compute; c_myTemp[2] outputs the 2nd vector value. Note that there is a compute reduce command which can sum per-atom quantities into a global scalar or vector.
Fixes can generate global scalar or vector values which can be output with thermodynamic output, e.g. the energy of an indenter's interaction with the simulation atoms. These values are accessed via the same format as a compute's values, as f_ID or f_ID[N]. See the doc pages for individual fix commands to see which ones generate global values that can be output with thermodynamic info. The fix ave/time command generates time-averaged global quantities which can be accessed for thermodynamic output, e.g. a time-averaged pressure.
Variables can be defined in the input script. All styles except the atom-style variable can be used for thermodynamic output, since it generates per-atom values. A variable with the name "abc" is referenced in a thermo_style command as v_abc.
The formula associated with equal-style variables can contain math operations and functions (x+y,x*y,(),sqrt,exp,etc), atom values (x[N],fx[N],etc), group functions (mass(),vcm(),etc), references to thermodynamic quantities (temp,press,vol,etc), references to computes that generate global values, references to fixes that generate global values, or references to other variables. Thus an equal-style variable is the most general way to define some quantity to calculate and include with thermodynamic output.
Dump file output is specified by the dump and dump_modify commands. There are several pre-defined formats (dump atom, dump xtc, etc). There is also a dump custom format where the user specifies what values are output with each atom. Pre-defined keywords can be specified (tag, x, fx, etc). Three additional kinds of keywords can also be specified (c_ID, f_ID, v_name), where a compute or fix or variable provides the value to be output. Each of these are described in turn.
Computes that generate one or more per-atom values can be accessed by the dump custom command. These are computes that have the word "atom" in their style name, e.g. ke/atom, stress/atom, etc. The values are accessed as c_myKE for a scalar per-atom quantity or as c_myStress[2] for a component of a vector per-atom quantity.
Fixes can generate per-atom values to output to dump files. For example, the fix ave/atom command calculates time-averages of per-atom quantities, such as per-atom computes and atom-style variables. These per-atom fix values are accessed by the dump custom command via the same format as a compute's values, as f_myKE or f_myStress[2].
Variables can be defined in the input script. Only atom-style variables can be used for dump custom output, since only they produce per-atom values. A variable with the name "abc" is referenced in a dump custom command as v_abc.
Just like equal-style variables, the formula associated with atom-style variables can contain math operations and functions (x+y,x*y,(),sqrt,exp,etc), atom values (x[N],fx[N],etc), group functions (mass(),vcm(),etc), references to thermodynamic quantities (temp,press,vol,etc), references to computes that generate global values, references to fixes that generate global values, or references to non atom-style variables that generate global values. In addition, an atom-style variable can reference vectors of atom values (x[],fx[],etc), computes that generate per-atom values, fixes that generate per-atom values, or other atom-style variables. Thus an atom-style variable is the most general way to define some quantity to calculate and output to a dump file.
Three other fixes are of particular note for output: fix ave/time, fix ave/spatial, and fix print.
The fix ave/time command enables time-averaging of any global quantity, like those output with thermodynamic info. The user specifies one or more quantities to time average. These can be global compute values, global fix values, or variables of any style except the atom style which produces per-atom values. Since a variable can refer to keywords used by the thermo_style custom command (like temp or press), any thermodynamic quantity can be time averaged in this way.
The fix ave/time command offers several options for how it performs time averaging. The results it produces can be used in two ways. First, they can be written directly to a file, one line per timestamp. Note that the averaging parameters can be specified in such a way that averaging is not done at all, in which case this is simply a convenient means of outputting desired quantities directly to a separate file. Like other fixes that produce global quantities, the results of this fix can also be used as input to any command that accesses global quantities, e.g. by the thermo_style custom command, by a variable, etc.
The fix ave/spatial command enables spatial-averaging of per-atom quantities like those output in dump files, within 1d layers of the simulation box. The per-atom quantities can be atom density (mass or number) or atom attributes such as position, velocity, force. They can also be per-atom quantities calculated by a compute, by a fix, or by an atom-style variable.
The fix ave/spatial command offers several options for how it performs time averaging. The per-layer values it produces can be used in two ways. First, they can be written directly to a file. Note that the averaging parameters can be specified in such a way that time averaging is not done, in which case this is a convenient means of simply outputting desired quantities (summed over atoms within a 1d layer) directly to a separate file. Like other fixes that produce global quantities, the results of this fix can also be used as input by any command that accesses global quantities, e.g. by the thermo_style custom command, by a variable, etc. See the doc page for fix ave/spatial for a description of how these values are indexed.
The fix print command can generate a line of output written to the screen and log file or to a separate file, periodically during a running simulation. The line can contain one or more variable values (for any style variable except the atom style), and as explained above, variables themselves can contain references to global values generated by thermodynamic keywords, computes, fixes, or other variables. Thus the fix print command is a means to output any desired calculated quantity separate from normal thermodynamic or dump file output.
This table summarizes the various output options, specifying what their inputs and outputs are. The frequency with which they are invoked and produce output is also listed. Basically, any two commands can be hooked together so long as one produces output that matches the input needs of the other. A "match" means that the frequencies and global vs per-atom attributes are the same.
Command | Input | Input Freq | Output | Output Freq |
thermo_style custom | thermo keyword, global scalar/vector compute, global scalar/vector fix, equal variable | nthermo | screen, log | nthermo |
dump custom | keyword, peratom scalar/vector compute, peratom scalar/vector fix, atom variable | dump freq | file | dump freq |
global fixes | N/A | N/A | global scalar/vector | 1 or nevery |
peratom fixes | N/A | N/A | peratom scalar/vector | 1 or nevery |
fix ave/time | global scalar/vector fix, global scalar/vector compute, equal variable | nevery | global scalar/vector, file | nfreq |
fix ave/spatial | peratom scalar/vector fix, peratom scalar/vector compute, atom vector, atom variable, density mass/number | nevery | global vector | nfreq, file |
fix ave/atom | peratom scalar/vector compute, peratom scalar/vector fix, atom variable, atom vector | nevery | peratom scalar/vector | nfreq |
fix print | any variable | nevery | screen, file | nevery |
global computes | N/A | N/A | global scalar/vector | N/A |
peratom computes | N/A | N/A | peratom scalar/vector | N/A |
compute sum | peratom scalar/vector compute, peratom scalar/vector fix, atom variable | N/A | global scalar/vector | N/A |
variable equal | thermo keywords, atom value vx[123], global scalar/vector compute, global scalar/vector fix, non-atom variable | N/A | global scalar | N/A |
variable atom | thermo keywords, atom value vx[123], atom vector vx[], global scalar/vector compute, peratom scalar/vector compute, global scalar/vector fix, peratom scalar/vector fix, any variable | N/A | peratom scalar | N/A |
any variable | N/A | screen, log | between runs | |
run every | any variable | nevery | screen, log | nevery |
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 compute commands calculate temperature, and the compute pressure command calculates pressure.
All but the first 3 calculate velocity biases (i.e. advection velocities) that are removed when computing the thermal temperature. Fix temp/sphere and fix temp/asphere compute kinetic energy for extended particles that includes rotational degrees of freedom. They both allow, as an extra argument, another temperature compute that subtracts a velocity bias, so the translational velocity of extended spherical or aspherical particles can be adjusted in prescribed ways.
Thermostatting in LAMMPS is performed by fixes. Four thermostatting fixes are currently available: Nose-Hoover (nvt), Berendsen, Langevin, and direct rescaling (temp/rescale):
Fix nvt only thermostats the translational velocity of particles. Fix nvt/sllod does as well, except that it subtracts out a velocity bias due to a deforming box and integrates the SLLOD equations of motion. See the NEMD simulations section of this page for further details. Fix nvt/sphere and fix nvt/asphere thermostat not only translation velocities but also rotational velocities for spherical and aspherical particles.
Any of these fixes can use temperature computes that remove bias for two purposes: (a) computing the current temperature to compare to the requested target temperature, and (b) adjusting only the thermal temperature component of the particle's velocities. See the doc pages for the individual fixes and for the 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 compute temp/partial.
IMPORTANT NOTE: 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. Thus they should be used in conjunction with a constant NVE integration fix such as these:
Barostatting in LAMMPS is also performed by fixes. Two barosttating methods are currently available: Nose-Hoover (npt and nph) and Berendsen:
The fix npt commands include a Nose-Hoover thermostat and barostat. Fix nph is just a Nose/Hoover barostat; it does no thermostatting. Both fix nph and fix press/bernendsen can be used in conjunction with any of the thermostatting fixes.
As with the thermostats, fix npt and fix nph only use translational motion of the particles in computing T and P and performing thermo/barostatting. Fix npt/sphere and 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 compute pressure compute to calculate a current pressure. The barostatting fixes can also use temperature computes that remove bias for the purpose of computing the current temperature which contributes to the current pressure. See the doc pages for the individual fixes and for the fix_modify command for instructions on how to assign a temperature or pressure compute to a barostatting fix.
IMPORTANT NOTE: As with the thermostats, the Nose/Hoover methods (fix npt and fix nph) perform time integration. 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 thermo_style command, often includes temperature and pressure values. As explained on the doc page for the 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 thermo_style custom command. Or you can use the thermo_modify command to re-define what temperature or pressure compute is used for default thermodynamic output.
(Cornell) Cornell, Cieplak, Bayly, Gould, Merz, Ferguson, Spellmeyer, Fox, Caldwell, Kollman, JACS 117, 5179-5197 (1995).
(Horn) Horn, Swope, Pitera, Madura, Dick, Hura, and Head-Gordon, J Chem Phys, 120, 9665 (2004).
(MacKerell) MacKerell, Bashford, Bellott, Dunbrack, Evanseck, Field, Fischer, Gao, Guo, Ha, et al, J Phys Chem, 102, 3586 (1998).
(Jorgensen) Jorgensen, Chandrasekhar, Madura, Impey, Klein, J Chem Phys, 79, 926 (1983).