/usr/share/doc/gromacs/html/gmxfaq.html

<HTML>
<HEAD>
<TITLE>GROMACS FAQ</TITLE>
<LINK rel=stylesheet href="online/style.css" type="text/css">
<BODY text="#000000" bgcolor="#FFFFFF" link="#0000FF" vlink="#990000" alink="#FF0000">
<TABLE WIDTH="98%" NOBORDER >
<TR><TD WIDTH=400>
<TABLE WIDTH=400 NOBORDER>
<TD WIDTH=116>
<a href="http://www.gromacs.org/"><img SRC="images/gmxlogo_small.jpg"BORDER=0 height=133 width=116></a></td>
<td ALIGN=LEFT VALIGN=TOP WIDTH=280><br><h2>GROMACS<br>FAQ</h2><font size=-1><A HREF="online.html">Main Table of Contents</A></font><br><br></td>
</TABLE></TD><TD WIDTH="*" ALIGN=RIGHT VALIGN=BOTTOM><p><B>VERSION 4.5<br>
Thu 26 Aug 2010</B></td></tr></TABLE>
<HR>
 
<p>If you don't find the solution to your problem here, you could have a look in 
the online archives of our <a href="http://www.gromacs.org/mailing_lists/index.php">
mailing lists</a>, or subscribe yourself!

<p>There is also a special <a href="http://www.gromacs.org/developer/developer_faq.php">Developer FAQ</a> 
at www.gromacs.org with more advanced and/or technical topics (e.g. automake/autoconf) available under 
Developer info that you could use, and when all else fails it's
time to post your question to the mailing lists!</p>



<h3>Download & Installation</h3>

<ul>
<li><A HREF="#getgromacs">How can I get GROMACS and how much does it cost?</A>
<li><A HREF="#systemsupported">Is my system supported?</A>
<li><A HREF="#binaries">Can't you provide binaries for my system?</A>
<li><A HREF="#install">How do I compile and install the GROMACS package?</A>
<li><A HREF="#compiler">How do I select the compiler and/or flags to use?</A>
<li><A HREF="#fftw">The configuration script complains about FFTW - how
do I install it?</A>
<li><A HREF="#fftwlocation">I HAVE installed FFTW, but the configuration script
still says it can't find it!</A>
<li><A HREF="#MPI">How do I compile GROMACS for parallel runs?</A>
<li><A HREF="#noMPIwrapper">When I enable MPI support for parallel runs, GROMACS
looks for a special MPI wrapper script like 'mpicc', but we don't use that; is it possible to
 add the MPI library manually with -lmpi ?</A>
<li><A HREF="#nomotif">How do I turn off Motif?</A>
<li><A HREF="#ldpath">Everything compiles fine, but when I try to run a program
it complains about not finding libXXXX.so.</A>
<li><A HREF="#osx_zsh">I get an error from the configure script on Mac OS X!</A>
<li><A HREF="#noclue">It still won't compile and I haven't got a clue what the problem might be...</A>
<li><A HREF="#relativespeed">How fast is GROMACS compared to other programs?</A>
<li><A HREF="#speed">Is there any way I can make GROMACS run faster?</A>
<li><A HREF="#besthardware">What hardware do you recommend?</A>
<li><A HREF="#systemsize">How large systems can I simulate with GROMACS?</A>
<li><A HREF="#pdfgraphics">Why is the front page graphics in the PDF manual strange?</A>
</ul><br>

<h3>System preparation</h3>

<ul>
<li><A HREF="#PDB">OK, I've downloaded a PDB file with a structure I'd like
to simulate. What should I do?</A>
<li><A HREF="#multi">My protein has multiple subunits. Is that a problem?</A>
<li><A HREF="#convert">How do I convert my structure from a .gro, .tpr, or trajectory 
file to a .pdb file?</A> 
<li><A HREF="#scmis">The <TT>pdb2gmx</TT> program is complaining about long bonds and/or
missing atoms. What should I do?</A>
<li><A HREF="#osxcpp">grompp doesn't find the C preprocessor /lib/cpp on OS X!</A>
</ul><br>

<h3>Simulation</h3>

<ul>
<li><A HREF="#1-4cut">What does "1-4 (#,#) interaction not within cut-off" mean?</A>
<li><A HREF="#libnet">What does "Fatal error: Routine gmx_tx called in libnet.c" mean?</A>
<li><A HREF="#output">My simulation seems to be running, but shouldn't there be any output?</A>
<li><A HREF="#temp">Why do I get very strange temperatures in my simulation?</A>
<li><A HREF="#recover">Is there any smart way to continue a run that crashed?</A>
<li><A HREF="#largefiles">When my trajectory files reach 2GB I get strange error messages,
or they just disappear. Why?</A>
</ul><br>

<h3>Analysis</h3>

<ul>
<li><A HREF="#multPDB">How do I analyze a PDB file with multiple entries?</A>
<li><A HREF="#twostruc">Can I fit two structures which do not have the 
same number/sequence of atoms?</A> 
<li><A HREF="#group">I get tired of having to select the same index group 
over and over again. Is there a better way to do it?</A>
<li><A HREF="#diys">How do I perform an analysis that GROMACS doesn't have a program
for?</A>
</ul><br>

<h3>Other problems</h3>

<ul>
<li><A HREF="#none">My problem isn't mentioned above, and/or none of the solutions seem to work?</A>
</ul>
<br><br><br><br>

<hr>

