A Network-based PDE Solving Environment
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
Background
•
NetSolve/GridSolve
– Network and grid-based
– Function evaluation: <output> = <name>(<input>)
– 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
Missions
• 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.
System Structure
Features
• 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 multimodel 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
NETWORK-based GUI
• Provide a platform for specifying applications,
constructing PDE solvers, and post-processing
• Convert the graphical user interface to the PDE objectbased internal system interface
• Communicate with the server for transporting the objects
• Serve as an agent between the client and server
Characteristics
•
•
•
•
Intensive interaction
Demanding graphics support
Object-oriented
Hierarchical browsing (domain shapes, PDE
types, numerical)
Overall Structure of PDE-GUI
Domain Editor
Shape Editor: General 2D
PDE Editor: Rectangle
PDE Editor
Model Editor: Elliptic, 2nd Order, Linear, Standard Form
-- Equation Page (3D)
Model Editor: Elliptic, 2nd Order, Linear, Standard Form
-- Boundary Condition Page (3D)
Method Editors
• 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
Post-processing
• Visualization
– VisAD
– Built on top of Java3D
• Data analysis
– Error analysis
– Interpolation at off-mesh points
– Derivatives, etc
Surface Plot of PDE Solution
PDE-SERVER
• Java application running on the host server
• Client-Server protocol
– Multiple users
– PDE solution services
Overall Structure of PDE-Server
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
Engine Builder and Computational Session
• 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
Engine Components
•
•
•
•
•
•
•
Domain Creator
PDE Creator
Mesh Generator
Discretizer
Indexer
Solver
Blackbox-solver
Client-Server Communication
• Java RMI (Remote Method Invocation)
– Easy and convenient for developing distributed objectbased 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
Client-Server Communication (continued)
• 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
PDE-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
Computational Flow in PDE Solution
• Descriptive objects
• Processing objects
Application Programmer Interfaces
• 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
PDE-API
•
Domain Interfaces
–
–
•
PDE Interfaces
–
–
–
–
•
Mesh2DGridInterface
Mesh2DFEInterafce
– ……
Discrete Interfaces
–
–
•
•
PDEEllipticInterface
PDEParabolicInterface
PDEHyperbolicInterface
……
Mesh Interfaces
–
–
•
Domain2DInterface
Domain3DInterface
DiscreteLinearInterface
DiscreteNonlinearInterface
Indexing Interface
Solution Interface
API-based Framework for Software Integration
• 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
Uniform Structure of Processing Class in PDE-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
Example of Processing Class
Multi-layer Wrapper Framework
• 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
Java Wrappers
• 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
Example of Java Wrapper
C++ Wrappers
• 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
Structure of C++ Wrappers
• 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.
Fortran/C Wrappers
• 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.
Structure of Fortran/C Wrappers
• 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
Call-back Wrappers
• 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
Multi-layer and Two-way Wrapper Framework
PDE.Mart Packages
• 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
PDE-LIB: Geometry Package