Statistical Seismology Science Gateway - Science Gateways for Distributed Computing Infrastructures - page 167

As can be seen in Fig. 12.2 , SSF2 portlet directs the user to the SSF1 portlet as an
alternative to earthquake catalog upload. For this particular case, such an alternative
exists because an integrated earthquake catalog produced by an SSF1 workflow can
be directly used as the catalog input in an SSF2 workflow. Hence, the user may

rst
execute an SSF1 workflow and download the produced integrated catalog, and then
upload it as an input to an SSF2 workflow through the SSF2 portlet. Similar input/
output relations also exist among other SSF workflows. In such situations, i.e., when
there is a chance of using some other SSF portlet to produce an input data

file for the

current one, the user is noti ed with an option of running the other portlet rst.

Similarly, if such an output data file has already been produced by a portlet, then the

current portlet provides a button through which the existing data file can be used

as input directly. Such direct data flow mechanisms, which eliminate the need for the
users to

files, are implemented for
the following input/output relations among SSF workflows:

first download and then upload the related data

Integrated earthquake catalog output of SSF1 workflow can be used as catalog
input in SSF2 and SSF3 workflows.

￿

￿ Seismic sources output, containing parameter estimates, produced by SSF2 and

SSF3 workflows can be used as source input in SSF4 and SSF6 workflows.

￿ Annual probability files produced by SSF4 and SSF6 workflows can be used as

seismic hazard input in SSF7 workflow.

All the portlets include the same workflow execution interface (Fig. 12.2 ) that
provides a list of currently available DCIs in the gateway. The user may select the
DCI where the workflow will be submitted and start the execution. As the user
requests to run the workflow, the following operations are performed by ASM API
calls:

1. Corresponding workflow is imported from a local gateway repository.
2. The imported workflow is con

gured to use the input files uploaded by the user

or propagated from another portlet.
3. A parameter file is constructed using the input obtained via the portlet interface,

and the imported workflow is also con gured to use this le.

4. Imported workflow is con gured to run on the speci c DCI selected by the user.

5. It is submitted for execution.

After the workflow is successfully submitted, the workflow execution interface
is updated to indicate the current status of the submitted workflow. In addition,
buttons for refreshing the status indicator and aborting the workflow execution are
included in the interface.
After the execution of a workflow is completed, the raw output produced by the
workflow is downloaded from the corresponding DCI to the gateway server by
using appropriate ASM API calls. Since some workflows involve plotting graphs
and/or maps, external scripts are executed by the corresponding portlets for pro-
ducing such graphical outputs, using the raw outputs obtained. Finally, the portlet
interface is updated to include a new set of buttons for downloading and examining
the produced results.