<ul>
<li><A NAME="getgromacs">
<B>How can I get GROMACS and how much does it cost?</B><br><br>
You can download it immediately from this website, and it won't cost
you a penny! GROMACS is free software, licensed under the GNU General 
Public License. The details are available in the 
<A HREF="http://www.gnu.org/copyleft/gpl.html">license text</a>, but
in short you can modify and redistribute the code as long as your
version is licensed under the GPL too. <br><br>

<li><A NAME="systemsupported">
<B>Is my system supported?</B><br><br>
GROMACS is a recursive acronym for "GROMACS Runs On Most Of All Computer Systems" :-)<br>
Since we use GNU automatic configuration scripts you should in principle
be able to compile GROMACS on any UNIX dialect, probably including Mac OS X.
Contact us if you have any problems. At least Solaris, IRIX, Linux (both x86 and alpha), 
Tru64/Digital Unix, and AIX should be virtually problem-free. An ANSI C compiler
is sufficient to compile GROMACS, but we definitely recommend a good Fortran 77 
compiler too (performance-critical routines are available in fortran versions). You
won't need Fortran on Linux/x86 where we provide even faster assembly loops!<br><br>

<li><A NAME="binaries">
<B>Can't you provide binaries for my system?</B><br><br>
The problem is that we want the highest possible performance, and to achieve this
it is necessary to adapt compiler flags to your processor type. We also use special
mathematic libraries from several hardware manufacturers, and different versions
of MPI for parallel runs. This means we would have to provide about 10 different
sets of binaries for each processor on each operation system, and keep them updated
for each new release. Sorry, but that's simply not possible.<br>
However, for Linux running on x86 computers it doesn't matter which compiler
flags we use since it doesn't affect the assembly loops, and we can thus distribute
RPM packages of GROMACS. If you want to run in parallel you probably have to install our
versions of the LAM MPI packages to get the correct version, or compile GROMACS yourself.
<br><br>

<li><A NAME="install">
<B>How do I compile and install the GROMACS package?</B><br><br>
That's easy - we provide step-by-step instructions for you <A HREF="/installation/">here</A>.<br>
If you're impatient you could just unpack the distribution and try<br><br>
<table BORDER=0 CELLSPACING=0 CELLPADDING=8 COLS=3 WIDTH="100%" NOSAVE >
<tr NOSAVE>
<td WIDTH="2%" NOSAVE><font color="#000000"></font></td>
<td WIDTH="98%" BGCOLOR="#000066" NOSAVE><font color="#FFFFFF">
<tt>
 ./configure<br>
 make<br>
 make install</tt>
<td></td>
</tr>
</table>
<br>

The configure script will complain if it doesn't find FFTW, but you will be told what to do.<br><br>
This setup is new from version 3.0, so there might be some bugs we've missed, though. Don't
hesitate to post questions to the <a href="http://www.gromacs.org/mailing_lists/users.php>mailing lists</a> 
if you have problems.<br><br>

<li><A NAME="compiler">
<B>How do I select the compiler and/or flags to use?</B><br><br>
Select the compiler by setting the CC and/or F77 environment variables before running the
GROMACS configure script (MPICC for the MPI C compiler). You can also set the corresponding compiler flags with CFLAGS and
FFLAGS, and the linker flags with LDFLAGS. If you want to add a library at the link stage
you can add the -llib flags to the LIBS variable, and include directories can be 
added in the CPPFLAGS variable.<br><br>

<li><A NAME="fftw">
<B>The configuration script complains about FFTW - how
do I install it?</B><br><br>
FFTW uses the same type of automatic configuration scripts as
GROMACS, so it's easy to configure and compile. The default setup
places libraries under /usr/local, but you can change it with
--prefix. One important difference is that GROMACS normally
is compiled in single precision, while FFTW defaults to double precision.
Configure and install FFTW with the command:<br><br>
<table BORDER=0 CELLSPACING=0 CELLPADDING=8 COLS=3 WIDTH="100%" NOSAVE >
<tr NOSAVE>
<td WIDTH="2%" NOSAVE><font color="#000000"></font></td>

<td WIDTH="98%" BGCOLOR="#000066" NOSAVE><font color="#FFFFFF">
<tt> ./configure --enable-float<br>
 make<br>
 make install</TT>
<td></td>
</tr>
</table>
<br>
If you want to compile GROMACS with parallel MPI support you should
also add --enable-mpi to the FFTW configuration. Once the installation
is ready we recommend that you also install a double-precision version
of FFTW (nice to have) with:<br><br>
<table BORDER=0 CELLSPACING=0 CELLPADDING=8 COLS=3 WIDTH="100%" NOSAVE >
<tr NOSAVE>
<td WIDTH="2%" NOSAVE><font color="#000000"></font></td>

<td WIDTH="98%" BGCOLOR="#000066" NOSAVE><font color="#FFFFFF">
<tt> make distclean<br>
 ./configure<br>
 make<br>
make install</tt>
<td></td>
</tr>
</table>
<br>

That's it. Consult <A HREF="http://www.fftw.org">www.fftw.org</A> if you have any problems.<br><br>

<li><A NAME="fftwlocation">
<B>I HAVE installed FFTW, but the configuration script
still says it can't find it!</B><br><br>

OK. The problem is most probably that your compiler doesn't look for the
header files and/or libraries in the place where you installed them. It's easy to fix; you
can just tell the GROMACS configure script to add those directories to the search paths.
Specify the header file directory (e.g. /home/erik/fftw/include) as<br><br>
<table BORDER=0 CELLSPACING=0 CELLPADDING=8 COLS=3 WIDTH="100%" NOSAVE >
<tr NOSAVE>
<td WIDTH="2%" NOSAVE><font color="#000000"></font></td>

