Subject: AutoDock 3: multiple ligands in one dpf?

From: Mikko Huhtala BKF <[email-masked]>
Date: Wed, 04 Dec 2002 01:20:15 +0200 (EET)

Has anyone tried using multiple 'move' commands in one AutoDock 3.0.5
input dpf file? Is there a working example of a multi-'move' dpf file?
Was the program ever meant to dock more than one ligand per run?

In the dpf I tried

[ ... the usual map etc. parameter lines... ] 

move lig1.pdbq
about    2.8527    3.4304    0.0000
ndihe 1
tran0 random
quat0 random
dihe0 random
ga_run 10
move lig2.pdbq
about    2.7408    3.3823    0.0397
ndihe 5
tran0 random
quat0 random
dihe0 random
ga_run 10

[ and so on ]

Docking many ligands this way has the performance advantage that the
map files are only read into memory once. The autodock3 program
accepts multiple 'move' commands in one dpf file and does dock
multiple ligands, but the output file (dlg) lists errors on
construction of the ligand internal non-bonded interactions for all
but the first ligand with rotatable bonds. If the same ligands are
docked one by one (one dpf file with one 'move' for each), there are
no errors.

It seems that the array that contains the non-bonded interacting atoms
(nbmatrix_binary in weedbond.cc source file) is not cleared between
the ligands. When a new ligand is read in, the computation of
non-bonded interactions fails because the table is corrupt and hence
ligand internal energies are wrong. The cluster analysis fails, too,
since the conformation set is also not cleared between ligands, but I
can do without cluster analysis.

Mikko Huhtala

---

From: Mikko Huhtala <[email-masked]>
Date: Wed, 4 Dec 2002 20:04:12 +0200

[email-masked] writes:
 > In the source there are some definitions of 'maximum number of ligands' or
 > something like this... Maybe, the authors wanted to make it for multiple
 > ligands, but then changed their mind...
 > Best,
 > Csaba

That's the impression I got from the source, too. I managed to modify
autodock3 to do multiple ligands, though. 

The culprits seem to be the arrays Nnbonds and nonbondlist, which are
reserved and initialized at the beginning of main() and then passed to
readPDBQ(), which passes the references to other functions. The arrays
are never re-initialized, even if new ligands are read in. There are
loops to initialize various arrays with zeroes in the beginning of
main(). I cut and pasted selected bits of this code into the 'case
DPF_MOVE' block, so the arrays are initialized every time a new ligand
is read in. I do not want to post the code as I am not sure if it
always produces correct results, but at least after very quick testing
the output seems to be consistent with single-'move' dpf runs. Another
mistake I had made before was not to give the 'torsdof' command for
every ligand that is read in and hence my torsional energies were
wrong.

Mikko Huhtala