Java for controlling and con guring a distributed Turbine Simulation

Java for controlling and con guring a distributed Turbine Simulation System Thomas Breitfeld Sven Kolibal [email protected] GMD, Sankt Augustin, Germany http://www.gmd.de/scai

Andreas Schreiber Matthias Wagner [email protected] DLR, Cologne, Germany http://clara.rz.kp.dlr.de

Abstract

cent years by using parallel computers and distributed computer systems. Today we are in the situation that the engineer spends more time in con guring and connecting the tools needed for the simulation than in running the simulation itself. Therefore it is not only important to increase the parallel performance of particular CFD methods but it is necessary to create an integrated simulation environment in which the CFD codes and the various supporting tools are embedded. Our approach of such an environment is the system TENT.

This paper describes some Java releated aspects of TENT (TEstbed for Numerical Turbine simulation), a system designed for integrating various codes and tools of a Computational Fluid Dynamics (CFD) simulation system. TENT provides a distributed simulation environment for simulation tasks in energy and propulsion technology, and it allows to connect the dierent tools to an application scenario. TENT uses a component architecture inspired mainly by the JavaBeans speci cation. It is based on the Common Object Request Broker Architecture (CORBA,[1]) which is used for the communication of the components in the distributed environment. In this paper we will describe the TENT system architecture, the component architecture, and the application component interface. We also describe the use of Java for controlling the simulation system. This includes a graphical user interface, which is realized using JavaBean components, for con guring the components and running the simulation.

1.2 Goal Some important goals of TENT are the following:

1 Introduction 1.1 Problem To solve many problems in energy and propulsion technology the uid and thermodynamic processes are simulated using CFD methods. The computing times for those methods have been reduced to acceptable levels in the reCopyright 1998 GMD/SCAI Sankt Augustin and DLR Cologne, Germany. This paper was submitted to the workshop "Java for High Performance Network Computing" that will be held in Southampton, UK, September 1998. The work was supported by the BMBF through the SUPEA project.



Creation of an integrated and distributed simulation environment.



Easy integration of existing CFD applications and the supporting tools.



Combining the message passing paradigm and the distributed objects computing in one system.



Provide interactive simulations, which easily can be done from any computer in the net.



Ecient data exchange between the particular tools in the simulation environment.



1

1.3 Approach

are compatible, i.e. a component knows how to react on an event submitted by another component. The following gives a survey of the components which are part of a TENT simulation scenario:

TENT is a component architecture based on CORBA. CORBA realizes a seamless integration of distributed objects into a system. It uses a language and platform independent Interface De nition Language (IDL) which is translated/mapped to the implementation language, especialy into Java and C++. This mapping is done by the IDL compiler. The generated code calls an Object Request Broker (ORB) to connect with other (remote) objects to invoke methods of these objects over the network. CORBA is good for connection and integration of distributed objects but it is only a middleware and therefore there are further needs for our eld of applications. This paper makes the following contributions: 

We describe the TENT component architecture which allows the integration of dierent codes and tools for simulation, partitioning, preprocessing, postprocessing and visualization in one distributed simulation environment.



All CFD systems have a lot of con guration data. We describe the TENT project management for con guration, construction and destruction of components.



A Graphical User Interface (GUI) based on JavaBeans is presented which allows the interactive connection and con guration of components.



Partitioner: The task of the partitioner is to decompose a grid into some partial grids which can be distributed to the different processors on a Massively Parallel Processor (MPP) or Symmetrical MultiProcessing (SMP) computer considering dierent processor performances, communication bandwidth etc. Also a repartitioning considering the real computing times should be possible.



Simulation Engine: The simulation engine contains the simulation code. Usually the simluation code ist a Multiple Instruction Multiple Data (MIMD) program based on a message passing architecture like the Message Passing Interface (MPI, [2]) or the Parallel Virtual Machine (PVM) architecture. The simulation engine is a MIMD object abstraction which integrates the message passing application into the distributed object world, i.e. the system has one object reference to all the message passing processes.



Postprocessing: The postprocessor is needed to process the simulation results and to analyse and process the physical data. The used postprocessing method depends on the type of the simulated data, the desired representation and the used visualization tool. It is possible to use more than one postprocessor and also to cascade postprocessors.



