Cyberinfrastructure: Helping Push Research Boundaries

Slide 1: Cyberinfrastructure: Helping Push Research Boundaries  Shantenu Jha* Asst. Res. Professor (CS)   Sr. Research Scientist (CCT) *also affiliated with National e­Science Centre (UK) & UCL

Slide 2: CI: Helping Push Research Boundaries • Developing CI: A one step process?  – “If we build it, will they come?” “Will it be usable?” • Interplay of (sustainable, long­term, and broadly  usable) CI and Research more complex  – Research & Applications requirements  inform the  development of CI  – In response, developed CI “roughly” sets the  boundaries of applications and their usage mode – Novel applications and usage modes that can  exploit CI will push the boundaries of research... 2

Slide 3: Outline • Scientific Grid Applications  • Computing Free Energies in Biological Systems –  STIMD (2003­04), SPICE (2005­06) • Challenges of Distributed Environments  • HARC: A tool for co­allocating resources – GENIUS: Grid­Enabled Neurosurgical Imaging  Using Simulations (2007­08) • Simple API for Grid Applications (SAGA) • Regional CI Example ­ Louisiana • Software: Cactus, HARC, Petashare, SAGA...  • People: LONI Institute and NSF Cybertools • Novel e­Science Applications 3

Slide 4:     Source: NSF report on Cyberinfrastructure for Biology

Slide 5: Computing Free Energies: Motivation Cellullar  messangers      e.g.  Growth  Factors,  Thermodynamic  quantity  of  maximum cytokines significance.  Transmembrane  receptor Characterizes the binding accurately: Recognition of    Inhibit specific protein domains      activated receptor by    Cell signalling events   Intelligent drug design ... SH2 domain Rapid  &  accurate  determination    is  critical:   Gene switched     ­  where  FE  difference  maybe  just  one part of the overall “system”      ­ library of ligands to explore    

Slide 6: Scientific Grid Computing: An Exemplar • Computing FE is computationally very expensive. Balance  between  accuracy  and  rapid  determination.  Some  experimental time­scales are 2­3 days.  • Algorithmic  advances  (e.g.,  O(N  logN))  have  helped;  but  more than just algorithmic advances are required.  • Computational  ‘Grid’  Science:  Which  approaches  can  be  adapted  to  exploit  grid­based  computation?  Interplay  of  physical algorithm(s) and grid  architecture(s).      

Slide 7: Computing a Free Energy Difference Using Thermodynamic Integration (TI) Src SH2 domain λ=0 λ=1 ∆G1 ∆GB ∆GA ligand Free  energy  of  binding  of  the  ligand  to  the  ∆G2 larger  protein  characterises  the  strength  of  the  binding.  TI provides a formalism to compute the difference of free energy of binding (GAB) between   two  somewhat  similar,  yet  different  peptides.  The  key  concept  in  TI    is  that  of  a  thermodynamic cycle ­ varying the value of lambda from 0 (peptide A) to 1 (peptide B).      ∆ ∆GAB  =   ∆GB ­ ∆GA      =   ∆G1 ­ ∆G2    

Slide 8: TI Calculation: Modified Workflow H λ Launch initial job, use real time analysis to  determine  when  to  spawn  next  simulation  Starting  Check for convergence t at  a  new  λ  value.  Spawning  simulation  conformation continues  until  sufficient  data  collected.  Need to control several jobs.  λ=0.10 time H λ=0.25 λ λ=0.33 In  general,  use  realtime  analysis  to  dynamically  determine best next value of lambda.  λ … λ=0.9 Combine  and  calculate  data  from  all  runs  to  compute the integral to get  ∆∆GAB.    

Slide 9: Infrastructure (Software) Developed for Application Steering  Library:  Correct  functional    abstraction  from  app.  perspective.  steering_control(), register_params(), emit_data()   Library  determines  destination,  transport  mechanism,  fopen,  fwrite Architecture of a steered application. Details of infrastructure & middleware (layers) hidden from app    

