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}=\left(x_1-x_2\right)$, are calculated following the minimum-image convention by default, unless forceNoPBC is enabled. ($x_1$ and $x_2$ may be either individual atomic coordinates, or centers of mass of two groups.)
2. For all other functions of individual atomic coordinates, $f\left(x_1,x_2,\dots \&ApplyFunction;<!--FUNCTION\; APPLICATION-->\right)$, it is assumed that all atoms that are part of the same group are in the same periodic unit cell (see 5.3).

• forceNoPBC — Use absolute rather than minimum-image distances?
  Default: no $[$ boolean, context: any component $]$
  If this keyword is set to yes, PBCs will be ignored when calculating this component. This is only useful in a limited number of special cases, e.g. to describe the distance between remote points of a single macromolecule, which cannot be split across periodic cell boundaries, and for which the minimum-image distance might give the wrong result because of a relatively small periodic cell.

Example: ignoring PBCs in a distance between two groups. Using forceNoPBC yes when defining a distance { ... } function lets Colvars ignore the minimum-image convention when computing the distance between the centers of mass of group1 and group2. (Note that the centers of mass themselves are always calculated as weighted averages anyway).

colvar {
  name d
  distance {
    forceNoPBC yes
    group1 { … }
    group2 { … }
  }
}

The distance {...} block defines a distance component between the two atom groups, group1 and group2.

List of keywords (see also 4.2, 4.14, 4.15 and 4.17 for additional options):

• group1 — First group of atoms
  $[$ Atom group, context: distance $]$
  First group of atoms.
• group2 — analogous to group1
• oneSiteTotalForce — Measure total force on group 1 only?
  Default: no $[$ boolean, context: angle, dipoleAngle, dihedral $]$
  If this is set to yes, the total force is measured along a vector field (see equation (24) in section 6.3) that only involves atoms of group1. This option is only useful for ABF, or custom biases that compute total forces. See section 6.3 for details.
• forceNoPBC — Use absolute rather than minimum-image distances? (see description)
  Default: no

The value returned is a positive number (in length unit), ranging from $0$ to the largest possible interatomic distance within the chosen boundary conditions (with PBCs, the minimum image convention is used unless the forceNoPBC option is set).

The distanceZ {...} block defines a distance projection component, which can be seen as measuring the distance between two groups projected onto an axis, or the position of a group along such an axis. The axis can be defined using either one reference group and a constant vector, or dynamically based on two reference groups. One of the groups can be set to a dummy atom to allow the use of an absolute Cartesian coordinate.

List of keywords (see also 4.2, 4.14, 4.15 and 4.17 for additional options):

• main — Main group of atoms
  $[$ Atom group, context: distanceZ $]$
  Group of atoms whose position $r$ is measured.
• ref — Reference group of atoms
  $[$ Atom group, context: distanceZ $]$
  Reference group of atoms. The position of its center of mass is noted $r_1$ below.
• ref2 — Secondary reference group
  Default: none $[$ Atom group, context: distanceZ $]$
  Optional group of reference atoms, whose position $r_2$ can be used to define a dynamic projection axis: $e={(\parallel r_2-r_1\parallel )}^{-1}\times (r_2-r_1)$. In this case, the origin is $r_m=1∕2(r_1+r_2)$, and the value of the component is $e\cdot (r-r_m)$.
• axis — Projection axis
  Default: (0.0, 0.0, 1.0) $[$ (x, y, z) triplet, context: distanceZ $]$
  This vector will be normalized to define a projection axis $e$ for the distance vector $r-r_1$ joining the centers of groups ref and main. The value of the component is then $e\cdot (r-r_1)$. The vector should be written as three components separated by commas and enclosed in parentheses.
• oneSiteTotalForce — same definition as oneSiteTotalForce (distance component)
• forceNoPBC — Use absolute rather than minimum-image distances? (see description)
  Default: no

This component returns a number (in length unit) whose range is determined by the chosen boundary conditions. For instance, if the $z$ axis is used in a simulation with periodic boundaries, the returned value ranges between $-b_z∕2$ and $b_z∕2$, where $b_z$ is the box length along $z$ (this behavior is disabled if forceNoPBC is set).

The distanceXY {...} block defines a distance projected on a plane, and accepts the same keywords as the component distanceZ, i.e. main, ref, either ref2 or axis, and oneSiteTotalForce. It returns the norm of the projection of the distance vector between main and ref onto the plane orthogonal to the axis. The axis is defined using the axis parameter or as the vector joining ref and ref2 (see distanceZ above).

List of keywords (see also 4.2, 4.14, 4.15 and 4.17 for additional options):

• main — same definition as main (distanceZ component)
• ref — same definition as ref (distanceZ component)
• ref2 — same definition as ref2 (distanceZ component)
• axis — same definition as axis (distanceZ component)
• oneSiteTotalForce — same definition as oneSiteTotalForce (distance component)
• forceNoPBC — Use absolute rather than minimum-image distances? (see description)
  Default: no

