The Integrated Simulation Environment TENT

CONCURRENCY|PRACTICE AND EXPERIENCE
Concurrency: Pract. Exper. 2000; 00:1{7 Prepared using cpeauth.cls [Version: 2001/03/05 v2.01]
The Integrated Simulation
Environment TENT
Andreas Schreiber
1,2,�,y
1
Deutsches Zentrum fur Luft- und Raumfahrt e.V.,
Simulation and Software Technology, Linder Hohe, 51147
Cologne, Germany
2
Argonne National Laboratory, Mathematics and Computer
Science Division, Argonne, IL 60439, U.S.A.
SUMMARY
This paper describes recent development e�orts on the integrated simulation
environment TENT. TENT is a component-based software integration and work
ow
management system using the capabilities of CORBA and Java. It is used to integrate the
applications required to form complex work
ows, which are typical of multidisciplinary
simulations in engineering, in which di�erent simulation codes have to be coupled.
We present here our work in integrating TENT with the Globus Toolkit to create a
Grid computing environment. The Java Commodity Grid Toolkit has been especially
useful for this work. Copyright
c

2001 John Wiley & Sons, Ltd.
key words: Grid computing; CORBA; Component-based software; Problem Solving Environment
1. INTRODUCTION
Many of today's engineering applications require the numerical simulation of the underlying
physical processes. For example,
uid mechanics, structural mechanics, thermodynamics, and
their coupling. Performing a complex simulation is the travers of a multistage process consisting
of the preprocessing of the di�erent simulation codes, the simulations themselves and their
coupling, and the appropriate postprocessing. Often the performance requirements for such a
complex simulation can be met only by exploiting distributed computing resources. Managing
these distributed resources compounds the complexity of handling the di�erent elements of
the simulation. This increases the time for performing simulations and forms an upper bound
for the complexity of a simulation being manageable.
�
Correspondence to: A. Schreiber, DLR, SISTEC, Linder Hoehe, 51147 Cologne, Germany
y
E-mail: Andreas.Schreiber@dlr.de
Copyright
c

2000 John Wiley & Sons, Ltd.

2 A. SCHREIBER
To improve the building and managing of process chains for complex simulations, we have
developed the distributed integration and simulation environment TENT. The most important
design goals of TENT are as follows:
� Application of component technology in distributed computing.
� Visual composition of process chains (work
ows).
� Flexible con�guration, online steering, and visualization.
� Easy management of user projects.
� Easy access to interactive simulations from any computer in the net.
� Simple integrability of existing applications and their supporting tools.
� E�cient data exchange between the stages in the process chain.
TENT has been designed with a CORBA [1] based distributed component architecture. Java
is used as the implementation language for all essential parts of the system, and C++ is used
for wrapping applications to components.
The �rst version of TENT used proprietary techniques for resource and information
management, job submission, and data transfer. Currently this basic computing infrastructure
is being replaced with Globus [2, 3] services, which allow one to use TENT as an environment
for working in computational Grids [4].
2. ARCHITECTURE
The idea of TENT is to establish a framework for the integration of applications, forming
typical engineering work
ows, and allowing one to concentrate on solving simulation problems
rather than struggling with technical details such as starting applications or passing data
through the various stages of the process chain. TENT requires the application developer
simply to compose a customized process chain from elementary building blocks and to run the
simulation.
The key to an e�cient implementation of a distributed integration framework is component
technology [5]. For TENT, we have de�ned a component architecture that is speci�ed using
CORBA IDL. All programs that conform to our component architecture are called TENT
components. Because of their de�ned interfaces, they can be connected, allowing them to work
together in distributed computational environments to form complex work
ows.
The TENT system consists of several packages, each containing related components and
tools. Figure 1 shows an overview of the existing TENT packages.
� The Base System covers all basic functionality of the system needed to use it as an
integration environment. This includes a basic component for controlling work
ows,
factories for starting components and applications in the distributed environment, a
name server for managing the names and addresses of all TENT components, and a
graphical user interface
� Facilities are components that can be used as services by application components but
that are not part of the basic functionality. Examples of TENT facilities are a data
converter for seamlessly converting data between two components, and a data server for
storing data �les in databases.
Copyright
c

2000 John Wiley & Sons, Ltd. Concurrency: Pract. Exper. 2000; 00:1{7
Prepared using cpeauth.cls

THE INTEGRATED SIMULATION ENVIRONMENT TENT 3
TENT - SDK
IDL-
Interfaces
Development
Libraries GUI Control Factories
Name
Server
TENT Base System
Coupling DataConverter
Scheduling
System
Data
Server
TENT Facilities
CFD-
Wrapper
CSM-
Wrapper
VR-
Wrapper
Visualizer-
Wrapper
TENT Components
Special
controls
...
Figure 1. Packages of the TENT system
� The Components package contains wrappers for integrated applications. Currently there
are wrappers for simulation applications such as the scienti�c CFD codes TRACE [6]
and FLOWer [7], as well as commercial CSM codes such as NASTRAN [8] and ANSYS
[9] or visualization tools such as Tecplot [10], AVS [11], and Gnuplot. This package also
contains specialized control components.
� The Software Development Kit (SDK) is necessary for developing new TENT
components. It contains development libraries for C++ and Java, all IDL interfaces,
and JavaBeans [12] for the development of customized GUIs.
In the following sections, we explain the TENT system architecture and the system
components in more detail. We also describe of which parts of the system have been changed
or extended to use Grid services.
2.1. System Architecture
The TENT system consists of application components, system components, and some basic
tools. A component is a piece of software with a clearly de�ned interface. In TENT, this
interface is de�ned by means of a distributed component model which has de�nitions for the
base interface, the property model, the event model, the life cycle, and persistence. To actually
build computational work
ows in TENT, one selects needed application components from a
repository and connects them to proper process chains.
Two di�erent types of application components exist. The �rst type, an application wrapper,
represents a speci�c single application by providing a CORBA interface that conforms to the
Copyright
c

2000 John Wiley & Sons, Ltd. Concurrency: Pract. Exper. 2000; 00:1{7
Prepared using cpeauth.cls

4 A. SCHREIBER
Factory
Proxy
1
Proxy
2
Proxy
3
Proxy
4
H
os
t B
H
os
t C
Host A
Control
Factory
Component Container
Workflow Visualization (GUI)
D
at
a
Se
rv
er
N
am
in
g
Se
rv
ic
e
Fa
ct
or
y
Component
1
Component
2
Component
3
Component
4
Key:
CORBA Ref.
Program start
Figure 2. Architectural overview.
TENT component model. The wrapper interface has to provide all necessary functionalities
which is needed to work with the particular application. The second component type is a
container in which other components are grouped and connected. The container's interface
includes management functionalities, such as adding and removing components or connecting
components by events or direct references, which are used, for example, from a GUI to create
work
ows. The container implementation usually includes the necessary infrastructure (e.g.,
an event channel).
Beside the application components, several TENT system components and tools are needed
to work with the system. A necessary tool is the naming service. This is basically an ordinary
CORBA naming service at which every component registers after startup to provide its
CORBA reference to the rest of the system. Currently, the naming service is the central
information service of TENT. Another tool, the graphical user interface, allows users to
create and manage work
ows graphically, to manipulate properties of application and system
components, to control the simulation, and to view status information of a running system.
The startup of components and applications and their process control in a distributed
environment is done by factorie. At least one factory must run on every system on which TENT
components or their application has to be started. The con�guration of a factory de�nes what
component it is able to start. The con�gurations of all factories (i.e., the information about
all startable components) is also provided to a component repository, which is used to select
available components for creating work
ows.
Copyright
c

2000 John Wiley & Sons, Ltd. Concurrency: Pract. Exper. 2000; 00:1{7
Prepared using cpeauth.cls

THE INTEGRATED SIMULATION ENVIRONMENT TENT 5
Furthermore, work
ows can contain auxiliary components, called TENT facilities, that can
be used by application components. For example, a data converter can be integrated into the
data stream between two components, or a data server can be used for persistent storage of
simulation data.
The connection of components is generally done by using events, which are either statically
speci�ed in the components IDL interface or dynamically generated for sending them through
an event channel. It is also possible to perform direct CORBA method calls between
components, a useful strategy for using other components as a service or for integrating special
control components such as a script control component.
2.2. System Components and Tools
This section describes the essential system components and tools, as well as their extensions
for the Globus integration. All of them are implemented in Java, which makes them platform
independent.
2.2.1. Control Components
Basic control component.The basic control component is a simple event sender component
that can be connected to certain components in the work
ow. Like any other TENT
component, it has its own GUI representation. In this case some buttons represent the event
actions and input �elds for entering event parameters. The event sender component is currently
used to start the whole work
ow by connecting it to the actual starting point of the work
ow.
This event control is usually automatically instantiated in the root container of every work
ow.
Special control components. For specialized tasks, more sophisticated control
components exist. Depending on their task, they are connected to one or more other
components, controlling them via events, direct CORBA method calls, or property
modi�cations. They usually also provide other components with certain input data. Examples
are control components for doing parameter studies, optimizations, or trajectory computations.
Some of these examples are complex, with sophisticated user interfaces and management
functions.
Script control. To build more complex process chains, a script control mechanism is
integrated, for example, for creating loops or creating
exible reaction on di�erent states
of application components. For this, the modern object-oriented scripting language Python
[13, 14] is used. The Python control component can be included into work
ows like any other
component. Its essential property is a Python script that is started at component startup
and that reacts properly to incoming events, sends events, and evaluates properties of other
components. The script control component is implemented in Java and uses the JPython
implementation as its script interpreter.
Copyright
c

2000 John Wiley & Sons, Ltd. Concurrency: Pract. Exper. 2000; 00:1{7
Prepared using cpeauth.cls