A Networkbased PDE Solving Environment

1
A Network-based PDE Solving Environment
PDE.Mart

• Mo Mu
• Department of Mathematics
• Hong Kong University of Science Technology
• Team members
• Chan Chui Ling, Chan Wing On, Cheung Lai Yee,
  Chim Lai Fong, Choi Kam Wing, Ho Ka Man, Ho Woon
  Ping, Kong Yin Wa, Law Man Fai, Ma Po Yee, So
  Ming Cheung, Tsui Ka Cheung, Tsui Wai Ming, Wu
  Sze Man, Yan Chi Hang, Falcon Siu, Xaio Hong Zhu

2
Background
PDE.Mart

• NetSolve/GridSolve
• Network and grid-based
• Function evaluation ltoutputgt ltnamegt(ltinputgt)
• Some PDE applications
• Web Pellpack
• PDE oriented with the full functionality of
  PDELab
• Host-based with VNC html upload
• WebInterfacer
• Host-based with CGI html
• Batch applications
• PDE.Mart
• Network-based with Java platform multi-language
  library
• PDE-oriented
• Net Pellpack
• Network-based with Java
• PDE-oriented

3
Missions
PDE.Mart

• Develop a network-based and PDE-oriented PSE
  (Problem solving environment)
• Investigate the impact and research issues of the
  rapidly growing network/grid technologies in
  designing and developing network/grid-based PSEs
  for scientific and engineering applications.

4
System Structure
PDE.Mart
5
Features
PDE.Mart

• Network-based Java platform
• Web browser-enabled interactive GUI
• Client-Server protocol
• PDE-oriented PSE
• Problem specification with complicated geometry,
  PDE, and boundary/interface/initial conditions,
  including multi-domain and multi-model problems
• Engine builder for method selection and
  composition
• Post-processing with visualization and data
  analysis
• Software engineering
• Platform uniform, flexible, machine independent,
  object-oriented
• LIB effective and efficient software integration
  with multi-language and multi-source software
  parts
• PDE-API-based mechanism
• Multi-layer and two-way wrapper framework

6
NETWORK-based GUI
PDE.Mart
GUI

• Provide a platform for specifying applications,
  constructing PDE solvers, and post-processing
• Convert the graphical user interface to the PDE
  object-based internal system interface
• Communicate with the server for transporting the
  objects
• Serve as an agent between the client and server

7
Characteristics
PDE.Mart
GUI

• Intensive interaction
• Demanding graphics support
• Object-oriented
• Hierarchical browsing (domain shapes, PDE types,
  numerical)

8
Overall Structure of PDE-GUI
PDE.Mart
GUI
9
Domain Editor
PDE.Mart
GUI
10
Shape Editor General 2D
PDE.Mart
GUI
11
PDE Editor Rectangle
PDE.Mart
GUI
12
PDE Editor
PDE.Mart
GUI
13
Model Editor Elliptic, 2nd Order, Linear,
Standard Form-- Equation Page (3D)
PDE.Mart
GUI
14
Model Editor Elliptic, 2nd Order, Linear,
Standard Form-- Boundary Condition Page (3D)
PDE.Mart
GUI
15
Method Editors
PDE.Mart
GUI

• Components of Numerical PDE methods
• Domain (spatial temporal) discretization
• PDE discretization
• Indexing
• Solution
• Blackbox
• Method browsing
• Application range problems and other numerical
  components
• Performance evaluation and method recommendation
• Relational database for method selection, solver
  composition, and consistency/error checking

16
Post-processing
PDE.Mart
GUI

• Visualization
• VisAD
• Built on top of Java3D
• Data analysis
• Error analysis
• Interpolation at off-mesh points
• Derivatives, etc

17
Surface Plot of PDE Solution
PDE.Mart
GUI
18
PDE-SERVER
PDE.Mart
SERVER

• Java application running on the host server
• Client-Server protocol
• Multiple users
• PDE solution services

19
Overall Structure of PDE-Server
PDE.Mart
SERVER
20
Server
PDE.Mart
SERVER

