Computers & Chemical Enqineering, Vol. 3, pp. 319-327, 1979 Prmted in Great Britain.

0098-1354/79/040319-09$02.00/O Pergamon Press Ltd.

Paper 6A.3

ASPEN: AN ADVANCED SYSTEM FOR PROCESS ENGINEERING

L. B. EVANS,* J. F. BOSTON, H. I. BRITT, P. W. GALLIER, P. K. GUPTA, B. JOSEPH, V. MAHALEC, E. NC, W. D. SEIDER~ and H. YACI

Department of Chemical Engineering and Energy Laboratory, Massachusetts Institute of Technology,

Cambridge, MA 02139, U.S.A.

(Receivedfor publication 15 November 1979)

Abstract-The paper presents an overview of ASPEN (Advanced System for Process Engineering) which is a next-generation process simulator and economic evaluation system. The system is presently under development for use in engineering of fossil energy conversion processes.

Scope-Unlike most existing simulators, ASPEN is intended for processes involving solids in addition to vapor and liquid streams. ASPEN can represent multi-phase streams and can also handle complex substances such as coal which are not described by conventional components or pseudo compounds.

ASPEN is file-oriented. The objective is to allow the user as much restart capability as possible and to allow changes to the flowsheet so that the process engineer can synthesize optimum flowsheets efficiently.

Because of the requirement for portability, the ASPEN System is being written entirely in FORTRAN. A key innovation in the system is the implementation in FORTRAN of techniques to handle a linked-list data structure. This has allowed considerable flexibility in design.

Although the basic computational scheme for ASPEN is sequential-modular, the system is designed to allow extensions to new types of flowsheet convergence techniques such as the simultaneous modular algorithm.

A problem-oriented input language has been designed to make the system easy to use by process engineers. It is free-format, with either keyword or positional input and allows flexibility in the choice of engineering units. Defaults are provided where possible.

Conclusions and Significance-When ASPEN has been adequately tested, in 1981, it will be publicly released and the source code will be available. This will permit companies to modify and adapt ASPEN to meet their own special needs. Because ASPEN is intended to be a public system, the details of its models will be known and engineers will understand the inherent assumptions in a simulation. ASPEN is expected to extend the technology of process simulation to a much wider range of industries and plants than those now served by traditional vapor-liquid simulators.

INTRODUCTION

This paper presents an overview of ASPEN (Advanced System for Process ENgineering) which is a process simulator and economic evaluation system under development at the Massachusetts Institute of Tech- nology. The development is supported by the U.S. Department of Energy for use in engineering of fossil energy conversion processes.

Techniques for simulating industrial-scale chemical processes have evolved over the past twenty years and most of the large chemical, petroleum, and construc- tion companies have access to an in-house simulator or to a simulator provided by a commercial organiz- ation. Most of these simulators were developed for vapor-liquid processes in the petrochemical industry and are not suited for processes involving solids or complex substances such as coal which are not described by conventional components or psuedo compounds.

* Author to whom correspondence should be addressed. t W. D. Seider is with the Department of Chemical and

Biochemical Engineering, University of Pennsylvania, Philadelphia, PA 19174, U.S.A.

The concept of the ASPEN Project was to develop a next-generation process simulator that would extend the technology of process simulation to cover a much broader range of processes. The system has been designed to be very flexible so that it can be expanded to meet future simulation requirements. An attempt has been made to provide a good preliminary cost estimation capability to permit comparison of alter- native processes on an economically consistent basis at an early stage of development. ASPEN will be publicly available and many different process development teams will have access to the same simulator ; it will be easy to share models, and the details of programs and models will be known so that all of the assumptions in a model will be clear. Because ASPEN will be used at many different sites and installed on many different computers, particular emphasis has been placed on portability and ease of maintenance.

The goal of ASPEN has been to build upon present technology and to engage the cooperation of the entire profession. The full-time staff at M.I.T. has involved about 15 people over the past two years, many of them on-loan from industry to work on ASPEN. Funds were budgeted to acquire proven industrial software

319

320 L. B. EVANS et al.

rather than reprogram standard programs that exist. The FLOWTRAN program [l] was acquired and the models in FLOWTRAN are being incorpor- ated into ASPEN. An advisory committee with rep- resentatives from industry, government, and univer- sities has met regularly to review progress’ on the system and to help make certain that ASPEN will meet the needs of the ultimate users. Over fifty companies are represented on the advisory committee, including several from outside the United States and represent- ing diverse industries including fossil energy, pet- roleum, chemicals, construction, pulp and paper, metals, and food.

