A Proposal for the Next Generation of HPCC Software

1: Where we are today Strategically

1.1: Important Concepts

• Ideas from HPCC research Good!
• Not enough people/funding in field to implement robust production systems
• Must re-use as much software (including infrastructure software) as possible
• Similarly must build HPCC software in a modular fashion with small enough modules that smallish groups can build effectively
• Different modules are likely to use different base technologies (Fortran v Java v C++ etc.) and so interoperability essential!
• No silver bullet on the horizon - maybe pessimistic but implies better HPCC environments implies better implementations of existing ideas.
• Need to support both production use of MPP's and "rapid prototyping" in development of new applications - latter is not well supported by current HPCC software systems even though need parallel support for prototyping of new 3D simulations

1.2 Some Technical Trends

• PC and workstation clusters are of growing important and this typically distributed memory people's technology is contrasted with distributed shared memory tightly coupled MPP's.
• Computational science moving to multidisciplinary (multi-component) applications
• Corresponding growing use of databases (for data-intensive applications)
• Interoperability between disparate heterogeneous platforms, support of multidisciplinary applications, and metacomputing are three related important areas
• "full metacomputing" (decompose general problem on general networked resources) may not be relevant
• The Web is delivering a new operating environment (WebWindows) and a rich distributed computing software infrastructure with especially excellent support for software integration
• There is a need for a new scalable technical operating system (NT v UNIX v WebWindows)

2: Statement of HPCC Software Problem

2.1: General Issues

• We should distinguish decomposition (into parts) and integration (of parts together). Integration called coordination and decomposition is called creation in volume 1.
• Decomposition is technically hardest but probably most software is devoted to integration and latter is where Web can help.
• Relevance of different computer architectures
• Why one needs many interoperable approaches and there is no single solution

2.2: Classes of Parallelism

• Data parallel, Event driven simulation, functional parallelism, Coarse grain metaproblems ……
• Loosely Synchronous, Synchronous, Regular, Irregular

2.3: Approaches to Decomposition

• Three important data parallel paradigms: compiler (e.g. HPF), SPMD (libraries such as DAGH, SCALAPACK), message passing (MPI)
• Threads for latency hiding and functional parallelism (as in Web servers and clients). Are these "just" an implementation strategy which help in load balancing (especially of asynchronous embarrassingly parallel problems) or a fundamental approach to data parallelism.
• Need to overrule system scheduling of processes and threads in SMP's for loosely synchronous problems
• Role of Adaptive Irregular Problems

2.4: Approaches to Integration

• From MPI to Web technologies
• Microscopic and Macroscopic integration and application requirements

2.5: Tools

• Performance Visualization, Load Balancing, Debugging, Data visualization, Performance analysis and prediction

3: Some Examples and Lessons

3.1: Computational Fluid Dynamics

PDE

3.2: Binary Black Hole Grand Challenge

PDE with many linked components, DAGH v HPF

3.3: Financial Modeling

MonteCarlo

3.4: (Some) Computational Chemistry

Focus on matrix based problems - discuss PNL NWCHEM

3.5: Manufacturing and Design

Multiphysics Metaproblems

4: Some Relevant Characteristics of Web Technologies

4.1: WebWindows

4.2: Java and JavaScript

4.3: VRML2

4.4: Web linked Databases

4.5: Agents and Robots

4.6: Java/Web for Computational Science and Engineering

• User Interfaces
• Collaborative Integration with Java Servers
• Compiled and Interpreted Java for "computational kernels"

5: The Proposed General Framework of Problem Solving Environment

5.1: System Architecture

• 4 level diagram (interpreted, semi-interpreted, compiled, machine specific runtime)
• Relation between system and user view

5.2: Function of 4 PSE Levels

• Interpreters
• Client side services (Java Applets)
• Compiled high level or SPMD code
• Runtime

5.3: Interlevel Operation Issues

• MPI2 at lower level and Web at high level and multiplexing between these
• Interoperability of compiled and interpreted levels

6: The lowest Runtime Level

6.1: General Issues

• Use by several higher levels; Interoperability
• Native Java classes interfacing to C and Fortran versus pure Java solutions

6.2: Examples

• MPI Messaging
• DAGH adaptive mesh
• CLIC adaptive mesh with domain decomposition
• COCOLIB multidisciplinary integration
• SPRINT and other load balancing systems
• CHACO Grid partitioning
• SCALAPACK matrix problems
• Grid Generation (?)
• PCRC Compiler runtime
• NWCHEM (Global Arrays)

7: Compilers

7.1: General Issues

• Convenience of single line interpreters versus performance of whole program compilation
• Metacomputing support at compiled level?

7.2: Memory Management

• Distributed Shared Memory
• Multilevel Memory

7.3: Adaptivity

• CHAOS support - inspector, executor
• Non array data structures; pointers

7.4: Parallel Java

• HPF like approaches
• Shared memory (Indiana JAVAR)
• Java as Interpreted front end to parallel computing in any paradigm

8: Integration SubSystem

8.1: General Issues and Examples

• Multi-science and multi-language linkage of already decomposed data
• AVS style image processing with decomposition of function not data

8.2: Java Server for Integration

• Custom v HTTP v Jigsaw v Jeeves Servers
• Servlets

8.3: Services in Computational and Other Domains

• Computing
• Collaboration
• Database
• Visualization including CAVE and specialized devices

9: User View

9.1 Graphical User Interface

• Java and JavaScript Interfaces
• WebFlow
• Data and Performance Visualization
• Client side Collaboration Services

9.2: Java Wrapper Interfaces

9.3: Java(Script) Interpreter

9.4: JDBC (Java Database Connectivity)

Link to user oriented resource database