Alliance Chemical Engineering Portal Jay Alameda Alliance Chemical Engineering National Center for Supercomputing Applications University of Illinois at Urbana-Champaign Alameda – EHAT Team Meeting – 02 November 2000

Essence of the Science Portal Share code, data, and expertise to allow experts and non-experts access to advanced tools to address substantial projects through collaborative efforts Link data and simulations, over broad range of scales, across discipline boundaries Alameda – EHAT Team Meeting – 02 November 2000

Chemical Engineering Portal Technical Plan Protocols for sharing experimental data and codes Mechanisms for including protected materials Specifications for interoperability in the portal environment Data repository with links to analysis tools Links to thermophysical property databases Linking codes continuum with non-continuum simulations with process control tools Alameda – EHAT Team Meeting – 02 November 2000

Application Area Portals Objective To provide a web-based environment for users of a class of related applications to Execute the apps by filling in web form information such as application parameter values path to input files User doesn’t care where it runs. Just wants it run fast. The ability to compose apps or to script parameter studies A Repository for managing experimental sessions. Both collaborative version and MyServer version Alameda – EHAT Team Meeting – 02 November 2000

Assumptions about Portal Users/Developers Three types of Users/Developers Users that want to run an application from their desktop. Don’t care if app is local or running on a remote resource Care only about access to capability Developers of application portal Want to develop portal capabilities for user of a class of applications. Want easy tools to build portal sites and integrate applications Developers of the application “components” want to focus on building application. Don’t want to fuss with grid details. Alameda – EHAT Team Meeting – 02 November 2000

Scientific Problem Interface Alameda – EHAT Team Meeting – 02 November 2000

Alameda – EHAT Team Meeting – 02 November 2000 Scientific Problem – 2 Alameda – EHAT Team Meeting – 02 November 2000

Alameda – EHAT Team Meeting – 02 November 2000 Scientific Problem - 3 Alameda – EHAT Team Meeting – 02 November 2000

Alameda – EHAT Team Meeting – 02 November 2000 Scientific Problem 4 Alameda – EHAT Team Meeting – 02 November 2000

Alameda – EHAT Team Meeting – 02 November 2000 Scientific Problem 5 Alameda – EHAT Team Meeting – 02 November 2000

Technology Development for the Alliance Science Portal Architecture Dennis Gannon, Geoffrey Fox, Gregor von Laszewski, Jay Alameda Browser Rendering Service (layoutportalML) Visualization Service Security Proxy Delegation Authorization Event Services Portal Information Service Technical Content for portal Architecutre. Gannon and Fox are doing this. See VII:96 plus next slide Broswer Rendering: representing the Portal in a variety of browsers. The next generation will use XML (layoutportalML) to represent active components on the browser that are executing back on the server. Visualization: A set of tools. Baker and Hibbard Security: see notes below. Proxy is easy, authorization is harder, wiping out fingerprints is even more difficult Events Services: Necessary for coordinating multi-scale calculations and for building collaborative Portals. Portal Information Service: used for finding portal components. This is like a Windows NT Registry or CORBA’s component information service. Alameda – EHAT Team Meeting – 02 November 2000

Technology Development, continued Component Architecture Composition Service Authoring Service Science Wrapper Team Shared Portal in the Web betterportalML Collaboration Services Data Strategy Globus Data Grid NPACI SRB/MCAT Technical Content for portal Component Architecture: Composition service is necessary to build multi-scale calculations. Authoring service allows scientists and engineers to build their own content (the ability to lay out a scientific problem so that others in front of the screen can interact with it. It is the task of creating an interactive electronic site. The expert identifies the important parameters and other interesting characteristic and provides linkages to the code that appear on the web page so that users “in front of the screen” can interact with the problem. Here is the expert behind the screen making code accessible to less expert users who want to use the code to check their data or other interests.) Science Wrapping allows code developers to easily incorporate their codes into the Portal (for starters this is the generic proxy modified by XML, and we are shooting for a wizard that does this). Shared Portal: Allows synchronous collaboration on different Portal tools between geographically distributed collaborators. Data Strategy: (a) Code interoperability so that data are understood across codes. (b) Finding data and recognizing what it is. Metadata about your data. Data can be on desktop, mass storage, HPC platfoms and these need to be seamlessly accessed. (c) Database interoperability involves making one query on multiple databases, preferably from within a simulation code, that returns the correct result. You don’t want to be opening ten different web sites and manually querying them and retrieving the answer and plugging it into your code. Alameda – EHAT Team Meeting – 02 November 2000

