John Rice's Introduction **************************

1. John Rice on PSE Examples
   1. *Text Processing -- compare Word, Troff or Tex
   2. *CAD Systems hide NASTRAN
   3. *MATLAB -- Underlying software in fact available to everybody
      1. -Gave nice language ala 1070's and support
      2. -language like mathematica
2. PDELab as an example
   1. *Large scope as collected 20 different solvers -- much more than other systems
   2. *Interesting script with mathematics notation
   3. *invokes decomposers for parallel partitioining
   4. *Developed specialized bioseparation environment
   5. *user interface models lab environment
3. History of PSE
   1. *Started in 1963 but abandonned as not enough computing power
   2. *Now technology allows
   3. *What about Kiowa and other histogramming packages
4. Software/Language
   1. *Define problem to be solved
   2. *PSE specific computational script
      1. -What is a script! John Rice agrees this is not defined
      2. -Not just an Interpreted Language
   3. *System Components
      1. -Control Program
      2. -Problem Specific Modules
      3. -Runtime Support Systems
      4. -Utilities
   4. *Analyses MATLAB and PDELAB in these terms
   5. *May not need one program that knows whats going on globally!
5. Parallelism
   1. *A focus of this workshop
   2. *Extreme solution is to develop optimal code with software tailored to exploit all possible optimizations
      1. -Possible as PSE typically generates code
   3. *Minimize user time not computer time
6. Questions
   1. *What about open architectues?
   2. *Mixed feelings as "open-ness" not used.
   3. *Claims developers will build software - not users
   4. *PSE's are general field but money comes from PDE parts of Arpa,NSF
   5. *What is a script! Not asked

Begin New Set ************************ purdups2

1. Lennart Johnsson's Panel
   1. Application Specific PSE's
2. Introduction
   1. *VanRosendale not here
   2. *Panel is Numerical Methods/Parallelism background
   3. *CATIA is an example PSE
   4. *Note finite element businesses are very proprietary and not open
      1. -ABACUS is open and this helps their success?
   5. *Can you build a business case for PSE's
3. L Johnsson -- Contd I
   1. *Why are many PSE's not out there?
      1. -Is it just that hardware only just becoming available?
   2. *Is Scalability important?
   3. *What are enabling technologies
   4. *What about testing and validation?
   5. *Is nature of required PSE's too multidisciplinary for academics?
4. L Johnsson -- Contd II
   1. *Who are users?
      1. -Note CATIA set up for use by teams
   2. *What should academia do
      1. -Set up standards
      2. -build prototypes, components
      3. -establish test and validation cases and procedure
5. Randall Bramley
   1. *Talked to users of (Mathworks) tools in research and teaching
   2. *PSE must allow user to intervene
      1. -at all levels of PSE
      2. -Monolithic systems not good
   3. *PSE's must be OPEN
   4. *Symbolic manipulation leads to unreadable unmodifiable sometimes inefficient code
6. Randall Bramley II
   1. *Users complain PSE's can't solve large problems
   2. *More efficient standard interfaces between PSE's
      1. -Microsoft OLE
   3. *Let users build their own application specific PSE's in terms of Meta-PSE systems
7. Gallopoulos from Illinois
   1. *Quicken and Tax Programs are well known PSE's
   2. *PSE's should use language of user domain
   3. *Compiler is a problem solving environment?
      1. -Yes as say HPF is specialized in terms of supported data structures
   4. *Illinois building MATLAB to F90 compiler
8. Marinescu from Purdue on PSE for Structural Biology
   1. *10-15 such groups nationwide
   2. *Commercial use down the road
   3. *Both computer science and biology issues
   4. *Likes adaptive algorithms which are self scheduling and make use of whatever machines are available.
   5. *Has system called Bond which is intelligent shell hiding details from user
   6. *Socrates is a spreadsheet like GUI to define problem
9. Questions to Panel I
   1. *Sherman(SCA) agrees that CORBA is not suitable for parallel implementations
   2. *Sewell agrees users want to modify code produced by PSE's -- Protran from IMSL (Sewell's work) used to produce unreadable code. *Build application specific PSE on top of general purpose PSE