A complete description of ASPEN would take many pages and is available in other Refs. [24]. In this brief paper we would like to give the reader an understand- ing of the major features of the system and an appreciation for what is new about ASPEN.

COMPONENTS

Chemical components are the most fundamental entities in a process simulation. The compositions of raw materials, products, and intermediate streams are expressed in terms of the chemical components. It is the purpose of most industrial processes to change the relative amounts of the chemical components in transforming raw materials into products by means of chemical reaction, separation, mixing, etc.

In ASPEN there are’two types of components: conventional and non-conventional. Conventional components are pure compounds or pseudo com- pounds that may be characterized in terms of standard pure properties such as molecular weight, critical temperature, critical pressure, vapor pressure coef- ficients, and heat capacity coefficients. There are over 200 pure compound properties (or correlation para- meters) that can be specified for each component. The data bank is designed so that it is easy to define new pure compound properties or parameters and add them to the system. The complete set of constants is needed, however, only if the full set of physical property options is exercised. Boiling fractions may be represented as pseudo compounds and are treated aa conventional components. Correlations are available to determine the standard pure properties needed for boiling fractions of petroleum and of coal liquids.

Nonconventional components are not pure com- pounds or pseudo compounds and are characterized in terms of nonconventional ‘attributes’ rather than the standard pure compound properties. Examples in- clude coal, ash, char, slag, and inert solids. For example, coal might be characterized in terms of two attribute types, ultimate and proximate analyses. The ultimate analysis gives the weight per cent of carbon, hydrogen, nitrogen, sulfur, oxygen, chlorine, and ash. The proximate analysis give the moisture content and the percent volatile matter, fixed carbon, and ash. The attribute values comprise the ‘state variable’ infor- mation required to calculate physical properties of nonconventional components and their mixtures.

In addition to proximate and ultimate analyses, there will be a number of other built-in attribute types provided by the system, each consisting of one or more elements. In a particular simulation, the nonconven- tional components may be characterized by any combination of these attribute types. The particular combination for a given component depends on the

properties calculated for that component and the models used, and is specified by the user in a simple input statement. A component may have some at- tribute types that are unique to it, and other attribute types that are shared by other components. Values of the attributes are of course always unique to each component.

STREAMS

An ASPEN stream represents the flow of material and/or information from one process unit to the next. Streams are subdivided into one or more substreams, each containing a portion of the stream that is to be treated in a special manner. For example, in a process stream describing the flow of a vapor-liquid mixture containing an inert solid, the user might want to treat the inert solid differently from the rest of the stream. To do so, two substreams would be defined: one for the conventional mixture, and one for the inert solids.

There are three kinds of substreams: conventional substreams describing the flow of conventional com- ponents, nonconventional substreams describing the flow of nonconventional components, and infor- mation substreams involving no component flows. A conventional substream is described by process data and any number of optional attributes. The process data consists of: the molar flow of each conventional component in the simulation, the total molar flow, temperature, pressure, specific enthalpy, specific en- tropy, density, molar vapor fraction, molar liquid fraction, and molecular weight. Attributes are used to specify additional information about the substream, such as particle size distribution.

A nonconventional substream is described by the same kinds of data as a conventional substream, except that the process data gives the flow rate of each nonconventional component in the simulation and the total flow of the substream in mass units; there is no substream molecular weight. The use of mass units is necessary, since nonconventional components do not have molecular weights.

The values of the component attributes for each nonconventional component are carried with each substream in which the component occurs. These ‘state variables characterizing the component can be changed as the material is processed in a block. In contrast, the pure compound properties that charac- terize a conventional component are constant values and are invariant during processing of the compound.

An information substream contains only attributes and no process data. A common use of an information substream is to describe the flow of energy (heat or work) from one process unit to the next.

A stream or substream attribute is any set of data in addition to the process data required by the simulator. There may be many different types of attributes, each with its own set of required data. For example a particle size distribution is one type of attribute and it requires the number of discrete size increments, the upper and lower size limit of each increment, and the weight percent of material within each increment. Some of the data are fixed (the number of increments and the size ranges) and some are variable (the fraction within each increment). Only the variable information is carried with each substream.

ASPEN will contain a set of built-in attributes, such as particle size distribution and particle density distri-

ASPEN : an advanced system for process engineering 321