<td WIDTH="98%" BGCOLOR="#000066" NOSAVE><font color="#FFFFFF">
<tt> CPPFLAGS="-I/home/erik/fftw/include"</tt>
<td></td>
</tr>
</table>
<br>
and the location of the libraries (e.g. /home/erik/fftw/lib) in<br><br>
<table BORDER=0 CELLSPACING=0 CELLPADDING=8 COLS=3 WIDTH="100%" NOSAVE >
<tr NOSAVE>
<td WIDTH="2%" NOSAVE><font color="#000000"></font></td>

<td WIDTH="98%" BGCOLOR="#000066" NOSAVE><font color="#FFFFFF">
<tt> LDFLAGS="-L/home/erik/fftw/lib"</tt>
<td></td>
</tr>
</table>
<br>
and then run the GROMACS configuration script. Note that some compilers don't search
/usr/local by default, so you might have to specify these paths even if you installed
FFTW in the default place.<br><br>

<li><A NAME="MPI">
<B>How do I compile GROMACS for parallel runs?</B><br><br>
On most systems you only have to add the option --enable-mpi to the configure
script, and then compile GROMACS the normal way. For this to work you need to
have MPI communication libraries install, and some kind of wrapper script like
mpicc or mpcc to use when compiling MPI programs. MPI should always be present
on supercomputers, and if you are running on workstations we recommend LAM MPI,
<a href="http://www.lam-mpi.org">www.lam-mpi.org</a>. On Linux it's even simpler -
just install the RPM packages we provide!<br><br>

On most supercomputers you can only run MPI programs on dedicated nodes, so
in this case you probably want all the analysis programs compiled without MPI first.
Since you normally only need the mdrun program with MPI support you can type
"make mdrun; make install-mdrun" instead, but remember to type "make distclean"
if you have previously compiled GROMACS without MPI. It is also possible to put a suffix
on the MPI-version programs, or just start MPI runs when an environment variable
is set. Check the options to the configure script with "./configure --help".
<br><br>

<li><A NAME="noMPIwrapper">
<B>When I enable MPI support for parallel runs, GROMACS
looks for a special MPI wrapper script like 'mpicc', but we don't use that; is it possible to
 add the MPI library manually with -lmpi ?</B><br><br>
Sure - no problem, but it might not be entirely obvious if you are new to autoconf scripts.
Here's how to do it:<br><br>
To use the MPI library we need the header files (mpi.h) with definitions, and the MPI libraries
with the actual code (e.g. libmpi.a). If your system uses some special hardware it might
also be necessary to link with more libraries - ask your system administrator if you have
any problems. Start by location these headers and libraries on your system, and then add
them to your environment variables before running the configure script:
<br><br>
<table BORDER=0 CELLSPACING=0 CELLPADDING=8 COLS=3 WIDTH="100%" NOSAVE >
<tr NOSAVE>
<td WIDTH="2%" NOSAVE><font color="#000000"></font></td>
<td WIDTH="90%" BGCOLOR="#000066" NOSAVE><font color="#FFFFFF">
<tt>
setenv CPPFLAGS "-I/path/to/your/mpi/include"<br>
setenv LDFLAGS "-L/path/to/your/mpi/lib"<br>
setenv LIBS "-lmpi"<br>
setenv MPICC "cc"</tt>
<td></td>
</tr>
</table>
<br>
(This is valid for tcsh, for bash you should use export instead.) Note that these commands overwrite 
any previous assignments, so you must add
all parts you want (you can use $VARIABLE to add the previous value of an environment variable).
<br>
Now you should be able to run ./configure --enable-mpi !
<br><br>

<li><A NAME="nomotif">
<B>How do I turn off Motif?</b><br><br>
Just use the flag --without-motif-libraries (or headers).
If the configure script doesn't find both libraries and headers it will disable motif. This is useful when you have motif on the machine where you compile, but not on all machines you run on.<br><br>

<li><A NAME="ldpath">
<b>Everything compiles fine, but when I try to run a program
it complains about not finding libXXXX.so.</b><br><br>
GROMACS and/or the FFTW package can be compiled with shared libraries. In fact,
it's the default setup in the Linux RPMs. This means we save space by not linking all the
routines into each binary, but call the shared library at runtime. Of course, this requires that you can find the library at runtime. For the GROMACS distribution programs we hardcode the location of the GROMACS and FFTW libraries, but if you compile your own programs or move your libraries you must tell the system where to find them! 
Fortunately, this is quite easy to do. On Linux you can do it permanently for
all users if you are root, by adding the search path to the file /etc/ld.so.conf. Alternatively, you can add it to the LD_LIBRARY_PATH environment variable:
<br><br>
<table BORDER=0 CELLSPACING=0 CELLPADDING=8 COLS=3 WIDTH="100%" NOSAVE >
<tr NOSAVE>
<td WIDTH="2%" NOSAVE><font color="#000000"></font></td>

<td WIDTH="98%" BGCOLOR="#000066" NOSAVE><font color="#FFFFFF">
<TT>setenv LD_LIBRARY_PATH "$LD_LIBRARY_PATH:/opt/lib"</TT>
<td></td>
</tr>
</table>
<br>
(This is valid for tcsh, for bash you should use export instead.) Ask your
local sysadm how to add it to your login file so it's done automatically each
time you log on.
<br><br>