10. Questions to Panel II
    1. *Analogy to specialized versus general purpose hardware
    2. *Can't start from scratch!
    3. *Sherman: must be able to certify code -- can't modify code used in real world so open-ness can be a liability
    4. *Are there two markets?
       1. -Engineering -- can't modify
       2. -Research -- must be able to modify
       3. -Also Users versus Developers
    5. *Note MATLAB and Maple combined succesfully!
11. Questions to Panel III
    1. *Boeing trying to get more and more software from the outside except in aeronautics
    2. *Boeing interested in PSE and agrees on legal issues brought up by Sherman
    3. *Academia can only help set standards as in most cases industry is solving real and much larger problems
    4. *Should tools for developing PSE's be in public domain?
       1. -Certainly should be available but Lennart is worried about standard problem that no incentive for commercial activities
    5. *John Rice agrees that PSE's need commercial support!
    6. *MATLAB contrated with ? to produce sparse MATLAB. ? is NAG?

Begin New Set ************************ purdups3

1. PDEease
   1. Robert Nelson
   2. A commercial System
   3. Currently only available in 2D
   4. Written in PASCAL
2. PDEase2 -- I
   1. *Only iterative solvers as aimed at PC's
   2. *Accepts a script from user specifying problem and desired output
   3. *Descriptor files define TITLE, EQUATIONS etc
   4. *Simple language to specify geometry
   5. *Generates adaptive irregular finite element meshes
3. PDEase2 -- II
   1. *Doing groundwater simulations for Livermore
   2. *Has ascii text way of specifying equations using curl dt del2 etc.
   3. *can solve eigenvalue problems
   4. *Cost $600 for a PC
   5. *Company is SPDE 510-862-0644 founded in 1991
   6. *Many 2 man years work and 40,000 lines in PDEase2
4. PDEase2 -- III
   1. *Uses linked lists as datastructures
   2. *Switching to C as more portable than Pascal
   3. *current PC's are so powerful, could reconsider emphasis on iterative solvers
   4. *Note have own Conjuagate Gradient, Lanczos solvers(non symmetric) internally written in Pascal for linked list
5. Questions from Audience - I
   1. *Skjellum mentions CMU NSF center which develope chemical engineering PSE's with object oriented design with applicative language*Industry very reluctant to change anything -- including changing to adaptive meshes
   2. *Nelson wrote all of it.Of course built on existing software
6. Questions from Audience - II
   1. *What is marketplace? Just through it out!
   2. *Macsyma Inc handles marketing and first level support
   3. *Not clear if anybody is making money from PDE PSE's
   4. *SPDC not making money
   5. *Set price low to create market!
   6. *There is $100 student version and a swedish professor has written a physics textbook to go with it
7. Questions from Audience -- III
   1. *Claim need to focus on specific market segments e.g. add a chemical engineering wrapper
      1. -General PDE solver has no market!
      2. -Can one compete with special purpose packages from particular field which ought to be more efficient and have precise software n
   Questions from Audience -- IV
   1. *Why don't we set up a Web Site which solves PDE's on demand!Nelson is interested
   2. *Note can build a nice educational resource on the web based on swedish textbook comined with PDEase!

Begin New Set ************************ purdups4

1. User Interfaces for PSE's
   1. Elias Houstis
   2. Granville Sewell El Paso
   3. Robert Nelson LLNL/SPDC
   4. Candrajit Bajaj Purdue
2. Houstis Presentation
   1. *Scalability -- too many grid points to display
   2. *and in aerospace design, have 300,000 parameters for 10,000 programs
      1. -One user can't set all these
      2. -AI system to help
   3. *Computational servers as new library model
   4. *Softlab project develops virtual laboratory for two Purdue projects.
   5. *SciencePad -- Laboratory Notebook built on top of web browser
3. Bajaj Presentation
   1. *Working on Visible Human Project
   2. *Has his own environment SHASTRA
   3. *Used to design Prosthesis
   4. *Problem Solving in the large to support collaboration between groups of experts