bution. The user can create new attributes as needed, but must also create new unit operation models that can operate on streams with the new attributes.

BLOCKS AND UNIT OPERATION MODELS

An ASPEN block refers to the process flowsheet element representing a process unit. Each block has one or more input streams and one or more output streams. An ASPEN model refers to the collection of subroutines used to model the unit operation and, in effect, defines the transformation that takes place in converting input streams into output streams.

The processing of information by a unit operation model is shown in Fig. 1. The primary function of a unit operation model during convergence of the heat and material balances is to calculate output stream variables given the input stream variables. The block data includes the engineering specifications for the unit (such as temperature and pressure for an isothermal

r-l BLOCK

DATA

user specifies a diagnostic level (either globally for the whole simulation or individually for each block) that controls the amount of information written onto the history Me.

COST ESTIMATION AND ECONOMIC EVALUATION

The final measure of merit of a given process flowsheet is the profitability of the business venture required for its implementation. The purpose of the ASPEN Cost Estimation and Economic Evaluation System is to calculate the profitability of the simulated process. This requires the calculation of the total required capital investment and the annual operating expenses.

The system is designed so that it can be used independently as a stand-alone system with all equip- ment sizes and process data supplied as input. Or, it can be run in conjunction with the unit operations

INTERNAL

RETENTION HISTORY

VARIABLES

Fig. 1. Flow of information to and from a unit operation model.

flash) and model control parameters (such as maxi- mum number of iterations, convergence tolerances, etc.). Default values are provided for all model control parameters but may be over-ridden by the user. Physical property options may be specified for each block and will designate the method to be used for calculating physical properties needed by the model. Internal retention variables include items such as intermediate tray temperatures and compositions for a rigorous distillation model; they are initialized during the first pass through the block and retained to speed convergence in subsequent calls

simulation portion of ASPEN and can refer to those blocks for equipment sizes and process data. The flow of information in sizing, costing, and economic evalu- ation is shown in Fig. 2.

Every block has a results flag that controls calcu- lation of results not needed for convergence of the flowsheet heat and material balance, but which maybe of interest in the final report of the simulation. They are calculated in a ‘results pass’ through the blocks after the heat and material balance has been converged. Each block also has an energy balance flag that, if turned off, omits calculation of outlet stream enthalpies, if optional. The flags can be used with simple models, such as mixers, splitters, etc. to give ASPEN a ‘mass balance only’ capability.

ASPEN is intended to provide cost estimates of the preliminary study grade with accuracies in the range of +/- 30%. An extensive effort is being made to collect current cost data for the first quarter of 1979. Particular attention has been paid to accurate rep- resentation of the effect of different plant locations (land costs, labor productivities, labor costs, construc- tion difficulties, etc.) and date of construction (esca- lation of the cost of construction material and labor, and installation material and labor etc.). Also great care has been given to the proper estimation of the cost of off-sites, since they represent a significant fraction of the cost of a new plant, particularly for large coal- conversion plants.

As with the rest of ASPEN, the cost estimation and economic evaluation system will be modular in design ; there will be one program module for each equipment class. It will be easy for users to add their own costing modules.

On each execution of a block, information may be A detailed discussion of the cost estimation meth- written onto a history file to provide a record of the odology or system structure is beyond the scope of this progress toward convergence of the simulation. The paper and will be treated in a future publication.

322 L. B. EVANS et al.

r I

4 EOUIPMENT

COSTING

ROUTINES

I

ECONOMIC EVALUATION SUBSYSTEM

* CAPITAL INVESTMENT * OPERATING EXPENSE

+ PROFITABILITY

Fig. 2. Figure of information for sizing and costing.

PHYSICAL PROPERTIES

ASPEN is supported by a comprehensive physical property system which is called upon by the unit operation models, equipment sizing models, and other routines, such as report writers, that require physical properties. Physical property monitors compute major properties such as enthalpy, entropy, free energy, molar volume, equilibrium ratio, fugacity coefficient, viscosity, thermal conductivity, diffusion coefficient, and thermal conductivity for specified phase conditions (vapor, liquid, or solid). The pro- perties may be computed for pure components, mix- tures, or components in a mixture as appropriate.

