Common errors when using |Gromacs|
==================================
The vast majority of error messages generated by |Gromacs| are descriptive,
informing the user where the exact error lies. Some errors that arise are noted
below, along with more details on what the issue is and how to solve it.
.. Moved my text that I duplicated to this page now, so that there is only one page for errors and
not two. Kept formatting from new pages, can be changed later.
.. _common-errors:
Common errors during usage
--------------------------
.. _out-of-memory:
Out of memory when allocating
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The program has attempted to assign memory to be used in the calculation, but is unable to due to insufficient memory.
Possible solutions are:
* reduce the scope of the number of atoms selected for analysis.
* reduce the length of trajectory file being processed.
* in some cases confusion between Ångström and nm may lead to users generating a
:ref:`pdb2gmx <gmx pdb2gmx>` water box that is |10to3| times larger than what they think it is (e.g. :ref:`gmx solvate`).
* use a computer with more memory.
* install more memory in the computer.
.. |10to3| replace:: 10\ :sup:`3`
The user should bear in mind that the cost in time and/or memory for various activities will
scale with the number of atoms/groups/residues *N* or the simulation length *T* as order N,
NlogN, or |Nsquared| (or maybe worse!) and the same for *T*, depending on the type of activity.
If it takes a long time, have a think about what you are doing, and the underlying algorithm
(see the `Reference manual`_, man page, or use the -h flag for the utility), and
see if there's something sensible you can do that has better scaling properties.
.. _Reference manual: `gmx-manual-parent-dir`_
.. |Nsquared| replace:: N\ :sup:`2`
.. _pdb2gmx-errors:
Errors in :ref:`pdb2gmx <gmx pdb2gmx>`
--------------------------------------
Residue 'XXX' not found in residue topology database
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This means that the force field you have selected while running :ref:`pdb2gmx <gmx pdb2gmx>` does not have an entry in
the :ref:`residue database<rtp>` for XXX. The :ref:`residue database<rtp>` entry is necessary both for stand-alone
molecules (e.g. formaldehyde) or a peptide (standard or non-standard). This entry defines the atom
types, connectivity, bonded and non-bonded interaction types for the residue and is necessary
to use :ref:`pdb2gmx <gmx pdb2gmx>` to build a :ref:`top` file. A :ref:`residue database<rtp>`
entry may be missing simply because the
database does not contain the residue at all, or because the name is different.
For new users, this error appears because they are running :ref:`pdb2gmx <gmx pdb2gmx>` on a
:ref:`PDB<pdb>` file they have, without consideration of the contents of the file. A :ref:`force field<gmx-force-field>`
is not magical, it can only deal with molecules or residues (building blocks) that are
provided in the :ref:`residue database<rtp>` or included otherwise.
If you want to use :ref:`pdb2gmx <gmx pdb2gmx>` to automatically generate your topology, you have
to ensure that the appropriate :ref:`rtp` entry is present within the desired :ref:`force field<gmx-force-field>` and
has the same name as the building block you are trying to use. If you call your
molecule "HIS," then :ref:`pdb2gmx <gmx pdb2gmx>` will try to build histidine, based on the
``[ HIS ]`` entry in the :ref:`rtp` file, so it will look for the exact atomic entries for histidine, no more no less.
If you want a :ref:`topology<top>` for an arbitrary molecule, you cannot use :ref:`pdb2gmx <gmx pdb2gmx>` (unless you
build the :ref:`rtp` entry yourself). You will have to build that entry by hand, or use another program
(such as :ref:`x2top<gmx x2top>` or one of the scripts contributed by users) to build the :ref:`top` file.
If there is not an entry for this residue in the database, then
the options for obtaining the force field parameters are:
* see if there is a different name being used for the residue
in the :ref:`residue database<rtp>` and rename as appropriate,
* parameterize the residue / molecule yourself (lots of work, even for an expert),
* find a :ref:`topology file<top>` for the molecule, convert it to an
:ref:`itp` file and include it in your :ref:`top` file,
* use another :ref:`force field<gmx-force-field>` which has parameters available for this,
* search the primary literature for publications for parameters for the
residue that are consistent with the force field that is being used.
Once you have determined the parameters and topology for your residue, see
:ref:`adding a residue to a force field <gmx_add_residue>` for instructions on how to proceed.
Long bonds and/or missing atoms
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
There are probably atoms missing earlier in the :ref:`pdb` file which makes :ref:`pdb2gmx <gmx pdb2gmx>` go crazy.
Check the screen output of :ref:`pdb2gmx <gmx pdb2gmx>`, as it will tell you which one is missing. Then add
the atoms in your :ref:`pdb` file, energy minimization will put them in the right place, or
fix the side chain with e.g. the `WHAT IF <https://swift.cmbi.umcn.nl/whatif/>`_ program.
Chain identifier 'X' was used in two non-sequential blocks
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This means that within the :ref:`coordinate file<gmx-structure-files>` fed to :ref:`pdb2gmx<gmx pdb2gmx>`, the X
chain has been split, possibly by the incorrect insertion of one molecule within another.
The solution is simple: move the inserted molecule to a location within the file so that it is not splitting another molecule.
This message may also mean that the same chain identifier has been used for two
separate chains. In that case, rename the second chain to a unique identifier.
.. _gmx-atom-missing:
WARNING: atom X is missing in residue XXX Y in the pdb file
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Related to the long bonds/missing atoms error above, this error is usually quite
obvious in its meaning. That is, :ref:`pdb2gmx<gmx pdb2gmx>` expects certain atoms within
the given residue, based on the entries in the force field :ref:`rtp` file.
There are several cases to which this error applies:
* Missing hydrogen atoms; the error message may be suggesting that an entry in the :ref:`hdb`
file is missing. More likely, the nomenclature of your hydrogen atoms simply does not match
what is expected by the :ref:`rtp` entry. In this case, use ``-ignh`` to
allow :ref:`pdb2gmx<gmx pdb2gmx>` to add the correct hydrogens for you,
or re-name the problematic atoms.
* A terminal residue (usually the N-terminus) is missing H atoms; this usually suggests
that the proper ``-ter`` option has not been supplied or chosen properly. In the case of
the :ref:`AMBER force fields<gmx-amber-ff>`, nomenclature is typically the problem.
N-terminal and C-terminal residues must be prefixed by N and C, respectively.
For example, an N-terminal alanine should not be listed in the :ref:`pdb` file
as ``ALA``, but rather ``NALA``, as specified in the
`ffamber <http://ffamber.cnsm.csulb.edu/ffamber.php>`_ instructions.
* Atoms are simply missing in the structure file provided to :ref:`pdb2gmx<gmx pdb2gmx>`;
look for ``REMARK 465`` and ``REMARK 470`` entries in the :ref:`pdb` file. These atoms
will have to be modeled in using external software. There is no
|Gromacs| tool to re-construct incomplete models.
Contrary to what the error message says, the use of the option ``-missing``
is almost always inappropriate. The ``-missing`` option should only be used to
generate specialized topologies for amino acid-like molecules to take
advantage of :ref:`rtp` entries. If you find yourself using ``-missing``
in order to generate a topology for a protein or nucleic acid,
don't; the topology produced is likely physically unrealistic.
Atom X in residue YYY not found in rtp entry
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If you are attempting to assemble a topology using :ref:`pdb2gmx <gmx pdb2gmx>`, the atom names
are expected to match those found in the :ref:`rtp` file that define the building
block(s) in your structure. In most cases, the problem arises from a naming mismatch,
so simply re-name the atoms in your :ref:`coordinate file <gmx-structure-files>` appropriately.
In other cases, you may be supplying a structure that has residues that do not conform
to the expectations of the :ref:`force field <gmx-force-field>`, in which case you should
investigate why such a difference is occurring and make a decision based on what you
find - use a different :ref:`force field <gmx-force-field>`, manually edit the structure, etc.
No force fields found (files with name 'forcefield.itp' in subdirectories ending on '.ff')
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This means your environment is not configured to use |Gromacs| properly, because
:ref:`pdb2gmx <gmx pdb2gmx>` cannot find its databases of forcefield information. This could
happen because a |Gromacs| installation was moved from one location to another.
Either follow the instructions about
:ref:`getting access to |Gromacs|`
or re-install |Gromacs| before doing so.
Errors in :ref:`grompp <gmx grompp>`
------------------------------------
Found a second defaults directive file
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is caused by the ``[defaults]`` directive appearing more than once in the :ref:`topology <top>` or
:ref:`force field <gmx-force-field>` files for the system - it can only appear once. A typical cause of
this is a second defaults being set in an included :ref:`topology <top>` file, :ref:`itp`, that
has been sourced from somewhere else. For specifications on how the topology files work,
see the `reference manual`_, Section 5.6.::
[ defaults ]
; nbfunc comb-rule gen-pairs fudgeLJ fudgeQQ
1 1 no 1.0 1.0
One solution is to simply comment out (or delete) the lines of code out in the file where it is included for the second time i.e.,::
;[ defaults ]
; nbfunc comb-rule gen-pairs fudgeLJ fudgeQQ
;1 1 no 1.0 1.0
A better approach to finding a solution is to re-think what you are doing. The ``[defaults]``
directive should only be appearing at the top of your :ref:`top` file
where you choose the :ref:`force field <gmx-force-field>`. If you are trying
to mix two :ref:`force fields <gmx-force-field>`, then you are asking for trouble.
If a molecule :ref:`itp` file tries to choose a force field, then whoever produced it is asking for trouble.
Invalid order for directive xxx
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The directives in the .top and .itp files have rules about the order in which they can
appear, and this error is seen when the order is violated. Consider the examples and
discussion in chapter 5 of the `reference manual`_, and/or from tutorial material.
The :ref:`include file mechanism <gmx-topo-include>` cannot be used to ``#include`` a
file in just any old location, because they contain directives and these have to be properly placed.
In particular, ``Invalid order for directive defaults`` is a result of defaults being
set in the :ref:`topology <top>` or :ref:`force field <gmx-force-field>` files in the inappropriate location;
the ``[defaults]`` section can only appear once and must be the first directive in
the :ref:`topology <top>`. The ``[defaults]`` directive is typically present in the :ref:`force field <gmx-force-field>`
file (forcefield.itp), and is added to the :ref:`topology <top>` when you ``#include`` this file in the system topology.
If the directive in question is ``[atomtypes]`` (which is the most common source of this error) or
any other bonded or nonbonded ``[*types]`` directive, typically the user is adding some
non-standard species (ligand, solvent, etc) that introduces new atom types or parameters
into the system. As indicated above, these new types and parameters must appear before
any ``[moleculetype]`` directive. The :ref:`force field <gmx-force-field>` has to be
fully constructed before any molecules can be defined.
Atom index n in position_restraints out of bounds
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
A common problem is placing position restraint files for multiple molecules out of order.
Recall that a position restraint :ref:`itp` file containing a ``[ position_restraints ]``
block can only belong to the ``[ moleculetype ]`` block that contains it. For example:
WRONG::
#include "topol_A.itp"
#include "topol_B.itp"
#include "ligand.itp"
#ifdef POSRES
#include "posre_A.itp"
#include "posre_B.itp"
#include "ligand_posre.itp"
#endif
RIGHT::
#include "topol_A.itp"
#ifdef POSRES
#include "posre_A.itp"
#endif
#include "topol_B.itp"
#ifdef POSRES
#include "posre_B.itp"
#endif
#include "ligand.itp"
#ifdef POSRES
#include "ligand_posre.itp"
#endif
Further, the atom index of each ``[position_restraint]`` must be relative to the
``[moleculetype]``, not relative to the system (because the parsing has not reached
``[molecules]`` yet, there is no such concept as "system"). So you cannot use the output
of a tool like :ref:`genrestr <gmx genrestr>` blindly (as ``genrestr -h`` warns).
System has non-zero total charge
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Notifies you that counter-ions may be required for the system to neutralize the charge or
there may be problems with the topology.
If the charge is not very close to an integer, then this indicates that there is a problem with the :ref:`topology <top>`.
If :ref:`pdb2gmx <gmx pdb2gmx>` has been used, then look at the right-hand
comment column of the atom listing, which lists
the cumulative charge. This should be an integer after every residue (and/or charge group where
applicable). This will assist in finding the residue where things start departing from
integer values. Also check the terminal capping groups that have been used.
If the charge is already close to an integer, then the difference is caused by
:ref:`rounding errors <gmx-floating-point>` and not a major problem.
Note for PME users: It is possible to use a uniform neutralizing background
charge in PME to compensate for a system with a net background charge.
This may however, especially for non-homogeneous systems, lead to unwanted artifacts, as
shown in \ :ref:`181 <refGroenhofEwaldArtefact>` (http://pubs.acs.org/doi/abs/10.1021/ct400626b).
Nevertheless, it is a standard practice to actually add counter-ions to make the system net neutral.
Incorrect number of parameters
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Look at the :ref:`topology <top>` file for the system. You've not given enough parameters for one of the
bonded definitions. Sometimes this also occurs if you've mangled the :ref:`Include File Mechanism <gmx-topo-include>`
or the topology file format (see: `reference manual`_ Chapter 5) when you edited the file.
Number of coordinates in coordinate file does not match topology
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is pointing out that, based on the information provided in the :ref:`topology <top>` file, :ref:`top`,
the total number of atoms or particles within the system does not match exactly with what
is provided within the :ref:`coordinate file <gmx-structure-files>`, often a :ref:`gro` or a :ref:`pdb`.
The most common reason for this is simply that the user has failed to update the topology file
after solvating or adding additional molecules to the system, or made a typographical error in
the number of one of the molecules within the system. Ensure that the end of the topology file
being used contains something like the following, that matches exactly with what is within the
coordinate file being used, in terms of both numbers and order of the molecules::
[ molecules ]
; Compound #mol
Protein 1
SOL 10189
NA+ 10
Fatal error: No such moleculetype XXX
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Each type of molecule in your ``[ molecules ]`` section of your :ref:`top` file must have a
corresponding ``[ moleculetype ]`` section defined previously, either in the :ref:`top` file or
an :ref:`included <gmx-topo-include>` :ref:`itp` file. See the `reference manual`_ section 5.6.1
for the syntax description. Your :ref:`top` file doesn't have such a definition for the
indicated molecule. Check the contents of the relevant files, how you have named your
molecules, and how you have tried to refer to them later. Pay attention to the status
of ``#ifdef`` and / or ``#include`` statements.
T-Coupling group XXX has fewer than 10% of the atoms
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
It is possible to specify separate :ref:`thermostats <gmx-thermostats>` (temperature coupling groups)
for every molecule type within a simulation. This is a particularly bad practice employed by
many new users to molecular dynamics simulations. Doing so is a bad idea, as you can
introduce errors and artifacts that are hard to predict. In some cases it is best to have all
molecules within a single group, using the default ``System`` group. If separate coupling groups are required to avoid
the ``hot-solvent, cold-solute`` problem, then ensure that they are of ``sufficient size`` and
combine molecule types that appear together within the simulation. For example, for
a protein in water with counter-ions, one would likely want to use ``Protein`` and ``Non-Protein``.
The cut-off length is longer than half the shortest box vector or longer than the smallest box diagonal element. Increase the box size or decrease rlist
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This error is generated in the cases as noted within the message. The dimensions of the box are such that an atom will
interact with itself (when using periodic boundary conditions), thus violating the minimum image convention.
Such an event is totally unrealistic and will introduce some serious artefacts. The solution is again what is
noted within the message, either increase the size of the simulation box so that it is at an absolute minimum
twice the cut-off length in all three dimensions (take care here if are using pressure coupling,
as the box dimensions will change over time and if they decrease even slightly, you will still be
violating the minimum image convention) or decrease the cut-off length (depending on the
:ref:`force field <gmx-force-field>` utilised, this may not be an option).
Atom index (1) in bonds out of bounds
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This kind of error looks like::
Fatal error:
[ file spc.itp, line 32 ]
Atom index (1) in bonds out of bounds (1-0).
This probably means that you have inserted topology
section "settles" in a part belonging to a different
molecule than you intended to. in that case move the
"settles" section to the right molecule.
This error is fairly self-explanatory. You should look at your :ref:`top` file and check that all
of the ``[molecules]`` sections contain all of the data pertaining to that molecule, and no
other data. That is, you cannot ``#include`` another molecule type (:ref:`itp` file) before
the previous ``[moleculetype]`` has ended. Consult the examples in chapter 5 of the `reference manual`_
for information on the required ordering of the different ``[sections]``. Pay attention to
the contents of any files you have :ref:`included <gmx-topo-include>` with ``#include`` directives.
This error can also arise if you are using a water model that is not enabled for use with your
chosen :ref:`force field <gmx-force-field>` by default. For example, if you are attempting to use
the SPC water model with an :ref:`AMBER force field <gmx-amber-ff>`, you will see this error.
The reason is that, in ``spc.itp``, there is no ``#ifdef`` statement defining atom types for any
of the :ref:`AMBER force fields <gmx-amber-ff>`. You can either add this section yourself, or use a different water model.
XXX non-matching atom names
^^^^^^^^^^^^^^^^^^^^^^^^^^^
This error usually indicates that the order of the :ref:`topology <top>` file does not match that
of the :ref:`coordinate file <gmx-structure-files>`. When running :ref:`grompp <gmx grompp>`, the
program reads through the :ref:`topology <top>`, mapping the supplied parameters to the atoms in
the :ref:`coordinate <gmx-structure-files>` file. If there is a mismatch, this error is generated.
To remedy the problem, make sure that the contents of your ``[ molecules ]`` directive
matches the exact order of the atoms in the coordinate file.
In a few cases, the error is harmless. Perhaps you are using a
:ref:`coordinate <gmx-structure-files>` file that has the old (pre-4.5) ion nomenclature.
In this case, allowing :ref:`grompp <gmx grompp>` to re-assign names is harmless.
For just about any other situation, when this error comes up, **it should not be ignored**.
Just because the ``-maxwarn`` option is available does not mean you should use it in the blind
hope of your simulation working. It will undoubtedly :ref:`blow up <blowing-up>`.
The sum of the two largest charge group radii (X) is larger than rlist - rvdw/rcoulomb
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This error warns that some combination of settings will result in poor energy conservation at the
longest cutoff, which occurs when charge groups move in or out of pair list range.
The error can have two sources:
* Your charge groups encompass too many atoms. Most charge groups should be less than 4 atoms or less.
* Your :ref:`mdp` settings are incompatible with the chosen algorithms. For switch or shift functions,
rlist must be larger than the longest cutoff (``rvdw`` or ``rcoulomb``) to provide buffer space for charge
groups that move beyond the neighbor searching radius. If set incorrectly, you may miss
interactions, contributing to poor energy conservation.
A similar error ("The sum of the two largest charge group radii (X) is
larger than rlist") can arise under two following circumstances:
* The charge groups are inappropriately large or rlist is set too low.
* Molecules are broken across periodic boundaries, which is not a problem in a periodic system.
In this case, the sum of the two largest charge groups will correspond to a value of twice
the box vector along which the molecule is broken.
Invalid line in coordinate file for atom X
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This error arises if the format of the :ref:`gro` file is broken in some way. The
most common explanation is that the second line in the :ref:`gro` file specifies an incorrect
number of atoms, causing :ref:`grompp <gmx grompp>` to continue searching for atoms but finding box vectors.
Errors in :ref:`mdrun <gmx mdrun>`
----------------------------------
Stepsize too small, or no change in energy. Converged to machine precision, but not to the requested F\ :sub:`max`
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This may not be an error as such. It is simply informing you that during the energy
minimization process mdrun reached the limit possible to minimize the structure with your
current parameters. It does not mean that the system has not been minimized fully, but in
some situations that may be the case. If the system has a significant amount of water present,
then an E\ :sub:`pot` of the order of -10\ :sup:`5` to -10\ :sup:`6` (in conjunction with an
F\ :sub:`max` between 10 and 1000 kJ mol\ :sup:`-1` nm\ :sup:`-1`) is typically a reasonable value for
starting most MD simulations from the resulting structure. The most important result is
likely the value of F\ :sub:`max`, as it describes the slope of the potential energy
surface, i.e. how far from an energy minimum your structure lies. Only for special
purposes, such as normal mode analysis type of calculations, it may be necessary to minimize further.
Further minimization may be achieved by using a different energy minimization method or by
making use of double precision-enabled |Gromacs|.
Energy minimization has stopped because the force on at least one atom is not finite
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This likely indicates that (at least) two atoms are too close in the input coordinates, and
the forces exerted on each other are greater in magnitude than can be expressed to
the extent of the precision of |Gromacs|, and therefore minimization cannot proceed. It
is sometimes possible to minimize systems that have infinite forces with the use
of soft-core potentials, which scale down the magnitude of Lennard-Jones interactions
with the use of the |Gromacs| free energy code. This approach is an accepted workflow for
equilibration of some coarse-grained systems such as Martini.
LINCS/SETTLE/SHAKE warnings
^^^^^^^^^^^^^^^^^^^^^^^^^^^
Sometimes, when running dynamics, :ref:`mdrun <gmx mdrun>` may suddenly stop (perhaps after writing
several :ref:`pdb` files) after a series of warnings about the constraint algorithms
(e.g. LINCS, SETTLE or SHAKE) are written to the :ref:`log` file. These algorithms often
used to constrain bond lengths and/or angles. When a system is :ref:`blowing up <blowing-up>`
(i.e. exploding due to diverging forces), the constraints are usually the first thing to
fail. This doesn't necessarily mean you need to troubleshoot the constraint algorithm.
Usually it is a sign of something more fundamentally wrong (physically unrealistic) with
your system. See also the advice here about :ref:`diagnosing unstable systems <system-diagnosis>`.
1-4 interaction not within cut-off
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Some of your atoms have moved so two atoms separated by three bonds are separated by more
than the cut-off distance. **This is BAD**. Most importantly, **do not increase your cut-off**!
This error actually indicates that the atoms have very large velocities, which usually means
that (part of) your molecule(s) is (are) :ref:`blowing up <blowing-up>`. If you are using
LINCS for constraints, you probably also already got a number of LINCS warnings. When using
SHAKE this will give rise to a SHAKE error, which halts your simulation before the
``1-4 not within cutoff`` error can appear.
There can be a number of reasons for the large velocities in your system. If it happens
at the beginning of the simulation, your system might be not equilibrated well enough
(e.g. it contains some bad contacts). Try a(nother) round of energy minimization to
fix this. Otherwise you might have a very high temperature, and/or a timestep that is too
large. Experiment with these parameters until the error stops occurring. If this doesn't help,
check the validity of the parameters in your :ref:`topology <top>`!
Simulation running but no output
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Not an error as such, but mdrun appears to be chewing up CPU time but nothing is being
written to the output files. There are a number of reasons why this may occur:
* Your simulation might simply be (very) :ref:`slow <gmx-performance>`, and since output is buffered, it can take quite
some time for output to appear in the respective files. If you are trying to fix some problems
and you want to get output as fast as possible, you can set the environment variable ``GMX_LOG_BUFFER`` to 0.
* Something might be going wrong in your simulation, causing e.g. not-a-numbers (NAN) to be
generated (these are the result of e.g. division by zero). Subsequent calculations
with NAN's will generate floating point exceptions which slow everything down by orders of
magnitude.
* You might have all ``nst*`` parameters (see your :ref:`mdp` file) set to 0, this will suppress most output.
* Your disk might be full. Eventually this will lead to :ref:`mdrun <gmx mdrun>` crashing, but
since output is buffered, it might take a while for mdrun to realize it can't write.
Can not do Conjugate Gradients with constraints
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This means you can't do energy minimization with the conjugate gradient
algorithm if your topology has constraints defined. Please check the
`reference manual`_.
Pressure scaling more than 1%
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This error tends to be generated when the simulation box begins to oscillate (due to large
pressures and / or small coupling constants), the system starts to resonate
and :ref:`then crashes <blowing-up>`.
This can mean that the system isn't equilibrated sufficiently before using pressure coupling.
Therefore, better / more equilibration may fix the issue.
It is recommended to observe the system trajectory prior and during the crash. This may
indicate if a particular part of the system / structure is the problem.
In some cases, if the system has been equilibrated sufficiently, this error can mean that the pressure
coupling constant, :mdp:`tau-p`, is too small (particularly when using the Berendsen weak coupling method).
Increasing that value will slow down the response to pressure changes and may stop the resonance from occurring.
You are also more likely to see this error if you use Parrinello-Rahman pressure coupling
on a system that is not yet equilibrated - start with the much more forgiving
Berendsen method first, then switch to other algorithms.
This error can also appear when using a timestep that is too large, e.g. 5 fs,
in the absence of constraints and / or virtual sites.
Range Checking error
^^^^^^^^^^^^^^^^^^^^
This usually means your simulation is :ref:`blowing up <blowing-up>`. Probably you need to do better
energy minimization and/or equilibration and/or topology design.
X particles communicated to PME node Y are more than a cell length out of the domain decomposition cell of their charge group
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is another way that :ref:`mdrun <gmx mdrun>` tells you your system is :ref:`blowing up <blowing-up>`.
If you have particles
that are flying across the system, you will get this fatal error. The message indicates that some
piece of your system is tearing apart (hence out of the "cell of their charge group"). Refer to
the :ref:`Blowing Up <blowing-up>` page for advice on how to fix this issue.
A charge group moved too far between two domain decomposition steps.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
See information above.
Software inconsistency error: Some interactions seem to be assigned multiple times
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
See information above
There is no domain decomposition for n ranks that is compatible with the given box and a minimum cell size of x nm
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This means you tried to run a parallel calculation, and when :ref:`mdrun <gmx mdrun>` tried to
partition your simulation cell into chunks, it couldn't. The minimum
cell size is controlled by the size of the largest charge group or bonded interaction and the
largest of ``rvdw``, ``rlist`` and ``rcoulomb``, some other effects of bond constraints,
and a safety margin. Thus it is not possible to run a small simulation with large numbers
of processors. So, if :ref:`grompp <gmx grompp>` warned you about a large charge group, pay
attention and reconsider its size. :ref:`mdrun <gmx mdrun>` prints a breakdown of how it
computed this minimum size in the :ref:`log` file, so you can perhaps find a cause there.
If you didn't think you were running a parallel calculation, be aware that from 4.5, |Gromacs|
uses thread-based parallelism by default. To prevent this, give :ref:`mdrun <gmx mdrun>`
the ``-ntmpi 1`` command line option. Otherwise, you might be using an MPI-enabled |Gromacs| and
not be aware of the fact.