4. PDE2D Sewell
   1. *PDE2D based on Protran
      1. -IMSL abandoned Protran
   2. *Protran was script based and translated into Fortran
   3. *PDE2D has an interactive Interface and skips script -- it generates readable Fortran
      1. -Interface is ascii question and answer -- not GUI
   4. *This Fortran repeats comments so code is self documenting -- Interesting
5. Graphical versus Scripting Interfaces
   1. *Visual C++ puts everything into icons -- Nelson considers this as a disaster
      1. -GUI should give you a menu access to complex set of scientific concepts
   2. *Thompson noted scripted Eagle grid generation system was not popular in Industry as they needed a GUI even though Eagle more fun
      -MSU built GUI on top of scripting system to make Eagle more acceptable
   3. *Purdue uses C++ and VX(?)
6. Questions from the audience - I
   1. *Do you need AI based reasoning techniques to customize interfaces for each different group of users?
   2. *PDE's have too many parameters to display all options
      1. -Need to arrange into subsets
   3. *What is Idiom that describes PSE environment that best represents scientific problem solving?
7. Questions from the Audience-- II
   1. *Sincovec notes that real problems require data from around the world -- advocates WebWork!
   2. *Require multiple cooperating laboratories
   3. *Need support for comparing computations with experimental results
      1. -So easy to go wrong as no guaranteed correct solution scheme for most real PDE's
      2. -Thompson says we have ethical need to make certain PSE's give reliable results
8. Questions from the
9. Audience-- III
   1. *Sherman says people seem to claim that all too specialized and so no viable commercial business plan
   2. *Thompson and Sherman say should hide grid -- this is a artifact and not the physical problem

Begin New Set ************************ purdups5

1. Enabling Technologies for PSE's
   1. Ron Boisvert NIST (from Purdue)
   2. Faisal Saied Illinois
   3. Paul Wang Kent State
   4. Sanjiva Weerawarana Purdue
2. Introduction
   1. *Wang came from Macsyma project at MIT
   2. *Weerawarana just got PhD from Purdue
   3. *Enabling Technologies are techniques and tools which provide infrastructure for building PSE's
   4. *One person's tool is another person's application!
3. Boisvert Presentation -I
   1. *Components include:
      1. -Integration
      2. -Domain Expertise or domain specific subsystems
      3. -User Interface
   2. *Enablers exist at different levels
      1. -Conceptual
      2. -Arcitectural
      3. -Procedural -- the actual implementation tools
4. Boisvert Presentation II
   1. *ELLPACK used
      1. -Linpack ITPACK etc
      2. -Macro-processor and compiler-compiler -- both built especially for LINPACK
   2. *What are most promising software archiectures for building PSE's?
5. Saied Presentation -- I
   1. *MGLab is a set of Matlab functions that define an interactive multigrid solver environment
      1. -generate results in Matlab's sparse matrix format
      2. -Use Matlab visualization capabilities
      3. -Design your own V cycle and choose smoother etc.
6. Saied Presentation -- II
   1. *Matlab has high level language, simple library interface, sparse matrix , visualization and GUI development support
   2. *Missing is 3D arrays, geometry and certain classes of algorithms
   3. *but is extensible with symbolic, neural net, ODE, optimization, image processing toolkits.
   4. *need visual programming voice natural language interfaces
7. Saied Presentation -- III
   1. *need computational geometry
      1. -solid modeling, mesh generation and adaptive mesh refinement
   2. *scalable software libraries for important algorithms
      1. -including automatic diffentiation
      2. -THIS is in good shape!
   3. *information technology
      1. -look up solution!
   4. *One person's PSE is another one's PSE enabler
      1. -eg Saied used MATLAB as enabler of MGlab
8. Wang Presentation -- Issues I
   1. *User Interface
   2. *Kernel
   3. *Domain Knowledge (data)base or expert
   4. *Compute Servers -- Symbolic Numeric Graphics AI Database
   5. *Help and Documentation
   6. *Utilities -- Debugging and Performance Tuning
9. Wang Presentation -- Issues II
   1. *Collection of Solution Procedures
      1. -parallel algorithms
   2. *Aids for Analysing problems
      1. -identify approach
   3. *Aid for preparing problem specific codes
      1. -generate and later modify codes for complex target machines
   4. *Parallel and Distributed Computing Implementation
