Alejandro Bernardin, Haochuan Chen, Jeffrey R. Comer, Giacomo Fiorin, Haohao Fu, Jérôme Hénin, Axel Kohlmeyer, Fabrizio Marinelli, Hubert Santuz, Joshua V. Vermaas, Andrew D. White, Wei Zhang

(PDF version)

Contents

In molecular dynamics simulations, it is often useful to reduce the large number of degrees of freedom of a physical system into few parameters whose statistical distributions can be analyzed individually, or used to define biasing potentials to alter the dynamics of the system in a controlled manner. These have been called ‘order parameters', ‘collective variables', ‘(surrogate) reaction coordinates', and many other terms.

Here we use primarily the term ‘collective variable', often shortened to colvar, to indicate any differentiable function of atomic Cartesian coordinates, $x_i$, with $i$ between $1$ and $N$, the total number of atoms:

This manual documents the collective variables module (Colvars), a software that provides an implementation for the functions $\xi \left(X\right)$ with a focus on flexibility, robustness and high performance. The module is designed to perform multiple tasks concurrently during or after a simulation, the most common of which are:

• apply restraints or biasing potentials to multiple variables, tailored on the system by choosing from a wide set of basis functions, without limitations on their number or on the number of atoms involved;
• calculate potentials of mean force (PMFs) along any set of variables, using different enhanced sampling methods, such as Adaptive Biasing Force (ABF), metadynamics, steered MD and umbrella sampling; variants of these methods that make use of an ensemble of replicas are supported as well;
• calculate statistical properties of the variables, such as running averages and standard deviations, correlation functions of pairs of variables, and multidimensional histograms: this can be done either at run-time without the need to save very large trajectory files, or after a simulation has been completed (post-processing).

Detailed explanations of the design of the Colvars module are provided in reference [1]. Please cite this reference whenever publishing work that makes use of this module, alongside any other publications for specific features being, according to the usage summary printed when running a Colvars-enabled MD simulation or analysis.

The Colvars configuration is a plain text file or string that defines collective variables, biases, and general parameters of the Colvars module. It is passed to the module using back-end-specific commands documented in section 3.

Example: steering two groups of atoms away from each other. Now let us look at a complete, non-trivial configuration. Suppose that we want to run a steered MD experiment where a small molecule is pulled away from a protein binding site. In Colvars terms, this is done by applying a moving restraint to the distance between the two objects. The configuration will contain two blocks, one defining the distance variable (see section 4 and 4.3.1), and the other the moving harmonic restraint (6.8).

indexFile index.ndx
colvar {
  name dist
  distance {
    group1 { atomNumbersRange 42-55 }
    group2 { indexGroup C-alpha_15-30 }
  }
}

harmonic {
  colvars dist
  forceConstant 20.0
  centers 4.0         # initial distance
  targetCenters 15.0  # final distance
  targetNumSteps 500000
} 

