GRAPHICAL USER INTERFACE

FOR A

VIRTUAL PIPELINE SIMULATION TESTBED

By

REVATHI MANNI RANGANATHAN

B.E., University of Madras, India, 2003

_________________________________________A REPORT

Submitted in partial fulfillment of the requirements for

the degree

MASTER of SCIENCE

Department of Computing and Information Sciences

College of Engineering

KANSAS STATE UNIVERSITY

Manhattan, Kansas

2005

Approved by:

Major Professor

Dr.Virgil Wallentine

ABSTRACT

The Pipeline Editor is the Graphical User Interface to the Virtual Pipeline Simulation

Testbed that simulates the pressure and flow rate distribution of a real pipeline system.

The GUI can be used to graphically represent the computer models of various pipeline

components like pipes, compressors and valves. The GUI is also integrated with the

sequential and parallel versions of the pipeline simulator. The GUI can be used to create

and manipulate virtual pipeline systems and acts as an interface to the sequential and

parallel simulators.

The basic version of the GUI is developed by Mr. Oyenan Walamitien, a Software

Engineering student in Computing and Information Sciences, under the guidance of

Dr.Virgil Wallentine. The GUI is built on top of an open source Java graph component

called JGraph. The Editor and the JGraph package are completely developed using Java

Swings.

The goal of this project is to extend the basic version of the GUI to represent the newly

supported pipeline components, modify the existing tool to implement the additional

requirements and to connect the GUI with the parallel and sequential simulators. New

component models like compression units and connectors are added to the GUI. The

existing pipe component is extended to represent the new requirements. The GUI can

now send data to the parallel and sequential simulators and display results generated by

them. The connection to the parallel simulator is implemented through sockets. The

connection to the sequential simulator is achieved through text files in ASCII format. The

new modules are implemented by extending the classes of the basic version of the GUI

and those of the JGraph package.

1

2

TABLE OF CONTENTS

TABLE OF CONTENTS.....................................................................................................iTABLE OF FIGURES........................................................................................................iiACKNOWLEDGEMENTS...............................................................................................iii1. Introduction:....................................................................................................................12. EARLIER WORK:..........................................................................................................1

2.1 Graphical User Interface:...........................................................................................22.1.1 GUI Features:......................................................................................................2

2.2 Job Control Optimizer:..............................................................................................32.3 Connection to the Pseudo-Simulator:........................................................................32.4 Display of the Results:...............................................................................................3

3. New Requirements...........................................................................................................43.1. Generic Connector Component................................................................................43.2. Changing the Pipe Component.................................................................................43.3 Compression Unit:.....................................................................................................43.4. Connection to the Parallel Simulator........................................................................53.5. Connection to the Sequential Simulator:..................................................................5

4. GUI Tech Choices:..........................................................................................................64.1 JGraph Design:..........................................................................................................6

4.1.1 JGraph MVC:......................................................................................................64.1.1.1 Model:..........................................................................................................74.1.1.2 View.............................................................................................................74.1.1.3 Control:........................................................................................................8

5. Software Architecture:.....................................................................................................95.1 Pipeline Editor Design:..............................................................................................9

5.1.1 Class Description:.............................................................................................105.2 Implementation Description:...................................................................................12

5.2.1 Connector Component Design:.........................................................................125.2.1.1 Class Description:......................................................................................13

5.2.2 Pipe Component Design:..................................................................................145.2.2.1 Class Description.......................................................................................14

5.2.3 Compression Unit Design:................................................................................145.2.3.1 Class Description.......................................................................................155.2.3.1 Database Design:.......................................................................................17

5.2.4 Connections to Parallel Simulator:...................................................................185.2.4.1 Class Description.......................................................................................195.2.4.2 Features:.....................................................................................................20

5.2.5 Connections to Sequential Simulator:..............................................................215.2.5.1 Features:.....................................................................................................215.2.5.2 Input Data File Generator:.........................................................................225.2.5.3 Output Data File Parser:............................................................................22

5.3 Adaptations:.............................................................................................................246. User Manual:.................................................................................................................24

i

6.1 How to use compression units:................................................................................246.2 How to use parallel simulator:.................................................................................256.3 How to use sequential simulator..............................................................................25

7.User Satisfaction:............................................................................................................267.1 Liubo Chen:.............................................................................................................267.2 Ravi Kiran Addanki:................................................................................................26

8. Conclusion:....................................................................................................................279. Appendices:...................................................................................................................27

9.1 Code:........................................................................................................................2710. References:..................................................................................................................29

TABLE OF FIGURES

Figure 1 : JGraph MVC....................................................................................................6

Figure 2 : A graph with two vertices and ports, and one edge in between...................7

Figure 3: Representation of the graph in the DefaultGraphModel..............................7

Figure 4: GraphLayoutCache and GraphModel............................................................8

Figure 5: JGraph’s Event Model......................................................................................9

Figure 6: Class Diagram.................................................................................................10

Figure 7. Database Design...............................................................................................18

