Iowa State University Capstones, Theses and

Retrospective Theses and Dissertations

Dissertations

1992

Development of a process simulator using object

oriented programming: Information modeling and
program structure
Gadiraju V. Varma
Iowa State University

Follow this and additional works at: https://lib.dr.iastate.edu/rtd

Part of the Chemical Engineering Commons

Recommended Citation
Varma, Gadiraju V., "Development of a process simulator using object oriented programming: Information modeling and program
structure " (1992). Retrospective Theses and Dissertations. 10355.
https://lib.dr.iastate.edu/rtd/10355

This Dissertation is brought to you for free and open access by the Iowa State University Capstones, Theses and Dissertations at Iowa State University
Digital Repository. It has been accepted for inclusion in Retrospective Theses and Dissertations by an authorized administrator of Iowa State University
Digital Repository. For more information, please contact [email protected].
MlCROnLMfiD 1992
 INFORMATION TO USERS

This manuscript has been reproduced from the microfilm master. UMI
films the text directly from the original or copy submitted. Thus, some
thesis and dissertation copies are in typewriter face, while others may
be from any type of computer printer.

The quality of this reproduction is dependent upon the quality of the

copy submitted. Broken or indistinct print, colored or poor quality
illustrations and photographs, print bleedthrough, substandard margins,
and improper alignment can adversely affect reproduction.

In the unlikely event that the author did not send UMI a complete
manuscript and there are missing pages, these will be noted. Also, if
unauthorized copyright material had to be removed, a note will indicate
the deletion.

Oversize materials (e.g., maps, drawings, charts) are reproduced by

sectioning the original, beginning at the upper left-hand corner and
continuing from left to right in equal sections with small overlaps. Each
original is also photographed in one exposure and is included in
reduced form at the back of the book.

Photographs included in the original manuscript have been reproduced

xerographically in this copy. Higher quality 6" x 9" black and white
photographic prints are available for any photographs or illustrations
appearing in this copy for an additional charge. Contact UM directly
to order.

University Microfilms International

A Bell & Howell Information Company
300 North Zeeb Road, Ann Arbor, Ml 48106-1346 USA
313/761-4700 800/521-0600
 Order Number 9234868

Development of a process simulator using object-oriented

programming: Information modeling and program structure

Varma, Gadiraju V., Ph.D.

Iowa State University, 1992

UMI
300N.ZeebRd.
Ann Arbor, MI 48106
 Development of a process simulator using object oriented programming:
Information modeling and program structure

by

Gadiraju V. Varma

A Dissertation Submitted to the

Graduate Faculty in Partial Fulfillment of the

Requirements for the Degree of

DOCTOR OF PHILOSOPHY

Major: Chemical Engineering

Approved:
Signature was redacted for privacy.
In Charge of Major Work
Signature was redacted for privacy.
For the MajoKBepartment
Signature was redacted for privacy.
For the Graduate College

Iowa State University

Ames, Iowa
1992
 ii

TABLE OF CONTENTS

ACKNOWLEDGEMENTS viii

CHAPTER 1. INTRODUCTION 1

CHAPTER 2. LITERATURE REVIEW 5

Process Simulation 5

Object Orientation 7

Process Integration 18

CHAPTER 3. INFORMATION MODELING 23

Object Design Criteria 28

Modeling Concept Analysis 29

Programming Feature Analysis 33

CHAPTER 4. PROGRAM STRUCTURE 37

Physical Quantity System 41

Units of measurement 41

Physical quantities 46

Dimensional expressions 47

Physical Property System 50

Chemical components 51
 iii

Physical properties 59

Component data bank 63

Flowsheet System 68

Balance equations 69

Process flowsheeting 76

CHAPTER 5. CONCLUSIONS 85

CHAPTER 6. RECOMMENDATIONS 87

BIBLIOGRAPHY 89

APPENDIX A. LIST OF OBJECTS 92

APPENDIX B. C++ CONSTRUCTS 101

 iv

LIST OF TABLES

Table 4.1: Operations around dimension 42

Table A.l: List of objects 92

Table B.l: C++ constructs 101

 V

LIST OF FIGURES

Figure 2.1: Object oriented process simulation 7

Figure 2.2: The realm of object orientation 8

Figure 2.3: The concept of object 9

Figure 2.4: Our view of simulation 10

Figure 2.5: ASPEN's view of simulation 10

Figure 2.6: Class and instance objects 12

Figure 2.7: The concept of encapsulation 13

Figure 2.8: Typical syntax for messaging 16

Figure 2.9: Flow of execution in OOPL 17

Figure 2.10: The concept of inheritance 18

Figure 2.11: One-to-many interface approach to integration 19

Figure 2.12: Object oriented process integration 20

Figure 3.1: Variations of the object component flowrate 25

Figure 3.2: Stream involving component flowrate 26

Figure 3.3: Representation of time and temperature 27

Figure 3.4: Representation of velocity 27

Figure 3.5: Operation tree 31

 vi

Figure 4.1: Simplified picture of the process simulation objects 39

Figure 4.2: Flowsheet as a dynamic object 40

Figure 4.3: Relationship of the objects in the PQS 42

Figure 4.4: Dimensions example 43

Figure 4.5: Units example 45

Figure 4.6: Prefixes example 46

Figure 4.7: Dimensional quantities example 47

Figure 4.8: Dimensional expressions example 48

Figure 4.9: Empirical expressions example 49

Figure 4.10: Difference quantities example 50

Figure 4.11: Relationship of the objects in the PPS 52

Figure 4.12: The object component 53

Figure 4.13: Component hierarchy .... 55

Figure 4.14: Example involving reaction 58

Figure 4.15: Physical property tree 61

Figure 4.16: Simplified physical property tree 62

Figure 4.17: Example involving physical properties 64

Figure 4.18: Data bank operations 65

Figure 4.19: Data bank as a mediator 66

Figure 4.20: Storage of binary parameters 67

Figure 4.21: Example involving data bank 68

Figure 4.22: Relationship of the objects in the FS 70

Figure 4.23: Object hierarchy for equations 71

Figure 4.24: Example involving equations 73

 vii

Figure 4.25: Example involving equation variables 74

Figure 4.26: A flowsheet with recycle and control loops 77

Figure 4.27: Example involving flowsheet 82

 viii

ACKNOWLEDGEMENTS

I would like to express my deep gratitude to Professor Dean L. Ulrichson for

giving me an opportunity to come to USA and work under him. His invaluable

guidance, advice and suggestions are gratefully acknowleged.

My sincere thanks to Professor Les L. Miller for his kind and active involvement

in this work.

I would like to acknowledge the financial support from the department of chem­

ical engineering.

I am very much thankful to my colleague Mr. Kheng H. Lau for his great help

and warm friendship.

I am grateful to my family and my wife's family for their support and encour­

agement.

Finally, I appreciate very much the patience and understanding of my wife during

the course of this work.

 1

CHAPTER 1. INTRODUCTION

The emergence of commercial Object Oriented Programming Languages (OOPL)

in the late eighties generated a rush of activity in the software arena. OOPL provide

a new approach for the design, development, and maintenance of software projects

resulting in improved software productivity and reduced software costs. Object mod­

eling and overloading are two features of OOPL that distinguish them from their

conventional counterparts. Object modeling allows the information pertaining to a

software project to be organized into a collection of well defined objects. Objects

are logical entities that exhibit the behavior of the real world entities in the prob­

lem's domain. They also provide the tight coupling necessary between the data and

operations, which are the two ingredients of conventional programming languages.

Overloading assigns an operation more than one meaning; it resolves the ambiguity

by analyzing the objects involved and performs the right action. An important con­

sequence of the combination of these two features in OOPL is the language extension.

By adding additional objects relating to an application and overloading the existing

operations with respect to these new objects, the language is considered to be ex­

tended to that application. It is this fact that makes OOPL attractive as software

platforms for a number of application areas. The application area of interest in this

thesis is process engineering in general and process simulation in particular.

 2

Process engineering encompasses a wide variety of tasks from process conception

through process design, plant startup and process control. It involves a number of

engineering disciplines and requires specialized software to carry out each task. Be­

cause of the close inter-relationship among various tasks and the iterative nature of

the engineering process, the automation of the whole process requires either a com­

mon platform around which all the applications can be developed or a one-to-many

interface approach that integrates all the applications involved in process engineering.

Process integration is an attempt to achieve this.

One of the activities involved in process engineering is process simulation. Pro­

cess simulation is a well established design activity. Process simulation can be per­

formed by a variety of approaches: sequential modular, equation-based, simultane­

ous modular; it may mean steady-state or dynamic simulation; it may be carried

out by a variety of software packages differing in their capabilities, applicabilities,

input/implementation languages. Also, to carry out routine design activities, a de­

sign firm often may end up dealing with more than one process simulator requiring

specialized training for the personnel and forcing increased software costs.

A number of commercial software packages exist to carry out process engineer­

ing activities [25]. Process simulators such as ASPEN-PLUS, DESIGN-II, PRO-II

and CHEMCAD-II perform steady-state simulation. SPEED-UP allows dynamic

simulation. Plant-wide energy integration using pinch technology and detailed heat

exchanger design can be performed with ADVENT. Since a typical design task in­

volves more than one of these packages, and each package has its own data format,

the problem of data transfer among these packages arises. Manual transfer of data is

cumbersome. Process integration should support automatic data transfer.

 3

The classical approach to process integration is through the development of one-

to-many interfaces among applications. The drawback is that it is impractical to

develop so many interfaces because of the presence of a large number of application

packages, the coordination among software vendors is difficult to realize and the

interface development itself is often not cost effective. With the realization of object

orientation, the use of a common platform to support process integration becomes

a viable alternative. There have been some efforts in the literature to use object

orientation to achieve process integration. They either use an existing object oriented

programming language or develop a new language to act as a programming system

that integrates various related applications. The integration is achieved at the object

level rather than at the module level. The language extension feature of OOPL,

with the help of object standardization, can be effectively used to achieve process

integration.

Since the integration is at the object level, for each application to be integrated,

the design of objects present in that application must follow some standard design cri­

teria. Efforts are under way to establish standards for process engineering data [25].

But there is neither an established criteria nor one being worked out for the design

of objects. The objective of this work is to develop an object oriented steady state

process simulator to illustrate the benefit of using OOPL in simulation. A steady

state process simulator that uses both sequential and simultaneous approaches is

developed and demonstrated here using the object oriented programming language

C+ + . The development of the simulator is a collaborative effort of myself and an­

other graduate student. This thesis develops the information modeling and program

structure aspects of the simulator. The reader is refered to the thesis of Lau [8] for
 4

the details of numerical procedures used and the results of convergence studies based

on this simulator. An object design criteria is formulated based on the experience

of developing the object oriented process simulator, an analysis of the object model

is performed, the suitability of C++ as an implemenatation language for supporting

process simulation applications is explored.

It is found that the object model has to be extended with operational behavior

to effectively represent the process simulation information, the development effort is

greatly reduced by using the object oriented approach for the process simulator, ob­

ject standardization including object design criteria is essential for achieving process

integration, OOPL can act as common platforms for integrating process engineer­

ing activities, and C++ can be used effectively as an implementation language for

object oriented process simulation. The ease with which the sequential and simulta­

neous approaches are incorporated into the process simulator reflects the potential

of object oriented programming for process engineering applications. It can be seen

that the developed process simulator can be easily extended with dynamic simulation

capabilities by adding only a few more objects.

Chapter 2 provides a review of the literature related to this work. Object model­

ing is an important prerequisite to the simulator development. The subject of object

design is discussed in Chapter 3. The developed object oriented process simulator

consists of three major components: physical quantity system, physical property

system and flowsheet system. Chapter 4 gives a detailed description of the objects

identified in these components with illustrative programming examples. Chapter .5

contains conclusions and Chapter 6 recommendations.

 5

CHAPTER 2. LITERATURE REVIEW

Process Simulation

The existence of many commercial process simulators reveals that process sim­

ulation is a well established design activity. Process simulators may follow different

approaches in handling material and energy balance calculations, but they all require

substantial effort for their development. Numerical computations and data manage­

ment are the two features characteristic of process simulators. Here, we concentrate

on the data management rather than the numerical computations. In addition to

reliability and computational stability a process simulator should be natural to the

designers who use the system. This requires that the process simulator deal with nat­

ural objects. Some of the tools used by commercial process simulators are graphic

input interfaces, high level input languages for problem specification and graphic

report presentation systems. All these tasks require tremendous effort in software

development.

Also, the development of a process simulator is not a one-time effort. Process

simulators evolve and hence they should be extensible with the addition of new unit

operations and modification of existing unit operation and physical property models.

This also indicates the importance of software maintenance. Also, designers of differ­

ing expertise use the simulators. Thus a graphic interface may be an effective tool for
 6

a novice user but not for an expert user who wants to explore the advanced capabili­

ties of the process simulator. So, the process simulator should support differing levels

of abstraction and detail. This puts additional constraints on the development of ef­

ficient process simulator. Process simulators are supplied by many vendors and the

lack of industry standards for process simulators leads to simulators with a variety of

interfaces. This puts more burden on the users who wish to learn and use various sim­

ulators. This also makes process integration more difficult as will be discussed later

in this chapter. The peculiarity arising from the simulator support of two disparate

features: data management and numerical computations, leads more often than not,

to either the use of more than one implementation language (e.g. SPEEDUP) or the

development of additional software just to handle the data structures (e.g. ASPEN).

An object oriented process simulator, on the other hand, follows a completely

different approach. The development of the simulator starts with either the selection

of an existing object oriented programming language or the creation of a new ob­

ject oriented programming language to act as a programming system. Since Object

