HowTo:autodock
Contents
AutoDock
This is a short help file on the AutoDock suite of automated docking tools. This software allows the prediction of how small molecules bind to a receptor site of known structure. Since AutoDock is a rather sophisticated set of tools, this FAQ cannot replace the manual. It is rather meant as a starting point for using AutoDock, and to answer questions that are specific to our installation of the software.
FeaturesAutoDock actually consists of three separate programs:
AutoDock has been widely used and there are many examples of its successful application in the literature (see References). It is very fast, provides high quality predictions of ligand conformations, and good correlations between predicted inhibition constants and experimental ones. For a more complete list, see the official AutoDock homepage and click on "capabilities". Location of the program and setupThe present version of AutoDock is 4.2.5, which is the latest as of early 2014. Before you can access AutoDock, you need to read our license agreement and sign a statement that you have done so and will abide by it. See the last section for details. The AutoDock program is located in the directory /opt/autodock. To access it, you have to do a setup using the usepackage facility: use autodock305 Of course, this may be included in your setup files (probably .bash_profile), so you don't have to type them each time you run AutoDock. |
Running NWChem from a command lineThe usage of AutoDock is explained in the User's Manual which is available for download. Input files for Autodock are in a PDBQS format for the macromolecule and in a PDBQ format for the ligand molecule. Autodock comes with additional ultilities such asmol2topdqs and addsol to convert other formats (such as mol2). For details, please check the documentation. Assuming that we have input files ligand.pdbq and macro.pdbqs, we need to make a Grid Parameter file (gpf) and a Docking Parameter file (dpf) which can be created using themkgpf3 and mkdpf3 programs. Both are part of the Autodock distribution:
This produces input files for autogrid3 and autodock3, which are called macro.gpf andligand.macro.dpf. Both files might have to be edited manually before being used. The main part of an Autodock run then consists in calls to autogrid3 (for calculating a grid map) and autodock2 (for docking):
The -l option is used to specify log files, whereas the -p defines the input. Various other output files will be produced, someof which can be used to inspect the docking result graphically. Other utilities such as get-docked are supplied to perform the necessary conversions. The usage of Autodock is quite complex, and the outline here cannot replace the study of the manual. A postscript version of the latter may be found in /opt/autodock/doc. Note: AutoDock does not have parallel capabilities at this point. As a result you won't get a considerable speedup for an individual run on a parallel system as compared with, say, a desktop machine. However, a parallel machine allows the simultaneous execution of multiple instances of this software. Submitting (parallel) NAMD jobsOnly short test jobs of application software can be run interactively on HPCVL machines. Production jobs must be submitted via the scheduling software Grid Engine. For usage of this software, please consult our Grid Engine FAQ. In most cases, you will be running NAMD production jobs in parallel mode. This means that you need to specify a number of CPUs that should be reserved to run each independent NAMD thread. This is done in a Grid Engine submission script:
#!/bin/bash
#$ -S /bin/bash
#$ -q abaqus.q
#$ -l qname=abaqus.q
#$ -V
#$ -cwd
#$ -M {email address}
#$ -m be
#$ -o {screen output file}
#$ -e {screen error file}
#$ -pe shm.pe {number of threads}
namd2 +p$NSLOTS {namd configuration (input) file}
The items in the template that are enclosed in {} be replaced by the appropriate values. Lines that start with "#$" contain information for Grid Engine. The "#$ -V" line tells GE to inherit the shell setup from the calling shell, for instance the $PATH variable. It is important to remember that you need to set up NAMD by issuing the "use namd" command before submitting the above script. "#$ -cwd" tells the system to start from the current working directory. "#$ -M" lets the system know you email address, so it can notify you when the job starts and ends. The "#$ -o" and "#$ -e" lines are there to define files that capture output that would go to the screen in an interactive run, coming from the program and the system, repsectively. Finally, the "#$ -pe" line serves to define the number of CPUs to be reserved. The number you insert here will be reused through the environment variable $NSLOTS, so that you do not have to type it again in the namd2 command line. Note that the name of the configuration file that replaces "configuration file" in the script template, should have file extension .namd, just as in the interactive run. Once you have a proper script file (let's call it namd.sh) you can submit your production job by typing qsub namd.sh The Grid Engine will take care of the rest. |
LicensingNAMD is free for non-commercial use, but it is licensed. As with other licensed software, we ask our users to read through the license agreement that exists between the University of Illinois and HPCVL, and to sign a statement that they agree to abide by the terms of the license. The main issue in the NAMD case is that usage has to non-commercial. Once we have received the signed statement (FAX to (613) 533-2015 or scan/email to admin@hpcvl.org), we will enter the user to a Unix group namd which enables access to the software. More InformationNAMD requires practice to be used efficiently. We cannot explain it use in any detail here, but
|