Slide 10: Extensions of the Distributed TI  Concept  Computational Techniques ­ Replica Exchange Methods     Need for “intelligent” infrastructure to be coupled with analysis method ­ Ensemble MD – Simulate each system many times from same starting position – Allows conformational sampling. Can’t say how much a priori. Start Conformation Series of Runs End Conformations C1 Cx C2 C3 Equilibration Protocols eq1  eq2  eq3  eq4  eq5  eq6  eq7  eq8 C4

Slide 11: RNA Translocation Through Protein Pores Molecular  Biology:  Critical  and  ubiquitous  process. A model for: ­ Gene expression in eukaryotic cells ­ Viral infections rely on import of viral  genome via nuclear pore ­Translocation  across  bacterial  membrane during  phage infection                       Technical Applications: Artificial pores  (similar  to  natural  pore)  for  high­ throughput DNA screening Theoretical  Physics:  Long  standing  problem  of  a  semi­flexible  polymer  motion in a confined geometry    

Slide 12: Simulated Pore Interactive Computing Environment Size,  complexity  &  timescale:  Computations  expensive.      Millions of CPU hours using “vanilla” MD.  Not good enough. Free  Energy  Profile:  Extremely  challenging  but  yields  maximal insight and understanding of translocation process. Novel  Algorithm:  Steered  Molecular  Dynamics  to  “pull  DNA  through  the  pore”.  Jarzynksi's  Equation    to  compute  equilibrium  free  energy  profile  from  such  non­equilibrium  pulling.    e ­ß∆F  = ‹ e ­ßW ›    

Slide 13: Grid Computing Using Novel Algorithms  SMD+JE:  Need  to  determine  “optimal”  parameters  before  simulations at the optimal values.   Requires:  Interactive  simulations  and  distributing  many  large,  parallel simulations  Interactive  “Live  coupling”:  use  visualization to steer simulation Reduces computational cost by a factor of ca. 100.  Solve  a  computationally  “intractable”  problem  using  novel  algorithm.  Our  solution  not  only  exploits  grid  infrastructure,  but  requires it.     

Slide 14: SPICE: Computing the Free Energy Profile (FEP) Replace single long running ‘vanilla’ MD simulation with following scheme: Step I: Understand structural features using static visualization  Step II:  Interactive simulations for dynamic and energetic features     ­  Steered simulations: bidirectional communication.  Qualitative + Quantitative (SMD+JE)                   ­  Haptic interaction: Use haptic  to feel feedback forces   Step III:  Simulations  to compute “optimal” parameter values:                e.g., 75 simulations on 128/256 processors each.        Step IV: Use computed “optimal” values to calculate full FEP   along the cylindrical axis of the pore.                

Slide 15: Grid Computing, Interactivity and Analysis •  Interactive  simulations  used  to  determine: Optimal  value  of  force­constant  &  pulling  velocity,  choice  of  sub­trajectory  length  and  location for optimal value simulations •  Use  visualization  to  provide  input  to    the  running  simulation.  Require  256px  (or  more)  of  HPC  for  interactivity.  Steady­state  data  stream (up & down) Interactive  simulations  perform  better  when  using  optical  lightpaths  between simulation and visualization Due to network characteristics. Typical “legacy” app (NAMD) not written  for network I/O. “Unreliable” transfer can stall simulations.      

Slide 16: “Global” Grid Infrastructure UK NGS NGS HPCx Leeds US TeraGrid Starlight (Chicago) Manchester Netherlight (Amsterdam) SDSC Oxford NCSA PSC RAL UKLight App Sci DEISA All sites connected by production network Computation Network PoP Visualization

Slide 17: Recap: FE Exemplars  Both FE Algorithms are good candidates for distributed  resource utilization –  i.e., “pleasantly” distributable  Similar Infrastructure  –  Software (ReG Steering Services), middleware..  –  Federated Grids  SPICE more complex than STIMD: – Complexity of tasks different –  Needs co­scheduling of heterogenous resources – number of components/degree­of­freedom different

Slide 18: VORTONICS:  Vortex Dynamics on Transatlantic Federated Grids US­UK TG­NGS Joint Projects Supported by NSF,  EPSRC, and TeraGrid Computational challenge: Enormous problem sizes, memory  requirements, and long run times: Largest runs require  geographically distributed domain decomposition (GD3)    