<li><A NAME="osx_zsh">
<b>I get an error from the configure script on Mac OS X!</B><br><br>
This is because OS X uses Z shell for /bin/sh. This will hopefully be
fixed in a future release of automake (it is not caused by Gromacs), but in the
meantime you can install bash (if you don't already have it) and 
use the command '/bin/bash ./configure'  (Your bash location might be different from /bin/bash).
<br><br>



<li><A NAME="noclue">
<B>It still won't compile and I haven't got a clue what the problem might be...</B><br><br>
Oops. Sorry, but those things happen :-) It's usually quite easy to fix. One possible
source of errors is the shared libraries we use to save space. You can try to disable
them with the --disable-shared flag to the configure script. You can also ask questions on the mailing
lists or contact us. BUT: Unless you attach copies of your configuration/make output and/or 
log files we can only guess what your problem might be!<br><br>


<li><A NAME="relativespeed">
<B>How fast is GROMACS compared to other programs?</B><br><br>
GROMACS is fast, VERY fast. In fact, on all benchmarks we've tested it's
3-10 times faster than any other program we've tried, many of which are
commercial. On x86 hardware GROMACS really excels due to the assembly loops.
Of course, speed isn't everything. There are cases where 
we don't support a certain algorithm that program X supports, and
vice versa. For instance, our assembly loops are only available in single precision.
In any case - show us a benchmark were some other program
is faster and we'll be happy to implement that algorithm. <br><br>


<li><A NAME="speed">
<B>Is there any way I can make GROMACS run faster?</B><br><br>
That depends on your setup. If you are using x86 processors you should definitely
make sure that you compile GROMACS with assemblt loops, and that your OS 
supports SSE instructions if you are using Pentium III/IV processors. If you
compiled GROMACS with assembly loops there will be a line in the logfile telling
you which loops we are using.<br>
On alpha hardware you might want to play around with enabling/disabling the
software invsqrt, and the inner loop vectorization. Modern alpha chips have a
fairly fast hardware sqrt, but they also seem to benefit even more from vectorizing the
innerloops and using the vectorized invsqrt provided in GROMACS.<br>
If you are using IBM hardware you should locate or download the MASS libraries
(mathematical accelerated subsystem). If you provide the location of this library
in the LDFLAGS environment variable GROMACS will automatically use fast vectorized
inner loops on IBM.<br>
On any system apart from Linux/x86 (where we use assembly innerloops) you should also
try to use a fortran compiler for better performance, and if you run Linux/alpha
you should use the Compaq compilers instead of gcc.<br><br>
You should always use single precision; there are very few cases where you
actually need double precision, and it's slower.<br><br>
Investigate the options <TT>-dummy</TT> and <TT>-heavyh</TT> to
<A HREF="/documentation/reference_3.1/online/pdb2gmx.html"><TT>pdb2gmx</TT></A> 
which control the constraining of hydrogen atoms and the mass of
unconstrained hydrogen atoms. This eliminates the highest freqency
motions in your system, enabling you to increase the timestep without
loss of accuracy to about 4 fs, or even up to 7 fs with negligible
loss of accuracy! (<I>J. Comput. Chem.</I> <B>20</B>,786).<br><br>
If your system has relatively slow disk-IO, and/or you write
frames and energies out very often, and/or you have a very large
system the performance might be limited by disk access. In that case,
you might consider writing fewer frames to your trajectories
(<TT>.xtc</TT> and especially <TT>.trr</TT> or <TT>.trj</TT>) and
energy file (<TT>.ene</TT> or <TT>.edr</TT>).<br><br>


<li><A NAME="besthardware">
<B>What hardware do you recommend?</B><br><br>
If cost is an issue, you can't beat dual Pentium boxes due to the assembly loops! 
Dual AMD machines should also be a nice option soon. Note that the Pentium 4 processors 
achieve a high clock frequency by using a longer pipeline, so a Pentium 4 at 1.7 GHz is 
about the same speed as a Pentium III at 1.2 GHz. Don't be fooled by the high clock!<br><br>


<li><A NAME="systemsize">
<B>How large systems can I simulate with GROMACS?</B><br><br>
It's only limited by your memory, and GROMACS is quite modest in its 
memory requirements. As an indictaion: a system of 12000 atoms takes 
about 10Mb of memory, and 6000 atoms about 5.5Mb (on a SGI O2), 
which comes down to just over 900 bytes memory use per atom in
your system (your mileage will vary). Due to the fact that we initially
developed GROMACS to run on our home-built parallel machine, with
only 8Mb of memory per processor, the code is quite well optimized for
memory use. To get an indication of scaling of GROMACS performance as
a function of system size, have a look at the
<A HREF="/benchmarks/scaling.php">scaling benchmark page</A>.<br><br>
Note that the .gro format only support atoms numbers up to 99999, so
it will loop once it reaches 100000 atoms. This is no problem in GROMACS
since we don't use the atom number from the .gro file.<br><br>


<li><A NAME="pdfgraphics">
<B>Why is the front page graphics in the PDF manual strange?</b><br><br>
This is a known problem with some versions of Acrobat reader on Linux. There
is nothing we can do about it, but in the cases we've tested the graphics
still prints fine on paper.<br><br>


<li><A NAME="PDB">
<B>OK, I've downloaded a PDB file with a structure I'd like
to simulate. What should I do?</B><br><br>
Look at the <A HREF="/documentation/reference_3.1/online/flow.html">flowchart</A> for a quick overview. 
Start where it says "eiwit.pdb" (this is somewhere at the top). 
More detailed info can be found in the 
<A HREF="/documentation/reference_3.1/online/getting_started.html">Getting Started</A>
section, you can probably start where it says "Ribonuclease S-Peptide".
<br><br>

