A Network-based PDE Solving EnvironmentA Network-based PDE Solving Environment

Mo Mu

Department of MathematicsHong 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

BackgroundBackground

• 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

MissionsMissions

• 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 StructureSystem Structure

FeaturesFeatures

• 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

NETWORK-based 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

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-SERVERPDE-SERVER

• Java application running on the host server

• Client-Server protocol– Multiple users– PDE solution services

Overall Structure of PDE-ServerOverall Structure of PDE-Server

ServerServer

• 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 SessionEngine 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 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

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 SolutionComputational 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– Domain2DInterface– Domain3DInterface

• PDE Interfaces– PDEEllipticInterface– PDEParabolicInterface– PDEHyperbolicInterface– ……

• Mesh Interfaces– Mesh2DGridInterface– Mesh2DFEInterafce

– ……• Discrete Interfaces

– 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 FrameworkMulti-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 WrappersJava 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++ WrappersC++ 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++ WrappersStructure 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 WrappersFortran/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 segme

nt 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 WrappersStructure 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 WrappersCall-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 FrameworkMulti-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 PackagePDE-LIB: Geometry Package