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