<li><A NAME="multi">
<B>My protein has multiple subunits. Is that a problem?</B><br><br>
<TT>pdb2gmx</TT> can automatically process multimeric proteins,
but won't be able to make inter-subunit cystine bridges. A word of warning, though: 
the units will only be recognized as different chains if they
have different chain identifiers!<br><br>

<li><A NAME="convert">
<B>How do I convert my structure from a .gro, .tpr, or trajectory 
file to a .pdb file?</B><br><br>
Any <a href="/documentation/reference_3.1/online/files.html">generic structure</a> file,
for instance <TT>.gro</TT>, <TT>.pdb</TT> or <TT>.tpr</TT>, can be
converted to <TT>.pdb</TT> with 
<a href="/documentation/reference_3.1/online/editconf.html">editconf</a></TT>.  You can view a
<TT>.pdb</TT> file with several programs, for instance <TT>rasmol</TT>. Two generic
structure files can be fitted with 
<a href="/documentation/reference_3.1/online/g_confrms.html">g_confrms</a></TT>, the two
superimposed structures can be written to a <TT>.pdb</TT> file.  Any
<a href="/documentation/reference_3.1/online/files.html">generic trajectory</a> format can be
converted with <a href="/documentation/reference_3.1/online/trjconv.html"><TT>trjconv</TT></a>.
You can dump one frame with <TT>trjconv -dump</TT>, or write a
<TT>.pdb</TT> with multiple frames using <TT>trjconv -op -app</TT>.
If multiple structures in a <TT>.pdb</TT> are separated by
<TT>ENDMDL</TT> keywords, you should use <TT>rasmol -nmrpdb</TT> to
view them.<br><br>


<li><A NAME="scmis">
<B>The <TT>pdb2gmx</TT> program is complaining about long bonds and/or
missing atoms. What should I do?</B><br><br>
There are probably atoms missing earlier in the 
<A HREF="/documentation/reference_3.1/online/pdb.html"><TT>.pdb</TT></A> file
which makes <A HREF="/documentation/reference_3.1/online/pdb2gmx.html"><TT>pdb2gmx</TT></A>
go crazy. Check the screen output of <TT>pdb2gmx</TT>, as it
will tell you which one is missing. Then add the atoms in your pdb file,
energy minimization will put them in the right place, 
or fix the side chain with e.g. the 
<A HREF="http://swift.embl-heidelberg.de/whatif/">WhatIF program</A>.<br><br>

<li><A NAME="osxcpp">
<B>grompp doesn't find the C preprocessor /lib/cpp on OS X!</B><br><br>
Yep, that's right. OS X is a real Unix system, but Apple have been moving
some stuff around. Look for it in /usr/bin or possible a place like
/usr/libexec/gcc/darwin/ppc/2.95.2/cpp. Since a lot of programs assume
cpp to be present in /lib it is probably smart to make a link, but you
can also specify the location with the cpp keyword in your mdp files.
<br><br>

<li><A NAME="1-4cut">
<B>What does "1-4 (#,#) interaction not within cut-off" mean?</B><br><br>
Some of your atoms have moved so two atoms separated by three bonds are
separated by more than the cutoff distance. This is BAD.
Most important: <b>do not increase your cut-off!</b> This error
actually indicates that the atoms have very large velocities,
which usually means that (part of) your molecule(s) is (are)
exploding. 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. <br><br>
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 too large
timestep. Experiment with these parameters till the error stops
occurring. If this doesn't help, check your topology!<br><br>

<li><A NAME="libnet">
<B>What does "Fatal error: Routine gmx_tx called in libnet.c" mean?</B><br><br>
You probably made a parallel mdrun without typing make distclean. The error
messages tells you that the GROMACS library you are using doesn't support parallel runs.<br><br>

<li><A NAME="output">
<B>My simulation seems to be running, but shouldn't there be any output?</B><br><br>


<UL> 
<LI>Your simulation might simply be (very) 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 <TT>LOG_BUFS</TT> to 0 by using <TT>setenv LOG_BUFS 0</TT>,
this disables output buffering. Use <TT>unsetenv LOG_BUFS</TT> to turn
buffering on again.

<LI>Something might be going wrong in your simulation, causing
e.g. <tt>not-a-number</tt>s (<TT>NAN</TT>) to be generated (these are
the result of e.g. division by zero). Subsequent calculations with
<TT>NAN</TT>'s will generate floating point exceptions which slow
everything down by orders of magnitude. On a SGI system this will
usually result in a large percentage of CPU time being devoted to
'system' (check it with <TT>osview</TT>, or for a multi-processor
machine with <TT>top</TT> and <TT>osview</TT>).

<LI>You might have all 
<A HREF="/documentation/reference_3.1/online/mdp_opt.html#out"><TT>nst*</TT></A> parameters (see
your <A HREF="/documentation/reference_3.1/online/mdp_opt.html"><TT>.mdp</TT></A> file) set to 0,
this will suppress most output.

<LI>Your disk might be full. Eventually this will lead to
<TT>mdrun</TT> crashing, but since output is buffered, it might take a
while for <TT>mdrun</TT> to realize it can't write.
<li>You are runnning an executable compiled with MPI support (e.g. 
<a href="http://www.lam-mpi.org">LAM</a>) and did not start the LAM daemon
(lamboot). See LAM documentation.
</UL>
<br><br>

