A Collaborative Science Portal for High. Performance Computing

Transcription

1

2 A Collaborative Science Portal for High Performance Computing Master of Science, Systems Science Project Report submitted to Department of Computer Science, Louisiana State University Xiaoxi Xu April 09, 2007 Department of Computer Science, Louisiana State University, Baton Rouge, LA

3 Abstract Recently-developed Grid technology promises new capabilities of on-demand high performance computing (HPC) with distributed machines, with simulations coupled to largescale data devices across high speed networks. However, these technologies are still complex and hard to use for researchers from fields other than computer science. Portlet-based portal technology provides an approach for organizations or communities to integrate a large variety of resources, services, applications, and data for private, public, and commercial entities. Users can access a portal through a consistent and customizable web interface through any web browsers running on the Internet, without the need to download or install specialized software. This report describes an effort to leverage Grid computing with portal technology to deliver an collaborative high performance computing portal for researchers from diversified disciplines to access their integrated resources, services, and data. I designed and developed a number of Grid-enabled portlets to reduce the complexity of grid computing for end users and enable advanced application scenarios for several nationally funded projects at the Center for Computation & Technology at Louisiana State University, including En- LIGHTened Computing, SCOOP, UCoMS and LPFS. The capabilities of the portlets span from resource co-scheduling, querying and retrieving files from data archives to storm simulation monitoring. i

4 Abstract ii An exploration towards integrating different domains portals into a united institute portal is also addressed in this report. Four major problems that are unique to the integration portal and associated with the layout, portlet dependency, social needs and security are identified, described and resolved.

5 Acknowledgements I am grateful to my parents for everything they did for me to reach this point. I would like to thank my advisor Dr. Gabrielle Allen for giving me the opportunity to work on an array of CCT principal projects and for her guidance and suggestions along the way. I also sincerely thank my other committee members, Dr. Jianhua Chen and Dr. Kevin McCarter for accepting my invitation to be in my Master s defense committee and their fully support. Sweet thanks go to my beloved Chongjie, you are always there for me and keep me happy all the time. Special thanks go to Ian kelley for his prompt help and constant guidance on the portal development. Also, sincere thanks to Dr. Jon MacLaren for his all-along guidance, help and supervision on my work at CCT spanning from the EnLIGHTened project to the SCOOP Project. I am thankful to Oliver Wehrens, who friendly offered me direct help on a number of issues involving GridSphere. A work like this can only be done within a strong collaboration and I was lucky to work closely together with many talented people. I explicitly want to mention Archit Kulshrestha for his help on setting up the LDAP authentication module, Dayong Huang and Shree Balasubramanian for their underlying service my portlets were built upon. I want to acknowledge LSU and CCT for providing me with the entire infrastructure needed to implement this project. This work was supported by the SURA Coastal Ocean Observing and Prediction (SCOOP) iii

6 Acknowledgements iv Program, an initiative of the Southeastern Universities Research Association (SURA). Funding support for SCOOP has been provided by the Office of Naval Research, Award #N and by the National Oceanic and Atmospheric Administration s NOAA Ocean Service, Award #NA04NOS Additional support was provided by the Center for Computation & Technology at Louisiana State University.

7 Table of Contents 1 Introduction Contributions Outline Motivation 5 3 Grid Portal Development Gridsphere Framework Overview GridPortlets Portals & Portlets for CCT Projects Resource Co-scheduling Design Implementation SCOOP Archive Portlet & Filenaming Convention Portlet WaveWatch3 Monitoring Portlet UCoMS & Numerical Relativity LPFS An Integrated Portal for High Performance Computing Science Drive for An Integrated Portal Design Implementation Challenging Issues Solution v

8 TABLE OF CONTENTS vi 6 Conclusion 39

9 List of Figures 4.1 The architecture of the co-scheduling portlet showing interaction with underlying HARC services The co-scheduling portlet showing how to set up compute resource requirements including machine name, processors, memory etc The co-scheduling portlet showing how to set up network resource requirements The co-scheduling portlet showing a default query result, where a user can further specify different desired start time and end time for each reservation The co-scheduling portlet showing an aligned query result, where a user can further specify a united desired start time and end time for all reservations The co-scheduling portlet showing a reservation history records of a user The data portlet on the SCOOP portal showing the query result set of atmospheric forcing with type NAM-NCEP The data portlet on the SCOOP portal showing the meta information for a particular queried file including data class, data type, catalog ID etc The parser portlet on the SCOOP portal showing how to query file meta information using a logic file name The WW3 monitoring portlet showing a list of jobs being monitored for storm The WW3 monitoring portlet showing the detailed information of one job The ensemble selector portlet showing how to select ensembles based on options including track, model, forcing etc The advanced resource selection portlet showing how to select ensembles based on advanced options including job manager, wallclock, hotstart etc.. 24 vii

