Bug #619

Improper handling of force field directories by pdb2gmx

Added by J. Nathan about 10 years ago. Updated almost 10 years ago.

preprocessing (pdb2gmx,grompp)
Target version:
Affected version - extra info:
Affected version:


This bug is in version 4.5.3. When I copy the complete, intact oplsaa.ff directory from share/top to a working directory, and then modify charges in the working directory copy of oplsaa.ff/aminoacids.rtp, pdb2gmx generates a topology file based on the modified copy of oplsaa.ff/aminoacids.rtp no matter if I pick force field 1 (oplsaa.ff from my working directory) from the interactive menu or force field 15 (oplsaa.ff from the share/top directory). I have confirmed this behavior several times, and have also noted that if I delete the oplsaa.ff/aminoacids.rtp file from the working directory pdb2gmx crashes and says it can't find a .rtp file, and this happens even if I pick the share/top/oplsaa.ff force field.

It seems that pdb2gmx is giving precedence to the working directory copy of the force field and essentially ignoring the choice the user makes in the interactive menu. I did discover that if I rename the working directory copy of the force field directory to something different (oplsaa2.ff for instance) then pdb2gmx will let me select between the 2 copies of the force field and will yield the appropriate topology file (correct charges based on which aminoacids.rtp file was used).

Perhaps this isn't really a bug so much as a warning that one must name the force field directory in a working directory something different than the share/top version of the directory in order to be able to choose between them correctly.

Associated revisions

Revision 565cf5c4 (diff)
Added by Berk Hess almost 10 years ago

add pdb2gmx check for multiple .ff directories

pdb2gmx will currently always read from the first .ff directory
in the library directory search list. Therefore selecting a second
force field with the same directory name would still lead to reading
the files in the first directory. A verbose fatal error now occurs
when not choosing the first of multiple entries.
This fixes #619


#1 Updated by Berk Hess almost 10 years ago

  • Category changed from mdrun to preprocessing (pdb2gmx,grompp)
  • Status changed from New to Closed
  • Assignee changed from Erik Lindahl to Berk Hess
  • Target version changed from 4.5.1 to 4.5.4

This is a nasty bug, because it might lead to using unwanted parameters if you don't read
your output carefully. I have now added a fatal error in case you try to select a second
entry in the list with the same ff directory name:
gmx_fatal(FARGS,"Can only select the first of multiple force field entries with directory name '%s%s' in the list. If you want to use the next entry, run pdb2gmx in a different directory or rename or move the force field directory present in the current working directory.",


Also available in: Atom PDF