ADL: Order of specifying affinity maps in .dpf

mswingle at mswingle at
Thu May 29 23:07:35 PDT 2008

I have encountered the following problem with autodock4:

When dockings (using the same random seeds) with flexible residues are done,
the results seem to depend upon the order in which atom affinity maps are
specified in the .dpf (but always keeping the order consistent with the
ligand_types list - so I don't think it's a map index issue). In some cases the
ligand conformations seem reasonable. In others the results are
clearly pathological. For example, a ligand with two aromatic ring systems connected by a 
flexible linker adopts a docked pose with the two ring systems stacked so close together 
that there are SEVERE steric clashes. This is associated with a very low (and clearly 
incorrect) ligand internal energy (~ -5 to -8 kcal/mol) in the .dlg. It seems like, in these 
cases, incorrect parameters are being used for some atoms, which distorts the energy 
landscape and drives the search toward a set of "pathological" conformations.

I first noticed these pathological cases when analyzing the results of a screen
of the NCI diversity set against my target (with 3 partially flexible
residues). My top scorers were contaminated by examples like the above (there
may be more subtle problems as well - I haven't sifted through everything yet).
The python utilities that came with MGLtools 1.5 were used to prepare those
ligands and make the .dpf files.

I decided to try to reproduce these weird conformation using one of the example 
receptors (1hvr) that came with the autodock distribution and one of the problem ligands
from the diversity set (150289). I set up a flexible docking of
150289 vs 1hvr with the guanidinium group of ARG8 allowed to rotate. I then
varied the order in which the ligand atom types and affinity maps were listed
in the .dpf (keeping them consistent with each other and also using the same
random seeds), ran the dockings, and got the results described above. I also
set up a similar series of dockings in which the receptor was treated as
completely rigid. In these cases I got exactly the same results each time, so
this problem apparently only crops up when flexible residues are specified.

So...either this is a rather serious bug or there is an undocumented (as far as
I can tell) requirement to specify the affinity maps in a particular order when
 using flexible residues. Has anyone else seen this behavior? Is there a particular order that 
must be adhered to when using flexible residues? If so, how can the python scripts be 
modified to ensure that order is used?



More information about the autodock mailing list