The call to a conventional property monitor is shown in Fig. 3. Information supplied to the monitor includes a set of codes to indicate which major properties are desired, a component index vector indicating which components (of all those involved in the simulation) are present in the mixture, the tem- perature, pressure, and composition of the mixture, and a pointer to an area of memory where appropriate information about the methods of calculation is stored. A monitor is called once with a request to calculate all of the properties of interest at a single set of conditions. This leads to computational efficiency, since intermediate results needed to calculate one property (say the enthalpy) may also be required to calculate others (say the density or fugacity coefficient) and redundant calculations can be avoided. The temperature derivatives of the major properties are also available from the monitors.

The pure compound properties and correlation parameters are loaded into labeled COMMONS, one property per COMMON and may be accessed directly by the physical property models. There is provision in ASPEN for multiple data banks to contain alternative sets of parameters for a given compound. It is also possible to load multiple sets of values into the labeled COMMONS and to call for use of a specific set of data

UNIT OPERATION -

TEMPERATURE OR SIZING MODEL

PRESSURE COMPOSITION

MAJOR PROPERTIES

CALCULATION CODES CONVENTIONAL

4 PROPERTY

PROPERTY OPTIONS MONITOR

A MAJOR 8 SUBORDINATE

PROPERTIES

CONVENTIONAL

PROPERTY MODELS

AND PARAMETERS

Fig. 3. Call to a conventional physical property monitor.

as part of the physical property option specifications. For most user needs, specification of the models to

be used for property calculations at any point in a process is simple and straightforward. By means of a statement in the input language, the user selects from among different routes (or methods) for computing each major property. In the ASPEN terminology a ‘major property route’ is the detailed specification of how to calculate one of the ten major properties for a given phase vapor, liquid, or solid of a pure component or mixture. For example in computing the enthalpy of a vapor mixture, the routes provided include one for each equation of state (e.g. Redlich-Kwong, Peng- Robinson, Modified BWR, etc.) and for the Yen- Alexander method.

The complete specification of all major property routes is referred to as the property option set. This set can be specified globally for the entire flowsheet or individually for each block. A collection of standard sets of options will be provided and one of these standard sets will be the default. The user may create a new option set by modifying a standard set. The user may also define new major property routes and may use them in option sets.

In summary, there are four levels of complexity and sophistication in specifying physical properties. In order of increasing complexity, they are :

(1) Use of the default option set throughout the flowsheet.

(2) Use of one or more standard option sets pro- vided by the system.

(3) Definition of one or more option sets, either com- pletely or by modifying standard ones, using standard major property routes provided by the system.

(4) Creation of a new major property route by specifying which physical property models are to be used for computing the subordinate properties for a major property.

ASPEN: an advanced system for process engineering 323

UNIT OPERATION

OR SIZING MODEL

TEMPERATURE

PRESSURE

NON- CONVENTIONAL

PROPERTY MONITOR

COMPONENT ATTRIBUTE VALUES

NON-CONVENTIONAL

i

PROPERTY MODEL

Fig. 4. Call to a nonconventional property monitor.

A Level 1 user is not required to provide any information about physical properties. While this is the ultimate in simplicity, it allows the user no flexibility. A Level 2 user must provide one or more option-set assignment statements ; input preparation is simpler than that of FLOWTRAN, while still providing greater flexibility. At Level 3, a user must define new option sets ; the complexity of user input is about the same as that of FLOWTRAN, but provides a great deal more flexibility than FLOWTRAN. Level 4 users should be knowledgeable in applied thermo- dynamics, and should be thoroughly familiar with the route construction capabilities of ASPEN. We antici- pate that the vast majority of ASPEN users will find the first three levels to be adequate.

Nonconventional physical property monitors are provided to calculate properties of nonconventional components and their mixtures. The call on such a monitor is shown in Fig. 4. Some of the nonconven- tional properties ofcoal and coal-related solids include the enthalpy, true density, ash fusibility, abrasion index, and grindability. Nonconventional properties of slurries include enthalpy, density, viscosity, thermal conductivity, and abrasion index.

FLOWSHEET CONVERGENCE AND CONTROL

ASPEN uses an advanced sequential modular? approach to flowsheet convergence. In this approach, individual unit operation models compute outlet streams and block results, given inlet streams and block parameters. Recycle streams are torn and the tear-stream variables are used as iteration variables. Design specifications are imposed by freeing certain block parameters or feed stream variables and adjust- ing their value to meet specifications on stream variables or block results.

The trend in process simulation research (Westerberg et al. [S]) has been toward newer compu-

t This terminology was suggested by Westerberg et al. [S].