Figure 8: GUI integration with the Parallel Simulator................................................20

Figure 9: Finite State Machine......................................................................................20

Figure 10: GraphParser..................................................................................................22

Figure 11: Input File Reader..........................................................................................23

ii

ACKNOWLEDGEMENTS

I sincerely thank Dr.Virgil Wallentine, my advisor, for giving me the

opportunity to work on this project. I also thank him for being flexible,

supportive and encouraging during the course of this project.

I’m grateful to Dr. Dan Andresen and Dr. Prakash Krishnamurthy for

serving on my committee and agreeing to review my report.

I thank my predecessor Oyenan Walamitien for the excellent documentation of the Pipeline Editor.

I also thank my colleagues Liubo Chen and Ravi Kiran Addanki for their

valuable feedback.

I am indebted to my parents for their love, support and encouragement.

iii

1. Introduction:The purpose of this report is to document the design and implementation of the Pipeline

Editor, the Graphical User Interface for the Virtual Pipeline Simulation Testbed that

models and simulates the pressure and flow rate distribution of gas in a real pipeline

system. The Pipeline Editor enables the user to create and manipulate model pipeline

systems. The Pipeline Editor is integrated with the Parallel and Sequential versions of a

simulator that simulates the behavior of each component in the model pipeline system by

solving a set of partial differential equations. The basic GUI for drawing the pipeline

system was developed by Mr. Oyenan Walamitien, a Software Engineering student in

Computing and Information Sciences, under the guidance of Dr.Virg Wallentine. The

GUI is built on top of an open source Java graph component called JGraph. This report

mainly aims at documenting the various extensions to the Pipeline Editor like integrating

with the Parallel simulator, integrating the Sequential Simulator, addition of a generic

Connector Component, addition of new component called Compression Unit and

modification of the Pipe component to meet the new requirements. This document

explains the design and structure of the basic tool, the design of the underlying software

package called JGraph and the implementation details of the above mentioned extensions

to the GUI.

The report starts with a brief overview of the earlier work by Oyenan and the new

requirements that should be satisfied. This is followed by the design description of the

JGraph package and the Pipeline Editor. Then the implementation details of the modules

added to meet the new requirements are provided. The report is complete with a user

manual that explains the functions of the new modules and the code that implements

these new functions.

2. EARLIER WORK:The Pipeline Editor, the GUI for the Virtual Pipeline Simulation Testbed, is developed by

Mr. Oyenan Walamitien, a Software Engineering student from the Department of

Computing and Information Sciences. The software developed by Oyenan include a GUI

1

and a job distribution optimizer for a Virtual Pipeline Simulation Testbed that can

simulate the pressure and flow distribution in a gas pipeline system. The GUI is used to

create and manipulate the pipeline system. The Job-Control Optimizer is used to

efficiently distribute computation among several machines. The GUI was also integrated

with a pseudo simulator (that could send some random data to the GUI) and was capable

of displaying the results back from it.

The tool is developed in Java Swings and built on top of JGraph, a Java graph drawing

and layout component also purely based on Java Swings. A basic introduction to the

earlier world done by Oyenan is as follows :

2.1 Graphical User Interface:

The GUI is an interface to the Virtual Pipeline Simulation Testbed. The users can draw

and manipulate a pipeline system using the GUI. Once the pipeline system is drawn, it

can be simulated and the simulation results will be displayed at the GUI.

2.1.1 GUI Features:

a) The Editor supports drag and drop operations for drawing various Pipeline

Components like pipes, compressors, joints.

b) The Components supported by the initial version of the GUI were Pipes,

Compressors, 2-way & 3-way Splits, 2-way and 3-way Combines, Joints and

Valves.

c) The editor supports standard editing functions like copy, cut and paste.

d) The editor supports zoom functions where a portion of the graph can be zoomed

in or out.

e) The editor also supports moving the components for better positioning.

f) The user can change the parameters of the various pipeline components.

g) The editor supports storage and retrieval of previously drawn pipeline systems.

h) The results from the Simulator could be displayed at the GUI.

i) The Editor can be started from any machine using only a browser and Java Web

Start.

2

2.2 Job Control Optimizer:

The software developed by Oyenan also included a Job-Control Optimizer for the

purpose of reducing the time required for simulation by efficiently distributing the

computation among several machines. The optimizer achieves this by producing a job

allocation that balances the load of each processor by minimizing the load difference

among the cluster machines involved in the simulation. The jobs are the pipeline

components like pipes, joints and compressors with some computation time and some

communication time. Computation time of a job is based on the component it represents

and the machine it is executed on. The communication time of a job depends on the

amount of information exchanged and the locality of the connected components. The

communication will be local if the connected components are on the same machine and

remote if they are on different machines.

The optimizer finds an optimal distribution of the jobs among machines that minimizes

the workload of each machine. The job allocation optimization is a discrete optimization

problem. The optimizer uses the Branch and Bound algorithm to find the best distribution