Visualization: TENT does not provide its own visualisation tool. But almost every visualisation tool or library can be integrated if one encapsulates the functions using a suitible wrapper, e.g. in Java or C++. The tools currently used are Tecplot and the Application Visualization System (AVS, [3]).

2 Application Structure 2.1 Application Scenario

A TENT application scenario consists of various tools, which are capsuled to components, that are interconnected using event channels. An event carries the control instructions and the user data. Figure 1 shows a possible process chain scenario. Using this concept one can exibly connect dierent components as long as the events which are transmitted between the components 2

Grid (build upon a CA designed construction)

MCP: Control & Interaction & Configuration

Partitioner patitioned Grid

Simulation Engine

PostProcessor

Simulation Results

PostProcessor

reduced and transformed Simulation Results PostProcessor

Visualization Tool movies, 3D scenes, diagrams Visualization Tool

Figure 1: TENT Application Scenario 

Master Control Process (MCP): The MCP is the central control instance of the TENT system. Its rst task is to wire the components together, i.e. build the desired process chain, and drive the simulation. That includes the whole data management and the protocollation. Its second task is the con guration of the components. This is done by a graphical user interface (see section 4). The MCP and the GUI are both implemented in Java. The communication interface for controlling the components is based on CORBA. For the de nite identi cation of components in a distributed system a naming service is used and the automatic creation of components is done by a factory service. A detailed description of this is given in section 3.

of TENT to interact with each other and allow the integration of the necessary system components that are responsible for controlling the whole application. 2. An infrastructure that allows the connection of components across machine boundaries. The second step is already done by many implementations of middleware. We decided to use CORBA for our system since it is available for nearly all UNIX platforms and Windows and all major implementation languages. The next architectural principle is to use Java wherever it seems to be feasible. Currently all system parts except the high performance application components are implemented in Java. Figure 2 gives an overview about the system architecture and which parts are currently implemented in Java and which in other languages. The concrete component interaction will be described in the following chapters.

2.2 System Architecture

The main goal of TENT is the integration of a lot of dierent and existing programs into one simulation environment with a centralised control. This becomes even more dicult due to the fact, that each part has its own requirements on hard- and software. For instance the simulation codes use C and Fortran and massively parallel computers, other parts are programmed in single threaded C++ and use a graphical frontend for user interaction. We decided to base the system architecture on a distributed component approach. This is done by specifying two major points: 1. A set of interfaces that are independent from any kind of implementation. These interfaces allow the dierent components

Since CORBA de nes an object model but no component architecture TENT de nes two things: a component architecture and anapplication component interfaces

Component Architecture

The component architecture of TENT is inspired by the JavaBeans speci cation [4] and the Data Interchange and Synergistic Collateral Usage Study (DISCUS) framework [5]. The near to Java was chosen for the seamless integration of the Java parts with the rest of the system and with respect to use as much Java code as possible especially for future ex3

Component Factory

Partitioner

Compute Server

Visualization Tool

MCP

GUI Legend: Java Impl. other

Component Factory

Postprozessor

Simulation Engine

Name Server

encapsulated Component GUIs Frontend Machine

Figure 2: Architectural Overview of TENT tensions where lot of useful code is expected to be available in form of Java components. The TENT component architecture includes general interfaces for components and data objects as well as an event and property model. Figure 3 shows the main interface hierarchy. The Component interface is the common base for all future components. It inherits from the CommonObject which implements, in conjunction with the Factory component, the life cycle of every object. The Component interface itself has one major method getProperties(). It returns a reference to an object that implements the property model of TENT. This conforms to the JavaBeans property model whereas the real properties of a TENT component are realized via the DataObject interface which will be described in chapter 4.2. The DataObject interface allows to get() or set() a value of any type by giving a property name. This is logically the same like the JavaBeans property model but includes the ability to add and remove properties at runtime and to add properties without modifying the component code. This is useful for our GUI architecture as described in section 4. The event model was adapted from the JavaBeans speci cation and relies on the same data structures and name conventions de ned there.

CommonObject

Component

destroy()

query() convert()

1 0..* DataObject set() get() describe()

Factory createComponent()

Figure 3: TENT Framework Interface Hierarchy (UML notation)