10. Wang Presentation -- Needs
    1. *Need flexible reusable numeric system and libraries
    2. *reliable efficient symbolic server
    3. *Expert knowledge based systems
    4. *Connection Interface mechanism
    5. *Parallel and Distributed operating Environments
    6. *Automatic and User Assisted code genearation
       1. -especially for parallel systems
11. Wang Presentation -- Exchange Issues
    1. *Need to agree on interface between tools
       1. -routine interface, control mechanisms, dataflow protocol
    2. *Scientific data exchange protocols -- exchange formulae, different precision and number number types
       1. -OPEN MATH
       2. -Mathlink -- mathematica
       3. -Iris -- Maple
       4. -MPI -- Message Passing
12. Wang Presentation -- His Ideas MP
    1. *Continues discussion of data exchange protocol
    2. *MP(MultiProtocol) -- ICM/Kent which is glue between different forms of math data and uses "binary encoded parse trees" and sits
    Wang Presentation -- Code Generation
    1. *Capture Parallelism at high level before you lose information by coding in C Fortran etc.
    2. *FINGER is finite element code generator
    3. *PIER is parallel FEM system
13. Wang Presentation -- Summary
    1. *Need to be object oriented
    2. *PSE frameworks
       1. -these seem to be templates
    3. *PSE standards for data exchange
    4. *PSE user interface standards
14. Weerawarana -- Overview
    1. *GUI requires many person years! -- Interesting
    2. *Claims languages are a complex issue but not obvious why
15. Weerawarana -- Needs
    1. *Portable GUI Tools
    2. *OLE OpenDoc CORBA
    3. *ILU Polylith Glish IDL Software component integration using software bus or other models
    4. *Object Oriented is natural as PSE's describe specific objects
    5. *Embeddable (in existing C program) scripting languages such as Perl TCL
    6. *Excutable content and Web Based PSE's -- Java Python
16. Weerawarana -- PSE Kernels
    1. *Key things needed in building PSE's -- middleware
       1. -from GUI, data management to scripting environment
    2. *Purdue PSE kernel implements this
       1. -Notebook -- missed item here!
       2. -Software bus
       3. -Utilities
       4. -C++ and Web versions exist
    3. *Java should not be used for applications but to invoke existing code in conventional languages

Begin New Set ************************ purdups6

1. Scalable Libraries
   1. Jim Demmel
   2. Berkeley
2. Demmel Introduction
   1. *They are building Castle which seems to be Berkeley's private system?
      1. -Unclear how relates to industry standards
   2. *Unreasonable number of acceses to netlib -- why so large?
      1. ->100 accesses per day for major packages such as CLAPACK (C version) and PVM
      2. -Surely number of actual users of say PVM averages at about 1-5 per day (thousand users is one per day for 3 years)
   3. *LAPACK is 800,000 lines of code
      1. -C version is one million lines of code and got by automatic conversion
      2. -no object oriented techniques
3. Demmel -- (SCA)LAPACK
   1. *New Sparse LU is 16 times faster than Matlab version -- GP
   2. *Duff's UMFPACK2 is similar performance on Sparse LU
   3. *SCALAPACK uses 2D block cyclic as best general decomposition except for nonsymmetric matrices
   4. *Have performance models for everything
   5. *Divide and conquer methods for eigenvector/eigenvalue determination
      1. -Ultimate methods! Problem is finished .....
   6. *Holy Grail for eigenvector determination copes with close and degenerate eigenvalues
4. Who uses Numerical Software
   1. *Engineers and Scientists
   2. *HPCC community
   3. *Education
   4. *Each set of users has different tradeoffs
   5. *Redoing Templates with greater attention to helping user choose correct method
      1. -focused on eigenvalues/vectors
      2. -PETsc is a nice language
   6. *see http:/www.cs.berkeley.edu/~demmel
      1. -nline courses in Parallel Computing and Numerical Linear Algebra
5. MultiPol-Kathy Yelick
   1. *Examine set of irregular problems including
      1. -Circuit Simulators
      2. -Irregular CFD
   2. *Abstract set of Irregular data structures
      1. -Just released
      2. -includes Fast Multipoles etc.
   3. *which have been implemented on top of active messages

