Autodock Portlet
General information
The docking portlet based on and hooked to three workflows, for 3 different docking scenarios. The docking applications used by the workflows: Autodock, Autodock Vina, and Autogrid (http://autodock.scripps.edu/). Each docking type required different kind of input files, the sample files are linked in each input field description.
The workflows' job are configured to use
See the appendix (1) for the workflows.
UPDATE for version 1.5:
The version is adopted to the modified ASM API (which is not compatible backward!) with portal 3.5.8. The portlet developed and tested stable on portal 3.6.1. Introduced more verbose logs, and detailed messages.
UPDATE for version 1.7: 2014-05
Jmol was deprecated because Java security settings. JSmol javascript based visualization - introduced instead for client side. Small logo size protein images removed.
Usage - users
Top of the portlet, select the right docking type by clicking the button.
Upload the input files from your local machine, specify the best results number and number of docking/parallelisation, give a name for your task, and click the Run task button. Please note, the task name should not contain special characters like <space>, -, _.
You will see your task in the list, just below the input form. You have to check/refresh the page periodically, to see the progress of the task. Many task can be submitted in parallel, but it could slow down the progress. The typical docking scenario could be finished from 1 hour to few days.
When the Task Status change to Finished, see the results with clicking to Show results button.
Maintenance - admins
The docking portlet is generating many temporary files when the user is checking the result. It is necessary for visualisation. The server administrator should clean these directories manually. The cleaning does not require the portal/portlet restart, but make sure no one is using the docking portlet that time (or it will display error message to the log and to the user).
The molecules (*.pdb, *.pdbqt files) are stored the path below:
<PortletContextPath>/script/jmol/model/result/
The administrator should delete all files in the directory during the maintenance. The molecules named using UUID.
Temporary files stored for users (by default, configured via <PortletContextPath>/WEB-INF/autodock_config.xmlautodock_config.xml file):
/tmp/wf_<*>_dir/
These directories automatically cleaned eventually by the portlet. The files are used during the result post-processing.
The finished and unused - workflow instances (tasks) should deleted from the portlet interface.
Configuration - admins
This section describes the configuration process of the docking portlet. The configuration should complete once, before use, but after the deploy. The docking portlet (*.war) file contains all (Java) library dependency, but the workflows are not included.
(Please make sure:
1. Correct version of workflows previously imported to the WSPGRADE portal.
2. The portlet deployed in the Liferay/gUSE, see GUSE_ASM manual Deploy portlet into gUSE component chapter)
You can configure the following parameters in the autodock_config.xml file:
VerboseLevel
VerboseLevelLog
LogFile
TempDir
MaximumWU
MaximumVisualizeFiles
DeveloperId
AutodockVina
Autodock4
Autodock4noautogrid
Please follow the steps for the portlet configuration:
1. The workflows should be exported as application:
(Go to the portal Workflow/Concrete list, Export/Export As: Application)
Do the same for the 3 workflows: AutodockVina, PublicAutodock4Log, PublicAutodock4Log-noautogrid.
2. Get the DeveloperId from the list:
(Go to the portal Workflow/Import list, find the exported workflow row and see the Exported by column for the Developer ID eg.: 11305)
3. Edit the autodock_config.xml file, a sample can be found at the end of this documnetation.
vim <PortletContextPath>/WEB-INF/autodock_config.xml
4. Fill the DeveloperId tag (2.)
5. Edit the AutodockVina, Autodock4 and Autodock4noautogrid tags with the related Workflow names, it will be mapped to the existing workflow names with a startWith() method. Please provide the full length of the name as you can., but it does not mandatory to give the full name, but should be matching to only one workflow.
6. Please do the other changes at the same time.
7. Visit and view the docking portlet page. It should write: Portlet configured and initialized. for first time. It should not contain any message for the second time. Configuration is done.
8. If you modify later the autodock_config.xml, you should restart the WS-PGRADE portal to reload the new configuration.
The other parameters are optional to change:
VerboseLevel and VerboseLevelLog:
Verbosity of the messages from the portlet. Higher value means more messages.
VerboseLevel references the messages displayed to the user, in the page.
VerboseLevelLog the message goes to the log file.
LogFile:
Path of the log file.
TempDir:
Where the workflow results unpacked, and processed, molecules merged, etc.
MaximumWU:
Set the upper bound of the maximum number of workunits.
MaximumVisualizeFiles:
Set the upper bound of maximum number of docked molecules displayed on the results page.
Appendix - admins
(1) The WS-PGRADE portal 3.6.1 workflows are available from repository (http://shiwa-repo.cpc.wmin.ac.uk). The docking workflows called: PublicAutodock-Log, AutoDockVina and PublicAutoDock-Log-NoAutoGrid.
(2) The workflows are based on applications Autodock4 and AutodockVina, which are available for grid systems (http://edgi-repo.cpc.wmin.ac.uk/repository/). Tested stable on BOINC based version of: PublicAutodockVina112, PublicAutodock423.
(3) Other dependency of the PublicAutodock-Log workflow is the MGLtool AutoGrid application (http://mgltools.scripps.edu/downloads/instructions/linux) installed on the portal server (if it uses local submitter for Generator job). The path should be set it up before launching the portal
(eg: export PATH=$PATH:/usr/src/mgltools_x86_64Linux2_1.5.6/bin
. /usr/src/mgltools_x86_64Linux2_1.5.6/bin/mglenv.sh)
(4) Please start the portal's tomcat from local working directory, as guse user like:
$ cd ~/guse/apache-tomcat-6.0.37/bin
and after invoke: $ ./startup.sh
(5) You can find a sample xml file end of this documentation.
The legal task-statuses are: Init, Submitted, Running, Finished, in case of abnormality: Suspended, Error
The portlet checks the WorkflowIDs in every doView() action and if they are not configured already calls the doConfigure(). This method reads the IDs from the autodock_config.xml file. In the case of new version of workflows deployed (IDs changed), please restart the porlet to apply the modification. If you want to modify other parameters in the configuration file (like path, developerID) you need to restart the portlet.
For documentation see the page:http://sourceforge.net/projects/guse/files/
For GUSE_ASM manual: http://sourceforge.net/projects/guse/files/3.5.2/Documentation/ASM_Developer_Guide_v3.4.3.pdf
https://sourceforge.net/projects/asm-docking
Development
For general java asm development: see GUSE_ASM manual.
Portlet generally divided two part, front-end based on .jsp files which are
responsible for the user interface. The back-end part based on java classes.
The front-end: main page is docking.jsp, and publicautodockvina,jsp, publicautodockautogrid.jsp and publicautodockno.jsp. The docking.jsp includes one of the three files, depend on the choosen docking type. The docking.jsp responsible for the task's list and the results visualisation.
The publicautodockvina,jsp, publicautodockautogrid.jsp and publicautodockno.jsp files contains the submit form, validation and description.
The back-end is contains the ASM_DockingPortlet.java, Validate.java and MoleculeStore classes. The MoleculeStore handles the molecules/proteins processing, like splitting, merging, energy level and additional information querying. Merge could be the process to add ligand to the receptor, the splitting action is the ligand separation from the best file.
Validate class makes validation of the user parameters, like task name, range check, workflow type and name check. To check the valid workflow name, please set the types first.
The ASM_DockingPortlet is the entry point for the service, it is processing the requests, manage the user request actions like Submit, CheckStatus, ReSubmit, View, DownloadResults and Delete.
Sample autodock_config.xml file
<?xml version="1.0"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
<entry key="VerboseLevel">10</entry>
<entry key="VerboseLevelLog">10</entry>
<entry key="LogFile">../webapps/autodock-portlet.log</entry>
<entry key="TempDir">/tmp</entry>
<entry key="MaximumWU">10000</entry>
<entry key="MaximumVisualizeFiles">100</entry>
<entry key="DeveloperId">10805</entry>
<entry key="AutodockVina">AutoDock-Vina</entry>
<entry key="Autodock4">PublicAutoDock423-Log</entry>
<entry key="Autodock4noautogrid">PublicAutoDock423-NoAutoGrid-Log</entry>
</properties>