The distanceVec component computes the 3-dimensional vector joining the centers of mass of group1 and group2. Its values are therefore multi-dimensional and are subject to the restrictions listed in 4.16. Moreover, when computing differences between two different values of a distanceVec variable the minimum-image convention is assumed (unless forceNoPBC is enabled).

List of keywords (see also 4.2, 4.14, 4.15 and 4.17 for additional options):

• group1 — same definition as group1 (distance component)
• group2 — analogous to group1
• oneSiteTotalForce — same definition as oneSiteTotalForce (distance component)
• forceNoPBC — Use absolute rather than minimum-image distances? (see description)
  Default: no

The distanceDir {...} block defines a distance unit vector component, which accepts the same keywords as the component distance: group1, group2, and forceNoPBC. It returns a 3-dimensional unit vector $d=(d_x,d_y,d_z)$, with $\left|d\right|=1$.

This multi-dimensional variable has two intrinsic degrees of freedom: however, these cannot be sampled independently as one-dimensional variables. A decomposition in two dimensions can be done using polarTheta and polarPhi angles, with the caveat that the latter is ill-defined when the former approaches 0${}^{\circ }$ or 180${}^{\circ }$.

The distance between two values of distanceDir is calculated internally as the angle (in radians) between the two unit vectors: this definition adapts the standard Euclidean distance to the unit sphere, to ensure that restraint forces comply with the mathematical constraint.

List of keywords (see also 4.2, 4.14, 4.15 and 4.17 for additional options):

• group1 — same definition as group1 (distance component)
• group2 — analogous to group1
• oneSiteTotalForce — same definition as oneSiteTotalForce (distance component)
• forceNoPBC — Use absolute rather than minimum-image distances? (see description)
  Default: no

The distanceInv {...} block defines a generalized mean distance between two groups of atoms 1 and 2, where each distance is taken to the power $-n$:

where $d_{ij}$ is the distance between atoms $i$ and $j$ in groups 1 and 2 respectively, and $n$ is an even integer.

List of keywords (see also 4.2, 4.14, 4.15 and 4.17 for additional options):

• group1 — same definition as group1 (distance component)
• group2 — analogous to group1
• oneSiteTotalForce — same definition as oneSiteTotalForce (distance component)
• exponent — Exponent $n$ in equation 2
  Default: 6 $[$ positive even integer, context: distanceInv $]$
  Defines the exponent to which the individual distances are elevated before averaging. The default value of 6 is useful for example to applying restraints based on NOE-measured distances.
• forceNoPBC — Use absolute rather than minimum-image distances? (see description)
  Default: no

This component returns a number ranging from $0$ to the largest possible distance within the chosen boundary conditions.

The angle {...} block defines an angle, and contains the three blocks group1, group2 and group3, defining the three groups. It returns an angle (in degrees) within the interval $[0:180]$.

List of keywords (see also 4.2, 4.14, 4.15 and 4.17 for additional options):

• group1 — same definition as group1 (distance component)
• group2 — analogous to group1
• group3 — analogous to group1
• oneSiteTotalForce — same definition as oneSiteTotalForce (distance component)
• forceNoPBC — Use absolute rather than minimum-image distances? (see description)
  Default: no

The dipoleAngle {...} block defines an angle, and contains the three blocks group1, group2 and group3, defining the three groups, being group1 the group where dipole is calculated. It returns an angle (in degrees) within the interval $[0:180]$.

List of keywords (see also 4.2, 4.14, 4.15 and 4.17 for additional options):

• group1 — same definition as group1 (distance component)
• group2 — analogous to group1
• group3 — analogous to group1
• oneSiteTotalForce — same definition as oneSiteTotalForce (distance component)
• forceNoPBC — Use absolute rather than minimum-image distances? (see description)
  Default: no

The dihedral {...} block defines a torsional angle, and contains the blocks group1, group2, group3 and group4, defining the four groups. It returns an angle (in degrees) within the interval $[-180:180]$. The Colvars module calculates all the distances between two angles taking into account periodicity. For instance, reference values for restraints or range boundaries can be defined by using any real number of choice.

List of keywords (see also 4.2, 4.14, 4.15 and 4.17 for additional options):

• group1 — same definition as group1 (distance component)
• group2 — analogous to group1
• group3 — analogous to group1
• group4 — analogous to group1
• oneSiteTotalForce — same definition as oneSiteTotalForce (distance component)
• forceNoPBC — Use absolute rather than minimum-image distances? (see description)
  Default: no

The polarTheta {...} block defines the polar angle in spherical coordinates, for the center of mass of a group of atoms described by the block atoms. It returns an angle (in degrees) within the interval $[0:180]$. To obtain spherical coordinates in a frame of reference tied to another group of atoms, use the fittingGroup (5.2) option within the atoms block. An example is provided in file examples/11_polar_angles.in of the Colvars public repository.

List of keywords (see also 4.2, 4.14, 4.15 and 4.17 for additional options):