Application Component Interfaces

A speci c application component interface (see Figure 4) consists mainly of speci c event listener interfaces. These event interfaces de ne interactions with other components as previously shown in Figure 1 as well as the data transported during event dispatching. In cases where vast amount of data would be moved we rely on the pull model, where only a reference to the appropriate data is transfered. The event listener can now request speci c data from the event sender. This oers the possibility to transfer only the data that is really needed. The second part of the component interfaces are speci c property names. Since they are used as strings directly in the property object they are not de ned using IDL. The properties 4

TENT-httpServer

Component query() convert()

nameServerPage 2: string_to_object(nameServerPage) NameServerRef

: ORB

1: load(NameServerUrl)

Partitioner

SimEng

Postproc

MCP

VisTool

: MCP

3: resolve(componentName) ComponentRef 4: getProperties()

ActionListener run() stop()

TimeStepListener

PostProcListener

TENT-NameServer : Naming Context

PropertyObject

ready()

ready()

anyTool : Component

Figure 4: TENT Components and the associated Listener Interfaces (UML notation)

Figure 5: MCP con guration bootstrap sequence (UML notation)

are used for both, the con guration of application speci c parameters, e.g. physical parameters of a CFD simulation, and the con guration of the component that is needed to integrate the particular component into the TENT environment. The rst problem is not part of this paper, the second will be described in more detaile throughout section 4.2.

metric description of the part that should be simulated with its physical properties. The geometric description is given in form of discrete grid points and their topology. Such a grid is usually generated out of a Computer Aided Design (CAD) program using a grid generator. Boundary and initial conditions are belonging to the simulation scene as well.

3 MCP, NameService, Factories - Java System Control

2. The Simulation Environment. This is the set of components described in 2.1 and their speci c con guration and wiring. The simulation scene is processed by the simulation environment.

3.1 Overview

The TENT system components do not contribute in the simulation of a physical scene, but actually they form a simulation system out of a bunch of standalone tools. All TENT system components are implemented in Java. The MCP is the main entity of TENT. It realizes and controls system tasks such as project management, construction and destruction of components, construction and destruction of a simulation environment, monitoring of the state of the system and its components or running the simulation itself.

3.3 System Startup

The MCP serves as a container for the various simulation components while the components might be spread across the network. A speci c state of the MCP is reconstructed while loading a project. In order to get access to the network references of the distributed components a kind of bootstrap process is involved during project loading. (see Figure 5):

3.2 TENT Projects

1. There is a well known Universal Resource Locator (URL) which contains the stringi ed object reference of the TENT naming service. The naming service might be site or task speci c. There is no need for an unique naming service in a company or

In order to save and load speci c system con gurations the MCP works with projects. A TENT project consists of two major parts: 1. The Simulation Scene. This is the geo5

research institute but the references contained in a speci c naming service de nes the resources and the domain where the TENT system can operate in.

does not implement an own GUI but it supports an interface a GUI can connect to. Currently the GUI interface is implemented as a pure Java interface with the option to be extended to Remote Method Invocation (RMI). This gives exibility changing the GUI even to a web based one.

2. The stringi ed object reference is converted to a binary object reference and used to bind to the naming service.

4 Component GUIs

3. The naming service contains references to already existing TENT components and references to factory components that can be used to create a prede ned set of components via the MCP. Usually there exists exactly one factory per machine. The MCP browses the naming hierarchy and queries for references of the involved components or creates them if they are not already exist.

4.1 Overview

Controlling the TENT system using Java components implies implementing the GUI parts of TENT in Java as well. Not only the easy to use GUI features of Java are valuable for our system but also Java language features like Runtime Type Information (RTTI), introspection and dynamic loading of implementation classes. The GUI itself is organized in various parts (see Figure 6). The upper part contains a tapped pane for each component that is part of the current working environment. The tab is reserved for the GUI panel of the appropriate component that allows the modi cation of runtime parameters and the access to component speci c controls. This component GUI might be provided by TENT as a default component GUI panel or it might be provided by the component itself (see section 4.3). The lower part of the GUI is used for con guring the process chain and running the simulation. Con guring the process chain is done by creating the components and connecting interfaces. All available components can be retrieved by the component repository that is not shown in the screen dump. The approach that was chosen for the GUI concept is based on JavaBeans and the meta data of the property object. This combination of CORBA components connected to JavaBean GUI components gives a highly exible self con guring and integrated GUI no matter what special application components are used currently or will be used in the future. The following sections will describe the property object in detail and how it is used to integrate the default or component provided

