This page was last updated on April 25th, 2019 at 09:12 pm

AutoDockFR home page

This site is under active development to replace the legacy AutoDockFR site.

AutoDockFR (or ADFR in short) is a protein-ligand docking program developed in the Sanner laboratory at Scripps Research under the AutoDock umbrella.

It uses:

  • the AutoDock4 scoring function implemented in a C++ library and wrapped for Python
  • its own genetic algorithm which can evolve and optimize multiple solutions simultaneously, can handle large numbers of rotatable bonds, and terminate searches upon convergence, i.e. potentially without exhausting its allocated number of energy function evaluations
  • a generic representation of molecular flexibility called the Flexibility Tree which enable the incorporation of a variety of molecular motions both in the ligand and receptor

While it supports the docking modes available in AutoDock4 and Vina, it was designed specifically, to include selective receptor flexibility and also supports covalent docking.Its custom Genetic Algorithm enables docking ligands with more rotatable bonds than AutoDock4. It is distributed as part of the ADFR software suite which provides additional  tools facilitating automated docking.

Ease of use

ADFR implements several features that help streamlines the docking procedure, and support the management and reproducibility of docking experiments through data-provenance. Self-documented files are used for storing: i) binding pocket representation used for docking (i.e. .trg target files), and ii) docking results (.dro Docking Results Object files). The meta-data stored in these files support not only supports reproducibility, but also reduces risks of operator errors, such as mixing up affinity maps.

Input

ADFR read ligands prepared for docking with AutoDock, i.e. in the PDBQT format and organize the reflect ligand flexibility based on rotatable bonds. A PDBQT file can be generated from a pdb file of a ligand using the prepare_ligand.

The receptor is specified as a target file, i.e. a single file describing the receptor. Target files can be calculated for a receptor in the PDBQT file format from the command using the agfr program, or using the graphical user interface agfrgui. A PDBQT file can be generated from a pdb file of a receptor using the prepare_receptor from the ADFR suite.

Usage

given a receptor and a ligand prepared for docking with AutoDock (i.e. in PDBQT format), a simple docking can be performed as follows:

Line 1 uses the native ligand xtallig.pdbqt of receptor rec.pdbqt to define a docking box covering the pocket and computing AutDock affinity maps that will be stored in the target.trg file,

Line 2 docks the ligand lig.pdbqt into this pocket.

additional use examples are available on the documentation page.

Implementation

ADFR s implemented in modern object-oriented programming languages and based on re-usable software components. Performance critical components are implemented in C and C++ (e.g. ADFRcc), while other are implemented in Python (ADFR, AutoSite, MolKit2, prody). More details on the software components is available on the ADFR suite implementation page.

License

ADFR is released under the LGPL v2 open source license.

What’s new?

ADFR v1.2 is available on the Download page as part of the ADFR software suite.

Key features:

  • Accuracy:  ADFR 1.2 achieves the same accuracy as AutoDock4 and AutoDock Vina and standard docking benchmark datasets, but performs better when making receptor side chain flexible.
  • Speed: Efficient C++ implementations of: 1) the scoring function, 2) the Flexibility Tree and 3) the Solis Wets local search method.
  • Ease of use:
    • Includes AutoGridFR, a program that facilitates the specification and calculation of affinity maps.
    • Includes an improved version of AutoSite (v1.1), a program for predicting binding pockets.
    • Support for complex docking scenarios, including (flexible receptor side chains, covalent docking, hydrated docking)
    • Streamlined executable exploiting multi-core architectures.
    • Streamlines output format (log file, poses file and docking result object file)
    • Support for data provenance and docking reproducibility through the use of target and docking result object files