Reducing Trajectory Storage Volume

This advice also pertains to cases where analysis tools crash (or are too slow) because you are running out of (real) memory.

First, consider whether you are producing more output than you need to store. Look at the .mdp file options for output frequency of positions (nstxout) and velocities (nstvout) in .trr files, whether you should be using .xtc files (nstxtcout) that store the positions efficiently at a user-selectable reduced precision, and whether you should be outputting only subsets of your system (xtc_grps) .

You don't want data every frame, because the frames are strongly correlated with their neighbours. If you're never going to do analysis on the solvent coordinates, there's no need to save them - and normally they greatly outnumber your solute of interest. So, if you only want position data for your solute for your later analysis, then outputting only that group to an .xtc file (xtc_grps) with frequency (nstxtcout) as high as you'd ever need will be a tiny fraction of the cost of a .trr file of the whole system with positions and velocities at every step. You can still have your .trr file for restarts (needed only for pre-4.0 GROMACS) - they're independent. Be aware that analysis types that require autocorrelation functions need data sampled much more frequently than the characteristic times of the system.

With GROMACS 3.x you normally only want a full frame of positions and velocities in your .trr file with frequency with which you might ever want to do an exact restart (and make sure your energy output frequency (nstenergy) is a suitable multiple so you also have energies at this time). This frequency is usually much smaller than the frequency with which you want output data for analysis.

With GROMACS 4.x the need for planning for positions, velocities and energies for restarts mentioned above is superseded by the checkpointing mechanism.

Note that you can also use trjconv and eneconv to reduce your output frequency, change file format and select groups after doing the simulation too, but most of these decisions are best made (correctly!) before the simulation.