Oriented Programming Languages, OOPL, can be extended through the addition of

object libraries, the development of a process simulation object library provides us

with a process simulator (Figure 2.1). This reduces the process simulator develop­

ment effort considerably and also permits us to focus on the application area (process

simulation in our case) rather than the software development necessary for the data

management support. Also, the selection and design of standardized objects has an

important effect on process integration. The objects should be as natural as pos­

sible, limited only by the capability of the underlying OOPL. Also, the division of

the application space into objects and incorporation of objects into the programming
 7

Process
Simulation
Object
Library

Object
Oriented
Programming
Language
as an OOPS

Figure 2.1: Object oriented process simulation

language provides the designers with a clear insight into the software structure. Since

a novice user will also be a programmer at a later stage, and since objects can be

used both by users and programmers, object orientation provides a natural solution

to the maintenance of the process simulator.

Object Orientation

We see more and more CAD applications relying on object orientation. Object

orientation is unifying programming languages, artificial intelligence and databases [10].

It is said to be at the center of the triangle with these three fields forming the ver­

tices (Figure 2.2). Our interest in object orientation initially arose from an interest
 8

Data Bases

Art£lcial Programming
Intelligence Languages

Figure 2.2: The realm of object orientation

in databases. It has long been established that classical data models are inadequate

for CAD databases. The pursuit of new data models led to semantic, special purpose

and finally, object data models. When it comes to data modeling, the gap between

databases and programming languages becomes narrow, and the object model pro­

vides the common interface. With our choice of process simulation as the application

area, our interest shifted from databases to programming languages.

An object oriented programming environment differs from its conventional coun­

terpart by providing additional concepts: objects (aggregation), encapsulation, mes­

sages and inheritance (generalization) constituting the object model. Any entity can

be treated as an object. An object consists of data and operations that act upon that

data. In a process engineering environment, one can conceive of flowsheet, stream,

equipment unit, chemical component, equation, reaction and even numerical values

as objects. An object's data is an aggregation of related entities.

Let us view the flowsheet as an object as illustrated in Figure 2.3. To represent an

object such as flowsheet, we should identify the data associated with the flowsheet
 9

Objaob Flowsheet

Data Equipment units

Simulate Display

Figure 2.3: The concept of object

and the operations required to analyze it. A typical flowsheet consists of a set of

equipment units. So equipment units are the data part of the object flowsheet.

What do we do with a flowsheet? We may want to simulate the flowsheet, analyze

the flowsheet, or display and draw the flowsheet. So, simulate, design, display and

draw form the operations of our object flowsheet.

There is a concept worth emphasizing here. In our view flowsheet is tlie object

and simulate is an operation around it. The output of the simulate operation is the

same flowsheet with more information (Figure 2.4). It is equally possible to view the

operation simulate as an object and tlie object flowsheet as an operation. In fact,

a simulator like ASPEN, does this (Figure 2.5). It emphasizes the simulator rather

than the flowsheet. The flowsheet information is buried into the input speciflcation

language. The output from the simulator does not signify the flowsheet either. In

fact there is no apparent relationship between the input and output of the simulator.

Input is accomplished using an input specification language that is altogether different

from the output format.

So, there is a choice among the views, and the choice of flowsheet as an object, is

preferable because it is natural to the designers. It is the flowsheet that we are sinni-
 10

Object Object
Operation
Incomplete Completed
Simulate
Flowsheet Flowsheet

Figure 2.4: Our view of simulation

Object Data
Data

Input Simulator Output

Flowsheet Preprocessor Stream matrix

Streams PP estimator History info.
PP options Model executor
Design specs Report generator

Figure 2.5: ASPEN's view of simulation

 11

lating, not the simulators that we are flowsheeting. A single simulate operation may

be applied to many flowsheets, but a flowsheet does not operate on many simulators.

In fact a flowsheet operating on simulator itself is rather imaginative. The same sce­

nario is supported in OOPL by differentiating between what is called class object and

instance object (Figure 2.6). An instance object contains the actual values (data)

and the class object contains the structure of the instance object. There can be only

one class object and many instance objects derived from that class object. Also, the

operations that can act on the instance objects are only a part of the class object,

not the instance objects. So, we can have many instance objects (differing in data

values) that use the same set of operations with similar structure. From Figure 2.6,

note that the data of an object consists of two parts: class data and instance data.

Class data is the data (both values and structure) common to all instances of a class

object. Instance data (only values not structure!) varies from instance to instance.

Viewing this subject from a different perspective, objects are nothing new to

Conventional Programming Languages (CPL). After all, an object is nothing but a

piece of data and associated operations acting on that data. A function or procedure

takes arguments as input, and returns arguments as output. So, the function or

procedure is the operation, and the input and output parameters are the data. So,

here too we have data and operations. But one difference between OOPL and CPL

is the kind of importance we attribute to data. In OOPL, it is the data that has

operations; in CPL, it is the operations that have input/output data. The other

important difference is the concept of encapsulation.

Encapsulation (Figure 2.7) is another most important feature of OOPL. It says

that data in an object can only be modified by the operations belonging to that
 12

Objeot Flowsheet Class objeot

[ Class data ]

Instance data Equipment units

Simulate Display
Operations

if

F1 Instance object

(HX1,DST1,HX2)

Simulate

Figure 2.6: Glass and instance objects

 13

Object's operations

Object

Object's Object Object's

data data

X Bncapsulatli
Object
Creators

Figure 2.7: The concept of encapsulation

object. This statement has more implications than are apparent at the outset.

First, since a user cannot modify an object's data directly, there should be

somebody who will provide the user with the set of operations that act upon the

object's data. So, there should be at least two parties - a creator (programmer)

who creates the object (its structure and operations) and a user (group of users)

who works with the object. In Cox's terms [4], the users and creators correspond to

consumers and suppliers, respectively. A consumer can buy products (objects) from

different suppliers and store them in his storehouse (object library) and build his own

product (application) using the stored products (objects).

Second, since the operations act as a wall between the outside world and the
 14

object's data, the way the user views the data may be completely different from

the representation of the object. The representation can be changed as long as the

previous operations are supported in the object's new representation. In essence, en­

capsulation provides the logical data independence between the object and the users.

The importance of logical data independence in databases need not be re-emphasized.

By providing logical data independence, OOPL are approaching database systems in

their capability. Encapsulation also supports the view concept of database models.

Many users can look at the same object from different perspectives. The differences

in the perspectives will be taken care of by the creator through the operations. So,

the users feel as though they are working with different objects tailored to their own

needs, but in fact it is a single object.

Third, encapsulation ensures that the object is consistent with respect to other

objects. Since the only way one can modify an object is through its operations, the

object's consistency is ensured as long as the operations are valid. It is the creator's

responsibility to provide a complete and valid set of operations, and to see that

various views co-exist. The user cannot perform a desired function on the object

unless the function is in the set of operations. This requires that the creator has a

complete specification of the requirements of the object before the implementation

can be started. Hence, the specification of requirements is essential to an object

oriented environment. Many specification languages exist for this purpose.

Finally, encapsulation forces the user to identify the object first before he can

invoke an operation. One cannot invoke an operation without referencing the object

to which that operation belongs. (Remember that there will be more than one object

with a similar set of operations. In fact, all instance objects of a particular structure
 15

object have the same set of operations.) This operation invoking is made possible by

the concept of messaging.

Messaging is similar to a conventional procedure call. The only difference is that

the procedure should have at least two arguments: one, the message receiver (an

object); two, the message selector (an operation of that object). The reply from a

message varies from operation to operation. Some messages may have no replies; in

that case it is customary to return the receiver as the reply. A typical syntax for

messaging is shown in Figure 2.8. Languages like Smalltalk follow a clever approach of

making the arguments semantic rather than syntactic. They precede each argument

with the role of the argument (a colon separates the argument and its role), and

the concatenation of the roles form the operation to act on the object. The sender

of the message has to wait for the reply (may be a null reply) from the message

receiver. So, contrary to one's expectation, there is no concurrent execution. Flow

of control is still sequential but the way one looks at the execution mechanism is

different. Figure 2.9 shows the flow of control for creating the flowsheet object F1

and simulating it. Assuming that the flowsheet F1 contains a heat-exchanger HXl,

the flow of control goes to the Construct operation of the class object Flowsheet,

comes back, goes to the Simulate operation of the instance object Fl, goes to the

Simulate operation of the instance object HXl, returns from HXl, and flnally back

to the program. Messaging is the only way one can talk to the objects (through the

operations).

The concept of inheritance (generalization) finds its roots in AI and database

fields [12]. Inheritance is a kind of abstraction in which objects are viewed as hier­

archies with specialized objects being at the bottom and generalized objects at the
 16

Small Talk notation [ Object Operation Arguments ]

/
Message
N Message
Receiver Selector

[ Object Rolel;Argl Role2:Arg2 ]

C++ notation Object.Operation (Arguments)

/
Message Message
Receiver Selector

Figure 2.8: Typical syntax for messaging

top (Figure 2.10). A specialized object possesses all the attributes of its generalized

object, besides having its own additional attributes. Also, since operations are part

of an object, they also adhere to inheritance and generalized operations may work

on a specialized object. In OOPL, the abstraction power of inheritance is used only

as an implementation tool rather than a programming tool. As far as the users are

concerned, inheritance is absent from OOPL. But the object creators use inheritance

to reduce duplication of code and data. Without inheritance, implementations for

OOPL may not be even realizable [4]. Also, inheritance removes the restriction of ob­

ject development from base level. Object developers can use the existing hierarchical

objects at the base level to start with and can achieve higher productivity.
 17

Instance object:
Class object: F1
Flowsheet

Data
Data

Program:
Simulate

Flowsheet F1
Fl.Simulate
HXl.Simulate

Simulate

Data

Analyze

Instance object:
HXl

Figure 2.9: Flow ol' execution in OOPL

 18

Generalized object Equipment unit

Heat Reactor Distillation

Specialized objects exchanger column

Figure 2.10: The concept of inheritance

Process Integration

A process design task consists of many phases and encompasses many disciplines.

Frequently, the output of one phase becomes the input to the next phase. Design

tools exist to carry out various design phases, but they are all independent and a

transition from one ])hase to another is not smooth. Process integration is the (ask

of combining these independent design tools to form a single design support system.

'J'he independent development of design tools means the current approach to process

integration is to create a one-to-many interface. That is, with each design tool, we

require additional interfaces to integrate that tool with its preceding and succeeding

design tools in the design sequence (Figure 2.11).

In this one-to-many interface approach, the development of interfaces becomes

difficult and sometimes impractical. This is because the software packages, around

which the interface is needed, will be supplied by different vendors and, quite of­

ten, the design of these packages does not take into account the existence of other

packages that have to be interfaced later. For example, when the implementors of

ASPEN-PLUS realized the need for the management of flowsheeting data gener-
 19

Tool 1 Tool 2 Tool 3

TIA T2A T3A

TIB T2B T3B

Figure 2.11: One-to-many interface approach to integration

atecl by their simulator, they turned to the relational database management system

PR0DA13AS [25]. But, since PRODABAS was not their own product, and PROD-

ABAS does not understand the input/output language of ASPEN-PLUS, an interface

between those two was necessary, and they had considerable difficulty in realizing the

interface.

Object oriented process integration assumes that all the design tools are devel­

oped around a single object oriented programming system (Figure 2.12). Also, the

interrelated design tools communicate through standardized objects. This im]>lies

that conventional and object oriented approaches do not differ in their need for ob­

ject standardization. But the objects in the object oriented approach make object

standardization easier than in the conventional approach. But it is impractical to

achieve complete standardization within a short time. To alleviate this problem, we

j)ropose a one-to-one interface approach, la this approach, a design tool needs a sin­

gle interface with the semi-standard object with which it is interacting. This reduces
 20

Process
Oriflae Simulation
Sizing

OOPS
OL OL
as an
Executive

Piping
Layout
Equipment
OL Design
OL

Figure 2.12: Object oriented process integration

the number of interfaces considerably, and at tlie same time provides for software

independence. By software independence we mean a design tool need not be modi­

fied/extended with additional interfaces to function in conjunction with new related

design tools.
Early efforts at adapting object orientation to chemical CAD can be attributed

to Buchmann [1]. He developed TM - an object oriented, message passing language

and combined it with an object oriented CAD DBMS to form a complete object

oriented programming environment for CAD.

The importance of object orientation for process integration was pointed out by

Yamashita and Motard [24]. Their interactive programming environment VSM (writ­

ten in C) was used to achieve heterogeneous integration, without modificalion (except

 21

some restructuring in the light of object orientation) of existing process engineering

software. They acknowledged the importance of object modeling and expressed con­

cern over the lack of proper object design methodology [9, 6, 10]. They used their

in-house design tools: spreadsheet, sequential modular simulator (CHESS) and re­

lational DBMS (CADRE) to show how they could achieve process integration using

VSM. In essence, their VSM acts as an object oriented interface between the users

and existing software and other design tools. They also showed the application of

VSM to object oriented dynamic simulation, again using existing software as far as

possible. Since VSM is not a true object oriented programming language and the enti­

ties involved in integration were never re-designed using object model, the suitability

of object modeling to process engineering was never explored in their work.

Another work on the application of object orientation to process engineering is

that of Stephanopoulos et al. [15]. Their product DESIGN-KIT is an object oriented

environment for process engineering. This, in contrast to Yam as hi ta and Motard's

work, follows homogeneous integration, with the development of all design tools from

flowsheet synthesis to operational analysis in a single programming language. Com­

mon Lisp (and its derivative, KEE). They also stressed the need for more work on

