PLATFORM FOR BUILDING PDE-BASED PROBLEM-SOLVING ENVIRONMENTS

1
PLATFORM FOR BUILDING PDE-BASEDPROBLEM-SOLVING
ENVIRONMENTS

• Mo Mu
• Department of Mathematics
• Center for Scientific Computation
• Hong Kong University of Science Technology
• Collaborators
• E. Houstis, J. Rice (Computer Sci. Dept, Purdue
  Univ.)
• E. Vavalis (Dept. of Math., Crete Univ., Greece)

2
WHAT ARE PSEs

• "A PSE is a computer system that provides all the
  computational facilities needed to solve a target
  class of problems. These features include
  advanced solution methods, automatic and
  semiautomatic selection of solution methods, and
  ways to easily incorporate novel solution
  methods. Moreover, PSEs use the language of the
  target class of problems, so users can run them
  without specialized knowledge of the underlying
  computer hardware or software. By exploiting
  modern technologies such as interactive color
  graphics, powerful processors, and networks of
  specialized services, PSEs can track extended
  problem solving tasks and allow users to review
  them easily. Overall, they create a framework
  that is all things to all people they solve
  simple or complex problems, support rapid
  prototyping or detailed analysis, and can be used
  in introductory education or at the frontiers of
  science." -- "Computer as Thinker/Doer
  Problem-Solving Environments for Computational
  Science" by E. Gallopoulos, E. Houstis and J.
  Rice (IEEE Computational Science and Engineering,
  Summer 1994).

3
WHY PSEs

• Researchers in scientific computing and
  simulation have witnessed the evolution of
  computer systems from subroutines to libraries,
  then to software packages/solvers, and now to
  PSEs.
• This evolution is possible and necessary because
  computational techniques have become more
  sophisticated, the computing environment has
  become more powerful with many varieties of
  architectures, and above all, the driving force,
  computational problems have become more complex.

4
EXAMPLES OF PSEs

• Workbench frameworks users enter commands or
  create the application
• Matlab (high-level interface to toolboxes)
• Maple, Mathematica
• PELLPACK
• PETSc (PDE-based scientific applications)
• NetSolve
• AirShed Modeler
• Soliton Explorer

5
EXAMPLES OF PSEs

• Component composition systems users can wire
  together components to create a complete
  application
• SCIRun
• Component Architecture Toolkit
• Workbench for Interactive Simulation of Ecosystems

6
EXAMPLES OF PSEs

• Code composition/generation frameworks these are
  distinguished by having as an end product code in
  a programming language
• POOMA/PAWS
• ATHAPASCAN
• SciNapse
• Falcon

7
EXAMPLES OF PSEs

• Collaboration frameworks they provide frameworks
  that allow multiple users at widely separated
  sites to work together on a single problem
• TechTalk (supporting shared Matlab, Maple)
• Shastra
• Intelligent Archive

8
LESSONS

• LARGE
• COMPLEX
• HETEROGENEOUS
• ENORMOUS EFFORTS

9
CHALLENGES AND OPPORTUNITIES

• How to build these very large and complex
  computer systems effectively and efficiently? We
  face many technological difficulties that have
  not yet been faced in the development of
  conventional scientific software packages.
• Meeting this challenge will lead to many research
  issues in software methodology, computational
  frameworks, and scientific modeling and will
  create great opportunities for exploring novel
  concepts and methodologies in these areas.

10
PDE-BASED PSEs

• Necessary to have a platform for building PSEs in
  a plug-and-play fashion
• Realistic for PDE applications

11
RESEARCH ASPECTS

• Scientific -- model integration (application
  users)
• Mathematical -- solution integration
• Technical -- software/shareware integration (real
  virtual)

12
COLLABORATING PDE SOLVERS

• Solve submodels independently with supplied
  boundary conditions
• Adjust boundary conditions to better satisfy
  interface constraints
• Iterate until convergence

13
INTERFACE RELAXATION

• Originating from the spirit of the classical idea
  by Southwell in the 1930s for solving linear
  algebraic systems
• Appearing in various formulations such as
  value-averaging, least-squares minimization,
  Newton iteration, energy minimization,
  Dirichlet-Neumann alternating, etc.
• Effective for a wide range of applications
• Analyzed for a class of model problems
• Reduced to domain decomposition in special cases
• Accurate and reliable
• Flexible

14
AGENT-BASED ARCHITECTURE

• Agents--single submodel solvers/PDE packages
• Mediators--interface relaxers / central
  convergence handler

15
ALL PURPOSE DOMAIN PROCESSOR