10 LIST OF FIGURES viii 4.14 The UCoMS archive portlet showing how to set up requirements including user name, host name, dates etc to query against the RLS archive The NumRel archive portlet showing how to set up query requirements and the query result set based on the requirements specified The LPFS portlet showing the storm information including alert level, location etc. and simulation status and outputs The architecture of the CCT integration portal showing interaction among portlets, portal services, and Grid Middleware The home page of CCT integrated portal showing the integration of HPC, SCOOP, UCoMS, LPFS portals into one united institute portal The screenshot showing the problematic tabbed-pane layout of the integration portal The screenshot showing the well-organized tabbed-pane layout of the integration portal The screenshot showing the duplicate credential portlets on the integration portal The screenshot showing the resulting layout of the integration portal after extracting shared portlets among component portals

11 Chapter 1 Introduction In the information era, the demand for high performance computing (HPC) is ever growing. In the academic world, more and more scientific fields have demonstrated the need for large-scale high performance computing, such as black hole simulations in physics, hurricane simulations in oceanography and coastal sciences, reservoir simulations in petroleum engineering, and gene data analysis in bioinformatics. In industry, speed-to-market is an essential component in getting, and staying, ahead of the competition. High performance computing can help solve highly complex problems, perform business critical analysis, or run computationally intensive workloads all faster and more efficiently than ever before. However, lowering the barrier of entry for access to HPC and mass data collections is still a technical and sociological challenge: the cost on purchasing and maintaining supercomputers and clusters is prohibitive; resources and services are complex and distributed; high performance computing environments change frequently; and more importantly, users often lack the specialized expertise to deal with the complex HPC environments. Recently-developed Grid technology (1) promises the capability of making large distributed resources such as large data archives, large computers, coupled by high speed 1

12 2 networks easily available for science. Grid technology makes use of the unused resources (CPU cycles and/or disk storage) of large numbers of disparate computers, including desktop computers, workstations, clusters, and supercomputers treated as a virtual cluster embedded in a distributed telecommunications infrastructure. Grid computing s focus on the ability to support computation across administrative domains enables resource virtualization and service (resource) sharing and lowers computation cost and complexity. Portlet-based portal technology provides an approach for organizations or communities to integrate a large variety of resources, services, applications, and tools for private, public, and commercial entities. Users can access those integrated systems through a consistent and customizable web interface through any web browsers running on the Internet, without the need to download or install specialized software or worry about setting up networks, firewalls, and port policies. Portal technology can provide a single entry for users to manage all applications and data and improve a user s work efficiency. For example, a black hole researcher can easily manage simulations and their results via a well-designed portlet without logging onto several different machines. In addition, a portals web interface carries advantages over traditional command tools. For example, web interface frees users from remembering a lot of commands and their argument formats, and it also can easily provide more active context information or hints than command-line tools for users to do desired actions. The Center for Computation & Technology at Louisiana State University is an interdisciplinary research center aiming to advance computational sciences, their enabling technologies, and many other disciplines. A number of research projects, such as SURA Coastal Ocean Observing and Prediction Program (SCOOP) (2), Ubiquitous Computing and Monitoring System for Discovery and Management of Energy Resources (UCoMS) (3), EnLIGHTened Computing (17), Numerical Relativity (NumRel) (4) and the Lake Pontchar-

13 1.1. Contributions 3 train Forecasting System (LPFS) (5), have a very high demand on HPC. This report describes an effort to leverage Grid computing with portal technology to deliver an collaborative high performance computing portal for researchers from diversified disciplines to access integrated resources, services, and data. In the rest of this chapter, I summarize my work on this effort and present the outline of this report. 1.1 Contributions As a graduate research assistant at CCT, I worked on several projects, including EnLIGHTened Computing, SCOOP, UCoMS, NumRel, LPFS. I designed and built Grid-enabled portlets and science portals for these projects to reduce the complexity of grid computing for end users and enable advanced application scenarios. The resource co-scheduling portlet I developed for the EnLIGHTened Computing project enables users to simultaneously co-allocate multiple computation and network resources for high performance computing applications. I extended the functionality of the SCOOP portal to allow users to better access ocean data and monitor their job runs. I generalized the data archive tool from the SCOOP portal and extended it to serve UCoMS and NumRel to provide researchers in these projects with a better tool to manage and analyze their mass simulation results. I also attempted to develop a real-time monitoring tool for the LPFS simulations which may help with planning flood gate closures of Lake Pontchartrain. The development and deployment of these portlets and portals also illustrate how portal technologies can complement Grid middleware to provide a community with an easy-to-use collaborative infrastructure that is tailored to their particular needs and has the ability to incrementally introduce and test new capabilities and services. Finally, I investigated how to integrate the portals and portlets described above into a