given some time and communication constraints. The solution may not be optimal but

will be very close to the optimal one. The optimizer outputs a list of all jobs along with

the machines on which they should be executed in order to have the best distribution.

2.3 Connection to the Pseudo-Simulator:

The software developed by Oyenan included a pseudo-simulator that the GUI could

communicate with. The pseudo-simulator is a simple program that can simulate the

communication behavior of the actual parallel simulator. This was used to test the

communication between the GUI and the actual Simulator before the Parallel Simulator

was developed.

2.4 Display of the Results:

The GUI was capable of receiving the results from the pseudo-simulator and displaying it

simultaneously. The results were viewed in the result panel available with the pipeline

components. The user has the option of viewing the results as the simulator progresses or

after the simulation ends. The user can also view the results by replaying them after the

3

simulation ends. The displayed data changes automatically as the simulation progresses at

the server side and the new data are received.

3. New Requirements

3.1. Generic Connector Component

The 2-way Split, 3-way Split, 2-way Combine and 3-way Combine were to be replaced

by a single generic type component called Connector. The Split and the Combine

components are used to connect the Pipes and the Compressor Stations together in

practice. They were mainly used to connect a two or more pipeline components in

parallel. Since in real pipelines more than two components are connected in parallel, a

new component was required that would connect multiple components in parallel. The

Connector component satisfies this requirement. A Connector can be drawn with as many

incoming and outgoing branches as required. Any type of pipeline component can be

connected to these connections using Pipes.

3.2. Changing the Pipe Component

Pipes, in gas pipeline system comprise a number of nodes across the length of the

component. The Pipe component was required to represent at least the leftmost and the

right most node since it is not possible to graphically represent all the nodes in a pipe.

The new Pipe component will have a left and right node and separate property panels for

these nodes. Users will be able to set different values for parameters of the right and left

node of the Pipe component. Similarly the output from the simulation result will be

different for the left and the right node and hence there is a different display panel for

each of the nodes.

3.3 Compression Unit:

A Compression Unit comprises of a driver and compressor. Previously only compressor

component were used that could represent only one type of compressor called Centrifugal

Compressor. A generic Compression Unit component that would represent each of the

four Compression Unit types, namely Reciprocating Engine-Reciprocating Compressor,

4

Reciprocating Engine-Centrifugal Compressor, Gas Turbine-Reciprocating Compressor,

and Gas Turbine- Centrifugal Compressor, is to be developed. The generic Compression

Unit component will take as input the driver type and the compressor type from the user

and construct the specific Compression Unit with the required set of properties. Once the

types of driver and Compressor that will constitute the compression unit are chosen, the

user should be able to choose the specific driver and compressor models from the already

available sets of models. Each unique combination of driver and compressor model has a

name that is also stored in the database along with the combination. The user should be

able to define his own combination of driver and compressor models. If the user chooses

a combination that is not already present in the database of Compression Units, there

should be provision for storing the user-defined combination under a new name.

3.4. Connection to the Parallel Simulator

The GUI has to be connected to the Parallel Simulator. The data entered by the user has

to be sent to the Parallel Simulator. The results from the Parallel Simulator have to be

displayed at the respective components in the GUI. The connection between the GUI and

the Simulator is through sockets. The user should be able to pause the simulation, replay

the simulation results, fast forward or backward the results by a single step or desired

number of steps. The user should also be able to stop the simulation anytime before

completion. The user commands from the GUI should be passed on to the remote Parallel

Simulator instantaneously and the response should be transmitted back to the user with

minimum delay.

3.5. Connection to the Sequential Simulator:

The GUI has to be integrated with the Sequential Simulator developed using FORTRAN.

The information in the pipeline graph drawn by the user has to be converted into a text

file that can be fed to the Sequential Simulator. The Sequential Simulator will work on

this input and generate results in the form of a standard output file. The information from

the text file outputted by the Sequential Simulator has to be parsed and the results should

be displayed graphically on the GUI. The users should also be able to stop, pause, step

5

forward or backward by a single or many steps as desired by the user as if the simulation

is done real time.

4. GUI Tech Choices:

4.1 JGraph Design:

JGraph is a Java swing component for graphs used in applications needing graph model

representation like the Virtual Pipeline Simulation Testbed. JGraph is a complete and

robust open-source package based on Swing MVC pattern. JGraph is based on the

mathematical theory of networks, called graph theory, and the Swing user interface

library. Graphs are used as a paradigm in Jgraph to display any network of related objects

(like pipeline components in Virtual Pipeline Simulation Testbed) and Java Swing is used

to define the architecture. By combining these two, a Swing user interface component to

visualize graphs is obtained. The JGraph component supports all standard features

required for a Graphical User Interface like cut, copy, paste, drag and drop, undo, zoom

and many more. The features offered by JGraph makes it ideal as a base for developing

the Pipeline Editor. It is important to understand the design of the JGraph package in

order to under stand the software architecture of the Pipeline Editor.