• Internal domain processing It supports one, two,
  three, and even higher-dimensional spatial
  domains. It is able to handle reasonably complex
  geometric shapes on both symbolic and numerical
  levels.
• Horizontally, it supports various mesh structures
  including tensor-product grids, polar meshes,
  finite element meshes, unstructured meshes.
• Vertically, it supports mesh coarsening/refinement
  , multi-level meshes, adaptive meshes, mesh
  restructuring, mesh partitioning, mesh
  overlapping, time-dependent moving meshes, moving
  boundaries.

16
DOMAIN PROCESSOR (continued)

• Inter-domain processing It provides facilities
  to support communication and plugging with other
  domains.
• Domain identification
• Domain joining (selecting, moving, gluing,
  interface-domain mapping, cross-point handling,
  etc.)
• Global/local coordinate systems mapping
• Meshing consistency

17
DOMAIN PROCESSOR (continued)

• Data structures and operations
• Hierarchical/paging techniques are used in our
  data structures for the purposes of flexibility
  and efficiency.
• For ease of implementation of native PDE solvers,
  we provide utility procedures including
  interpolation, restriction, extrapolation,
  differentiation, neighboring values, blending,
  smoothing, functions of boundary value, normal
  derivatives, interface values and/or jumps,
  values at previous time levels, mean-values at
  overlapping points, such as cross-points and
  those in an overlapping region.

18
APPLICATIONS PROGAMMER INTERFACES

• Standards--necessary for software/shareware
  integration
• Efficiency--optimized implementation by experts
• Publicity--participation of computer vendors and
  software firms
• Successful example BLAS/BLACS
• Upcoming example DFTAPI
• On low level of subroutines
• We see the need and importance to have a widely
  accepted standard Applications Programmer
  Interface (API) for PDE-based PSE components

19
STANDARD PDE APIs

• Several levels of the PDE-API are defined.
• The lowest level starts with a set of basic
  building blocks for PDE solvers.
• The next level contains basic and commonly used
  PDE solvers defined on simple shaped domains.
• The more advanced level has general linear PDE
  solvers.
• The highest level covers general nonlinear PDEs,
  systems of PDEs, complex-valued PDEs, and so on.,
  in order to model a reasonably complicated, yet
  still well understood and solvable single
  physical or chemical phenomenon.

20
STANDARD INTERFACE APIs

• This covers commonly used interface conditions
  and relaxation/matching schemes

21
WrapperLib

• Optimized implementation of core PDE solvers
• Browser for foreign solvers
• WrapperLib--a collection of wrappers that map the
  user interfaces of commonly used PDE solvers and
  shareware to the standard PDE-API.

22
PDE BROWSER

• Browse available PDE solvers according to users
  specification
• Solver selection by invoking the expert system
• Plug-in (real or virtual) through
  PDE-API/WrapperLib

23
APPLICATION EXAMPLE

• Long Range Transport of Air Pollution (LRtap)
• Multiple models convection, diffusion,
  deposition, emission, chemical reaction
• SciAgents implementation
• Simulation for the island of Crete

24
PDE-Mart Features

• PDE based PSE
• Networked (the users point of view GUI)
• Distributed (the computing point of view LIB,
  network/parallel computing)

25
PDE-Mart System Structure

• PDE-Mart GUI
• PDE-Mart library

26
PDE-Mart GUI

• The interface is a platform for specifying
  applications, constructing PDE solvers,
  evaluating mathematical models and numerical
  methods, as well as scientific simulation
• The engine (a preprocessor or interpreter)
  translates the user interface to the internal
  system interface

27
PDE-Mart GUI practical and technical issues

• Invoke mode web-based versus host-based
• web-based
• convenient for anonymous users through browser
  access to the software system
• could be inefficient due to network traffic
• network security especially for performing I/O
  (access to the file systems at both ends)
• untrusted users to the PDE-Mart server
• untrusted shareware to the users computer

28
PDE-Mart GUI practical and technical issues

• web-based versus host-based (continued)
• host-based
• suitable for advanced users who need an efficient
  GUI and intensive I/O, are experienced with the
  software system, and are mutually trusted with
  the PDE-Mart server
• remote host use the PDE-Mart server as the host
• directly connect to the server through an
  explicit network protocol such as telnet or other
  gateways
• no regular access to the local machine
• local host use users computer as the host
• download the GUI and run the Java application on
  the local machine
• with full access to the local host
• communicate with the PDE-Mart server through a
  suitable networking technology such as CGI or the
  Java client-server mode

29
PDE-Mart GUI practical and technical issues

