Cactus/TIKSL/KDI/Portal Synch Day

Agenda n Main Goals:  Overview of Cactus, TIKSL, KDI, and Portal efforts  present plans for each project  make sure everyone knows what is going on  coordinate efforts to extent possible  Present/develop detailed plan for Portal  where we are now  who will do what in future  develop coherence with NCSA, other portal efforts  get clear plan for future development, feedback to Globus, NCSA  get testbed set up  get user input asap!  Break up into working groups, summarize plans n Overall Top Question to Answer: How do we integrate and develop limited production testbed asap? Want something in place by end of August!

Agenda, cont. n Questions to be asking and answering in your presentations:  What is the overview and status of your project (save gory details for working groups)?  How do we best integrate the efforts?  When will certain features be done?  What support/features do you want from other groups (NCSA, Portal, Globus, TIKSL, HDF, Cactus, etc.) l What to do about lunch? n Look at rest of agenda...

Big Picture: Project Space Cactus TIKSL AEI-ZIB-Garching KDI Egrid EU Network Globus Zeus Numerical Rel AEI/NCSA/WashU Grid Forum Grads Portal NCSA Users General User Community Developers

What is Cactus? n It’s not just for breakfast anymore... l It is not a relativity application…(but it can do that) l It is not an astrophysics application…(but it can do that) l It is not a fluid dynamics application…(but it can do that) n It is a metacode framework for parallel applications, with… l Pluggable data distribution layers (generic MPI, others) l Pluggable parallel I/O l Pluggable performance monitoring tools (PAPI, Autopilot, etc…) l Pluggable engineering/scientific applications, linear solvers, etc l Pluggable cool stuff (remote steering, monitoring tools…) l Etc... n Cactus + Globus: apps plugged into Cactus can become Grid-enabled n A portal under development: main topic here...

Cactus Computational Toolkit Science, Autopilot, AMR, Petsc, HDF, MPI, GrACE, Globus, Remote Steering... A Portal to Computational Science: The Cactus Collaboratory 1. User has science idea Selects Appropriate Resources Collaborators log in to monitor Steers simulation, monitors performance Composes/Builds Code Components w/Interface... Want to integrate and migrate this technology to the generic user...

Portal Components

Cactus Portal n Has Generic and Cactus-specific parts: build on generic interfaces, which should be enhanced for additional app info l Cactus specific –Code composition (Cactus can be what you want it to be…) –Configuration Analysis (What the hell is in this directory…?) –Parameter Setting –Interfaces must be self configuring… l Generic (+ Cactus specific bonus features…) –Manual Resource Selection 1. Which machine? User selects based on available resources »How will user know loads, wait times, resources? Need to have some standard interface to provide this info Which machines? User wants 20GF, 20GB memory. Could get 64 procs at NCSA and 64 at SDSC... Added cactus bonus: what resources are compatible or recommended with my special configuration –Automatic Resource Selection Just direct job to “appropriate” resources given request….

Cactus Portal, cont... –Job Launching Once resources selected, start job, handle batch, job submission, compilation if required Take care of file storage, archiving n Job Monitoring l Generic: monitoring queues through common interface, notification of completion of job –What is that interface? –What about distributed simulations across sites??? l Cactus specific: –Web server interface (thorn http) All active routines in running simulation displayed All parameters for those routines displayed, steerable parameters can be changed Crude visualization of running simulation through browser interface –Sophisticated Remote Visualization Retrieval of arbitrary data through streaming HDF5 for local visualization »1D, 2D, 3D, downsampled, depending on bandwidth available Inline visualization (e.g., isosurfaces, streamlines) sent over network

Cactus Portal, continued –Performance monitoring: Want generic interface to warn user when perf is poor (usually is, and user does not even know!!!) PAPI (single proc, color coded for routine…) Autopilot What else should be provided? What is envisioned for generic portal? n Steering l Science –User changes parameters based on what is observed Parameters screwed up: abort or keep going? »Forgot to turn on output of favorite variable »Forgot to turn on some routine »Too much output, disc filling up Scientific results lead to change in algorithm or resource request »AMR »Feature indicates some change beneficial –Logging of all changes

Cactus Portal, continued l Performance steering –How is my job doing? Network bandwidth OK? Suggest other architecture Suggest algorithm changes due to current state of performance »E.g., Extra ghost zones n Questions for discussion: l What is really Cactus specific? l What is generic: what will standard portal, VMR, etc, provide? l How to get maximum overlap between these efforts? l How to get active testbed established asap, get appropriate users, portal developers, Globus developers, Grads developers effectively working together l How long before this can brought into production? l Should at least have SC2000 demo!

Grand Picture Remote steering and monitoring from airport Origin: NCSA Remote Viz in St Louis T3E: Garching Simulations launched from Cactus Portal Grid enabled Cactus runs on distributed machines Remote Viz and steering from Berlin Viz of data from previous simulations in SF café DataGrid/DPSS Downsampling Globus http HDF5 IsoSurfaces

Further details... n Cactus l l n Movies, research overview (needs major updating) l n Simulation Collaboratory/Portal Work: l n Remote Steering, high speed networking l l n EU Astrophysics Network l potsdam.mpg.de/research/astro/eu_network/index.html