4.1.1 JGraph MVC:

Figure 1 : JGraph MVC

6

The JGraph component is largely based on JTree, the Java Swing’s component for trees.

But it is not an extension of JTree, but a modification of JTree’s source code. The basic

structure of the JGraph component, namely Swing MVC design pattern, is used to

separate the model from the view and establish a relation between them, such that more

than one view can be attached to the same model, and all views are automatically updated

when the model changes.

4.1.1.1 Model:

The model provides the data for the graph, consisting of the cells, which may be vertices,

edges or ports, and the connectivity information, which is defined using ports that make

up an edge's source or target. This connectivity information is referred to as the graph

structure.

Figure 2 : A graph with two vertices and ports, and one edge in between

Figure 3: Representation of the graph in the DefaultGraphModel

4.1.1.2 View

The view in JGraph is somewhat different from other classes in Swing that carry the term

view in their names. The difference is that JGraph's view is stateful, which means it

contains information that is solely stored in the view. The GraphLayoutCache object and

7

the CellView instances make up the view of a graph, which has an internal representation

of the graph's model.

Figure 4: GraphLayoutCache and GraphModel

The GraphLayoutCache object holds the cell views, namely one for each cell in the

model. These views are kept in two structures, an array that holds the port views, and a

list that holds the views for the root cells. Thus, ports and other cells are kept in different

data structures in the graph view, whereas in the model, they are kept in the same

structure. The graph view also has a reference to a hash table, which is used to provide a

mapping from cells to cell views. The inverse mapping is not needed, because the cell

views point to their corresponding cells.

4.1.1.3 Control:

The control defines the mapping from user events to methods of the graph- and selection

model and the view. It is implemented in a platform-dependent way in the UI-delegate,

and basically deals with in-place editing, cell handling, and updating the display. As the

only object that is exchanged when the look and feel changes, the UI-delegate also

specifies the look and feel specific part of the rendering.

In JGraph, the graph model, selection model and graph view may dispatch events. The

events dispatched by the model may be categorized into

1. Change Notification

2. History Support

8

Figure 5: JGraph’s Event Model

The GraphModelListener interface is used to update the view and repaint the graph, and

the UndoableEditListener interface to update the history. These listeners may be

registered or removed using the respective methods on the model.

The selection model dispatches GraphSelectionEvents to the GraphSelectionListeners

that have been registered with it, for example to update the display with the current

selection. The view's event model is based on the Observer and Observable class to

repaint the graph, and also provides undo-support, which uses the graph model's

implementation.

5. Software Architecture:

5.1 Pipeline Editor Design:

The Pipeline Editor is built on top of the JGraph package. Hence, most of the classes of

the Pipeline Editor are an extension of the classes of JGraph. MyGraph, the main class of

the Pipeline Editor used to model the pipeline graph, is an extension of the class JGraph.

Thus most of the features necessary for the GUI like cut, copy, paste, move, drag and

drop are available at a single function call to the parent class. The GUI software basically

comprises of the following three packages:

1. JGraph

9

2. Editor

3. Optimizer

5.1.1 Class Description:

The classes of the Pipeline Editor are listed below along with their brief description and

function. The classes that are colored pink are JGraph’s classes, yellow ones are by

Oyenan and the blue ones are the classes added to implement the new requirements.

Figure 6: Class Diagram

Class Editor extends JPanel:This is the main class representing the main panel of the application. It has the graph panel (instance of JGraph) and the toolbars. This class also contains handles to threads that communicate with the parallel and sequential simulators.

10

Class MyGraph extends JGraph:Provide a custom graph model. Contains all the necessary methods to create and insert custom components in the graph.

Class MyMarqueeTransferHandler extends MarqueeTransferHander:Provides a custom mouse handler for the graph. Provides custom edges used to represent pipes.Creates popup dialogs.

Class MyModel extends GraphModel:Defines the criteria to accept the connection edge (pipe) and cell (component)

Class MyPortView extends Port view:Defines a custom representation of ports.

Class MyGraphTransferHandler extends GraphTransferHandler:Provides drag and drop support for the graph.

Class ButtonTransferHandler extends TransferHandler:Transfer Handler for dragging the buttons from the toolbar.

Class DataCell extends DefaultGraphCell:This cell is a JPanel.Defines a cell used to display data from the simulation.

Class DataRenderer extends VertexRenderer:Used to draw the DataCell as a JPanel containing information to be displayed.

Class MyCell extends DefaultGraphCell:Abstract class for all the custom cells representing the components.Each MyCell object has a reference to a DataCell.

Class MyEdge extends DefaultEdge:Abstract class for the pipe component that connects any two component.Each MyEdge object has a reference to two DataCells.

Class CompressionUnitCell extends MyCell:Represent a component cell. The component is a compression unit. Each component cell has a DataCell and a MyUserObject to hold information about the cell.There is a similar class for each component (Pipe, Joint, Connector…).

Class CompressionUnitView extends VertexView:Define the shape of the component.There is similar class for each component (Pipe, Joint, Connector …).