4. The last step is retrieving the property object using the components methods and storing the project speci c con guration in it. 5. Step 2 through step 4 will be repeated for all involved components of a project. Subsequently the MCP tries to instantiate a control and con guration GUI for each of the referenced components and to embed this GUI in the system GUI. Embedding of component provided GUIs is done using the JavaBeans speci cation. There are two possible variants for such a GUI. First the component may deliver an own specialized GUI by propagating the name of the appropriate JavaBean class in the DefaultGUIBean property in its property object. Second, if this property is missed or the given class cannot be found, the MCP loads a default GUI which is able to generate appropriate controls for the property object of its component. Finally the MCP wires the components to build the process chain. The MCP itself is highly independent of the components it is dealing with. This is achieved by dealing only with the base interfaces that are provided by each component. The MCP 6

Figure 6: Screen dump of TENT control GUI with visualization tool controls GUI within the TENT GUI.

The data object supports the events for bound and constrained properties that are known from the JavaBeans property model. We introduce an extension to the property listener interfaces. The interestedIn() method is used by the listener to describe the name of the properties for which it is interested in receiving events. This more selective event registration decreases the network trac in a distributed system during event dispatching. In comparison to Java, our used property model is in two major points dierent from the JavaBeans model (however it is still in conformance with the JavaBeans model since the root of the property hierarchy must be retrieved calling the getProperties() method of the Component interface):

4.2 Component Properties

The interface de nition of the TENT properties uses the generic data object interface provided by TENT. Such kind of interface was introduced in [6]. Logically the interface describes a list of name value pairs. The values are accessible by the get() and set() methods of the data object interface. All properties can be retrieved or stored by the readObject() and writeObject() methods. These methods were introduced in order to improve the communication eciency in cases where the whole object has to be set or got. The value of a property is always stored as the type any, which is a CORBA de ned type that stores not only the value but also a typecode within a variable. Given that, the data object is even able to contain other data objects. This is used to store the properties hierarchically. Figure 7 shows parts of the IDL de nition of the interface.

1. The properties are accessible over a generic interface since the any type is used for the property value. 2. The property interface is not an integral part of the component interface but rep7

In most cases, the component GUI has only the function of a container for the property GUI, and so it can be implemented in the same Java class as the property GUI. In special cases some additional control elements, required by a specialized implementation, can be added to the component GUI. The component GUI is instantiated by the MCP and initialized with the CORBA reference to the component it refers to. If this component does not have a specialized GUI, a default property GUI is instantiated, which is initialized with the reference on the property object. In the other case (the GUI is provided by the component) the reference to the component is casted by CORBA::Object:: narrow() to the expected type and so the Component GUI gets access to the implementation speci c interface methods. In a second step the component GUI asks the property object for the PropertyBean attribute. This may have the name of a specialized GUI for the representation of the property object of this component. If this attribute does not exist or the instantiation of the property bean class contained within fails, a default property bean is instantiated and receives the reference of the property object. Now the properties can be described by interrogate the meta data of the property object. With this information the editor with the graphical representation of the properties can be instantiated. Again the component can register special editors, if special properties for certain types exist. To minimize the load on the net, the editors do access on the assigned property not on their own initiative, but are initialized by the property GUI, which can use the more eective method readObject, to get the referring data in a call. At last the property bean registers itself at the property object as PropertyChangeListener. This mechanism allows a very exible linking of arbitrary TENT components into the control and con guration GUI. In the simplest case the component does not need to provide additional functionality for that linking. This

// IDL module TentData { interface DataObject : CommonObject { struct Property { string propertyName; any value; } typedef sequence PropList; exception PROPERTY_NOT_FOUND { string propertyName; }; any get(in string propertyName) raises(PROPERTY_NOT_FOUND); void set(in string propertyName, in any value) raises(PROPERTY_NOT_FOUND); void readObject(out PropList props); void writeObjekt(in PropList props); typedef sequence NameList; typedef sequence TypeList; void describe(out unsigned long nrOfProperties, out NameList names, out TypeList types); } }