• I/O mode batch versus interactive
• batch mode
• program text based, such as the Ellpack approach
• necessary file access and possible implementation
• on the remote server
• browse and load sample programs (e.g. prog.e)
• - simple for HTML
• - Java applet (coming from the remote server)
  network connection or interaction with CGI)
• review and edit/save intermediate results (e.g.
  prog.f, out.dat)
• - HTML/CGI or Java/CGI
• - limited access for untrusted users

30
PDE-Mart GUI practical and technical issues
(batch mode)

• necessary file access and possible implementation
  (continued)
• on users machine
• file access
• browse and load sample or previous programs (e.g.
  prog.e)
• edit/save intermediate and final results (e.g.
  prog.e, prog.f, out.dat)
• implementation
• HTML or Java application running on the local
  host
• Java applet is not allowed to do so. Must go
  through HTML or using Java client-server to walk
  around
• a form protocol is sufficient for job submission
  and retrieving data, such as HTML/CGI or Java/CGI
• efficient interactive post-processing on the
  local machine is possible after the solution is
  computed and fetched back to the users end

31
PDE-Mart GUI practical and technical issues

• I/O mode batch versus interactive
• conclusions of the web-based, batch version the
  HTML/CGI approach is chosen in our implementation
• browser enabled
• simple
• enough graphics for basic UI purposes

32
PDE-Mart GUI practical and technical issues

• I/O mode batch versus interactive
• web-based interactive mode Java applet
• web browser enabled
• object-oriented
• domain class
• PDE class
• domain processor class
• solver class
• post-processing class
• reusability
• graphics support (Java AWT, Java Swing)
• Do users often need to save the current
  application (domain, PDE, ect.) on client
  machines, reload and edit it? And how (via a
  template)?

33
PDE-Mart GUI practical and technical issues

• Security policies
• on the users side
• HTML--save by users
• Java applet? Current approach--through HTML
• on the servers side
• with limited access to the server for
  intermediate I/O in order to control anonymous
  users, except for authorized ones

34
PDE-Mart GUI (html)

• WELCOME TO PDE-MART
• PDE-PSE
• ELLPACK
• OTHER PDE SYSTEMS

35
PDE-Mart GUI

• A PROBLEM-SOLVING ORIENTED GUI FOR PDE-PSE
• (Java applet)
• Problem specification
• DOMAIN
• PDE
• Solver specification
• DOMAIN DISCRETIZATION
• PDE DISCRETIZATION
• SOLUTION
• ANALYSIS
• Function buttons
• submit
• compile
• run
• load
• save
• For security reasons, applets that are loaded
  over the network have several restrictions. One
  is that an applet can't ordinarily read or write
  files on the computer that it's executing on.
  Another is that an applet can't make network
  connections except to the host that it came from.
  Despite these restrictions, applets can do some
  things that you might not expect. For example,
  applets can invoke the public methods of other
  applets on the same page.

36
PDE-Mart GUI

• DOMAIN SPECIFICATION-2D
• DOMAIN OF SPECIAL SHAPES
• POLYGONS
• DOMAIN WITH PIECEWISELY DEFINED BOUNDARIES BY
  PARAMETRIC FUNCTIONS

37
PDE-Mart GUI

• DOMAIN OF SPECIAL SHAPES
• RECTANGLE
• DISC
• ELLIPSE

38
PDE-Mart GUI

• RECTANGLE
• Please input the coordinates for the four edges
  (xa, xb), (ya, yb)

39
PDE-Mart GUI

• DISC
• Please input the coordinates of the center (a, b)
  and the radius r

40
PDE-Mart GUI

• ELLIPSE
• Please input the .

41
PDE-Mart GUI

• POLYGON
• Please input the vertices list

42
PDE-Mart Technical issues of Library

• Interact with other software parts
• data structure aspect PDE-API
• language JNI (Java Native Interface)
• Interact with other servers
• Java Networking in JDK with TCP and UDP
• Java RMI (Remote Method Invocation)

43
PDE-Mart Library

• Domain class
• PDE class
• Discrete domain class
• Discretization class
• Solution class
• Evaluation class
• Display class

44
PDE-Mart Library domain class

• disc
• square
• rectangle
• triangle
• polygon
• general domain with piecewise boundary defined by
  parametric functions (supplied by users through
  GUI)

45
PDE-Mart Library PDE class

• equation class
• elliptic
• Poisson equation
• second order linear equation with constant
  coefficients
• second order linear equation with non-constant
  coefficients
• forth order equation
• parabolic
• heat equation
• hyperbolic
• wave equation
• Euler equation
• N-S equation

46
PDE-Mart Library PDE class

• boundary condition class
• interface condition class