tational strategies such as the simultaneous modular approach and the equation-solving approach. The simultaneous modular method utilizes simple linear models of unit operation blocks to generate a large system of linear equations. The linear equations are solved simultaneously for the stream variables. The nonlinear models are used to update the linear models. The method appears promising, but has not been tested on large problems.

In the equation-solving approach all the nonlinear equations describing the system are solved simul- taneously using a Newton-type method. The ad- vantage of the approach is speed of convergence near the solution and ease with which design specifications are included. The disadvantage is that good initial guesses are required and that the method has not been fully demonstrated on large-scale systems. This ap- proach would not be able to utilize the vast amount of existing software based on the sequential modular approach.

In our initial survey the Advisory Committee over- whelmingly recommended use of the sequential modu- lar approach, mainly because of its proven capa- bility. Therefore, the decision was made to use the sequential modular approach, but to design the system in such a way as to permit extension to a simultaneous modular architecture in the future.

The first step in structuring the computations for sequential modular solution, whether done manually or automatically, is to partition the flowsheet into maximal cyclic subsystems (parts of the flowsheet that are to be converged prior to any computation of down stream subsystems). Next a set of tear streams is selected to break the recycle loop; the choice is aimed at achieving the best convergence properties of the resulting algorithm. Loops are then nested by dividing iteration variables into subsets of variables to be converged simultaneously and specifying the order in which they are to be converged. Finally, the compu- tational sequence is determined.

In many process simulators, the user is responsible for all structuring of computations and specifies the computational sequence directly. In ASPEN the system is capable of complete automatic determi- nation of the computational sequence, but the user can impose as many constraints as desired (such as select- ing certain tear streams) and can, in fact, easily specify the entire sequence.

In ASPEN the convergence of recycle streams and the satisfaction of design specifications are treated the same. In the recycle problem the goal is to adjust the recycle stream variables to drive the difference between assumed and calculated recycle variables to zero. In the design problem, the goal is to adjust certain parameters to drive the difference between required and calculated values of design specification to zero. In ASPEN there is no distinction between convergence and control blocks, there are simply convergence blocks. ASPEN permits simultaneous convergence of heat and material balances and design specifications.

An ASPEN convergence block is not a ‘pseudo unit operation’ that breaks a recycle stream (Fig. Sa). Instead, the convergence system sits outside the flow- sheet, samples current values of the tear-stream vari- ables and determines new assumed values (Fig. 5b). A copy of the values of the tear-stream variables at the last iteration is kept in the retention area of a

324 L. B. EVANS et al.

Fig. 5(a). A convergence block that breaks a recycle stream and serves as a psuedo unit operation.

convergence block. Therefore, the flowsheet descrip- tion is independent of the numerical procedures used to carry out the calculations.

All convergence algorithm subroutines have the same argument list. Numerical procedures do not contain any information specific to the data structure describing the flowsheet. Therefore, the flowsheet description is independent of the numerical procedures used to carry out the calculations.

The user can access any flowsheet variable using ASPEN Input Language statements and carry out any transformation of these variables by entering program statements in FORTRAN or supplying user written FORTRAN subroutines. Variables related to sizing and costing can be accessed as well as those for heat and material balancing. The transformation is carried out in an information processing block which retrieves accessed variables, executes the FORTRAN, and replaces modified accessed variables. Accessed, vari- ables or transformations of them, may be used as design specifications to be driven to zero by the con- vergence blocks.

The ASPEN user can specify any independent set ot stream variables as the iteration variables. Process streams usually carry more variables than necessary to completely describe the thermodynamic state of the system and only an independent subset need be used for convergence. Also, the existence of stream attri- butes dictates the need for a user to be able to specify iteration variables. The default set for a conventional substream will be component flow rates, enthalpy, and pressure. Variables not contained in the iteration variable set such as temperature and vapor fraction may still be tested for convergence. The ASPEN data

iij 3;:

Fig. 5(b). An ASPEN convergence block that sits outside the flowsheet.

structure accommodates scaling for each iteration variable for algorithms that require all variables to be of the same order of magnitude.

INPUT LANGUAGE

The Input Language is oriented towards process engineers familiar with chemical engineering calcu- lations, but without extensive knowledge of computer programming. The input can be considered to be made up of paragraphs, sentences, and words. A paragraph begins with a primary keyword and may consist of one or more sentences. Each sentence begins with a secondary keyword that indicates the category of data appearing in the sentence. Tertiary keywords are used to enter data and their values are the data items.