11

Class MyUserObject extends Object:Holds the property of the associated object (component) in a map for future reference.Displays the property dialog for each component.

Class Optimizer:Create JobComponent objects from component cells taken from the graph.Each component cell has a corresponding JobComponent.Holds a reference to BranchBound class to start the optimization.

5.2 Implementation Description:

5.2.1 Connector Component Design:

The Connector Component replaces the four junction components called 2-way

Split, 3-way Split, 2-way Combine, 3-way Combine. These components

were used to connect to connect pipeline components in parallel. The Connector

component is a generic component that replaces all the above four components. The

Connector component can have any number of incoming and outgoing branches as

desired by the user during run time. The branches are unidirectional. The branches on the

left side of the Connector are incoming branches and only incoming pipe connections can

connect to them. The branches on the right side of the Connector are outgoing branches

and only outgoing pipes can connect to them. The number of incoming branches can be

different from the number of out going branches. Any of the available pipeline

components can be connected to these branches through a pipe component.

A Connector can have more than two ports which are the entry or exit points in a

component. Ports are the source or target of the edges that connect the components. All

other components except the Connector have one (eg. Delivery point, Receipt Point) or

two ports (eg. Compressor, Compression Unit) that other components can connect to.

These ports are named ‘right’ and ‘left’. Since connectors can have any number of

branches and each branch should contain a port, the ports in Connectors are named in a

different way. The ports are numbered in increasing order along the anticlockwise

direction starting from the leftmost branch. This port number is important when the

12

connectivity information among the various job components is rebuilt on the Parallel

Simulator side. In this document, the terms ports and branches are used interchangeably.

The implementation of the Connector component required construction of the three

classes- ConnectorCell to hold the information represented by the connector component,

ConnectorView to render the Connector component, Connector to represent the job

component of a connector. The following is a description of the above classes along with

the additional methods required for the implementation of the generic type connector

component.

5.2.1.1 Class Description:

Class ConnectorCell extends MyCellRepresents the Connector component cell. It has a MyUserObject and DataCell to hold information about the represented component. It also holds information about the number of in coming and out going branches.

setInCount(inCount)Sets the number of in coming branches the Connector should contain.

setOutCount(outCount)Sets the number of out going branches the Connector should contain.

getInCount()Returns the number of in coming branches the represented Connector contains.

getOutCount()Returns the number of outgoing branches the represented Connector contains.

Class ConnectorView extends VertexViewDefines the view for the Connector component.Contains an inner Renderer object that provides the paint method to render the component.

Class Connector extends JobComponentRepresents a job component of type ConnectorHolds the properties of the Connector and their initial values.

putJoint (joint, portName)Maps the branch of the connector to the joint it is connected to.

13

getBranch (joint)Returns the branch number the given joint is connected to.

5.2.2 Pipe Component Design:

The earlier implementation of pipe cell directly used the JGraph’s DefaultEdge class

since no additional features were required. Since the new requirement of the pipe

component needed it to represent two nodes each having a property and data display

panel, DefaultEdge was extended to MyEdge. MyEdge contains two DataCell objects to

hold the simulation data of the two nodes.

5.2.2.1 Class Description

The class description of the class MyEdge is given below along with the description of

some of the important methods.

Class MyEdge extends DefaultEdgeRepresents the pipe component.MyEdge holds two DataCell objects to hold information about the rightmost and the leftmost node of the pipe.

setDataCell (leftDataCell, rightDataCell)Sets the Datacell objects for the leftmost and the rightmost node of the represented pipe component.

getLeftDataCell()Returns the DataCell associated with the leftmost node of the represented pipe component.

getRightDataCell()Returns the DataCell associated with the rightmost node of the represented pipe component.

5.2.3 Compression Unit Design:

A Compression Unit comprises of a driver and a compressor. The driver can be one of

the 2 types – Reciprocating Engine (RE), Gas Turbine (GT). Similarly, the compressor

can be either a Reciprocating Compressor (RC) or a Centrifugal Compressor (CC). So the

Compression Unit component can be one of the following four types:

14

1. Reciprocating Engine – Reciprocating Compressor (RERC)

2. Reciprocating Engine – Centrifugal Compressor (RECC)

3. Gas Turbine – Reciprocating Compressor (GTRC)

4. Gas Turbine – Centrifugal Compressor (GTCC)

Compression Unit component is a generic component and all the above four types can be

represented using it. The two types of drivers differ in their properties. Similarly the

compressor types also differ in their properties. Further a single type of driver or

compressor will consist of many specific models of drivers and compressors. Though the

properties are the same for all the driver models belonging to the same type, the values of

these properties may differ from one driver model to another. The same applies for

different compressor models belonging to the same type. Once the user chooses the

desired combination of the driver and compressor types that constitute the Compression

Unit, a 2-tabbed panel with the available list of compressor and driver models appears.

Then he/she can choose the specific compressor and driver model they want from the