Begin New Set ************************ purdups7

1. Virtual Parallel Languages and Environments
   1. Geoffrey Fox NPAC
   2. Andrew Sherman SCA
   3. Cal Rbbens Virginia Tech
   4. Manish Parashar Texas
2. Sherman SCA -I
   1. *Agrees with my analysis and goals with different technology
   2. *Virtual Shared Memory very good for PSE
   3. *Store data so greater than one process can examine at same time -- enables computational steering and monitoring simultaneously
   Sherman SCA -II
   1. *Khoros-Paradise System for Navy -- Khoros natural as Navy interested in signal processing
   2. *Paradise replaces transport mechanism in Khoros and you have virtual shared memory -- not file -- between modules
   3. *Piranha does scheduling of different modules including replication of the different stateless(often true) Khoros modules
   4. *This enables parallel Khoros
3. Parashar -- Black Hole
   1. *Process involved complex cycle between CS and application scientists to identify requirements
   2. *Merged multipole, black hole and FEM technologies
   3. *DAGH Technologies for parallel adaptive hierarchical AMR implemented in C++
   4. *Has shadow grid hierarchy for on the fly error estimaion
   5. *Good performance compared to hand coded software
   6. *C++ driver calls Fortran routines in coarse grain model
4. Ribbens
   1. *Was in ELLPACK project at Purdue -- a user not developer of languages
   2. *Works with engineers at Virginia Tech
   3. *There is no holy grail language or paradigm
   4. *Some sacrifice in raw performance possible
   5. *MDO codes need shell scripts/wrappers
5. Ribbens
   1. *Compares with Pasadena1 workshop
      1. -likes HPF and MPI forum process
      2. -Not clear if good progress in tools
      3. -What about process of building "advanced prototype"
   2. *Is there a PSE forum -- is problem well defined
   3. *Sems to agree Web is a reasonable starting point
   4. *Agrees that AVS is a good model and in general visual programming environment
   5. *What is a VPE (Virtual Parallel Environment)
   6. *How important/useful is:
      1. -visual programming
      2. -shared address space
      3. -a template
      4. -existing code re-use -- one trusts existing code!
6. Questions from Audience -- I
   1. *Why shared memory in Sherman's example
      1. -User sees conventional Khoros
      2. -Systems uses shared memory
   2. *Ribbens says shared memory supports incrementalism
   3. *Only developers or expert users will address closely coupled applications
   4. *Skjellum -- Java linked to MPI -- abandon PERL
7. Questions from Audience -- II
   1. *Do we agree on division between coarse grain and fine grain parallelism
   2. *AVS/Khoros checks if modules should be connected
   3. *Is set of modules the correct model!
      1. -Smith says no -- do top down -- he seems to be very puristic as current modules "artificial" -- I don't agree!
      2. -rather mix top down and bottom up approaches
   4. *PDE's solvers are clearly used cf. NASTRAN but PSE"S are not taking world by storm
   5. *Typical discussion of interdisciplinary research with industry, computer science -- application interaction, computational scien

Begin New Set ************************ purdups8

1. Architecture of Scalable Libraries
   1. Michael Hearn Illinois
2. Hearn Presentation -- Questions
   1. *Usability -- Must Hide Complexity
   2. *Software Development costs time ...
      1. -Immature Computing Environment
      2. -Moving Targets
      3. -Lack of standards
      4. -Complexity
   3. *Portability
      1. -No standard or dominant parallel architecture
      2. -Programming Investment not protected
3. Hearn -- Answers to problems
   1. -more BLAS?
   2. -Object Oriented?
   3. -PSE's ?
4. Grimes -- Background
   1. *Manages Mathematical software group in Boeing
   2. *Hired by Sinjovec while he was at Boeing
   3. *BCSLIB is Boeing's IMSL
   4. *Supports sparse matrix library at Boeing
5. Grimes -- Why is Library/PSE succesful
   1. *Solves a problem that somebody wants
   2. *Useful Interfaces
   3. *Transportable -- must run on 10 platforms from mainframe to many types of WS/PC's
   4. *Affordable sustaining costs
   5. *Can be extended/modified easily
   6. *efficient
   7. *solves as big a problem as possible