• Create the Client-Server protocol
• Listen to clients on the Internet
• Create a socket for each client-server connection
  to establish the communication channel
• Create a CS (computational session) thread as an
  instance of Engine Builder for the client to
  build the computational engine

21
Engine Builder and Computational Session
PDE.Mart
SERVER

• A CS is an instance of Engine Builder
• A CS is an interactive Control Program
• communicating with the user (through PDE-GUI) via
  the socket for input or output
• mapping a PDE-GUI session to the internal system
  interface
• controlling the computation on the server to
  create or update the Domain object, PDE object,
  Mesh object, Discrete PDE object, Indexing
  object, and Solution object, or Blackbox-solver
  object that combines the latter three
• CS is object-oriented based on PDE-API
• CS is multi-threaded

22
Engine Components
PDE.Mart
SERVER

• Domain Creator
• PDE Creator
• Mesh Generator
• Discretizer
• Indexer
• Solver
• Blackbox-solver

23
Client-Server Communication
PDE.Mart
SERVER

• Java RMI (Remote Method Invocation)
• Easy and convenient for developing distributed
  object-based applications
• Without object transportation and replication
• Expensive communication
• Object Serialization
• Read/write a full-blown object via byte streams
• With object replication
• Convenient
• Improved communication performance than RMI, yet
  still expensive for BIG objects

24
Client-Server Communication (continued)
PDE.Mart
SERVER

• Parameter-based object transmission
• Passing defining information and
  re-creating/updating the object
• More efficient
• Tedious low-level socket data manipulation
• Hash table-based Key-Value parameter array
• Creator key for identifying a creator to invoke
• Object key for identifying an object to
  create/update, such as shape key for domain
  objects, type key for PDE object,
• Event-driven CS

25
PDE-LIB
PDE.Mart
LIB

• A collection of computational and utility
  supporting software parts for developing
  PDE-oriented PSEs
• Self-developed or ported from existing systems
  for software re-use
• Most of the computationally intensive software
  parts are fine-tuned and mature native codes
• Challenge software integration with
  multi-language and multi-source native codes into
  an object-oriented Java platform

26
Computational Flow in PDE Solution
PDE.Mart
LIB

• Descriptive objects
• Processing objects

27
Application Programmer Interfaces
PDE.Mart
LIB

• BLAS API for numerical linear algebra
• API for FFT
• PDE-API
• PDE-oriented API
• Descriptive objects
• A standard set of methods for the specification
  of geometry, PDE, initial/boundary/interface
  conditions, domain discretization, PDE
  discretization, indexing, solution
• A protocol of behavior for a group of classes
  that implement the interface

28
PDE-API
PDE.Mart
LIB

• Domain Interfaces
• Domain2DInterface
• Domain3DInterface
• PDE Interfaces
• PDEEllipticInterface
• PDEParabolicInterface
• PDEHyperbolicInterface
• Mesh Interfaces
• Mesh2DGridInterface
• Mesh2DFEInterafce
• Discrete Interfaces
• DiscreteLinearInterface
• DiscreteNonlinearInterface
• Indexing Interface
• Solution Interface

29
API-based Framework for Software Integration
PDE.Mart
LIB

• A processing class expects certain input from the
  descriptive objects on the argument list
• A processing class has its application range
• Java interface can be used as a reference data
  type
• Only an instance of a class that implements the
  interface can be assigned to a reference variable
  whose type is an interface name

30
Uniform Structure of Processing Class in PDE-LIB
PDE.Mart
LIB

• PDE-API interfaces, instead of class names, are
  used as reference data types to declare the input
  arguments for descriptive objects
• The descriptive objects implementing the
  interfaces offer the promise to provide all the
  necessary information expected by the underlying
  numerical procedure
• The interface data types ensure the application
  limitation of the numerical procedure
• PDE-API defines a protocol of proper
  communication among the PDE-LIB objects

31
Example of Processing Class
PDE.Mart
LIB
32
Multi-layer Wrapper Framework
PDE.Mart
LIB