For example, in the statement

BLOCK Fl FLASH-PT2 PARAM TEMP = 310 PRESS = 1 [ATM]

The word BLOCK is a primary keyword indicating that the paragraph contains block data. The user- specified block identifier is Fl and the unit operation model (FLASH-PT2) is a two-phase flash with specified temperature and pressure. PARAM is a secondary keyword indicating that the sentence contains block parameters. TEMP and PRES are tertiary keywords whose values are the temperature and pressure re- spectively. The value of a tertiary keyword may consist of a single data item or a vector of values.

The internal units for calculation are basic SI units, but the user may specify optional sets of input and output units which include English engineering, metric

? 56

f CONV ‘I, \BROYOEy \ -_/

Fig. 6. Flowsheet of process for manufacture of cumene.

ASPEN: an advanced system for process engineering 325

engineering, a set specific to the company or instal- lation, or SI units. The set of units may be specified separately for individual process units. In addition the user may specify individual units, such as temperature, that override the set. Finally, units may be specified for any individual data item (as in the specification of pressure in atmospheres above) and will override all other specifications.

The input is completely free format, except that primary keywords (and nothing else) must begin in column 1. The order of input language statements is immaterial, since the statements are sorted into a standard order before processing. Although every data item or vector of items has a tertiary keyword, the keyword may be omitted to allow positional input. Almost every entity in the simulation (blocks, streams, components, calculation sequences, etc.) are given user specified identifiers for reference elsewhere in the input and output. The default principle is fully exercised and where ever it is meaningful, default values are provided for items the user need not supply.

A Aowsheet for manufacture of cumene is shown in Fig. 6 and used as an example to illustrate the input language shown in Fig. 7. The statements should be relatively self explanatory.

INPUT

TITLE 'MANUFACTURE OF CUMENE"

DESCRIPTION uTHIS IS A SAMPLE PROBLEM TO SHOW THE MAIN

FEATURES OF THE ASPEN INPUT LANGUAGE.'

FLOWSHEET

MI IN:SI S7 OUT= S2 RI IN--S2 OUT = S3 HI IN=S3 OUT: 54 FI IN:S4 OUT = S5 S6 PI IN-S6 OUT: S7

HISTORY MSG-LEVELz6

RUN-OPTIONS MAX-TIME=30 MAX-ERR: 500

COMPONENTS Cl BENZENE/C2 PROPYLENE/C3 CUMENE

PROPERTIES STDOI

STREAM SI

TEMP = 220 [C] PRES-36

MOLE-FLOW Cl 4O/C2 4O/C3 0

STREAM S7

TEMP ~320 PRES-36

MOLE-FLOW Cl 62O/C2 4O/C3 0.2

BLOCK MI MIXER

PARAM PRES--0.5

BLOCK RI RFRAC

STOICH REACTION: I Cl I/C2 I/C3 -I

CONY REACTION : I C2 0.9

BLOCK HI HEATER

PARAM TEMP ~300 PRES= -0.1

BLOCK Fl FLASH2

PARAM TEMP: 310 PRES : I [ATM]

BLOCK PI PUMP

PARAM PRES: 36

TEAR -STREAMS S7

DES-SPEC PURITY

DEFINE COMP MOLE-FLOW STREAM-S5 COMPONENT:C3

SPEC COMP TO 39.8

VARY BLOCK-VAR BLOCK=FI VAR-TEMP

CONV Cl EROYDEN

STREAMS s7 SPECS PURITY

PARAM MAXIT--

Fig. 7. Statements in ASPEN input language for simulation of process to manufacture cumene.

USER,INPUT

COMPILED PROGRAMS

USER LIBRARIES

Fig. 8. Flow of information in ASPEN

SYSTEM ARCHJTECTURE

ASPEN has adopted a ‘preprocessor’ type of struc- ture in which the input translator generates a main calling program which is executed to perform the particular simulation. The flow of information in executing an ASPEN calculation is shown in Fig. 8.

The input translator processes the user input, enters all data regarding the process into a problem data file and writes the main calling program containing the necessary calls to models. Any FORTRAN statements supplied by the user are converted into FORTRAN subprograms. A physical property initialization sub- program, PPLOAD, which depends on the property models used in the simulation, is also written. These programs are then compiled, and linked together with object modules supplied from user program libraries and ASPEN libraries. The load module thus created is a tailor-made simulation program for the problem at hand. This program reads data from the problem data file and after performing necessary calculations, writes it back on the same or a new problem data file. The Report Writer can then reproduce reports from this file.