14 1.2. Outline 4 single collaborative science portal and employed portlet group settings to provide a rolebased access control for users from different fields and projects. The resulting work saved computational resources and human resources for CCT, eased the portal maintenance and extension for portal administrators, and relieve end users from managing multiple accounts on different portals. My work benefits greatly from a friendly and productive cooperation with other members in the SCOOP team and Portal group at the Center for Computation & Technology, without whom, this work would not be accomplished. 1.2 Outline The rest of this report is organized as follows. Chapter 2 discusses the motivation of this work on Grid portals. Chapter 3 introduces the Grid portal toolkits used in this work. Chapter 4 elaborates my effort in detail on each project at CCT and how they may help researchers in their daily work. Chapter 5 describes the motivation to integrate portals and how to set up role-based access control for users from different projects. Finally, Chapter 6 presents the conclusions of this work.

15 Chapter 2 Motivation Computational Science is now indispensable to the solution of complex problems in every sector, from traditional science and engineering domains to such key areas as national security, public health, and economic innovation. Advances in computing and connectivity make it possible to develop computational models and capture and analyze unprecedented amounts of experimental and observational data to address problems previously deemed intractable or beyond imagination. President s Information Technology Advisory Committee 2005 In 2003, Louisiana State University established the Center for Computation & Technology (CCT) with funding from the Governor s Information Technology Initiative. The goal for the CCT is to create an innovative and interdisciplinary research environment, exploring, investigating, and constructing systems integrating advanced computation, data, networks, and novel devices to solve complex large-scale problems in science, engineering, humanities, and business. Currently, the CCT has 32 faculty, 46 graduate students, and 25 undergraduate students from 12 departments, including Computer Science, Electrical Engineering, Mathematics, 5

16 6 Physics, Oceanography & Coastal Science, Petroleum Engineering, Music, Mechanical Engineering, Mass Communication, Finance, Accounting, Information Systems & Decision Sciences. As a result, collaborations within and beyond CCT have led to many interdisciplinary research projects. Those research projects share a common characteristic, demanding high performance computing and mass data storage. For example, in the Numerical Relativity project, solving Einstein s equations can take two weeks to run on hundreds of processors; in the UCoMS project, a reservoir simulation with a small number of factors also takes about two or three weeks to run on hundreds of processors; in the SCOOP project, the ocean sensors and coastal simulations generates about 1 Terabyte data each month. The CCT and LSU s Information Technology Services (ITS) have joined together and united their computing resources and human resources to create a premium high performance computing environment that advances interdisciplinary research as well as research within individual disciplines, and supports users with the best possible infrastructure to carry out their research. How to make best use of the computing resources to meet the demands of researchers is still a challenging problem from the perspective of technology. One possible approach is to employ Grid Computing technology which enables distributed heterogeneous resources to be aggregated to provide seamless computational capabilities to the user. An important feature of Grid technology is to allow for sharing of computing resources, expertise, software, and data across multiple institutions which is critical for the multi-institution collaborative projects, such as SCOOP and UCoMS. The CCT has already started to build the necessary Grid infrastructures for those projects by integrating multiple Grid middleware packages to provide a holistic approach to collaborative problem solving. As mentioned above, many research projects in the CCT are interdisciplinary. As a result, many researchers from other fields may not have a strong computer science back-

17 7 ground. Also, although Grid technologies have evolved over time, they are still complex and difficult to use. Grid portals have come to be recognized as a useful tool to enable the work of researchers and engineers without burdening them with the low-level details of underlying technologies. Web portal technology provides an easy way to integrate applications and content and provides groups of users with a single entry point to interact with their applications, data, colleagues and services, all the while maintaining a uniform interface; Also, web portal technology provides groups of users with an easy-to-use and customized visual interface. Moreover, it is a way to introduce new technologies. This work explores how portal technologies can complement Grid middleware to provide researchers from fields other than Computer Science with an easy-to-use collaborative infrastructure that is tailored to their particular needs and has the ability to incrementally introduce and test new capabilities and services. Work in developing Grid portals for several projects at CCT will be described in detail in chapter 4.

18 Chapter 3 Grid Portal Development Grid portal toolkits are increasingly being adopted as a means to speed application development since they can provide much of the high-level functionality that is needed to manage the multi-institutional and multi-virtual organization issues that arise when designing and maintaining a production portal. There are a number of portal frameworks including IBM WebSphere, BEA WebLogic, uportal and GridSphere (6), and Grid portal toolkits including GridPortlets (7), GridPort (8), OGCE (9), and Java COG (10). A comparative analysis of GridPortlets and OGCE (11) by a former portal developer at CCT in his paper Grid Portal Solutions: A Comparison of GridPortlets and OGCE, gave us an insight into both the advantages and disadvantages of GridPortlets and OGCE. Being advised that the use of a mature portal framework and a well-designed Grid portal toolkit was necessary to be able to focus on the business logic of the current use-case scenarios, and taking into account that most of ongoing projects are at the early stage, still evolving and yet mature, we regard that GridSphere s highly straightforward extensibility fits our needs. Also, GridPorlets can abstract the details of underlying Grid technologies and offer a uniform high-level service API enabling developers to easily create customizable Grid portal applications which fit 8