The Big Picture Three Levels Top Level Middle Level Back End Browser and Other Client Tools Middle Level Secure Web Server Script execution engine Servlets/Beans Proxies for Grid Services MyProxy Authentication Derived from GSI Uses Globus COG to talk to Grid. Back End Application components Specified by XML Communicate directly or by files Client side Vis Tools Browser Journal Tool HTTP/SOAP calls Server side Secure web server Servlet Engine & JPython Script Interpreter MyProxy Auth. Job Mgmt File Mgmt Info & Event Services The Big Picture for the Portal: Three levels of running codes. Client: allows you to run applications (viz tools etc) or web browsers, and keep track of your activities in a journal. Server: here is where the Portal components run. All the events get routed through server. The Portal can find important components (via JAVA servlets/beans, C++) at the server level, and run scripts (PYTHON scripts or short code that tell the Portal how to run an application) that run in the web server. Also, the users grid credentials get established on a temporary basis on the web server (MyProxy). Globus COG (Commodity Grid) bridges between web server and Grid (job submission, file management, communication, security) Grid: We have access to diverse set of HPC platforms (SGI, Linux Cluster, NT Cluster, Condor) running codes encapsulated with a component proxy (gives the code an interface to make it interoperable with the components at the server level). Generic proxy is modified with XML metadata describing the application-specific input/output files (these are at the simplest level: ASCII or binary, input or output, required or optional, etc.) so that the proxy becomes specific to the application. Example: User directs the browser to link a MC and FEM code at the application level Security architecture now: user keeps their credentials to themselves, and delegate a temporary credential to a secure (MyProxy) server that runs at a high level of security. From the Portal, a user can grab temporary credentials and use them to do calculations. The full bore credentials are always kept with the user so that if any machines are compromised, the credentials will expire. Users can run secure Portal sessions from any machine. This handles authentication: knowing who every user is. Next generation security: Full authorization from top to bottom (controlling access to codes and data). You want to know with a single knob who has access to what. Some codes are controlled by licensing. Some files are confidential information. After that: Leaving no fingerprints: a still higher level that enables a user to set up work and then retrieve all results back behind firewalls and wipe the slate clean. Globus Cog calls Grid side Application Application XML/SOAP communication Application Alameda – EHAT Team Meeting – 02 November 2000

The Back End in Greater Detail For Application Components Each is described by an XML description Descriptions stored in Information Service. Used to generate a “proxy” which launches and listens for application events such as file reads/writes. Component apps typically read and write files. File types described by another XML schema which is used to generate intermediate communication adaptors which allow the output of one component to be used as the input to another. Server-managed scripts can be used to manage computations involving large numbers of apps and files. Alameda – EHAT Team Meeting – 02 November 2000

Alliance - IU App Portal Notebook An extension of User Grid Portal A Script Engine Jpython based script pages Scripts can access COG/GPDK to launch jobs, etc. A Database of user experiments Each session/experiment is saved as a directory containing Scripts used and parameters output pages user annotations Event log Simple Grid Event model based on SOAP. Standard Browser Specialized client tool http request reply SOAP RMI Portal Server Notebook Database Servlets Authentication Servlets Grid Access Servlets Script Interpreter Remote distributed resources globus grids, legion condor, entropia Alameda – EHAT Team Meeting – 02 November 2000

Alameda – EHAT Team Meeting – 02 November 2000 Portal Notebook Notebook is a hierarchical directory of ordinary web pages pages with input forms (java script) execution scripts (driven by forms pages.) Users of a notebook create “sessions”: an application execution/experiment. Including parameter settings and results and event log A session can be revisited, modified and run as a new session. Start running session. Leave and come back later. portal server Notebook servlets Portal services Electo-chem Configure & launch scripts User Sessions User 1 experiment User 2 Parameters (xml) Output files Event logs Alameda – EHAT Team Meeting – 02 November 2000

Application Scripting execution Proxy Script 1. stage 1. Configure 2. Launch 3. Monitor 4. signal Portal Server application configuration & launch proxy scrpts Events Application 2 Some Apps require linking together several sub-apps. Chem-Eng: monte carlo + Finite Diff codes Requires two levels of scripts configuration and launch scripts running in server application proxy scripts monitor sub-app send events stage files event handler scripts Alameda – EHAT Team Meeting – 02 November 2000

I could end in the last one minutes by describing how this project represents but one example of many that are likely to emerge out of chemical engineering. I will comment briefly on the need for similar tools in order to address processing issues in biotechnology and nanotechnology, the re-inventing of the chemical process industry from an environmental quality point of view, and the implications associated with run out of petroleum as the limitless feed stock.