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 wanting to generate a :ref:`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 ` -------------------------------------- Residue 'XXX' not found in residue topology database ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This means that the force field you have selected while running :ref:`pdb2gmx ` does not have an entry in the :ref:`residue database` for XXX. The :ref:`residue database` 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 ` to build a :ref:`top` file. A :ref:`residue database` 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 ` on a :ref:`PDB` file they have, without consideration of the contents of the file. A :ref:`force field` is not magical, it can only deal with molecules or residues (building blocks) that are provided in the :ref:`residue database` or included otherwise. If you want to use :ref:`pdb2gmx ` to automatically generate your topology, you have to ensure that the appropriate :ref:`rtp` entry is present within the desired :ref:`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 ` 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` for an arbitrary molecule, you cannot use :ref:`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` 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` and rename as appropriate, * parameterize the residue / molecule yourself (lots of work, even for an expert), * find a :ref:`topology file` for the molecule, convert it to an :ref:`itp` file and include it in your :ref:`top` file, * use another :ref:`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. .. TODO Once you have determined the parameters and topology for your residue, see :ref:`adding a residue to a force field ` 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 ` go crazy. Check the screen output of :ref:`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 `_ program. Chain identifier 'X' was used in two non-sequential blocks ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This means that within the :ref:`coordinate file` fed to :ref:`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` 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` 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`, 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 `_ instructions. * Atoms are simply missing in the structure file provided to :ref:`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 `, 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 ` appropriately. In other cases, you may be supplying a structure that has residues that do not conform to the expectations of the `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 `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 ` 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| after installation ` or re-install |Gromacs| before doing so. Errors in :ref:`grompp ` ------------------------------------ Found a second defaults directive file ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is caused by the ``[defaults]`` directive appearing more than once in the :ref:`topology ` or :ref:`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 ` 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 `. If you are trying to mix two :ref:`force fields `, 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 ` 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 ` or :ref:`force field ` files in the inappropriate location; the ``[defaults]`` section can only appear once and must be the first directive in the :ref:`topology `. The ``[defaults]`` directive is typically present in the :ref:`force field ` file (forcefield.itp), and is added to the :ref:`topology ` 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 ` 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 ` 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 `. If :ref:`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 ` 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 `Hub, J. S., de Groot, B. L., Grubmüller, H. & Groenhof, G. Quantifying artifacts in Ewald simulations of inhomogeneous systems with a net charge. *J. Chem. Theory Comput.* **10**, 381–390 (2014) `. 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 ` 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 ` 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 ` 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 `, 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 ` :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 ` (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 ` 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 ` 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 ` by default. For example, if you are attempting to use the SPC water model with an :ref:`AMBER force field `, 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 `. 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 ` file does not match that of the :ref:`coordinate file `. When running :ref:`grompp `, the program reads through the :ref:`topology `, mapping the supplied parameters to the atoms in the :ref:`coordinate ` 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 some cases, the error is harmless. For example, when running simulations with the `MARTINI force field `_, the workflow relies on :ref:`grompp ` to apply the correct names, which are not previously assigned. Also, perhaps you are using a :ref:`coordinate ` file that has the old (pre-4.5) ion nomenclature. In this case, allowing :ref:`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 `. 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 ` to continue searching for atoms but finding box vectors. Errors in :ref:`mdrun ` ---------------------------------- Stepsize too small, or no change in energy. Converged to machine precision, but not to the requested precision ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is not an error as such. It is simply informing you that during the energy minimization process it 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|. LINCS/SETTLE/SHAKE warnings ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Sometimes, when running dynamics, :ref:`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 ` (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 `. 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 `. 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 `! 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 `, 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 ` 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 `. 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 `. 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 ` tells you your system is :ref:`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 ` 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 ` 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 ` warned you about a large charge group, pay attention and reconsider its size. :ref:`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 ` the ``-ntmpi 1`` command line option. Otherwise, you might be using an MPI-enabled |Gromacs| and not be aware of the fact.