Programming Guide

Coding Standards

In order to make the GROMACS code more accessible to non-experts we are working on a set of rules for new code, that will successively be implemented for existing code as well.

• Indentation
• Block structure - how to write loops and if-statements
• Code constructs - argument order, return values
• Encapsulation using abstract data types
• Interfaces - the Application Programming Interface should say it all
• Comments in code - need we say more?
• Compilation - now and later

Library Structure

An important point of confusion for many would-be developers is the structure of the code. Which file resides in which directory and why? Why does code from the gmxlib refer to functions from mdlib? Why is there pure MD code in gmxlib? Many of these issues are due to history, decades of sloppy programming. But now we know better. Please have a look at the Library Structure page, and contribute to the discussion.

Projects

Here a number of projects are described which we would like volunteers to work on. Since these are new algorithms and extensions to the current code they have to be based on the latest CVS code. If you are interested in helping out, please send email to the gmx-developers mailing list and note your interest on the discussion page for this wiki entry or the special entry for each topic. It is a good idea to thoroughly discuss things with other developers before starting to code. An estimate of the amount of time for each project is given for an experienced C developer. To make the deal somewhat sweeter, some of these projects may be publishable if completed successfully, and one or more of the core developers will probably be interested to make that happen.

A number of "other projects" do not require C-programming, but they do require thorough GROMACS and/or other specialist knowledge.

Wish list

• Ability to supply a .ndx group of arbitrary size to pull_pbcatom0. When more than one atom is included in this group, each atom in the group is used in turn to create the image of pull_group0 and is assigned a "score" = sum of distances to other atoms in the group. The atom with the lowest "score" is used as pull_pbcatom0 for that integration step. This will allow smaller box sizes when pull_group0 represents something dynamic like a detergent micelle where even the distal carbon of the acyl-chain may spend a non-zero time on the surface of the semi-spherical micelle (far from the center). Since this may affect performance, one might also add new .mdp option pull_pbcatom_selection_frequency that controls how often (in integration steps) this test is performed. Note that even if the performance cost is 5-10%, this will be greatly overwhelmed by the time savings due to the ability to use a smaller unit cell.

• Alternative option that may have better performance: Addition of a new mdp option pull_pbcatom_two_iterations that, when selected, has the following behaviour. The first iteration is exactly the same as the current implementation. However, after each atom of the pull_group0 has been put in its proper image, the geometrical center of mass of that group is determined (no additional pbc here) and used as the central point for one more round of pbc_group0 atom placement. In cases where only a few atoms were placed in an undesired image during the first round, this procedure should correct that.

• Two new .mdp options: 1) "nstfrcout" that defines the number of steps between outputting selected forces to a special file = "traj.frc". and 2) "force_grps" that controls output selection to the new file = "traj.frc". Note: This is intended to have no effect on nstfout.

• The ability to make more than one .xtc file with different output selections nstxtcout, xtc_grps, xtc_precision, is desirable for example when one wants to save a small group of selected coordinates every step for processing and the entire coordinates once and a while for later system analysis.

• Seamless integration of AMBER force fields (http://chemistry.csulb.edu/ffamber/) into GROMACS.

• Output from all analysis tools also in an human readable style (something like a matrix) and not only in xpm format (http://lists.gromacs.org/pipermail/gmx-developers/2004-April/000857.html).

• Adding Canonical sampling through velocity rescaling (G. Bussi, D. Donadio, M. Parrinello J. Chem. Phys. 2007, 126 (1), Art. No. 014101)

• Improved speedup when fixing atoms via freezing and energy_group exclusions. Somehow, when atoms are fixed in place during a CHARMM simulation, the speedup is many times faster than it is in GROMACS. For a comment on how this might be done: http://lists.gromacs.org/pipermail/gmx-users/2004-July/011403.html

• Adding -nopbc option to g_dist and g_mindist.

• The ability to read in multiple .ppa files, for example to allow one pull-code implementation of an umbrella in absolute coordinates and one relative to a reference group, or one umbrella and one constraint and one afm, etc.

• Since the pull code is now integrated into the mdp file in gromacs 4, this request now has a different format, but the functionality requested remains the same.

• Adding "-dt" flag to gmxdump which reports the time step of a trajectory and exits immediately. Very useful!

Developer resources

• CVS HowTo With GROMACS-specific info.
• Brief CVS Guide by Doug Wright, last update August 29, 1995
• Compiling CVS GROMACS-specific tips on how to compile the sources once you have downloaded them from CVS
• More CVS Downloading the manual and the test set
• Development Tools like autoconf and automake
• Programmer's Guide Quick introduction to the layout of the simulation kernel
• gmx-developers thread on searching the code base with grep
• Bugzilla database for bug-tracking