object modeling concepts, physical property systems and knowledge-based expert

systems in addition to equation oriented simulation and design.

In a more recent work, Stephanopoulos et al. [13, 14] developed a new modeling

language to support process engineering activities. The language is based on object

oriented modeling concepts. It captures the qualitative and quantitative knowledge

found in process engineering. The knowledge is collected using some basic modeling

elements and relating them through fundamental semantic relationships. Their work
 22

closely resembles the one in this thesis. It tries to cover the entire process engineering

cycle without particular emphasis on any one activity. In comparison, the present

work concentrates on process simulation activity alone. Also, the emphasis of the

present work is not on developing a new modeling or programming language but to use

an existing object oriented programming language and its accompanying object model

to model the information contained in process simulation. Use of special purpose

languages for process integration limits the integration only to process engineering.

Another modeling language that has been developed using object oriented mod­

eling concepts is that of Piela ei al. [11]. The language allows the definition of a

physical process in terms of a mathematical model involving algebraic and ordinary

differential equations. It separates the definition of the mathematical model from

the solution of it. It treats even the solution schemes for the equations as models,

thus allowing the user to specify new solution methods for solving equations. But it

appears that the modeling elements present in the language allow only a restricted

set of methods to solve ordinary differential equations, thus limiting its versatility.

The present work also supports equations as modeling elements to define a physical

process in terms of a mathematical model. But again, it uses an existing language

rather than a new one.

 23

CHAPTER 3. INFORMATION MODELING

Objects are central to the theme of object orientation. OOPL allow objects to

be created and manipulated. But they don't carry the methodology to identify and

design the objects. Typically, an application environment consists of a number of

entities and intricate relationships among them. The division of an application space

into various objects capturing all the intricate relationships, within the constraints of

the object model of OOPL, is the responsibility of the software designer/developer.

As discussed in the previous chapter, the object model of OOPL supports concepts

like objects (aggregation), data, operations, inheritance (generalization) and encap­

sulation. The following questions arise as one tries to identify the objects using these

concepts;

1. How do we distinguish between data and operations?

This arises from the fundamental definition of the object itself. For example,

using the format data.operation^ we have a choice between flowsheet.simulate

and simulator.flowsheet. Since the relation between data and operation is many

to one and also since it is clear that we can use a single simulate operation

to simulate many flowsheets, in this case, flowsheet becomes the object and

simulate, the operation. The distinction is not so obvious if we have a choice

between component, enthalpy diwA enthalpy, component.

 24

2. Which is an object and which is not?

This arises from the concept of aggregation, which allows related entities to

be grouped together to form an object. Consider two variations of an object

component flowrate as shown in Figure 3.1. Which variation is desirable? Is it

necessary that component must be a separate object as in variation 1? If we

consider a broader view as shown in Figure 3.2, we may ask ourselves whether

the component flowrate itself should be considered as an object or just as a

compound entity (e.g. Pascal record). Variation 1 is desirable and we treat

component as a separate object because it is desirable to manipulate a com­

ponent independent of its flowrate. Also, component flowrate need not be an

object since we don't foresee any operations around it.

3. How do we organize objects into hierarchies?

The concept of generalization allows us to organize objects into a hierarchical

structure. Let us consider two approaches to the representation of time and

temperature (Figure 3.3). Which approach do we prefer? Why are they so

different? The first approach [6] organizes time and temperature into their
respective units. Note that there is one-to-one correspondence among these

units (e.g. 1 hr = 60 min = 3600 sec). The second approach identifies unit as a

separate object and places time and temperature under yet another new object

physical quantity. Contrary to the first, the second approach does not treat the

specific units (s, min, C) as separate objects but as instances of the object unit.

At first sight, it appears that approach 1 is simpler and easier to use, but the

superiority of approach 2 is apparent when we extend the approach to other

physical quantities like velocity (Figure 3.4), where it is impractical to gather

 25

Component flowrate

Component

Flowrate Component flowrate

Name
Component PC
To

— Name
Flowrate
— PC
— To

Variation 1 Variation 2

Figure 3.1: Variations of the object component flowrate

 26

Stream Stream

Temperature Temperature
Pressure Pressure
Sequence of component
Set of Component flowrate
Sequence of flowrate

Component flowrate

Component

Flowrate

Figure 3.2: Stream involving component flowrate

all velocity units and put them under velocity. The decision of whether to treat,

an entity as an object or not makes various approaches completely different.

4. When is an object completely defined?

The concept of encapsulation does not allow an object's data to be modified

without going through the object's ojîerations. How many operations are we

going to provide for an object? How do we know that the provided operations

are sufficient? What is the guarantee that an object does not have interac­

tions with the new objects, or new interactions with the existing objects? A

requirement analysis of the application environment is essential to know what

operations to be provided and whether they are sufficient. It is difficult to guar­

antee that the object design is perfect and complete in view of the emerging
 27

Time Unit Dimension

s min hr b Symbol
Dimension
— M
L
— T
t
Temperature Physical quantity

Magnitude
C F R Unit

Time Temperature

Approach 1 Approach 2

Figure 3.3: Representation of time and temperature

Velocity Physical quantity

cm/s km/hr in/min Time Temperature Velocity

Approach 1 Approach 2

Figure 3.4: Representation of velocity

 28

new requirements. But encapsulation and careful requirement analysis eases

software maintenance.

Object Design Criteria

Object selection and design is critical for the success of OOPL. Also, process

integration, which depends on object standardization, requires the objects to be

designed following a well established object design criteria. Without a proper object

design criteria, the independent efforts in selection and design of objects provide not

much more benefit than that of conventional programming. In spite of the obvious

need for an object design criteria, as yet, there does not exist any object design

methodology. It is one of our objectives to arrive at an object design criteria on our

way to build the object oriented process simulator. Based on our experience gained

in developing the process simulator, we provide below a list of guidelines for object

design:

1. The relation between data and operations is many to one. Also, operations

characterize data.

2. Multiple occurrences and associated operations call for new objects.

3. No one-to-one correspondence is permitted among the specialized objects under

a generalized object.

4. Follow uniformity in approach. This facilitates the user understanding of the

objects.
 29

5. Provide a minimal and convenient set of operations that satisfy all the require­

ments. The requirements analysis should be performed involving that object.

6. Make objects natural and simple.

7. Prefer top-down design. A top-down design identifies all the top-level objects

prior to the lower-level objects.

8. Use existing standard objects to allow easy integration.

9. Coordinate object activation and passivation. For example, an identical format

for an object's input and output provides user convenience.

10. Achieve modular design. Divide the application space into categories of closely

related objects (object modules). Object modules provide greater flexibility for

objects usage.

11. Customize objects within the limits of standardization.

12. Extensibility. Prefer user extensibility to programmer extensibility. Objects

are user extensible if the extension is at the instance object level. Programmer

extensibility deals with class objects.

13. Make object modules includable. An object module should be usable in another

object module without any modifications.

Modeling Concept Analysis

The modeling concepts of OOPL allow natural representation of most of the

entities of process simulation. We argue that, with the present modeling constructs
 30

for the operations of an object, it is difficult to represent all the entities of process

simulation, so the modeling power of operations around the data of an object need to

be explored further. For example, take the physical property system. If we consider

the component as an object, physical properties like enthalpy and density become

its operations. We know that there is more than one method for calculating en-

halpies. So, a term like component .enthalpy will be incomplete unless we specify a

method that estimates enthalpy. We can identify all the enthalpy estimation proce­

dures, name them differently and call a particular procedure to calculate enthalpy

as component.ideaLenthalpy, component.RKS.enthalpycomponent.PR.enthalpy etc.

But each of these procedures do not know the existence of the other and we are

essentially losing the fact that the operation enthalpy is a generic name for various

enthalpy calculation routines. Also, a user does not want to specify his choice of

enthalpy estimation method every time he wants to calculate the enthalpy of a com­

ponent. Instead, he specifies once and intends to use the same procedure until he

overrides it. To support this scenario, we need to enhance the existing object model

to support operational behavior. In general an operation is carried out in a num­

ber of alternatives and each alternative consists of a number of sub-operations, each

sub-operation may in turn have many alternatives and so on (Figure 3.5).

We can see that if we assume data and operation of an object as separate entities,

there is a binary relationship between the two. Also, the binary relationship is one

sided, since we distinguish between data and operation and only data, operation is

meaningful, not the operation, data. If we go one step further and make a one-sided

binary relationship (a.b), a two-sided one, then (a.b) and (b.a) should be identical

and both data and operation should be objects. This eliminates the dilemma of data
 31

Operation

Altl Alt 2 Alt3

Sub opl

Sub op2
Altl Alt 2 Alts
Sub op3
Sub opl

Sub op2

Sub op3

Figure 3.5: Operation tree

and operation distinction. At first glance, this two-sided binary relationship appears

to have solved the problem of operational behavior, since the earlier operation can

now be treated as an object and can be described with the original concepts of the

object model to reflect its behavior. But, it generates a whole new set of problems

as to which the entity (a.b) belongs - to a? to b? or to both? Also what about the

concept of encapsulation?

The disadvantage of the binary relationship is that we cannot relate more than

two entities directly. If we go even one step further and make a binary relationshi]),

an n-ary relationship, we can represent relationships among multiple objects. This

also reduces the number of arguments to be passed to the operations. For example,

component, si ate.enthalpy represents a three-object relation and for different values

of state (vapor, liquid, solid) we can get the enthalpies of a chemical component for

diflerent states. Of course, as we can see, the higher the order of the relationship.
 32

the more complex it is to interpret and maintain the operations involving the related

objects.

A one-sided binary relationship with a provision for operational behavior descrip­

tion, more or less similar to that of objects, provides a reasonable and simple modeling

approach to represent process simulation objects. So, in component.enthalpy^ com­

ponent is an object (data) and enthalpy is an operation for the component, but now,

enthalpy recognizes its alternatives and sub-operations.

The concept of generalization is useful in organizing objects into hierarchies. It

works fine with individual objects, but fails with groups of objects. For example, in

physical property system, we can see the object component and the object component

set. Component set is a collection of component objects. The object component can

be specialized into molecular component, coal component, ionic component etc. But

the same thing cannot be done with the component set, molecular component set,

coal component set etc. because when we say component set it means collection of

components - in fact, all types of components. So, this makes the specialization of

component set into various types ambiguous.

Another problem with generalization is that it introduces a choice between nat­

uralness and storage space, even though both are important. An example illustrating

this fact can be taken from the physical quantity system. There the object physical

quantity is specialized into length, area, dimensional etc. To save space, physi­

cal quantity does not have dimensional information, because not all objects under

it require the dimensional information stored within them. Only the instances of

the object dimensional contain specific dimensional information. So, it is not clear

whether the object physical quantity or the object dimensional is the generic object
 33

in the generalization hierarchy. Putting the dimensional information within physical

quantity and calling it the root of the hierarchy is more natural but wasteful of space.

A problem involving both the object model and the programming language is

the definition of a complex object. A complex object is one that is either big enough

or contains references to other objects. For a complex object it is difficult to give

all the information pertaining to it when it is constructed. In that case, how can it

be guaranteed that an object's data is completely specified? It is necessary to know

when an object is completely defined because, semi-automatic objects like Stream

have to be initialized (flashed, in this case) before they can be used. The objects are

called semi-automatic because the user may not give the full data of the object but

expects the program to fill in the remaining data. To address this problem, a new

concept called state of an object may have to be defined in the object model. The

user can start with an empty object, add the necessary data and fix its state. Once

the state is fixed, appropriate operations may be performed on the object.

Object model does not enforce every object to have an external identity. But

object identity is utilized quite often in comparison of objects. Use of pointers to

objects for comparing the objects is a good choice, but is implementation dependent

and not advisable. Objects may have their own identity based on some key, but

unless it is required by the object model, the uniformity is lost. The current work

uses both pointers and keys to identify and compare objects.

Programming Feature Analysis

In addition to the modeling concepts discussed above, an object oriented pro­

gramming language should support the following programming features to make the
 34

programming simple. Note that our comments apply mainly to C + + , since that is

our implementation language. Languages like CLOS support some of these features.

1. Ability to know the names of the instance objects. This reduces the user input

data.

2. Facility for dynamic expression evaluation. Without this feature, we lose the

programmer convenience.

3. Uniform treatment of class and instance objects.

4. Ability to access the object's meta data besides the object's data. Meta data

is the data about data. An object's meta data includes its type, name and its

parent in the generalization hierarchy etc.

5. Ability to add new operators. This allows natural operators.

6. Automatic garbage collection. In a simulation environment objects are created

at will and may remain without being used by anyone. The unused objects

must be destroyed to make use of the space occupied by them.

7. Move some of the run-time error checking to the compilation step by allowing

operations to be tagged as invalid or inappropriate.

8. Ability to define objects as restricted that makes some of the operations more

efficient.

Automatic freeing of unused space is very important and worth some discussion.

Process simulation involves complex objects and when it is necessary to copy objects
 35

from one to another, the copying operation becomes very expensive and sometimes

infeasible. Also, a simple object may be shared by more than one complex object.

So, when the complex object is deleted, the simple object within it should not be

deleted unless it is not pointed to by any other object. Since C++ does not support

this scenario, it is necessary to support an automatic garbage collection scheme on

our own. This increases the programming effort and also makes the programming

difficult.

There are many schemes to restore unused space. The technique used in this work

is based on reference counting. Every object contains a count that tells the number of

references to that object. The object will be deleted when its reference count goes to

zero. To support reference counting, an object has to be divided into two parts: data

part and pointer part. The pointer points to the data part. When an object is copied

from one to another, the data are not copied but its count is increased by one and