19 3.1. Gridsphere Framework Overview 9 our needs precisely. Therefore, we chose GridSphere and GridPortlets as our main toolkits to speed up the process of developing and deploying application portals. 3.1 Gridsphere Framework Overview GridSphere is a free, open-source portal framework originally developed by the European GridLab project (12) which focused on developing Grid application tools and middleware. The GridSphere portal framework provides a standards based portal for the easy development of modular web components, called portlets. Portlets are defined by a standard API and provide a model for developing new portal components that can be shared and exchanged by various portlet containers. GridSphere provides a portlet container, a collection of core portlets (for portlet management, user management, layout management, and role-based access control) and an advanced user interface library that makes developing new portlets easier for application developers. Its portlet-based architecture offers flexibility and extensibility for portal development and facilitates software component sharing and code reuse. GridSphere is compliant with the JSR-168 portlet specification (13) which allows portlets to be developed independently of a specific portal framework. GridSphere s portlet service model provides developers with a way to encapsulate reusable business logic into services that may be shared between many portlets. 3.2 GridPortlets The advantages of using GridSphere come not only from its core functionalities, but also from its accompanying Grid portal toolkit GridPortlets. GridPortlets abstracts the details of underlying Grid technologies and offers a consistent and uniform high-level service API,

20 3.2. GridPortlets 10 enabling developers to easily create custom Grid portal web-applications.the GridPortlets services provide functionalities for managing proxy credentials, resources, jobs, and remote files, and supports persisting information about credentials, resources, and jobs submitted by users. GridPortlet service API currently supports Globus Toolkit (14) (15). In addition, GridPortlets delivers five well-designed, easy-to-use portlets, which include: resource registry, resource browser, credential management, job submission, and file management: Resource Registry Portlet Administrators can manage the set of resources their Grid portal makes available to its users. Resource Browser Portlet Users can browse the resources to which they have access, including the services, job queues, and accounts that are available on remote computers. Credential Retrieval Portlet Users can retrieve credentials from a MyProxy (16) server and gain single sign-on access to both the portal and Grid resources. Job Submission Portlet Users can submit and manage jobs on their resources using Globus. File Browser Portlet Users can browse and manage physical files on Grid resources. Logical files registered with a logical file service can be accessed if a service is available.

21 Chapter 4 Portals & Portlets for CCT Projects There are several ongoing projects at CCT, including EnLIGHTened Computing, SCOOP, LPFS, Numerical Relativity, and UCoMS, for which an array of portlets were under development, such as resource co-scheduling,querying and retrieving files from data archives, and storm simulation monitoring. This chapter will focus on the author s contribution to each project. 4.1 Resource Co-scheduling As Grid technology advances, more and more distributed high performance computing applications are designed to execute on computational Grids. Often, many of these applications need the ability to allocate multiple resources (processors, memory, storage, network bandwidth) simultaneously. Assuring predictable resources for applications running on the Grid is a critical factor for the success of the Grid. Supported by the NSF EnLIGHTened Computing project (17), the Highly-Available Resource Co-allocator (HARC) (18), a resource co-scheduling framework supporting advance reservations, was designed and im- 11

22 4.1. Resource Co-scheduling 12 plemented at the CCT. To facilitate the usage of HARC services, a Co-scheduling portlet was developed based on the GridSphere framework Design The goal of the co-scheduling portlet is to allow users to manage their resource reservations via an easy-to-use interface. The portlet is intended to meet the following requirements: The portlet must be JSR-168 compliant so that it can be deployed in the most widelyused portal frameworks, such as GridSphere, UPortal, WebSphere, etc. The portlet must allow a user to set up a complex reservation query, which may contain many resource requirements with different types, i.e. computational requirements (processors, memory, storage) and network requirements. A user can freely add, update, delete requirements of a reservation query and preview the resource availability for each requirement before making a reservation. The portlet should list all possible resource timetables for each requirement in a reservation query to allow a user to choose a desirable time to use resources. A user can keep track of all reservations he/she made and cancel reservations. Figure 4.1 shows the architecture of the co-scheduling portlet is based on the Grid- Sphere framework. To simplify the development and improve code reuse, the whole co-scheduling portlet is separated into two components: the co-scheduling portlet and coscheduling portlet service. The co-scheduling portlet handles the requests from end users, calls the portlet service to fulfill those request, and generate result pages to end users. The coscheduling portlet service communicates directly with the HARC, which manages