Slide 19: Run Sizes to Date / Performance • Using an early version of MPICH­G2, 3D lattice  sizes up to 6453  across six sites on TG/NGS • NCSA, SDSC, ANL, TACC, PSC, CSAR (UK) • Amount of data injected into network.   Strongly bandwidth limited. • Effective SUPS/processor • Reduced by factor approximately equal to  1 2 3 4 sites number of sites • Therefore SUPS approximately constant as  problem grows in size sites kSUPS/Proc – If too large to fit onto one machine, GD3   over  1 600 N resources simultaneously is no worse than  2 300 N sequential runs 4 149 6 75    

Slide 20: Outline • Scientific Grid Applications  • Computing Free Energies in Biological Systems –  STIMD (2003­04), SPICE (2005­06) • Challenges of Distributed Environments  • HARC: A tool for co­allocating resources – GENIUS: Grid­Enabled Neurosurgical Imaging  Using Simulations (2007­08) • Simple API for Grid Applications (SAGA) • Regional CI Example • Software: Cactus, HARC, Petashare, SAGA...  • People: LONI Institute and NSF Cybertools • Novel e­Science Applications 20

Slide 21: Challenges of Distributed Environments Lessons learnt from Pilot Projects • Hiding the Heterogeneity; providing uniformity We interface application code to grid middleware through well  defined user­level APIs. No code refactoring required. Hides heterogeneity of software stack and site­specific details: Vortonics: MPICH­G2 hides low­level details   (communication,  network­topology,  resource­allocation and management) SPICE ­­ RealityGrid steering library  • Need for usable, stable and  extensible infrastructure Infrastructure relatively “easy” for demo(s); difficult for routine use!  Science requires stable & persistent infrastructure Motivation for SAGA Efforts at OGF    

Slide 22: Challenges of Distributed Environments • Machine Configuration Issues: ­ Variants of the same problem faced, e.g., hidden IP issue         for MPICH­G2 and RealityGrid steering   ­ Same problem on different resources, e.g., PSC and HPCx.  PSC  = qsocket + Access Gateway Node         performance issues remain due to protocol constraints HPCx= Same solution does not work for ReG Steering;                   port­forwarding being tested    

Slide 23: Challenges of Distributed Environments Federated Grids • Current barrier to utilise federated grids still high: Many degrees­of­freedom need coordination Collective Inter­Grid Debugging required • Federated Grids must be interoperable in practice: Stress test using real applications Requires additional “user level  middleware” (MPICH­G2,   ReG steering infrastructure), to work  across grids • Paper on the theory, implementation and experiences of the three  joint projects: (CLADE 2006, Sp. Issue Cluster Comp)        http://www.realitygrid.org/publications/triprojects_clade_final.pdf •Application level Interoperability; Influenced the creation of GIN    

Slide 24: Challenges of Distributed Environments New policies for resource co­ordination are required  A common requirement of SPICE and VORTONICS: co­scheduling  of resources (computer, visualization, network)! Three levels of scheduling complexity: –  Advance single resource reservation –  Advanced, coordinated multiple reservations across a grid  –  Advance coordinated reservations across distinct grids! First breaks standard HPC usage model; Third  Cross­Grid Co­ scheduling is very hard today. Current levels of human intervention too high: Need  Automation              Motivation for HARC    

Slide 25: HARC: Highly­Available Resource Co­allocator • What is Co­allocation? • Process of reserving multiple resources for use by a  single application or “thing” – but in a single step... • Can reserve the resources: – For the same time: • Metacomputing, large MPIg/MPICH­G2 jobs • Distributed visualization  – Or some coordinated set of times • Computational workflows   HARC is primarily  developed by Jon  Maclaren@ CCT  

Slide 26: How does HARC Work? • Client makes request, from  command line, or other tool via  Client API • Request goes to the HARC  Acceptors, which manage the co­ allocation • The Acceptors talk to individual  Resource Managers which make  the individual reservations by  talking to the local schedulers    