• Direct implementation of the numerical procedure
  is possible
• Native method invocation is more practical
• Software re-use
• Numerical efficiency
• The general class structure is reduced to a Java
  wrapper
• JNI (Java Native Interface) supports native
  method invocation
• Native codes are ported from existing packages
• Self-contained systems and Own data structures
• Control program (main program)
• Memory declaration
• Data structures allocation global variables,
  common blocks
• User-supplied routines
• Native method invocation
• Preprocessor
• Determine memory size
• Generate control program

33
Java Wrappers
PDE.Mart
LIB

• Lack of preprocessor and control program
• MemoryAllocator
• Calculate the dimension sizes of all the arrays
  associated to each numerical procedure
• Allocate the required memory of the data
  structures
• GlobalControl
• encapsulate the global control information
  necessary in a PDE computation, but not available
  from other descriptive objects such as domain,
  PDE, mesh, etc
• Wrapper structure extended from the general
  structure
• Native method declaration
• Descriptive objects plus GlobalControl object are
  passed to the argument list due to
  object-orientation
• Numerical procedure implementation
• Memory allocation
• Native method invocation

34
Example of Java Wrapper
PDE.Mart
LIB
35
C Wrappers
PDE.Mart
LIB

• The official Java technology only supports the
  JNI interface to C/C
• Technology for interfacing Java with Fortran or
  others is not mature and standard yet
• The arguments to a native method in a Java
  wrapper are passed by objects
• So, all native methods declared in Java wrappers
  are implemented in C
• If the target native code is not in C, the C
  code is again reduced to a C wrapper

36
Structure of C Wrappers
PDE.Mart
LIB

• Declare the external native routine
• Decode the information encapsulated in the
  argument objects passed from the Java side
• Invoke the native routine for passing the decoded
  information to input arguments and returning the
  computed information from the output arguments
• Encode the output from the native code to the
  target object for returning back to the Java side
  through the output argument of the C wrapper.

37
Fortran/C Wrappers
PDE.Mart
LIB

• The technology for calling routines between C
  and Fortran is mature and stable
• Fortran routine declared in a C wrapper is
  usually still not the target native code due to
  the lack of control program
• To invoke a library module, the control program
  contains a segment of statements for the setup
• Global variables cannot appear in an argument
  list
• A Fortran wrapper basically replaces part of the
  Fortran control program corresponding to the
  given numerical procedure.

38
Structure of Fortran/C Wrappers
PDE.Mart
LIB

• Pass the input data from the C wrapper to the
  Fortran side through the argument list to the
  Fortran wrapper
• Set up the global data structures, mostly in
  common blocks, as required by the Fortran
  routines involved in the native invocation
• Invoke the target Fortran native method together
  with the necessary setup
• Return the generated output to the C wrapper
  through the argument list to the Fortran wrapper

39
Call-back Wrappers
PDE.Mart
LIB

• Some native methods need to invoke methods
  available on the Java side
• ELLPACK
• Built-in routines for problem specification are
  available in the control program
• Used by Domain processor, Discretization modules,
  
• Available from Java methods defined in PDE-API
• Integrate ELLPACK into PDE.Mart
• Five Fortran call-back wrappers Q1BDRY Q1PCOE
  R1PRHS Q1BCOE R1BRHS of the same names in ELLPACK
  for the missing built-in routines
• Five C call-back wrappers DomBdryCpp,
  PDECoeCpp, PDERhsCpp, BCCoeCpp, BCRhsCpp

40
Multi-layer and Two-way Wrapper Framework
PDE.Mart
LIB
41
PDE.Mart Packages
PDE.Mart

• PDEMart
• PDEMart.GUI
• PDEMart.SERVER
• PDEMart.LIB
• PDEMart.LIB.Geometry
• PDEMart.LIB.PDE
• PDEMart.LIB.Mesh
• PDEMart.LIB.Discretization
• PDEMart.LIB.Indexing
• PDEMart.LIB.Solver
• PDEMart.LIB.Util

42
PDE-LIB Geometry Package
PDE.Mart