The GROWL Project Rob Allan E-Science Centre, CCLRC Daresbury Laboratory r.j.allan@dl.ac.uk

1. The GROWL Project Rob Allan E-Science Centre, CCLRC Daresbury Laboratory r.j.allan@dl.ac.uk

2. Institutions need Autonomy and Security Host – client relationship Example solution suggested by Web server - browser Communication must be initiated by client because of firewall around client’s institution. Can use a proxy or gateway.

3. The Grid “Client Problem” Many clients want to access a few Grid-enabled resources Grid Core Consumer clients: PC, TV, video, AG Middleware e.g. Globus Workplace: desktop clients Portable clients: phones, laptop, pda, data entry… Grid Core

4. Summary of Options • Provide a Grid with heavyweight functionality (Globus?) - Grid-enabled compute and data servers analogous to Web servers; • Implied need for client-server software architecture, e.g. using Web services: • Web-based portal with familiar browser • Client programming library - API in C, C++ Java, Perl, Python, R etc. • Ability to link to existing applications/ GUIs • Command-based shell interface • Drag and Drop desktop interface • Need a published set of services on Grid hosts – OGSA model, registry, semantics; • Need easy development and deployment framework for applications and client tools - encourage community contribution via an open process. This was presented in the JISC VRE Roadmap

5. GROWL, potted History GROWL: Grid Resources on Workstation Libraryhttp://www.growl.org.uk • Discussion started on underground with Peter Coveney, 18/12/03 after attending the GOSC meeting convened by Tony Hey in London. • Prototype developed by RJA to expose the Globus services provided in HPCPortal as C-client Web services • Proposal to and funding by JISC under the VRE Progamme £150k for 18 months (developers at Cambridge, Daresbury, Lancaster) • SABRE-R, ESRC pilot project • Follow-on projects, GROWL will be used in CQeSS, ESRC e-Infrastructure, e-CCP, NW-GRID, etc. Strix Nebulosa,the Great Grey Owl

6. GROWL Modules and Server GROWL is designed to allow “heritage” applications to be Grid enabled. Written in C/ C++ with wrappers (e.g. Fortran, R, Python…) 100% non-Java!!! John and Dan will explain technical details in other talks. I will quickly mention additional work on • AgentX • RCommands Future interest: • Work with others to standardise technology and functionality • Other funding opportunities? • Standarise API (SAGA, DRMAA, etc?) • Additional modules, e.g. OGSA-DAI • WSRF?

7. AgentX Framework - Example DL_POLY3 (CCP5) integrated with CCP1 GUI Mappings DL_POLY3 REVCON.xml CONTROL CCP1 GUI Mappings • AgentX • Core library written in C • Wrappers for Python, Perl and Fortran • Hides the complexities of dealing with XML • Simple API • Enables straightforward exchange of information AgentX core AgentX core CONFIG.xml Fortran wrapper Python wrapper Standard Ontology Standard Mappings

8. “Grand Challenge” science and the e-Minerals VO Level of theory Quantum Monte Carlo Natural organic matter Linear-scaling quantum mechanics Oxides/hydroxides Aluminosilicates Clays, micas Sulphides Phosphates Carbonates Large empirical models Organic molecules Adsorbing surface Metallic elements Halogens Contaminant Beginning to use AgentX to link together many applications, DL_POLY, Siesta, GULP etc.

9. RCommands (1) • RCommands are shell tools and associated Web services for meta-data manipulation • RCommands primary use case is within e-Minerals workflow, i.e. to allow automatic insertion of meta-data as a post processing action

10. RCommands (2) Client Side RCommands gSOAP RCommand Server Code Axis Server Side JDBC Link into workflows BPEL Engine SOAP Relational Database

11. Architecture RCommand RPC Endpoints MDE JSP, Servlets & Beans RCommand Server Code Relational Database Expose same functionality/ code base via a variety of interfaces

12. Subset of Schema • Title • Description • Notes • Start / End Dates • Originator • Name • Description Name Value Pairs • Name • URI

13. RCommand Clients