Reading this input in plain English: the variable here named dist consists in a distance function between the centers of two groups: the ligand (atoms 42 to 55) and the $\alpha$-carbon atoms of residues 15 to 30 in the protein (selected from the index group “C-alpha_15-30"). To the “dist" variable, we apply a harmonic potential of force constant 20 energy unit/length unit${}^2$, initially centered around a value of 4 length unit, which will increase to 15 length unit over 500,000 simulation steps.

The atom selection keywords are detailed in section 5. If the selection is too complex to implement only via internal keywords, an external index file may be created following the NDX format used in GROMACS (see 3.8.2) or by using the group2ndx LAMMPS command.

Example: using multiple variables and multiple biasing/analysis methods together. A more complex example configuration is included below, showing how a variable may be constructed by combining multiple existing functions, and how multiple variables or multiple biases may be used concurrently. The colvar indicated below as “$d$" is defined as the difference between two distances (see 4.3): the first distance ($d_1$) is taken between the center of mass of atoms 1 and 2 and that of atoms 3 to 5, the second ($d_2$) between atom 7 and the center of mass of atoms 8 to 10 (see 5). The difference $d=d_1-d_2$ is obtained by multiplying the two by a coefficient $C=+1$ or $C=-1$, respectively (see 4.17). The colvar called “$c$" is the coordination number calculated between atoms 1 to 10 and atoms 11 to 20. A harmonic restraint (see 6.8) is applied to both $d$ and $c$: to allow using the same force constant $K$, both $d$ and $c$ are scaled by their respective fluctuation widths $w_d$ and $w_c$. The values of “$c$" are also recorded throughout the simulation as a joint 2-dimensional histogram (see 6.13).

colvar {
  # difference of two distances
  name d 
  width 0.2  # estimated fluctuation width 
  distance {
    componentCoeff  1.0
    group1 { atomNumbers 1 2 }
    group2 { atomNumbers 3 4 5 }
  }
  distance {
    componentCoeff -1.0
    group1 { atomNumbers 7 }
    group2 { atomNumbers 8 9 10 }
  }
}

colvar {
  name c
  coordNum {
    cutoff 6.0
    group1 { atomNumbersRange  1-10 }
    group2 { atomNumbersRange 11-20 }
    tolerance 1.0e-6
    pairListFrequency 1000
  }
}

harmonic {
  colvars d c
  centers 3.0 4.0
  forceConstant 5.0
}

histogram {
  colvars c
} 

Here, we document the syntax of the commands and parameters used to set up and use the Colvars module in LAMMPS [2]. One of these parameters is the configuration file or the configuration text for the module itself, whose syntax is described in 3.4 and in the following sections.

The “internal units" of the Colvars module are the units in which values are expressed in the configuration file, and in which collective variable values, energies, etc. are expressed in the output and colvars trajectory files. Generally the Colvars module uses internally the same units as its back-end MD engine, with the exception of VMD, where different unit sets are supported to allow for easy setup, visualization and analysis of Colvars simulations performed with any simulation engine.

Note that angles are expressed in degrees, and derived quantities such as force constants are based on degrees as well. Some colvar components have default values, expressed in Ångström (Å) in this documentation. They are converted to the current length unit, if different from Å. Atomic coordinates read from XYZ files (and PDB files where applicable) are expected to be expressed in Ångström, no matter what unit system is in use by the back-end (LAMMPS) or the Colvars Module. They are converted internally to the current length unit as needed. Note that force constants in harmonic and harmonicWalls biases (6.8) are rescaled according to the width parameter of colvars, so that they are formally in energy units, although if width is given its default value of 1.0, force constants are effectively expressed in energy unit/(colvar unit)${}^2$.

To avoid errors due to reading configuration files written in a different unit system, it can be specified within the input:

• units — Unit system to be used
  $[$ string, context: global $]$
  A string defining the units to be used internally by Colvars. Supported values are the following LAMMPS unit styles: real (Å, kcal/mol), metal (Å, eV), and electron (Bohr, Hartree). However only the unit system currently in use by LAMMPS is accepted: other values will trigger an error.

To enable a Colvars-based calculation, the following line must be added to the LAMMPS configuration file:

fix Colvars all colvars configfile [keyword value pairs ...] 

where the fix ID is here set to the string “Colvars", because there can only be one instance of fix colvars in a LAMMPS run.

The value of the configfile keyword is the name of the configuration file for the Colvars module. You may also provide the lowercase string “none" to create an empty module, and define the configuration via fix_modify (see 3.3).

Other optional keywords for fix colvars are:

• output — Prefix of the output state file
  Default: “out" $[$ string, context: Keyword of the fix colvars command $]$
  If a value is provided, it is interpreted as the prefix to all output files that will be written by the Colvars module (see 3.7). This includes output state files for checkpointing, as well as accumulated information such as PMFs or histograms and trajectories of the collective variables. Because this information is often useful, a default value is set for this keyword when not provided. However, supplying an empty string suppresses any file output from Colvars to file, except for data saved into the LAMMPS binary restart file.
• input — Name or prefix of the input state file (optional)
  $[$ string, context: Keyword of the fix colvars command $]$
  If a value is provided, it is interpreted as either the name of the input state file, or as the prefix of the file named input.colvars.state. This file contains information needed to continue a previous collective variables-based calculation, including the number of the last computed step (useful for time-dependent biases). The same information is also stored in the binary restart files written by LAMMPS, so this option is generally not needed when the read_restart LAMMPS command is used.
• unwrap — Whether to unwrap coordinates passed to the Colvars module (optional)
  Default: “yes" $[$ “yes" or “no", context: keyword of the fix colvars command $]$
  This keyword controls whether wrapped or unwrapped coordinates are passed to the Colvars module for calculation of the collective variables and of the resulting forces. The default is to use the image flags to reconstruct the absolute atom positions: under this convention, centers of mass and centers of geometry are calculated as a weighted vector sum (see 5.3). Setting this to no will use the current local coordinates that are wrapped back into the simulation cell at each re-neighboring instead.
• seed — Seed for the random number generator (optional)
  Default: 1966 $[$ positive integer, context: Keyword of the fix colvars command $]$
  If defined, the value of this keyword is provided as seed to the random number generator. This is only meaningful when the extendedLangevinDamping keyword is used (see 4.21).
• tstat — Thermostating fix (optional)
  Default: NULL $[$ string, context: Keyword of the fix colvars command $]$
  This keyword provides the ID of an applicable thermostatting fix command. This will be used to provide the Colvars module with the current thermostat target temperature when using a method that needs this information.

All of the above keywords except for the name of the configuration file may also be given (or overridden) using fix_modify, as well as new Colvars configuration files (see 3.3 for more details).

After the first initialization of the Colvars module, the internal state of Colvars objects may be queried or modified in a LAMMPS script (here, “Colvars" is the ID of the fix colvars instance):

fix_modify Colvars $<$method$>$ arg1 arg2 ...

where $<$method$>$ is the name of a specific procedure and arg1, arg2, …are its required and/or optional arguments.

Each fix_modify command may be used in either one of two ways:

1. Provide an updated value for the parameters of the fix listed in 3.2: this behavior is similar to that of several other LAMMPS fix styles, and follows the same argument parsing rules. For example, multiple keywords can be provided together:

   fix_modify Colvars seed 111111 tstat NPT 

2. Use one of the scripting functions described in this section; the arguments provided as strings are passed to Colvars. LAMMPS variables referenced by their string representation, “${variable}", will be expanded immediately. Additionally, variable expansion will also happen within quotes, similar to what the mdi command provides in a LAMMPS script: this feature makes it possible to use the values of certain LAMMPS variables in Colvars configuration strings (see 3.3.1).

   variable freq index 10000
   dump myDump all atom/zstd ${freq} dump.atom.zstd
   fix_modify Colvars config "colvarsTrajFrequency ${freq}" 

fix_modify can be run on a previously created instance of fix colvars at any time. However, because the fix is not fully initialized until the beginning of the next simulation step, only the variables and biases that were created prior to the most recent run or minimize command will be accessible. This fact is true even if a Colvars configuration file that defines those variables and biases was already given in the LAMMPS script. Should you want to trigger an immediate initialization of the Colvars module, consider running “run 0".

In the remainder of this section, the most frequently used commands of the Colvars scripting interface are discussed and exemplified. For a full list of scripting commands available, see section 7.

To define new collective variables and/or biases for immediate use in the current session, configuration can be loaded from an external configuration file:

fix_modify Colvars configfile "colvars-file.in" 

This can in principle be called at any time, if only flags internal to Colvars are being modified. In practice, when new atoms or any new atomic properties (e.g. total forces) are being requested, initialization steps will be required that are not carried out during a simulation. Therefore, it is generally good practice in a simulation to change the Colvars configuration outside the scope between segments of the same computation.

To load the configuration directly from a string the “config" method may be used:

fix_modify Colvars config "keyword { ... }" 

This method is particularly useful to dynamically define the Colvars configuration within a LAMMPS script. For example, when running an ensemble of umbrella sampling simulations in LAMMPS, it may be convenient to use an identical script and define the specific window through environment variables.

In the following example, the environment variable “SLURM_ARRAY_TASK_ID" is set in a Slurm array job to increasing values starting at 0. The value of this variable is used to define the window's numeric index, and the umbrella restraint center beginning at 2.00 for the first window, and increasing in increments of 0.25 for all other windows:

variable window getenv SLURM_ARRAY_TASK_ID
fix_modify Colvars config """
harmonic {
  name us_${window}
  colvars xi
  centers [expr 2.0 + 0.25 * ${window}]
  ...
}""" 

After a configuration is fully defined, the “load" method may be used to load a state file from a previous simulation that contains e.g. data from history-dependent biases), to either continue that simulation or analyze its results:

fix_modify Colvars load "$<$oldjob$>$.colvars.state"

or more simply using the prefix of the state file itself:

fix_modify Colvars load "$<$oldjob$>$"

Anything following the “.colvars.state" suffix will be stripped.

Note that the Colvars state is already loaded automatically as part of the LAMMPS restart file, when this is read via the LAMMPS read_restart command; the “load" method allows to load a different state file after the fact.

The “save" method, analogous to “load", allows to save all restart information to a state file. This is normally not required during a simulation if colvarsRestartFrequency is defined (either directly or indirectly by the LAMMPS restart frequency). Because not only a state file (used to continue simulations) but also other data files (used to analyze the trajectory) are written, it is generally recommended to call the save method using a prefix, rather than a complete file name:

fix_modify Colvars save "$<$job$>$"

For computational efficiency the Colvars module keeps internal copies of the numeric IDs, masses, charges, positions, and optionally total forces of the atoms requested for a Colvars computation. At each simulation step, up-to-date versions of these properties are copied from the central memory of LAMMPS into the internal memory of the Colvars module. In a post-processing workflow or outside a simulation (e.g. when using VMD), this copy can be carried out as part of the update method:

fix_modify Colvars update   

which also performs the (re-)computation of all variables and biases defined in Colvars.

For example, the current sequence of numeric IDs of the atoms processed by Colvars can be obtained as:

fix_modify Colvars getatomids   

and their current positions as:

fix_modify Colvars getatompositions   

This may prove useful to test the correctness of the coordinates passed to Colvars, particularly in regard to periodic boundary conditions (5.3). There is currently no mechanism to modify the above fields via the scripting interface, but such capability will be added in the future.

While running a simulation, or when setting one up in VMD, it is possible to examine all the forces that were last applied by Colvars to the atoms, or are about to be applied:

fix_modify Colvars getatomappliedforces   

where the length and order of this sequence matches that provided by the getatomids method. A simpler way of testing the stability of a Colvars configuration before or during a simulation makes use of aggregated data, such as the energy:

fix_modify Colvars getenergy   

the root-mean-square of the Colvars applied forces:

fix_modify Colvars getatomappliedforcesrms   

or the maximum norm of the applied forces:

fix_modify Colvars getatomappliedforcesmax   

which can be matched to a specific atom via its numeric ID obtained as:

fix_modify Colvars getatomappliedforcesmaxid   

See 7.1 for a complete list of scripting commands used to manage atomic data and runtime parameters of the Colvars module.

After one or more collective variables are defined, they can be accessed with the following syntax.

fix_modify Colvars colvar "$<$name$>$" $<$method$>$ arg1 arg2 ...

where “$<$name$>$" is the name of the variable.

For example, to recompute the collective variable “xi" after a change in its parameters, the following command can be used:

fix_modify Colvars colvar "xi" update  

This ordinarily is not needed during a simulation run, where all variables are recomputed at every step (along with biasing forces acting on them). However, when analyzing an existing trajectory, e.g. in VMD, a call to update is generally required.

While in all typical cases all configuration of the variables is done with the “config" or “configfile" methods, a limited set of changes can be enacted at runtime using:

fix_modify Colvars colvar "$<$name$>$" modifycvcs arg1 arg2 ...

where each argument is a string passed to the function or functions that are used to compute the variable, and are called colvar components, or CVCs (4.1). For example, a variable “DeltaZ" made of a single “distanceZ" component can be made periodic with a period equal to the unit cell dimension along the $Z$-axis:

fix_modify Colvars colvar "DeltaZ" modifycvcs "period ${Lz}" 

Please note that this option is currently limited to changing the values of the polynomial superposition parameters componentCoeff, or of the componentExp to update on the fly, of period, wrapAround or forceNoPBC options for components where it is relevant. Furthermore, because the call above uses an immediate expansion of the variable “${Lz}", its value will not be updated during a constant-pressure simulation.

If the variable is computed using many components, it is possible to selectively turn some of them on or off:

fix_modify Colvars colvar "$<$name$>$" cvcflags $<$flags$>$

where “$<$flags$>$" is a list of 0/1 values, one per component.

Important: None of the changes enacted by the “modifycvcs" or “cvcflags" methods will be saved to state files, and will be lost when restarting a simulation, deleting the corresponding collective variable, or resetting the module with the “reset" method.

As soon as a colvar “xi" and its associated biasing potentials are up to date (i.e. during a MD run, or after the respective “update" methods have been called), the force applied onto the colvar is known and may be accessed through the getappliedforce method:

fix_modify Colvars colvar "xi" getappliedforce  

See also the use of the outputAppliedForce option to have this force be saved to file during a simulation.

Aside from the biasing methods already implemented within Colvars (6) this force may be incremented ad hoc:

fix_modify Colvars colvar "xi" addforce $<$force$>$

where “$<$force$>$" is a scalar or a vector (depending on the type of variable “xi"). Although this would offer in principle a way to add custom forces to a variable, fix_modify is executed outside the run or minimize commands, and the given force will be reset during a simulation.