the new object points to the old. Because of the use of reference counting, an object

can stay out of its scope. (A scope, in programming language sense, determines the

life of an object.) This in turn requires the object's data to be stored not on the

stack but on the heap. (Again, a stack is a part of the computer memory that will

be used by compiler as a storage space. Heap is also a part of the computer memory

but will be used by the programmer as a storage space.) Since storing objects on the

heap is much slower than on the stack, the price paid in supporting complex objects

is obvious.

One of the main advantages of using reference counting is that it makes the users

feel they are working with objects rather than pointers to objects. The disadvantage

of using reference counting for complex objects is that if an object points to itself
 36

either directly or indirectly, it is never deleted. The division of an object into two

parts makes it unnatural to the users. Use of a pointer to access an object's data

makes the operations slower. Since, quite often, not all objects are complex and

storing of simple objects on stack is much faster, we will end up with two type of

objects thereby losing the uniformity. In spite of these disadvantages, the technique

of reference counting has widespread use and consequently it is used for storing and

manipulating complex objects in this work.

 37

CHAPTER 4. PROGRAM STRUCTURE

The approach used in this work to develop the process simulator is to choose

an existing general purpose object oriented programming language as the implemen­

tation language and extend it with objects specific to process simulation. Other

approaches either develop new object oriented programming languages tailored for

process simulation or provide object oriented interfaces to existing conventional sim­

ulators. The premise behind the present work is to use an existing object oriented

programming language that is easily available to all and explore its suitability for

process simulation. The well known C++ is used as the implementation language

for developing the process simulator.

One important point to note here is that the use of object oriented programming

to develop process simulators does not change in any way the conventional process

simulation calculation methods or unit operation models. The same physical property

methods, equation solving techniques, formulation of material and energy balances

are used, except that the way they are incorporated into the computer program (the

program structure) is completely different. Any computer programming language

that is procedural (i.e. that allows a sequence of instructions) recognizes two enti­

ties: data and procedures. In a conventional programming language, the data and

procedures (operations) are treated separately, whereas, in an object oriented Ian-

 38

guage the data and procedures are clubbed together to form what is called object. It

is the identification of these objects and defining them into the programming language

that constitutes the development of the process simulator.

This chapter describes the objects that have been identified and defined to per­

form process simulation using C+ + . The complexity of the process simulator made

it necessary to divide the information content in the process simulator into easily

manageable components. Three major components were identified. They are Physi­

cal Quantity System (PQS), Physical Property System (PPS) and Flowsheet System

(FS). PQS is a collection of objects necessary to support units of measurement in

the process simulator. PPS makes possible the calculation of physical properties for

various chemical components present in a process simulation run. Process flowsheets

are logical representations of industrial chemical processes. FS contains the objects

necessary to perform simulation on a process flowsheet. Figure 4.1 shows a simplified

picture of the objects that were defined and their inter-relationships. Note the close

interaction between the FS and the PPS. Also the hierarchy is obvious. The FS

includes both the PPS and the PQS. The PPS includes only the PQS. The PQS can

be used independent of the FS and the PPS.

Since C++ does not support garbage collection and the inherent nature of simu­

lation requires objects to be created at random and destroyed if unused, the technique

of reference counting, as discussed in the previous chapter, is used to monitor the life

of an object. The object dynamic and its associated object dynamic record facilitates

the implementation of the reference counting technique. Eventually all complex ob­

jects (i.e. objects that are either big enough or contain references to other objects)

are divided into two parts: object and object record, and inherit the properties of the
 39

Flowsheet

t Equipment units

Constraints
L Streams
FLOWSHEET SYSTEM

Phase mixture
J
Phases J
Component mixture J
Components J—J PHYSICAL PROPERTY SYSTEM

Physical quantity

L Unit

L Dimension

PHYSICAL QUANTITY SYSTEM

Figure 4.1: Simplified picture oï the jirocess simulation objects

 40

Dynamic

L Pointer • Dynamic record

^— Count
11
Flowsheet •" Flowsheet record

Figure 4.2: Flo\v.sheet as a dynamic object

dynamic and dynamic record objects. Figure 4.2 illustrates the concept of treating

flowsheet as a dynamic object. Almost all objects of the FS and the PPS are treated

as dynamic objects. To make the understanding easier, the rest of the discussion does

not divide objects into its constituent parts: object and object record, even though

they are implemented in that fashion. Appendix A contains a list of all the objects

defined in the process simulator. Also, the user is allowed to manipulate only the

objects, not their record parts. This makes it clear the the division of an object into

I,wo parts is just to facilitate implementation and the user need not know anything

about the record portion.

The rest of this chapter discusses the three major components of the developed

process simulator. A description of the defined objects is provided followed by the

implementation aspects and illustrative examples. The programming examples are

in C!++, since it is the implementation language. The reader is referred to [16] for a

detailed description of the C++ programming language. The examples given here do

not assume any proficiency of the reader in C++. Appendix B gives an outline of the

C++ language constructs that might be helpful in understanding the programming

exam])les.
 41

Physical Quantity System

Conventional programming languages support entities like integer (for integral

quantities), real (for real precision numbers) or double (for double precision numbers),

while physical quantities like length, velocity and density are of primary interest to

the process designer. In contrast, conventional process simulators carry the notion

of units and physical quantities, but they bury the concept into their input language

thereby reducing its functionality. PQS fills this gap being an independent and

major component of the developed process simulator. There have been efforts to

support dimensional quantities in OOPL [5], but they tend to be incomplete for the

chemical process design environment. The approach used in this work emphasizes

object modeling, eliminates most of the constraints of the previous approaches and

is far more extensive. Figure 4.3 shows the relationship of the objects defined in the

PQS.

Units of measurement

Physical quantities such as length and density have units. Units in turn have di­

mensions. Dimension is defined in terms of the primary dimensions like mass, length,

time and temperature. Table 4.1 shows the operations defined around dimension.

These operations allow the generation of derived dimensions from the primary di­

mensions. Examples of derived dimensions are the dimensions of force and energy.

A dimension can be raised to any power, real or integer. As shown in Figure 4.4,

this allows the definition of physical quantities like dipole moment which involves

dimensions raised to a real power.

Operations similar to those around dimension are defined around unit. Each
 42

Physical quantity

Dimensional Length Density Velocity

L .
'— Dimension
Unit

Difference
L Dimension

Prefix

Unit set Unit system

L Units L Non-equivalent units

Figure 4.3: Relationship of the objects in the PQS

Table 4.1: Operations around dimension

Operation Purpose
dimension Construct a dimension
operator[] Raise a dimension to a power
operator== Compare two dimensions
operator!= Contrast two dimensions
operator* Multiply two dimensions
operator/ Divide two dimensions
operator» Read in a dimension
operator« Write out a dimension
 43

// Primary dimensions

Dimension M ("mass"); // mass

Dimension L ("length"); // length
Dimension t ("time"); // time
Dimension n ("molar.mass"); // mole
Dimension T ("temperature"); // temperature

// Derived dimensions

Dimension A (L/t[2]); // acceleration

Dimension F (M*A); // force
Dimension E (F*L); // energy
Dimension V (L[3]); // volume
Dimension D ((E*V)[0.5]); II dipole moment

II Input/Output

Dimension P; // Power
cin » P; // ML[2]t[-3]
cout << P; // ML[2]t[-3]
cout << E; // ML[2]t[-2]
cout << V; // L[3]
cout << D; // M[0.5]L[2.5]t[-l]

Figure 4.4: Dimensions example

 44

unit is uniquely identified by a symbol. Two units are said to be equivalent if they

both have the same dimension. To convert a physical quantity from one unit {x) into

another (t/), we need a function of the form y — f{x). T h e simplest function is y = a x

where a is the conversion factor. This simple form fails to convert some of the physical

quantities like temperature from one unit into another. A conversion function of the

form y = ax + b where a and b are the conversion constants works for all engineering

units [19]. Consequently this is the form adopted in the PQS. For example, to convert

temperature from C to A', the conversion function is K = C + 273.15. Every unit

carries with it two conversion constants; conversion factor (a) and conversion offset

(6). SI is chosen as the reference unit system to store the conversion constants of all

units. This implies that the conversion factor and conversion offset of all SI units

are 1 and 0, respectively. A unit's conversion constants are the constants when it is

converted to its equivalent SI unit. For example, the conversion constants for C are

1.0 and 273.15. Figure 4.5 shows how complex units can be built from simple units.

Prefixes are short-hand notation for powers of. ten. They considerably improve

the magnitude specification of the physical quantities [21]. Prefix is defined as a

unit with null dimension. Only the multiply operation of unit is needed for prefix.

Figure 4.6 shows an example involving prefixes.

Unit set is a collection of units. All miscellaneous units which do not belong to

any unit system can be grouped together using unit set. Unit system is a unit set with

the restriction that no two units are equivalent. Unit system can be used to support

measurement unit systems like SI, ENGLISH and METRIC. Note that, contrary to

unit system, unit set can contain more than one unit with the same dimension. The

operations around the unit system allow the user to switch from one unit system
 45

Il SI units

Unit kg("kilogram","kg",M); II kg is mass unit

Unit m("meter","m",L); // m is length unit
Unit s("second","s",t); II s is time unit
Unit kmol("kg_mole","kmol",n); // kmol is mole unit
Unit K("kelvin","K",T); II K is temperature unit
Unit sqm("sq_met","sqm",m[2]); II sqm is area unit
Unit cum("cub_met","cum",m[3]); II cum is volume unit
Unit N("newton","N",m-kg/s[2]); // force unit
Unit Pa("pascal","Pa",N/m[2]); // pressure unit
Unit J("joule","J",N-m); // energy unit
Unit W("watt","W",J/s); II power unit

// ENGLISH units

Unit lb("pound","lb",4.536e-l*kg); // 1 lb = 0.4536 kg

Unit ft("foot","ft",3.048e-l*m); // 1 ft = 0.3048 m
Unit cuft("cub_ft","cuft",ft[3]); // 1 cuft = 0.02832 cum
Unit F("Fahrenheit","F",T,0.5556,255.37); // K = 0.5556 * F + 255.37
Unit Btu("Btu","Btu",1.05506e3*J); // 1 Btu = 1055.06 J
Unit psi("psi(abs)","psi",6.89476e3*Pa); // 1 psi = 6894.76 Pa

// Miscellaneous units

Unit gm("gram","gm",kg/1000); // 1 gm = 0.001 kg

Unit cm("centimeter","cm",m/100); // 1 cm = 0.01 m
Unit cc("cub_cm","cc",cum/le6); // 1 cc = le-6 cum
Unit gmol("gm_mole","gmol",kmol/1000); // 1 gmol = 0.001 kmol
Unit C("Centigrade","C",T,1.0,273.15); // K = C + 273.15
Unit cal("calorie","cal",4.1868*J); // 1 cal = 4.1868 J

// Input/Output

Unit dyne; // force unit

cin >> dyne; // gm-cm/s[2]
cout << dyne; // gm-cm/s[2]
cout << dimension(dyne); // MLt[-2]

Figure 4.5: Units example

 46

// prefixes

Prefix MC'mega" ,"M",le6); // prefix M = ie6

Prefix k("kilo","k",le3); // prefix k = le3
Prefix c("centi","c",0.01); // prefix c = le-2

II use of prefixes

Length d(2,k-m); // d = 2 k-m = 2000 m

Power p(10,M-W); // p = 10 M-W = le+7 W

Figure 4.6: Prefixes example

to another for input/output of physical quantities, to create new unit systems that

contain units of user's preference, to copy one unit system to another and to display

a unit system. Similar operations are also present around unit set.

Physical quantities

Physical quantity is a generalization of quantities like length, velocity and den­

sity. Quantification of a physical quantity requires two items: numerical value and

unit. But by sticking to a single unit system (SI in this work) for storing physical

quantities, we can eliminate the need for the second item, unit. This is reflected in

Figure 4.3, which shows the object physical quantity and some of its derived objects.

The input and output unit systems facilitate the input/output of physical quantities.

They default to SI, but can be changed any time.

Physical quantities like length and velocity are dimensional quantities. The

specialized object dimensional, under the physical quantity, represents all the dimen­

sional quantities that are not explicitly present under physical quantity (Figure 4.3).
 47

An example of dimensional is the ideal gas constant (Figure 4.7). Note that, contrary

to physical quantities like length, dimensional objects can have different dimensions.

Also, a particular dimensional object can have different dimensions at different times

(Figure 4.8).

Dimensional R(8320,J/kmol/K); // R is gas constemt

Dimensional k(2,cuft): // volume k = 2 cuft
Length 1(2,cm); // length 1 = 2 cm
k(4,cuft); // volume k = 4 cuft
1(3,cm); // length 1 = 3 cm
k(4,sqcm); // area k = 4 sqcm
l(3,sqcm); // invalid!

Figure 4.7; Dimensional quantities example

Dimensional expressions

Directly following from the dimensional quantities are the dimensional expres­

sions. In contrast to a normal expression, a dimensional expression involves di­

mensional quantities (Figure 4.8). A dimensional expression is valid only if the di­

mensions of its Ihs and rhs are equal. Also it is meaningful to add/subtract only

dimensionally-equal quantities. Dimensional equality checking is performed for all

dimensional expressions.

Sometimes we find dimensional expressions whose Ihs and rhs are not dimen-

sionally equal. Most of the empirical or semi-empirical equations in chemical process

design fall into this category. We call these expressions empirical expressions. Em­

pirical expressions differ from their dimensional counterparts in that no dimensional

equality checking is performed. Dimensional checking will be disabled automatically

 48