<li><A NAME="temp">
<b>Why do I get very strange temperatures in my simulation?</b><br><br>
You probably have very close contacts or a too large time
step. This causes inaccurate integration which will usually result in
a large positive temperature drift. Try some more energy minimization
to get rid of the close contacts, or if that still doesn't help, try a
short equilibration run with a small(er) time step.  <br><br>

<li><A NAME="recover">
<b>Is there any smart way to continue a run that crashed?</b><br><br>
Yes, if the reason for the crash didn't have anything to doe with
the algorithms, i.e. it was due to a system crash, a full disk, or
 a kill by the queuing system.  Otherwise you'll have to use 
<TT><a href="/documentation/reference_3.1/online/grompp.html">grompp</a></TT>
and change the options.

To really continue a simulation as if nothing had happened, you will
need coordinates and velocities in full precision (i.e. 
<TT><a href="/documentation/reference_3.1/online/trr.html">.trr</a></TT> format). 
<TT><a href="/documentation/reference_3.1/online/xtc.html">.xtc</a></TT> trajectories are in
reduced precision (only 3 decimal places after the decimal point) and
do not contain velocity information at all. Feed this trajectory and
your origional <TT><a href="/documentation/reference_3.1/online/tpr.html">.tpr</a></TT> file to
<TT><a href="/documentation/reference_3.1/online/tpbconv.html">tpbconv</a></TT> to obtain a new
<TT><a href="/documentation/reference_3.1/online/tpr.html">.tpr</a></TT> file, <EM>be sure</EM>
to specify the one-but-last frame from your 
<TT><a href="/documentation/reference_3.1/online/trr.html">.trr</a></TT> file, since the very
last frame is likely to be corrupted due to the crash. With the 
<TT><a href="/documentation/reference_3.1/online/tpr.html">.tpr</a></TT> file 
<TT><a href="/documentation/reference_3.1/online/tpbconv.html">tpbconv</a></TT> produces you can
restart your simulation.<br><br>

After the continuation run is finished, you will have your simulation
split up in separate files, which you will probably want to combine.
This can be done as follows (the same command works for xtc-files):<br><br>
<table BORDER=0 CELLSPACING=0 CELLPADDING=8 COLS=3 WIDTH="100%" NOSAVE >
<tr NOSAVE>
<td WIDTH="2%" NOSAVE><font color="#000000"></font></td>

<td WIDTH="98%" BGCOLOR="#000066" NOSAVE><font color="#FFFFFF">
<TT>trjcat -o whole.trr part1.trr part2.trr part3.trr</TT>
<td></td>
</tr>
</table>
<br>
The energy files can be concatenated in a similar manner:<br><br>
<table BORDER=0 CELLSPACING=0 CELLPADDING=8 COLS=3 WIDTH="100%" NOSAVE >
<tr NOSAVE>
<td WIDTH="2%" NOSAVE><font color="#000000"></font></td>
<td WIDTH="98%" BGCOLOR="#000066" NOSAVE><font color="#FFFFFF">
<TT>eneconv -o whole.edr part1.edr part2.edr part3.edr</TT>
<td></td>
</tr>
</table>
<br>
Since tpbconv sets the time in the continuation runs the files are
automatically sorted and overlapping frames removed. If you have a mix of
runs continued with tpbconv and grompp you might have to set the times yourself
(see the manual pages for details).
<br><br>

It is of course possible to start a simulation from the coordinates in
your <a href="/documentation/reference_3.1/online/xtc.html">xtc</a> file, but in that case new
velocities will have to be generated resulting in a 'kink' in the
simulation. To prevent this you should write coordinates and
velocities to a <TT><a href="/documentation/reference_3.1/online/trr.html">.trr</a></TT> file
during your simulations.  Do this by setting 
<A HREF=/documentation/reference_3.1/online/mdp_opt.html#out><TT>nstxout</TT></a> and 
<A HREF=/documentation/reference_3.1/online/mdp_opt.html#out><TT>nstvout</TT></a> in your 
<TT><a href="/documentation/reference_3.1/online/mdp.html">.mdp</a></TT> file. You don't need
these frames very often (every 10 ps or so), but remember that when
<TT><a href="/documentation/reference_3.1/online/mdrun.html">mdrun</a></TT> crashes, everything
calculated after the last frame in the <TT><a
href="/documentation/reference_3.1/online/trr.html">.trr</a></TT> file, will have to be
recalculated for a proper continuation.<br><br>

<li><A NAME="largefiles">
<b>When my trajectory files reach 2GB I get strange error messages,
or they just disappear. Why?</b><br><br>
This is a problem with the file system; when the system, or the C library,
or the compiler, or the NFS implementation (version 2) only uses 32 bits
for the file pointer you cannot use files larger than 2GB. On most modern
systems there are special compiler flags you can set to enable 64-bit file
pointers, but since the autoconf test for this doesn't work we have chosen
not to include any flags by default, since it can break other things. But
you can of course try anything if you add your own flags :-)
<br>
In any case, it is probably a good idea to try to keep your files
smaller than 2GB. You never know if you later might need to use it over
NFS version 2 or on some supercomputer system that doesn't support large
files yet.<br><br>