For certain types of variable, the force applied directly on a colvar may be combined with those acting indirectly on it via the interatomic force field, making up the total force. When the outputTotalForce keyword is enabled, or when a biasing method that makes explicit use of the total force is enabled, the total force may be obtained as:

fix_modify Colvars colvar "xi" gettotalforce  

Note that not all types of variable support total-force computation, and the value of the total force may not be available immediately within the same simulation step: see the documentation of outputTotalForce for more details.

See 7.2 for a complete list of scripting commands used to manage collective variables.

Because biases depend only upon data internal to the Colvars module (i.e. they do not need atomic coordinates from LAMMPS), it is generally easy to create them or update their configuration at any time. For example, given the most current value of the variable “xi", an already-defined harmonic restraint on it named “h_xi" can be updated as:

fix_modify Colvars bias "h_xi" update  

During a running simulation this step is not needed, because an automatic update of each bias is already carried out.

Some types of bias are history-dependent, and the magnitude of their forces depends not only on the values of their corresponding variables, but also on previous simulation history. It is thus useful to load information from a state file that contains information specifically for one bias only, for example:

fix_modify Colvars bias "metadynamics1" load "old.colvars.state" 

or alternatively, using the prefix of the file instead of its full name:

fix_modify Colvars bias "metadynamics1" load "old" 

