a network-based pde solving environment
DESCRIPTION
PDE.Mart. A Network-based PDE Solving Environment. Mo Mu Department of Mathematics Hong Kong University of Science & Technology Team members: - PowerPoint PPT PresentationTRANSCRIPT
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