// normal expression
// r = 1.987 cal/gmol/K
double r = 8320.0; // = 8320 J/kmol/K
double p = 101325.0; // p = 1 atm = 101325 Pa
double t = 298.15; // t = 25 C = 298.15 K
double v; // V = ?
V = r * t / p; // normal expression
cout << v; // 24.48 cum/kmol

Il dimensional expression

Dimensional R(1.987,cal/gmol/K); // R = 1.987 cal/gmol/K

Pressure P(l,atm); // P = 1 atm
Temperature T(25,C); // T = 25 C
Molar_volume V; // V = ?
V = R * T / P; // dimensional expression
cout << V; // 24.48 cum/kmol

// invalid dimensional expression

Area a(20,sqcm); // a = 20 sqcm

Length b(10,cm); // b = 10 cm
a = a + b; // invalid! a ft b are
// dimensionally different

// valid dimensional expression.

Length 1(3,cm); // 1 = 3 cm
Dimensional s(20,kg/cm); // s = 20 kg/cm
s = 1 * s; // s is now mass (s = 60 kg)

Figure 4.8: Dimensional expressions example

 49

Length dh(7.48,m); // dh = 7.48 m

Volume.flowrate q; // q = ?
q(cuft/s) = 0.27 * sqrt(dh(ft)); // empirical expression
cout << q; // 0.038 cum/s

Figure 4.9: Empirical expressions example

if a dimensional expression contains physical quantities with their units specified.

For example, to calculate the volumetric flowrate through a valve in a liquid storage

tank, an equation of the following form is used: q{cxtft/s) = 0.27^dh{ ft). Figure 4.9

shows how this can be programmed using PQS.

The inherent nature of the conversion function used { y = a x + b ) , differentiates

normal and difference quantities. A difference quantity, as the name implies, is the

difference between two values of a physical quantity. Change in pressure {DP) and

change in temperature (DT) are examples of difference quantities. In the expression

T = T + DT, where T is the temperature and DT is the temperature difference,

T = 20C implies T = 293.15A' and DT = 5C implies DT = 5A'. Temperature

(T) is a normal physical quantity and temperature difference {DT) is a difference

physical quantity. Physical quantities like temperature difference are defined as dif­

ference quantities. As shown in Figure 4.3, the object dimensional is specialized

into difference dimensional to account for difference quantities that are not specifi­

cally categorized under physical quantity. Figure 4.10 shows a programming example

involving temperature difference.

The fact that all the objects in PQS have input/output operations defined around

them makes the PQS very powerful for entering/displaying physical quantities in user

preferred units/unit systems and for writing interactive programs such as unit con-
 50

Temperature T(25,C); // T = 25 C
Temperature.difference DT(25,C); // DT = 25 C
cout << T; // 298.15 K
cout << DT; // 25 K
T = T + DT; // dimensional expression
cout << T; // 323.15 K

Figure 4.10: Difference quantities example

verter, that converts physical quantities from one unit to another. An interactive unit

converter was written using PQS that was less than thirty lines of source code. This

shows the elegancy of object orientation in achieving tremendous gains in software

productivity. The stand alone nature of the PQS makes it useful not only for process

simulation but for any application that deals with units of measurement. This kind of

reusability is another attractive feature of object orientation that makes the software

development easier and faster.

Physical Property System

Physical property calculations play a major role in any process simulator. The

material and energy balance calculations of the Flowsheet System, FS, make use of

the property estimation procedures of the PPS. The design of the PPS affects the

performance of the simulator as a whole. Chemical components, component data

bank and physical properties are the major constituents of PPS. Even though the

PPS and the FS are two separate components of the process simulator, the interaction

between the two does not allow an independent design of these two systems. Since

PPS involves physical quantities like enthalpy and density, its development requires
 51

the PQS. Figure 4.11 shows the relationship among the objects defined in the PPS.

Chemical components

Chemical components or simply components form the basis for PPS. Compo­

nents are defined as objects and the physical properties as the operations around

these objects (Figure 4.12). We encounter various types of components in a typi­

cal process flowsheet. Conventional chemical compounds, non-conventional coal and

mineral solids, petroleum and coal liquid fractions. The diversity arises from the

characterization of these various components. The characterization of a component

establishes the data required to identify that component and deduce the physical

properties of that component from the component data using various physical prop­

erty estimation procedures.

Conventional chemical compounds are well understood regarding their charac­

terization and their characterization stems from theoretical principles and empirical

correlations [18]. Non-conventional coal and other mineral solids are characterized in

a variety of ways and none of the schemes provide a complete identification for these

components with the result that all or some of them are used to estimate their phys­

ical properties. For example, coal characterization schemes include ultimate analy­

sis, proximate analysis and sulfonate analysis. There is no proper characterization

scheme for petroleum and coal liquid fractions and the subject is still under active

research [17, 23]. Assay data analysis in terms of boiling point and specific grav­

ity curves and pseudo-component methods provides one way of characterizing these

components. The characterization depends on the validity of the various correlations

used to convert assay data analysis from one type of boiling point curve to another
 52

Phase mixture

L Phases

Component mixture
Reaction

L L Components

Participants
L
H— Component
L Formula
i

' State A

Substance Property value

Component Component mixture Simple Aggregate

Property method Property method set

Substance L Property methods

Property
Property method system
State
Property ^ Non-equivalent
function property methods

Figure 4.11: Relationship of the objects in the PPS

 53
Consonant

Physloal
Properbles

Methane

Denalty
Enthalpy

Figure 4.12: The object component

and also the empirical correlations used to generate the pseudo-components from

these boiling point curves and to establish the identity of these pseudo-components.

An altogether different approach of characterizing the petroleum fraction as a contin­

uous mixture is gaining acceptance in the literature [22]. There are some components

like charcoal which can be treated as both conventional components (carbon) and as

non-conventional components (coal). This adds additional complexity to the com­

ponent hierarchy. Note that the same compound (say coal) depending on its phase

(solid/liquid) requires different characterizations (non-conventional/coal fraction).

Figure 4.13 shows the component hierarchy as defined in the PQS. Compo­

nent is divided into conventional and non-conventional components. Conventional

component is again specialized into molecular component. Ionic components and

petroleum components can be further specialized from the molecular component but

they haven't been implemented in the present work. Ionic components are required to

simulate processes involving electrolytes. Petroleum components, also called pseutlo-

 54

components, are required to simulate processes involving petroleum fractionation.

Note that pseudo-components are useful only if the petroleum fraction is treated as

a mixture of discrete components. If instead the petroleum fraction is treated as a

continuous mixture, a new type of component has to be defined with physical prop­

erty calculation methods radically different from those used for pseudo-components.

Hence it is clear with the continuous development of new component characterization

schemes, new component property calculation procedures and new simulation/design

methods for process equipment, arriving at a fixed software design of the process

simulation application will never be realizable. But the challenge for the process

software designers/developers lies in fore-seeing these new surprises and, effectively

using techniques such as object orientation, coming up with a software design that

is likely to require the fewest changes in the future.

Properties such as enthalpy, density, Gibbs free energy and fugacity coefficient

can be calculated for a component using its operations. The details of these physical

property calculations can be found in the work of Lau [8]. We rarely work with just

pure components. A component mixture, which is a mixture of pure components is

another object defined in PPS. Similar to component, component mixture also has

properties around it as operations. The physical property operations of a component

mixture make use of the physical property operations of the pure components. Since

a component mixture is a mixture of components and components are divided into

various types, component mixture also needs to be divided into various types. Fig­

ure 4,13 shows that component mixture is divided into molecular component mixture

and mixed component mixture, A mixed component mixture, as the name implies, is

a mixture of components of any type. A molecular component mixture is a mixture of

 Component
Component mixture

Conventional Non-conventional Molecular Mixed

I I
Molecular Coal Component set

Component pair I Components

Component pairs
I— First component

Second component Molecular

Figure 4.13: Component hierarchy

only molecular components. In the present work, again, component mixtures such as

electiolytes and jietroleum fractions are not implemented, but they can be included

without too much effort because they eventually make use of the operations defined

around the molecular component mixture.

Most of the physical property models require binary interaction parameters.

Component pair can be used to store the binary parameters. Also, some of the

binary interaction parameters may not be symmetric and this requires the component

pair to be ordered. That's the reason why the components in a component pair are

named first component and second component. The user has no control of specifying

a component to be first or second. Instead, the object compojient pair automatically

decides a component in a component pair to be first or second based on comparing

 56

the names of the two components. This makes it much easier for the user to simply

specify the interaction parameters for a pair of components without worrying about

their order in the component pair. Let us say we have 10 components and we would

like to store a binary interaction parameter for those components. That requires 45

(^^62) component pairs to be stored. For 20 components, 190 component pairs. It

is clear that for components in the range of hundreds (which is not uncommon in

industrial processes), a huge amount of data space is required to store the components

and their associated binary parameters. This requires only the components required

in a particular simulation run to be stored in the primary computer memory. All

others must be stored in the secondary storage such as disk. Note that some of

the physical property models (e.g. liquid phase equilibrium calculations) require

ternary interaction parameters, besides binary parameters. This increases the storage

space requirements tremendously. A data bank that stores all the components and

their associated interaction parameters is required to alleviate the primary storage

problems. Component data bank is discussed later in this chapter.

Components and component pairs used in the component mixture are placed

in the object component set. By doing so all the material streams present in the

flowsheet can share a single set of components, which reduces duplication to a great

extent. It is often the case that the same components are used throughout the

flowsheet and if the data of a component is changed the changes need to be reflected

everywhere. As shown in Figure 4.13, component set is further specialized into molec­

ular component set. Molecular component set contains only molecular components

and molecular component pairs. It can be used to store components and component

pairs in a molecular component mixture.

 57

A molecular component can be identified by its molecular formula. Molecular

formula in turn is identified by a collection of atoms. The number of the participat­

ing atoms and their atomic weights facilitate the calculation of molecular weight for

the formula object. Chemical components participate in reactions. The state of the

component participating in the reaction can be solid, liquid or vapor. Also, compo­

nents participate in reactions according to some stoichiometric ratios. The collection

of component, state and stoichiometric number yields the object participant. The

object reaction contains reactants and products. Reactants and products are a set of

participants. Figure 4.14 shows an example involving reaction. It can be seen that

starting from simple objects, using object modeling concepts such as aggregation and

generalization, complex objects and hierarchies can be created with ease.

Phase fixes the state of a component mixture. Phase mixture is a collection of

phases. There can be any number of phases in a phase mixture. Also, the phase

present may or may not be in phase equilibrium. Molecular phase mixture is a

phase mixture containing only molecular components. Contrary to phase mixture,

molecular phase mixture allows only equilibrium phases. When physical properties

are requested, a molecular phase mixture uses flash calculations to establish the

phases from the total component mixture present in it. In the present work, only

two phase (vapor-liquid) flash calculations are performed, but three phase (vapor-

liquid-liquid) calculations are also quite common in process simulation and they can

be incorporated without much effort. Phase mixture can eventually be used as part

of a material stream in the Flowsheet System, FS.

 58

// Atoms

Atom C ("C",12); // carbon atom

Atom H C'HM); // hydrogen atom
Atom 0 ("0M6): // oxygen atom

// Formulas

Formula CH4_ (C-H[4]); // methane

Formula H20_ (H[2]-0); // water
Formula C0_ (C-0); // carbon monoxide
Formula H2_ (H[2]); // hydrogen

II Components

Moleculeu:.component CH4 (CH4_); // methane

Molecular.component H2D (H20_); // water
Molecular_component CO (CO.); // carbon monoxide
Molecular.component H2 (H2.); // hydrogen

// Reaction

Reaction R (CH4 [G] + H20 [G] » CO [G] + 3 * H2 [G]);

Figure 4.14: Example involving reaction

 59

Physical properties

To calculate the physical properties of a component or a component mixture,

we have to specify the state of the system such as the temperature and pressure.

Also, it will be computationally superior if we calculate certain related properties

together rather than independently, for example, enthalpy and temperature derivative

of enthalpy. In general, a physical property procedure takes the state of the system as

input and returns as output one of simple property or aggregate property. To support

this kind of scenario, the object property value is defined. .4n example of a simple

property is the enthalpy of a component mixture. Fugacity coefficients of components

present in a component mixture are returned through the aggregate property.

In the approach used in this work, physical properties form the operations around

component and component mixture. A component or a component mixture will have

different physical properties depending on its state (solid, liquid or vapor). The

object property method contains the information necessary to calculate the physical

property of a component or component mixture for a certain state. It is a collection of

substance, state, property and property function. A substance can be a component or

a component mixture. Property can be any physical property like enthalpy or density.

Property function is the name of the procedure that implements the physical property

calculation for a substance.

Invariably, there will be more than one method of calculation for any physical

property. These methods vary in their accuracy and applicability. The object prop­

erty method set implements this fact. It is a collection of property method objects.

As an example, enthalpy of a component in the vapor state can be calculated by

assuming it to be an ideal gas, or by using equations of state. Again a number of

 60

equations of state exist which differ in applicability. So, to calculate the vapor en­

thalpy of a component, we may have three property methods: one using ideal gas,

one using SRK equation of state and one using PR equation of state. All these may

be put in the property method set to tell the programming system that there are

alternatives to calculate the same property.

A method of calculation for a physical property may involve other physical

properties as intermediate properties. As Figure 4.15 illustrates, a physical prop­

erty operation may have many alternatives. Each alternative may have one or more

sub-operations. The sub-operations in turn may have alternatives and so on. This

sort of tree structure is evident among the physical property procedures of process

simulators.

Also, in a simulation run or property run, the user wants to specify the physical

property routes to calculate a certain property. This is achieved in conventional

commercial process simulators using an option set for physical properties [18].

Unfortunately, the object model of OOPL does not support any modeling fea­

tures for the operations. For example, an operation cannot know its sub-operations

that constitute it. As discussed in chapter 3, this is one of the drawbacks of the

object model of OOPL and further work needs to be done to enhance the object

modeling features. Since object modeling is being used in this work, and the object

model does not support operational description, the object property method system

is defined, the primary purpose of which is to support the user in controlling the

physical property calculation procedures. We also note that, the physical property

tree shown in Figure 4.15 is too general and our object property method system rep­

resents a simplified version of it (Figure 4.16). The major difference between these
 61

„/ \ O - Operation
A1) f A2 ) A - Alternative
'—^ ^^ S - Sub-operation