23 4.1. Resource Co-scheduling 13 End User 1 GridSphere Framework Santaka.cct.lsu.edu End User CoScheduling Portlet Portlet Service HARC kite1.enl-comp.org End User n Database EnLIGHTened NRM Figure 4.1: The architecture of the co-scheduling portlet showing interaction with underlying HARC services a bunch of computational resources and network resources to allow users to make reservations. It builds HARC queries from user-specified reservation requirements for resource timetables, makes a reservation based on timetables a user chooses, and cancels reservations. The portlet service also contains a persistence layer using Hibernate to store reservations for each portal user and allow them to keep track of reservations Implementation As can be seen from Figure 4.2 and Figure 4.3 when creating a reservation query, users can specify requirements either for compute resources such as which machine does the job could be run on, how many processors and how much memory would be utilized to perform the science task, or a network resource, where a network connection can be chosen. At this stage, the user can also set up the time slot, during which they would expect to employ aforementioned resources. Since we use the advance co-scheduling mechanism, taking uncertainty into account, the portlet provides users with two mechanisms to specify their time information. On the one hand, a user can only specify the time duration on the portlet but leave earliest start time and latest end time blank. In such a case, the portlet will

24 4.1. Resource Co-scheduling 14 Figure 4.2: The co-scheduling portlet showing how to set up compute resource requirements including machine name, processors, memory etc. Figure 4.3: The co-scheduling portlet showing how to set up network resource requirements

25 4.1. Resource Co-scheduling 15 Figure 4.4: The co-scheduling portlet showing a default query result, where a user can further specify different desired start time and end time for each reservation by default query the timetable in the next 8 hours to find if there is any time slot available meeting the requirements for the resources. On the other hand, users can narrow their query conditions by specifying the earliest possible start time and the latest end time.under this circumstances, the portlet will query against the timetable to look for the time slot meeting the duration requirement as well as within the time stamp between the user suggested started time and end time. Moreover, we currently offer two modes of query to make the best use of resources. Under the circumstances that a user hopes to find a common timetable for all the resources, the aligned query would be suggested. Otherwise, user would query out separate time table for each resource specified. Figure 4.4 and Figure 4.5 respectively show result pages for these two types of reservation queries. Since not all the queries would be responded with an available timetable, a user can try to reset up another possible start/end time to refire another query upon the resources interested. If one or more timetable could be found for the queried resources, then at the

26 4.1. Resource Co-scheduling 16 Figure 4.5: The co-scheduling portlet showing an aligned query result, where a user can further specify a united desired start time and end time for all reservations next stage, a user will be able to choose one favorite time slot made as start of possible time range and end of possible time range either for each resource (if query is used), or for all resourced( if aligned query is used). Finally, the underlying co-scheduler will try to make the reservation upon the users confirmation. Once the adapter successfully makes the reservation, users will see the status on the portlet. However, some exceptions (i.e. two users request the same resource for an overlapping period) may occur, due to which a reservation for the resources may finally fail to be made. If this is the case, the portlet will report the failure to the user so users can re-schedule again. Furthmore, as shown in Figure 4.6, a user can check out his/her reservation history on the portlet which shows the reservation name and description that the user specified at the time making the reservation. Also, the last modified time can be seen as well. Another column shows the status which can be inactive, active, finished or unreserved. Taking into account that sometimes users may hope to cancel a previously scheduled reservation which is especially true in a workflow scenario, where if task A was not finished in time, a

27 4.2. SCOOP 17 Figure 4.6: The co-scheduling portlet showing a reservation history records of a user subsequent event B has to be delayed, as a result, this reservations may be rescheduled. As long as an reservation is not completed, no matter whether its status is reserved or active, the reservation can be unreserved. 4.2 SCOOP The Southeastern Coastal Ocean Observing and Prediction (SCOOP) Program is an ongoing collaboration between the modeling research community and operational agencies, such as the National Oceanic and Atmospheric Administration (NOAA). SCOOP, sponsored by the Office of Naval Research (ONR) and NOAA s Coastal Services Center, is a multi-institution collaboration which is working towards an integrated and coordinated coastal ocean observing and prediction system, leveraging emerging regional efforts and cutting-edge Grid technologies. It aims to integrate distributed real-time ocean observing stations and regional coastal modeling entities, to run ensembles of numerical hydrodynamic models for the prediction, verification and visualization of critical storm surge and wave behaviour during severe storms and hurricanes. To support this, a portal (19) was built for the SCOOP project at CCT, which provides a number of functionalities to users. Later on, we also deployed our CCT SCOOP portal