lists. Each unique combination of driver and compressor model will have a unit name.

The user may also change the values of one or more properties of the driver or

compressor model. But if any of the values of the properties is altered, the driver or

compressor model can be stored only under another unique name in the database.

Likewise if the driver or compressor model name is changed, the unit name must also be

changed. All the data belonging to the driver and compressor models and Compression

Units are stored and retrieved from a central database.

The implementation of the Compression units consist of a single class called the

CompressionUnitCell to hold information about the properties. However, there is a

separate UserObject for each of the four types. The CompressionUnitCell contains

information about the type of the unit and holds the UserObject for the compression unit.

5.2.3.1 Class Description

Class CompressionUnitCell extends MyCellRepresents the Compression unit component.Holds the UserObject for the represented compression unit component.Contains information about the driver and compressor type that comprise the represented unit.

15

setCompressorType (compressorType)Sets the type of the compressor in the compression unit.The compressor can be of type reciprocal or centrifugal

setDriverType (driverType)Sets the type of the driver in the compression unit.The driver can be of type reciprocal or gas turbine

getCompressorType ()Returns the type of the compressor in the compression unit

getDriverType()Returns the type of the driver in the compression unit.

getUnitType ()Returns the type of the compression unit represented.

Class CompressionUnitView extends VertexViewDefines the view for the connector component.Contains an inner Renderer object that provides the paint method to render the component.

Since the properties differ for the four types of compression Units, the userObject that

holds the properties for a component also differs correspondingly. Hence the four

compression unit components are represented by different types of job components

namely, RERCCompressionUnit, GTCC CompressionUnit, RECC CompressionUnit,

GTRC CompressionUnit. These job components are similar to those of the other

components except a few additional methods to set and get the driver and compressor

names. The name of a compressor or driver refers to its model and not the type it belongs

to.

Class GTCCCompressionUnit extends JobComponentDefines the properties of a GTCCCompressionUnit.Values of the component’s properties are fetched from the corresponding userObject

setName (unitName)Sets the name for the represented CompressionUnit.

setCompName (compName)Sets the name of the centrifugal compressor in the represented CompressionUnit.

setDriverName (driverName)

16

Sets the name of the gas turbine in the represented CompressionUnit.

getName ()Returns the name of the represented Compression Unit.

getCompName ()Returns the name of the centrifugal compressor in the represented Compression Unit.

getDriverName ()Returns the name of the gas turbine in the represented Compression Unit.

There is a similar job class for each of the other three compression unit types.

5.2.3.1 Database Design:

Given below is the database diagram containing all the tables used in the implementation

of the compression unit component. The different types of drivers and compressors that

constitute the compression units have different sets of properties. The properties can be

grouped as follows:

Simulation Data

Operational Data

Manufacturer’s Data

The simulation data contains those properties that will change during the course of

simulation. The operational data contains those properties that can be changed by the

user. The manufacturer’s data contains the properties that are supplied by the

manufacturer of the model. The database is a straight forward implementation of the

compression unit design. Reciprocating engine contains all the three groups of data. So

there are three tables to store the properties of reciprocating engine. Reciprocating

compressor has only manufacturer’s data and operational data thus requiring only two

tables. There is also a table to store all the unique combination of compressor and driver

models available.

17

Figure 7. Database Design

5.2.4 Connections to Parallel Simulator:

The communication between the GUI and the Parallel Simulator is through sockets. Since

the Pipeline Editor actually simulates the pressure and flow distribution that is happening

in a real pipeline system which involves some tedious computations, the simulation will

be done on several powerful computers in order to meet the timing constraints. So, the

input is first passed to a Job-Control Optimizer which efficiently distributes the

computation among several machines. The graph drawn by the user which is in .vps

format is fed to the Optimizer which in turn outputs a file in .opt format. This output is in

turn fed to the Parallel Simulator.

18

The Pipeline Editor comprises of three separate threads running in Parallel. The user

interface runs on one thread while two threads are required for communicating with the

Parallel Simulator. This is necessary for the user to be able to work on the GUI while it

converses with the Parallel Simulator running on the remote server. The communication

between the GUI and the Parallel Simulator consumes two threads. One thread is used to

send the user commands from the GUI to the parallel simulator and the other thread is

used to receive the results and status messages from the parallel simulator. This is

necessary for getting instantaneous results for user commands. SimulatorClient passes

user commands from the GUI to the parallel simulator where as SimulatorDataClient

passes results and status messages from the parallel simulator to the GUI.

5.2.4.1 Class Description

Class SimulatorClientConnects to the simulator on the server side.Runs as a separate thread to avoid freezing the GUI.Gets commands from the Editor and passes them to the simulator.

Class SimulatorDataClientConnects to the simulator on the server side.Runs as a separate thread to avoid freezing the GUI.Gets results and error messages from the simulator on the server side and passes them to the Editor.

19

Figure 8: GUI integration with the Parallel Simulator

Figure 9: Finite State Machine