Slide 27: HARC is Extensible (Community Model) • Modular Design throughout – Not just compute resources.  New resource types can be  added, then co­allocated with all other types of resource – No modification to Acceptors is needed.  Just provide  Resource Manager code to schedule the resource – And extend the Client API with new classes (again, no mods to  existing code) – Even works from the command line • Example: Network Resource Manager $ harc-reserve -n EnLIGHTened/RA1-BTH -c bluedawg.loni.org/8 -s 12:00 -d 1:00 – Co­allocates a lightpath between LSU & MCNC, with 8  processors on bluedawg... – Was used to schedule lightpaths in EnLIGHTened testbed for  Thomas Sterling’s HPC Class, broadcast in High­def video    

Slide 28: GENIUS: Overview PI: Coveney, UCL Goals:    Provide a better understanding of      cerebral fluid flow,   Inform clinicians of best surgical approaches. Approach:   Model large scale patient specific cerebral blood flow within clinically  relevant time frames Provides:    Reliable & effective patient­specific image­based models   Efficient LB blood flow simulation  Real time blood flow volume rendering – Visualisation    

Slide 29: HemeLB fluid flow solver  A fast fluid flow simulation of a very large system  requires the use of an efficient parallel fluid solver  several processors • Lattice­Boltzmann method; Parallel MPI code, • Efficient algorithms for sparse geometries, • Topology­aware graph growing partitioning technique, • Optimized inter­ and intra­machine communication  patterns, • Full checkpoint capabilities...    

Slide 30: HemeLB fluid solver performance MPI­g: pre­release grid­enable MPI implementation which is  optimised for the overlap of communication and computation. Performance of HemeLB’s fluid solver on patient­specific  system using LONI machines (IBM Power5 1.9 GHz). LB time steps per second Cross­site ­ 2 LONI IBM machines    

Slide 31: Advance resources reservation: HARC Efficient code and MPI­g exist,  but how to run over several  distributed machines? Use HARC ­ Highly Available Robust Co­scheduler (developed  by Jon Maclaren at LSU). Why  HemeLB  +  MPI­g  +  HARC ? Heterogeneous and sparse resources are more likely to be  available and give us prompt results Clinically relevant and timely results    

Slide 32: NGS UK NGS US/UK Grid Infrastructure HPCx Leeds Manchester TeraGrid Oxford RAL LONI LSU HSCTech La ULM NSU The GENIUS project makes use of Alex SLU SU LSU infrastructure provided by LONI,  TeraGrid and NGS, connected by  ULL UNO McNeese LSU HSC dedicated switched optical light paths Tulane    

Slide 33: Using HARC... • Our aim is to get HARC available to users as part of  the basic Grid infrastructure • Current deployments – LONI (Louisiana Optical Network Initiative) • production mode – UK NGS, Manchester, Leeds and Oxford NGS2  – TeraGrid Co­scheduling testbed machines  (SDSC/NCSA IA­64) – NW­Grid (Lancaster, Manchester) • Everything is open source too • See:   – http://www.cct.lsu.edu/~maclaren/HARC/  

Slide 34: Rough Taxonomy of Applications • Some applications are Grid­unaware and want to remain so – Use tools/environments (e.g, NanoHub, GridChem) – May run on Grid­aware/Grid­enabled environments (e.g.   Condor) or programming environment (e.g, MPICH­G2) • Some applications are explicitly Grid­aware – Control, Interact & Exploit distributed systems at the  application level 34

Slide 35: SAGA: In a Nutshell • A lack of:  • Programming interface that provides common grid  functionality with the correct level of abstractions?  • Ability to hide underlying complexities, varying semantics,  heterogenities and changes from application  program(er)  • Simple, integrated, stable, uniform, high­level  interface • Simplicity: Restricted in scope, 80/20  • Measure(s) of success: • Does SAGA enable quick development  of “new”  distributed applications? • Does it enable greater functionality using less code?