28 4.2. SCOOP 18 to machines at University of Alabama at Huntsville (UAH). The SCOOP portal at CCT provides user with interfaces to run and track popular coastal modeling simulations, such as ADCIRC, on the SCOOPGrid resources. The CCT designed and built a general archive ROAR (20) of data for use by the SCOOP Partners. This archive stores atmospheric model outputs (wind data), results generated by the hydrodynamic models which use the atmospheric model outputs for input (wave/surge data), and observational data to be used for verification of model results (sensor data). The archive is based on around a 5TB local storage area, plus a 7TB allocation of off-site storage at SDSC s DataCentral. The portal provides an easy-to-use interface to query the archive for files, which can then be downloaded using either http or GridFTP (21), to the user s desktop, or directly to a remote location (GridFTP only) Archive Portlet & Filenaming Convention Portlet Currently, there are three basic types of data, with which SCOOP is dealing: atmospheric data, simulated wave/surge data, and other observed data to verify the model accuracy. Different classes of data files are associated with different sets of metadata attributes, and have differing query interfaces. The archive portlet at SCOOP Portal gathers metadata information from user requests and retrieves a list of logical file names which have matching metadata from the archive portal service. At the moment, SCOOP does not have an advanced metadata service, the logical file name specified in queries is generated from metadata information contained in the SCOOP file-naming convention. All files in the archive can be classified as belonging to one Catalog ID. The Catalog is a service run at UAH which provides users with a way to locate files in the SCOOP archive. To classify the

29 4.2. SCOOP 19 Figure 4.7: The data portlet on the SCOOP portal showing the query result set of atmospheric forcing with type NAM-NCEP Figure 4.8: The data portlet on the SCOOP portal showing the meta information for a particular queried file including data class, data type, catalog ID etc.

30 4.2. SCOOP 20 Figure 4.9: The parser portlet on the SCOOP portal showing how to query file meta information using a logic file name file into a catalog ID, we need to match the file name against a series of regular expressions. Since the logical file name on the query result page does not explicitly display the meta information including Data Class, Data Type, Institution, Data Format, and CatalogID etc, we decided to construct a parser portlet to show th file meta information for the ease of research. Two implementations of the SCOOP file-naming convention were performed on the portal interface. On the one hand, after querying out the result, by clicking the logical file name, a user will be led to the page showing the specific metadata information, as shown in Figure 4.7. This was accomplished by using the SCOOP file-naming convention documents to map the physical file name with the generated logical name and parse into different fields of metadata information. On the other hand, a separate parser portlet was developed as well for the use of filenaming convention. As shown in Figure 4.9 this portlet would be used generally to check out the meta data information without any query if a logical file name is at hand.

31 4.2. SCOOP 21 Figure 4.10: The WW3 monitoring portlet showing a list of jobs being monitored for storm WaveWatch3 Monitoring Portlet Part of the SCOOP project s work involves the regular execution of atmospheric (e.g. WindGen) and hydrodynamic (e.g. ADCIRC, WaveWatch3) coastal modeling codes, for various geographical regions. These modeling codes consume powerful computational resources and data storage and take a long time to finish. Monitoring the status of each execution becomes important, because it can help researchers or engineers to detect errors and bugs in the execution far earlier before it runs to the end. As a result, it saves time for researchers and computational resources for the organization. As shown in Figure 4.10, the WaveWatch3 Monitoring portlet displays information about the WaveWatch3 operational code we were running for the SCOOP 2006 storm season. The WAN analytical winds are used as input for WaveWatch3 simulations. This interface gives us debug information, status and monitoring information for each ensemble run. However, the current implementation only displays historical information for SCOOP 2006 storm simulations. Once the underlying framework is accomplished, the portal interface will be able to connecting to real-time simulation information.

32 4.2. SCOOP 22 Figure 4.11: The WW3 monitoring portlet showing the detailed information of one job

33 4.3. UCoMS & Numerical Relativity 23 Figure 4.12: The ensemble selector portlet showing how to select ensembles based on options including track, model, forcing etc. Currently, another two portlet interfaces for ensemble selection shown in Figure?? and advanced resource selection shown in Figure 4.13 are being developed for the CCT SCOOP portal. 4.3 UCoMS & Numerical Relativity The UCoMS project (3), sponsored by the Department of Energy and the Louisiana Board of Regents, is researching and developing new Grid computing and sensor network technologies for the management of energy resources. Reservoir simulations are widely used to predict and optimize the production of oil and gas reservoirs, analyzing a myriad of uncertainties in the geophysical structure of the reservoir as well as operational factors such as well location. A number of reservoir simulations are involved in a typical uncertainty analysis. The result dataset of a single simulation depends on the configuration of the simulator, whose average size reaches up to 50 Megabytes or so. Massive simulations lead to storage needs which cannot be easily accommodated with a typical storage resource. A similar