6. Sinjovec
   1. *Scalable libraries are building blocks
   2. *Multimedia Interface
   3. *Geographically distributed
   4. *Likes WWW and suggests need software tools to exploit
   5. *Paradigm shift from homogeneous MPP to metacomputing
   6. *PSE is everything available on network
7. Sinjovec
8. Object-Oriented Approach
   1. *Abstract Data types(ADT)
      1. -ADA Modula2 find programs easier to write/re-use
   2. *Interfaces are independent of implementation whereas
      1. -subroutine libraries require user to understand data structures and algorithms
   3. *Parallel Programming
      1. -encapsulate parallelism in coarse grain objects
9. Sinjovec Briefing I
   1. *Has example of ADA to Fortran linking where needed to use packages to hide Fortran data structures
   2. *Standards for parallel objects are needed
      1. -HPF has started this
   3. *Tools that enhance re-use such as CORBA/OLE are needded but these are sequential
10. Sinjovec Briefing II
    1. *Interested in secure repositories -- don't keep bringing software over net
       1. -compute servers
    2. *Is an ADA fan
    3. *Has a set of language object oriented features
    4. *need heirarchy of object-oriented abstractions -- ADT's
11. Skjellum Briefing
    1. *Skjellum agrees with Sinjovec
       1. -Software engineering should be studied and used
    2. *Standard components are not used now!
    3. *Inheritance is a limited value
    4. *hierarchies produce inefficiences as a lot of copying
12. Questions from the Audience--I
    1. *Hearn -- can one achieve these wonderful software engineering goals?
    2. *Abstraction can lead to higher performance (as allows optimal implementation) or lower performance if too much copying
    3. *Must make libraries allow any decomposition
    4. *Can one cope with changing decompositions between library components
    5. *Don't answer question if realistic to implement!
13. Questions from the Audience - II
    1. *PBLAS attacked as incomplete by Johnsson and Skjellum
       1. -Need multiple simultaneous problems
       2. -separate operations and data/data layout
    2. *Smith has an approach that seems inconsistent with HPF and does not accept people with a different approach.
    3. *Grimes and Smith use C plus MPI as only transportable solution
14. Questions from the Audience -III
    1. *Skjellum does not believe in HPF - says C++ will dominate
    2. *Demmel is concerned about portability of numbers between different platforms
       1. -algorithms need to be robust in this area!
       2. -Hearn notes that no two computers agree on the time
    3. *Rice notes no correctness proof is realistic in any real problem

Begin New Set ************************ purdups9

1. Characteristics and Components of PDE Libraries
   1. John Rice Purdue
   2. Jim Demmel UCB Math/CS
   3. Ashok Singhal CFDRC
   4. Lutz Grosz Karlsruhe
   5. William Mitchell NIST(ex Purdue)
2. John Rice Presentation
   1. *Numerical Methods
   2. *Symbolic Methods
   3. *Geometry -- MUCH THE MOST IMPORTANT
      1. -Specify and Discretize
      2. -Computational Geometry is part of CS theory community and not very useful here!
      3. -Thompson says Geometry not glamorous
   4. *Visualization and Assessment
   5. *ELLPACK has 60 components at user level
   6. *Need good interfaces and transformers(wrappers)
3. Rice -- Classification of PDE's
   1. *eg elliptic, Navier-Stokes
   2. *Properties: eg singular, boundary layer
   3. *Type of Solution: Fine/Coarse mesh
   4. *How do you find this out?
      1. -Hard to get details which are critical, correct!
4. Mitchell Presentation
   1. *Has hierarchical picture of PDE library organization
      1. -Solvers(FD,FEM..), Data structures, Problem specification(boundaries) etc.
   2. *Interfaces: Object-Oriented, Data structures, Procedures, Parameters
      1. -Should these be consistent
5. Singhal Presentation - I
   1. *Developing VCE -- Visual Computing Environment for MDO
   2. *His colleague is computer scientist
   3. *increasing employment
   4. *Real-world engineering specification is 3D complex geometries, multiple length scales, multidisciplinary
   5. *Multi-Site Multi-developer model for software production.
