Developing Science Gateways at Various Levels of Granularity Using WS-PGRADE/gUSE - Science Gateways for Distributed Computing Infrastructures - page 109

AutoDock 4 is typically used to accurately model the molecular docking of a
single ligand to a single receptor. In this instance the process is composed of three
discrete stages. First, a low complexity sequential preprocessing stage de

nes a
random starting location in 3D space for both the ligand and receptor. This is
achieved using a tool within AutoDockTools (ADT) called AutoGrid. The second
stage can comprise many parallel jobs, each receiving a copy of the ligand and
receptor starting locations which form the input to a genetic algorithm. The algo-
rithm acts to randomly rotate/reposition the ligand and then determine likely
docking/binding sites based upon energy levels which are calculated from the
original starting locations. This process can be considered a parameter sweep,
where the varied input parameter is the initial random rotation of the ligand. Finally,
a single low complexity sequential post-processing stage can be used to identify the
most likely binding site by comparing energies from all jobs of the preceding stage.
Above described scenarios are supported in four different granularity level
implementations, using the WS-PGRADE/gUSE framework described next.

8.4 Granularity Level 1: Out of the Box

Granularity level 1 simply means installing the generic WS-PGRADE/gUSE
framework by a system administrator (including the connection and con guration

of the gateway to suitable distributed computing resources), and providing access
for potential end-users in the form of power-user accounts. After getting access to
the gateway, it is the task of the end-users to design and develop the necessary
workflow applications to run the docking scenarios.
WS-PGRADE/gUSE provides an intuitive and high-level user interface for this
scenario that supports complex workflow development without needing to deal with
low-level details, such as job submission mechanisms, job monitoring, file trans-

fers, etc. There is no need to write complex programs or to use command line
interfaces and understand the low-level details of various DCIs. On the other hand,
this scenario is still well above the expertise of most bioscientists and requires a
speci

c and rather long training period. As the target end-users are scientists, they
typically do not wish to be diverted from their research with such extra activities
and requirements.
The typical tasks needed to be carried out by the user in this scenario are illus-
trated on Fig. 8.1 . The graph editor is required to design the workflow graph, and
then the concrete workflow needs to be con gured, including the upload of exec-

utables, de nition of

ports, etc. Figure 8.1 shows a three-job AutoDock Vina workflow and its con

nition of command line parameters, selection of DCIs, de

gu-

ration, as a representative example. The first job of this workflow is the Generator

that runs only once and prepares the necessary input files for the simulation. The

second job is the actual docking simulation application, in this case AutoDock Vina.
This job runs as many times there are input ligands uploaded to the workflow. In
each run, a different ligand is docked on the target receptor molecule. The right-hand