34 4.3. UCoMS & Numerical Relativity 24 Figure 4.13: The advanced resource selection portlet showing how to select ensembles based on advanced options including job manager, wallclock, hotstart etc. scenario happens in the Numerical Relativity group at CCT, where mass data are generated from simulations, e.g. two orbiting black holes. To facilitate future comparison and analysis on results from different runs, we developed and deployed a data archive system for each project to store simulation results. Numerical relativity is the oldest application area of Cactus project (22), for which an array of cactus portlets were developed by Ian Kelley. These two archive systems used similar Grid services (e.g. GridFtp, RLS (23)) and Grid environment and functioned similarly to the SCOOP archive, except that they used different sets of meta data. The archives are implemented with a client-server model. The archive clients are deployed on the computational resources, where simulations run. Once a simulation is finished, its results are pushed to an archive server asynchronously using a transmission protocol of choice with a set of meta data. As shown in Figure 4.14 and Figure 4.15, portlets are developed and deployed to access archive systems so that research scientists are free from the traditional command line to check out the simulation history records, and can easily set up query conditions via Web-

35 4.3. UCoMS & Numerical Relativity 25 Figure 4.14: The UCoMS archive portlet showing how to set up requirements including user name, host name, dates etc to query against the RLS archive Figure 4.15: The NumRel archive portlet showing how to set up query requirements and the query result set based on the requirements specified

36 4.4. LPFS 26 based interface, for example, by user name, host name, file name, or by date, or even by such finer conditions as algorithm, simulator etc. Furthermore, wildcard characters can be utilized to accommodate unknown metadata or to select a range of files. For example, via the archive portlet in the UCoMS ResGrid portal, a petroleum engineer may want to query the archive system about a run conducted within the last 30 days. The user specifies a date range in the portal and submits the query to the portal server. The portal queries the archive system, and returns all the data set entries corresponding to that time frame. If this user is interested only in which algorithm the results are generated by, he/she can restrict the searching criteria to a particular simulation algorithm. The end result would then show all the simulation results from the specified algorithm which occurred within the last 30 days. 4.4 LPFS The Lake Pontchartrain Forecasting System (LPFS) is a collaboration which joins CCT with the Institute for Marine Sciences at UNC and the US Army Corps of Engineers using the computational resources of the Louisiana Optical Network Initiative (LONI) (24). The primary objective of this project is to create an automated wind speed and water level forecast system for Lake Pontchartrain on distributed LONI resources and help the Corp of Engineers to determine when to initiate canal gate closures. The general procedure is to create an ensemble of multiple ADCIRC storm surge simulations based on the consensus storm forecast from the National Hurricane Center and perturbations to this forecast. Winds are generated using a synthetic wind model that has been coded as an ADCIRC subroutine to maximize execution speed. Initial outputs are water level and wind speed time series plots along the southern shore of Lake Pontchartrain near the mouths of the drainage canals.

37 4.4. LPFS 27 Figure 4.16: The LPFS portlet showing the storm information including alert level, location etc. and simulation status and outputs

38 4.4. LPFS 28 The LPFS framework creates an ensemble of multiple ADCIRC storm surge simulations for each storm. Figure 4.16 shows a portlet developed for the LPFS project. This portlet provides an interface to access the storm information, e.g. alert level (yellow, orange, or red) and location, and keep track of ADCIRC storm surge simulations for the storm, e.g. its running status and outputs.

39 Chapter 5 An Integrated Portal for High Performance Computing 5.1 Science Drive for An Integrated Portal Science portals now exist at CCT for a broad range of science collaborations, including efforts in oceanography and coastal sciences (SURA SCOOP), petroleum engineering (UCoMS), numerical relativity (Cactus), and LPFS at the Louisiana State University s Center for Computation & Technology. The close collaborations among research scientists across the center motivated an investigation of the integration of all CCT principal portals into one single highly collaborative portal. From the user perspective, the integration portal relieves them from maintaining a different account on each portal, and provides them the flexibility to customize their personal portal of research interest across projects. From the institution perspective, the integration portal could cut the cost of purchasing additional machines and human resources to maintain those portals and machines. From the portal developer and administrator perspective, 29