Slide 36: Copy a File: Globus GASS int copy_file (char const* source, char const* target) if (source_url.scheme_type == GLOBUS_URL_SCHEME_GSIFTP || { source_url.scheme_type == GLOBUS_URL_SCHEME_FTP ) { globus_url_t source_url; globus_ftp_client_operationattr_init (&source_ftp_attr); globus_io_handle_t dest_io_handle; globus_gass_copy_attr_set_ftp (&source_gass_copy_attr, globus_ftp_client_operationattr_t source_ftp_attr; &source_ftp_attr); globus_result_t result; } globus_gass_transfer_requestattr_t source_gass_attr; else { globus_gass_copy_attr_t source_gass_copy_attr; globus_gass_transfer_requestattr_init (&source_gass_attr, globus_gass_copy_handle_t gass_copy_handle; source_url.scheme); globus_gass_copy_handleattr_t gass_copy_handleattr; globus_gass_copy_attr_set_gass(&source_gass_copy_attr, globus_ftp_client_handleattr_t ftp_handleattr; &source_gass_attr); globus_io_attr_t io_attr; } int output_file = -1; output_file = globus_libc_open ((char*) target, if ( globus_url_parse (source_URL, &source_url) != GLOBUS_SUCCESS ) { O_WRONLY | O_TRUNC | O_CREAT, printf ("can not parse source_URL "%s"n", source_URL); S_IRUSR | S_IWUSR | S_IRGRP | return (-1); S_IWGRP); } if ( output_file == -1 ) { printf ("could not open the file "%s"n", target); if ( source_url.scheme_type != GLOBUS_URL_SCHEME_GSIFTP && return (-1); source_url.scheme_type != GLOBUS_URL_SCHEME_FTP && } source_url.scheme_type != GLOBUS_URL_SCHEME_HTTP && /* convert stdout to be a globus_io_handle */ source_url.scheme_type != GLOBUS_URL_SCHEME_HTTPS ) { if ( globus_io_file_posix_convert (output_file, 0, printf ("can not copy from %s - wrong protn", source_URL); &dest_io_handle) return (-1); != GLOBUS_SUCCESS) { } printf ("Error converting the file handlen"); globus_gass_copy_handleattr_init (&gass_copy_handleattr); return (-1); globus_gass_copy_attr_init (&source_gass_copy_attr); } globus_ftp_client_handleattr_init (&ftp_handleattr); result = globus_gass_copy_register_url_to_handle ( globus_io_fileattr_init (&io_attr); &gass_copy_handle, (char*)source_URL, &source_gass_copy_attr, &dest_io_handle, globus_gass_copy_attr_set_io (&source_gass_copy_attr, &io_attr); my_callback, NULL); &io_attr); if ( result != GLOBUS_SUCCESS ) { globus_gass_copy_handleattr_set_ftp_attr printf ("error: %sn", globus_object_printable_to_string (&gass_copy_handleattr, (globus_error_get (result))); &ftp_handleattr); return (-1); globus_gass_copy_handle_init (&gass_copy_handle, } &gass_copy_handleattr); globus_url_destroy (&source_url); return (0); 10/22/2006 LCSD'06  36 }

Slide 37: SAGA Example: Copy a File High­level, uniform #include <string> #include <saga/saga.hpp> void copy_file(std::string source_url, std::string target_url) { try { saga::file f(source_url); f.copy(target_url); } catch (saga::exception const &e) { std::cerr << e.what() << std::endl; } } • Provides the high level abstraction, that application programmers  need; will work across different systems • Shields gory details of lower­level m/w system • Like MapReduce – leave details of distribution etc. out 10/22/2006 LCSD'06  37

Slide 38: SAGA: Scope • Is: –  Simple API for Grid­Aware Applications •  Deal with distributed infrastructure explicitly – High­level (= application­level) abstraction – An uniform interface to different middleware(s) – Client­side software • Is NOT: – Middleware – A service management interface! – Does not hide the resources ­ remote files, job (but  the details)    

Slide 39: SAGA API: Towards a Standard • The need for a standard programming interface – “Go it alone” versus “Community” model  –  Reinventing the wheel again, yet again, and again –  MPI as a useful analogy of community standard – OGF the natural choice; establish SAGA­RG •  “Tedium” of the standardisation process? – Not all technology needs to be standardised upfront  – Standardisation not a guarantee to success • Requirements Document  –  Quick skim through the Requirements document re –  Design and requirements derived from 23 Use Cases –  Different projects, applications and functionality    

Slide 40: The SAGA Landscape    

Slide 41: SAGA  C++ (LSU)