A skeleton version of the simulation program for a process to simulate a mixer and two flash units is shown in Fig. 9. The program INTSIM initializes the simulation run and PPLOAD loads in physical pro- perty constants for the run. The routine SEQMON is, in effect, the traffic director that controls execution of each of the models as needed for the simulation. The input translator generates the calculation sequence that SEQMON processes during execution of the simulation program. Note that although there are two flash units in the example, the simulation program requires only one call to FLASHJ. The ‘I’ routines are actually interface routines which call the actual model. The reason for this is discussed later.

This processor-type approach to the system has a

326 L. B. EVANS et al.

EXTERNAL FLASH,MIXER COMYONIPLEX I IPLEX (10001 CALL INTSIM CALL PPLOAD

100 CALL SEOMON (NG~,N~,LI,LZ,L~,....) GO IO llOl,lO2) , NGO

101 CALL FLASH1 (NB,lPLEX(Ll),lPLEXIL2),lPLEX (L3)...,FLASH..) GO TO 100

102 CALL MIX1 (NE, IPLEX (LI), IPLEX ILZI, IPLEX (L31.. ,MIXER..l GO TO 100 END

Fig. 9. Skeleton version ofsimulation program-usedasmain calling program in simulation phase.

number of advantages as opposed to a single, large, ready-to-execute program. First, the creation of a single, large program would have to include all unit operations, sizing and costing, and physical property modules in the system. All of these programs are not required in any one simulation. Thus, by generating a program especially tailored for a specific simulation, we can avoid the use of complex overlay structures and other memory-conserving techniques which will be required in the interpretive approach. Secondly, this structure allows us to easily incorporate user supplied FORTRAN statements and programs into the simu- lation phase. They may be compiled along with the main program generated by the Input Translator. Thirdly, the data arrays used in the simulation can be dimensioned to their proper length, thus avoiding the use of large, unwanted dimensions in the simulation.

The Input Translator is completely table driven. This means that all of the information needed to process input statements (such as names of keywords, default values of data items, etc.) are stored in tables in a file called the System Definition File. It is, therefore, easy to add keywords or change defaults by changing entries in the System Definition File. In addition to the Input Language tables, almost any ‘changeable’ in- formation related to Input Translation is stored in the System Definition File. This includes unit conversion tables, attribute descriptions, physical property option models and data structure, unit operation model data and stream requirements, etc. Thus it is easy to add a new attribute type, physical property option, unit operation model, etc. without changing any code in the Input Translator.

ASPEN utilizes a plex data structure of the type proposed in Evans et al. [6]. Information is stored in blocks of contiguous locations known as beads. Beads of any length are created dynamically from a pool of free storage which may be thought of as a lengthy FORTRAN array named PLEX. Beads may contain integer values, real values, or character strings. Since ASPEN is implemented in FORTRAN, the plex handling capability was built using a number of subroutines called the Data Management System. The only exception to the storage of data in the plex is for physical property constants and correlation para-

meters which are stored in labeled COMMONS, one for each property or set of parameters. This approach was used because the physical property models are the most frequently executed parts of the system, and the ‘read-only’ information required by them must be accessible as efficiently as possible. The approach is made feasible by the fact that only those labeled COMMONS containing properties or parameters required by a given model need be included in its subroutine.

The Problem Data File is also structured as a plex. Each bead in the file is located by a directory containing the location of all beads in the file. During a simulation, beads are read from the file into core and may be written out when no longer needed.

Beads are identified and stored by bead number. Programs can access the contents of a bead by using its bead number and Data Management System sub- routines to determine its location in the PLEX array. However, this is rather cumbersome and inconvenient for unit operation and other lower level routines. Hence, an attempt is made to ‘isolate’ the plex by using the subroutine call facility in FORTRAN. Thus, a bead in the plex array can be referenced as an object time dimensioned FORTRAN array in a unit operation model. The primary purpose of the model interface routines (e.g. FLASH1 and MIXI in Fig. 9) is to allow the actual models to reference data in arrays rather than beads within the routines.

The combination of the preprocessor architecture and the plex data structure, have resulted in the complete absence of any dimensional constraints on the system. That is, there are no maximum number of streams, components, blocks, stages in a column, etc. The plex isolation principle has allowed us to use the plex with its great flexibility in the executive routines, but to write lower-level routines (models) with mnemonically named, object-time dimensioned FORTRAN arrays.

In addition to the three load models involved in a process simulation run, ASPEN has three other sup- porting subsystems that exist as stand-alone pro- grams. The Data File Management System creates, maintains and updates data files containing physical property constants. The Data Regression subsystem process raw data to generate updated physical pro- perty data files. The Table Building System maintains and updates System Definition Files.

ASPEN is a file-oriented system. Files are used to store input translator tables, intermediate results, pro- grams and reports. As a result, it is possible to examine intermediate results, using an interactive terminal before printing them. Use of files to store intermediate results allows the system to be broken up into smaller subsystems, thus simplifying the system coding, debug- ging and maintenance. Finally, since intermediate results are stored, it is easy to restart a simulation in case of termination before completion. The file orien- tation makes it easy to modify the process being simulated and save considerable time in reruns and sensitivity runs.

Table 1 lists the various files created during a simulation. The user can save any of these files for future reference. The Problem Data File forms a convenient medium for storing intermediate results and saves considerable time for reruns when only a few process variables are changed. Provision is made to

ASPEN: an advanced system for process engineering 327

Table 1. Types of data files in ASPEN

Type of file

System definition file

Input data file Program file Load control file

Problem data file

Problem history file

Report file Property data files Cost and size data file

Contents

File containing Input Translator tables. The file has a plex data structure and each table is made up of a link-list of beads. The user’s input data. The FORTRAN programs generated by the Input Translator. A file generated by the Input Translator containing loader or linkage editor control statements. A copy of the data structure describing the process. This file contains all information about the processes. During EDITRUNs the file is used as the starting point for modifications. Space is allocated in the data structure to store the results of the simulation. File containing all intermediate messages produced by the system during a run. File containing all the reports produced by the system. File containing physical property constants for components. File containing constants for equipment sizing and costing.

update this file frequently with the current state of the The ASPEN system is expected to consist of about simulation so that all data is not lost due to an 150,000 lines of code. Because the funding and schedule abnormal termination such as a system error. for development of ASPEN were fixed by the contract

ASPEN has a small executive program written in with the Department of Energy, it was essential that the language of the operating system (e.g. Job Control ASPEN be delivered on time and within budget. Some Language for IBM computers). This executive controls of the most up-to-date methodologies of software the execution of various programs and the creation development have been used, including structured and selection of files used by the system. For a typical analysis and programming, strict standards of pro- simulation, this executive controls all the steps shown gramming and documentation, critical path schedul- in Fig. 8. ing, and a systematic plan for integration and testing

of the system. We believe that these techniques have SOFTWARE DESIGN FOR PORTABILITl AND given the ASPEN project a higher productivity and

MAINTAINABILITY will result in a more easily maintainable product. When ASPEN is completed it will be installed on

many different computers and maintained and modi- fied by many different organizations. This requires that the system be portable, highly reliable, and easy to maintain.

I.

Early in the project a survey was made of the ASPEN advisory committee to get their recommend- 2. ations concerning the language in which the executive system and the models should be written. An over- whelming majority preferred the use of FORTRAN as the programming language for both the executive 3. system and the model. The reason for their preference was availability of FORTRAN as a maintained and 4. widely used language in their company, familiarity with FORTRAN, and the availability of trained

5,

personnel to maintain programs in FORTRAN in their companies. Therefore, the decision was made to 6. program the entire system in FORTRAN.

REFERENCES

J. D. Seader, W. D. Seider & A. C. Pauls, FLOWTRAN Simulation-An Introduction. 2nd Edn, The CACHE Corporation (1977). Project on Computer-Aided Industrial Process Design (U.S. Department of Energy Contract No. E(49-18b2295, Task Order No. 9) 2nd Ann. Rep., June, 1978 (Report MIT-2295T9-9). Ibid, 9th Quart. Progress Rep., September, 1978 (Report MIT-2295T9-10). Ibid, 10th Quart. Progress Rep., December (1978)(Report MIT-2295T9-11). A. W. Westerberg, P. Hutchison, R. L. Motard & P. Winter, Process Flowsheeting. Cambridge University Press, Cambridge (1979). L. B. Evans, B. Joseph SK W. D. Seider, System structures for process simulation. AIChE J. 23(S), 658466 (1977).

CACE 3: 1-4 - ”