A corresponding “save" function is also available:

fix_modify Colvars bias "metadynamics1" save "new" 

Please note that the file above must contain only the state information for that particular bias: loading a state file for the whole module is not allowed.

This pair of functions is also used internally by Colvars to implement e.g. multiple-walker metadynamics (6.6.7), but they can be called from a scripted function to implement alternative coupling schemes.

See 7.3 for a complete list of scripting commands used to manage biases.

Configuration for the Colvars module is passed using an external file. Configuration lines follow the format “keyword value" or “keyword { ... }", where the keyword and its value must be separated by one or more space characters. The following formatting rules apply:

• Keywords are case-insensitive; for example, upperBoundary is the same as upperboundary and UPPERBOUNDARY); note that their string values are however still case-sensitive (e.g. names of variables, file names).
• A long value, or a list of multiple values, can be distributed across multiple lines by using curly braces, “{" and “}": the opening brace “{" must occur on the same line as the keyword, following at least one space character; the closing brace “}" may be at any position after that; any keywords following the closing brace on the same line are not valid (they should appear instead on a different line).
• Many keywords are nested, and are only meaningful within the specific context of another keyword; for example, the keyword name is available inside the block of the keyword colvar {...}, but not outside of it; for every keyword documented in the following, the “parent" keyword that defines such context is also indicated.
• If a keyword requiring a boolean value (yes|on|true or no|off|false) is provided without an explicit value, it defaults to ‘yes|on|true'; for example, ‘outputAppliedForce' may be used as shorthand for ‘outputAppliedForce on'.
• The hash character “#" indicates a comment: all text in the same line following this character will be ignored.
• Outside of comments, only ASCII characters are allowed for defining keywords, and the only white-space characters supported are spaces, tabs and newlines: a warning will be printed upon detection of non-ASCII characters in a configuration line, which include both characters that are visibly “special", as well as those with a very similar appearance to ASCII ones (for instance, non-breaking spaces); common ways to identify/remove non-ASCII characters are using the Emacs text editor, or using LC_ALL=C vi.

The following keywords are available in the global context of the Colvars configuration, i.e. they are not nested inside other keywords:

• colvarsTrajFrequency — Colvar value trajectory frequency
  Default: 100 $[$ positive integer, context: global $]$
  The values of each colvar (and of other related quantities, if requested) are written to the file output.colvars.traj every these many steps throughout the simulation. If the value is 0, such trajectory file is not written. For optimization the output is buffered, and synchronized with the disk only when the restart file is being written.
• colvarsRestartFrequency — Colvar module restart frequency
  Default: LAMMPS restart frequency when defined $[$ positive integer, context: global $]$
  When this value is non-zero, a state file suitable for restarting will be written every these many steps. Additionally, any other output files produced by Colvars are written as well (except the trajectory file, which is written every colvarsTrajFrequency steps). It is generally a good idea to leave this parameter at its default value, unless needed for special cases or to disable automatic writing of output files altogether. If neeed, writing of all output files can still be triggered at any time via the save scripting function.
• indexFile — Index file for atom selection (GROMACS “ndx" format)
  $[$ UNIX filename, context: global $]$
  This option reads an index file (usually with a .ndx extension) as produced by the make_ndx tool of GROMACS. This keyword may be repeated to load multiple index files. A group with the same name may appear multiple times, as long as it contains the same indices in identical order each time: an error is raised otherwise. In LAMMPS, the group2ndx command can be used to generate such file from existing groups. Note that the Colvars module reads the indices of atoms from the index file: therefore, the LAMMPS groups do not need to remain active during the simulation, and could be deleted right after issuing group2ndx. The names of index groups contained in this file can then be used to define atom groups with the indexGroup keyword. Other supported methods to select atoms are described in 5.
• smp — Whether SMP parallelism should be used
  Default: on $[$ boolean, context: global $]$
  If this flag is enabled (default), SMP parallelism over threads will be used to compute variables and biases, provided that this is supported by the LAMMPS build in use.

Several of the sampling methods implemented in Colvars are time- or history-dependent, i.e. they work by accumulating data as a simulation progresses, and use these data to determine their biasing forces. If the simulation engine uses a checkpoint or restart file (as GROMACS and LAMMPS do), any data needed by Colvars are embedded into that file. Otherwise, a dedicated state file can be loaded into Colvars directly.

When a dedicated Colvars state file is used, it may be in either one of two formats:

• Formatted, i.e. “text" format, which takes more space and is slower to to load/save but is also portable across different platforms and even different simulation engines (save for changes in physical units). This format is used by default, unless explicitly requested otherwise.
• Unformatted, i.e. “binary" format, which is both space-efficient and quick to load/save, but requires that the same LAMMPS build was used to write the file and that the Colvars configuration remains the same. This format is supported by Colvars versions starting 2023-09-25. Colvars state files can be written in binary format by setting the environment variable “COLVARS_BINARY_RESTART" to 1.

In either format, the state file contains accumulated data as well as the step number at the end of the run. The step number read from a state file overrides any value that LAMMPS provides, and will be incremented if the simulation proceeds. This means that the step number used internally by Colvars may not always match the step number reported by LAMMPS.

read_restart filename 

Alternatively, restarting from a Colvars-specific state file is also possible by providing the input keyword to the fix colvars command:

fix Colvars all colvars configfile input input_prefix 

When the “input" keyword is used, the contents of the file $<$input_prefix$>$.colvar.state override the information read from the LAMMPS restart file. Finally, a state file may also be loaded after initialization through the “fix_modify" command:

fix_modify Colvars input new_input_prefix 

In some cases, it is useful to modify the configuration of variables or biases between consecutive runs, for example by adding or removing a restraint. Some special provisions will happen in that case. When a state file is loaded, no information is available about any newly added variable or bias, which will thus remain uninitialized until the first compute step. Conversely, any information that the state file may contain about variables or biases that are no longer defined will be silently ignored. Please note that these checks are performed based only on the names of variables and biases: it is your responsibility to ensure that these names have consistent definitions between runs.

The flexibility just described carries some limitations: namely, it is only supported when reading text-format Colvars state files. Instead, restarting from binary files (such as the LAMMPS restart file) after a configuration change will trigger an error. It is also important to remind that when switching to a different build of LAMMPS, the binary format may change slightly, even if the release version is the same.

To work around the potential issues just described, a text-format Colvars state file should be loaded. This can be achieved by providing an explicit input keyword when initializing the Colvars fix (see 3.2), which will instruct Colvars to use the given filename, instead of the LAMMPS restart file. Furthermore, the fix_modify scripting command allows to load a Colvars file after initialization (3.3.2).

When the output prefix output is defined, the following output files are written during a simulation run:

• A state file, named output.colvars.state, which is written at the end of the specified run. This file is in plain text format by default, or in binary format if the environment variable COLVARS_BINARY_RESTART is set to a non-zero integer. The state file can be used to continue a simulation: unless its contents are embedded in the checkpoint file of the MD engine itself (currently, GROMACS and LAMMPS support this), instructions for loading the Colvars state file will be required in the simulation script (see 3.6).
• If the parameter colvarsRestartFrequency is larger than zero and the restart prefix is defined, a restart file is written every that many steps: this file is fully equivalent to the final state file. The name of this file is restart.colvars.state.
• If the parameter colvarsTrajFrequency is greater than 0 (default value: 100 steps), a trajectory file, named output.colvars.traj, is written during the simulation. Unlike a state file, this file is not needed to restart a simulation, but can be used for post-processing and analysis. The format of this file is described in sec. 3.8.5.
• Additionally, certain features, when enabled, can emit output files with a specific purpose: for example, potentials of mean force (PMFs) can be written to file to be analyzed or plotted. These files are described in the respective sections, but as a general rule they all use names beginning with the output prefix. Like the trajectory file, these additional files are needed only for analyzing a simulation's results, but not to continue it.

This section summarizes the file formats of various files that Colvars may be reading or writing.

Configuration files are text files that are generally read as input by LAMMPS. Starting from version 2017-02-01, changes in newline encodings are handled transparently, i.e. it is possible to typeset a configuration file in Windows (CR-LF newlines) and then use it with Linux or macOS (LF-only newlines).

Formatted state files, although not written manually, follow otherwise the same text format as configuration files. Binary state files can only be read by the Colvars code itself.

For atom selections that cannot be specified only by using internal Colvars keywords, external index files may also be used following the NDX format used in GROMACS:

[ group_1_name ]
  i1  i2  i3  i4  ...
  ...             ...  iN
[ group_2_name ]
  ... 

where i1 through iN are 1-based indices. Each group name may not contain spaces or tabs: otherwise, a parsing error will be raised.

Multiple index files may be provided to Colvars, each using the keyword indexFile. Two index files may contain groups with the same names, however these must also represent identical atom selections, i.e. the same sequence of indices including order.

Other than with GROMACS, an index group may also be generated from the VMD command-line interface, using the helper function write_index_group provided in the colvartools folder:

source colvartools/write_index_group.tcl
set sel [atomselect top "resname XXX and not hydrogen"]
write_index_group indexfile.ndx $sel "Ligand" 

In LAMMPS, NDX files may also be generated from internal groups via the group2ndx command.

where $N$ is the number of atomic coordinates in the file and $E_i$ is the chemical element of the $i$-th atom. Because $E_i$ is not used in Colvars, any string that does not contain tabs or spaces is acceptable.

Note: all XYZ coordinates are assumed to be expressed in Å units, regardless of the units currently used by LAMMPS.

An XYZ file may contain either one of the following scenarios:

1. The file contains as many coordinates as the atoms that they are being read for: all coordinates will be read from the file following the same order as the atoms appear in the selection generated using the keywords listed in section 5. (Note that the order is guaranteed only if a single type of selection keyword is used one or more times, and not guaranteed when different types of selection keywords are used.)
2. The file contains more coordinates than needed, and it is assumed to contain coordinates for the entire system: only coordinates that match the numeric indices of the selected atoms are read, in order of increasing number.

XYZ-file coordinates are read directly by Colvars and stored internally as double-precision floating point numbers.

Many simulation methods and analysis tools write files that contain functions of the collective variables tabulated on a grid (e.g. potentials of mean force or multidimensional histograms) for the purpose of analyzing results. Such files are produced by ABF (6.3), metadynamics (6.6), multidimensional histograms (6.13), as well as any restraint with optional thermodynamic integration support (6.2).

In some cases, these files may also be read as input of a new simulation. Suitable input files for this purpose are typically generated as output files of previous simulations, or directly by the user in the specific case of ensemble-biased metadynamics (6.6.5). This section explains the “multicolumn" format used by these files. For a multidimensional function $f({\xi }_1$, ${\xi }_2$, …$)$ the multicolumn grid format is defined as follows:

Lines beginning with the character “#" are the header of the file. $N_{cv}$ is the number of collective variables sampled by the grid. For each variable ${\xi }_i$, $min\left({\xi }_i\right)$ is the lowest value sampled by the grid (i.e. the left-most boundary of the grid along ${\xi }_i$), $width\left({\xi }_i\right)$ is the width of each grid step along ${\xi }_i$, $npoints\left({\xi }_i\right)$ is the number of points and $periodic\left({\xi }_i\right)$ is a flag whose value is 1 or 0 depending on whether the grid is periodic along ${\xi }_i$. In most situations:

• $min\left({\xi }_i\right)$ is given by the lowerBoundary keyword of the variable ${\xi }_i$;
• $width\left({\xi }_i\right)$ is given by the width keyword;
• $npoints\left({\xi }_i\right)$ is calculated from the two above numbers and the upperBoundary keyword;
• $periodic\left({\xi }_i\right)$ is set to 1 if and only if ${\xi }_i$ is periodic and the grids' boundaries cover its period.

How the grid's boundaries affect the sequence of points depends on how the contents of the file were computed. In many cases, such as histograms and PMFs computed by metadynamics (6.6.5), the values of ${\xi }_i$ in the first few columns correspond to the midpoints of the corresponding bins, i.e. ${\xi }_1^1=min\left({\xi }_i\right)+width\left({\xi }_i\right)∕2$. However, there is a slightly different format in PMF files computed by ABF (6.3) or other biases that use thermodynamic integration (6.2). In these cases, it is free-energy gradients that are accumulated on an (npoints)-long grid along each variable $\xi$: after these gradients are integrated, the resulting PMF is discretized on a slightly larger grid with (npoints+1) points along $\xi$ (unless the interval is periodic). Therefore, the grid's outer edges extend by $width\left({\xi }_i\right)∕2$ above and below the specified boundaries, so that for instance $min\left({\xi }_i\right)$ in the header appears to be shifted back by $width\left({\xi }_i\right)∕2$ compared to what would be expected. Please keep this difference in mind when comparing PMFs computed by different methods.

After the header, the rest of the file contains values of the tabulated function $f({\xi }_1$, ${\xi }_2$, …${\xi }_{N_{cv}})$, one for each line. The first $N_{cv}$ columns contain values of ${\xi }_1$, ${\xi }_2$, …${\xi }_{N_{cv}}$ and the last column contains the value of the function $f$. Points are sorted in ascending order with the fastest-changing values at the right (“C-style" order). Each sweep of the right-most variable ${\xi }_{N_{cv}}$ is terminated by an empty line. For two dimensional grid files, this allows quick visualization by programs such as GNUplot.

Example 1: multicolumn text file for a one-dimensional histogram with lowerBoundary = 15, upperBoundary = 48 and width = 0.1.

Example 2: multicolumn text file for a two-dimensional histogram of two dihedral angles (periodic interval with 6${}^{\circ }$ bins):

The Colvars trajectory file (with a suffix .colvars.traj) is a plain text file (scientific notation with 14-digit precision) whose columns represent quantities such as colvar values, applied forces, or individual restraints' energies. Under most scenarios, plotting or analyzing this file is straightforward: for example, the following contains a variable “$A$" and the energy of a restraint “$rA$":

#       step   A                     E_rA
           0    1.42467449615693e+01  6.30982865292123e+02
         100    1.42282559728026e+01  6.20640585041317e+02
…

Occasionally, if the Colvars configuration is changed mid-run certain quantities may be added or removed, changing the column layout. Labels in comment lines can assist in such cases: for example, consider the trajectory above with the addition of a second variable, “$B$", after 10,000 steps:

#       step   A                     E_rA
           0    1.42467449615693e+01  6.30982865292123e+02
         100    1.42282559728026e+01  6.20640585041317e+02
…
#       step   A                     B                     E_rA              
       10000    1.38136915830229e+01  9.99574098859265e-01  4.11184644791030e+02
       10100    1.36437184346326e+01  9.99574091957314e-01  3.37726286543895e+02

Analyzing the above file with standard tools is possible, but laborious: a convenience script is provided for this and related purposes. It may be used either as a command-line tool or as a Python module:

>>> from plot_colvars_traj import Colvars_traj
>>> traj = Colvars_traj('test.colvars.traj')
>>> print(traj['A'].steps, traj['A'].values)
[    0   100  ...  10000 10100] [14.246745 14.228256 ... 13.813692 13.643718]
>>> print(traj['B'].steps, traj['B'].values)
[10000 10100] [0.999574  0.9995741] 

A collective variable is defined by the keyword colvar followed by its configuration options contained within curly braces:

colvar {
  name xi
  $<$other options$>$
  function_name {
    $<$parameters$>$
    $<$atom selection$>$
  }
} 

There are multiple ways of defining a variable:

• The simplest and most common way way is using one of the precompiled functions (here called “components"), which are listed in section 4.1. For example, using the keyword rmsd (section 4.6.1) defines the variable as the root mean squared deviation (RMSD) of the selected atoms.
• A new variable may also be constructed as a linear or polynomial combination of the components listed in section 4.1 (see 4.17 for details).
• A user-defined mathematical function of the existing components (see list in section 4.1), or of the atomic coordinates directly (see the cartesian keyword in 4.9.1). The function is defined through the keyword customFunction (see 4.18 for details).

Choosing a component (function) is the only parameter strictly required to define a collective variable. It is also highly recommended to specify a name for the variable:

• name — Name of this colvar
  Default: “colvar" + numeric id $[$ string, context: colvar $]$
  The name is an unique case-sensitive string which allows the Colvars module to identify this colvar unambiguously; it is also used in the trajectory file to label to the columns corresponding to this colvar.

In this context, the function that computes a colvar is called a component. A component's choice and definition consists of including in the variable's configuration a keyword indicating the type of function (e.g. rmsd), followed by a definition block specifying the atoms involved (see 5) and any additional parameters (cutoffs, “reference" values, …). At least one component must be chosen to define a variable: if none of the keywords listed below is found, an error is raised.

The following components implement functions with a scalar value (i.e. a real number):

• distance: distance between two groups;
• distanceZ: projection of a distance vector on an axis;
• distanceXY: projection of a distance vector on a plane;
• distanceInv: mean distance between two groups of atoms (e.g. NOE-based distance);
• angle: angle between three groups;
• dihedral: torsional (dihedral) angle between four groups;
• dipoleAngle: angle between two groups and dipole of a third group;
• dipoleMagnitude: magnitude of the dipole of a group of atoms;
• polarTheta: polar angle of a group in spherical coordinates;
• polarPhi: azimuthal angle of a group in spherical coordinates;
• eulerPhi: Roll angle of rotation from references coordinates;
• eulerTheta: Pitch angle of rotation from references coordinates;
• eulerPsi: Yaw angle of rotation from references coordinates;
• coordNum: coordination number between two groups;
• selfCoordNum: coordination number of atoms within a group;
• hBond: hydrogen bond between two atoms;
• rmsd: root mean square deviation (RMSD) from a set of reference coordinates;
• eigenvector: projection of the atomic coordinates on a vector;
• orientationAngle: angle of the best-fit rotation from a set of reference coordinates;
• orientationProj: cosine of orientationProj;
• spinAngle: projection orthogonal to an axis of the best-fit rotation from a set of reference coordinates;
• tilt: projection on an axis of the best-fit rotation from a set of reference coordinates;
• gyration: radius of gyration of a group of atoms;
• inertia: moment of inertia of a group of atoms;
• inertiaZ: moment of inertia of a group of atoms around a chosen axis;
• alpha: $\alpha$-helix content of a protein segment.
• dihedralPC: projection of protein backbone dihedrals onto a dihedral principal component.

Some components do not return scalar, but vector values:

• distanceVec: distance vector between two groups (length: 3);
• distanceDir: unit vector parallel to distanceVec (length: 3);
• cartesian: vector of atomic Cartesian coordinates (length: $N$ times the number of Cartesian components requested, X, Y or Z);
• distancePairs: vector of mutual distances (length: $N_1\times N_2$);
• orientation: best-fit rotation, expressed as a unit quaternion (length: 4).

The types of components used in a colvar (scalar or not) determine the properties of that colvar, and particularly which biasing or analysis methods can be applied.

What if “X" is not listed? If a function type is not available on this list, it may be possible to define it as a polynomial superposition of existing ones (see 4.17), a custom function (see 4.18).

In the rest of this section, all available component types are listed, along with their physical units and their ranges of values, if limited. Such ranges are often used to define automatically default sampling intervals, for example by setting the parameters lowerBoundary and upperBoundary in the parent colvar.

For each type of component, the available configurations keywords are listed: when two components share certain keywords, the second component references to the documentation of the first one that uses that keyword. The very few keywords that are available for all types of components are listed in a separate section 4.14.

In all colvar components described below, the following rules apply concerning periodic boundary conditions (PBCs):

1. Distance vectors between two coordinates $d_{i,j}=({}_{}$