Slide 42: Implementation ­ Requirements • Non­trivial set of requirements: – Allow heterogenous middleware to co­exist – Cope with evolving grid environments; dyn resources – Future SAGA API extensions  – Portable, syntactically and semantically platform  independent; permit latency hiding mechanisms – Ease of deployment, configuration, multiple­language  support, documentation etc. – Provide synchronous, asynchronous & task versions  Portability, modularity, flexibility, adaptabilty, extensibility 10/22/2006 LCSD'06  42

Slide 43: Job Submission API 01: // Submitting a simple job and wait for completition 02: // 03: saga::job_description jobdef; 04: jobdef.set_attribute ("Executable", "job.sh"); 05: 06: saga::job_service js; 07: saga::job job = js.create_job ("remote.host.net", jobdef); 08: 09: job.run(); 10: 11: while( job.get_state() == saga::job::Running ) 12: { 13: std::cout << “ Job running with ID: “ 14: << job.get_attribute(“ JobID” ) << std::endl; 15: sleep(1); 16: }    

Slide 44: SAGA Landscape    

Slide 45:  GridSAT  First Principles Grid Application • Grid implementation  of the  satisfiability problem: To  determine if the variables of  given Boolean formula can  be assigned such as to  make it TRUE.  • Adaptive: computation to  communication ratio  need/can be adjustable (!) • Allows new domain science –  beats zChaff (time taken  and problem) Adapted from slides by Wolski & Chakrab    

Slide 46: GridSAT Characteristics • Parallel, distributed SAT solver – Both CPU and Memory Intensive – Splitting leads to better performance – Allows sharing: clause learned in solver shared • Grid Aware Application: – Heterogenous (single, clusters & supercomputers) – Dynamical Resource Usage • Unpredictable runtime behaviour –  How much time? How many resources? When  to split? Which process splits first? – Problems vary: easy to hard, short to long – Need to be adaptive, “add resources as you go”    

Slide 47: GridSAT: Programming Requirements • RPC, Dynamic resource & Job   Error Handling, scheduling and  management checkpointing SAGA provides the required programming functionality, at the  correct level of abstraction and thus makes it easier to   manage, deploy and extend (for new functionality) GridSAT    

Slide 48: Legacy Application: Replica Exchange • “Class of algorithm” used for bio­ molecular simulations • e.g.,  Protein (mis­) folding • Primarily used for  •  Enhanced sampling •  Determine transition rates • Task Level Parallelism  – Embarrassingly distributable!    

Slide 49: Replica Exchange Algorithm • Create replicas of initial  R1 configuration • Spawn 'N' replicas over  R2 different machine R3 • Run for time t RN • Attempt configuration  swap of   Ri  <­> Rj • Run for further time t hot • ... T • Repeat till termination     t Exchange  attempts 300K t

Slide 50: RE: Programming Requirements  RE can be implemented using following “primitives” • Read job description – # of processors, replicas, determine resources • Submit jobs – Move files, job launch • Access simulation data & analysis • Checkpoint and re­launch simulations – Exchange, RPC (to swap or not)  Implement above using “grid primitives” provided by SAGA   Separated “distributed” logic from “simulation” logic  Independent of underlying code/engine  Science kernel is independent of details of distributed  resource management    Desktop akin to High­end supercomputer!!    

Slide 51: Programming Distributed  Applications    Parallel Programming Analogy  Status of distributed programming today, (somewhat) similar  to parallel programming pre­MPI days  MPI was a “success” in that it helped many new applications –  MPI was simple –  MPI was a standard (stable and portable code!) • SAGA is to the grid application developer, what MPI is to the  parallel program developer  (“grid­primitives”) • SAGA conception & trajectory similar to MPI –  SAGA is simple to use – OGF specification; on path to becoming a standard   •Therefore, SAGA's Measure(s) of success:    •  Does SAGA enable “new” grid applications?   

Slide 52: Outline • Scientific Grid Applications  • Computing Free Energies in Biological Systems –  STIMD (2003­04), SPICE (2005­06) • Challenges of Distributed Environments  • HARC: A tool for co­allocating resources – GENIUS: Grid­Enabled Neurosurgical Imaging Using  Simulations (2007­08) • Simple API for Grid Applications (SAGA) • Regional CI Example: LONI (Now part of TeraGrid!) • Hardware: Compute + Network  • Software: Cactus, HARC, Petashare, SAGA...  • People: LONI Institute and NSF Cybertools • Novel e­Science Applications 52