5.2.4.2 Features:

Simulate: This command is used to simulate the graph currently displayed at the GUI

using the Parallel Simulator.

Stop: This command is used to stop the simulation in progress.

Pause: This command is used to pause the simulation in progress.

Resume: This command resumes the paused simulation.

Replay: This command is used to replay the results of a previously completed

simulation.

Step Forward: This command is valid only during replay and is used to skip forward

one step in the simulation results.

20

Step Backward: This command is also valid only during replay and is used to skip

backward one step in the simulation results.

Skip Forward: This command is also valid only during replay and is used to skip

backward any desired number of steps in the simulation results.

Skip Backward: This command is also valid only during replay and is used to skip

backward any desired number of steps in the simulation results.

5.2.5 Connections to Sequential Simulator:

The communication between the GUI – Sequential Simulator is through text files in

ASCII format. When the user designs a graph modeling a pipeline network on the GUI,

he/she can choose to simulate it using the Sequential Simulator. This can be achieved

either by pressing the Sequential Simulator button in the tool bar or by choosing the

‘Start Sequential Simulation’ menu from the menu bar. This single command will start a

three step process. First, the GUI will output an input data file, representing the

components in the pipeline network in text format. This input data file will contain the

properties of the components of the input graph in a predefined standard format. The

input data file will be then inputted to the Sequential Simulator which will process it and

output the results in an output data file. The output data file will also be in a predefined

standard format. This output data file will in turn be read by the GUI and the results will

be displayed graphically.

5.2.5.1 Features:

Simulate: This command is used to simulate the graph displayed at the GUI using the

Sequential Simulator.

Stop: This command is used to stop the Simulation in progress.

Pause: This command is used to pause the Simulation in progress.

Resume: This command resumes the paused Simulation to continue.

Step Forward: This command is used to skip forward one step in the simulation results.

21

Step Backward: This command is used to skip backward one step in the simulation

results.

Skip Forward: This command is used to skip backward any desired number of steps in

the simulation results.

Skip Backward: This command is used to skip backward any desired number of steps in

the simulation results.

5.2.5.2 Input Data File Generator:

The GraphParser parses the graph required to be simulated by the sequential simulator

and extracts the data from all the components in the graph. The values of different

parameter values of each of the component present in the network graph are then printed

as ASCII text in a predefined standard format. This data file is called input data file

because it will be the input to the sequential simulator. The sequential simulator will

process this data file and generate the simulation results. Thus the input provided by the

user in graphical format is converted into text format in order to be fed to the sequential

simulator.

Figure 10: GraphParser

Class GraphParserParses the garph collecting each component's properties.Counts the number of component of each type.

5.2.5.3 Output Data File Parser:

The sequential simulator outputs the simulation results in an ASCII text file predefined

standard format. The result has to be displayed graphically at the GUI. The sequential

22

Simulator at the GUI parses this output text file, and updates all the components at the

GUI with the parameter values changed after simulation. The SequentialSimulator at the

client-side acts as a pseudo-simulator by reading the output file step by step and

displaying the result simultaneously giving the effect of a simulator running in the

background. Like in the case of the Parallel Simulator, there is a separate thread called

SequentialSimulatorClient that passes the user commands to the simulator which in this

case is the SequentialSimulator. Since the results are displayed at the GUI only after the

simulation ends, there is no need for a replay command in Sequential Simulation.

Figure 11: Input File Reader

Class SequentialSimulatorParses the output file from the SequentialSimulator and displays the result.Runs as a separate thread to avoid freezing the GUI.

Class SequentialSimulatorClientReceives and services the commands from the user and passes it to the SequentialSimulator.Runs as a separate thread to avoid freezing the GUI.

23

5.3 Adaptations:

The implementation of the new requirements involved many modifications to the basic

version of the Editor as developed by Oyenan. The basic version of the Pipeline Editor

supported most of the features required for component visualization like drawing

component icons, displaying property panel and a data panel to view simulation results.

However when new complex component types were required to be supported, the basic

classes of the GUI had to be modified and extended. In the basic version the properties of

all components except pipes were represented by a single UserObject using a HashTable.

The problem with this implementation was that the order in which the properties were

displayed was completely random. They also shared the display method to draw the

property panel. But now each component type has a customized userObject and

customized display method to draw property panels. This will ensure that each

component can have its own customized property panel where properties can be grouped

more meaningfully.

6. User Manual:

6.1 How to use compression units:

The compression Unit can be added to the graph by double clicking or dragging and

dropping the compression Unit icon in the vertical toolbar. The compression Unit can

only be added to a station and not directly to the main graph panel. Once the compression

Unit is added, the combination type of the driver and the compressor can be selected from

the drop down menu that appears. After the driver-compressor combination type is

chosen, the user will get a two-tabbed panel where the one tab is for the driver and the

other tab is for the compressor. The user has to chose the specific driver and compressor

model from the drop-down list of driver and compressor models available. This list is

populated from a central database.