• atoms — Group of atoms defining this function
  $[$ Atom group, context: polarPhi $]$
  Defines the group of atoms for the COM of which the angle should be calculated.
• forceNoPBC — Use absolute rather than minimum-image distances? (see description)
  Default: no

The polarPhi {...} block defines the azimuthal angle in spherical coordinates, for the center of mass of a group of atoms described by the block atoms. It returns an angle (in degrees) within the interval $[-180:180]$. The Colvars module calculates all the distances between two angles taking into account periodicity. For instance, reference values for restraints or range boundaries can be defined by using any real number of choice. To obtain spherical coordinates in a frame of reference tied to another group of atoms, use the fittingGroup (5.2) option within the atoms block. An example is provided in file examples/11_polar_angles.in of the Colvars public repository.

List of keywords (see also 4.2, 4.14, 4.15 and 4.17 for additional options):

• atoms — Group of atoms defining this function
  $[$ Atom group, context: polarPhi $]$
  Defines the group of atoms for the COM of which the angle should be calculated.
• forceNoPBC — Use absolute rather than minimum-image distances? (see description)
  Default: no

Note: polarPhi is ill-defined when the corresponding polarTheta component is close to 0${}^{\circ }$ or 180${}^{\circ }$; please take measures to avoid sampling these configurations in your simulations.

The coordNum {...} block defines a coordination number (or number of contacts), which calculates the function $(1-{(d∕d_0)}^n)∕(1-{(d∕d_0)}^m)$, where $d_0$ is the “cutoff" distance, and $n$ and $m$ are exponents that can control its long range behavior and stiffness [3]. This function is summed over all pairs of atoms in group1 and group2:

List of keywords (see also 4.2, 4.14, 4.15 and 4.17 for additional options):

• group1 — same definition as group1 (distance component)
• group2 — analogous to group1
• cutoff — “Interaction" distance (length unit)
  Default: 4.0 Å $[$ positive decimal, context: coordNum $]$
  This number defines the switching distance to define an interatomic contact: for $d\ll d_0$, the switching function $(1-{(d∕d_0)}^n)∕(1-{(d∕d_0)}^m)$ is close to 1, at $d=d_0$ it has a value of $n∕m$ ($1∕2$ with the default $n$ and $m$), and at $d\gg d_0$ it goes to zero approximately like $d^{m-n}$. Hence, for a proper behavior, $m$ must be larger than $n$.