Slide 53: 3 Axes: ­ LONI ­ CyberTools ­ LONI Institute ~ 100TF IBM, Dell  LA Tech Supercomputers National Lambda Rail LSU SUBR UNO UL­L Tulane

Slide 54: Cybertools: Providing Application Software     

Slide 55: Cybertools (2) WP4: Core Package!    

Slide 56: Integrating Applications into a Cyberenvironment    

Slide 57: 57

Slide 58: • Goal: Enable underlying infrastructure to manage the  low­level data handling issues.  • Novel approach: treat data storage resources and the  tasks related to data access as first class entities just like  computational resources and compute tasks. • Key technologies being developed: data­aware storage  systems, data­aware schedulers (i.e. Stork), and cross­ domain meta­data scheme.  • PetaShare exploits 40 Gb/sec LONI connections  between 5 LA Universities : LSU, LaTech, Tulane, ULL &  UNO Cybertools: Not just compute! PI: Tevfik Kosar (CCT/LSU)    

Slide 59: Participating institutions in the PetaShare project, connected through LONI. Sample research of the participating researchers pictured (i.e. biomechanics by Kodiyalam & Wischusen, tangible interaction by Ullmer, coastal studies by Walker, and molecular biology by Bishop). High Energy Physics Biomedical Data Mining LaTech Coastal Modeling Petroleum Engineering LSU Computational Fluid Dynamics Synchrotron X-ray Microtomography UNO Biophysics ULL Tulane Geology Molecular Biology Petroleum Engineering Computational Cardiac Electrophysiology    

Slide 60: LONI Institute  • Build on LONI infrastructure, create bold new inter­ university superstructure – New faculty, staff, students;  train others.  Focus on CS, Bio,  Materials, but all disciplines impacted – Promote collaborative research at interfaces for innovation – Much stronger recruiting opportunities for all institutions • Two new faculty at each institution (12 total) – Six each in CS, Comp. Bio/Materials with half PKSFI matching;   fully covered after five years • Six Computational Scientists – Support 70­90 projects over five years; lead to external funding • Graduate students – 36 new students funded, trained; two years each

Slide 61: Applications: Where it all comes together... 61

Slide 62: Resource Performance Monitoring Application • NWS, BQP – only 1 resource at a time!!  • jfdja; • How to choose M resources out of N ?   e.g. MPICH­G2 Application, which M • Cactus + SAGA + LONI (Lightpaths) 62 CENTER FOR COMPUTATION & TECHNOLOGY AT LOUISIANA STATE UNIVERSITY

Slide 63: 63

Slide 64: 64 CENTER FOR COMPUTATION & TECHNOLOGY AT LOUISIANA STATE UNIVERSITY

Slide 65: Acknowledegments: The SAGA Team Hartmut Kaiser Thilo Kielmann Andre Merzky Ceriel Jacobs Ole Weidner Kees Verstop

Slide 66: Acknowledgements • HARC: Jon Maclaren, LSU  • GENIUS: Peter Coveney and Steve Manos, UCL • PetaShare: Tevfik Kosar  • Students & Research Staff @ CCT  • LONI Staff • Funding Agencies: NSF, EPSRC (UK), LA BoR 66 CENTER FOR COMPUTATION & TECHNOLOGY AT LOUISIANA STATE UNIVERSITY

Slide 67: Conference Announcement • MardiGras Conference 2008:  “Novel Distributed  Computing Applications and Technology”  –  http://mardigrasconference.org • Dan Katz (Chair) & Shantenu Jha (co­Chair)  • Craig Lee (PC Chair), Geoffrey Fox (Vice­Chair,  Emerging Technologies), Bill St. Arnaud (Vice  Chair, Network­Instensive Applications), Matei  Ripeanu (UBC) Publicity  • Oct 31 Paper Submission Deadline • Peer reviewed proceedings  to be published in  ACM library (ISBN I978­1­59593­835­0) 67