2009 IWPLS’09 Pages 1–8 G-FLUXO: A workflow portal specialized in Computational BioChemistry E. Gutiérrez 1,∗ , A. Costantini 2 , J. López Cacheiro 1,∗ and A. Rodrı́guez 1∗ 1 CESGA. Santiago de Compostela. Spain. 2 Department of Chemistry, University of Perugia. Perugia, Italy. Associate Editor: Sandra Gesing and Jano van Hemert ABSTRACT Accelrys Materials Studio (http://accelrys.com/products/materials- The development of a Grid Portal Workflow aware and specialized studio) are commercial examples where an integration of in Computational BioChemistry is presented. specific scientific applications, execution on remote resources The P-GRADE Portal (GridSphere based) has been expanded with and centralized visualization have been implemented. However, specific portlet developments adding both support for Computational although a lot of work about applications integration (compatibility, BioChemistry applications and for different distributed resources is input/output format interchange, visualization...) have been done not described. too much effort have been done with the aim of an easy and efficient As a first prototype, GROMACS, a versatile package to perform execution of applications on the very different computational Molecular Dynamics simulations making use of the Newtonian platforms available today (from a multicore desktop to the equations of motion for systems with hundreds to millions of particles, heterogeneous and geographically distributed Grid infrastructure has been implemented and supported. Starting from that, specific passing through the cluster platform located on a lab or on a DAG workflows running GROMACS jobs, demanding very different supercomputer center). In this sense the G-Fluxo project is devoted computational resources on different local and Grid infrastructures to the development of a Grid Portal Workflow specialized in (i.e. EGEE, EELA, etc), have been developed and tested. The JMOL Computational BioChemistry where very different computational based portlet tighly integrated into the portal has been developed in platforms can be used without the need of very specific computer order to help the user in the visualization of both workflow progress skills. G-Fluxo is developed trying to use existing and widely and results. used technology in order to avoid very specific requirements for adding computational resources. The P-GRADE Portal (Kacsuk and Sipos (2005)) have been chosen as the starting point of this project so the most widely used Grid middleware is supported. 1 INTRODUCTION Integration of the cluster platform is based on the SSH protocol In the XX century advances in BioChemistry and Computer Science and the DRMAA standard (Tröger et al. (2007)) operative on enabled the development of new mathematical models able to most of the clusters running today. Finally a GridSphere based simulate the behavior of complex systems at molecular level, solution (http://www.gridsphere.org) such as P-GRADE Portal also allowing to understand chemical reactions as well as macroscopic lets the development of applications specific portlets fully JSR 168 properties of such systems. The huge number of atoms and compliant (http://www.jcp.org/en/jsr/detail?id=168). interactions involved in the calculations require an increasing The first application chosen to be implemented and supported into amount of computational resources not always available in local the G-Fluxo project is GROMACS (van der Spoel et al. (2005)). laboratories. GROMACS is a suite of applications for the simulation of complex Advances in Computational Science as well as improvements systems making use of a wide variety of Molecular Dynamics in CPU performance, new architecture designs and the increasing techniques optimized for different architectures. The variety of availability of computer power on Grid platforms, together with simulations needed to solve a particular problem makes GROMACS the adoption of new computational models and algorithms adapted suitable to exploit different types of computer platforms to solve to better exploit parallelism and memory management of such one single problem. Workflows where each part can be run on very resources, gave a strong contribution to the computing simulation different platforms is possible, requiring to send one part of those of complex systems. jobs to High Performance Computing (HPC) and the other part to Nowadays many Graphical User Interfaces for BioChemistry High Throughput Computing (HTC). programs have been developed. Special emphasis have been Computing Grid resources can be considered as a type of put on the coordinate and collaborative use of different HTC platform, on the other hand, local clusters with high speed applications in order to perform more complex simulations. interconnect networks are examples of HPC platforms. In the Schrödinger Software (http://www.schrodinger.com), Scienomics present paper a system to split workflows between grid and MAPS (http://www.scienomics.com/Products/maps/index.php) and local clusters in a transparent way for the user is described. Traditionally the management of such workflows is performed ∗ g-fluxo@listas.cesga.es manually, increasing notably the effort for the scientist to take 1 E. Gutiérrez et al advantage of both platforms. The use of the developed web portal OGCE GridPort Vine P- provides an abstraction of these systems showing a user friendly, GRADE and customizable, interface. Portal The Web Portal presented in this article makes use of both HPC GridSphere GridSphere GridSphere GridSphere Framework and HTC infrastructures showing, as an example, an interface for 2.1.5 2.0.2 3.1 2.2.10 job submission using GROMACS. GROMACS output visualization is done through a specific developed portlet based on Jmol no no yes yes GLite (http://www.jmol.org). support The GROMACS and Jmol packages have been implemented also in the COMPCHEM P-GRADE Portal (http://ui.grid.unipg.it:8080/ yes (through no no yes (through Workflow gridsphere/gridsphere) web portal in order to test the porting of the editor Java Web Start) Java Web Start) portlet applications developed at CESGA. The paper is organized as follows: in Section 2 the design Web portlets portlets portlets portlets and implementation of the portal built upon existing technologies interface and Adobe is illustrated (a comparison of existing portals is also included); Flex in Section 3 a case study consisting of a workflow based on GROMACS is presented. Our conclusions and future work are VO no or no or no or easy (but summarized in section 4. certificate difficult difficult difficult insecure) management 2 PORTAL DESIGN AND IMPLEMENTATION Table 1. Comparison of existing Portal technologies Nowadays the most common way of sending jobs is through the command line, both for grid and local cluster. An alternative to sending jobs through command line is to use a graphical interface. A web portal has been chosen as the graphical interface, because it P-GRADE Portal was the portal chosen as the base for our work offers wide compatibility, between different platforms, on the client because it is Open Source, it supports gLite 3.1, it has a graphical side. Furthermore each user can access to their data from different editor for workflows, and it is able to manage the certificates that places and machines, and they don’t need to be worried about new each user has for each Virtual Organization (VO) of the grid. software instalation or updates. In the following subsections, some existing technologies to send 2.1.2 Portal Technology Servlets are implementations of Java simulations through a web portal will be described. Then, with an code that run at the server-side as an answer to a web client request. existing web portal as a base, the modifications in that portal will The result of that execution is a web page. The concept of ”portlet” be described, both to send jobs to local cluster and to visualize is closely related to servlet concept. The main different is that while simulation job output. a servlet generates a whole web page a portlet generates only one part of a given page. Portlets are defined in the Sun specification 2.1 Existing Technologies JSR 168. A study of existing technologies has been done where four existing From the user’s point of view, a portlet is often represented web portals were compared, the results are presented in this Section. visually by a window embedded in a web page, with icons to get Afterwards, the characteristics of the portal chosen as the starting help, to maximize,. . . That is called “modes” and can be specified point for our developments will be commented with more detail. in a XML configuration file. Portlets can be grouped into tabs, this approach allows the creation of separated sections in a web page, 2.1.1 Portal Comparison There are several implementations providing more versatility in composition, to the administrator of a of web portals for sending jobs to grid. Four Open Source site and even to a user. web portals were tested to use as a base for our work: Vine Portlets are usually written in Java and JSP, with some XML (http://vinetoolkit.org), GridPort 4.0.1 (http://gridport.net/main), configuration files, and deployed, in a portlet container at the server, OGCE Release 2 (http://www.ogce.org), and P-GRADE Portal. All using a script language as Jackarta Ant. of these portals have a common execution platform: GridSphere. P-GRADE Portal is implemented using servlets and portlets. In As it is shown in the Table 2.1.1 the Vine is remarkable for its fact, P-GRADE Portal can be considered as a set of portlets which interface based on Adobe Flex (http://www.adobe.com/go/flex); for are distributed with its dependencies. Those portlets are mainly example, it has a comfortable file manager for grid. Additionally it focused on grid computing. There are portlets to send jobs and has an API for development. With that API it is possible to develop to manage certificates (using MyProxy), files in Store Elements applications for the web portal and also for applications running in (SE), and user accounts. They are deployed on a container called a desktop environment. Unfortunately Vine lacks both a standard GridSphere. The version of GridSphere used by P-GRADE Portal language and graphical environment for managing workflows. We is the 2.2.10 version, which it is not the last version and have also tested the GridPort 4.0.1 and OGCE Release 2. Both lack not good support. GridSphere, in turn, uses the Apache Tomcat of support for gLite (http://glite.web.cern.ch/glite), a middleware (http://tomcat.apache.org) as servlet container. widely used in grid platforms (EGEE, ELAA...) and it is currently That platform is adequate as a basic working grid environment the main grid middleware used at CESGA. and to add new portlets which expand the features of the web portal. 2 G-FLUXO Fig. 2. Local Cluster setup Fig. 1. Workflow application screenshot 2.2 Portal Development Taking the P-GRADE Portal version 2.7 source code as the starting point several add-ons have been developed: There is also a workflow editor, showed in the right-bottom side of • Integration of the CLUSTER platform figure 1. A group of tasks connected between them is called workflow. In 1. File management and communication through SSH a workflow, the output of one or more tasks are the input of one or protocol more tasks. In our case, those tasks are mainly jobs which are sent to 2. Distributed Resource Management Systems (DRMS) Job a grid or local cluster. The workflows can be depicted in a graphical submission and monitoring through DRMAA API based way. This is very useful because it make easy to choose where each program job is executed. It is possible that each job in the workflow needs different • Application specific portlet integration resources, for example one needs HTC resources and other need HPC resources, in this case, the job which needs HTC can be run in In the following subsections the way to add a local cluster to the grid and the other can be run in a local cluster. A user can indicate P-GRADE Portal, a new implementation for file management, the that in a workflow editor. Also, other job parameters can be changed local cluster execution via DRMAA, and visualization of job outputs in a workflow editor, as well as the relations between jobs. from GROMACS simulations through a Jmol specific developed The P-GRADE Portal has a graphical interface for workflows, portlet, will be explained. as shown in the Fig. 1. The workflow is designed in a workflow editor. The workflow editor is implemented in Java, 2.2.1 Merging Local Clusters and Grid The first step to add a and it run on the client machine. To do that, it uses new local cluster is the portal administrator define a new “Grid Java Web Start (http://java.sun.com/javase/technologies/desktop/ configuration” in P-GRADE Portal. The only condition in this form javawebstart) technology. is the name having the following syntax: Each node in the graph, represented by an orange square, corresponds to a job. Each job can be sent to a different grid, [host DN|host IP] CLUSTER-GRID being able to indicate explicitly the Computer Element (CE). The second step is the portal administrator has to create a SSH The workflows implementation is based on a DAG (Directed public key for the portal and give that key to each user. Acyclic Graph), and uses Condor (http://www.cs.wisc.edu/condor) Finally, each user must copy the SSH public key of the portal in for planning the shipment of those jobs. the file .ssh/authorized keys of their account at the local cluster. The This workflow application also facilitates the implementation and user should trust in the portal administrator because all their remote execution of parametric studies. In that case you may specify the accounts are exposed to the portal, but not to the other users of the input parameters of a job to be vary for the study. These parameters, portal. It is critical that the server where the portal resides must be including the intervals between the argument of each parameter very secure because it would be able to access to all remote user vary, and its increase or decrease, are specified in a node in the accounts. This procedure is represented in Fig. 2. graph (in one of the orange square that represents one job). For To copy files between local cluster and grid, and between local each of these arguments it will generate an job output. To collect cluster and server machine (“local” option in that editor), a new all of these outputs there is a ”collector”. It is also represented by an syntax has been specifically defined into the workflow editor: orange square that is configured as such because it connects the job output (all the exits, with each execution of the job). This method cluster:[host DN|host IP]:[path to file] allows to process all the outputs of the parametric study and obtain a single final output result of the workflow. For each job, the following folder is created in the local cluster: 3 E. Gutiérrez et al Fig. 3. Scripts and functions diagram implemented for file management and job submission in the local cluster platform [local cluster]:gfluxo/[workflow name] Fig. 4. Platform architecture /[job name] Each job is executed on different platforms: Grid or local cluster. The files needed for job execution are copied into this folder. The part of P-GRADE Portal to send jobs to Grid has not been So the files specified by the user in job ports have to be sent to altered. The script ‘wkf CLUSTER-GRID.sh’ has been created to this folder by default, or to another path if this is indicated in the send jobs to local cluster. workflow job definition. DRMAA is a standard library for the submission and control Each user can indicate, for each job, the necessary resources of jobs to one DRMS. Two programs, coded using DRMAA, for the local cluster execution. Those resources are specified by were developed: one to send jobs and another to monitor directives in the user script. This directives are parsed through a job status. Those programs were compiled, and executed, in script configured by the portal administrator. The administrator also the two GridEngine (GE) platforms present at CESGA: SVG has to configure a file to map each portal user to a local cluster user. (http://www.cesga.es/content/view/409/42/lang,en) and Finis Terrae One limitation of the workflow editor of P-GRADE Portal is (http://www.cesga.es/content/view/917/115/lang,en). that is not possible to link ports between jobs if one job goes to a Those two programs are permanently located in the portal. They local cluster, another goes to the grid and the shared files do not are sent to local cluster, using the same scripts commented in the pass through the portal server. In this case a little reference file previous subsection, when the user job is sent to execute. Then, they (semaphore), which is passed through the portal server, has to be are executed by a portal script, ’wkf CLUSTER-GRID.sh’, through used. SSH. To do that it is necessary to load the remote environment For the implementation, the files ‘wkf pre CLUSTER-GRID.sh’, variables needed and then to execute the DRMAA programs. ‘wkf post CLUSTER-GRID.sh’ and ‘ff CLUSTER-GRID.sh’ have The user can specify explicitly some requirements for local been created in P-GRADE Portal. A diagram with files and cluster execution of each job, resources as memory size, CPU functions modified or created can be seen in the Fig. 3. time,. . . Those resources are indicated in the user main script The input files are managed by P-GRADE Portal through the through directives with the following syntax. ‘wkf pre.sh’ script. That script call some functions located in more specific scripts. In the case of local cluster, those functions # gfluxo: [resource name] [resource value] are ‘local input copy CLUSTER-GRID’, for unlinked ports, and ‘channel input copy CLUSTER-GRID’, for linked ports. They are Those scripts are executed by the portal through Condor. Condor located in the file ‘wkf pre CLUSTER-GRID.sh’. is integrated in P-GRADE Portal and it is running in the portal The output files are managed by P-GRADE Portal through the server. When a user submits a job, this job is submitted to Condor ‘wkf post.sh’ script. The following function has been introduced and the scripts are executed using the files created by the workflow in the file ‘wkf post CLUSTER-GRID.sh’ to be called by editor and the files upload by the user as input. ‘wkf post.sh’: ‘local copy output CLUSTER-GRID’. An architecture diagram showing the pre/post file management ‘ff CLUSTER-GRID.sh’ has been created to separate more and job submission procedures is presented on Fig. 4. Additionally specific functions, more dependent on the technology to all the SSH based communication (SCP/SSHFS) channels linked implement the file management. Those functions are called with the specific tasks and the different functions developed in the ‘copy portal2cluster’, ‘copy cluster2portal’, ‘copy cluster2cluster’, ‘ff CLUSTER-GRID.sh’ file are also shown. ‘copy lfn2cluster’, ‘copy gsiftp2cluster’ and ‘copy cluster2gsiftp’. Currently, the only implementation is using LCG, for dealing with 2.2.2 Visualization GridSphere was used as a framework for the Grid platform, and SSH (‘scp’ and ‘sshfs’ commands), for local the development of a specific portlet for the visualization of the cluster. GROMACS output. For that, two code files, one in JSP and another 4 G-FLUXO in Java, and the corresponding configuration files were created. Also default in the P-GRADE Portal installation so it is needed to modify a Jakarta Ant (http://ant.apache.org) script was developed to deploy the P-GRADE Portal installation script in order to avoid it. the portlet in GridSphere. For the specialized visualization needed in The deployment is done with a Jakarta Ant script. To deploy the case of GROMACS output Jmol is used. All together is packaged the portlet, a portal administrator has to execute the following in one tar.gz file for easy distribution. sentences, in the directory ‘gridsphere-2.2.10/projects/portlet jmol Jmol is an open-source Java viewer for chemical structures. Inside v0.1’. Jmol the JmolApplet is a web browser applet that can be integrated into web pages and, in our case it has been integrated into a ant install GridSphere Portlet. It supports several input file formats, but does not support the GROMACS format. One popular molecule format The deployment script is in the file ‘build.xml’. That script is the Protein Data Bank PDB (http://www.wwpdb.org/docs.html). compiles the Java and JSP source code explained before. Also, it The command pdb2gmx, of the GROMACS package, is used for creates JAR files and copies all files to the ‘tomcat/webapps/jmol’ the conversion from GROMACS to Protein Data Bank (PDB) file directory. format. The Jmol library is contained in the file ‘jmol-11.4.4-full.tar.gz’. The use of portlets allows us to easily add new tabs and That file is unpackaged into ‘/webapps/gridsphere’ directory. This windows associated with simulation applications needed by the location is needed because it is the root of the P-GRADE Portal, user, or applications for file management in a grid, management seen by the user’s web browser. credentials... Once implemented a portlet for distribution, we create an Jakarta Ant script and everything is packaged in an archive. For installation, the user only has to copy the file, unzip or unpack, and deploy portlets in the container (the GridSphere, in our case) by 3 CASE STUDY running this script from Jakarta Ant to be created. The test application chosen as a case study has been GROMACS as The source code of the Jmol portlet can be downloaded from the it is stated before. The criteria followed for this election was: G-Fluxo web site (http://gfluxo.cesga.es/download/Gromacs/portlet jmol v0.1.tar.gz). • The application should demmand very different platforms The main class is ‘UiJmol’. That class is a child of the (Grid and local cluster) to be run efficiently depending on the ‘ActionPortlet’ class of GridSphere. The ‘UiJmol’ class call to input case. ‘uiJmol.jsp’, where the main layout of the web page is described. The portlet layout consists of a form, to choose the file to • The application must have a very active development comunity visualize, and of an applet, to render the molecule. so it has utilities and visualization tools related with the The form was developed using three boxlists (ListBoxBean application that can be used and integrated into the portal. class). The first boxlist is used to choose the workflow, the second to • it should desirable to have an Open Source license schema so choose the job in that workflow, and the third to choose the molecule there will not be any limitation of use. file (output of GROMACS). The portlet searches for the files only in the current user account of P-GRADE Portal; it can not access to In order to test the features of the P-GRADE Portal developed files in other user’s accounts. That Bash script get the name of the under the G-Fluxo project, several Gromacs workflows made up user account through the following Java method of a chain of three jobs has been run. Each job is run on different platforms (2 clusters, Finis Terrae and SVG, and the EGEE Grid event.getActionRequest().getRemoteUser() infrastructure (http://eu-egee.org) ). These workflows take advantadge of all the extra funcionalities Each list is obtained executing a Bash script. The Bash script is described previously: executed from Java code when the user clicks on one of the buttons over each listbox. • File Management between different platforms taking into To clear the listbox it is needed to use a global variable to account the dependecies coming from the workflow definition execute the sentence lbb workflows.clear() only when the • Job Submission using gLite middleware and the DRMAA ListWorkflows method was already called after the portlet was implementation included in the DRMS used in both local initiated. Each time a button is pressed, and one element is selected clusters (GridEngine, http://gridengine.sunsource.net). in the previous listbox, the next listboxes are cleared. • Output visualization including all the intermediate results The method to visualize created the HTML and JavaScript code coming from all the jobs that belong to the workflow. necessary to call the Jmol applet with the path of the file. The file has to be copied to a path visible from the web navigator. The path The developed workflows are based on one of the available chosen was GROMACS tutorials (http://md.chem.rug.nl/education/mdcourse/ index.html). The three jobs are: users/[user name]/[workflow name]/[job name] /[molecule file] 1. Vacuum: Energy minimization of the structure. For the distribution it is needed to unpackage the tar.gz file 2. Water: Energy minimization of the solvated system. in the ‘gridsphere-2.2.10/projects’ directory (relative to the root 3. PR: Relaxation of solvent and hydrogen atom positions: P-GRADE Portal directory). GridSphere directory is deleted by Position restrained Molecular Dynamics. 5 E. Gutiérrez et al These jobs must be executed following this order. The workflows nomenclature). Future work that involves a deeper change in P- used as test case are shown in Fig. 5 and 6. GRADE Portal will be needed in this sense. In the second case (Fig. 6) only the cluster platform is used althought it involves two different DRMS (Finis Terrae and SVG). In this case many link relations are established between the jobs, the output files of the first job became inputs files of the others. In this case (Fig. 7) it is only needed to specify the route of the file (output port) once being automatically asigned to the other job input port. cluster:ft.cesga.es:gfluxo/Gromacs_DEMO/Gromacs_vacuum/1LW9−EM−vacuum.gro Vacuum Port 3 cluster:ft.cesga.es:gfluxo/Gromacs_DEMO/Gromacs_vacuum/1LW9.top Vacuum Port 4 Vacuum Port 3 Vacuum Port 4 Vacuum Port 5 cluster:ft.cesga.es:gfluxo/Gromacs_DEMO/Gromacs_vacuum/minim.mdp Vacuum Port 5 Water Port 4 cluster:ft.cesga.es:gfluxo/Gromacs_DEMO/Gromacs_vacuum/posre.itp Vacuum Port 6 Vacuum Port 6 Water Port 3 cluster:svgd.cesga.es:gfluxo/Gromacs_DEMO/Gromacs_water/1LW9.top Fig. 5. Workflow definition involving a coordinated execution using Grid Water Port 3 (EGEE) and Cluster platforms cluster:svgd.cesga.es:gfluxo/Gromacs_DEMO/Gromacs_water/1LW9−water.gro Water Port 4 Fig. 7. File Management: Output files from one job became input files of other job. The file transfer need for every job execution is made automatically by the portal. In Fig. 8 three screenshots coming from the visualization Jmol porlet developed in the GFluxo project are shown. Using this portlet the PDB file carried out from the calculations can be easily visualized and there is no need to wait for the completion of the whole workflow. All the funcionalities available at the JmolApplet are also present in the portlet. Even more, Jmol additional functionalities like the RasMol/Chime scripting language and JavaScript support library can be integrated in the portlet letting the development of a very specific visualization portlet of great help in a specific simulation. Fig. 6. Workflow definition involving a coordinated execution using only 3.1 Integration in COMPCHEM Cluster platforms and visualization of the standard output In order to test the porting procedure of the GROMACS workflow and JMOL portlet packages developed at CESGA, In the first case (Fig. 5) the workflow is executed in the Finis both packages have been installed and tested in the P-GRADE Terrae cluster (1st job), the SVGD cluster (2nd job) and the EGEE Portal implemented by COMPCHEM VO. The COMPCHEM grid (3rd job). The relations between jobs in this case are made using VO (http://compchem.unipg.it) has been created by a group of one link (a semaphore) that defines the dependancy job chain. In molecular and material science laboratories committed to adapt their this case the user must set all the job ports adequately following computer codes to run in the EGEE production grid infrastructure. the syntax described previously in Section 2, taking into account More specifically the goal of designing and implementing grid where the job is executed so the portal could be aware of all the empowered versions of quantum reactive scattering codes as information needed for file transfers. This is needed to overcome the well as advanced visualization tools devoted to the study of limitation present in the P-GRADE Portal file transfer management the behavior of complex molecular systems Gervasi and Laganà system that does not allow direct file transfer between different (2004); Gervasi et al. (2006), is the task of the QDYN platforms (different Grid middlewares following P-GRADE Portal and ELAMS working groups of the European Cooperation in 6 G-FLUXO 4 CONCLUSIONS Web portals to create workflows and send jobs to different Grid infrastructures have been tested. Starting from that a workflow environment to send jobs to grid and local cluster based on P-GRADE Portal has been developed. As a case study in BioChemistry, a GROMACS workflow has been created and tested and a portlet to visualize molecules has been developed and integrated in the portal. The output files carried out from the calculations have been successfully visualized in the new portlet. The GROMACS workflows and JMOL portlet have been also successfully implemented in the COMPCHEM computational environment to test the porting of such applications. Through this paper it has been shown that the combination of a GridSphere based portal like P-GRADE Portal, that facilitates the use of very different computational platforms, jointly with a very specific portlet development (application aware portlet) can be flexible enough to develop specialized portals not only devoted to the Life Science Community. In this scenery, G-Fluxo is able to supply the Fig. 8. Workflow definition and output visualization computational needs that the e-science community could have as: • Orchestration of the use of many different Computational infrastructures • Specific support for applications • Scientific Simulations Modeling: Implementation of different methodologies Science and Technology (COST) Action D37, called ”Grid-Chem” (http://www.cost.esf.org/index.php?id=189&action number=D37). Additional effort is needed in the local cluster platform Thanks to a recent Short Term Scientific Mission (STSM) implementation in P-GRADE Portal. In fact, user access and sponsored by COST D37 Action, the GROMACS package and registration need to be implemented and tested. At present the SSH the JMOL applet have been implemented in the COMPCHEM Public Key Authentication implemented involves some security P-GRADE Portal and made available to the Molecular Science risks that could be mitigated using a user access and register Community supported by the VO. The workflow used as a case architecture as the one described in the RETELAB project (Mera study is one the already discussed jobs as shown in Fig. 8: et al. (2009)). It is evident that working with workflows implies applications • Water: Energy minimization of the solvated system. communication. Working on the development of common data formats and conversion routines are critical inside the different Thanks to mentioned STSM a set of detailed wiki pages about life sciences areas. For example tools like Open Babel (Guha how to install and run GROMACS in COMPCHEM P-GRADE et al. (2006)) should be integrated on the GFluxo portal. With a Portal have been written and made available to the COMPCHEM conversion tool, job links can be implemented not only as a file copy Community at the following link: [http://compchem.unipg.it/wiki]. action but as a format conversion action. Two GROMACS tutorials have been written. In the first tutorial Improvement in workflow support will be also performed and the configuration and run procedure for a single job are described aside from DAG workflow definitions, more complex workflow and summarized in the following steps: languages will be supported. A particular effort is focused to link P-GRADE Portal DAG Workflow submission with the Nova Bonita • Grid configuration, including certificates in MyProxy Server. Console (http://www.bonitasoft.com), a workflow open source • Preparing a job. solution that support the standard XPDL process definition language (http://www.wfmc.org/xpdl.html). • Script to GROMACS on CompChem VO, including how to download the GROMACS application and configure the environments variables. • Set up of the input and output files of a job. • Visualization of GROMACS output, using the Jmol portlet. ACKNOWLEDGMENTS We would like to thank all the people that have created P-GRADE In the second tutorial a workflow is described. A more complex Portal and released it under an open source license so everyone can GROMACS example, with three simulations linked between them, contribute to its development. This work is supported by Xunta is shown. de Galicia under the project G-Fluxo (07SIN001CT). The grid A set of video-tutorials, made with the gtk-recordMyDesktop infrastructures used are those of FORMIGA (07TIC01CT) and application in Ubuntu 9.04 are also available. EGEE-III (INFSO-RI-222667) projects. 7 E. Gutiérrez et al Acknowledgment is also due to the financial support by COST in Chemical Informatics. Journal of Chemical Information and Modeling, 46, 991– CMST Action D37 GRIDCHEM, through the activities of QDYN 998. Kacsuk, P. and Sipos, G. (2005). Multi-Grid, Multi-User Workflows in the P-GRADE and ELAMS working groups, and the EGEE III EU Project under Portal. Journal of Grid Computing, 3(3-4), 221–238. contract IST-2003-508833. Mera, D., Cotos, J. M., Varela, J., Cotelo, C., and López, J. I. (2009). An integration of Finally we would like to thank the support from the e-Science several technologies in the architecture denition and deployment of a geospatial grid Institute for the hosting of the IWPLS’09 workshop. web portal. In WORLDCOMP’09 - The 2009 World Congress in Computer Science, Computer Engineering, and Applied Computing. Tröger, P., Rajic, H., Haas, A., and Domagalski, P. (2007). Standardization of an api for distributed resource management systems. In Proceedings of the Seventh IEEE REFERENCES International Symposium on Cluster Computing and the Grid (CCGrid 2007), pages Gervasi, O. and Laganà, A. (2004). Simbex a portal for the a priori simulation of 619–626, Rio de Janeiro, Brazil. crossed beam experiments. Future Generation Computer Systems, 20, 703–715. van der Spoel, D., Lindahl, E., Hess, B., Groenhof, G., Mark, A. E., and Berendsen, H. Gervasi, O., Tasso, S., and Laganà, A. (2006). Immersive molecular virtual reality J. C. (2005). Gromacs: Fast, flexible and free. J. Comp. Chem., 26, 1701–1718. based on x3d and web services. Lecture notes in Computer Science, 3980, 212–221. Guha, R., Howard, M. T., Hutchison, G. R., Murray-Rust, P., Rzepa, H., Steinbeck, C., Wegner, J. K., and Willighagen, E. L. (2006). The Blue Obelisk–Interoperability 8