6. Singhal Presentation - II
   1. *Doing coarse grain prototyping
   2. *VCE looks very similar to AVS
   3. *Working with Lewis Industry collaboration on VCE2
   4. *Differential equations
   5. *Integro-Differential Equations
   6. *Numeriacl Stiffness
   7. *Physical models such as for turbulence
7. Lutz Grosz Presentation
   1. *Solver is core of PDE PSE
   2. *Must characterize both solver and problem and then match
   3. *analyse what a user would do
   4. *reduce to canonical form and "look up" as function of parameters
      1. -break up into sub PDE's
      2. -Do this by trial and error running of codes with different parameter values
8. Demmel Presentation
   1. *Describes EOSDIS climate ocean model
   2. *EOSDIS -- 6 petabytes by year 2000
   3. *Extending SQL to handle huge databases associated with simulations
      1. -for instance, extract data at arbitary resolution
   4. *specify planckton pieces
   5. *Hughes prime contractor
   6. *2 central resources and a set of smaller focused repositories
   7. *keep lineage (where it came from)
9. Questions from the audience - I
   1. *Any decision on object oriented methods is a compromise which depends on status of compilers
      1. -Can't put lowest level abstractions with overloaded + and - operators as inefficient
   2. *ELLPACK is not Supported
   3. *Hitachi has commercial DECSOLVE PDE solver
      1. -If original Fortran x lines
      2. -DECSOLVE is x/20 and produced 2x line length Fortran which ran faster than original code as optimized for Hitachi Compiler
10. Questions from the audience - II
    1. *Thompson says he can give people both geometries and meshs from National Grid project
    2. *John Rice says little difference between different languages!
       1. -Barry Smith violently disagrees
       2. -Fortran77 can't do user interfaces but Rice doesn't believe ELLPACK (written in F77) would be much easier in another language

Begin New Set ************************ purdps10

1. Scalability of Problem Solving Environments
2. and Wrap Up Session
   1. Ahmed Sameh Minnesota
   2. Wayne Joubert LANL
   3. Barry Smith ANL
   4. John Rice Purdue
3. Sameh Presentation
   1. *Scalable Algorithms for sparse problems adjust algorithms -- see METIS by Kumar for partitioning and matrix reordering
   2. *SPARSLIB
      1. -Iterative solvers not as robust as he would like
      2. -Can tailor to user's data structures
4. Barry Smith Presentation
   1. *Levels of abstraction
      1. -Application Interface
      2. -Math Interface
   2. *Data encapsulation(=hidden)
   3. *Use C as an example to remove compiler manipulation
      1. -objects carry with them routines to manipulate objects
      2. -in C specify functions by pointers to routines
   4. *State Encapsulation
      1. -Could use a global array -- common block but this is not good if recursive
      2. -So use a user supplied data structure
5. John Rice Presentation
   1. *Parallelism can be exploited at all levels from user to utilities
   2. *Data Parallelism in space is key
      1. -need to allow variable in space algorithms
   3. *Collatz conjecture (1970ish) -- time to solve PDE of same order as time to evaluate closed form solution
6. Joubert Presentation -- I
   1. *Amoco Cray LANL collaboration to develop parallel oil reservoir simulation system
      1. -GUI, visualization, geostatics,history matching. simulation itself
      2. -Want 100 times a Cray2
      3. -Must run overnight
   2. *Need scalability -- PC to MPP
7. Joubert Presentation -- II
   1. *Port to 128 node T3D -- initially 7-8 mflops per node
      1. -drastic optimization gives 18 mflops/node with 1 to 2 man-months
   2. *2200 wells, 5 years, 5 million grid points
      1. -run 50 such cases by end of year
   3. *Hindrances
      1. -lack of convergence of architectures and their short lifetime
      2. -no clear standards for sparse linear algebra
      3. -would like standard sparse BLAS so vendor would automatically optimize
8. Questions from Audience -- I
   1. *Physics of compositional models makes load balancing critical not solver
      1. -however Amoco problem is not of this type
   2. *Smith with usual glee with pointers(!) says we will use unstructured meshes for everything to allow natural load balancing
   3. *General discussion of load balancing ensues but little/new deep thoughts