<li><A NAME="multPDB">
<b>How do I analyze a PDB file with multiple entries?</b><br><br>
Assuming your 
<A HREF="/documentation/reference_3.1/online/pdb.html"><TT>.pdb</TT></A> file is
called "<TT>eiwit.pdb</TT>", this is what you would do:<br><br>
<table BORDER=0 CELLSPACING=0 CELLPADDING=8 COLS=3 WIDTH="100%" NOSAVE >
<tr NOSAVE>
<td WIDTH="2%" NOSAVE><font color="#000000"></font></td>
<td WIDTH="98%" BGCOLOR="#000066" NOSAVE><font color="#FFFFFF">
<TT>pdb2gmx -f eiwit.pdb -reth -ter -n</TT>
<td></td>
</tr>
</table>
<br>

<TT>-reth</TT> lets 
<A HREF="/documentation/reference_3.1/online/pdb2gmx.html"><TT>pdb2gmx</TT></A> keep all
hydrogens which are present in your input file. It will also <B>not
add</B> any missing hydrogens, so your molecules should be
complete. <TT>-ter</TT> will cause <TT>pdb2gmx</TT> to ask for termini
types for which you must select 'none' for both C- and N-terminus.
<TT>-n</TT> tells <TT>pdb2gmx</TT> to generate a 
<A HREF="/documentation/reference_3.1/online/ndx.html"><TT>.ndx</TT></A> file with the atoms
reordered to the GROMACS standard. <TT>pdb2gmx</TT> now generates a
topology file (<A HREF="/documentation/reference_3.1/online/top.html"><TT>topol.top</TT></A>)
which exactly corresponds with the molecule(s) in your input file.
It also writes a coordinate file 
(<A HREF="/documentation/reference_3.1/online/gro.html"><TT>conf.gro</TT></A>).<br><br>

<P>
The next step is:
<br><br>
<table BORDER=0 CELLSPACING=0 CELLPADDING=8 COLS=3 WIDTH="100%" NOSAVE >
<tr NOSAVE>
<td WIDTH="2%" NOSAVE><font color="#000000"></font></td>
<td WIDTH="98%" BGCOLOR="#000066" NOSAVE><font color="#FFFFFF">
<tt>trjconv -f eiwit.pdb -o eiwit.xtc -n clean -timestep 1 -box 10 -center</tt>
<td></td>
</tr>
</table>
<br>

Yes, <TT>-f eiwit.pdb</TT> works because a <TT>.pdb</TT> is also a
<A HREF="/documentation/reference_3.1/online/files.html">trajectory format</A>
in GROMACS. <TT>-ox</TT> sets output to 
<A HREF="/documentation/reference_3.1/online/xtc.html"><TT>.xtc</TT></A>. <TT>-n clean</TT>
tells <A HREF="/documentation/reference_3.1/online/trjconv.html"><TT>trjconv</TT></A> to
use the <TT>clean.ndx</TT> generated by 
<A HREF="/documentation/reference_3.1/online/pdb2gmx.html"><TT>pdb2gmx</TT></A>, so the atom
ordering in the output (<TT>.xtc</TT>) file will be according to GROMACS
standards. <TT>-timestep 1</TT> sets the timestep between output frames
to one, so the structures from the <TT>.pdb</TT> file get numbered 
sequentially.
<TT>-ter</TT> causes <TT>TER</TT> markers in the <TT>.pdb</TT>
file to be seen as end-of-frame, default <TT>ENDMDL</TT> is used. If you
are not sure what is in your <TT>eiwit.pdb</TT>, <TT>TER</TT> is a good
guess, but you should check. If you have <TT>ENDMDL</TT> in stead of 
<TT>TER</TT>, omit the <TT>-ter</TT>. <TT>-box 10</TT> sets a default
box-size in the output <TT>.xtc</TT> trajectory (since no box is stored
in a <TT>.pdb</TT> file). The size is in nm and should be larger than
your molecule size. <TT>-center</TT> resets the geometrical center of
each of your structures to the center of the box (the one you specify
with <TT>-box</TT>). <TT>trjconv</TT> will generate a <TT>.xtc</TT>
trajectory file with all the coordinates from your <TT>eiwit.pdb</TT>.

<P>
A not very exiting but mandatory step is:<br><br>
<table BORDER=0 CELLSPACING=0 CELLPADDING=8 COLS=3 WIDTH="100%" NOSAVE >
<tr NOSAVE>
<td WIDTH="2%" NOSAVE><font color="#000000"></font></td>
<td WIDTH="98%" BGCOLOR="#000066" NOSAVE><font color="#FFFFFF">
<tt>
grompp -f grompp.mdp -c conf.gro -p topol.top</tt>
<td></td>
</tr>
</table>
<br>

This will generate a run input file 
(<A HREF="/documentation/reference_3.1/online/tpr.html"><TT>topol.tpr</TT></A>) from the 
<TT>topol.top</TT> and <TT>conf.gro</TT> you generated with 
<TT>pdb2gmx</TT>. 
A <A HREF="/documentation/reference_3.1/online/mdp.html">default <TT>grompp.mdp</TT></A> is 
available. You can probably use it 'as is', but you might want or need 
to modify some thing. In any case you are encouraged to 
<A HREF="/documentation/reference_3.1/online/mdp_opt.html">review the description</A> of the 
numerous options in the <TT>.mdp</TT> file.

<P>
Now, suppose you want to calculate all cross-rmsd values for all
structures. Enter:<br><br>
<table BORDER=0 CELLSPACING=0 CELLPADDING=8 COLS=3 WIDTH="100%" NOSAVE >
<tr NOSAVE>
<td WIDTH="2%" NOSAVE><font color="#000000"></font></td>
<td WIDTH="98%" BGCOLOR="#000066" NOSAVE><font color="#FFFFFF">
<tt>
g_rms -f eiwit.xtc -s topol.tpr -m</tt>
<td></td>
</tr>
</table>
<br>