• cutoff3 — Reference distance vector (length unit)
  Default: (4.0, 4.0, 4.0) Å $[$ “(x, y, z)" triplet of positive decimals, context: coordNum $]$
  The three components of this vector define three different cutoffs $d_0$ for each direction. This option is mutually exclusive with cutoff.
• expNumer — Numerator exponent
  Default: 6 $[$ positive even integer, context: coordNum $]$
  This number defines the $n$ exponent for the switching function.
• expDenom — Denominator exponent
  Default: 12 $[$ positive even integer, context: coordNum $]$
  This number defines the $m$ exponent for the switching function.
• group2CenterOnly — Use only group2's center of mass
  Default: off $[$ boolean, context: coordNum $]$
  If this option is on, only contacts between each atoms in group1 and the center of mass of group2 are calculated (by default, the sum extends over all pairs of atoms in group1 and group2). If group2 is a dummyAtom, this option is set to yes by default.
• tolerance — Pairlist control
  Default: 0.0 $[$ decimal, context: coordNum $]$
  This controls the pair list feature, dictating the minimum value for each summation element in Eq. 3 such that the pair that contributed the summation element is included in subsequent simulation timesteps until the next pai r list recalculation. For most applications, this value should be small (eg. 0.001) to avoid missing important contributions to the overall sum. Higher values will improve performance by reducing the number of pairs that contribute to the sum. Values above 1 will exclude all possible pair interactions. Similarly, values below 0 will never exclude a pair from consideration. To ensure continuous forces, Eq. 3 is further modified by subtracting the tolerance and then rescaling so that each pair covers the range $\left[0,1\right]$.
• pairListFrequency — Pairlist regeneration frequency
  Default: 100 $[$ positive integer, context: coordNum $]$
  This controls the pairlist feature, dictating how many steps are taken between regenerating pair lists if the tolerance is greater than 0.
• forceNoPBC — Use absolute rather than minimum-image distances? (see description)
  Default: no

This component returns a dimensionless number, which ranges from approximately 0 (all interatomic distances are much larger than the cutoff) to $N_{group1}\times N_{group2}$ (all distances are less than the cutoff), or $N_{group1}$ if group2CenterOnly is used. For performance reasons, at least one of group1 and group2 should be of limited size or group2CenterOnly should be used: the cost of the loop over all pairs grows as $N_{group1}\times N_{group2}$. Setting $tolerance>0$ ameliorates this to some degree, although every pair is still checked to regenerate the pair list.

The selfCoordNum {...} block defines a coordination number similarly to the component coordNum, but the function is summed over atom pairs within group1:

The keywords accepted by selfCoordNum are a subset of those accepted by coordNum, namely group1 (here defining all of the atoms to be considered), cutoff, expNumer, and expDenom.

List of keywords (see also 4.2, 4.14, 4.15 and 4.17 for additional options):

• group1 — same definition as group1 (coordNum component)
• cutoff — same definition as cutoff (coordNum component)
• cutoff3 — same definition as cutoff3 (coordNum component)
• expNumer — same definition as expNumer (coordNum component)
• expDenom — same definition as expDenom (coordNum component)
• tolerance — same definition as tolerance (coordNum component)
• pairListFrequency — same definition as pairListFrequency (coordNum component)
• forceNoPBC — Use absolute rather than minimum-image distances? (see description)
  Default: no

This component returns a dimensionless number, which ranges from approximately 0 (all interatomic distances much larger than the cutoff) to $N_{group1}\times (N_{group1}-1)∕2$ (all distances within the cutoff). For performance reasons, group1 should be of limited size, because the cost of the loop over all pairs grows as $N_{group1}^2$.

The hBond {...} block defines a hydrogen bond, implemented as a coordination number (eq. 3) between the donor and the acceptor atoms. Therefore, it accepts the same options cutoff (with a different default value of 3.3 Å), expNumer (with a default value of 6) and expDenom (with a default value of 8). Unlike coordNum, it requires two atom numbers, acceptor and donor, to be defined. It returns a dimensionless number, with values between 0 (acceptor and donor far outside the cutoff distance) and 1 (acceptor and donor much closer than the cutoff).

List of keywords (see also 4.2, 4.14, 4.15 and 4.17 for additional options):

• acceptor — Number of the acceptor atom
  $[$ positive integer, context: hBond $]$
  Number that uses the same convention as atomNumbers.
• donor — analogous to acceptor
• cutoff — same definition as cutoff (coordNum component)
  Note: default value is 3.3 Å.
• expNumer — same definition as expNumer (coordNum component)
  Note: default value is 6.
• expDenom — same definition as expDenom (coordNum component)
  Note: default value is 8.
• forceNoPBC — Use absolute rather than minimum-image distances? (see description)
  Default: no

The block rmsd {...} defines the root mean square replacement (RMSD) of a group of atoms with respect to a reference structure. For each set of coordinates $\left\{x_1\right(t),x_2(t),\dots \&ApplyFunction;<!--FUNCTION\; APPLICATION-->x_N(t\left)\right\}$, the colvar component rmsd calculates the optimal rotation $U^{\left\{x_i\right(t\left)\right\}\to \left\{x_i^{\left(ref\right)}\right\}}$ that best superimposes the coordinates $\left\{x_i\right(t\left)\right\}$ onto a set of reference coordinates $\left\{x_i^{\left(ref\right)}\right\}$. Both the current and the reference coordinates are centered on their centers of geometry, $x_{cog}\left(t\right)$ and $x_{cog}^{\left(ref\right)}$. The root mean square displacement is then defined as:

The optimal rotation $U^{\left\{x_i\right(t\left)\right\}\to \left\{x_i^{\left(ref\right)}\right\}}$ is calculated within the formalism developed in reference [4], which guarantees a continuous dependence of $U^{\left\{x_i\right(t\left)\right\}\to \left\{x_i^{\left(ref\right)}\right\}}$ with respect to $\left\{x_i\right(t\left)\right\}$.

List of keywords (see also 4.2, 4.14, 4.15 and 4.17 for additional options):

• atoms — Group of atoms defining this function
  $[$ Atom group, context: rmsd $]$
  Defines the group of atoms of which the RMSD should be calculated. Optimal fit options (such as refPositions and rotateToReference) should typically NOT be set within this block. Exceptions to this rule are the special cases discussed in the Advanced usage paragraph below.
• refPositions — Reference coordinates
  $[$ space-separated list of (x, y, z) triplets, context: rmsd $]$
  This option (mutually exclusive with refPositionsFile) sets the reference coordinates for RMSD calculation, and uses these to compute the roto-translational fit. See the equivalent option refPositions within the atom group definition for details on acceptable formats and other features.
• refPositionsFile — Reference coordinates file
  $[$ UNIX filename, context: rmsd $]$
  This option (mutually exclusive with refPositions) sets the reference coordinates for RMSD calculation, and uses these to compute the roto-translational fit. See the equivalent option refPositionsFile within the atom group definition for details on acceptable file formats and other features.
• atomPermutation — Alternate ordering of atoms for RMSD computation
  $[$ List of atom numbers, context: rmsd $]$
  If defined, this parameter defines a re-ordering (permutation) of the 1-based atom numbers that can be used to compute the RMSD, typically due to molecular symmetry. This parameter can be specified multiple times, each one defining a new permutation: the returned RMSD value is the minimum over the set of permutations. For example, if the atoms making up the group are 6, 7, 8, 9, and atoms 7, 8, and 9 are invariant by circular permutation (as the hydrogens in a CH3 group), a symmetry-adapted RMSD would be obtained by adding:
  atomPermutation 6 8 9 7
  atomPermutation 6 9 7 8
  This will result in these 2 atom orders being considered in addition to the order used when defining the atom group. Note that this does not affect the least-squares roto-translational fit. Therefore, this feature is mostly useful when using custom fitting parameters within the atom group, such as fittingGroup, or when fitting is disabled altogether. For details, see reference [5].
• forceNoPBC — Use absolute rather than minimum-image distances? (see description)
  Default: no

This component returns a positive real number (in length unit).

1. applying the optimal translation, but no rotation (rotateToReference off), to bias or restrain the shape and orientation, but not the position of the atom group;
2. applying the optimal rotation, but no translation (centerToReference off), to bias or restrain the shape and position, but not the orientation of the atom group;
3. disabling the application of optimal roto-translations, which lets the RMSD component describe the deviation of atoms from fixed positions in the laboratory frame: this allows for custom positional restraints within the Colvars module;
4. fitting the atomic positions to different reference coordinates than those used in the RMSD calculation itself (by specifying refPositions or refPositionsFile within the atom group as well as within the rmsd block);
5. applying the optimal rotation and/or translation from a separate atom group, defined through fittingGroup: the RMSD then reflects the deviation from reference coordinates in a separate, moving reference frame (see example in the section on fittingGroup).

The block eigenvector {...} defines the projection of the coordinates of a group of atoms (or more precisely, their deviations from the reference coordinates) onto a vector in ${ℝ}^{3n}$, where $n$ is the number of atoms in the group. The computed quantity is the total projection:

where, as in the rmsd component, $U$ is the optimal rotation matrix, $x_{cog}\left(t\right)$ and $x_{cog}^{\left(ref\right)}$ are the centers of geometry of the current and reference positions respectively, and $v_i$ are the components of the vector for each atom. Example choices for $\left(v_i\right)$ are an eigenvector of the covariance matrix (essential mode), or a normal mode of the system. It is assumed that ${\sum \&ApplyFunction;<!--FUNCTION\; APPLICATION-->}_i{v}_i=0$: otherwise, the Colvars module centers the $v_i$ automatically when reading them from the configuration.

List of keywords (see also 4.2, 4.14, 4.15 and 4.17 for additional options):

• atoms — same definition as atoms (rmsd component)
• refPositions — same definition as refPositions (rmsd component)
• refPositionsFile — same definition as refPositionsFile (rmsd component)
• vector — Vector components
  $[$ space-separated list of (x, y, z) triplets, context: eigenvector $]$
  This option (mutually exclusive with vectorFile) sets the values of the vector components.
• vectorFile — file containing vector components
  $[$ UNIX filename, context: eigenvector $]$
  This option (mutually exclusive with vector) sets the name of an XYZ (3.8.3) coordinate file containing the vector components. Note: Reading data from a coordinate file may entail an automatic unit conversion if the length unit currently used by the MD engine is not Å. If this is not the desired behavior, this can be remedied using the normalizeVector option described below.
• normalizeVector — Normalize the vector components when reading them?
  Default: off $[$ boolean, context: eigenvector $]$
  If this flag is activated, the norm of the vector $\left|v\right|=\sqrt{{\sum \&ApplyFunction;<!--FUNCTION\; APPLICATION-->}_i{\left|v_i\right|}^2}$ is set equal to 1 by automatically rescaling all the components $v_i$; alternatively, the value of $\left|v\right|$ is printed.
• differenceVector — The $3n$-dimensional vector is the difference between vector and refPositions
  Default: off $[$ boolean, context: eigenvector $]$
  If this option is on, the numbers provided by vector are interpreted as another set of positions, $x_i^{\prime }$: the vector $v_i$ is then defined as $v_i=\left(x_i^{\prime }-x_i^{\left(ref\right)}\right)$. This allows to conveniently define a colvar $\xi$ as a projection on the linear transformation between two sets of positions, “A" and “B". If this flag is on, the vector is normalized so that $\xi =0$ when the atoms are at the set of positions “A" and $\xi =1$ at the set of positions “B". Setting normalizeVector on overrides this behavior.
• forceNoPBC — Use absolute rather than minimum-image distances? (see description)
  Default: no

The block gyration {...} defines the parameters for calculating the radius of gyration of a group of atomic positions $\left\{x_1\right(t),x_2(t),\dots \&ApplyFunction;<!--FUNCTION\; APPLICATION-->x_N(t\left)\right\}$ with respect to their center of geometry, $x_{cog}\left(t\right)$:

This component must contain one atoms {...} block to define the atom group, and returns a positive number, expressed in length unit.

List of keywords (see also 4.2, 4.14, 4.15 and 4.17 for additional options):

• atoms — same definition as atoms (rmsd component)
• forceNoPBC — Use absolute rather than minimum-image distances? (see description)
  Default: no

The block inertia {...} defines the parameters for calculating the total moment of inertia of a group of atomic positions $\left\{x_1\right(t),x_2(t),\dots \&ApplyFunction;<!--FUNCTION\; APPLICATION-->x_N(t\left)\right\}$ with respect to their center of geometry, $x_{cog}\left(t\right)$:

Note that all atomic masses are set to 1 for simplicity. This component must contain one atoms {...} block to define the atom group, and returns a positive number, expressed in length unit${}^2$.

List of keywords (see also 4.2, 4.14, 4.15 and 4.17 for additional options):

• atoms — same definition as atoms (rmsd component)
• forceNoPBC — Use absolute rather than minimum-image distances? (see description)
  Default: no

List of keywords (see also 4.2, 4.14, 4.15 and 4.17 for additional options):

• atoms — same definition as atoms (rmsd component)
• forceNoPBC — Use absolute rather than minimum-image distances? (see description)
  Default: no

The block inertiaZ {...} defines the parameters for calculating the component along the axis $e$ of the moment of inertia of a group of atomic positions $\left\{x_1\right(t),x_2(t),\dots \&ApplyFunction;<!--FUNCTION\; APPLICATION-->x_N(t\left)\right\}$ with respect to their center of geometry, $x_{cog}\left(t\right)$:

Note that all atomic masses are set to 1 for simplicity. This component must contain one atoms {...} block to define the atom group, and returns a positive number, expressed in length unit${}^2$.

List of keywords (see also 4.2, 4.14, 4.15 and 4.17 for additional options):

• atoms — same definition as atoms (rmsd component)
• axis — Projection axis
  Default: (0.0, 0.0, 1.0) $[$ (x, y, z) triplet, context: inertiaZ $]$
  The three components of this vector define (when normalized) the projection axis $e$.
• forceNoPBC — Use absolute rather than minimum-image distances? (see description)
  Default: no

The variables discussed in this section quantify the rotations of macromolecules (or other quasi-rigid objects) from a given set of reference coordinates to the current coordinates. Such rotations are computed following the same method used for best-fit RMSDs (see rmsd and fittingGroup). The underlying mathematical formalism is described in reference [4], and the implementation in reference [1].

The first of the functions described is the orientation, which describes the full rotation as a unit quaternion $q=(q_0,q_1,q_2,q_3)$, i.e. 4 numbers with one constraint (3 degrees of freedom). The quaternion $q$ is one of only two representations that are both complete and accurate, the other being a $3\times 3$ unit matrix with 3 independent parameters. Although $q$ is used internally in the Colvars module for features such as the rmsd function and the fittingGroup option, its direct use as a collective variable is more difficult, and mostly limited to fixed or moving restraints.

The two functions orientationAngle and orientationProj, with the latter being the cosine of the former, represent the amplitude of the full rotation described by $q$, regardless of the direction of its axis. As one-dimensional scalar variables, both orientationAngle and orientationProj are a much reduced simplification of the full rotation. However, they can be used in a variety of methods including both restraints and PMF computations.

A slightly more complete parametrization is achieved by decomposing the full rotation into the two parameters, tilt and spinAngle. These quantify the amplitudes of two independent sub-rotations away from a certain axis $e$, and around the same axis $e$, respectively. The axis $e$ is chosen by the user, and is by default the Z axis: under that choice, tilt is equivalent to the sine of the Euler “pitch" angle $𝜃$, and spinAngle to the sum of the other two angles, $(\varphi +\psi )$. This parameterization is mathematically well defined for almost all full rotations, including small ones when the current coordinates are almost completely aligned with the reference ones. However, a mathematical singularity prevents using the spinAngle function near configurations where the value of tilt tilt is -1 (i.e. a -180${}^{\circ }$ rotation around an axis orthogonal to $e$). For these reasons, tilt and spinAngle are useful when the allowed rotations are known to have approximately the same axis, and differ only in the magnitude of the corresponding angle. In this use case, spinAngle measures the angle of the sub-rotation around the chosen axis $e$, whereas tilt measures the dot product between $e$ and the actual axis of the full rotation.

Lastly, the traditional Euler angles are also available as the functions eulerPhi, eulerTheta and eulerPsi. Altogether, these are sufficient to represent all three degrees of freedom of a full rotation. However, they also suffer from the potential “gimbal lock" problem, which emerges whenever $𝜃\simeq \pm 90^{\circ }$, which includes also the case where the full rotation is small. Under such conditions, the angles $\varphi$ and $\psi$ are both ill-defined and cannot be used as collective variables. For these reasons, it is highly recommended that Euler angles are used only in simulations where their range of applicability is known ahead of time, and excludes configurations where $𝜃\simeq \pm 90^{\circ }$ altogether.

The block orientation {...} returns the same optimal rotation used in the rmsd component to superimpose the coordinates $\left\{x_i\right(t\left)\right\}$ onto a set of reference coordinates $\left\{x_i^{\left(ref\right)}\right\}$. Such component returns a four dimensional vector $q=(q_0,q_1,q_2,q_3)$, with ${\sum \&ApplyFunction;<!--FUNCTION\; APPLICATION-->}_i{q}_i^2=1$; this quaternion expresses the optimal rotation $\left\{x_i\right(t\left)\right\}\to \left\{x_i^{\left(ref\right)}\right\}$ according to the formalism in reference [4]. The quaternion $(q_0,q_1,q_2,q_3)$ can also be written as $\left(\cos \&ApplyFunction;<!--FUNCTION\; APPLICATION-->(𝜃∕2),\sin \&ApplyFunction;<!--FUNCTION\; APPLICATION-->(𝜃∕2)u\right)$, where $𝜃$ is the angle and $u$ the normalized axis of rotation; for example, a rotation of 90${}^{\circ }$ around the $z$ axis is expressed as “(0.707, 0.0, 0.0, 0.707)". The script quaternion2rmatrix.tcl provides Tcl functions for converting to and from a $4\times 4$ rotation matrix in a format suitable for usage in VMD.

As for the component rmsd, the available options are atoms, refPositionsFile and refPositions.

Note: refPositions and refPositionsFile define the set of positions from which the optimal rotation is calculated, but this rotation is not applied to the coordinates of the atoms involved: it is used instead to define the variable itself.

List of keywords (see also 4.2, 4.14, 4.15 and 4.17 for additional options):

• atoms — same definition as atoms (rmsd component)
• refPositions — same definition as refPositions (rmsd component)
• refPositionsFile — same definition as refPositionsFile (rmsd component)
• closestToQuaternion — Reference rotation
  Default: (1.0, 0.0, 0.0, 0.0) (“null" rotation) $[$ “(q0, q1, q2, q3)" quadruplet, context: orientation $]$
  Between the two equivalent quaternions $(q_0,q_1,q_2,q_3)$ and $(-q_0,-q_1,-q_2,-q_3)$, the closer to (1.0, 0.0, 0.0, 0.0) is chosen. This simplifies the visualization of the colvar trajectory when sampled values are a smaller subset of all possible rotations. Note: this only affects the output, never the dynamics.
• forceNoPBC — Use absolute rather than minimum-image distances? (see description)
  Default: no

Example: stopping the rotation of a protein. To stop the rotation of an elongated macromolecule in solution (and use an anisotropic box to save water molecules), it is possible to define a colvar with an orientation component, and restrain it through the harmonic bias around the identity rotation, (1.0, 0.0, 0.0, 0.0). Only the overall orientation of the macromolecule is affected, and not its internal degrees of freedom.

colvar {
  name Orient
  orientation {
    atoms { … }
    refPositionsFile reference.pdb
  }
}

harmonic {             # Define a harmonic restraint
  colvars Orient       # acting on colvar "Orient"
  centers  (1.0, 0.0, 0.0, 0.0)  # center the unit quaternion (no rotation)
  forceConstant 500.0            # unit is energy: quaternions are dimensionless
}

The block orientationAngle {...} accepts the same base options as the component orientation: atoms, refPositions, refPositionsFile. The returned value is the angle of rotation $𝜃$ between the current and the reference positions. This angle is expressed in degrees within the range [0${}^{\circ }$:180${}^{\circ }$].

List of keywords (see also 4.2, 4.14, 4.15 and 4.17 for additional options):

• atoms — same definition as atoms (rmsd component)
• refPositions — same definition as refPositions (rmsd component)
• refPositionsFile — same definition as refPositionsFile (rmsd component)
• forceNoPBC — Use absolute rather than minimum-image distances? (see description)
  Default: no

The block orientationProj {...} accepts the same base options as the component orientation: atoms, refPositions, refPositionsFile. The returned value is the cosine of the angle of rotation $𝜃$ between the current and the reference positions. The range of values is [-1:1].

List of keywords (see also 4.2, 4.14, 4.15 and 4.17 for additional options):

• atoms — same definition as atoms (rmsd component)
• refPositions — same definition as refPositions (rmsd component)
• refPositionsFile — same definition as refPositionsFile (rmsd component)
• forceNoPBC — Use absolute rather than minimum-image distances? (see description)
  Default: no

The complete rotation described by orientation can optionally be decomposed into two sub-rotations: one is a “spin" rotation around e, and the other a “tilt" rotation around an axis orthogonal to e. The component spinAngle measures the angle of the “spin" sub-rotation around e.

List of keywords (see also 4.2, 4.14, 4.15 and 4.17 for additional options):

• atoms — same definition as atoms (rmsd component)
• refPositions — same definition as refPositions (rmsd component)
• refPositionsFile — same definition as refPositionsFile (rmsd component)
• axis — Special rotation axis
  Default: (0.0, 0.0, 1.0) $[$ (x, y, z) triplet, context: tilt $]$
  The three components of this vector define (when normalized) the special rotation axis used to calculate the tilt and spinAngle components.
• forceNoPBC — Use absolute rather than minimum-image distances? (see description)
  Default: no

The component spinAngle returns an angle (in degrees) within the periodic interval $[-180:180]$.

Note: the value of spinAngle is a continuous function almost everywhere, with the exception of configurations with the corresponding “tilt" angle equal to 180${}^{\circ }$ (i.e. the tilt component is equal to $-1$): in those cases, spinAngle is undefined. If such configurations are expected, consider defining a tilt colvar using the same axis e, and restraining it with a lower wall away from $-1$.

The component tilt measures the cosine of the angle of the “tilt" sub-rotation, which combined with the “spin" sub-rotation provides the complete rotation of a group of atoms. The cosine of the tilt angle rather than the tilt angle itself is implemented, because the latter is unevenly distributed even for an isotropic system: consider as an analogy the angle $𝜃$ in the spherical coordinate system. The component tilt relies on the same options as spinAngle, including the definition of the axis e. The values of tilt are real numbers in the interval $[-1:1]$: the value $1$ represents an orientation fully parallel to e (tilt angle = 0${}^{\circ }$), and the value $-1$ represents an anti-parallel orientation.

List of keywords (see also 4.2, 4.14, 4.15 and 4.17 for additional options):

• atoms — same definition as atoms (rmsd component)
• refPositions — same definition as refPositions (rmsd component)
• refPositionsFile — same definition as refPositionsFile (rmsd component)
• axis — same definition as axis (spinAngle component)
• forceNoPBC — Use absolute rather than minimum-image distances? (see description)
  Default: no

Assuming the axes of the original frame are denoted as x, y, z and the axes of the rotated frame as X, Y, Z, the line of nodes, N, can be defined as the intersection of the plane xy and XY. The axis perpendicular to N and z is defined as P. In this case, as illustrated in the figure below, the complete rotation described by orientation can optionally be decomposed into three Euler angles:

• the “roll" angle $\varphi$, i.e. the rotation angle from the x axis to the N axis;
• the “pitch" angle $𝜃$, i.e. the rotation angle from the P axis to the Z axis, and
• the “yaw" angle $\psi$, i.e. the rotation angle from the N axis to the X axis.

Although Euler angles are more straightforward to use than quaternions, they are also potentially subject to the “gimbal lock" problem:
https://en.wikipedia.org/wiki/Gimbal_lock
which arises whenever $𝜃\simeq \pm 90^{\circ }$, including the common case when the simulated coordinates are near the reference coordinates. Therefore, a safe use of Euler angles as collective variables requires the use of restraints to avoid such singularities, such as done in reference [6] and in the protein-ligand binding NAMD tutorial.

The eulerPhi component accepts exactly the same options as orientation, and measures the rotation angle from the x axis to the N axis. This angle is expressed in degrees within the periodic range $[-180^{\circ }:180^{\circ }]$.

List of keywords (see also 4.2, 4.14, 4.15 and 4.17 for additional options):

• atoms — same definition as atoms (rmsd component)
• refPositions — same definition as refPositions (rmsd component)
• refPositionsFile — same definition as refPositionsFile (rmsd component)
• forceNoPBC — Use absolute rather than minimum-image distances? (see description)
  Default: no

This component accepts exactly the same options as orientation, and measures the rotation angle from the P axis to the Z axis. This angle is expressed in degrees within the range $[-90^{\circ }:90^{\circ }]$.

Warning: When this angle reaches $-90^{\circ }$ or $90^{\circ }$, the definition of orientation by euler angles suffers from the gimbal lock issue. You may need to apply a restraint to keep eulerTheta away from the singularities.

List of keywords (see also 4.2, 4.14, 4.15 and 4.17 for additional options):

• atoms — same definition as atoms (rmsd component)
• refPositions — same definition as refPositions (rmsd component)
• refPositionsFile — same definition as refPositionsFile (rmsd component)
• forceNoPBC — Use absolute rather than minimum-image distances? (see description)
  Default: no

This component accepts exactly the same options as orientation, and measures the rotation angle from the N axis to the X axis. This angle is expressed in degrees within the periodic range $[-180^{\circ }:180^{\circ }]$.

List of keywords (see also 4.2, 4.14, 4.15 and 4.17 for additional options):

• atoms — same definition as atoms (rmsd component)
• refPositions — same definition as refPositions (rmsd component)
• refPositionsFile — same definition as refPositionsFile (rmsd component)
• forceNoPBC — Use absolute rather than minimum-image distances? (see description)
  Default: no

The block alpha {...} defines a measure of the helical content of a segment of protein residues, as a tunable combination of an angle term between alpha carbon atoms, and a 1-4 hydrogen-bond term. To create a colvar that computes the helical content of a protein with several, non-contiguous helical segments, just define several alpha blocks inside a single colvar block, and give them linear combination coefficients that sum to 1 (see componentCoeff in section 4.17).

The $\alpha$-helical content across the $N+1$ residues $N_0$ to $N_0+N$ is calculated by the formula: