# Presentation: 511255

## The Alliance Portal Expedition

**Jay Alameda**
**National Center for Supercomputing Applications**
**University of Illinois at Urbana-Champaign**

## Portal Expedition

**Dennis Gannon, Beth Plale co-leads**
**Jay Alameda “day to day management”**
**Application Areas**
**Chemical Engineering**
**MEAD**
**Radioastronomy**
**Computer Science Areas**
**ANL: von Laszewski (CoG kits, OpenGCE)**
**IU: Fox (portlets), Gannon (X-everything), Plale (data and databases)**
**UIUC: (java webstart clients, application managers, etc)**
**Utah: Johnson (visualization)**
**U C Santa Barbara: Petzold (sensitivity software (DASPK))**

## Chemical Engineering

**Multiscale computations (with multiple codes)**
**Parameter sensitivity, estimation methods**

## Linked Monte Carlo-Continuum Simulations of Copper Deposition in a Trench

**Monte Carlo**

**Filter**

**Finite Difference PETSc **

**c****k**

**c****k**

**^**

**f****k**

**Diffusion Boundary Layer**

**Near-**
**Surface**
**Region**

**f****k ****– Vector of fluxes passed at time step k**

**c****k**** – Vector of concentrations passed at time step k**

**c****k**** – Vector of filtered concentrations passed at time step k**

**^**

## Motivating Example for CondorG/IU Portal: Parameter Sensitivity & Estimation Methods

- Main Script

- Perturbation Matrix Script

- Script to generate input files

- MC Simulations

- Post-processing Script

*One pass and terminate*

*Iterate until convergence to experimental data*

- Script to compute Jacobian and Sensitivity Matrix

## MEAD

**My take on the requirements:**
**Need to manage datasets (input/output/derived data) for hundreds of large runs**
**And corresponding metadata**

## Radioastronomy

**Reliable execution of workflows paramount**
**Access to grid-enabled platforms**

## NCSA Developments

**Inspired by extreme lab application managers**
**How to take it to the next level**
**Adopt grid web services**
**Asynchronous job launch**
**Configurable gui elements**
**Automatic deployment of grid computing environments**

## Basic Design

**Software Requirements**
**Tomcat 4.0.4**
**Axis Beta 3**
**Java**
**Jython (.jar)**
**Ant 1.5 (.jars)**
**CoG 0.9.13**
**XMessages**

- Factory Service

- Client

- Factory Service Client

***SOAP***

- Application Manager
- Service

***GRAM***

- Workflow Script

- Executable (1, 2, 3 ... )

- ...

- Registry Service Client

- Project Repository Client

- Event Publisher

- Data Services

- Event Listener

**Runtime Monitor**

**Notes:**
Uses Web Service Interfaces, Axis-Soap
Client Build Up Project Description, Job Instance & Environement
Contacts Factory which is responsible for staging the necessary executables and files, launching the application manager
Stateless (re the AppMan/Jobs)
AppMan comes up as another service (I’ve left out the “client” here -- API) which can be contacted
In most cases, AppMan runs a set of scripts, then disappears (batch constraints)
AppMan is skeleton for the actual WorkflowRight now:  hard coded Jython script which composes set of tasks {Ant-like or borrowed}
Want to get to:  XML description which is interpreted
All is done asynchronously, with communication through event system
Data is wrapped in/associated with XML metadata, registered

## Grid Computing Client in detail

## Application Manager Web Service

## Elements of a job

**1)****       ****Select Project**
**2)****       ****Create a new Run**
***3)******      ******Create/Select a workflow***
**4)****       ****Register Run**
**5)****       ****Build Job object**
**6)****       ****Register Job object**
**7)****       ****Submit Job**
**8)****       ****AppMan starts**
**9)****       ****AppMan retrieves everything from Repository**
***10)******   ******Files are retrieved from MSS if necessary***
**11)****    ****RuntimeMonitor wraps executables**
**12)****    ****RuntimeMonitor creates output files**
***13)******   ******AppMan stores output files to MSS***
***14)******   ******AppMan wraps output files and registers them with Repository***
**Italicized steps include data elements**

**Notes:**
Considering the above high level scenario, there are a number of steps (italicized) which involve data and metadata management.  For step #3, which takes place in the GCE client, the user will identify in some fashion the files relevant to the job.  This could be by browsing to the appropriate location, either on the local machine or on a grid-enabled platform, but, in either case this will generate a file-registration in the XMLDBWS.  Desired enhancements to this would include being able to optionally select files from which metadata will be harvested (Note: most of the files we deal with lack the metadata – so for some we would like to say “harvest parameters A, B, D, and F as metadata to describe what this job was about -- we have a prototype of this for a class of chemical engineering files, we will implement this as a task in the workflow description for composition in the overall workflow), as well as the registration of replicas either created through the gui or scheduled to be created with the job or created later during analysis, data mining, and visualization.  How to compose these services is one issue to be resolved for our expeditions.

Similarly, for step 10, being able to augment the basic file transfer with either metadata creation and/or replica tracking would be a valuable addition.  Note in this case the data management task would occur in the AMWS.  Finally when the job completes, steps 13 and 14 are important with respect to file registration – the complete job description stored in the registry would include the location of the output files (and in the full MEAD case, down to the tile files) as stored.  Quite often science codes will have an element of post-processing involved, which will also produce derived quantities which need to be stored, from a scientific point of view, with relevant metadata in the metadata database (the metadata and data should not have to be located physically in the same place.  This will be another element of the workflow to configure; also, keeping track of the replicas is desirable at this point.

## Challenges

***Resolving how to compose these data functionalities is a critical challenge; note that the framework for composition in this case occurs in the AMWS.***
***Want to create a workflow that includes standard analysis, data mining, and vis!  In all of these there is data in (existing data) and data out (new data) that needs to become a part of the “data at large”.***
*** ******Further, it is important that we can come back and make new runs that are tied to a particular suite of simulations.***
*** ******Finally, it is important that our schemas for describing our science are extensible, and, as we learn more about the science we are doing we can send “robots” through the deep data storage to harvest newly-desired metadata for an extended schema and for additional analysis on older data.***

## Alameda Portal Overview – 1 October 2002

## ...

**Broker Service**

**...**

**...**

**User 1**

**User 2**

**User 3**

**JobSet ID**

**Broker Agent 1**

**User Requests**

**Running**

**Completed **

**( Pool )**

**Factory Contact Thread**

**Scheduler Contact Thread**

**App Man**
**Service**

**Factory Service**

**Repository **
**Service**

**Unscheduled**

**Broker Agent 2**

**Broker Agent 3**

**( JobID )**

**JobXML**

**GRAM**

**Job IDs**

**[u1, u2, u3, ... ]**

**[j1, j2, j3, ... ]**

**( JobID )**

**( Job Update)**

**Event Sink **

**Event Listener Agent**

**Runtime Monitor**
**(executable 1)**

**Scheduler**
**Service**

**( Job Status Event )**

**( Job Update )**

**( Job Status Event )**

**( Job Update)**

**JobXML**

**Pending**

**...**

**Runtime Monitor**
**(executable 2)**

**Scheduled**

**JobSet XML**

**Notes:**
1. 	Users send requests for execution of one or more jobs (a job set) to the Broker Service
2.	The broker service handles these requests by (locally) instantiating an agent for each request
	- In essence, the Broker Service is like a factory in that it does not maintain state on the user after the request has been dequeued
	- For scalability, the queue will have a max number of active requests (a pool)
	- For efficiency, we may want to run each agent as a separate JVM (so the OS schedules them as processes rather than threads)
3.	Each broker agent maintains a set of queues for the jobs it is given
	- It uses an Event Listener Agent to monitor for update events (“SCHEDULED”, “RUNNING”, “FAILED”, “DONE”)
		(we may want to have the agent switch periodically between push and pull modes for added reliability)
	- On the basis of these events, the broker agent promotes or demotes the apposite job from one queue to another
		(policy concerning failures will be specified as part of the job description; eventually what we will probably want to pass to the 
		 Broker is not a set of Job IDs but a single ID for an “ensemble” description in the registry which the Broker Service will retrieve and 
		give to the agent; this ensemble would contain, among other things, a list of the job ids, along with their failure policy; the agent 
		would parse this document so it could refer to this info without having to recontact the repository)
	- The scheduler contact thread listens to the “unscheduled” queue and sends off requests to the scheduler
	- The factory contact thread listens to the “scheduled” queue and sends off requests to the factory
4.	The scheduler service will, upon determination of the host on which to run the job, directly contact the repository and update
	 the job instance description
5.	The repository will be responsible for sending a Job Status Event whenever it is updated

ISSUES:
1.	How does the factory get the client proxy? 
2.	Should the Broker Agent also be a service?  i.e., be contactable?

-----------------------------------------------------------------------------------

NEAR TERM GOALS:

GGF 6:
End-to-End demo:
	Build & register job through GUI
	Launch Job through Web Service Factory
	Factory uses cheat (local proxy) to launch AppMan remotely
	AppMan comes up as simple JVM, but registers its url
	AppMan automatically runs the WRF/Scoring Jython scripts 
	Jython scripts call simulation stubs (in C)
	Client intercepts unfiltered events from the run

SC2002:
End-to-End demo:
	Build & register job through GUI
	Launch Job through Web Service Factory which is GSI-enabled (i.e., is Grid Service)
	Factory launches AppMan remotely
	AppMan comes up as contactable service
	AppMan automatically runs the WRF/Scoring Jython scripts
	Jython scripts call real codes
	Client intercepts unfiltered events from the run
	Viz??????

Q1:
	Scripts should properly wrap output with metadata descriptions and register them
	Event channel should be connected to XML db and filtering enabled

Q2:
	Prototype of the XML-based work-flow engine
	Prototype of Broker

I’m not going beyond that for the moment :-).