The user can also change the property values in the driver or compressor model. Once

any property value is changed, the user can only save the model under a new name which

24

is not already in the database. Similarly, if the driver or compressor model changes, the

unit type for the new combination also should be changed.

6.2 How to use parallel simulator:

In order to use the parallel simulator, the user should optimize the graph before

simulating it using the parallel simulation option. The optimizer can be started from the

toolbar or menu bar. Once the optimizer is started, the user will not be able to use the

GUI until the optimization completes. Once the optimization completes, the user can start

the simulator by clicking on the parallel simulator button in the horizontal toolbar. It will

be a few seconds before the results start appearing in the GUI. To view the simulation

result, the user has to right-click on the desired component and choose the ‘View Data

Cell’ option. The user can stop, pause, resume the simulation any time when the

simulation is in process. Once the simulation is complete, the user can choose to playback

the results of the simulation as many times as desired. During replay, the user can also

step forward or backward the replay by 1 or more simulation steps.

If the optimization and simulation are not done in a stretch, it is required to save the

graph once the optimization is finished. A graph saved like this can be opened again and

simulation can be started without the need to optimize again.

6.3 How to use sequential simulator

The sequential simulator cannot be used in parallel like the parallel simulator. The

procedure to use the sequential simulator is to draw the graph and choose the sequential

simulator option. The GUI will output a text file, that can be inputted to the Sequential

Simulator. This input file is processed by the Sequential Simulator and the results are

generated in another output file. The GUI can parse this output file and display the results

graphically as if the simulation is happening in parallel. So replay mode has no meaning

in the Sequential Simulation. The user can still step forward or back ward the results by

one or more simulation steps.

25

7.User Satisfaction:

7.1 Liubo Chen:

Mr. Liubo Chen, a graduate student in Computing & Information Sciences developed the

Parallel Simulator, under the guidance of Dr.Virgil Wallentine. As a programmer, he has

used the Pipeline Editor to create model pipeline systems to test the Parallel Simulator

and to control the Parallel Simulator via the GUI.

Feedback: The GUI application at the client-side of the VPST system was developed on

the basis of JGraph, which is a graph component written in 100% pure Java and provides

features such as zooming, folding, undo, drag and drop and much more. The GUI

application fully implements these features and let users construct a natural gas pipeline

system via drag-and-drop. The interface is very friendly.  In addition, it supports

server/client computation. It can send requests to the server (simulator) and display the

results back from the server in real-time. In the future, more components may be

supported. The display of the results may be improved. In a word, the GUI is excellent.

7.2 Ravi Kiran Addanki:

Mr. Ravi Kiran Addanki, a graduate student in Department of Mechanical and Nuclear

Engineering, is developing a version of the Sequential Simulator, under the guidance of

Dr. Prakash Krishnaswami. As the Sequential Simulator programmer, he regularly uses

the Sequential Simulator for creating pipeline systems that server as input to the

Sequential Simulator and to test the new pipeline components.

Feedback: The GUI for the VPST is a very useful tool for the user to create any pipeline

network and run the simulation process. The GUI in its present form contains all the basic

components that a Pipeline network comprises off. It allows the user to draw a network

just by drag and drop. The icons provided for each component are associated with the

parameters that define them. The GUI also allows the user to concentrate on a particular

part of a large network by a ZOOM operation. After creating the network and entering

the required data and on starting the simulator the GUI generates an output file in a

26

specific format in which the sequential code for VPST reads in the data and starts the

simulation process. At every time step the sequential code generates an output file again

in a particular format which has the changing values of the state variables with respect to

time. This information is then displayed on the GUI at the respective component heads

and used for post processing. The future work on the GUI should include data post

processing with the GUI being able to display the various parameters with respect to time

and space in graph format.

8. Conclusion:The Pipeline Editor can be used to simulate the behaviour gas in a real pipeline system.

All the requirements of the system have been met and the GUI is fully functional. The

Editor can be used to create pipeline systems graphically, manipulate the component

properties, and simulate the model using one of the two available versions of the Pipeline

Simulator. The user can choose to simulate using the parallel simulator or the sequential

simulator. The Editor will be easy and powerful tool to simulate pipeline networks and

visualize the results.

The report documents the design, architecture and implementation of the software

modules added to the Pipeline Editor. The report is complete with a user manual that

explains the features added to the Pipeline Editor and instructions on how to use them.

9. Appendices:

9.1 Code:

The code used in the implementation can be found in the attached CD-ROM. The source

code is distributed across three packages:

1. Editor

2. optimizer

3. gif

4. org

The Editor package contains the classes directly used in the implementation of the GUI.

27

The Editor package contains the other three packages. The optimizer package contains

classes used in the implementation of the Job-control optimizer. The gif package contains

the image icons used in the GUI. The org package contains the class files of all the

JGraph classes used in the implementation of the GUI.

28

10. References:1. www.jgraph.org

2. Mr. Oyenan Wallemitien’s documentation on the Pipeline Editor

29