Figure 4.15: Physical property tree

two choices is that in the first case, an operation present in more than one place may

use (lifTerent procedures for its calculation. This is not allowed in the second case

and hence all the operations are at the same level. The simplified physical property

tree will be sufficient for a realistic physical property system and consequently that

is the one used in our approach.

The object property method set contains a set of property methods. Two prop­

erty methods are said to be equivalent if they specify for a substance, in a particular

state, two different property functions for the same property. The object property

method system contains a set of non-equivalent property methods. This is similar

to a unit system where there won't be more than one unit with the same dimension

in a unit system. Propei'ty method systems such as IDEAL, SllK, PR can be either

pre-defined or the user can define new property method systems based on existing
(5 © © © ©
O - Operation
A - Alternative

Enthalpy
Density
SRK enthalpy
SB PB PR enthalpy
SRK density
PR density

Figure 4.16: Simplified physical property tree

 63

property methods. Similar to the unit system, there will be a default property method

system defining the properties calculated for a substance. When the property of a

substance has to be calculated, the default property method system is consulted to

find out which property method is present for that substance and for that property,

and once it is found, it is used to calculate that property. Note that a property may

be major or sub-ordinate. A major property may call many sub-ordinate properties.

When a major property is requested for a substance, the major property gets the

specific property method from the default property method system. The specific

property method will in turn go to the default property method system to get the

property methods corresponding to the sub-ordinate properties present in it. The

exceptions to this are in situations where the major property of a substance requires

its sub-ordinate property to be calculated using the the same calculation method as

the one used in the major property calculation. For example, to calculate the vapor

enthalpy of a pure component, if the default property method system contains the

SRK method to calculate enthalpy, then it is meaningful to calculate vapor density

which is required in the calculation of enthalpy using the same SRK equation of

state, even though the default property method system contains the PR method to

calculate density. Figure 4.17 shows an example involving physical properties.

Component data bank

The existence of hundreds of known components requires a data bank to store

all the component data. During a particular simulation or property run, only those

components of interest should be retrieved from the data bank for program use, saving

the core memory. Component and component pair are the objects that will be stored
 64

property_method_system (SRK); // SRK method

Molecular.component iso_butane ("iso-butane");

Molecular.component ethane ("ethane");

Temperature t (250,K); // t = 250 K

Pressure p (5,atm); // p = 5 at m

output_unit_system (MET); // Metric system

cout << t(SI); // 250 K

cout << p(bar); // 5.06625 bar
cout << iso_butane.vapor_density(t,p); // 0.018945 gm/cc
cout << ethane.liquid_enthalpy(t,p); // -790.801 cal/gm

Molecular_component_set mes (iso_butane,ethane);

Molecular_component.mixture mem (mes);

mcm.mole_fraetion(iso_butane) =0.4;
mem.mole.fraction(ethane) = 0.6;

cout << mem.vapor.fugaeity_eoefficient(t,p); // 0.82, 0.94

Molecular.phase.mixture mpm (mem);

cout << mpm.molar_enthalpy(t,p); // -28400 eal/gmol

cout << mpm.vapor.phase.fraetionO; // 0.4

Figure 4.17: Example involving physical properties

 65

Data bank Data Index

" store (Persistant) ~ Store

" Retrieve — Retrieve

— Modify — Modify

" Remove " Remove

. Traverse

~~ Allooate_spaae

— Deallooatespaoe

— Pill_spaoe

Read spaoe
Persistent

Persistent Component Component pair

Store (Data bank)

Retrieve

Modify

Remove

Figure 4.18: Data bank operations

in the object data bank. Component contains the universal constants and model

specific parameters and a component pair allows binary interaction parameters to be

stored. Figure 4.18 shows the operations around data bank.

The object data bank stores information about the objects component anil com­

ponent pair. How will it know how to store an object? Obviously, the dala bank will

have no idea of tlie structure of the object. So, it simply asks the respective object

to get itself stored in the data bank. Now, the stored object takes control and taking
 66

Data bank Objects

Figure 4.19: Data hank as a mediator

the help ol'storage management operations of the data bank, gets itself stored in the

data bank. Hence, the data bank merely acts as a mediator between the object and

the user (Figure 4.19) and provides permanent storage facilities for the objects. 'J'he

only intelligence the data bank has is that it knows what objects it contains, but does

not know how it is stored. However, with this little knowledge, it can, il" necessary,

approach the respective objects and can manage the information contained within it.

All objects that have to be stored in the data bank have to be put under the object

persistent (Figure 4.18). Data bank and persistent talk to each other through the

operations they have in common, operations such as store, retrieve etc.

The object data index allows the data in the data bank to be stored as a tree-like

structure. This tree-like structure allows fast access to individual objects from the

disk. Data index is implemented as a B-tiee. B-tree [7] is a data structure that

provides fast access to external information (information that is stored on disk in the

form of files). It is a multi-way search tree, with some restrictions on its growth I hat

will minimize file accesses. Data index contains a set of keys with their respective

data values. So, given a key, it searches the tree to get the data belonging to that

key. The length of the key and data fields can be specified when the clala index is
 67

Cl 02

02 03 04

C - Component
BP BP - Binary parameters

Figure 4.20: Storage of binary parameters

constructed. Objects use data index to their advantage to store data, in the object

data bank. Figure d.lS shows the operatioJis around data index. When a new data

bank is created, it starts with a top level empty data index. This tree contains as

key, the object type (component, component pair etc.) and as data, a pointer to

some space in the data bank. Objects store their data using whatever approach they

i'eel is best, and pass the top pointer back to the data bank. Data bank stores the

pointers under the key belonging to that object's type. To store the data belonging

to it, component creates a new data index, the key being the name of the component,

and the data being a pointer to the storage space in the data bank that contains

the component data. On the other hand, component pair creates two levels of data

index, one for storing the second component and the otiier for storing the binary
interaction parameters as shown in Figure 4.20.

A default data bank called public data bank is created and loaded with a number

of commonly used chemical components and component pairs. Whenever a compo-

 68

Molecular.component methane ("metheme");

Molecular_component ethane ("ethane");
Molecular_component_pair methane_ethane (methane,ethane);

methane.acentric_factor(0.012);
methane_ethane.srk_kij(-0.003);

Data_bank private ("private.db",public_data_bank);

private.store(methane);

Molecular.component CH4 ("methane",private);

cout << CH4.acentric.factor0 ; // 0.012

Figure 4.21: Example involving data bank

nent or component pair is defined in a program, the public data bank is automatically

searched and retrieved if it is present in the data bank. The user may specify a par­

ticular data bank to be searched for a component instead of the public data bank.

Since a data bank can be copied from one to another, the user can make a private

copy of the public data bank and make modifications to the personal copy by adding

additional components or changing the data of existing components. Figure 4.21

shows a programming example involving data bank.

Flowsheet System

This is the top-level component of the process simulator. It encompasses all

the objects necessary to perform steady-state simulation. Steady-state simulation

of a process flowsheet can be performed by either sequential modular approach or

simultaneous equation based approach. In the sequential approach, each process unit
 69

present in the flowsheet is represented by a module and the modules are solved in

sequence. Each module takes the inlet streams of the process unit as input and

performs the material and energy balance calculations using the modeling equations

specific to the unit operation being carried out in the process unit. The output of

the module is the outlet streams of the process unit. In the simultaneous approach,

all the modeling equations of all the process units present in the flowsheet are solved

simultaneously without the need for any sequence. Some of the variables are known

and the rest are unknown, and the number of equations must be equal to the number

of unknown variables in order to solve the resulting consistent set of equations. Both

approaches have advantages and disadvantages. The objects in the Flowsheet System,

FS, are designed in such a way that both sequential and simultaneous approaches to

flowsheet calculations can be supported. Figure 4.22 shows the relationship among

the objects defined in the Flowsheet System, FS.

Balance equations

Process simulation involves solving the material and energy balance equations

for all the process units present in the flowsheet. Figure 4.23 shows the hierarchy of

objects created for supporting equations. The object equation variable is different

from a normal programming variable in that if it participates in an expression its

value won't be evaluated immediately, but stored as an equation expression. The ob­

ject equation represents the mathematical relationship among the equation variables

present in it. Not just one equation, but hundreds of them are required to model

any sizable process flowsheet. The object equation set is a collection of one or more

equation objects. Equation solution procedures are built around the equation set.
 70

Flowsheet

b Equipment units
a4> v>B 4
Constraints a I

Flowsheet
b Streams
Constraints

Ordered Unordered

Equipment unit

Flasher Mixer Splitter

Constraint

Recycle Inverse Implicit Explicit

Stream

Material Energy

Molecular

Figure 4.22: Relationship of the objects in the

 71

Equation set

— Equations

Matrix
— Sparse matrix Equation expression

Equation variable L Equation variable

Static Dynamic

x\
Double Dimensional Independent Dependent Derivative

Equation

Static Dynamic

Algebraic Procedural Algebraic Procedural Differential

Procedural object
Equation set
— Equation variables
Number of equations
Function values
Static Mixed
~ Evaluate
— Evaluate approximate

Figure 4.23: Object, hierarchy for equalious

 72

Steady-state simulation of a flowsheet involves only algebraic equations. But, dy­

namic simulation involves differential equations also. To support both requirements,

the equations and hence, equation variables and equation sets are divided into various

sub-types. An equation can be static or dynamic. Static equations model equations

that are not functions of time or any other independent variable. Dynamic equations

model equations that are functions of time or any other independent variable. Static

and Dynamic equations are divided again into algebraic and procedural equations. In

process simulation, the majority of balance equations involve physical property calcu­

lations. If the simultaneous approach is used to perform simulation, it is impractical

to include the equations and variables involving physical property calculations into

the general set of equations and variables. Instead, the equations involving physical

properties are solved separately from the main set of equations. The commonly used

technique is that at the beginning of each iteration, the equation solver calculates all

the physical properties necessary for the main set of equations. The technique used in

the present work is not to perform physical property calculations at the beginning of

each iteration, but to integrate them into the main set of equations using procedural

equations. This provides the uniformity necessary for good object design. Using this

new technique, the physical property calculations are still solved separately from the

main set of equations but they are not visible to the equation solver. Procedural

equations are defined in terms of procedural objects. A procedural object contains

all the information necessary to be treated as an equation. As shown in Figure 4.23,

it has as its data: equation variables, number of equations and function values, and

as its operations: evaluate and evaluate approximate. To get the function values of

a procedural equation (Note that a procedural equation may in fact represent more
 73

Equation.variable X;
Equation.variable Y;

X « 0.5; // X = 0.5
Y « 0.3; // Y = 0.3

Equation e (5 * log(0.8+0.16/Y) - X/(Y+0.2) =4.46);

Equation f (X + Y = 0.8);

Equation.set s (e,f);
s.solve 0 ;

cout « X; // X = 0.7574
cout « Y; // Y = 0.0426

Figure 4.24: Example involving equations

than one equation), the evaluate operation of the procedural object is executed. The

operation evaluate approximate may be used to get approximate function values when

the rigorous evaluation of the equations is too expensive and approximate function

values are sufficient. An example where approximate function values are sufficient is

when the equations are perturbed to get the interaction of the variables present in
the equations. Figure 4.24 shows an example involving equations.

Since the simulator is required to support both sequential and simultaneous

approaches, an equation variable is allowed to have direct link with a normal pro­

gramming variable. Since the simultaneous approach needs good initial guesses to

arrive at a fast converged solution, and the sequential approach with its robust in­

dividual equipment models can provide good guesses, the switch over between these

two is simple if there is a direct connection between normal programming variables

like double (in C+-I-, double is a data type for representing double precision num-
 74

double d = 2; // d = 2
Temperature t (300,K); // t = 300

Equation.variable D ("D",d): // D -> d

Equation,variable T ("T",t); // T -> t

cout << D; // 2
cout << T; // 300

d = 4; // d = 4

o
o
T « 400;

II
cout << D; // 4
cout << t; // 400 K

Figure 4.25: Example involving equation variables

bers) which will be used for the sequential approach and equation variables which

will be used in the simultaneous approach. The static equation variable is in turn

divided into double and dimensional equation variables. Since in process simulation,

dimensional variables (physical quantities) are used even more frequently than dou­

ble variables, it is natural to connect an equation variable to either a double or a

dimensional variable. The example in Figure 4.25 illustrates this.

A dynamic variable is divided into an independent variable, a dependent vari­

able and a derivative variable. A variable like time can be defined as an independent

variable. Dependent variables are functions of the independent variable. In dynamic

simulation, examples of dependent variables are flowrate, temperature, etc. A deriva­

tive variable is a function of independent and/or dependent variables. The derivate

of flowrate with time can be treated as a derivative variable.

 75

Besicles algebraic and procedural, dynamic equations also contain differential

equations. Differential equations involve derivative variables besides other type of

variables.

An equation expression provides the link between equation variables and equa­

tions. It is implemented as a binary tree. A binary tree [7] is a data structure in

which every node points to two more nodes. Since most of the arithmetic operators

involved in an equation expression are binary (binary operators take two operands)

binary tree is a natural data structure for storing the equation expression. When

an equation has to be evaluated, the binary tree of the equation expression will be

traversed.

Numerical solution of the equations requires the object matrix and its associ­

ated operations: matrix multiplication, addition, decomposition etc. to be defined.

Vector, diagonal vector and permutation vector are derived from matrix to facilitate

matrix operations. Matrices involved in process flowsheet calculations are mostly

sparse. Sparse techniques are essential to solve flowsheeting problems, otherwise the

storage requirements are excessive and speed deteriorates rapidly with the size of the

problem. Sparse techniques are implemented around the object sparse matrix.

In this work, the operations around the object equation set allows only the

solution of the algebraic equations. This is because only sequential and simultaneous

approaches to process simulation are supported in this work. The equation set has to

be augmented with operations for the solution of the differential equations if dynamic

simulation has to be performed. The non-linear algebraic equations are solved using

the modified Powell's dogleg method developed by Chen and Stadtherr [2, 3] for full

and sparse matrices. The details of the solution procedures are discussed by Lau [8].
 76

Process flowsheeting

Material and energy is invariably recycled back in any typical industrial chemical

process. This creates recycle loops in the flowsheet representing that physical process.

Also, to achieve the desired product quality and yield, industrial processes use process

controllers to maintain some of the process parameters at preset values. This creates

control loops in the flowsheet. A control loop can be feed forward or feedback. In

feed forward control, the value of a downstream process parameter is set based on

the values of upstream parameters. In feedback control, the upstream parameters are

manipulated to achieve the desired values of the downstream parameters. Control

loops may also be artificially created by the process designers to make what-if studies

(in the form of design specifications) on the process flowsheet. Figure 4.26 shows a

simple flowsheet with recycle and control loops.

Since, in the sequential modular approach to process simulation, calculations

are performed in sequence, module by module, the presence of recycle and feedback

control loops makes it necessary to tear these loops, sequence the modules and per­

form iterative calculations until the guessed and calculated values of the tear streams

match within a desired tolerance. For the flowsheet in Figure 4.26, tearing the recycle

stream results in the calculation sequence shown in the figure. In the simultaneous

approach, recycle and control loops either augment the equations of the flowsheet by

a certain number or make known variables unknown and unknown variables known

so that the final set of equations representing the flowsheet is consistent. The equa­

tions resulting from the presence of recycle and control loops may be called constraint

(equality constraint) equations. So, constraints in the simultaneous approach are sim­

ilar to the design specifications and tear streams found in the sequential approach.
 7T

Recycle Split Product

- - Tear stream
Vapor

Feed Mix Mixed Flash

Liquid

FF - Feed forward: Set Flash temperature

to Mix temperature
FB - Feedback: Adjust Flash pressure
until Product flowrate - 0.5 kmol/s
Tear stream: Recycle •

Sequence: Mix Flash Split

Figure 4.26: A flowsheet with recycle and control loops

 78

In commercial process simulators, the approach used for calculation, sequential

or simultaneous, strongly influences the definition of the flowsheet. For example,

in a simulator such as ASPEN-PLUS, which uses the sequential approach, every

equipment module assumes that some parameters are known and others unknown. To

make a known parameter, unknown, a module (design specification block or fort ran

block) has to be created. Also, the module has to be identified as feed forward,

feedback or recycle, even though the user may not know in advance whether a module

is feed forward or feedback. Note that in feedback control the upstream parameters

fix the value of a downstream parameter, upstream/downstream are meaningful only

when the sequence of the flowsheet is known, but the user has no way of knowing

in advance the sequence generated by the simulator. In this work, it is felt that the

definition of a flowsheet must be independent of the approach used for performing

the simulation calculations. Once a flowsheet is deflned, the user must be able to

perform simulation using any one of the approaches without giving additional data

for the flowsheet's definition. To support this idea, the flowsheet is defined in terms

of equipment units and constraints, and the constraints need not be identified as feed

forward or feed back, instead they must be specified whether implicit or explicit. The

sequence of the flowsheet need not be known to specify a constraint to be implicit

or explicit. Depending on the sequence, the simulator may internally convert an

explicit constraint to an implicit constraint and perform the sequential calculations.

Constraints are discussed in detail later in this chapter.

Material or energy flows from one process unit to another in a physical process.

The object stream models these flows. Streams convey the inter-relationship among

the process units. Streams are divided into material and energy streams. Material
 79

stream models the flow of material in a process. Energy streams convey the transfer

of energy flow from one process unit to another. Material stream contains the object

phase mixture defined in the PQS. So, it forms the connection between the PQS and

the FS. Figure 4.22 shows the stream structure.

The object constraint models both the behavior of design specifications and

tear stream specifications encountered in the sequential approach and the equality

constraints found in the simultaneous approach. It is divided into four types: recycle

constraint, inverse constraint, implicit constraint and explicit constraint. Recycle

constraint, as the name implies, is used to specify tear streams. In the sequential

modular approach, since the calculation flow is sequential, any flow of material or

energy that is in the opposite direction has to be iterated until the convergence is

achieved between the guessed and calculated values. In the simultaneous approach

recycle constraint has no significance because equations from all the process units are

solved simultaneously. An inverse constraint allows specifying a known variable as

unknown and an unknown variable as known. Since in the simultaneous approach,

all are equations, it should not matter at least from the user's point of view, if known

and unknown variables are interchanged. But for the sequential approach, changing

a variable from known to unknown creates an additional convergence loop that has to

be torn and iterated. Implicit constraint, as the name implies, provides an additional

implicit equation, for example y = f{x,y), and reduces the number of known variables

by one. In the the sequential approach this resembles a design specification or a

feedback control specification. The variable which has been made unknown has to

be iterated until the implicit equation is satisfied. Note that inverse constraint is

a variant of implicit constraint. Sometimes we may encounter explicit constraints.

 80

An explicit constraint again, as the name implies, gives an explicit expression for

a variable (of the form y = f{x)) and reduces the known variables by one. In the

simultaneous approach this is not much different from an implicit constraint, but in

the sequential approach time can be saved if, instead of iterating on the unknown

variable, the variable is simply set by the value of the explicit expression. Of course,

this is possible only if the calculation sequence is such that the variables involved

in the explicit expression are calculated upstream. An explicit constraint is similar

to a feed forward control specification. Figure 4.22 shows the object hierarchy for

constraints.

Process unit in a flowsheet is represented by the object equipment unit. The

operations around this object allow the analysis of the process unit to be performed.

The mathematical representation of a process unit is contained within the equipment

unit corresponding to that process unit. In the sequential approach, the mathematical

representation is a set of equations with well-defined calculation procedure assuming

some variables to be known and others unknown. Note that the calculation procedure

works only under this assumption. That is the reason why if a known variable

is made unknown one must resort to iterative calculations because the procedure

always treats that variable as known. The advantage of the sequential approach is

that the calculation procedure is robust and rarely fails. The disadvantage is that if

too many variables that the procedure assumed to be known are, in fact, unknown,

it is difficult to converge the iterative calculations. For a simultaneous approach, the

mathematical representation is a set of equations modeling the physical process unit.

In this case a robust equation solver, which seems not to be available yet, is required

to solve the equations. Equipment unit is divided into flasher, mixer, splitter etc.
 81

Each of these models a unit operation. Equipment unit contains streams, as inlets

and outlets. In the sequential approach, the outlets are calculated based on the

values of inlets and parameters of that equipment unit. Figure 4.22 shows the object

hierarchy for equipment units.

Process flowsheets are the logical representations of physical processes. Process

simulation is eventually performed on the process flowsheet. Flowsheet is a collec­

tion of equipment unit objects. Equipment unit objects in turn have references to

the stream objects. Stream object in turn to phase mixture and so on. So, flowsheet

is the top-most object in the process simulator. Flowsheet may have constraints. Be­

cause of the support of both sequential and simultaneous approaches, a flowsheet is

divided into ordered and unordered flowsheet. Figure 4.22 shows the object hierarchy

for the flowsheet. In an ordered flowsheet the sequence of equipment units is already

established. In an unordered flowsheet the sequence does not matter. Consequently,

unordered flowsheet is used for simultaneous calculations and ordered for sequen­

tial calculations. To perform sequential calculations on an unordered flowsheet, the

unordered flowsheet is automatically converted into an ordered flowsheet before the

calculations are performed. On an ordered flowsheet, both sequential and simultane­

ous calculations can be performed. Figure 4.27 shows the programming example for

the flowsheet in Figure 4.26.

Simulating an unordered flowsheet is straight forward because once the equa­

tions representing all the equipment units present in the flowsheet are gathered into

an equation set, the equation set can be solved using the operations around the

equation set. As discussed before, one of the operations around the equation set is

to solve a set of non-linear algebraic equations. This is the same whether constraints
 82

Molecular.component propeoie ("propauie");

Molecular.component ethane ("ethame");
Molecular_component_set mes (propeme,etheme);

Molecular_material_stream feed ("feed", mes);

feed.molar_flowrate(propane)(0.6,kmol/s);
feed.molar.flowrate(ethane)(0.4,kmol/s);
feed.pressure0(100,psi);
feed.temperature0(85,C);

Molecular_material_stream mixed ("mixed",feed);

Molecular_material_stream liquid ("liquid",feed);
Molecular_material_stream vapor ("vapor",feed);
Molecular_material_stream recycle ("recycle",feed);
Molecular_material_atream product ("product",feed);

Mixer mix ("mix",mixed,feed,recycle);

Flasher flash ("flash",mixed,vapor,liquid);

flash.pressure()(25,psi);
flash.temperature 0(5,C);

Splitter split ("split",vapor,product,recyle);

split.split_fraction()(0.5);

Explicit.constraint ec (flash.TEMPERATUREO,
mix.TEMPERATUREO .flash,mix);

Implicit_constraint ic (flash.PRESSURE(),
product.MOLAR_FLOWRATE() = 0.5,flash,product);

Unordered.flowsheet f ("flowsheet",mix,flash,split);
f.constraints(ec,ic);
f. simulate 0 ;

Ordered.flowsheet of = f.sequenceO ;
of.simulate0 ;

Figure 4.27: Example involving flowsheet

 83

are present in the flowsheet or not. But for an ordered flowsheet, the presence of

constraints makes the calculations iterative. The definition of the flowsheet is re­

cursive. That is, an ordered flowsheet is a sequence of equipment units and ordered

flowsheets. An unordered flowsheet is a set of equipment units, ordered flowsheets

and unordered flowsheets. This recursive definition allows smaller flowsheets to be

included in a larger flowsheet and also to divide a large flowsheet into sections which

can be simulated individually.

Conversion of an unordered flowsheet into an ordered flowsheet and simulating

an ordered flowsheet needs some discussion. The first step in arriving at the ordered

flowsheet is to build the digraph from the equipment units and streams present in

the unordered flowsheet. A digraph is a graphical representation of the flowsheet

in the form of vertices and directed edges. Then the digraph is updated to reflect

the presence of constraints in the unordered flowsheet. That is, for every constraint,

additional edges are added into the digraph if the edges involving that constraint

are not already present in the digraph. Then the edges of the digraph are given

weights. When the decomposition step is performed on the digraph, weights deter­

mine whether an edge has to be torn or not. The given weight depends on whether the

edge represents a material stream, energy stream or if a constraint, what type of con­

straint etc. The lower the weight the more chance that it may be torn in the tearing

step of the decomposition algorithm. In general, constraints and energy streams are

given lower weights, and material streams are given higher weights because tearing

an energy stream gives much faster convergence than tearing a material stream. An

energy stream typically contains only one variable that has to be iterated, whereas a

material stream with its component flowrates, temperature, pressure and enthalpy is
 84

more difficult to converge in iterative calculations. Once the weights are assigned, the

decomposition algorithm developed in [20, 8] is applied over the digraph. Decomposi­

tion of a digraph consists of partioning followed by tearing. Partitioning of a digraph

breaks it into a set of strong components. A strong component, in a loose sense, is

the largest part of the digraph that cannot be further subdivided without tearing

an edge. The reader is referred to any text book on graph theory for the rigorous

mathematical definition of a strong component. In the tearing step, all the loops are

torn and the sequence is generated. Once the strong components are identified and

the sequence is generated, the equipment units present in each strong component are

placed in an ordered flowsheet unless the strong component contains only a single

equipment unit. These ordered flowsheets and equipment units in turn are placed in

an ordered flowsheet that will eventually be simulated. All the constraints and tear

streams belonging to a strong component are placed in an ordered flowsheet created

for that strong component.

To simulate an ordered flowsheet, we check to find any constraints. If there are

no constraints, each equipment unit in the ordered flowsheet is simulated one after

another in sequence. If there are constraints, an equation set containing a procedural

equation is created. The procedural equation is connected to a procedural object

which in turn executes the constraints and simulates the equipment units when the

equation is evaluated. Hence, the solution of the equation set results in the simulation

of the ordered flowsheet.

 85

CHAPTER 5. CONCLUSIONS

Our main research interest lies in applying the concept of object orientation to

process simulation. We want to establish that object oriented process simulation is

more functional and flexible than its conventional counterpart. Our approach to the

simulation consists of using an object oriented programming language to act as an ob­

ject oriented programming system for the process simulation. The process simulation

becomes an object library to the programming system. We believe object modeling

is the key to successful object oriented process simulator development, primarily be­

cause objects provide the vehicle for process integration. Even though object design

is an important aspect of object orientation there has never been an established ob­

ject design criteria. We provide a set of guidelines for object selection and design. We

also explore the suitability of object modeling in the process simulation environment.

It is found that the object model has to be extended with operational behavior

to effectively represent the process simulation information, the development effort is

greatly reduced by using the object oriented approach for the process simulator, ob­

ject standardization including object design criteria is essential for achieving process

integration, OOPL can act as common platforms for integrating process engineering

activities, and C + + can be effectively used for implementing object oriented simula­

tion applications. The ease with which the sequential and simultaneous approaches
 86

are incorporated into the process simulator reflects the potential of object oriented

programming for process engineering applications. It can be seen that the developed

process simulator can be easily extended with dynamic simulation capabilities by

adding only a few more objects.

The major impact of this work is on the development and maintenance of process

design software. The use of commercial OOPL for process simulation and design

shortens the software development cycle. Process simulation using object orientation

eases software maintainance. The reduced cost in the development and maintenance

of design software has direct effect on the investment of a process design organization.
 87

CHAPTER 6. RECOMMENDATIONS

The simulator has to be extended with dynamic simulation capabilities to make

it provide an integrated solution to process simulation. Differential equations are the

main ingredients of dynamic simulation. They were modeled but not implemented

in the present work. So, without too much effort dynamic simulation can be incor­

porated into the existing simulator.

Also, a process simulator has to be interactive and user friendly. To support

this, a graphic inteface has to be developed. The power of software reusability in

the object oriented approach will greatly assist in developing the graphic interface by

permitting use of objects already defined in the simulator.

In the existing simulator, not many unit operation models were implemented.

Only a flasher, mixer, splitter and separator are present in the simulator. However,

since the structure of the program need not be extended to support additional unit

operations, little effort will be required to add new unit operations.

Only two phase calculations are allowed in the current system. Support for

three phase calculations requires a more extensive set of physical property methods

to be added into the simulator. Physical property methods in the current simulator

are based on SRK and PR equations of state. Using these methods, vapor phase

calculations can be performed fairly accurately, but not liquid phase calculations
 88

(especially at high pressures). More accurate liquid phase property methods such as

NRTL and UNIFAC have to be included to enable three-phase calculations.

Finally, with regard to chemical components, only molecular components are

implemented in the present work. Even though the majority of chemical processes use

molecular components, non-conventional components such as coal will be important

to extend the scope of the simulator to processes involving solids. The complex

characterization schemes used for non-conventional components will test the power of

the object model in effectively representing the information contained in real chemical
processes.
 89

BIBLIOGRAPHY

[1] Buchmann Alejandro P., An architecture and data model for CAD databases.
11th International Conference on Very Large Data Bases, Stockholm (1985).

[2] Chen H. S. and M. A. Stadtherr, A modification of Powell's dogleg method for

solving systems of nonlinear equations. Computers and Chemical Engineering 5,
143 (1981).

[3] Chen H. S. and M. A. Stadtherr, On solving large sparse nonlinear equation

systems. Computers and Chemical Engineering 1 (1984).

[4] Cox Brad J., Object oriented programming: An evolutionary approach. Addison-
Wesley, Reading, Massachusetts (1987).

[5] Cmelik Robert F., and Narain H. Gehani, Dimensional Analysis with C++.
IEEE Software 5, 21 (1988).

[6] Joshi A., Y. Yamashita and R. L. Motard, A client-server model of computation

for object oriented dynamic simulation. AICHE Annual Meeting, Chicago ( 1990).

[7] Kruse Robert L., Data structures & program design. Prentice-Hall, Englewood
Cliffs, New Jersey (1984).

[8] Lau Kheng H., Development of a process simulator using object oriented pro­
gramming: Numerical procedures and convergence studies. Ph.D. dissertation,
Iowa State University, Ames, Iowa (1992).

[9] Mehta J., Y. Yamashita and R. L. Motard, Integration technology in process

design and simulation. AIChE Spring National Meeting, Orlando (1990).

[10] Motard R. L., Integrated computer aided process engineering. Computers and
Chemical Engineering, 13, 1199 (1989).
 90

[11] Piela P. C. et. al., Ascend: An object oriented computer environment for model­
ing and analysis: The modeling language. Computers and Chemical Engineering
15, 53 (1991).

[12] Smith J. M. and D. C. P. Smith, Database abstractions: Aggregation and gen­

eralization. ACM Transactions on Database Systems 2, 105 (1977).

[13] Stephanopoulos G. et. al., Model.LA. A modeling language for process engineer­
ing - I. The formal framework. Computers and Chemical Engineering 14, 813
(1990).

[14] Stephanopoulos G. et. al., Model.LA. A modeling language for process engineer­
ing - II. Multifaceted modeling of processing systems. Computers and Chemical
Engineering 14, 847 (1990).

[15] Stephanopoulos G. et. al.. Design-kit: An object oriented environment for pro­
cess engineering. Computers and Chemical Engineering 11, 655 (1987).

[16] Stroustrup Bjarne, The C++ programming language. Addison-Wesley, Reading,

Massachusetts (1986).

[17] Tsonopoulos, Heidman and Hwang, Thermodynamic and transport properties

of coal liquids. John Wiley, New York (1986).

[18] Aspen user manual. Vol. 1. USDOC, Springfield, Virginia (1982).

[19] Aspen system administrator manual. Vol. 1; USDOC, Springfield, Virginia

(1982).

[20] Varma G. V., K. H. Lau and D. L. Ulrichson, A new decomposition algorithm

for process flowsheeting. Accepted for publication in Computers and Chemical
Engineering (1992).

[21] Wandmacher Cornelius, Metric units in engineering - Going SI. Industrial Press,
New York (1978).

[22] William B. T. and A. S. Teja, Continuous thermodynamics of phase equilib­

ria using a multivariate distribution function and an equation of state. AIChE
Journal ^2, 2067 (1986).

[23] Wu R. S., and R. M. Fish, C^ Characterization for fluid properties predictions.

The Journal of Canadian Petroleum Technology 28, 112 (1989).
 91

[24] Yamashita Y., and R. L. Motard, Object oriented integration in process engi­
neering computation. AIChE Spring Meeting, New Orleans (1986).

[25] Winter P., Computer-aided process engineering: The evolution continues. Chem­
ical Engineering Progress 88, 76 (1992).
 92

APPENDIX A. LIST OF OBJECTS

Chapter 4 on program structure gives a detailed description of the objects that

are of primary interest to the users. A number of other objects are required to support

those primary objects. Table A.l Contains a list of all the objects that are defined to

support steady-state process simulation in C++.

Table A.l: List of objects

Neune of the object
Acceleration
Aggregate_property_value
Aggregate_property_value_record
Angle
Angular.frequency
Area
Atom
AtomintAVLMap
AtomintMap
Component
ComponentAVLSet
ComponentDimensionalAVLMap
Component0imensionalMap
ComponentEquation_variableAVLMap
ComponentEquation_variableMap
ComponentMassAVLMap
ComponentMassMap
ComponentMolar_ flowrat eAVLMap
ComponentSet
 93

Table A.l (Continued)

Name of the object

ComponentMolar_flowrat eMap
Component doub1eAVLMap
ComponentdoubleMap
Component_init
Component.mixture
Component_mixture_init
Component_mixture_record
Component _pair
Component _pairAVLSet
Component_pairSet
Component_pair.record
Component.record
Component.set
Component.set.record
Constraint
ConstraintAVLSet
ConstraintSet
Constraint.hemdler
Constraint.handler.record
Constraint.node
Constraint.nodeAVLSet
Constraint.nodeSet
Constraint.node.record
Constraint.record
Conventional.component
Convent ional.component.record
Currency
Data.bank
Data.index
Dep endent.variable
Dependent.variable.record
Derivative.variable
Derivative.variable.record
Derived.dimensional
 94

Table A.l (Continued)

Name of the object

Diagonal.vector
Difference.dimensional
Differential_equation
Differential_equation_record
Diffusivity
Dimension
Dimension_init
Dimension,iterator
Dimensional
Dimensional.init
Dimensional.variable
Dimensional_variable_record
Dimensionless
Double.variable
Double_variable_record
Dynamic
Dynamic_algebraic_equation
Dynamic_algebraic_equation_record
Dynamic.equation
Dynamic_equation_record
Dynamic_procedural_equation
Dynamic_procedural_equation_record
Dynamic_record
Dynamic.variable
Dynamic.variable.record
Energy
Energy.flux
Energy.stream
Energy_stream_record
Equation
EquationAVLSet
Equationset
EquationVec
 95

Table A.l (Continued)

Name of the object

Equation.expression
Equation.expression.record
Equation.record
Equation.set
Equation.set.record
Equation.variable
Equat ion.variableAVLSet
Equat ion.variableSLLi st
Equation.variableSet
Equation.variableVec
Equation.variableintAVLMap
Equation.variableintMap
Equation.variable.record
Equipment.unit
Equipment.unitAVLSet
Equipment.unit S et
Equipment.unitVec
Equipment.imit.pair
Equipment.unit.record
Explicit.constraint
Explicit.constraint.record
Expression.equati on
External.feed.handler
External.feed.handler.record
Flasher
Flasher.kvalue.equation
Flasher.kvalue.equation.record
Flasher.record
Flowsheet
FlowsheetAVLSet
FlowsheetSet
Flowsheet.record
 96

Table A.l (Continued)

Name of the object
Force
Formula
Frequency
Heat_transfer_coeff
Implicit.constraint
Implicit.constraint.record
Independent.variable
Independent.variable.record
Inverse.constraint
Inverse.constraint.record
Kinematic.viscosity
Length
Lengthy.unit
Mass
Mass.density
Mass.flowrate
Mass.flux
Mass.heat.capacity
Mass.specific.energy
Material.stream
Material.stream.record
Matrix
Mixed.equation.set
Mixed.equat ion.set.record
Mixer
Mixer.record
Mixer.stream.pressure
Mixer.stream.pressure.record
Molar.density
Molar.flowrate
Molar.flux
Moleur.heat.capacity
Molar.mass
 97

Table A.l (Continued)

Neune of the object

Molar_specific_energy
Molar_volume
Molecular.component
Molecular.component.mixture
Moleculeu:.component_mixture_record
Molecular_component_pair
Molecular_component_pair_record
Molecular.component.record
Molecular.component_set
Molecular.component.set.record
Moleculeur.material.stream
Molecularjmaterial.stream.record
Molecular.phase
Molecular.phase.record
Ordered.flowsheet
Orderod.flowsheetAVLSet
Ordered.flowsheetOrdered.flowsheetAVLMap
Ordered.flowsheetOrdered.flowsheetMap
Ordered.flowsheetSLList
Ordered.flowsheetSet
Ordered.flowsheetVec
Ordered.flowsheetintAVLMap
Ordered.flowsheetintMap
Ordered.flowsheet.record
Participant
Part i cipemtAVLSet
ParticipantSet
Permutation.vector
Persistent
Persistent.record
Phase
PhaseAVLSet
PhaseSet
Phase.mixture
 98

Table A.l (Continued)

Neune of the object

Phase_record
Physical_quantity
Power
Pressure
Procedural
Procedural_record
Property_function_name
Property_function_nameproperty_functionAVLMap
Property_function_nameproperty_fimctionMap
Property_method
Propert y_methodAVLS et
PropertyjmethodSet
Property_method_init
property_method_set
Property_method_system
Property_method_uniqueAVLSet
Property_method_uniqueSet
Property_value
property.value.record
Reaction
ReactionSLList
ReactionSLSet
Reactionset
Reaction_record
Recycle.constraint
Recycle_constraint_record
Separator
Separator.record
Simple_property_value
Simple_property_value_record
Sparse_matrix
Sparse_matrix_col_iterator
Sparse_matrix_row_iterator
Splitter
 99

Table A.l (Continued)

Neime of the object

Splitter_record
Static_algebraic_equation
Static_algebraic_equation_record
Static.equation
Static_equation_record
Static.equation.set
Static_equation_set_record
Static_procedural_equation
Static_procedural_equation_record
Static.variable
Static_variable_record
Stream
StreamAVLSet
StreamEquipment.imit.pairAVLMap
StreairiEquipment _unit_pairMap
Streamset
StreamVec
StreamintPairAVLMap
StreamintPairMap
Stream_enthalpy
Stream_liquid_enthalpy
Stream.record
Stream_vapor_enthalpy
Substance
Substance_record
Surface.tension
Temperature
Temperature_diff
Thermal_conductivity
Time
Unit
Unit.set
 100

Table A.l (Continued)

Name of the object

Unit_set_init
Unit_set_iterator
Unit.system
Unit_system_init
Unit_system_iterator
Unitised_dimensional
Unordered.floHsheet
Unordered.floHsheet.record
Velocity
Viscosity
Volume
Volume.flowrate
doubleQueue
doubleSLList
doubleVQueue
doubleVec
intAVLSet
intOrdered.flowsheetAVLMap
intOrdered.flowsheetMap
intQueue
intSLList
intSLQueue
intSet
intVec
intPair
intPairAVLSet
intPairQueue
intPairSLList
intPairSLQueue
intPairSet
set
set.iterator
 101

APPENDIX B. C++ CONSTRUCTS

As any other programming language C++ has its own syntax. But since C+ +

is an object oriented programming language, and an object oriented programming

language can be extended with application specific objects, programs written in C++

won't be difficult to understand from the syntax point of view. Table B.l gives an

explanation of the C++ language constructs used in the programming examples

presented in this thesis.

Table B.l; C + + constructs

Construct Explanation
// denotes a comment a line
denotes an end of a statement
<< write out data
» read in data
cin st«mdard input (screen)
cout stemdard output (screen)
double double precision real number