<TT>-f eiwit.xtc</TT> and <TT>-s topol.tpr</TT> are self-explanatory.
<TT>-m</TT> tells <A HREF="/documentation/reference_3.1/online/g_rms.html"><TT>g_rms</TT></A>
to output an RMSD matrix in 
<A HREF="/documentation/reference_3.1/online/xpm.html"><TT>.xpm</TT></A> format, which can be
directly viewed with for example <TT>xv</TT>.

<P>
Of course there are many more analysis tools available. For example
<A HREF="/documentation/reference_3.1/online/ngmx.html"><TT>ngmx</TT></A> a trajectory viewer.
A list of all tools is available in the <A HREF="/documentation/reference_3.1/online.html">online
manual</A>.

<P>

<li><A NAME="twostruc">
<b>Can I fit two structures which do not have the 
same number/sequence of atoms?</b><br><br>
Yes, just type:<br><br>
<table BORDER=0 CELLSPACING=0 CELLPADDING=8 COLS=3 WIDTH="100%" NOSAVE >
<tr NOSAVE>
<td WIDTH="2%" NOSAVE><font color="#000000"></font></td>
<td WIDTH="98%" BGCOLOR="#000066" NOSAVE><font color="#FFFFFF">
<tt>g_confrms -f1 file1.xxx -f2 file2.xxx</tt>
<td></td>
</tr>
</table>
<br>
g_confrms accepts 
any <A HREF="/documentation/reference_3.1/online/files.html">generic structure format</A> which 
for instance can be <TT>.pdb</TT>, <TT>.gro</TT> or <TT>.tpr</TT>.
The program will ask you to select subgroups of both structures for the
(non mass weighted) LSQ fit. These subgroups must have the same number of atoms, however the two 
structures do <B>not</B> need to have the same number of atoms, i.e. two proteins
with the same number of residues but not the same type of residues can be
fitted on c-alpha's. You will be warned when the atomnames in the fit groups
do not match, but the program will go on.
Option <TT>-o</TT> gives a <TT>.gro</TT> file of the second structure fitted
one the first.
Option <TT>-op</TT> gives a <TT>.gro</TT> file of the two structures fitted
on top of each other.
</P>

<li><A NAME="group">
<b>I get tired of having to select the same index group 
over and over again. Is there a better way to do it?</b><br><br>
Use <A HREF="/documentation/reference_3.1/online/make_ndx.html"><TT>make_ndx</TT></A> to create 
an <A HREF="/documentation/reference_3.1/online/ndx.html"><TT>.ndx</TT></A> file with only one
group in it, this is done by typing '<TT>keep #</TT>' in <TT>make_ndx</TT>,
where '<TT>#</TT>' stands for the one group you want to have. 
Name the file <TT>index.ndx</TT> (which is the default
filename for index files) and specify the option <TT>-n</TT> with your
favorite GROMACS analysis tool. Now this single group will get selected 
automatically every time an index group is needed.
<P>

<li><A NAME="diys">
<b>How do I perform an analysis that GROMACS doesn't have a program
for?</b><br><br>
We've created a small well-commented template analysis program for you; look in
/usr/local/gromacs/share/template (or wherever you have gromacs installed.) 
This program reads a topology and trajectory and shows you how to access 
both coordinates and topology information like atom masses and charges.
There is also a proper GROMACS Makefile in this directory, so if you
copy the entire contents of the directory you should be able to type 
"make template" to build the program. It's easy to add more programs or
change the name by editing the Makefile.<br><br>

Now, if you wrote an analysis tool which, in your opinion, adds
something that is really missing in GROMACS, please post it on the
<a href="http://www.gromacs.org/mailing_lists/developers.php">developers 
mailing list</a> so that all other GROMACS users can also benefit from it!
<br><br>

<li><A NAME="none"> <b>My problem isn't mentioned above, and/or none
of the solutions seem to work?</b> <br><br> Check the installation
instructions carefully if your problem is related to the
configuration, building and installation of GROMACS.  Also try <A
HREF="/documentation/reference_3.1/online/getting_started.html">"Getting
Started"</A> where a guided tour of GROMACS is provided.  A quick
glance at the <A
HREF="/documentation/reference_3.1/online/flow.html">flowchart</A> will
tell you if you missed any essential steps in setting up a run.
Checking your <A
HREF="/documentation/reference_3.1/online/mdp.html"><TT>.mdp</TT></A>
file against our <A
HREF="/documentation/reference_3.1/online/mdp.html">sample
<TT>.mdp</TT> file</A> and the <A
HREF="/documentation/reference_3.1/online/mdp_opt.html">mdp options
list</A> might solve a number of potential problems. In general it
never hurts to read the <A
HREF="/documentation/reference_3.1/online.html">manual pages</A> of all
the GROMACS programs you (tried to) use. If all this still leaves you
with any unanswered questions, please post your question to the <a
href="/mailing_lists/users.php">gmx-users mailing list</a>!  <br><br>
</ul>


<hr>
<div ALIGN=RIGHT>
<font size="-1"><a href="http://www.gromacs.org">http://www.gromacs.org</a></font><br>
<font size="-1"><a href="mailto:gromacs@gromacs.org">gromacs@gromacs.org</a></font><br>
</div>

</BODY>
gromacs-data 4.5.5-2 / usr / share / doc / gromacs / html / gmxfaq.html