40 5.2. Design 30 the integration portal provides them the possibility of centralized management of all institutional portals under one GridSphere framework, and greatly ease their work on portal maintenance. For example, they only need regularly upgrade one GridSphere framework, intead of upgrading different Gridsphere framework for different science portals on different machines. A similar situation happens for deploying or upgrading generic portlets that can be used by different projects. In the integration portal, all portlets and their services are deployed in one GridSphere framework which allows developers to reuse portal services between different projects and develop portlets and services to utilize or manage data across different projects. For example, notification services in Cactus projects can be reused in the SCOOP project. 5.2 Design A collaborative science portal for high performance computing shown by Figure 5.2 was developed at CCT to meet the needs across disciplines. The components of such a collaborative portal come from a number of active major projects at CCT, each of which has demonstrated its unique features and functionalities in its particular area. Figure 5.1 shows the architecture of CCT integration portal based on the GridSphere framework. Users from each project are restricted to access portlets for just that project in addition to common portlets, such as generic Grid portlets (Credential Retrieval, File Browser, etc) and Resource Co-scheduling portlet. A user, who is a member of multiple projects can subscribe to all portlets from those projects. Portlets from each project usually use portal services from that project for applicationspecific functionality and business logic. They can also use portal services from other projects. For example, the credential portlet calls the credential service to retrieve proxy

41 5.2. Design 31 Figure 5.1: The architecture of the CCT integration portal showing interaction among portlets, portal services, and Grid Middleware

42 5.2. Design 32 Figure 5.2: The home page of CCT integrated portal showing the integration of HPC, SCOOP, UCoMS, LPFS portals into one united institute portal credentials from a MyProxy server, and later a job submission portlet can get the retrieved credentials to authenticate with Grid resources. Since most portlets in the Gridsphere do not directly interact with each other, they can communicate via the service layer. Portal services themselves can use or extend services built into the GridSphere framework, other portal services, as well as some third-party packages. For example, the UCoMS portal services use the GridPortlets portal services to interact with Grid resources, such as submitting jobs and managing remote files. The integration portal facilitates the interaction between portal services. As most projects portal services utilize the GridPortlets services, we only need deploy one copy in the integration portal. This portlet-based, service-oriented architecture greatly speeds up portal development and deployment, and exhibits high extensibility.

43 5.3. Implementation Implementation Challenging Issues Just as developing other portals, we first developed a prototype collaborative portal using Gridsphere2.1. We deployed each single project to the integration portal, and generated the collaborative home page by differentiating tabs to show homepages of component portals. However, this initial integration exposed the following problems: Layout issue: Portlets from different component portals sharing common names have tab conflict. Portlets dependency issue: Portlets with the same functionalities from different component portals such as credential management and job submission have duplications. Social issue: Login problems with users having different account name/password on different component portals. Security issue: Portlet visibility among portal users from different projects. Layout Issue In GridSphere, the portlets layout in the portal uses a nested tabbed pane approach. A tabbed pane can contain a list of tabs, and a tab can contain a tabbed pane. After we initially deployed all the CCT major portals into the integration science portal, the tabbed pane on the integration portal can be seen on Figure 5.3. In a portal language, the layout of the integration portal includes a tabbed pane that contains tabs such as Welcome, Data, Models etc, and the data tab contains a lower level of tabbed pane which includes tabs Archive, Parser and Files. Some problems were identified with this initial integration. For

44 5.3. Implementation 34 Figure 5.3: The screenshot showing the problematic tabbed-pane layout of the integration portal Figure 5.4: The screenshot showing the well-organized tabbed-pane layout of the integration portal example, lower level portlets such as Data portlet and Models that belong to a higher level SCOOP project spread out at the same level with UCoMS portlet, which is another higher level project. Also, sometimes, portlets from different component portals sharing common names have tab conflict. For example, both the SCOOP portal and UCoMS portal have the simulation portlet. Portlets Dependency Issue In the integration portal, all portlets and their services are deployed in one GridSphere framework which allows developers to reuse portal services between different projects and develop portlets and services to utilize or manage data across different projects. Portlets with same functionalities from different component portals such as credential management and job submission may have duplications. Figure 5.5 shows the duplicate credential portlets on the integration portal. Figure 5.5: The screenshot showing the duplicate credential portlets on the integration portal

45 5.3. Implementation 35 Figure 5.6: The screenshot showing the resulting layout of the integration portal after extracting shared portlets among component portals Social Issue On the one hand, at the Center for Computation & Technology, research scientists from different domains more often than not have close collaborative opportunities. Most of the faculties and students are actively involved in a number of projects, for example research scientists in data management may be interested in building data archive systems for a wide range of applications, such as data archive for storing and retrieving result datasets from large-scale reservoir simulations, similar data archive serving the same purpose for black hole simulations. Before we implemented the idea of integrating all CCT major portals into one collaborative portal, researchers may need to request an account at each portal, and to test and compare history record at different places. On the other hand, for a user across serveral projects, it may have different accounts on different component portals, which are hard to maintain. Security Issue In addition to the social issue, the security issue is also complicated. When the user logs on the integration portal, how does the portal recognize its identity and roles in different projects and them grant them the appropriate priviledges in the integration portal? For example, a user can only access portlets from projects he/she works on. The project manager may access some administration portlets that ordinary team members can t access. All such issues should be addressed in the integration portal.