9. Questions from Audience -- II
   1. *Memory used could be a serious issue on the web as can't predict how much memory availabe
      1. -somebody claims (remarkably) that cache based machines run irregular meshs as well as regular meshs
   2. *Skjellum notes that pointers in C++ are class relative so can move from machine to machine
   3. *Incorrect discussion of multithreaded models for load balancing irregular problems
10. Overall Conclusions -- I
    1. *Hardware will change
    2. *Need to support multiple paradigms
    3. *PSE's will deliver scalable libraries
    4. *Need Examples of PSE's inside and outside PDE domain
       1. -Purdue had a table of some 20 PDE PSE's
11. Overall Conclusions -- II
    1. *PSE's are good but need study of software architecture and tools to build them
    2. *PSE's will build on PSE's
    3. *Can re-use PSE modules and PSE infrastructure
    4. *Standards for Sparse libraries

Begin New Set ************************ purdps11

1. Overall Discussion on Last Day
   1. First Panel: Bob Lucas Chair
2. Written Suggestions of Future Activities
   1. *CFDRC/John Rice:
      1. - Geometry
   2. *Minnesota:
      1. -Preconditioners,
      2. - expert systems,
      3. -pre and post processing standards
      4. -MDO PSE
   3. *Argonne,MSU:
      1. -software engineering standards (object-oriented)
   4. *Purdue:
      1. -Virtual Environments,
      2. -Multidisciplinary and domain specific PSE's,
      3. -Browsers/Agents to find useful material
3. Bob Lucas Again
   1. *Design $10M/year program over next 6 months
   2. *In same science/technology area as now
   3. *Remember speakers at Arpa PI meeting from industry said software integration is key
   4. *Package proposals as DoD area
   5. *Metacomputing Programming Tools
      1. -such as compilers and algorithms for World Wide Virtual Machine
      2. -components and large complex systems
      3. -legacy systems
4. Boisvert's Ideas --I
   1. *Emerging Trends
      1. -Computing is getting better
      2. -Systems are getting more complex and flexible and this is a PSE
      3. -global networks are increasing vision of what computer is
   2. *High Fidelity Multi-Component Distributed Simulation
   3. *Software development environment is bottleneck
5. Boisvert's Ideas --II
   1. *High cost of developing a PSE
      1. -GUI
      2. -Expert Systems
      3. -Ad Hoc Integration and distribution of components
      4. -they are heterogeneous
   2. *Need dynamic interoperable problem solvers on the network
   3. *Lucas suggests eigensolvers on the network
   4. *Components of Program
      1. -distribution object management
      2. -metadata to discover services
      3. -coarse grain software integration
      4. -need prototypes, PSE middleware
6. Discussion -- I
   1. *Lucas says no two sparse solvers have the same interface and no two users use the same package
      1. -Boisvert says object-oriented techniques solve
      2. -But Lucas says this is a mature field; in real world can't afford performance loss of such wrappers
      3. -Lucas notes real application people are cleverer than computer scientists think! They often use excellent innovative algorithms
      *Sameh emphasizes expert systems to help choice of method
7. Discussion -- II
   1. *Heath says grid generation and human time more important than PDE solution time
      1. -Lucas counters that PDE solver purchase is done in "isolation" as a separate competition
   2. *Need to trap and understand error messages from say NASTRAN and detect that say one needs to give it more memory
   3. *Barry Smith says Web Technology is just TCP/IP!
   4. *Lucas suggests partnering with either aerospace industry or government laboratory.
      1. -But Lucas's Arpa's interest is mainly electronic not mechanical application
8. Discussion -- III
   1. *I added following points
      1. -In multidisciplinary PSE's need to do more than just CFD and structures -- ASOP needs 10,000 programs
      2. -Shared memory and distributed memory metacomputer two architecture model
      3. -Coarse grain and Fine grain software/problem models
      4. -Exploit software engineering opportunities of the web
9. Discussion -- IV
   1. *Lucas can't persuade its management to support MOSIS
      1. -How can he persuade them to support software systems which are less clearly generally valuable

Begin New Set ************************ purdups