Figure 7: Part of IDL de nition of the TentData module (Event and serialization interfaces are not shown) resents a standalone object. These changes allow the runtime modi cation of the set of provided properties of a component and allows the realization of an o-line con guration modus to parameterize a component since the component itself must not live in order to change parameters. This is most important where limited resources exist what is the case with parallel and high performance computers that must be used over a Wide Area Network (WAN).

4.3 Generated and provided GUIs

Figure 8 shows the relationships between the component GUI Bean, the property GUI Bean, and the property Object. Only the MCP can access the component base implementation, but this is controlled via the GUI and the property components. 8

JavaImplementations

MCP

Component GUI

Property GUI

ORB

Application spezific Implementations

Component implementation

Property Object

Legend: local References

spezialiced Implementation

remote References

Figure 8: Reference Scenario between Components and their associated JavaBean Component GUIs is one of the key mechanisms for integrating new TENT components.

for a CFD simulation system. The major parts are implemented in Java and use a component architecture which is related to JavaBeans. We described an application component interface and the use of Java for the system control and the implementation of the GUI. The use of Java has two important advantages:

5 Related Work Many other research groups are currently working at projects to create distributed high performance environments. Some examples are COVISE [7]or CAESAR[8], which demonstrate the possibility of integrated distributed simulation systems. An approach to improve the data transfer rate in parallel applications is PARDIS [9], a system which uses CORBA for communication between dierent components and which extends the CORBA object model with Single Program Multiple Data (SPMD) objects representing data parallel computations. Further important approaches are GLOBUS [10] and the World-Wide Virtual Machine (WWVM,[11]). GLOBUS is a complete metacomputing toolkit based on a communication library called NEXUS. WWVM is a metacomputing environment with a web interface for con guration and management of computation servers. The interface is based on Common Gateway Interface (CGI) scripts, whereas the TENT system uses Java as an approach for implementing a GUI, which is also independent from the operating system.

1. Java is available on almost every computer system and therefore the control process and the GUI can be used especially from every (desktop) computer. 2. Together with the use of CORBA, the TENT system runs on any network environment. The current TENT system works good for controlling and managing a simulation. But there are some performance constraints using CORBA for data communication between the components. One of the future goals is to overcome these performance constraints using more ecient techniques for the data exchange.

References [1] Object Management Group. The Common Object Request Broker: Architecture and Speci cation. OMG speci cation, Revision 2.2, February 1998.

6 Conclusions

[2] Message Passing Interface Forum. MPI: A Message-Passing Interface Standard. http://www.mpi-forum.org, 1995

This paper presented TENT as a system for integrating the various codes and tools needed 9

[3] AVS Advanced Visualization Systems. AVS/Express. http://www.avs.com/products/xp-intro, 1998. [4] Graham Hamilton, editor. JavaBeans API Speci cation. Sun Microsystems Inc., Mountain View, CA., 1.01 edition, July 1997. [5] Ron Zahavi and Thomas J. Mowbray. The essential CORBA: Systems Integration Using Distributed Objects. John Wiley & Sons, New York, August 1997. [6] Thomas Mowbray and Raphael Malveau. Corba design patterns. John Wiley & Sons, Inc., New York, 1 edition, 1997. [7] RUS. Introduction to COVISE. http://www.hlrs.de/structure/organisation /vis/covise/, 1998 [8] CAESAR. Cluster of computational intensive applications for engineering, design ans simulation on scalable parallel architectures. http://www.telecall.co.uk/~srcbae/, 1998 [9] Katarzyna Keahey and Dennis Gannon. Pardis: A parallel approach to corba. In Proceedings of IEEE 6th International Symposium on High Performance Distributed Computing, Portland, OR., August 1997. [10] Ian Foster and Carl Kesselman. GLOBUS: A metacomputing infrastructure toolkit. http://www.globus.org/documentations/papers.html. [11] Kivanc Dincer and Georey C. Fox. Building a World-Wide Virtual Machine Based on Web and HPCC Technologies . http://www.bib.informatik.thdarmstadt.de/sc96/DINCER/INDEX.HTM.

10