Concepts and implementation of Collaborative Modeling in MOSAIC · 2017-10-26 · Concepts and...

Concepts and implementation of

Collaborative Modeling in MOSAIC

vorgelegt von

Dipl.-Ing.

Robert Kraus

geb. in Frankfurt an der Oder

von der Fakultat III - Prozesswissenschaften

der Technischen Universitat Berlin

zur Erlangung des akademischen Grades

Doktor der Ingenieurwissenschaften

- Dr.-Ing.-

genehmigte Dissertation

Promotionsausschuss:

Vorsitzender: Prof. Dr.-Ing. Matthias Kraume

Gutachter: Prof. Dr.-Ing. Gunter Wozny

Gutachter: Prof. Ph.D. Rafael Batres Prieto

Gutachter: Prof. Ph.D. Flavio Manenti

Tag der wissenschaftlichen Aussprache: 29. Mai 2015

Berlin 2015

Zusammenfassung

Zu den zentralen Arbeitsgebieten in der chemischen Prozesstechnik gehort

die Entwicklung neuer und Verbesserung existierender Prozesskonzepte. Ma-

thematische Modelle werden fur die verschiedenen physikalischen und che-

mischen Vorgange formuliert und in Simulationen verwendet, welche wie-

derum als Basis fur Optimierungen dienen. Anlagen- ebenso wie Labor-

daten, konnen der Validierung der berechneten Ergebnisse und zudem als

Ausgangspunkt fur neue Entwicklungen dienen. Aufgrund der wachsenden

Komplexitat konnen diese Projekte nur gemeinschaftlich in Kooperation von

interdisziplinaren Fachexperten bearbeitet werden.

Im Rahmen dieser Arbeit werden neue Konzepte eingefuhrt und prasen-

tiert, die Losungsansatze fur diese Herausforderung der gemeinschaftlichen

Prozessentwicklung bieten. Daruber hinaus wird eine Datenbankstruktur

fur die integrierte Verwaltung von Modell- und Messdaten entwickelt.

Die strikte Typisierung und Limitierung auf bestimmte Anwendungs-

bereiche von Prozessmodellen wird durch die Einfuhrung von Modularitats-

konzepten gelockert. Die Verschiebung mehrerer Modellspezifizierungen, wie

z.B. die Auswahl der Zielfunktion, vor die Code-Generierung fur die Zielpro-

grammiersprache ermoglicht Anwendern eine großere Flexibilitat hinsicht-

lich der verwendeten Modellierungs- und Optimierungssoftware. Modelle

konnen in Simulations- und Optimierungssoftware verwendet werden und

die Definitionen von Umwandlungen fur eine automatisierte Diskretisierung

von ODE/DAE Systemen konnen erstellt werden. Dies wird erreicht ohne

dabei das Ursprungsmodell zu andern, welches dementsprechend in seinem

gut dokumentierten Originalzustand erhalten bleibt. Eine Strukturanalyse

I

II

ermoglicht die Zerlegung von Gleichungssystemen und die automatisierte

Generierung von Losungsalgorithmen.

Zur vielfaltigen Demonstration der Machbarkeit wurden die Konzepte in

die Online-Modellierungsumgebung MOSAIC implementiert.

Abstract

In process engineering a lot of resources are invested to improve existing

and to develop new process concepts. Process unit models are derived and

applied in simulations, which are the basis for further optimization work.

Process data from the actual production plant, or the laboratory, can be

used for the validation of the calculated results and as starting point for

new developments. Due to the complexity, the work on large projects can

only be realized in interdisciplinary collaboration with a team of specialists.

In the scope of this work concepts are introduced and presented to

meet the challenging demands for the collaborative process development.

A database structure is generated for the integrated management of model

and measurement data.

The strict classification and area of application of process models is re-

laxed by the introduction of modularity approaches. A tool independence

is achieved by moving several model specification features prior to the code

generation of the target programming language. Models can be applied

in simulation and optimization software and the specification of transfor-

mations for an automated discretization of ODE/DAE systems can be de-

fined. This is achieved without altering the original equation system, which

is thereby preserved in its original and well documented state. A structure

analysis functionality offers decomposition concepts of equation systems and

the automated development of solution routines.

As a proof of concept, all the approaches are implemented in the online

modeling environment MOSAIC.

III

Contents

Zusammenfassung I

Abstract III

1 Introduction 1

2 Integrated collaboration via databases 5

2.1 Requirements for a collaborative modeling environment . . . 6

2.2 System architecture . . . . . . . . . . . . . . . . . . . . . . . 11

2.2.1 Infrastructure . . . . . . . . . . . . . . . . . . . . . . . 11

2.2.2 Model database . . . . . . . . . . . . . . . . . . . . . . 14

2.2.2.1 Model data management . . . . . . . . . . . 14

2.2.2.2 User management . . . . . . . . . . . . . . . 17

2.2.3 Measurement information database . . . . . . . . . . . 19

2.2.3.1 Equipment and process data . . . . . . . . . 20

2.2.3.2 Connection of measurement and modeling data 23

2.3 Case studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.3.1 MOSAIC and database usage . . . . . . . . . . . . . . 25

2.3.2 Development history of a model . . . . . . . . . . . . 31

2.3.3 Modeling and measurement case study . . . . . . . . . 37

3 Advanced modularity concepts 41

3.1 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.1.1 Optimization . . . . . . . . . . . . . . . . . . . . . . . 42

3.1.2 Discretization . . . . . . . . . . . . . . . . . . . . . . . 43

V

VI CONTENTS

3.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.2.1 Optimization . . . . . . . . . . . . . . . . . . . . . . . 46

3.2.1.1 Integration into MOSAIC . . . . . . . . . . . 46

3.2.1.2 Proposed optimization approach . . . . . . . 48

3.2.2 Discretization . . . . . . . . . . . . . . . . . . . . . . . 49

3.2.2.1 Resulting structure . . . . . . . . . . . . . . 50

3.2.2.2 Discretization procedure . . . . . . . . . . . 54

3.3 Application examples . . . . . . . . . . . . . . . . . . . . . . . 55

3.3.1 Optimization in MOSAIC . . . . . . . . . . . . . . . . 55

3.3.1.1 Calculation of chemical equilibrium . . . . . 55

3.3.1.2 Optimal control of a batch reactor . . . . . . 60

3.3.2 Discretization . . . . . . . . . . . . . . . . . . . . . . . 67

3.3.2.1 Example of discretization methods in MOSAIC 68

3.3.2.2 Application on a semi-continuous bioreactor 70

3.3.2.3 Introduction of a step size control mechanism 77

4 Assistance and decomposition concepts 83

4.1 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

4.1.1 Dulmage-Mendelssohn Decomposition . . . . . . . . . 85

4.1.2 Bordered block decomposition . . . . . . . . . . . . . 86

4.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 88

4.3 Application example . . . . . . . . . . . . . . . . . . . . . . . 89

4.3.1 User assistance . . . . . . . . . . . . . . . . . . . . . . 89

4.3.1.1 Interactive model structure . . . . . . . . . . 89

4.3.1.2 Identification of key variables . . . . . . . . . 90

4.3.2 Identification of solution algorithms . . . . . . . . . . 95

5 Conclusion 101

6 Appendix 103

6.1 Notations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

6.1.1 28986: chemical equilibrium.mosnot . . . . . . . . . . 103

6.1.2 32005: discretization.mosnot . . . . . . . . . . . . . . 104

6.1.3 2323: Asprey.mosnot . . . . . . . . . . . . . . . . . . . 104

CONTENTS VII

6.1.4 10260: Biegler control.mosnot . . . . . . . . . . . . . . 105

6.1.5 2951: Public notation.mosnot . . . . . . . . . . . . . . 106

6.1.6 8957: pcsaft notation.mosnot . . . . . . . . . . . . . . 114

6.2 Equation system . . . . . . . . . . . . . . . . . . . . . . . . . 117

6.2.1 28994: chemical equilibrium.moseqs . . . . . . . . . . 117

6.2.2 32089: Full column model with Wilson Model.moseqs 118

6.2.3 12522: Tray Dippr.moseqs . . . . . . . . . . . . . . . . 119

6.2.4 12527: Tray plain.moseqs . . . . . . . . . . . . . . . . 120

6.2.5 32087: Condenser Dippr Full with Wilson Model.moseqs122

6.2.6 12517: Condenser Basic.moseqs . . . . . . . . . . . . . 123

6.2.7 32088: Reboiler Dippr Full with Wilson Model.moseqs 125

6.2.8 12599: Reboiler plain.moseqs . . . . . . . . . . . . . . 126

6.2.9 33506: Corrected PC SAFT.moseqs . . . . . . . . . . 128

6.3 Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

6.3.1 12504: Enthalpy DIPPR100.mosfun . . . . . . . . . . 138

6.3.2 12505: DIPPR101.mosfun . . . . . . . . . . . . . . . . 138

6.3.3 12593: DIPPR106 - Evaporation molar.mosfun . . . . 138

6.3.4 32032: gamma1.mosfun . . . . . . . . . . . . . . . . . 139

6.3.5 32058: gamma2.mosfun . . . . . . . . . . . . . . . . . 139

6.3.6 32084: wilsonparameter1.mosfun . . . . . . . . . . . . 139

6.3.7 32085: wilsonparameter2.mosfun . . . . . . . . . . . . 140

6.3.8 32086: DIPPR105-mod.-molar spec. volume.mosfun . 140

6.4 Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

6.4.1 12607: Condenser.moscon . . . . . . . . . . . . . . . . 140

6.4.2 12609: Reboiler.moscon . . . . . . . . . . . . . . . . . 141

6.5 Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . 142

6.6 Variable lists . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

6.7 Additional screenshots . . . . . . . . . . . . . . . . . . . . . . 146

6.7.1 Calculation of the chemical equilibrium . . . . . . . . 146

6.7.2 Optimal control of a batch reactor . . . . . . . . . . . 152

6.7.3 Transformation editor . . . . . . . . . . . . . . . . . . 154

6.7.4 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . 157

VIII CONTENTS

7 List of literature 159

7.1 Own publications . . . . . . . . . . . . . . . . . . . . . . . . . 159

7.2 Supervised theses . . . . . . . . . . . . . . . . . . . . . . . . . 162

7.3 Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

List of Figures

2.1 Data sources and sinks in process engineering . . . . . . . . . 6

2.2 Data exchange with different local copies and inconsistent

versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Integrated modeling and measurement database . . . . . . . . 8

2.4 Standard exchange with separated documentation . . . . . . 9

2.5 Integrated platform with one documentation . . . . . . . . . 10

2.6 Possible database configurations . . . . . . . . . . . . . . . . 12

2.7 Map of MOSAIC server locations, as of May 2014 . . . . . . . 13

2.8 Structure of the model database . . . . . . . . . . . . . . . . 15

2.9 File selection dialog of the model database . . . . . . . . . . . 16

2.10 Access rights for user and groups . . . . . . . . . . . . . . . . 18

2.11 Structure of the measurement data database . . . . . . . . . . 20

2.12 Structure of the connection of measurement model data . . . 24

2.13 Number of registered user . . . . . . . . . . . . . . . . . . . . 25

2.14 Number of active users per month, working on the main server

in Berlin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.15 Database queries for 30 days . . . . . . . . . . . . . . . . . . 27

2.16 Map of access locations to MOSAIC . . . . . . . . . . . . . . 28

2.17 Used code specificators: NLE (May 2014) . . . . . . . . . . . 29

2.18 Used code specificators: ode (May 2014) . . . . . . . . . . . . 29

2.19 Used code specificators: DAE (May 2014) . . . . . . . . . . . 30

2.20 Piping and instrumentation diagram of the column (Barz, 2008) 36

2.21 Panel for matching variables with measurements . . . . . . . 38

IX

X LIST OF FIGURES

3.1 General procedure for simulation and optimization in process

simulation, with different model versions . . . . . . . . . . . . 42

3.2 Proposed approach in which the same model is utilized for

simulation and optimization software . . . . . . . . . . . . . . 43

3.3 Processing of differential equations in process simulation, dis-

cretized model as additional implementation . . . . . . . . . . 44

3.4 Processing of differential equations in process simulation, dis-

cretized model based on original implementation . . . . . . . 45

3.5 MOSAIC-based optimization approach . . . . . . . . . . . . . 49

3.6 Elements of an applied transformation . . . . . . . . . . . . . 51

3.7 Orthogonal collocation on finite elements, implemented as

equation system in MOSAIC . . . . . . . . . . . . . . . . . . 52

3.8 Workflow for the discretization of an equation system . . . . 54

3.9 Equilibrium reactor . . . . . . . . . . . . . . . . . . . . . . . . 55

3.10 Specification of the optimization statement in MOSAIC -

Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.11 Batch reactor temperature control (Biegler, 2011) . . . . . . . 61

3.12 Initial solution with a constant temperature of T = 400K . . 62

3.13 Maximized product with optimized temperature profile and

constant time step intervals . . . . . . . . . . . . . . . . . . . 66

3.14 Minimized batch time with optimized temperature profile and

variable time step intervals . . . . . . . . . . . . . . . . . . . 67

3.15 Semi-continuous fermenter (Asprey and Macchietto, 2002) . . 71

3.16 Final model after transformation with the impl. Euler method 73

3.17 Final model with orth. coll. on finite elements . . . . . . . . 74

3.18 Result of the different discretization methods . . . . . . . . . 76

3.19 Bioreactor, final model with step size control . . . . . . . . . 79

3.20 Simulation results with a variable step size . . . . . . . . . . . 82

4.1 Limited access of user to model structure knowledge . . . . . 83

4.2 Analysis and derived decomposition algorithm, accessible by

the user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

4.3 Result of a Dulmage Mendelssohn Decomposition . . . . . . . 85

LIST OF FIGURES XI

4.4 Result of a bordered block decomposition . . . . . . . . . . . 86

4.5 Decompositon of the equation system in an inner and outer

loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

4.6 System information exchange via a central data storage . . . 88

4.7 Incidence matrix of the equation system 32089: Full col-

umn model with Wilson Model.moseqs . . . . . . . . . . . . 92

4.8 Incidence matrix of equation system after Dulmage–Mendelsohn

decomposition was applied . . . . . . . . . . . . . . . . . . . . 93

4.9 Incidence matrix of equation system after Dulmage-Mendelsohn

decomposition was applied . . . . . . . . . . . . . . . . . . . . 94

4.10 Algorithm for solution of PC-Saft . . . . . . . . . . . . . . . . 95

4.11 Incidence matrix of PC-Saft, bordered-block-decomposition,

temperature and pressure as function of the phase composi-

tion, border variables: ρk=2, ρk=1, T . . . . . . . . . . . . . . 98

4.12 Incidence matrix of PC-Saft, bordered-block-decomposition,

phase composition as function of pressure and temperature,

border variables: ηk=1, ηk=2, ρk=1, ρk=2,mmk=1,mmk=2 . . . 99

4.13 PC-Saft results, x(T,P) and y(T,P) calculated with inner and

outer iteration cycle . . . . . . . . . . . . . . . . . . . . . . . 100

6.1 Specification of the optimization statement in MOSAIC -

Constrains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

6.2 Optimization code generation for Matlab using fmincon . . . 147

6.3 NEOS submission panel - connect . . . . . . . . . . . . . . . . 148

6.4 NEOS submission panel - select optimizer and submit . . . . 149

6.5 NEOS submission panel - read results . . . . . . . . . . . . . 150

6.6 Optimization results, imported into MOSAIC . . . . . . . . . 151

6.7 Variable specification for the maximization of the product

concentration . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

6.8 Variable specification for the minimization of the batch time . 153

6.9 Transformation editor - Step 1, Discretization equation sys-

tem and super notation . . . . . . . . . . . . . . . . . . . . . 154

XII LIST OF FIGURES

6.10 Transformation editor - Step 2, Matching of independent vari-

ables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

6.11 Transformation editor - Step 3, Matching of indices . . . . . . 156

6.12 Transformation editor - Step 4, Listing of time depending

algebraic variables . . . . . . . . . . . . . . . . . . . . . . . . 157

6.13 Search panel of the model database . . . . . . . . . . . . . . . 157

List of Tables

1.1 Use of databases in process modeling (- not available) . . . . 3

3.1 Gibbs parameter for the different species (T=3500K) . . . . . 56

3.2 Solutions of different optimizer . . . . . . . . . . . . . . . . . 60

6.23 32050: Asprey, implicit euler method.mostra . . . . . . . . . . 142

6.24 32027: Asprey, orthogonal collocation.mostra . . . . . . . . . 142

6.25 32822: Asprey, orthogonal coll. with step size error.mostra . . 143

6.26 2334: Inital estimates.mosvar . . . . . . . . . . . . . . . . . . 144

6.27 Design variables from 10316: initial solution.mosvar

and index informations . . . . . . . . . . . . . . . . . . . . . . 145

XIII

XIV LIST OF TABLES

Nomenclature

Block . . . . . . . . . . . . In this work, a block is a set of equations and variables

which can be solved together

Connector . . . . . . . MOSAIC specific element, used for the connection of

modeling elements with different notations

DAE . . . . . . . . . . . . . Differential Algebraic Equation

Database . . . . . . . . A data management and storage system

Key variable . . . . . A variable with a high importance for the solution of an

equation system. Similar to tearing variables

Model . . . . . . . . . . . An equation set, describing the physical phenomena of

a process unit

Modeling element MOSAIC specific element, an equation, function, or equa-

tion system which can be part of a model

MOSAIC . . . . . . . . Modular model specification on documentation level

NLE . . . . . . . . . . . . . Nonlinear Equation

ODE . . . . . . . . . . . . Ordinary Differential Equation

Package . . . . . . . . . . Similar to a folder on a personal computer system, data-

base entries are assigned to a package

PDE . . . . . . . . . . . . . Partial Differential Equation

Process . . . . . . . . . . As defined in DIN IEC 60050-351: “Set of interacting

procedures in a system where matter, energy or infor-

mation is being formed, transported or stored”

Simulation . . . . . . . A set of models, connected to a process model, including

all necessary parameter for a solution

SQL . . . . . . . . . . . . . Structured Query Language - a special purpose language

XV

XVI LIST OF TABLES

to interact with databases

Tearing . . . . . . . . . . Disconnection of variables and equations by introduc-

tion of additional iteration variables and loops

Timestamp . . . . . . The time at which an entry is added to the database

Transformation . . MOSAIC specific element, containing the information,

necessary to transform a differential to an algebraic ex-

pression

Chapter 1

Introduction

In rigorous process modeling and optimization, only a smaller part of the

effort and work is dedicated to the actual mathematical description of the

physical system. A bigger part of the resources is used for technical configu-

ration of the software environment and the implementation of the equation

system. Equation systems and measurement values have to be stored, in-

tegrated into existing models, implemented in other systems, debugged and

constantly documented.

Three challenges are addressed in this work. The management of model

and measurement data in a collaborative database. A modularity concept

for a better interchangeability between simulation and optimization tools

as well as the discretization of differential equation systems. Finally, an

assistance concept for the structural analyzation and decomposition of the

final equation system is presented.

In process modeling, several software platforms exist, which can be used

to describe and solve different types of problems. Different categories with

two popular representatives and their collaboration capabilites are listed in

Table 1.1.

Despite different origins and fields of application, all tools have certain

characteristics in common, highlighting the need of the methods, presented

in this work. Internet is only used to publish the resulting source code

with embedded comments. Model and measurement data are managed by

1

2 CHAPTER 1. INTRODUCTION

the user on his local file system, in most cases without much support. If

the software tool is a specialized application, it is either on simulation, or

optimization and the capabilities of the neglected domain are if at all limited.

Software, where the model structure is analyzed, or decomposition methods

are available, the results are hidden to the user (e.g. gPROMS1) in the

solver output. Where available, this information is difficult to interpret and

to utilize.

In the early days of process simulation, general purpose programming

languages as C++ and Fortran where used to create complex and user spe-

cific modeling routines. Though highly flexible, for most users, the usage of

programming languages as low level modeling languages is too time consum-

ing and not user-friendly. In addition, a high level of programming skills is

needed (Tolsma, 1999). Interfaces exist for other platforms and with a cer-

tain effort, single subroutines can be reused. The documentation is based

on comments in the source code, which have to be updated manually by

the modeler and can be transfered to a documentation file with third party

software such as DoxyGen2. Since programming languages are not espe-

cially designed for process modeling, useful and complex features such as a

modeling management are not supported.

Driven by the need of providing better support for the model develop-

ment and management, several software tools have been developed. Among

these a distinction can be made between programs for mathematical mod-

eling, plain modular flowsheet modeling, and a combination of both.

Mathematical modeling environments are especially suited to solve user

defined equation systems. Popular representatives are Matlab3 and Math-

ematica4. The user has all possibilities to influence the model but with an

increasing demand for higher complexity of process models. As a result, this

modeling procedure becomes a time-consuming and error-prone task (Jensen

and Gani, 1996). In both cases, the model and data management have to

1Process Systems Enterprise Ltd., www.psenterprise.com2http://www.stack.nl/ dimitri/doxygen/index.html3MathWorks c©, www.mathworks.com4Wolfram c© Research Europe Ltd., www.wolfram.com

3

Table 1.1: Use of databases in process modeling (- not available)

Model

datab

ase

Measurementdatabase

Exchange

Interoperability

Documentation

ProgrammingC++ - - - good source

Fortran - - - good source

MathematicalMatlab R© - - forum / SQL limited source

Mathematica - - SQL limited CDF

FlowsheetingChemcad local - - CAPE-OPEN report

aspentech local connection restricted CAPE-OPEN report

Advanced gPROMS local - - CAPE-OPEN report

flowsheeting Modelica R© libraries - - limited report

OptimizationGAMS - - - limited source

AMPL R© - - - limited source

be organized individually by the user.

For Matlab, the exchange of plain model files is supported by means of

a public Internet forum. Thereby, the user has the possibility to publish his

or her source code. A documentation generator is available, which is based

on the source code and embedded comments.

Mathematica is able to connect the model with the documentation en-

coded in the Computable Document Format. The feature of dynamic Web

deployment allows the user to publish the model as an interactive website.

Matlab and Mathematica have interfaces for SQL-Databases, thus a model

and measurement database as proposed in this work can be connected.

Examples for modular flowsheet simulation programs are Aspen Plus5

and Chemcad6. These type of tools offer the possibility of building complete

process flowsheets by connecting pre-built models from an unit operation

library, and provide not only tailored solution algorithms for the single units

but also reliable flowsheet convergence strategies, which are convenient for

5AspenTech., www.aspentech.com6Chemstations Inc., www.chemstations.com

4 CHAPTER 1. INTRODUCTION

solving process flowsheets consisting of standard units. However there is a

significant disadvantage of this type of programs. If a model of a specific

unit operation is missing in the pre-built library, it is difficult for the user to

extend the library. In most cases, the step backwards to classic programming

languages like Fortran has to be taken and in addition the user has only a

limited influence on the numeric algorithms.

Programs like gPROMS or Modelica7 combine the advantages of flow-

sheeting and user defined units (Fritzon, 2000). A built-in library of models

can be used in a flow sheet environment and new units can be created by

assembling the model equations in the corresponding program syntax. How-

ever, the ability of formulating user-defined models relies on general numeri-

cal solution procedures, which are not as robust as problem tailored solution

algorithms.

GAMS8 and AMPL9 are advanced optimization tools. Both are similar

and offer access to state of the art optimization algorithms. Model libraries,

exchange methods, or special documentation features are not supported as

the focus is on optimization.

As proof of concept, the methods presented in this work are implemented

in the Web-based modeling environment MOSAIC. Detailed information of

the existing modeling functionality can be found in Zerry (2008); Kuntsche

(2013).

7Modelica Association, www.modelica.org8GAMS Development Corporation, www.gams.com9AMPL Optimization LLC, www.ampl.com

Chapter 2

Integrated collaboration via

databases

The need for a central data storage concept and a way to trace and docu-

ment different development steps and utilization of information is empha-

sized in Figure 2.1. For this illustration, three different data clusters are

used. Parameter data, e.g. equipment parameter or time constants for con-

trol; simulation data, which can be both, model equations and simulation

results; process data which is based on real world measurements. During

the steps of process design and development, data is generated and used

in different connections. For example, process data from the experimental

plant (source) can be used in optimization (sink) for parameter estimation

(source). In this chapter, concepts for collaborative database storage and a

lasting documentation of the data linkage and usage are presented.

5

6 CHAPTER 2. INTEGRATED COLLABORATION VIA DATABASES

Figure 2.1: Data sources and sinks in process engineering

2.1 Requirements for a collaborative modeling en-

vironment

In a globalized working environment, where the organization of collabora-

tion teams changes dynamically, new software tools are needed to manage

and preserve the model-related knowledge. Two statements in a survey of

Cameron and Ingram (2008), are of particular interest. Namely, facilitating

the integration of predefined models and custom models; and exchange of

models and reuse of previous work.

Facilitating the integration of predefined models and custom models.

The possibility to integrate a user defined model into popular modeling envi-

ronments extends its application range and applications. This is increasingly

important for areas such as multiscale modeling, since these composite mod-

els consist of a wide range of sub-model types (Jaworski and Zakrzewska,

2011).

Simulation programs and techniques are constantly refined and new

methods are evolved. If the model code in the model library is written

in the syntax of some simulation environment it risks becoming useless over

time and the results may differ significantly when the model is used in con-

2.1. REQUIREMENTS FOR A COLLABORATIVEMODELING ENVIRONMENT7

junction with new modeling tools. In extreme cases where the old file format

is no longer supported, the model can become unusable (Foss et al., 1998;

Eggersmann et al., 2004). This problem can be avoided with a simulation

environment in which models are stored independently of the implementa-

tion.

In addition, there are situations in which activities associated with a sim-

ulation may need to be carried out across different modeling and simulation

tools, requiring the transformation of models due to proprietary formats.

As a result, repetitive modeling is a common practice in chemical process

research and development (Schopfer et al., 2000; Lam et al., 2007; Cameron

and Ingram, 2008).

Modeling in the documentation level, as proposed by Kuntsche (2013)

and realized with MOSAIC1 addresses the problem of multi-tool modeling

and a consistent modeling documentation. Program codes for different soft-

ware environments and the documentation file are created, based on the

same source. This solves the problem of exchanging models between differ-

ent software platforms.

Exchange of models and reuse of previous work.

In the life cycle of chemical process design, the sharing and exchange of

existing models is difficult because of insufficient documentation associated

with the different versions of the models. Classic exchange in collaboration

groups, is mainly done via conventional portable memory devices and email

communication, see Figure 2.2. According to Foss et al. (1998) it is already

common for single user and groups to build up personal model libraries. Very

often the build-up, maintenance and documentation are doomed to failure,

due to a lack of time and the missing of appropriate programs. More likely,

only parts of existing models are reused in later projects, which are rarely

exchanged between members of one and the same working group in an oper-

ating company. There are different development lines of the model, because

the model exists in more than one version in more than one location.

A more advanced approach is the use of network storage. Figure 2.3

1www.mosaic-modeling.de

8 CHAPTER 2. INTEGRATED COLLABORATION VIA DATABASES

Figure 2.2: Data exchange with different local copies and inconsistent ver-sions

Figure 2.3: Integrated modeling and measurement database

Different approaches exist for different purposes. For a small workgroup

with a limited number of users and the same software infrastructure, a shared

network folder could be sufficient. All the data is stored in one place and can

be accessed by all participants. However, a huge effort is needed to preserve

order and a documented structure.

Previous types of network storage were not designed for use in the area

of process engineering. There are software tools for version control imple-

2.1. REQUIREMENTS FOR A COLLABORATIVEMODELING ENVIRONMENT9

Modeling

Experiments

Documentation A

Parameter estimationModel validation

Design of experimentsDocumentation B

Documentation C

Figure 2.4: Standard exchange with separated documentation

mentation. Two known tools are CVS2 and SVN3. The origin of these tools

is the area of informatics, where these tools are used for collaborative work

on a common software project. Support for the use of different modeling

tools and the connection with measurement data is crucial so as, to cover

the different aspects of process modeling and optimization. Access rights

have to be fully manageable by the user, in order to provide full control over

the individual work. Most importantly, existing modeling environments lack

consistent documentation, which is crucial for sustainable work and should

include details regarding the different elements and their history.

The reuse and exchange of both, model and measurement data, is a

challenge in process engineering. Especially for long term projects, the doc-

umentation of the development steps poses a challenge. Figure 2.4 illustrates

the main information flow between model and measurement data sets. Sim-

ulation results are used to design experiments and in turn, experimental

data can be used to validate the model and to estimate model parameters.

For each task, special tools were developed but the data exchange is

done manually and the user is responsible for the consistency of both, the

implementation and documentation. After the parameter estimation, the

model documentation is not to be found in the used raw data and this

2Concurrent Versions System, www.nongnu.org/cvs/3Apache Subversion, subversion.apache.org

10CHAPTER 2. INTEGRATED COLLABORATION VIA DATABASES

Modeling Experiment

Documentation

Export

Code for:Matlab, gPROMS,Aspen, GAMS, ...

Exchange via:xml, csv

Parameter estimationModel validation

Design of experiments

Combination of model development and experiments

Figure 2.5: Integrated platform with one documentation

useful piece of information is lost permanently for other users, who may

desire to reuse the model and parameter information. This problem can

be solved with an integrated platform, based on MOSAIC and its model

documentation facilities.

A database for the model and measurement data is developed that ad-

dresses both requirements. In this thesis, such an integrated platform is pro-

posed in which the Web-based modeling environment MOSAIC is extended

with documentation capabilities. Users get full control over their data and

can share and access other data as needed. A full version management sys-

tem is included for model reuse. The measurement database is more than a

list of plain values. It is designed to keep track of the plant history. By doing

so, users have a better possibility to understand the measurement data and

their validity. Variables from the model can be permanently connected to

the corresponding measurement point in the plant.

Figure 2.5 illustrates the information flow of the integrated environment.

Measurement data and model data are connected and can be used for opti-

mization or design of experiments. The highlight is the integrated documen-

tation. In addition to the standard model description it is possible to include

2.2. SYSTEM ARCHITECTURE 11

the full model development history, based on the version control data. When

the model is connected to measurement data, the list of matched variable

and measurement points, the plant information and the raw data are also

taken into account. The resulting documentation thus contains the full his-

tory of both, model and measurements, which is needed to understand not

only the function of a model, but also the origin of the calculated variables

and parameter.

2.2 System architecture

Different relational databases (Codd, 1970) were introduced and implemen-

ted in MOSAIC in order to introduce a multi-user access, as well as man-

agement and integration of modeling elements and measurement data.

The design of the system is focused on three main points, which are

equally important. A central storage and scalable system was indispensable.

Collaboration work is emphasized and methods for access restriction and

user management are also included. With MOSAIC, the user has a tool for

advanced modeling, based on documentation implementation. The origin

and connection of model and measurement data have to be part of this

documentation in order to preserve important information.

2.2.1 Infrastructure

Different database configurations can be created, depending on the needs of

the project. It is important to meet the different user and security require-

ments. The structure of the possible information flows can be seen in Figure

2.6.

In research, the main goal is to have an open and freely available plat-

form for a broad collaborative community, independent of user locations and

available software. The control over sensitive data is as important as the

possibility to give access to certain groups and users. Depending on the sci-

entific standards in the different countries, original data has to be stored for

a certain period of time. The German Research Foundation proposes a time


MOSAIC

DatabaseMaster

DatabaseSlaves Private master server

MOSAIC MOSAIC

Local server environment

I II IIIFigure 2.6: Possible database configurations

span of ten years for the storage of original data (DFG, 2013) and there

are different international recommendations (WCRI, 2013) with basically

the same statement. Collaborating partners should agree on a method and

system to manage, share and save the use of research data. Configuration

I and II in Figure 2.6 are most suitable for the tradeoff between security

and open access. This configuration was applied in a research project (In-

PROMPT SFB TR63) founded by the German Research Foundation with

different universities and teams participating in different fields of research.

Another point of interest and scope of application for MOSAIC is teach-

ing. Because of the software structure, it is easily possible to perform lectures

independent of the computer operating systems on-site. All that is necessary

to is a set of computers with Internet connection. Depending on the learning

progress of the individual participants, examples can be derived dynamically

from the database to support the learning process, or to introduce additional

topics. The common server structure for this scenario is Configuration I in

Figure 2.6. As previously mentioned, workshops are performed worldwide

and this concept has proven to be useful.

The use of MOSAIC in industrial projects is more difficult, mainly be-

cause of the higher demand of security. In many cases, a firewall and the


Figure 2.7: Map of MOSAIC server locations, as of May 2014

use of a proxy server can block the connection to the MOSAIC database.

Especially in companies, the integrated modeling environment can be an

asset. Globally distributed teams can sign up an collaborate. Also the mea-

surement data from the plant can be used by research, development and

engineering groups for modeling and optimization. Owing to the flexible

code generation feature and the platform independent software, MOSAIC

could be easily integrated into existing systems and workflows. Configura-

tions II and III in Figure 2.6 are appropriate to this case. A private server

with access control to the company network can increase the security. A

local workstation as in Configuration III is suggested when it is not possible

to connect to a public or company database.

Currently available MOSAIC servers and their locations are shown in

Figure 2.7 (as of May 2014). The first and main server is located at the

Technical University of Berlin, Germany. Together with a slave server in

Scranton, USA, it represents Configuration Type I, as shown in Figure 2.6.

Additional standalone servers of Type II are located in Medellin, Colombia

and Kuantan, Malaysia.


2.2.2 Model database

The database implementation can be divided into different sections. The

main part and development is the model database. It includes the model

data management and a user management, along with the management of

access rights. For a better reuse, all elements are indexed together with the

element description. A search mechanism is implemented, giving users the

possibility to search for single keywords.

Collaborative work on a common set of model equations is prone to

conflicts. To deal with these, an effective version control mechanism is im-

plemented. MOSAIC was designed for a better connection of documentation

and the software implementation, by creating the model source code from

the documentation. The version control mechanism can be used to extend

the documentation with the model history, which is an important piece of

information for a possible reuse.

2.2.2.1 Model data management

In model management, different aspects are important. Each user has to

have a private area in the database with a limited access for other users. As

the focus is on collaboration, it has to be possible to share individual data

elements among team members. The database table structure in Figure 2.8

was designed to address these requirements. Different tables are needed for

individual data elements. If not stated differently, the field ts in each table

is used to trace the changes in the corresponding entries.

Table: data Each modeling element, e. g.notation and equation, is stored

in this table with a unique id. The field content contains the correspond-

ing XML-files. To ensure consistent naming, a combination of id package,

id data type and name has to be unique.

Version management is accomplished with the field snapshotFrom. When

a new version of a data element has to be stored, the previous version is

moved into a new entry in the table with a new unique id. In the field

snapshotFrom, the original id is used to link to the root entry. In combination


Figure 2.8: Structure of the model database

with the field ts, the complete history of each element is preserved.

Table: package Individual data elements are grouped by assigning each

of them to a single package. Every package has a unique id. A hierarchical

package structure is achieved by assigning each package to a parent package

by specifying the id parent package. To ensure consistent naming, a combi-

nation of id parent package and name has to be unique. In case of changes,

the field ts is updated with current timestamp to trace changes. The result-

ing hierarchical structure can be seen in Figure 2.9, which is a screenshot of

the general open/save file dialog of the graphical user interface.

Table: dataXdata This table is used to document the connection of the

single data elements. It includes both the dependencies and the use. The

information is used for the hierarchical search functionality and documenta-

tion with keywords. Each entry in the table is a connection of the modeling


< <

deTU-Berlin

dbtaBasic balancesDebugExamples

AspreyExercise FlashHeat exchanger

Wrongreduced System.moseqsSystem.moseqs

Learning TrailLectureMixerOptimizationOrthogonal collocationVLE - Wilson - Methanol - Water

Process UnitsPublications

A corrugation geometry based model for efficiency of structured distillation packing, Z. Olujic, A. B. Kamerbeek und J. de Graauw (1999), in: Chemical Engineering and ProDesigning robust optimal dynamic experiments, S. P. Asprey und Sandro Macchietto (2002), in: Journal of Process Control, 12:4(545 - 556)Distillation Columns Containing Structured Packings: A Comprehensive Model for Their Performance. 1. Hydraulic models, J. Antonio Rocha, Jose L. Bravo und James R. F

Open

Close

New Package

current Version

[/, de, TU-Berlin, dbta, Examples, Heat exchanger]

reduced System.moseqs

Package:

File:

Version:

Figure 2.9: File selection dialog of the model database

element identified by (id) with the parent element identified by idParent.

For a full documentation of the model development history, the duration of

the application is specified with timestamps in the fields tsStart and tsEnd.

tsStart is set when the connection between the two data elements is set and

tsEnd is defined when the connection is removed.

Table: keywords Keywords are assigned to single elements is used to

categorize and organize the model elements. Each keyword has a unique id.

Similar to the package table, the keywords are hierarchically organized and

each keyword can have a parent element defined with the field id parent. To

ensure consistent naming, the combination of id parent and name has to be

unique. Each keyword is assigned to the creator with the field userId.

Table: dataXkeywords Keywords can be assigned to any type of mod-

eling element. The realization is done with a cross table, where the id of the

keyword (idKeywords) is matched with the data id (idData). For documen-

tation, the start (tsStart) and end times (tsEnd) are included.


Table: files In order to understand a complex model, providing additional

material along with the model can be useful. This table is a container

for external files (e.g. figures, flowcharts). Each entry has a unique id as

identifier and is displayed to the user with the value of name. The file itself

is stored in the field file as a blob entry.

Table: dataXfiles A cross table is used to assign the files to the cor-

responding modeling element with the paring of idData and idFiles. The

duration of the connection is documented with the fields ts and tsEnd.

Table: data typ id This table is an auxiliary table for use in MOSAIC

and contains a list with different file names (name) and their file extensions.

2.2.2.2 User management

An advanced, but mandatory feature of an online collaboration platform is

a full user and access rights management system. The database structure,

which is needed to describe these relations is illustrated in Figure 2.10. It is

ensured that every individual user gets their private workspace. User groups

can be created and access can be granted as needed.

Table: user A list of all registered users containing the mandatory user-

specific display settings (displayName, displayRealName, displayDate, dis-

playTime). Every user has a unique id and login name, a password, and

additional information such as name and email.

Table: group User groups are listed in this table. Each user gets a

group where other user can become a member. Additional groups can be

created as needed. Similar to the package organization, groups are sorted

in a hierarchical structure with super and sub groups, where members of a

super group are automatically members of the subgroup. However, members

of sub groups are not necessarily members of the super group. Each group

has a unique id and a reference to the super/parent group id parent group.


Figure 2.10: Access rights for user and groups

Table: userXgroup A cross table is used to assign users with their unique

id (id user) to the id of the user group (id group). As mentioned earlier,

every user gets a group by default, and this entry in the table is marked

with a Boolean value in the field default. Group memberships have a limited

tenure and expire according to the time stamp in expires.

Table: dataXuser To share single modeling elements between individual

users, the unique user id (id user) and the data element id (id data) are

paired in this table along with the level of access (right) and a time limit


for the access (expires).

Table: packageXuser Not only single modeling elements, but also whole

packages can be shared with single users. Analogous to the table dataXuser,

the unique id of the package (id package) is matched with the unique id of

the user (id user). The home package, which is a private workspace for the

user, is marked with a Boolean value (default). Every user has exactly one

home package. With the fields right and expires, the access permissions and

duration are also specified.

Table: dataXgroup To grant access to whole groups for single data el-

ements, the data id (id data) is matched with the corresponding group id

(id group) as well as with the desired access level and duration (expires).

Every user of the group and possible subgroup has instant access.

Table: packageXgroup Finally, to share whole packages with a group of

users, this table is used to combine the unique id of the package (id package)

and the group (id group). The access level and duration can be set in the

fields right and expires.

Table: package see Figure 2.8

Table: data see Figure 2.8

2.2.3 Measurement information database

With the introduction of a measurement information database, an integra-

tion step is taken where the model information is permanently connected

to the corresponding measurement data. In the next section, the structure

of the measurement database and the connection to the model elements are

explained. With a suitable designed software bridge, it could be possible to

connect the database to the historian software of commercial process control

software.


Figure 2.11: Structure of the measurement data database

2.2.3.1 Equipment and process data

The tablie is intended for the collection of historical data. By using this

database, users can track the complete equipment history to get a fingerprint

of the plant in combination with process data values. This can be crucial to

judge the integrity of the available data.

Table: mPlant Measurement values are part of some kind of process

system. Each plant is identified with a unique id and name.


Table: mPlantDescription A plant is documented with a description,

which may change and evolve during its lifetime. New descriptions (descrip-

tion) are added to this table and are then assigned to a plant (idPlant) with

a starting (tsStart) and end point (tsEnd)

Table: userXmPlant Similar to model data management, access rights

are granted for individual users by combining a user (idUser) with a plant

(idmPlant) and the access right.

Table: mPlantInformation Different more and less important pieces of

background data are listed with a unique id and name. The single entries

are categorized according to their level of importance. Per default this list

contains the plant location, the person in charge and contact details.

Table: mPlantXmPlantInformations Plant data types are assigned to

a specific plant by matching the plant (idPlant) with one or more mPlantIn-

formation (idInformation). The field value contains the actual information

content. In the field tsStart, the starting point of the validity of the in-

formation is given. When the value of a piece of information is changed,

tsEnd is specified. This gives us the possibility to search the history of a

plant and previous valid information entries. For instance, the location of

a laboratory facility can change. By considering the date of the change, a

consistent documentation of the location history is assured.

Table: mConfiguration During the lifespan of a plant, different changes

are carried out with regard to the configuration. Whenever changes are

done on the plant structure, which have to be documented to understand

the measurement values, a new configuration entry is added to this table

with a unique id, the connection to the plant (idmPlant) and a description.

The creation of the configuration is stored in the field ts. When a new

configuration is created, the previous one is closed by defining the end point

in tsEnd. Only one configuration can be active with an unspecified ending

time.


Table: files Various elements are needed to provide a sufficient documen-

tation of the single configuration setups. The user is encouraged to provide

updated and detailed flowchart files, which illustrate the setup and the mea-

surement device locations for each new configuration. Any file can be added

to this table and is stored as (file) with a unique id.

Table: mConfigurationXfiles The files are assigned to the respective

configuration with this cross table by matching the configuration (idMCon-

figuration) with the file idFiles. With the fields ts and tsEnd, the start and

end time points of the assignment are stored.

Table: mPoints Available data points in the plant, which can be ob-

tained from measurement or control devices, are listed in this table with a

unique id and are permanently assigned to a plant (idmPlant). According

to definition, the name of the entries is the same as its name in the corre-

sponding flow chart of the configuration. The available time span is defined

with a starting tsStart and end tsEnd point.

Table: mPointsXmConfiguration The active and available data points

of a plant have to be marked as activated for configuration. This is done

by assigning the points idmPoints to the corresponding configuration idm-

Configuration. The fields tsStart and tsEnd are used to set the time range

of this assignment.

Table: mValues The actual value entries are stored in the table mVal-

ues. Each value gets an entry that contains the measurement time (ts), the

measured point in the plant (idmPoint), the value and the measurement

set (idMSet). Additional fields are the lower and upper error (lowerError,

upperError) as well as a Boolean field to mark the entry as valid. The

timestamp is an absolute date with a precision up to a millisecond.

Table: mSet Different values are summarized as a set, which is mostly

a continuous data collection of some sort. Each set gets a unique id and a


description and is assigned to a plant (idmPlant). The starting time is set in

the field ts. tsEnd has in this case the function to mark this set as deleted.

If it is set, the set is no longer listed in the graphical user interface. An extra

field (hasTimeValues) provides the information, if time values are available

in this set for measurements. If no time values are available, a relative time

in milliseconds is used, which acts as a counter for the data values.

Table: user see Figure 2.10

2.2.3.2 Connection of measurement and modeling data

Different data tables where designed to store information of modeling and

measurement data in a structured way. With two more tables, it is now pos-

sible to include the connection between the model and measurement parts.

Table: dataXmeasurement In this table, a connection between a data

element and the measurement section is listed. When measurements are

connected to a variable list, a new entry is created with a unique id, the id

of the variable list (idData), the id of the user, who is creating the connection

(idUser) and the time range for the desired values (timeStart - timeEnd).

The detailed type of import (e.g. the first data point or an average) is set

in pointIndex.

Table: variableXmPoints The detailed connection of the model and

measurement is listed in this cross table. Single variable namings from the

model (variableNaming) are matched with single measurement points (idm-

Points) from a plant configuration. Related matchings are summarized by

assigning them to a dataXmeasurement entry (idDataXmeasurement).

Table: data see Figure 2.8

Table: user see Figure 2.10


Figure 2.12: Structure of the connection of measurement model data

Table: mValues see Figure 2.11

Table: mPoints see Figure 2.11

Table: mSet see Figure 2.11

Table: mPlant see Figure 2.11

2.3 Case studies

Three different aspects are highlighted with examples. To begin with, user

development and the propagation of the unique workfloware outlined by

2.3. CASE STUDIES 25

Apr 2011

Aug 2011

Dec 2011

Apr 2012

Aug 2012

Dec 2012

Apr 2013

Aug 2013

Dec 2013

Apr 2014

Aug 20140

100

200

300

400

500

Figure 2.13: Number of registered user

discussing the existing data in the database.

Two case studies are presented. First, the development history of the

equation system for the calculation of a chemical equilibrium, (used in sec-

tion 3.3.1.1) is presented.

Finally, the connection of a equilibrium column model with measurement

data of a pilot plant is discussed. This case study illustrates the implemen-

tation and integration of measurement data in MOSAIC.

2.3.1 MOSAIC and database usage

The best proof of a working concept is the acceptance. Without some kind

of personal advantage for the user, the long-term development of a new

modeling and simulation software will not work. A first usable version of

MOSAIC, based on the database engine, was released in February 2011.

Initially, only a limited group of internal test users were given access. The

feedback was positive and after student workshops, MOSAIC was opened

to the public. Since March 2012, anyone can apply for a personal account


Feb 2011

Aug 2011

Feb 2012

Aug 2012

Feb 2013

Aug 2013

Feb 2014

Aug 20140

20

40

60

80

100

120

Figure 2.14: Number of active users per month, working on the main serverin Berlin

on the project homepage4, free of charge. At this point, more users started

to register, as can be seen in Figure 2.13, where the aggregated number of

users is plotted. The development was supported by arranging MOSAIC-

workshops at different universities worldwide. All participants were supplied

with a personal account and initial models from the workshop, which can be

used as a starting point for development. Feedback was collected constantly

and used for improvements.

It is important to point out that registered users continue to work for a

longer period, often for a specific project. Figure 2.14 shows the total number

of users per month, who are working in the main database in Berlin.

Since the opening of the registration in March 2012, the number of active

users has also increased. The results of the MOSAIC server in Berlin are

shown in Figure 2.15, where the traffic on the server is visualized with the

total number of database queries for the last 30 days. Since MOSAIC is

in permanent use, including weekends, a high reliability of the hardware

4www.mosaic-modeling.de


101

102

103

104

105

106read

Oct 28 2014

Oct 31 2014

Nov 03 2014

Nov 06 2014

Nov 09 2014

Nov 12 2014

Nov 15 2014

Nov 18 2014

Nov 21 2014

Nov 24 2014100

101

102

103

104write

Figure 2.15: Database queries for 30 days

infrastructure has to be guaranteed.

By presenting MOSAIC in conferences and offering workshops at foreign

universities worldwide, a demand to offer a worldwide service was created.

Gradually, additional servers were installed. By tracking back the IP of

every computer, which tries to start MOSAIC via our homepage, a map

can be created as in Figure 2.16. Where a server is installed, a higher user

activity is observable. The main activities are clearly located in Germany

and Europe.

In MOSAIC, three different classes of equation system types are sup-

ported. For each class, different code generators are available, which can be

used to export and solve the system. Figures 2.17 - 2.19 illustrate the distri-

bution of the used code generator for nonlinear (NLE), ordinary differential

(ODE) and differential algebraic (DAE) equation systems. MOSAIC has

the demand to increase the interchangeability between different simulation


Figure 2.16: Map of access locations to MOSAIC

tools. As can be seen, this feature is used and different types of solvers are

applied. The BzzMath library can be executed from within MOSAIC and is

selected as default in all three cases. Additionally, local software as Matlab

and gPROMS is used.


a

b

cd

ef

ghi

j

% Specificator name

a 46.6 C++ BzzMath NLE Obj

b 23.0 MATLAB NLE

c 11.5 AMPL Functions as Equations

d 4.9 C GSL Hybrid

e 3.9 gPROMs NLE Std

f 2.0 C GSL Hybrids

g 2.0 MATLAB NLE - nested and decomposed

h 1.2 MATLAB NLE - decomposed

i 1.1 User defined

j 3.8 Other with < 1%

Figure 2.17: Used code specificators: NLE (May 2014)

a

b

c

d

ef

ghijk

% Specificator name

a 34.5 C++ BzzMath ODE Stiff Obj

b 19.2 sDACl ODE

c 16.3 C++ BzzMath ODE Non-Stiff Obj

d 13.1 MATLAB ODE Std

e 3.8 User defined

f 2.6 C++ BzzMath DAE Obj

g 2.6 SCILAB ODE Std

h 2.2 gProms DAE Std

i 1.3 ACM DAE Funcs to Equas

j 1.3 MATLAB DAE Std

k 3.2 Other with < 1%

Figure 2.18: Used code specificators: ode (May 2014)


a

bc

d

efgh

% Specificator name

a 63.1 gProms DAE Std

b 15.9 C++ BzzMath DAE Obj

c 8.4 MATLAB DAE Std

d 5.9 sDACl DAE

e 3.2 C++ BzzMath DAE Obj auto alg. consist.

f 1.3 SCILAB DAE Std

g 1.2 MATLAB DAE Funcs to Equas

h 0.9 Other with < 1%

Figure 2.19: Used code specificators: DAE (May 2014)


2.3.2 Development history of a model

Users have the possibility to activate the version control system in MOSAIC.

MOSAIC registers any change in the single modeling elements, and users

have the possibility to view and reuse previous model versions and to in-

clude the history of equation systems in the documentation generated by

MOSAIC.

An example is given with the equation system 28994: chemical equi-

librium.moseqs, which is used to minimize the Gibbs enthalpy. The op-

timization results are described in Section 3.3.1.1 and the final model is

documented in the Appendix. The different development steps in the evo-

lution to the final model can be seen and will be discussed with extracted

elements from the documentation generation of MOSAIC. All the steps in-

clude actual intermediate versions of the final equation system model that

were revised and corrected between November, 2013 and March, 2014.

Version from: 2013-11-18 13:00:49.0

The first version of the equation system was implemented in MOSAIC in

November 2013, with the following set of equations, based on a literature

example (Bracken and McCormick, 1968) with a molar balance, a flow bal-

ance, the calculation of the molar fraction, and the equation for the Gibbs

enthalpy.

Equation 28988: molar balance.mosequ

NS∑s=1

as,e · F ins =

NS∑s=1

as,e · F outs

Equation 29231: molar fraction.mosequ

xs =F outs

F out


Equation 28993: gibbs free energy.mosequ

G =

NS∑s=1

(F outs · (ws

T+ ln(P ) + ln(

F outs

F out)))

Equation 29010: total flow out.mosequ

F out =

NS∑s=1

F outs

Version from: 2013-11-18 14:46:05.0

The model was changed that same day. Specifically, the variable for the total

outgoing flow in the calculation of the mole fraction was substituted with

the right hand side of the flow balance. Additionally, the equation for the

Gibbs enthalpy was reformulated and the chemical potential was calculated

separately.


NS∑s=1

as,e · F ins =

NS∑s=1

as,e · F outs


xs =F outs

F out

Equation 29289: chemical potential, ideal.mosequ

μs = gs + (P · xs)



G =

NS∑s=1

(ns · μs)

Version from: 2014-03-11 13:34:10.0

For a long time, nothing was changed in the system. After a while, different

variables were reformulated. The variable of the pressure was changed from

a capital to a lower case p and the flow (F ) was replaced by the molar

amounts (n).


NS∑s=1

as,e · nins =

NS∑s=1

as,e · ns


xs =ns∑NSs=1 ns


μs = gs + ln(p · xs)


G =

NS∑s=1

(ns · μs)


Version from: 2014-03-12 13:02:38.0

This time, a reformulation of the equation for the chemical potential was

done to remove the logarithm. Instead, it was decided to use an exponential

expression, in an attempt to eliminate a discontinuity in the previous version,

a mole fraction with the possible value zero.


NS∑s=1

as,e · nins =

NS∑s=1

as,e · ns


xs =ns∑NSs=1 ns


exp(μs − gs) = p · xs


G =

NS∑s=1

(ns · μs)

The final equation system was changed one more time and the documen-

tation, including the final notation information can be found in Appendix

(p. 117). It became apparent that the system had a better convergence

behavior in the optimization when the logarithm was utilized. Therefor,

boundaries for the mole fraction were set to 1E − 6 ≤ x ≤ 1, additional

work on this topic is discussed in Esche et al. (2014b).

Adding the equation system history to the documentation automatically

proved to be useful. The different approaches to model and describe the


system can be browsed, including different equation formulations. Other

users can follow the changes and individual decisions can be withdrawn.


UPPER FEED LP

KHP

WK101

WE101

TIR

101

TIR

105

TIR

107

TIR

109

TIR

113

TIR

111

TIR

115

TIR

117

TIR

119

TIR

121

TIR

123

TIR

125

TIR

127

TIR

128

TIR

126

TIR

124

TIR

122

TIR

120

TIR

118

TIR

116

TIR

114

TIR

112

TIR

110

TIR

108

TIR

106

TIR

104

TIR

102

TIR

129

VM101

VM102

VM103

VM104

VM105

H144

H143

H142

H141

H140

WE2

M

VS2

WE1

VLIR

2

M

VS1VLIR

1

VM1

VM3

TIR

2

VM4

VM2

H1 H2

M

VS4VLIR

4

H122 H4

H3

H33

H121W

K2WK1

VD101

TIR

4

FIR

1

FIR

2

TIR

3

TIR

1

P101

MVS 101

FIR

101

VM106

WK102

WK103

WK104

VM107

H115

H116

H118

H119

H117

H120

M

VS103

VLIR

103

TIR

134

LIR

102

TIR

142

FIR

103

TIR

141

M

VS102H114

VLIR

102

TIR

135

WE103

PIR

104

PIR

103

PIR

102

TIR

139

TIR

138

PIR

101

TIR

137

BHP23

BHP13

BHP7

BHP3

H32

H111 H112

H109 H110

PIR

101

H108

TIR

131

TIR

130

H39

H113

LP

TIR

103

LIR

101

TIR

100

H 204

VU101

TIR

140

H14

CoolingWateroutput

By-passvalve

CoolingWatersupply

LOWER FEED LP

LP

INLET (TANK 6)

OUTLET(TANK 2)

OUOTLET(TANK 1)

INLET(TANK 1)

INLET(TANK 3)

LOWER FEED LP

WK 201

Figure 2.20: Piping and instrumentation diagram of the column (Barz, 2008)


2.3.3 Modeling and measurement case study

This is an actual application done with data from a pilot plant located at the

Technical University Berlin. The focus is on a distillation column, which is

part of a pressure swing setup, comprising a high and low pressure column,

for the separation of the azeotropic mixture acetonitril/water (Forner et al.,

2005). The set of measurements used, is part of a PhD thesis (Barz, 2008)

and the raw data as well as the different description files are from this thesis5.

In this case study, only the high pressure column is considered. The

piping and instrumentation diagram is shown in Figure 2.20. It is a tray

column with 28 stages, an inner diameter of 0.107m, and is equipped with

a natural circulation evaporator (WE101) and a total condenser (WK101).

An existing steady state equilibrium model is reused and adapted to the

equipment and process specifications. Models for the evaporator and the

total condenser are connected, and the nonlinear phase behavior is described

by using the Wilson gE model for the calculation of the activity coefficients

(Wilson, 1964). The full model is documented in the Appendix.

When the model is evaluated, a new matching dialog (2.21) can be

opened from the variable specification panel. All the information needed

to connect the evaluation to the plant data is specified here. First, the

plant is chosen from the dialog box. In the next step, the time range is

defined from which the values are imported. Two different modes are pos-

sible. The first available value is used, or an arithmetic average of all the

values in the specified time range is calculated. The most important step is

the matching of the variables and the measurement points. From the list of

available model variables and plant measurements, the couples are selected

and matched. In this example, the evaporator temperature and condenser

pressure are imported. TR is matched with T100 and ptr=28 is matched

with P103. A steady point was detected by the user between 14.03.2007

06:40:00.000 and 14.03.2007 06:42:00.000, where an average of the values is

calculated. The values for the variables are directly set and, as usual can

be used for simulation and optimization. In addition to the measurement

5The author is graceful for this


14.03.2007 06:42:00.000End point

14.03.2007 06:40:00.000Starting poi...

averageclosestSelection

6: ZweidruckkolonnePlants

Couples

NSPC Variab... Senso...

e2: T100e0: P103

break

match

Measurement points

id Sensor n...

154 P101155 P102156 P103157 P104158 P105159 P106144 T223

NSPC Variable ...

e0:e0:e0:e0:e0:e0:e0:

Variables

Figure 2.21: Panel for matching variables with measurements

data, the documentation of the evaluation in MOSAIC is extended with the

information with regard to the new connection. Variable details, plant in-

formation, and the raw data are added. The documentation text added here

is copied from MOSAIC and was generated automatically.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%Measurement information start

Measurement information

Values used

From: 14.03.2007 06:40:00.000

To: 14.03.2007 06:40:00.000

Modus: average

Plant info

Id: 6

Name: Zweidruckkolonne

Location: TU Berlin

Emergency contact: Guenter Wozny

Person in charge: Tilman Barz - tilman.barz@tu -berlin.de

Room: TK Halle

Plant configuration history

31.03.2005 15:10:00: Database Initialization


01.11.2006 00:00:00: Condenser setting changed by Piotr

04.06.2007 16:37:00: Setting update by Shivom

22.08.2007 16:51:00: Setting update by Eugen

Connected Variables

Variable -> measurement point

e[0]32089 >e[2]32088. T_{R} -> T100

e[0]32089. p_{tr=28} -> P103

Raw data

P103:

time;value;lowerError;upperError

14.03.2007 06:40:02.000;1.998392582; -; -;

14.03.2007 06:40:10.000;2.001471519; -; -;

14.03.2007 06:40:18.000;2.001471519; -; -;

14.03.2007 06:40:26.000;1.998392582; -; -;

14.03.2007 06:40:34.000;2.001471519; -; -;

14.03.2007 06:40:42.000;1.998392582; -; -;

14.03.2007 06:40:50.000;2.004550457; -; -;

14.03.2007 06:40:58.000;1.998392582; -; -;

14.03.2007 06:41:06.000;2.004550457; -; -;

14.03.2007 06:41:14.000;1.998392582; -; -;

14.03.2007 06:41:22.000;2.001471519; -; -;

14.03.2007 06:41:30.000;2.001471519; -; -;

14.03.2007 06:41:38.000;2.001471519; -; -;

14.03.2007 06:41:46.000;1.998392582; -; -;

14.03.2007 06:41:54.000;2.001471519; -; -;

T100:

time;value;lowerError;upperError

14.03.2007 06:40:02.000;120.9039993; -; -;

14.03.2007 06:40:10.000;120.9839935; -; -;

14.03.2007 06:40:18.000;120.9039993; -; -;

14.03.2007 06:40:26.000;120.9039993; -; -;

14.03.2007 06:40:34.000;120.9299927; -; -;

14.03.2007 06:40:42.000;120.9039993; -; -;


14.03.2007 06:40:50.000;120.9299927; -; -;

14.03.2007 06:40:58.000;120.9299927; -; -;

14.03.2007 06:41:06.000;120.9299927; -; -;

14.03.2007 06:41:14.000;120.9039993; -; -;

14.03.2007 06:41:22.000;120.8769989; -; -;

14.03.2007 06:41:30.000;120.9299927; -; -;

14.03.2007 06:41:38.000;120.8769989; -; -;

14.03.2007 06:41:46.000;120.9299927; -; -;

14.03.2007 06:41:54.000;120.9039993; -; -;

Measurements were done at

07.12.2006 00:00:00

19.12.2006 00:00:00

16.02.2007 00:00:00

20.02.2007 00:00:00

08.03.2007 00:00:00

14.03.2007 00:00:00

20.03.2007 00:00:00

28.03.2007 00:00:00

03.04.2007 00:00:00

05.04.2007 00:00:00

12.04.2007 00:00:00

18.04.2007 00:00:00

Chapter 3

Advanced modularity

concepts

3.1 Concepts

Many tools are common in process modeling and optimization. These tools

range from spreadsheets, general mathematical software and programming

languages to specialized high level modeling environments. According to

a survey by Cameron and Ingram (2008), the average number of modeling

and simulation tools used by a work group is approximately five. Only

a minority of the survey participants use a single modeling tool which is

usually a flowsheeting package. In the extreme case, up to 12 tools are used

in one team.

Various reasons for this behavior are plausible. Each user in a team

has different preferences and demands on a software tool. The different

tools themselves have different capabilities and solution methods for different

tasks. As stated in the Table 1.1, most tools are specially designed for either

simulation or optimization and support only a limited set of model types.

In the global optimization of a differential algebraic equation system

which is part of an optimal control problem, the results are also used in a

flowsheet simulation environment. This forces the modeler to use at least

two different pieces of software and to manually discretize and implement

41

42 CHAPTER 3. ADVANCED MODULARITY CONCEPTS

Create, or update model Run optimizationyes

Reimplement simulation in optimization

software

yes

no no

yes

no

FinishedBuild in optimizersufficient?

Does simulation softwaresupport optimization?

Run optimization

Figure 3.1: General procedure for simulation and optimization in processsimulation, with different model versions

the model as needed. This implies redundant work, and is thus prone to

error and time consuming.

In this context, the modularity is defined as a decomposition of the single

simulation and optimization elements into functional units with a subset of a

unique modeling function. With the proposed modularity approach, the user

has the possibility to access the needed functions with the original model

instance, thereby having the freedom to choose the most suitable simulation

or optimization platform.

This results in an increased reuse of data and less redundant, and unnec-

essary work. Two different approaches are presented the switching between

simulation and optimization environments, and the modular discretization

of differential (algebraic) equation systems to nonlinear equation systems.

3.1.1 Optimization

There is a permanent gap between simulation and optimization due to their

different features. While simulation tools have advanced methods to describe

physical properties and are capable of solving dynamic process simulations,

pure optimization tools are focused on large-scale nonlinear algebraic equa-

tion systems with the application of state of the art optimization algorithms.

Most simulation platforms offer limited optimization capabilities, but the

transfer of state of the art optimization algorithms, e.g. global optimizer, is

slow and the user has, in most cases, limited access to the algorithm param-

eters. The problems of model sharing between simulation and optimization

platforms are illustrated in Figure 3.1. In this case, the user starts with an

3.1. CONCEPTS 43

Create, or update model Run optimizationyes yes

nono

yes

no

FinishedBuild in optimizersufficient?

Does simulation softwaresupport optimization?

Run optimization

Export for simulation

software

Export foroptimization

software

Figure 3.2: Proposed approach in which the same model is utilized for sim-ulation and optimization software

initial model, designed for a simulation application. When there is need for

optimization, it can first be tried if the optimizing capabilities of the simula-

tion tool are sufficient. If not, the user has to implement the model again for

the desired optimization platform, and add the optimization specifications.

Consequently, there are two model implementations with different variable

specifications (simulation and optimization). The modeler can only work on

one copy at a time and changes are implemented asynchronously.

In this work, a new approach is introduced, where the full model and vari-

able specification for both, simulation and optimization is done in MOSAIC

prior to the implementation in the finally used simulation or optimization

platform, as illustrated in Figure 3.2.

Changes have to be made only once and the specific results can be reim-

ported and used in different contexts. The documentation capabilities of

MOSAIC were presented in Kuntsche (2013), the same source is used for an

automated documentation generation.

3.1.2 Discretization

In process modeling, different types of equation systems are created, depend-

ing on the system and the described phenomena. The range includes plain

(non)linear equation systems, ordinary equation systems (ODE), differential

algebraic equation systems (DAE) and partial differential equation systems

(PDE) (Hangos and Cameron, 2001; Pantelides et al., 1988).

For steady state simulations, nonlinear equation systems are common

and can be used in nearly any context. To study the influence of time-


Modeling, including differential expressions

Run simulationyes

Reimplement as discretized modelno

yes

no

FinishedDoes simulation softwaresupport differential

operators?Run simulation

Figure 3.3: Processing of differential equations in process simulation, dis-cretized model as additional implementation

and location variables on dependant variables, differential expressions are

inevitable and the numerical approximation of these requires special meth-

ods. Software tools were developed to enable the user to describe the system

in some kind of modeling language, and predefined internal libraries handle

the solution (Finlayson, 1980; Ascher and Petzold, 1998).

Dynamic optimization is a field with different application possibilities,

e.g. optimal control (Biegler, 2007; Logsdon and Biegler, 1989). However,

most optimization algorithms are not designed to handle differential expres-

sions. Typically, the user has to find a suitable way to solve the differential

equation system and then use an application programming interface of the

optimizer in a sequential loop. High effort is required for the realization and

the calculation of the required derivatives (Barz et al., 2011). The resulting

software combination is in most cases an isolated implementation with a

limited range of applications.

Another approach is the full discretization of the differential equations

and the reformulation as nonlinear equation system by using higher order

implicit discretization methods (Oh and Luus, 1977; Tsang et al., 1975;

Biegler, 2010). This gives the possibility to optimize the system directly

using some kind of optimization software and the derivatives are directly

available. The main disadvantage is the early commitment to a certain

discretization method, which is hard coded into the model equations.

As illustrated in Figure 3.3, in this approach the user has the idea of

a model and can decide what kind of software tool s/he wants to use for

the solution. If the target platform can handle differential operations well

3.1. CONCEPTS 45

Modeling, including differential expressions

Run simulationyes

Apply discretizationno

yes

no

FinishedDoes simulation softwaresupport differential

operators?Run simulation

Figure 3.4: Processing of differential equations in process simulation, dis-cretized model based on original implementation

enough and the produced solution is valid, everything is fine.

However, problems arise in cases where the solution fails, the supported

methods are insufficient, or a specific target platform is mandatory, which

only supports nonlinear equation systems.

Different tools are used for a better understanding of the model. For

the final implementation, some kind of discretization has to be applied,

which permanently changes the structure. Different model implementations

are the result and the switching of the software platform in an advanced

modeling stadium and the resulting new implementation is time consuming

and involves unnecessary effort.

The modeler has limited options in regards to the selection of methods

and tools. In this work, the freedom to choose any desired modeling or

optimization platform, independent of the equation system type and with-

out redundant implementation work is proposed. Discretization methods

are moved from the solvers and numerical libraries to the documentation

modeling tool MOSAIC and are stored as separate modules. It is then

possible to apply these to the differential expressions of the original model

implementation as necessary. The original equations are not altered and the

discretization methods can be altered and exchanged if need be.


3.2 Implementation

3.2.1 Optimization

The objective is the seamless integration of an optimization framework in the

existing modeling and simulation software MOSAIC. It is mandatory to use

only existing MOSAIC components, namely variables, equations, equation

systems and evaluations. It thus is ensured that the user has the option of

switching between simulation and optimization, depending on the needs and

the designated third party software. After parameter estimation is carried

out using GAMS, it becomes possible to use the same equation system from

the optimization along with the optimized parameter in a flowsheeting tool

like Aspen Plus.

3.2.1.1 Integration into MOSAIC

Four components are needed to specify a complete optimization statement:

an objective function, which has to be minimized; equality and inequality

constraints, which have to be fulfilled; and variable boundaries, which limit

the solution domain. Apart from the inequality constraints, all elements can

be described with existing MOSAIC modeling elements.

Objective function The objective function can be made out of any vari-

able from the equation system, which is selected for use as an equality con-

straint.

Equality constraints A previously created equation system, containing

all needed equations. It is assumed that this equation system has been

previously tested in a simulation context.

Inequality constraints Inequality constraints are not supported for the

simulation in MOSAIC and it is not possible to use inequality constrains

without excluding a vast number of unconstrained numerical solvers, mostly

for simulation (e.g. fsolve (Matlab))). Since MOSAIC is designed to empha-

3.2. IMPLEMENTATION 47

size the exchange between different programming and modeling languages,

the exclusion of inequality constraints was a conscious decision.

However, in constrained optimization inequality constraints are needed

so the requirement for compatibility with the simulation features of MOSAIC

lead to a conflict, as inequality equations are not supported by simulation

software.

When do algebraic inequality constraints arise and are they really nec-

essary to state optimization problems?

No, they are not necessarily needed and are created by moving variable

boundaries into equations, by substituting the variable in the equation. For

example, for the trivial optimization of the volume V = f(d, h) of a cylinder,

by optimizing the diameter d and height h in their bounds, the optimization

statement could be written as:

Minimize: V

Subject to: 2 ≤ Vπ·r2 (3.1)

1.5 ≤ d (3.2)

The height, diameter and volume are connected via the formula of a cylinder

volume, but in Equation 3.1 the height is not clearly visible. Through the

insertion of the lower bound for the height into the original equation of the

Volume, an equality constraint was reformulated to an inequality constraint

and the variable for the height was neglected.

Without this step, the equation system is formulated with equality con-

straints and variable boundaries only so that the boundaries are directly

linked to the appropriate variables:

Minimize: V

Subject to: V = π · r2 · h (3.3)

1.5 ≤ d (3.4)

2 ≤ h (3.5)

By using the proposed approach, there is no need to support inequality con-


straints. The model equations and the variables are neatly separated, as

they are needed for simulation problems, and the user is not tempted to

merge variable boundaries with equality constraints. Besides, this is an ad-

vantage for the user, as the variable information, in this case height, would

be hidden. The additional variable also does not lead to a higher compu-

tational effort. The optimization algorithm would reintroduce the variable

as a slack variable to reformulate the inequality constraint into an equality

constraint.

Optimization variables The optimization variables are selected from

the available variables in the equality constraint equation system and are

changed by the optimizer to minimize the objective function. It is required

to select at least one variable from the list of design variables.

3.2.1.2 Proposed optimization approach

The workflow for the use of the optimization feature in MOSAIC is shown

in Figure 3.5. As a starting point, the user has to create a fully functional

evaluation. The user can test the model in a simulation context, which is

later used for optimization. Any variable of the equation system can be

selected for minimization. If a suitable objective function is not available,

an additional equation can be added as an objective function. It is optional

to run a simulation and save the solution, which is reused for the initial

values of the optimization. An additional advantage is the possibility to

validate the model equations and test the parameters with the simulation

results.

The evaluation is loaded into the optimization panel and the equation in-

stances are directly set as equality constraints. In the next step, the missing

information of the optimization statement is defined in a variable selection

panel. The objective value and the optimization variables are selected and

variable boundaries defined.

With the completed statement, it is now possible to generate the source

code for the designated optimization environment. If a local installation


Figure 3.5: MOSAIC-based optimization approach

of the software is available, the code can be directly executed. Otherwise,

the NEOS server (Czyzyk et al., 1998; Gropp and More, 1997) can be used,

which provides computer clusters and most of the state of the art solvers

for GAMS and AMPL. In both cases the optimization results can be re-

imported into MOSAIC and stored as a variable list for further use in any

MOSAIC context.


The objective is to move the discretization step for the numerical solution of

differential algebraic equations from the software implementation in a solver

to the documentation level in MOSAIC. Accordingly, the application range

of models, the documentation of the solver method, the reusability of the

models, and the discretization methods are increased. A seamless integration

into the MOSAIC modeling environment is achieved by taking advantage of

the existing modeling elements. A specific discretization method for partial

differential equation systems is further discussed in Esche et al. (2014a).


The freedom of choice of software tools is increased for the user with

a higher level of modularity, reusability and documentation. Earlier, the

model had to be implemented along with the hard coded discretization

method, in cases where the solver did not support differential algebraic sys-

tems. A new implementation means redundant, and unnecessary work and

an increased demand for maintenance. With the new feature as part of this

research it is possible to use the same model in diverse software architectures

including those that support differential equations (e.g. Matlab, gPROMS)

and those that do not (e.g. Aspen, GAMS).

This problem is addressed by separating the original model and dis-

cretization implementation in two separated equation systems. A trans-

formation is introduced as a new modeling element in MOSAIC, which is

designed to modify the existing equation system as defined by the user. In

this case, the transformation is used to apply the discretization equation

system to the original model equation system. Ultimately, MOSAIC will

automatically reformulate the differential (algebraic) equation system as de-

fined in the transformation and the discretization into a nonlinear equation

system. Differential operators are replaced with a discretization expression,

and auxiliary equations are added to the final equation system.

In the current implementation, which was carried out as part of the

master’s thesis of Tolksdorf (2013), the transformation can be applied if

certain requirements are met and considered. As MOSAIC only supports

first order, linear explicit ordinary differential equations, the transformation

is limited to these. Future extensions are possible for partial differential

expressions of different orders. The right hand side of the discretization

equation can not be altered. Only discretization methods are supported,

which have access to the right hand side as provided.

3.2.2.1 Resulting structure

To create the discretized equation system, three components are needed.

The resulting structure of the use of the transformation is shown in Figure

3.6.


Figure 3.6: Elements of an applied transformation

As a starting point, the original model equation system, including the

ordinary differential expression to be discretized, has to be available. This

can be a set of ordinary differential equations, or differential algebraic equa-

tions. The equation system is not changed and preserved in the original

form.

The discretization method is defined by creating, or reusing, an equa-

tion system that contains an equation based representation of the method.

Figure 3.7 shows a screenshot of the equation system 32017: Orthogonal

collocation on finite elements.moseqs. The first equation describes

the discretization expression of the differential expression, in this case a

sum for the collocation matrix multiplication. A discretization expression

that can be used as an algebraic approximation is the only crucial element

to use an equation system for discretization. Two algebraic equations are

included as auxiliary equations. Details of the method will be explained in

the application section, when the method is used to solve the initial value

problem of a dynamic batch bio-reactor. The focus here lies on the fact

that the discretization method is implemented in a human accessible form

as equation system in MOSAIC, with the benefits of reuse and documenta-

tion. The documentation has to be given, as it is essential for all modeling

elements in MOSAIC.

The transformation gives a new MOSAIC element, in which the dis-

cretization equation system is applied to the notation of the original model

equation system. The transformation is defined in this context as a new


Evaluate Analysis Optimization Optimal exp. Design Measurements Unit Export IcasMoT Documentation ExtrasEditors

Notation Equation Function Parameter List Transformation Connector Interface Language Specification VarSpec ViewerEquation System

Save AsSaveNewSearchOpen32017: Orthogonal collocation on finite elements.moseqsLocation

ChangeReload32005: discretization.mosnotNotation

Connected Elements Internal Streams External Ports Functions Description Keywords Preview

Update Preview

NotationEquation System

Functions Internal Streams External PortsEquations

Connected Elements

Row HeightFont Size

Figure 3.7: Orthogonal collocation on finite elements, implemented as equa-tion system in MOSAIC

feature, that reformulates existing equations in MOSAIC, based on certain

user instructions. Up to now, the only application is the discretization of

differential equations.

The transformation is defined with a new editor in four steps. Screen-

shots of an example application can be found in the Appendix (Figures 6.9 -

6.12). As for any modeling element in MOSAIC, a description is mandatory

for the transformation.

Step 1: Discretization equation system and super notation The

equation system that contains the discretization has to be selected together

with the notation of the equation system, where the discretization is intended

to be applied and which is used as a super notation. Based on this infor-

mation, the available independent variables, indices, and algebraic variables

are gathered for the next steps.


The resulting transformation can later be applied to any equation sys-

tem that uses the specified notation, while the notation is also used for the

resulting equation system.

Step 2: Independent variables The available independent variables are

listed and the user has to match the independent variables, which have to be

discretized with the independent variables from the discretization equation

system. In the current form, only one independent variable can be considered

per transformation. Additional transformations can be used and applied one

after another, to discretize more than one independent variable.

Step 3: Index matching Additional variable indices are introduced with

the discretization equation system. Owing to possible naming problems and

to prevent conflicts, they are not automatically added to the final equation

system. The user has to match all existing indices from the discretization

equation system with corresponding indices from the super notation.

Step 4: Algebraic time dependent variables Only variables in a dif-

ferential operator can automatically be identified as dependent variables by

MOSAIC. Additional algebraic variables could be later used as state vari-

ables, or as design variables and an automated and clear assignment is not

possible. Thus, the user has to specify additional dependent variables that

are also considered in the transformation, and in this case, also discretized.

The final transformed equation system is created by adding the original

model equation system along with the transformation into a new equation

system. It represents the final and discretized model, and MOSAIC au-

tomatically applies the discretization to the original model. The modular

characteristic of MOSAIC is preserved, and the discretization method can

be changed easily by selecting a different transformation with a different

discretization method. If necessary, it is also possible to extend existing

methods and implement own methods.


Figure 3.8: Workflow for the discretization of an equation system

3.2.2.2 Discretization procedure

The resulting workflow for the application of a discretization transforma-

tion to an equation system, which contains ordinary differential equations

is provided in Figure 3.8. After the creation of the original model, the first

decision is the selection of a suitable discretization method. If a method

was already implemented and is available in MOSAIC, this can directly be

reused. Otherwise a complete new discretization equation system has to be

implemented. By using equation systems as format for the implementation

of discretization methods, the reuse capabilities are preserved and existing

methods can be used as a starting point for new methods. The transfor-

3.3. APPLICATION EXAMPLES 55

Figure 3.9: Equilibrium reactor

mation is specified by defining the discretization equation system, the super

notation, the variable, and index information. As a final step, a new equa-

tion system is created. The original model equation system is added together

with the previously defined transformation. When the equation system is

loaded for evaluation or optimization, MOSAIC automatically applies the

discretization equation system and the differential expressions are discretized

as defined and auxiliary algebraic equations are added.

3.3 Application examples

3.3.1 Optimization in MOSAIC

3.3.1.1 Calculation of chemical equilibrium

The problem of determining the chemical composition of a complex mixture

under chemical equilibrium conditions is a good example for the application

of optimization techniques in chemical engineering. A literature example

can be found in Bracken and McCormick (1968). The reaction conditions

are shown in Figure 3.9. The objective is to calculate the reactor outlet

stream ns with a given input nins , a given temperature (T ) and pressure

(p). Different species (s) are produced by combining the different types of

atomic elements (e). In this example, the monotonic atom is also regarded

as a possible compound.

Implementation in MOSAIC and initial solution Before the opti-

mization can be started, a model of the reactor has to be implemented in


Table 3.1: Gibbs parameter for the different species (T=3500K)

H N O

s gs[−] e = 1 e = 2 e = 3

1 H -10.22 1

2 H2 -21.52 2

3 H2O -38.75 2 1

4 N -10.04 1

5 N2 -29.23 2

6 NH -19.3 1 1

7 NO -28.59 1 1

8 O -14.93 1

9 O2 -31.21 2

10 OH -26.63 1 1

MOSAIC. Based on the second law of thermodynamics, a mixture of chemi-

cal species held at a constant temperature and pressure reaches its chemical

equilibrium when the Gibbs enthalpy (G) is at a minimum.

min(G =NS∑s=1

(ns · μs)) (3.6)

The Gibbs enthalpy can be calculated with the chemical potential (μ) of the

different species. With the assumption of an ideal gas and an ideal mixture,

the chemical potential can be calculated with the following equations:

μs = gs + ln(p · xs) (3.7)

xs = ns∑NSs=1 ns

(3.8)

A certain error can be expected in the results, since the presence of high pres-

sure indicates a non-ideal behavior. For a general formulation, the fugacity

coefficient has to be considered. The values of the dimensionless Gibbs pa-

rameter (gs) can be found in Bracken and McCormick (1968) and are listed

in Table 3.1. To ensure conservation of the elements, a balance for each


element is needed. The same number of elements in the feed has to leave

the reactor in the product stream. The parameter as,e indicates the number

of element atoms (e) in the specie (s) and can also be found in Table 3.1.

NS∑s=1

as,e · nins =

NS∑s=1

as,e · ns (3.9)

Equations (3.6)-(3.9) are implemented in MOSAIC in the equation system

28994: chemical equilibrium.moseqs, which can be found in the Ap-

pendix on page 117.

Prior to the optimization, an initial evaluation has to be created. It is

possible to generate feasible initial values by solving a simulation statement

with appropriate design values. For a first calculation, it is assumed, that no

reaction takes places and the composition of the outgoing stream is equal to

the ingoing stream. The design variables are selected as shown in Figure 3.9

and Table 3.1. In MOSAIC, the variable list is stored as 34164: initial

simulation.mosvar.

The solution is stored in a new variable list 34209: initial sim-

ulation result.mosvar. For the initial Gibbs free enthalpy a value of

G = −45.96J is calculated.

Optimization statement The full optimization statement contains three

mandatory components. The objective, the variable which as to be mini-

mized (G). The equality constraints, which are summarized in the equation

system 28994: chemical equilibrium.moseqs. And the variable bound-

aries, which are important for the molar fraction (xs) and the mole amounts

(ns).


Editors Evaluate Analysis Optimal exp. Design Measurements Documentation ExtrasOptimization

Constraints OptimizeVariable

Save AsSaveNewSearchOpen34209: initial simulation result.mosvarVar Specs

Optimization Variables

NSPC Variable N... Initial Lower Bou... Upper Bou... Integer

e0 1.0E-7 1.0E-7 5.0

e0 1.0E-7 1.0E-7 5.0

e0 1.0 1.0E-7 5.0

e0 1.0E-7 1.0E-7 5.0

e0 1.0E-7 1.0E-7 5.0

e0 0.5 1.0E-7 5.0

Objective Variables

NSPC Variable N... Lower Bou... Upper Bou...

e0 -1.0E9 0.0

> >

< <

> >

< <

< <

> >

Design Variables

NSPC Variable N... Value

e0 1.0

e0 0.0

e0 0.0

e0 1 0

Iteration Variables

NSPC Variable N... Initial Lower Bou... Upper Bou...

e0 0.0 -1.0E9 1.0E9

e0 0.0 -1.0E9 1.0E9

e0 0.0 -1.0E9 1.0E9

e0 0.0 -1.0E9 1.0E9

n - amount of component (mol) Indices s - species

e[0]28994

e0

Name Space:

Figure 3.10: Specification of the optimization statement in MOSAIC - Vari-ables

Minimize: G

Subject to: G =

NS∑s=1

(ns · μs)

μs = gs + ln(p · xs)xs =

ns∑NSs=1 ns

0 =

NS∑s=1

as,e · ns −NS∑s=1

as,e · nins

0 ≤ xs ≤ 1

0 ≤ ns

The first step from simulation to optimization is performed by loading the

evaluation file into the optimization tab. All equations from the simula-

tion are declared and displayed as equality constraints as the screenshot

in Figure 6.1 (Appendix) shows. In a variable specification panel (Figure

3.10), designed for the optimization task, the missing information is speci-


fied. When loaded, the variables contain the results and the specifications

of the initial solution 34209: initial simulation result.mosvar. The

objective variable has to be selected from the list of iteration variables. For

the simulation, the degree of freedom has to be zero and the design variables

are still set accordingly. Optimization only works with a degree of freedom,

which is greater than zero. Therefore, a number of design variables have to

be declared as optimization variables, which the optimizer is allowed to mod-

ify. In this case, the Gibbs enthalpy (G) has to be minimized by changing

the outgoing mole quantities (ns) and the variables are selected accordingly.

The variable boundaries are also specified in this panel.

Following this step, the optimization statement is completed in MOSAIC.

Two options are available to run the optimization. It is possible to create a

code for the local execution, e.g. in Matlab (see Appendix, Figure 6.2), or

the NEOS server can be used to run the optimization on their computer clus-

ters (see Appendix, Figures 6.3 - 6.5). In both cases the variable results of

the optimization can be imported into MOSAIC for further use in MOSAIC

(see Appendix, Figure 6.6). Different local and global optimizer algorithm

have been used to minimize the Gibbs enthalpy. The different results are

listed in Figure 3.2, including the initial values and the results obtained

from Bracken and McCormick (1968). Both local (CONOPT, IPOPT) and

global (BARON) optimizers have been able to solve this problem with iden-

tical initial values. Compared to the published literature example, a slight

difference can be observed, which is mainly caused by rounding errors and

unit conversions.


Table 3.2: Solutions of different optimizer

Initial

Brackenand Mc-Cormick(1968)

CONOPT IPOPT BARON

G -45.96 -47.76 -48.80 -48.80 -48.80

H xs=1 0 0.0248 0.02427537 0.02427537 0.0242754

H2 xs=2 0.5 0.0901 0.08849933 0.08849933 0.08849931

H2O xs=3 0 0.4779 0.48153308 0.48153308 0.48153299

N xs=4 0 0.0009 7.8667E-4 7.8667E-4 7.8667E-4

N2 xs=5 0.25 0.2962 0.29713049 0.29713049 0.29713047

NH xs=6 0 0.0004 3.7291E-4 3.7291E-4 3.7292E-4

NO xs=7 0 0.0167 0.01602309 0.01602309 0.01602309

O xs=8 0 0.0110 0.01069643 0.01069643 0.01069644

O2 xs=9 0.25 0.0228 0.02250842 0.02250842 0.02250838

OH xs=10 0 0.0591 0.05817422 0.05817422 0.05817434

3.3.1.2 Optimal control of a batch reactor

Optimal control is a main field of dynamic optimization. The control of a

batch reaction is a good application area and is used to optimize the reaction

parameter to reach a certain objective, e.g. product quality. Two cases with

different objective functions are demonstrated. First, the reactor tempera-

ture trajectory is optimized to maximize the product concentration after a

certain total reaction time. In the second example, the overall reaction time

is minimized to reach a user-defined product concentration.

As a demonstration case, the batch reactor model available in Biegler

(2011) is used and implemented in MOSAIC. The system has three compo-

nents and two reactions, as outlined in Figure 3.11. Component A reacts

to Product B, which reacts to the unwanted side product C. The reactor

temperature (T ) can be manipulated and has an impact on the reactions.

A set of differential algebraic equations describes the system, which is

implemented as 10264: Biegler DAE.moseqs. The index k is used to


Figure 3.11: Batch reactor temperature control (Biegler, 2011)

number the components (A: k = 1, B: k = 2, C: k = 3) and the full notation

is available in Table 6.1.4 on page 105.

Equation System 10264: Biegler DAE.moseqs

Notation 10260: Biegler control.mosnot

Description: A dynamic batch reactor model with three components and

two reactions. Component A reacts to B, which is the wanted product.

In a second reaction, component B reacts to the side product C.

Equation 10261: component a.mosequ

Dynamic component balance for component A (k=1)

dxk=1

dt= −kr=1 · exp(−Er=1

R · T ) · xk=1 (3.10)

Equation 10262: component b.mosequ

Dynamic component balance for component B (k=2)

dxk=2

dt= kr=1 · exp(−Er=1

R · T ) · xk=1 − kr=2 · exp(−Er=2

R · T ) · xk=2 (3.11)

Equation 10263: sum equation.mosequ


Sum equation to calculate component C (k=3)

NK∑k=1

xk = 1 (3.12)

Equations 3.10 and 3.11 are dynamic molar component balances in which

the total number of moles is assumed to be constant. Component 3 is

calculated with a sum equation in Equation 3.12. The initial solution with

a constant temperature of T = 400K and the initial values xk=1|t=0 = 1

and xk=2|t=0 = 0 is plotted in Figure 3.12. The full list of design values is

provided in the Appendix in Table 6.27. All the design variable values and

the initial values are used for the next calculations.

As expected, the reactant A (xk=1) reacts with the product B (xk=2),

which partially reacts to side product C (xk=3). By increasing the reaction

temperature, both reactions are accelerated, and there is an obvious conflict

in terms of maximizing the product yield and minimizing the generation of

the side product.

0 10 20 30300

350

400

450

t (h)

T(K

)

0 10 20 300

0.2

0.4

0.6

0.8

1

t (h)

x(m

ol/mol)

xk=1xk=2xk=3

Figure 3.12: Initial solution with a constant temperature of T = 400K

A larger number of optimization platforms do not support differential


equations. Thereby, in order to use state of the art optimizing tools, it

is useful to be able to discretize the differential equations to nonlinear ap-

proximations. Different discretization methods are possible. In this case,

an orthogonal collocation on finite elements is applied as a higher-order ap-

proximation. Since the focus is on optimization, the possibility to use the

transformation feature is not considered and the discretization is directly

applied to the model equations. Nonetheless, it is possible to combine the

transformation for the discretization of the differential equations and the

optimization feature. A corresponding example is presented in the next sec-

tion. The fully discretized equation system is implemented in MOSAIC as

10315: Biegler Batch.moseqs.

Equation System 10315: Biegler Batch.moseqs


Description: A dynamic batch reactor model with three components

and two reactions. Component A reacts to B, which is the wanted

product. In a second reaction, component B reacts to the side product

C. Discretized with orthogonal collocation on finite elements.

Equation 10310: component a.mosequ

Dynamic component balance for component A (k=1)

NJ∑j=0

aj,c · xc=j,i,k=1 = (−kr=1 · exp(− Er=1

R · Ti) · xi,c,k=1) · hi (3.13)

Equation 10311: component b.mosequ

Dynamic component balance for component B (k=2)

NJ∑j=0

aj,c · xc=j,i,k=2 = (kr=1 · exp(− Er=1

R · Ti) · xi,c,k=1

−kr=2 · exp(− Er=2

R · Ti) · xi,c,k=2) · hi

(3.14)



Sum equation to calculate component C (k=3)

0 = (1−NK∑k=1

xi,c,k) · hi (3.15)

Equation 10313: continuity condition.mosequ

Continuity condition for the mole fractions

xc=3,i−1,k = xc=0,i,k (3.16)

Equation 10314: time constrain.mosequ

Auxiliary calculation of the actual time value for each interval, based on

the time steps

ti = ti−1 +hi

3600(3.17)

The time horizon is divided into a discrete number of time intervals (i), where

the system is described with higher-order approximations. The differential

equations 3.10 are 3.11 reformulated into equations 3.13 and 3.14. Equation

3.12 is rewritten with additional indices to extend the use for each collocation

point (c), in each element (i). Additional auxiliary equations to ensure the

continuity between the intervals (Equation 3.16) and the calculation of the

total time in hours (Equation 3.17) are added.

The first objective is the maximization of the product concentration

(xk=2) after 105 seconds. An additional equation is needed, in order to

convert the maximization to a minimization statement.

Equation System 36443: Biegler Batch optimization.moseqs


Description: Discretized dynamic batch reactor together with the objec-


tive function.

Connected Equation System: 10315: Biegler Batch.moseqs (Connector:

-, Transformation: -)

Equation 10319: objective function.mosequ

Objective value calculation, transformition from maximization to mini-

mization of the product concentration (Component B, k=2) at the end

of the last time interval

φ = −xc=3,i=50,k=2 (3.18)

Therefore, a new equation system is created which contains the dis-

cretized model equation system and the objective function.

The optimization problem can now be stated and summarized as follows:

Minimize: φ

Subject to: 36443: Biegler Batch optimization.moseqs

300 ≤ Ti ≤ 450 K

0 ≤ xc,i,k ≤ 1

First, the equation system 36443: Biegler Batch optimization.moseqs

is selected as a collection of equality constraints. In the next step (Appendix,

Figure 6.7), φ is selected for minimization and the temperatures of the in-

tervals (Ti) are marked for the optimization. The additional design values

can be found in Table 6.27.


0 10 20 30300

350

400

450

t (h)

T(K

)

0 10 20 300

0.2

0.4

0.6

0.8

1

t (h)

x(m

ol/mol)

xk=1xk=2xk=3

Figure 3.13: Maximized product with optimized temperature profile andconstant time step intervals

The GAMS code is generated by MOSAIC and the NEOS server is used

to find the solution, which is then reimported into MOSAIC. The resulting

temperature control profile and the product mole fraction are shown in Fig-

ure 3.13. In the beginning of the reaction, the temperature is set to 395.06K.

In order to suppress side reaction, the temperature is decreased during the

next control steps. After 105 seconds, the product concentration reaches a

mole fraction of 0.968molmol .

To demonstrate the flexibility of the modular optimization feature, the

statement is reformulated to minimize the total reaction time with a product

fraction of 0.96molmol .

Minimize: ti=50

Subject to: 36443: Biegler Batch optimization.moseqs

300 ≤ Ti ≤ 450 K

100 ≤ hi ≤ 3000 s

0.96 ≤ xc=3,i=50,k=2 ≤ 1

0 ≤ xc �=3,i �=50,k �=2 ≤ 1

The equality constraints can be reused but the variable specification has to


be changed (Appendix, Figure 6.8). In this case, the interval temperature Ti

and the interval length hi can be optimized to minimize the end time ti=50.

0 5 10 15 20300

350

400

450

t (h)

T(K

)

0 5 10 15 200

0.2

0.4

0.6

0.8

1

t (h)

x(m

ol/mol)

xk=1xk=2xk=3

Figure 3.14: Minimized batch time with optimized temperature profile andvariable time step intervals

To ensure final product concentration, the lower bound of xc=3,i=50,k=2 is

set accordingly.

The optimized temperature profile as well as the resulting product con-

centration is plotted in Figure 3.14. For the overall reaction time, a value

of 0.58 · 105 seconds is calculated. The temperature profile is similar to the

previous example, with the difference of smaller time steps in the beginning

of the reaction and larger time steps at the end. Through this, a better

approximation of a high order control trajectory is achieved.


In this section, the application possibilities of the modular discretization

are demonstrated with the help of an example from the literature. First,

two discretization methods and their correct implementation in MOSAIC as

common equation systems are explained.

By applying them to a dynamic model of a bio-reactor, it is shown how

differential algebraic equation systems are transformed into nonlinear equa-


tion systems. The advantages of the modular storage are demonstrated by

switching between the two different discretization methods. A first-order

discretization is done with the implicit Euler method and for a better ap-

proximation of the solution, then a third order orthogonal collocation on

finite elements is applied afterwards. The original model is not altered dur-

ing the whole process and is preserved in the original form.

The simulation results are compared and the reuse character is empha-

sized by reusing the orthogonal collocation method and extending it with a

stepsize control. Furthermore, the combination of the discretization and the

optimization interface is demonstrated and highlighted.

3.3.2.1 Example of discretization methods in MOSAIC

The discretization methods are stored as a standard differential algebraic

equation system in MOSAIC. Since the equation systems are not linked to

any specific application, they can be reused and reapplied as needed.

Implicit Euler One of the common discretization methods is the implicit

Euler approach. The implementation in MOSAIC can be done in a straight-

forward way with one mandatory and one auxiliary equation.

Equation System 32049: implicit euler.moseqs

Notation 32005: discretization.mosnot

Description:

Equation 32042: implicit.mosequ

implicit euler, main expression

dx

dy=

xk − xk−1

hk(3.19)

Equation 32047: independent variable.mosequ

Auxillary equation for the independent variable calculation, depending


on the step size

yk = yk−1 + hk (3.20)

Equation 3.19 is the expression for the actual discretization, where the

differential term is described as a finite difference. When the equation is

applied as a transformation, the state variables on the right-hand side will

be extended with the index k for the discretization element number. The re-

sulting equations will thus be of the following form, representing the implicit

Euler method:

xk − xk−1

hk= f(yk, xk)

The expression for the explicit Euler could be described by shifting the

indices of the finite difference one position forward. The resulting system

would have the following form:

xk+1 − xkhk

= f(yk, xk)

In order to calculate the independent variable (y), the different steps of the

independent variable are summed up in Equation 3.20.

Orthogonal collocation on finite elements The orthogonal colloca-

tion on finite elements involves a more complex method. Two mandatory

and one auxiliary equations are combined to create a generic third order

implementation in MOSAIC. The roots of Radau polynomials are used as

described in Biegler (2010, p. 292).

Equation System 32017: Orthogonal collocation on finite ele-

ments.moseqs



Description:

Equation 32008: main expression.mosequ

Orthogonal collocation on finite elements, main expression

dx

dy=

1

hk·NJ∑j=0

aj,c · xc=j,k (3.21)

Equation 32012: continuity expression.mosequ

Continuity equation as connection between the intervals

xc=3,k = xc=0,k+1 (3.22)

Equation 32009: independent variable.mosequ

Auxillary equation for the independent variable calculation, depending

on the step size

yk,c = yk−1,c=3 + hc · hk (3.23)

Equation 3.21 is the main expression for the orthogonal collocation. It

describes a matrix-vector multiplication, where the collocation matrix is

multiplied with the state vector of each finite element. The elements are

connected with the continuity condition in Equation 3.22. The last colloca-

tion point (c = 3) of the element has to be the initial value (c = 0) of the

next element. Equation 3.23 is added to calculate the independent variables

at the collocation points in the different elements, where hk is the step size

of the element, and k and hc are the bases of the collocation points.

3.3.2.2 Application on a semi-continuous bioreactor

Different scenarios for the use of the discretization feature are imaginable.

In this example, it is applied to a differential algebraic equation system of a


,,

Figure 3.15: Semi-continuous fermenter (Asprey and Macchietto, 2002)

bio-semi-batch reactor, found in Asprey and Macchietto (2002). In Figure

3.15, a draft of the system is given, which is a common benchmark model

for optimal control and optimal design of experiments, such as in Barz et al.

(2010). The biomass concentration (xB), the substrate concentration (xS)

and the rate (r) are calculated based on their initial values, the dilution

factor (u) and the substrate feed concentration (xSF ) of the feed. In the next

step, two discretization equation systems are applied to the model equations

and the results are compared.

Original equation system The original model of the system was im-

plemented in MOSAIC based on the equations described by Asprey and

Macchietto (2002). Only minor changes had to be done to improve the com-

prehensibility of the notation. A set of three equations is needed to describe

the semi-continuous fermentation of baker’s yeast. The model and all equa-

tions are shown in the following equation system.

Equation System 2327: An Engineering Example.moseqs

Notation 2323: Asprey.mosnot


Description:

Equation 2324: Biomas Concentration.mosequ

Biomas concentration

dxB

dt= (r − u− θi=4) · xB (3.24)

Equation 2325: Substrate Concentration.mosequ

Substrate concentration

dxS

dt= −r · xB

θi=3+ u · (xSF − xS) (3.25)

Equation 2326: Rate.mosequ

Rate

r =θi=1 · xSθi=2 + xS

(3.26)

All used design and initial values needed for the solution of the model,

are listed in Table 6.26. Different tools could be used for the solution of

the direct exported DAE system, e.g. Matlab, gPROMS, and BzzMath.

The solution of gPROMS will later be compared with the results of the

discretized equation systems.

Discretization with the implicit Euler method As a first step, the

implicit Euler method is used to transform and discretize the DAE equa-

tion system to an NLE system. For this purpose, a transformation has to

be specified in MOSAIC. It contains the needed information to transform

the differential expressions of one independent variable. The structure of

the resulting equation system is displayed in Figure 3.16. The original equa-

tion system 2327: An Engineering Example is added to the final equation

system 32066: Asprey, implicit euler. While doing so, the transfor-

mation 32050: Asprey, implicit euler method is given. It contains


Figure 3.16: Final equation system after transformation with 32050: Asprey,implicit euler method.mostra

the name of the discretization equation system to use and the dependent

variable, in this case 32049: implicit euler and t. The dependent vari-

ables xB and xS are automatically identified by MOSAIC. Both occur in

a differential operator in Equations 3.24 and 3.25. Since r is an additional

dependent variable, that only occurs in algebraic expressions, it has to be

added to the list of additional dependent variables. When the equations

are parsed, MOSAIC applies this information and creates the following dis-

cretized model equations.

Equation System 32066: Asprey, implicit euler.moseqs


Description: The asprey model, discretized with the implicit euler

method

Equation 3.24, discretized with Equation 3.19

xBk − xBk−1

hk= (rk − u− θi=4) · xBk (3.27)


xSk − xSk−1

hk= −rk · xBk

θi=3+ u · (xSF − xSk ) (3.28)


Figure 3.17: Final equation system after transformation with 32027: Asprey,orthogonal collocation.mostra

Equation 3.26, discrete algebraic

rk =θi=1 · xSkθi=2 + xSk

(3.29)

Equation 3.20, applied on Notation 2323: Asprey.mosnot

tk = tk−1 + hk (3.30)

The resulting equations are the product of the original equation system

and the implicit Euler discretization of the time. Both differential operators

are replaced by the discretization of Equation 3.19. All dependent variables

have an additional index k for the element number. The auxiliary Equation

3.20 for the calculation of the dependent variable is translated and added.

Discretization with the orthogonal collocation on finite elements

To change the used discretization method, a new transformation has to be

defined and applied to the original equation system. Figure 3.17 shows the

new resulting structure. The transformation 32027: Asprey, orthogo-

nal collocation includes the equation system 32017: Orthogonal col-

location on finite elements as discretization and defines t as indepen-

dent variable. When the original equation system 2327: An Engineering


Example is added along with the new transformation into the new equa-

tion system 32028: Asprey, orthogonal collocation on finite el-

ements, MOSAIC creates the following set of equations.

Equation System 32028: Asprey, orthogonal collocation on finite ele-

ments.moseqs


Description: Discretized model with orthogonal collocation on finite el-

ements


1

hk·NJ∑j=0

aj,c · xBc=j,k = (rc,k − u− θi=4) · xBc,k (3.31)


1

hk·NJ∑j=0

aj,c · xSc=j,k = −rc,k · xBc,kθi=3

+ u · (xSF − xSc,k) (3.32)


rc,k =θi=1 · xSc,kθi=2 + xSc,k

(3.33)


xBc=3,k = xBc=0,k+1 (3.34)

xSc=3,k = xSc=0,k+1 (3.35)

rc=3,k = rc=0,k+1 (3.36)


tk,c = tk−1,c=3 + hc · hk (3.37)


0 5 101

2

3

4

5

t (h)

xB(g/l)

0 5 100

0.05

0.1

0.15

0.2

t (h)xS(g/l)

gPROMSImpl. eulerOrth. coll.

0 5 100.1

0.2

0.3

0.4

0.5

t (h)

r(1/h)

Figure 3.18: Result of the different discretization methods

As in the previous case, the differential operators in Equations 3.24 and

3.25 are replaced by the specified discretization expression, which is a sum

expression. The indices for the finite element (k) and the collocation point

(c) are added to the dependent variables in all equations. For this dis-

cretization method, a continuity equation was specified and is added for

each dependent variable (Equations 3.34 - 3.36). The time t is the de-

pendent variable and is calculated for each collocation point in each finite

element with Equation 3.37.

Solution of the different methods In Figure 3.18, the different solu-

tions are plotted for the state variables xB, xS , and r for a simulation time

between 0 and 10 hours. The solution of the original differential algebraic

model with the default solver of gPROMS and a step size control are used

as benchmarks to validate the user-defined discretization methods. For the

implicit Euler and the orthogonal collocation method, the step size was fixed

to one hour.

Both methods are capable of approximating the solution, but have severe

problems with the first step. While the orthogonal collocation has a very

high accuracy for the following steps, the implicit Euler shows a constant


offset. One solution strategy would be to use a higher order discretization

method, e.g. a fifth-order collocation on finite elements. Another approach

is a step size control mechanism, which is demonstrated in the next section.

3.3.2.3 Introduction of a step size control mechanism

The plot in Figure 3.18 shows a significant drop in the substrate concentra-

tion (xS) and the rate (r) in the first minutes of the simulation. A higher

error in the used solution methods with constant step-size can be observed.

With a variable step-size, the accuracy could be improved by reducing the

step-size where needed. Less difficult areas can be solved with a higher step

size, as shown in Cruz Bournazou et al. (2011); Logsdon and Biegler (1989).

This technique is not limited to time dependent systems. The accuracy of

non equilibrium rectification column models (Fillinger, 2013) could be in-

creased, by adjusting the height of a separation unit over the height of the

column.

The combination of the discretization and the optimization interface

is demonstrated by using an optimizer to solve the model of the semi-

continuous reactor (Equation System 2327: An Engineering Example-

.moseqs) and minimizing the approximation error. To begin with, the ex-

isting discretization method is reused and extended with auxiliary equations

for the calculation of a penalty function. This new discretization equation

system is then applied with a transformation to the original model. By

reusing the results of the previous simulation as a consistent starting point,

the optimization statement is formulated.

The first step is the definition of a lower order approximation equation.

Equation 3.38 is a linear approximation based on the solution of the first

and third collocation points. xk,c=3,e=1 is a relative error weighted with

xk,c=3. The error is zero in case of a linear step and increase proportion-

ally to the degree of nonlinearity. Along with the equation system 32017:

Orthogonal collocation on finite elements.moseqs, it represents the

following enhanced discretization equation system.


Equation System 32821: Orthogonal collocation on finite elements step

size error.moseqs


Description: Orthogonal collocation with step size error

Connected Equation System: 32017: Orthogonal collocation on finite

elements.moseqs (Connector: -, Transformation: -)

Equation 32979: numerical error linear gradient.mosequ

Nummerical error between linear approximation and orthogonal collo-

cation calcuation

xk,c=3,e=1 · xk,c=3 =

((xk,c=3 − xk,c=1

hc=3 − hc=1− xk,c=3 − xk,c=0

hc=3

)2)0.5

(3.38)

Figure 3.19 shows the structure of the final equation system, which can

be used for the optimization. The general discretization equation system

32017: Orthogonal collocation on finite element is reused together

with the approximation 32979: numerical error linear gradient to

compose the new discretization equation system 32821: Orthogonal col-

location on finite elements step size error.

By applying a new transformation to the initial model, an approximation

calculation is added for each dependent variable. One additional equation

is needed to calculate the overall error between the linear approximations

and the actual results. This is done with Equation 3.49, resulting in the

following equation system, created by MOSAIC.

Equation System 32823: Asprey, orthogonal collocation on finite ele-

ments with step size error.moseqs


Figure 3.19: Final equation system with additional equations for a step sizecontrol


Description: Asprey, discretized with orthogonal collocation and step

size error


1

hk·NJ∑j=0

aj,c · xBc=j,k = (rc,k − u− θi=4) · xBc,k (3.39)


1

hk·NJ∑j=0

aj,c · xSc=j,k = −rc,k · xBc,kθi=3

+ u · (xSF − xSc,k) (3.40)


rc,k =θi=1 · xSc,kθi=2 + xSc,k

(3.41)



xBc=3,k = xBc=0,k+1 (3.42)

xSc=3,k = xSc=0,k+1 (3.43)

rc=3,k = rc=0,k+1 (3.44)


tk,c = tk−1,c=3 + hc · hk (3.45)


xBk,c=3,e=1 · xBk,c=3 = ((xBk,c=3 − xBk,c=1

hc=3 − hc=1− xBk,c=3 − xBk,c=0

hc=3)2)0.5 (3.46)

xSk,c=3,e=1 · xSk,c=3 = ((xSk,c=3 − xSk,c=1

hc=3 − hc=1− xSk,c=3 − xSk,c=0

hc=3)2)0.5 (3.47)

rk,c=3,e=1 · rk,c=3 = ((rk,c=3 − rk,c=1

hc=3 − hc=1− rk,c=3 − rk,c=0

hc=3)2)0.5 (3.48)

Equation 32884: total error asprey.mosequ

Total error

θe=1 =NK∑k=1

rk,c=3,e=1 + xBk,c=3,e=1 + xSk,c=3,e=1 (3.49)

It is important to see the difference between the conventional way of

hard-coding the equation system above, as it has to be done to solve it in

optimization software as GAMS and the new way in MOSAIC to reach the

same set of equations. In MOSAIC, all used elements are preserved in their

original form and are step by step extended and transformed by reusing and

creating extended equation systems.


The final optimization statement is specified in MOSAIC as follows.

Minimize: θe=1

Subject to: 32823: Asprey, orthogonal collocation on

finite elements with step size error.moseqs

0 ≤ xSk,c ≤ 1

0 ≤ xBk,c ≤ 1

0.1 ≤ hk ≤ 2

As demonstrated in the previous section, the equality constraints are de-

fined on the basis of the model equation system. The objective function,

the optimization variables and the variable boundaries are specified in the

variable panel. In this case, the sum of the linear approximation error θe=1

is minimized by optimizing the size of the time steps hk. The results of the

previous simulation can be used as an initial starting point for the optimiza-

tion. By using GAMS and the NEOS server, different optimizers were tested

and the results for the rate (r), including the final stepsizes, are illustrated

in Figure 3.20. The solution with a constant step size has an error of 1.781.

By shortening the first, third, and fourth steps, the local optimizer SNOPT

reduces the error down to 0.745. The global optimizer BARON reduces it

even further by setting the first steps to the lower boundary of 0.1h.


0 1 2 3 4 5 6 7 8 9 100.1

0.2

0.3

0.4

0.5Constant step size

t (h)

r(1/h)

1 2 3 4 5 6 7 8 9 100

0.5

1

1.5

2θe=1 = 1.781

Constant step size

step number k

hk(h)

0 1 2 3 4 5 6 7 8 9 100.1

0.2

0.3

0.4

0.5Variable step size with SNOPT

t (h)

r(1/h)

1 2 3 4 5 6 7 8 9 100

0.5

1

1.5

2θe=1 = 0.745

Variable step size with SNOPT

step number k

hk(h)

0 1 2 3 4 5 6 7 8 9 100.1

0.2

0.3

0.4

0.5Variable step size with BARON

t (h)

r(1/h)

1 2 3 4 5 6 7 8 9 100

0.5

1

1.5

2θe=1 = 0.695

Variable step size with BARON

step number k

hk(h)

Figure 3.20: Simulation results with a variable step size

Chapter 4

Assistance and

decomposition concepts

4.1 Concepts

The formulation of process models for simulation and optimization neces-

sitates experience and advanced knowledge of available solution methods.

Different software tools offer different methods for analyzing the validity of

the model structure and decomposing the system for a more efficient solu-

tion. The access to these implemented methods is limited for the user.

Solver algorithm

Preconditioning and analysis

Status report

Software user interface

Figure 4.1: Limited access of user to model structure knowledge

83

84 CHAPTER 4. ASSISTANCE AND DECOMPOSITION CONCEPTS

Solver algorithmAnalysis interface

and derived preconditioning

Status reportSoftware user interface

Figure 4.2: Analysis and derived decomposition algorithm, accessible by theuser

As outlined in Figure 4.1, the user has access to the software user inter-

face to edit and implement the model in a certain way. When the model is

implemented, and the user starts the solution routine, the software starts to

analyze the modeled equations and applies available preconditioning meth-

ods. After the solution algorithm is finished, results are summarized in a

report and are displayed to the user. The user has only a limited access to

the preconditioning and further analyze information.

Complex equation systems in which decomposition methods are manda-

tory can only be solved with a limited selection of solvers, offering these

methods. If this software package is not available, user’s own implementa-

tions of possible methods have to be implemented, which is an additional

effort. In this approach, two changes in the methodology are proposed where

functionalities are moved from the solver to the user. First, the structure

of the equation system is displayed to the user in a graphical and accessible

way, to provide access to structural information. Different decomposition

possibilities of the model have to be highlighted in addition to variables and

equations. Thus, the effects of changing the model and the design variable

specification are visible, so the user can get a better understanding of his/her

model, and take appropriate actions before it is passed to the solver.

Secondly, the limitation to a certain set of software tools, which offer the

4.1. CONCEPTS 85

Figure 4.3: Result of a Dulmage Mendelssohn Decomposition

sole implementation of decomposition methods, has to be broken. By using

the code generation feature of MOSAIC, these techniques can be imple-

mented for any tool, by using the analyze information. Solving algorithms

are proposed to increase the decomposition.

4.1.1 Dulmage-Mendelssohn Decomposition

The Dulmage-Mendelssohn-Decomposition is a method to decompose large

equation systems into smaller equation systems, which can be solved one

after another. Figure 4.3 shows the basic results of a matrix (e.g. a Jacobian

Matrix) where the Dulmage-Mendelsohn Decomposition was applied. The

objective of the algorithm is to create a upper triangular form with a full

diagonal. Matrix entries can thereby be found in the boxes on the diagonal

and the grey area.

If the method is applied on the incidence pattern of a Jacobian matrix,

the boxes represent subsystems, which can be solved separately. A large

equation system can thereby be decomposed to a series of smaller sub equa-

tion systems, which can be solved separately, if the results of the previous

blocks are available. At first, it would be possible to solve the box in the

lower right. Afterwards the results are then available as design variables for


Figure 4.4: Result of a bordered block decomposition

the next block. Since this decomposition is now included in MOSAIC, it can

be used in any code generators. Thus, the Dulmage-Mendelssohn decompo-

sition becomes available for Software like Matlab, which does not offer this

method in its solvers.

Even without the integration in the code generator, this information is

already useful. It reveals, how interwoven an equation system is. Small

blocks are an indicator for decoupled equations, which can be solved sep-

arately. Large blocks are more difficult to solve, since all equations and

variables in the large block have to be solved simultaneously

4.1.2 Bordered block decomposition

As second sorting method, the bordered block decomposition is used and

the result is shown in Figure 4.4. The algorithm has the goal to create a

bordered block lower-triangular form. Single entries are moved to the right

and lower border, in order to minimize the size of the blocks on the diagonal.

If this method is applied on the incidence pattern of a Jacobian matrix, the

lower border (chess pattern) contains the equations and the right border

(dotted) the key variables.

Variables in the right border were moved there, because of their influence

4.1. CONCEPTS 87

Borderequations

Outer iteration

Inner blockequations

Block decomposition

Inner iteration

Figure 4.5: Decompositon of the equation system in an inner and outer loop

on the equation system, in which they prevent a higher degree of decom-

position. In other words, these variables link equations and are causing

dependencies. As example one can think about a cascade of some process

units, which are in series and have no recycle streams. It is possible to solve

one after another, by using the results in the first unit for the solution of the

second and so on. However, this kind of decomposition cannot be applied

if a recycle flow is introduced from the last unit to the first. In an equation

based model of the whole system, the variables of the recycle stream would

be automatically moved to the right border. These kind of key variables

are of special interest and have to be identified. With this information, it is

possible to create an extended solution algorithm where the bordered block

decomposition results are used to realize a tearing on any equation system.

The resulting solution algorithm is illustrated in Figure 4.5. An outer

iteration loop is used for the simultaneously solution of the border equations

and variables. After each iteration step of the outer loop, the inner iteration

loop is started, where the inner equation blocks are solved one after another.

By doing so, a system which has to be solved simultaneously can be

decomposed in single blocks with 1-3 equations and variables.


4.2 Implementation

A very flexible and modular implementation is realized by connecting differ-

ent tools dynamically through the central MOSAIC database. As illustrated

MOSAIC

MOSAICDatabase

MOSAICMOSAIC

EvaluationBzzMathGSLsDACl

OptimizationNEOS

AnalysisAdolcHSL MC79HSL MC33

Figure 4.6: System information exchange via a central data storage

in Figure 4.6, the MOSAIC user can access the numerical solver libraries (e.g.

BzzMath, GSL, sDACl) for the solution (evaluation or optimization) of the

equation system via the MOSAIC database.

Additional analysis tools, such as tools for the visualization of the struc-

ture of the Jacobian incidence matrix, can be accessed by the user as needed.

Communication between and a combination of the different tools becomes

also possible and the obtained information and results of the different tools

can be exchanged and synergies are used.

Specialized methods for the determination of the sparsity structure and

derivative information can be combined with solver algorithms, which oth-

erwise only use numerical approximations for the derivative calculation.

For the incident pattern of the Jacobian pattern, the ADOL-C package

was used (Walther and Griewank, 2012). Highly efficient ordering methods,

which can be applied on the incident pattern where taken from the HSL li-

brary (HSL, 2013). MC79 is used for a Dulmage-Mendelsohn decomposition

and MC33 as implementation for the bordered block sorting. The pattern

information and the sorting results can be accessed by the code generators

and the visualization tools.

4.3. APPLICATION EXAMPLE 89

4.3 Application example

In two use cases, the advantages of the assistance concept is demonstrated.

First, the integration in MOSAIC and the user interaction possibilities are

explained by analyzing the model of a rectification column. In this case

study, the structure is browsed, key variables are identified and approaches

for the solution are derived.

Secondly, the derivation of a solution algorithm for is done for the calcu-

lation of the phase equilibrium with the equation of state PC-SAFT. After

identification of the key variables, the complex equation system is decom-

posed in an outer and inner iteration loop.

4.3.1 User assistance

In most environments, the equation system is only textually represented.

However, better insights and a deeper understanding of the inner connections

of the equations and variables are achieved by visualization of the incidence

pattern of the Jacobian matrix.

This case study uses an equilibrium model of a rectification column:

32089: Full column model with Wilson Model.moseqs. The column

consists of a tray, a reboiler, and a condenser model. The full documen-

tation is available in the Appendix on page 118.

4.3.1.1 Interactive model structure

One of the objectives of the analyze module in MOSAIC is the transition

of the textural analysis of the equation system, to a graphically assisted

system. A screenshot of the unsorted incidence pattern of the full equation

system is visualized in Figure 4.7. Instead of connecting the Jacobian and

code information manually, the user can directly select a single entry in the

pattern. The appropriate equation and variable is automatically displayed

and shown to the user. In Figure 4.7, the Jacobian pattern was not altered

and represents the actual, unsorted equation system structure. An overview

of the sparsity can be obtained.


This kind of visualization is an optimal entry point for further struc-

ture analysis. For a better representation, the next pattern are displayed

independently from the rest of the graphical user interface.

Different ordering algorithms can be applied on the pattern. On the

top in Figure 4.7, the user has the possibility to select between unsorted,

block-diagonal and bordered block diagonal.

In Figure 4.8, the result of the block diagonal ordering algorithm is

displayed. Possible improvements to reduce the size of the equation system

are revealed. Each block could be solve independently, starting with the

block in the lower right.

In this case, the first block calculates the specific enthalpy of the feed

hf,L,n by using the equation 12522: Tray Dippr.moseqs:

hf,L,n

hsca=

∑NCi=1 x

fi · hf,L,ni

hsca

This is completely reasonable, all other variables and parameter are given

and the enthalpy is in this case the only unknown. The result can be used in

the remaining equations. In addition, the user can also use this information

to reformulate the equation system. In any case, MOSAIC offers the pos-

sibility to consider the block information and is able to generate the code

for a decomposed system. In this specific case, the largest block has 101

equations and variables. Compared to the original system, where the full

system has a dimension of 120 equations and variables.

4.3.1.2 Identification of key variables

The bordered block ordering algorithm has the objective to create a lower

diagonal matrix. Disturbing entries in the pattern are moved to the right

(variables) and bottom (equations). Compared to the pattern in Figure 4.8,

a decoupled subsystem is created, as illustrated in Figure 4.9.

Variables which cause a higher complexity and prevent a decomposition

of the system are moved to the right border and are declared as key variables,

due to the influence on the system. The corresponding equations are moved


to the lower border. By providing good initial values for the variables in the

right border, corresponding initial values can be calculated by solving the

decomposed subsystem. The right border reveals the key variables:

Tray: Ttr, yi=1,tr

Condenser: FL,ntr=11, xi=2,tr=11, TC

Reboiler: yi=2,tr=0

With this information, the user knows where it is important to estimate

good initial values. By solving the subsystem where the key variables are

used as design variables, the missing initial values for the solution of the total

system can be even calculated. Due to the nearly perfect triangular structure

of the incident pattern, the equations can be solved step by step. In short,

if the initial values for key variables are estimated well enough, the chance

for the successful solution of the equation system is considerably increased.

Alternatively, the remaining initial values can be calculated automatically,

with a low effort.


Edito

rsEv

alua

teO

ptim

izat

ion

Opt

imal

exp

. Des

ign

Mea

sure

men

tsU

nit E

xpor

tIc

asM

oTD

ocum

enta

tion

Extra

sAn

alys

is

Sens

itivi

tySt

ruct

ure

bord

ered

blo

ck d

iago

nal

bloc

k di

agon

alun

sorte

d

Equa

tion

Varia

ble

e[0

]125

28

Save

As

Save

New

Sear

chO

pen

1253

0: E

valu

atio

n w

ith D

ippr

.mos

eva

Loca

tion

Figure 4.7: Incidence matrix of the equation system 32089: Full column

model with Wilson Model.moseqs


Figure 4.8: Incidence matrix of equation system after Dulmage–Mendelsohndecomposition was applied


Decoupledsubsystem

Border variables

Border equations

Figure 4.9: Incidence matrix of equation system after Dulmage-Mendelsohndecomposition was applied


xLi

Li = xV

iV

i

Outer iteration

p = pcalc

Inner iteration

Equation of state

Figure 4.10: Algorithm for solution of PC-Saft

4.3.2 Identification of solution algorithms

The possibilities of the sorting and decomposition possibilities in MOSAIC

are demonstrated by applying it to the Perturbed-Chain SAFT equation of

state (PC-Saft) (Gross and Sadowski, 2002, 2004). The model can be used

to calculate different mixtures, containing gases, solvents, and polymers. A

Fortran code file can be downloaded on the developer homepage1 with an

implemented solution algorithm as shown in Figure 4.10, which was directly

implemented by the designer of PC-Saft, Joachim Gross.

The algorithm for the calculation of a vapor-liquid phase equilibrium,

at a given temperature and pressure, comprises two iteration loops. As a

starting point, initial values are provided. In an outer iteration, the loop

solves the isofugacity criteria. For each call, an inner iteration loop adjusts

the calculated pressure to the defined and given pressure.

This solution algorithm was hard-coded and is based on the experience of

the developer and users. For using the model in simulation or optimization,

this library has to be connected and called. Problems arise when the use

of external code is not supported and the model has to be implemented

1http://www.th.bci.tu-dortmund.de/de/forschung/pc-saft


equation by equation. This is a difficult task due to a high complexity of the

model and undocumented transcription mistakes in the published papers.

The corrected and equation based implementation in MOSAIC was ini-

tiated in the master’s thesis of Pulido Lopez (2012), and is continued by my

colleague Victor Alejandro Merchan Merchan Restrepo and students. The

resulting equation system for the calculation of a binary mixture and two

phases is added to the Appendix 33506: Corrected PC SAFT.moseqs.

For a simultaneous solution of an equation-based implementation, ini-

tial values for 216 variables are needed. The bordered block decomposition

is now used to automatically generate an outer and an inner iteration al-

gorithm for better decomposition and solution. Parameter for the mixture

of methane and butane were taken from Tihic (2008), and the results were

compared with measurement values from Sage et al. (1940). In the first case,

the system pressure and temperature are calculated for a given concentra-

tions in each phase. Figure 4.11 shows the bordered block permuted inci-

dence matrix of the Jacobian for the equation system 33506: Corrected

PC SAFT.moseqs. The border on the right consists of three variables, namely

ρk=2, ρk=1, T and Equations 4.1-4.3. The remaining 213 equations and vari-

ables for a complete lower triangular matrix and each equation can be solved

individually and decoupled from the rest. It is interesting to see how the

border variables change, depending on the selected design variables. Fig-

ure 4.12 shows the permuted Jacobian matrix, when the temperature and

pressure are given and the concentration is calculated. The border variables

change to

ηk=1, ηk=2, ρk=1, ρk=2,mmk=1,mmk=2 (4.10)

and the corresponding equations to Equations 4.5-4.9. Except for two blocks

with two equations and variables, the inner block can be completely decom-

posed.

The decomposition algorithm decomposes the system as needed to in-

crease the degree of decomposition. In both cases, the system was solved by

using the outer and inner iteration cycles. Instead of 216 initial values, it is


sufficient to give only three variables in the first case and six in the second

case. All other initial variables are set to zero. Discontinuities are avoided

by relaxing the logarithm and fraction for a preliminary solution.

ln(x) → ln(x+ r) (4.11)

1

x→ 1

x+ r(4.12)

For a preliminary solution, r is set to 10−6 and the results are used as

initial values for a second solution with r = 0. This is an option in the

code generator of MOSAIC and is automated. Figure 4.13 is generated with

concentrations, calculated for given pressures and a given temperature.


Figure 4.11: Incidence matrix of PC-Saft, bordered-block-decomposition,temperature and pressure as function of the phase composition, border vari-ables: ρk=2, ρk=1, T

μresi=1,k=2 = (−(xi=1,k=2 · (dahs,redi=1,k=2 + dahc,redi=1,k=2 + dadisp,redi=1,k=2)

+ xi=2,k=2 · (dahs,redi=2,k=2 + dahc,redi=2,k=2 + dadisp,redi=2,k=2))

+ (dahs,redi=1,k=2 + dahc,redi=1,k=2 + dadisp,redi=1,k=2) + ared,resk=2 + (Zk=2 − 1))

(4.1)




(4.2)

Zdispk=2 = (−2 · π · ρk=2 · dI1k=2 · abbv1k=2

− π · ρk=2 ·mmk=2 · [C1k=2 · dI2k=2

+ C2k=2 · ηk=2 · I2k=2] · abbv2k=2) (4.3)


Figure 4.12: Incidence matrix of PC-Saft, bordered-block-decomposition,phase composition as function of pressure and temperature, border variables:ηk=1, ηk=2, ρk=1, ρk=2,mmk=1,mmk=2

ρk=2 = (ηk=2

(π6 · ((xi=1,k=2 ·mi=1 · (di=1)3 + xi=2,k=2 ·mi=2 · (di=2)3))))

(4.4)

ϕi=2,k=1 = (exp(μresi=2,k=1 − ln(Zk=1))) (4.5)

mmk=1 = ((xi=1,k=1 ·mi=1 + xi=2,k=1 ·mi=2)) (4.6)

dgdrhoi=2,k=1 = (1

(1− ηk=1)2+ 3 · (0.5 · di=2) · (ζ2k=1 · (1 + ζ3k=1)

ζ3k=1 · (1− ηk=1)3)

+ (0.5 · di=2)2 · ( (ζ2k=1)

2

(1− ηk=1)4· (4 + 2 · ζ3k=1)

ζ3k=1)) (4.7)




(4.8)

dgdrhoi=2,k=2 = (1

(1− ηk=2)2+ 3 · (0.5 · di=2) · (ζ2k=2 · (1 + ζ3k=2)

ζ3k=2 · (1− ηk=2)3)

+ (0.5 · di=2)2 · ( (ζ2k=2)

2

(1− ηk=2)4· (4 + 2 · ζ3k=2)

ζ3k=2)) (4.9)


0 0.2 0.4 0.6 0.8 10

20

40

60

80

100

120

140PC-Saft; Methane (i = 1) - Butane (i = 2); T = 21.1◦C

xi=1,k (mol/mol)

P(bar)

k = 1k = 2Sage et al., 1940

Figure 4.13: PC-Saft results, x(T,P) and y(T,P) calculated with inner andouter iteration cycle

Chapter 5

Conclusion

Approaches addressing the challenges of model/measurement integration

and management, modularity and user assistance were successfully intro-

duced in the field of chemical process modeling.

In the first chapter the integrated collaboration via databases was dis-

cussed. Data exchange and the sustainable data storage was increased by

introducing a database concept, which can not only be used for model data,

but also measurement and plant data. The database structure is scalable

and can be adapted to the needs of the specific teams. Model and measure-

ment informations can be persistently linked, enabling the user to keep track

of the utilization among each other. Furthermore, a better documentation

was reached by including the history and internal connection of the single

data elements.

In the chapter advanced modularity concepts, it was shown how op-

timization statements and differential equations can be handled to create

equation systems with more flexibility and less restrictions with respect to

the simulation/optimization environment. The user is free to select the tar-

get software. Thereby, it is now possible to switch between simulation and

optimization as needed and to utilize the most appropriate tools available.

For the solution of differential equation systems, a concept for the general,

equation oriented implementation of discretization is presented and imple-

mented for first order systems, where discretization methods are treaded as

101

102 CHAPTER 5. CONCLUSION

modular equation system.

The chapter assistance and decomposition concepts introduces two nov-

elties. First, assistance for the design and solution of the equation system is

now given by an interactive visual presentation of the system structure. Or-

dering and decomposition methods can be applied on the structure informa-

tion. By bringing this information to the user, the time needed to properly

specify and solve the model is reduced. Furthermore, the system structure

information was exploited for model initialization and tool-independent de-

composition methods. A new decomposition algorithm was presented, which

decomposes the system in an inner and outer iteration loop and takes ad-

vantage of the different equation system characteristics.

All methods and concepts are successfully implemented in MOSAIC and

the functionality of the database concept was proved by a worldwide setup

of different servers. In many cases, the implementations go beyond a conven-

tion proof of concept implementation and were used on a larger scale with

a wide range of applications. MOSAIC in general is applied in different

projects, mainly in an academic context with a constantly growing number

of users.

Despite the implementation of further numerical solver and tools, dif-

ferent topics could be considered for further development of MOSAIC and

academic research.

The final step to the cloud could be taken by moving the MOSAIC

database to large scale cloud providers (e.g. Google, Amazon) and to utilize

big data storage concepts.

Current developments, namely the connection of 3D-Plant Management

Systems with modeling information and the further utilization of the CAPE-

OPEN Interface, offers MOSAIC a promising perspective for the future suc-

cess. Integration of code-based third party developments in commercial

software can be difficult. By using an open interface like CAPE-OPEN for

the communication, the need for an direct integration of user models can be

avoided. Experience is needed for the utilization of such an interface and

automated framework would be helpful.

Chapter 6

Appendix

6.1 Notations

6.1.1 28986: chemical equilibrium.mosnot

Base line symbols

G Gibbs free enthalpy (J)

μ Chemial potential (J/mol)

a Number of moles of element in species

g Dimensionless gibbs free enthalpy for constant T,

scaled for the usage with bar and K

n amount of component (mol)

p Pressure (bar)

x Molar fraction (mol/mol)

Superscripts

in ingoing

Indices

103

104 CHAPTER 6. APPENDIX

e 1..NE element

s 1..NS species

6.1.2 32005: discretization.mosnot

Base line symbols

a collocation constant

h step size

k step variable

x dependent state variable

y independent variable

Indices

c 1..NC collocation index

e 1..NE numerical error

j 1..NJ auxiliary collocation index

k 1..NK finite element index

6.1.3 2323: Asprey.mosnot

Base line symbols

J Jacobian

M Mass Matrix

S Sensitivity

θ Parameter

r Rate (1/h)

t Time (h)

u Dilution Factor (1/h)

6.1. NOTATIONS 105

x Concentration (g/l)

Superscripts

B Biomass

L Lower - LU Decomposition

M Mass matrix

S Substrat

U Upper - LU Decomposition

dyn dynamic

p parameter

stat steady state

u control variable

x state variable

Subscripts

F Feed

Indices

c 1..NC collocation points

e 1..NE numerical error

i 1..NP Number of Parameters

j 1..NJ collocation points - auxillary

k 1..NK fine element index

u 1..NU Number of control variables

x 1..NX Number of state variables

6.1.4 10260: Biegler control.mosnot


Base line symbols

E Activation Energy (J/mol)

R Gas constant (J/molK)

T Temperature (K)

a Collocation parameter

h Time step (s)

k Constant (1/s)

t Time (s)

x Mole fraction (mol/mol)

Subscripts

a Component a

b Component b

c Component c

Indices

c 1..NC Number of collocation points

i 1..NI Number of intervals

j 1..NJ Number of collocation points - auxilary

k 1..NK Number of components

r 1..NR Number of reactions

6.1.5 2951: Public notation.mosnot

Base line symbols

A Area [m2]; Parameter 1

B Parameter 2

C Parameter (3)

6.1. NOTATIONS 107

Cp Heat capacity [kJ/K]

D Parameter 4

DeltaT Difference in temperature [K]

Deltap Pressure drop [Pa]

E Parameter 5, Efficiency factor

F Flow [kg/s], [kmol/s], [l/h] Force [N], Parameter 6

G Parameter 7

H Enthalpy [kJ], Henry Coefficient

HU Holdup m: [kg], n: [kmol]

HenryOption Henry option like in Aspen Plus

I Impulse / momentum [kg/ms2], Parameter 8

J Parameter 9

K Equilibrium Factor; Gain factor (Controller)

L Liquid molar flow

M Molar weight [kg/kmol]

NC Number of Components

P Power [kJ]

Q Heat duty [kJ/s]

R Reflux ratio; Ideal gas constant [kJ/kmol K],

Parameter 6 (validity range)

Re Reynoldszahl [-]

T Temperature [K]

U Internal energy [kJ]; Heat transfer coefficient [kW/m2 K];

general manipulated variable

V Volume [m3]; Input value 1

W Physical work [kJ]; Input parameter 2

X Turn over (chemical) [kmol/kmol]; Input parameter 3

Y Input parameter 4


Z Function value

ΔT Difference in temperature [K]

Δp Pressure drop [Pa]

α General value at beginning

ε Void fraction [m3/m3]

η Dynamic viscosity [Pa s], Level of efficiency [Superscript:

eff] [-], regularization function

γ Activity coefficient

ν Stoichiometric coefficient [-]

ω General value at the end

φ Fugacity coefficient

π Mathematical constant pi

ρ Mass density m: [kg/m3], n: [kmol/m3]

σ Surface tension [N/m]

τ Time constant

θ Temperature [◦C]

ξ Mass fraction [kg/kg]

a Specific surface area [m2/m3], Activity

av Auxiliary variable

b Auxiliary Parameter

c Molar concentration [kmol/m3]

cp Specific heat capacity m: [kJ/kg K], n: [kJ/kmol K]

d Diameter [m]

e Control deviation (Controller)

epsilon Void fraction [m3/m3]

eta Dynamic viscosity [Pa s], Level of efficiency [Superscript: eff] [-]

f Factor

g Gravitational constant [m/s2]

6.1. NOTATIONS 109

h Specific Enthalpy m: [kJ/kg], n: [kJ/kmol]

hu Specific holdup m: [kg/kg], n: [kmol/kmol], v: [m3/m3]

i Auxiliary Parameter

j Auxiliary Parameter

k Pre-exponential factor (reaction rate)

l Length [m]

m Mass [kg]

n Number of moles [mol]

nu Stoichiometric coefficient [-]

o Auxiliary Parameter

p Pressure [Pa]

pi Mathematical constant pi

q Specific heat duty [kJ/m3]

r Reactive term m: [kg/s], n: [kmol/s]

(specific: m: [kg/s m3], n: [kmol/s m3])

rho Density m: [kg/m3], n: [kmol/m3]

s Auxiliary Parameter

sigma Surface tension [N/m]

t Time [s]

u Specific internal energy m: [kJ/kg], n: [kJ/kmol]

Manipulated variable (controller)

v Specific volume [m3/kg], molar volume [m3/kmol]

w Velocity [m/s]

x Mole fraction liquid phase [kmol/kmol]

xi Mass fraction [kg/kg]

y Mole fraction vapour phase [kmol/kmol]

z Molar fraction feed stream [kmol/kmol]


Superscripts

A Phase A

B Bottom product

CSpI Component Splitter 1 in Flowsheet

CSpII Component Splitter 2 in Flowsheet

D Destillate

DecI Decanter (LLE) 1

F Film

G Gas

HXI Heat Exchanger 1 in Flowsheet

HXII Heat Exchanger 2 in Flowsheet

HXIII Heat Exchanger 3 in Flowsheet

I Phase 1, Inlet/Outlet I

II Phase 2, Inlet/Outlet II

III Inlet/Outlet III

L Liquid phase

LV Liquid-Vapour

Mix1 Mixer 1 in Flowsheet

Pref Reference pressure

R Reactor

Reflux Reflux stream

S Solid

SpI Splitter 1 in Flowsheet

SpII Splitter 2 in Flowsheet

SpIII Splitter 3 in Flowsheet

T Temperature

TLV Boiling temperature [K]

V Vapour phase

6.1. NOTATIONS 111

α Phase alpha, begin

β Phase beta

ω end

a Parameter 1

act Active

add Addend, additional

avg Average

b Parameter 2

c Parameter 3

cat Catalyst

cc Counter current

cold Cold

cp Heat capacity

crit Critical

d Parameter 4

e Parameter 5

eff Effective

eq Equilibrium

eta Dynamic viscosity

exc Excess

exp Exponent

f Feed

h Enthalpy

hLV Enthalpy of evaporation

hor Horizontal

hot Hot

in Inlet

lam Heat conductivity (lambda)


lev Level

m Mass

max Maximum value (range of validity)

mega x 106

min Minimum value (range of validity)

n Molar

o Reference

out Outlet

p Pressure

pLV Vapour pressure

par Parallel

pilot Pilot control (Vorsteuerung)

red Reduced

rho Density

sat Saturated

sca Scale factor

set Setpoint

sig Surface tension (sigma)

tot Total

v Volumetric

ver Vertical

w General weighting factor

wilson Wilson gE model

Subscripts

B Boiler

C Condenser

D D-Part (Controller: dead time) ; Destillate

6.1. NOTATIONS 113

I I-Part (Controller: integrate)

P P-Part (Controller: propotional)

R Reboiler

cp Heat capacity

d100 DIPPR 100

d101 DIPPR 101

d102 DIPPR 102

d105 DIPPR 105

d106 DIPPR 106

d107 DIPPR 107

eta Dynamic viscosity

h Enthalpy

lam Heat conductivity (lambda)

log Logarithmic

p Pressure

pLV Vapour pressure

pol5 Polynom 5. order

pol6 Polynom 6. order

rho Density

sig Surface tension (sigma)

tray Tray

Indices

i 1..NC Number of components

in 1..NIS Number of inlet streams

j 1..NU Number of units (cascade), Number of components

k 1..NFS Number of film segments

l 1..NC − 1 Number of components, second index


m 1..NFS − 1 Number of film segments, second Index

n 1..NR Number of reactions

nr 1..NR Number of reactions

out 1..NOS Number of outlet streams

s 1..NS Number of Streams (Processes)

t 1..NTSI Number of Taylor series indices

tr 1..NTR Number of trays

6.1.6 8957: pcsaft notation.mosnot

Base line symbols

A Helmhotz free energy

A2 second derivative of A

A3 thrid derivative of A

C1 abbreviation for the compressibility expression c1

C2 abbv c2

I1 Integrals over the radial pair distribution func. of chain molecules

I1xk integral 1 xk

I2 Integrals over the radial pair distribution func. of chain molecules

I2xk integral 2 xk

N total number of molecules

P pressure

R gas constant

T absolute temperature

Z compressibility factor

ε depth of pair potential(interaction energy parameter), J

η packing fraction, dimensionless density

κ Boltzmann constant, J/K

6.1. NOTATIONS 115

μ chemical potential

φ fugacity

π pi

ρ total number density of molecules,1/A

σ segment diameter

ζ abbreviation

ζ0 zeta0

ζ1 zeta 1 xk

ζ2 zeta 2

ζ3 zeta 3

a Residual Helmholtz energy

abbv1 abbreviation 1

abbv2 abbreviation 2

b coefficient depending on the chain length

d Temperature dependent segment diameter of component i

dI1 partial derivative Integral constant 1

dI2 partial derivative Integral constant 2

da partial derivative a residual

dgdrho partial derivative from gij with respect to rho

dgdx partial derivative of the radial distribution function of the hard sphere

with respecto to the mole fraction

dgdz first partial derivative of g ij hs with respect to density

g radial pair distribution function for segments of component i in the hard sphere system

k binary interaction parameter

lnZ Natural log of Z

lng Natural Log of g

m number of segments in a chain of component

mm mean segment number in mixture


n eqs 42,47,59,60

v molar volume

x mole fraction of chains of component

zms 1 minus zeta 3 k

Superscripts

basic eqs 3.17-20

disp dispersion contribution

hc residual contribution of hard-chain system

hs residual contribution of the hard-sphere system

id ideal gas contribution

ln natural logarithmus

mol molar

red reduced quantity

res residual

Subscripts

ij For the kij parameter

xk with respect to mole fraction

Indices

i 1..NC Number of Component

j 1..NS Number of unlike segment molecule

k 1..NK Phase Number

n 1..NN 0 to 3 for zeta n

p 1..NP coefficients ai bi

ui 1..NU max. 2 for the Universal constants

6.2. EQUATION SYSTEM 117

6.2 Equation system

6.2.1 28994: chemical equilibrium.moseqs

Equation System 28994: chemical equilibrium.moseqs

Notation 28986: chemical equilibrium.mosnot

Description: chemical equilibrium calculation


molar balance for each element

NS∑s=1

as,e · nins =

NS∑s=1

as,e · ns (6.1)


outgoing molar fraction

xs =ns∑NSs=1 ns

(6.2)


chemical potential for an ideal gas and constant T

μs = gs + ln(p · xs) (6.3)


Gibbs free energy

G =

NS∑s=1

(ns · μs) (6.4)


6.2.2 32089: Full column model with Wilson Model.moseqs

Equation System 32089: Full column model with Wilson Model.moseqs

Notation 2951: Public notation.mosnot

Description: The basic model is extended with dippr equations for the

vapour pressure and the pure component enthalpy. The specific stream

enthalpy is calculated with ideal mixing.

Connected Equation System: 12522: Tray Dippr.moseqs (Connector: -,

Transformation: -)

Connected Equation System: 32087: Condenser Dippr Full with Wilson

Model.moseqs (Connector: 12607: Condenser.moscon, Transformation:

-)

Connected Equation System: 32088: Reboiler Dippr Full with Wilson

Model.moseqs (Connector: 12609: Reboiler.moscon, Transformation: -)

Function 32032: gamma1.mosfun

γi=1,tr = f(xi=1,tr, xi=2,tr, Da,wilsontr , Db,wilson

tr ) (6.5)


γi=2,tr = f(xi=1,tr, xi=2,tr, Da,wilsontr , Db,wilson

tr ) (6.6)

Function 32084: wilsonparameter1.mosfun

Da,wilsontr = f(vi=1,tr, vi=2,tr, Ttr) (6.7)



Db,wilsontr = f(vi=1,tr, vi=2,tr, Ttr) (6.8)

Function 32086: DIPPR105-mod.-molar spec. volume.mosfun

vi,tr = f(Ttr) (6.9)

6.2.3 12522: Tray Dippr.moseqs

Equation System 12522: Tray Dippr.moseqs


Description: The basic model is extend with dippr equations for the



Connected Equation System: 12527: Tray plain.moseqs (Connector: -,

Transformation: -)

Equation 12521: Enthalpy liquid.mosequ

scaled specific enthalpy of the liquid stream

hL,ntr

hsca=

∑NCi=1 xi,tr · hL,ni,tr

hsca(6.10)

Equation 12526: Enthalpy vapor.mosequ

scaled specific enthalpy of the vapour stream

hV,ntr

hsca=

∑NCi=1 yi,tr · (hL,ni,tr + hLV,ntr,i )

hsca(6.11)

Equation 12589: Enthalpy liquid feed.mosequ


scaled specific enthalpy of the liquid feed

hf,L,n

hsca=

∑NCi=1 x

fi · hf,L,ni

hsca(6.12)

Function 12505: DIPPR101.mosfun

pLVi,tr = f(Ttr) (6.13)

Function 12593: DIPPR106 - Evaporation molar.mosfun

hLV,ni,tr = f(Ttr) (6.14)

Function 12504: Enthalpy DIPPR100.mosfun

hL,f,ni = f(T f ) (6.15)

hL,ni,tr = f(Ttr) (6.16)

6.2.4 12527: Tray plain.moseqs

Equation System 12527: Tray plain.moseqs


Description: Basic model of an equilibrium tray, component properties

are not calculated

Equation 12532: Component balances.mosequ


Component balances

0 = F f,L,ntr · xfi + FL,n

tr+1 · xi,tr+1 + F V,ntr−1 · yi,tr−1 − FL,n

tr · xi,tr − F V,ntr · yi,tr(6.17)

Equation 12533: Energy balance.mosequ

scaled energy balance

0 =

F f,L,ntr · hf,L,n + FL,n

tr+1 · hL,ntr+1 + F V,ntr−1 · hV,ntr−1 − FL,n

tr · hL,ntr − F V,ntr · hV,ntr

hsca

(6.18)

Equation 12534: Isofugacity conditions.mosequ

simple isofugacity conditions

ptr · yi,trpsca

=xi,tr · γi,tr · pLVi,tr

psca(6.19)

Equation 12538: Summation relations liquid phase.mosequ

Sum equation of the liquid phase

1 =

NC∑i=1

xi,tr (6.20)

Equation 12540: Summation relations vapor phase

Sum equation of the vapor phase

1 =

NC∑i=1

yi,tr (6.21)

Equation 12606: Pressure drop.mosequ

Pressure drop of one tray

Δp = ptr−1 − ptr (6.22)


6.2.5 32087: Condenser Dippr Full withWilson Model.moseqs

Equation System 32087: Condenser Dippr Full with Wilson

Model.moseqs


Description: The basic model is extended with dippr equations for the



Connected Equation System: 12517: Condenser Basic.moseqs (Connec-

tor: -, Transformation: -)


specific enthalpy of the liquid stream

hL,nC

hsca=

∑NCi=1 xC,i · hL,nC,i

hsca(6.23)


hL,nC,i = f(TC) (6.24)


pLVC,i = f(TC) (6.25)


γC,i=1 = f(xC,i=1, xC,i=2, Da,wilsonC , Db,wilson

C ) (6.26)



γC,i=2 = f(xC,i=1, xC,i=2, Da,wilsonC , Db,wilson

C ) (6.27)


Da,wilsonC = f(vC,i=1, vC,i=2, TC) (6.28)


Db,wilsonC = f(vC,i=1, vC,i=2, TC) (6.29)


vC,i = f(TC) (6.30)

6.2.6 12517: Condenser Basic.moseqs

Equation System 12517: Condenser Basic.moseqs


Description: A flash unit where the vapour flow rate is set to zero. This

leads to a total condenser. The liquid stream is splitted into a product

and a reflux stream. A reflux ratio can be defined.

Equation 12462: Component balance.mosequ

Component molar balance with two outgoing streams, one for the reflux


and one for the product

0 = F V,D,n · yDi − (FL,nC + FReflux,L,n

C ) · xC,i (6.31)


Energy Balance for a total condenser and two product streams

0 =F V,D,n · hV,D,n − (FL,n

C + FReflux,L,nC ) · hL,nC +QC

hsca(6.32)

Equation 12464: Equilibrium.mosequ

Simplified phase equilibrium

yC,i · pCpsca

=xC,i · pLVC,i · γC,i

psca(6.33)

Equation 12468: Sum equation liquid

Sum equation

NC∑i=1

xC,i = 1 (6.34)

Equation 12469: Sum equation vapour.mosequ

sum equation

NC∑i=1

yC,i = 1 (6.35)

Equation 12605: Reflux ratio.mosequ

The splitter is directly integrated into the condenser

FReflux,L,nC = R · FL,n

C (6.36)


6.2.7 32088: Reboiler Dippr Full with Wilson Model.moseqs

Equation System 32088: Reboiler Dippr Full with Wilson Model.moseqs


Description: The basic model is extend with dippr equations for the



Connected Equation System: 12599: Reboiler plain.moseqs (Connector:

-, Transformation: -)

Equation 12600: Enthalpy vapour.mosequ

specific enthalpy of the vapour stream

hV,nR

hsca=

∑NCi=1 yR,i · (hL,nR,i + hLV,nR,i )

hsca(6.37)


specific enthalpy of the liquid stream

hL,nR

hsca=

∑NCi=1 xR,i · hL,nR,i

hsca(6.38)


hL,nR,i = f(TR) (6.39)


pLVR,i = f(TR) (6.40)



vR,i = f(TR) (6.41)

Function 12593: DIPPR106 - Evaporation molar.mosfun

hLV,nR,i = f(TR) (6.42)


γR,i=1 = f(xR,i=1, xR,i=2, Da,wilsonR , Db,wilson

R ) (6.43)


γR,i=2 = f(xR,i=1, xR,i=2, Da,wilsonR , Db,wilson

R ) (6.44)


Da,wilsonR = f(vR,i=1, vR,i=2, TR) (6.45)


Db,wilsonR = f(vR,i=1, vR,i=2, TR) (6.46)

6.2.8 12599: Reboiler plain.moseqs

Equation System 12599: Reboiler plain.moseqs



Description: A flash drum without any equations for the component

properties.

Equation 12595: Isofugacity-condition.mosequ

simple scaled phase equilibrium

yR,i · pRpsca

=xR,i · pLVR,i · γR,i

psca(6.47)


Energy balance

0 =FL,in,nR · hL,in,nR − FL,n

R · hL,nR − F V,nR · hV,nR +QR

hsca(6.48)

Equation 12596: Component balance.mosequ

Component balance

0 = FL,in,nR · xin,nR,i − FL,n

R · xR,i − F V,nR · yR,i (6.49)

Equation 12597: sum equation liquid.mosequ

sum equation

1 =

NC∑i=1

xR,i (6.50)

Equation 12598: sum equation vapour.mosequ

sum equation

1 =NC∑i=1

yR,i (6.51)


6.2.9 33506: Corrected PC SAFT.moseqs

Equation System 33506: Corrected PC SAFT.moseqs

Notation 8957: pcsaft notation.mosnot

Description: final

Equation 8958: 3 a res.mosequ

residual Helmholtz free energy

ares,redk = ahs,redk + ahc,redk + adisp,redk (6.52)

Equation 8977: 4 a res hch.mosequ

hard-chain reference contribution to the residual free energy

ahc,redk = −NC∑i=1

xi,k · (mi − 1) · ln(ghsi,k) (6.53)

Equation 8983: 5 mean seg.mosequ

mean segment number in the mixture

mmk =

NC∑i=1

xi,k ·mi (6.54)

Equation 8989: 6 ar hs.mosequ

Helmholtz hard-sphere contribution

ahs,redk = mmk · 1

ζ0k· [3 · ζ1k · ζ2k

(1− ζ3k)+

(ζ2k)3

ζ3k · (1− ζ3k)2

+((ζ2k)

3

(ζ3k)2− ζ0k) · ln(1− ζ3k)] (6.55)

Equation 8992: 7 radial dist func hs.mosequ


Radial distribution function of the hard-sphere fluid

ghsi,k =1

(1− ζ3k)+ (0.5 · di) · 3 · ζ2k

(1− ζ3k)2+ (0.5 · di)2 · 2 · (ζ2k)2

(1− ζ3k)3

(6.56)

Equation 8993: 8 zeta 0.mosequ

Zeta 0

ζ0k =π

6· ρk · (

NC∑i=1

xi,k ·mi) (6.57)


Zeta n

ζ1k =π

6· ρk · (

NC∑i=1

xi,k ·mi · di) (6.58)


Zeta 2

ζ2k =π

6· ρk · (

NC∑i=1

xi,k ·mi · (di)2) (6.59)


Zeta 3

ζ3k =π

6· ρk · (

NC∑i=1

xi,k ·mi · (di)3) (6.60)

Equation 8997: 9 temp dep seg diam.mosequ

Temperature dependent segment diameter of component i

di = σi · (1− 0.12 · exp(−3 · εiT)) (6.61)

Equation 8998: 10 a dispersion.mosequ


dispersion Helmholtz free energy contribution

adisp,redk = −2 · π · ρk · I1k · abbv1k − π · ρk ·mmk · C1k · I2k · abbv2k(6.62)

Equation 8999: 11 C1.mosequ

Abbreviation for the compressibility expression

C1k = (1 +mmk · 8 · ηk − 2 · (ηk)2(1− (ηk))4

+(1−mmk) · 20 · ηk − 27 · (ηk)2 + 12 · (ηk)3 − 2 · (ηk)4[(1− ηk) · (2− (ηk))]2

)−1 (6.63)

Equation 9000: 12 abbv1.mosequ

Abbreviation 1

abbv1k =

NC∑i=1

NS∑j=1

xi,k · xi=j,k ·mi ·mi=j · (εi,jT

) · (σi,j)3 (6.64)

Equation 9001: 13 abbv2.mosequ

Abbreviation 2

abbv2k =

NC∑i=1

NS∑j=1

xi,k · xi=j,k ·mi ·mi=j · (εi,jT

)2 · (σi,j)3 (6.65)

Equation 9002: 14 segment diameter.mosequ

Combining rule for sigma

σi,j = 0.5 · (σi + σj) (6.66)

Equation 9004: 16 Int 1.mosequ

Integral 1(eta,mm)

I1k = abasick,p=7 + abasick,p=1 · (ηk) + abasick,p=2 · (ηk)2 + abasick,p=3 · (ηk)3

+abasick,p=4 · (ηk)4 + abasick,p=5 · (ηk)5 + abasick,p=6 · (ηk)6 (6.67)


Equation 9005: 17 Int 2.mosequ

Integral 2 (eta,mm)

I2k = bbasick,p=7 + bbasick,p=1 · (ηk) + bbasick,p=2 · (ηk)2 + bbasick,p=3 · (ηk)3

+bbasick,p=4 · (ηk)4 + bbasick,p=5 · (ηk)5 + bbasick,p=6 · (ηk)6 (6.68)

Equation 9006: 18 ai coeff.mosequ

coefficient ai(mm)

abasick,p = abasicp,ui=0 +mmk − 1

mmk· abasicp,ui=1 +

mmk − 1

mmk· mmk − 2

mmk· abasicp,ui=2

(6.69)

Equation 9007: 19 bi coeff.mosequ

coefficient bi(mm)

bbasick,p = bbasicp,ui=0 +mmk − 1

mmk· bbasicp,ui=1 +

mmk − 1

mmk· mmk − 2

mmk· bbasicp,ui=2

(6.70)

Equation 9008: 20 density molecules.mosequ

number density of molecules

ρk =ηk

(π6 · (∑NCi=1 xi,k ·mi · (di)3))

(6.71)

Equation 9010: 23 pressure.mosequ

pressure N/m2

P = Zk · ρk · κ · T · (10)30 (6.72)

Equation 9011: 24 Z hc plus disp.mosequ

compressibility factor (hs plus hc plus disp)

Zk = 1 + Zhsk + Zhc

k + Zdispk (6.73)


Equation 9012: 25 Z hc.mosequ

Compressibility factor hard-chain

Zhck = −

NC∑i=1

xi,k · (mi − 1) · (( ηkghsi,k

) · dgdrhoi,k) (6.74)

Equation 9013: 26 z hs.mosequ

residual contribution of the hard-sphere fluid

Zhsk = mmk · ( ζ3k

(1− ηk)+

3 · ζ1k · ζ2kζ0k · (1− ηk)2

+(ζ2k)

3 · (3− ζ3k)

ζ0k · (1− ηk)3) (6.75)

Equation 9014: 27 dg droh.mosequ

Partial derivative rho times gi

dgdrhoi,k =1

(1− ηk)2+ 3 · (0.5 · di) · (ζ2k · (1 + ζ3k)

ζ3k · (1− ηk)3)

+(0.5 · di)2 · ( (ζ2k)2

(1− ηk)4· (4 + 2 · ζ3k)

ζ3k) (6.76)

Equation 9016: 28 Z disp.mosequ

Compressibility factor dispersion contribution

Zdispk = −2 · π · ρk · dI1k · abbv1k − π · ρk ·mmk · [C1k · dI2k

+C2k · ηk · I2k] · abbv2k (6.77)

Equation 9116: 31 C2.mosequ

Abbreviation for the compressibility expression

C2k = −(C1k)2 · (mmk · −4 · (ηk)2 + 20 · ηk + 8

(1− (ηk))5

+(1−mmk) · 2 · (ηk)3 + 12 · (ηk)2 − 48 · ηk + 40

((1− ηk) · (2− ηk))3) (6.78)

Equation 9017: 29 d etaI1 d eta.mosequ


partial derivative eta by I1 with respect to eta

dI1k = abasick,p=7 + abasick,p=1 · (2) · (ηk) + abasick,p=2 · (3) · (ηk)2 + abasick,p=3 · (4) · (ηk)3

+abasick,p=4 · (5) · (ηk)4 + abasick,p=5 · (6) · (ηk)5 + abasick,p=6 · (7) · (ηk)6(6.79)

Equation 9018: 30 d etaI2 d eta.mosequ

partial derivative eta I2 with respect to eta

dI2k = bbasick,p=7 + bbasick,p=1 · (2) · (ηk) + bbasick,p=2 · (3) · (ηk)2 + bbasick,p=3 · (4) · (ηk)3

+bbasick,p=4 · (5) · (ηk)4 + bbasick,p=5 · (6) · (ηk)5 + bbasick,p=6 · (7) · (ηk)6(6.80)

Equation 9292: 34 zeta 0 xk.mosequ

abbreviations for derivatives of eq 8 with respect to mole fraction

ζ0xk,i,k =π

6· ρk ·mi (6.81)



ζ1xk,i,k =π

6· ρk ·mi · di (6.82)



ζ2xk,i,k =π

6· ρk ·mi · (di)2 (6.83)



ζ3xk,i,k =π

6· ρk ·mi · (di)3 (6.84)

Equation 9297: 36 d a hs d x k.mosequ


partial derivative of hard-sphere reference contribution with respect to

molar fraction

dahs,redi,k = mi · ahs,redk +mmk · ((−ζ0xk,i,kζ0k

· ahs,redk )+

(3 · (ζ1xk,i,k · ζ2k + ζ1k · ζ2xk,i,k)

(1− ηk)+

3 · ζ1k · ζ2k · ζ3xk,i,k(1− ηk)2

+3 · (ζ2k)2 · ζ2xk,i,kζ3k · (1− ηk)2

+(ζ2k)

3 · ζ3xk,i,k · (3 · ζ3k − 1)

(ζ3k)2 · (1− ηk)3

+((3 · (ζ2k)2 · ζ2xk,i,k · ζ3k − 2 · (ζ2k)3 · ζ3xk,i,k)

(ζ3k)3

−ζ0xk,i,k) · ln(1− ηk) + (ζ0k − (ζ2k)3

(ζ3k)2) · ζ3xk,i,k

(1− ηk))/(ζ0k)) (6.85)

Equation 9299: 38 d a disp d x k.mosequ

Partial derivative of g hs

dadisp,redk,i = −2 · π · ρk · (I1xk,k,i · abbv1k + I1k · abbv1xk,k,i)−π · ρk ·mmk · C1k · (I2xk,k,i · abbv2k + I2k · abbv2xk,k,i)

−π · ρk · (mi · C1k +mmk · C1xk,k,i) · I2k · abbv2k (6.86)

Equation 9300: 32 fug coeff.mosequ

fugacity coefficient

φi,k = exp(μresi,k − ln(Zk)) (6.87)

Equation 9302: 33 chem pot.mosequ

chemical potencial

μresi,k = −

NS∑j=1

xi=j,k · (dahs,redi=j,k + dahc,redi=j,k + dadisp,redi=j,k ) + (dahs,redi,k + dahc,redi,k

+dadisp,redi,k ) + ares,redk + (Zk − 1)

(6.88)


Equation 9539: 39 abbv1 x k.mosequ

Abb. 1 xk

abbv1xk,i,k = 2 ·mi ·NS∑j=1

xi=j,k ·mi=j · (εi,jT

) · (σi,j)3 (6.89)

Equation 9541: 40 abbv2 x k.mosequ

Abb. 2 xk

abbv2xk,i,k = 2 ·mi ·NS∑j=1

xi=j,k ·mi=j · (εi,jT

)2 · (σi,j)3 (6.90)

Equation 9544: 41 C1 xk.mosequ

Abb. for the compressibility expression (molar)

C1xk,i,k = C2k · ζ3xk,i,k − (C1k)2 · (mi · 8 · ηk − 2 · (ηk)2

(1− (ηk))4

−mi · 20 · ηk − 27 · (ηk)2 + 12 · (ηk)3 − 2 · (ηk)4[(1− ηk) · (2− (ηk))]2

) (6.91)

Equation 9545: 42 I1 xk.mosequ

I1(eta,mm) Integral 1 xk

I1xk,i,k = abasicxk,i,k,p=7 + (abasick,p=1 · (ζ3xk,i,k) + abasicxk,i,k,p=1 · (ηk))+(abasick,p=2 · 2 · (ζ3xk,i,k) · (ηk) + abasicxk,i,k,p=2 · (ηk)2)+(abasick,p=3 · 3 · (ζ3xk,i,k) · (ηk)2 + abasicxk,i,k,p=3 · (ηk)3)+(abasick,p=4 · 4 · (ζ3xk,i,k) · (ηk)3 + abasicxk,i,k,p=4 · (ηk)4)+(abasick,p=5 · 5 · (ζ3xk,i,k) · (ηk)4 + abasicxk,i,k,p=5 · (ηk)5)+(abasick,p=6 · 6 · (ζ3xk,i,k) · (ηk)5 + abasicxk,i,k,p=6 · (ηk)6) (6.92)

Equation 9546: 43 I2 xk.mosequ


I2(eta,mm) Integral 2 xk

I2xk,i,k = bbasicxk,i,k,p=7 + (bbasick,p=1 · (ζ3xk,i,k) + bbasicxk,i,k,p=1 · (ηk))+(bbasick,p=2 · 2 · (ζ3xk,i,k) · (ηk) + bbasicxk,i,k,p=2 · (ηk)2)+(bbasick,p=3 · 3 · (ζ3xk,i,k) · (ηk)2 + bbasicxk,i,k,p=3 · (ηk)3)+(bbasick,p=4 · 4 · (ζ3xk,i,k) · (ηk)3 + bbasicxk,i,k,p=4 · (ηk)4)+(bbasick,p=5 · 5 · (ζ3xk,i,k) · (ηk)4 + bbasicxk,i,k,p=5 · (ηk)5)+(bbasick,p=6 · 6 · (ζ3xk,i,k) · (ηk)5 + bbasicxk,i,k,p=6 · (ηk)6) (6.93)

Equation 9547: 44 ai xk.mosequ

coefficient ai,xk

abasicxk,i,k,p = (mi

(mmk)2· abasicp,ui=1 +

mi

(mmk)2· (3− 4

mmk) · abasicp,ui=2) (6.94)

Equation 9548: 45 bi xk.mosequ

coefficient bi,xk

bbasicxk,i,k,p = (mi

(mmk)2· bbasicp,ui=1 +

mi

(mmk)2· (3− 4

mmk) · bbasicp,ui=2) (6.95)

Equation Eq: 9990: 0 phi phi.mosequ

phi-phi crieria for a binary system

xi,k=1 · φi,k=1 = xi,k=2 · φi,k=2 (6.96)


Summation Relation

1 =NC∑i=1

xi,k (6.97)

Equation 20072: 35 NUEVA.mosequ

Partial derivative of hard-chain reference contribution for the first com-


ponent

dahc,redi=1,k =NS∑j=1

xi=j,k · (1−mi=j) · ((ghsi=j,k)−1 · dgdxi=1,j,k)

+(1−mi=1) · ln(ghsi=1,k) (6.98)

Equation 20073: 35 B NUEVA.mosequ

Partial derivative of hard-chain reference contribution for the 2nd com-

ponent

dahc,redi=2,k =

NS∑j=1

xi=j,k · (1−mi=j) · ((ghsi=j,k)−1 · dgdxi=2,j,k)

+(1−mi=2) · ln(ghsi=2,k) (6.99)

Equation 22743: 15 depth pair potential - CORRECTED.mosequ

Combining rule for epsilon ij

εi,j = (εi · εj)0.5 · (1− ki,j) (6.100)

Equation 20075: 37 nueva.mosequ

Partial derivative of g hs

dgdxi,j,k =ζ3xk,i,k

(1− ζ3k)2+ (0.5 · di=j) · ( 3 · ζ2xk,i,k

(1− ζ3k)2+

6 · ζ2k · ζ3xk,i,k(1− ζ3k)3

)

+(0.5 · di=j)2 · (4 · ζ2k · ζ2xk,i,k

(1− ζ3k)3+

6 · (ζ2k)2 · ζ3xk,i,k(1− ζ3k)4

)

(6.101)


6.3 Functions

6.3.1 12504: Enthalpy DIPPR100.mosfun


Mole specific liquid enthalpy based on DIPPR-Equation 100 [kJ/kmol], In-

puts: X as temperature [K], Note: Parameters are mole-based heat-capacity

parameters, results are mole-based enthalpies

Z = f (X) (6.102)

f = AL,h,nd100 · (X − T h,o) +

BL,h,nd100

2· ((X)2 − (T h,o)2) +

CL,h,nd100

3· ((X)3 − (T h,o)3)

(6.103)

+DL,h,n

d100

4· ((X)4 − (T h,o)4) +

EL,h,nd100

5· ((X)5 − (T h,o)5) + hL,o,n

(6.104)

6.3.2 12505: DIPPR101.mosfun


DIPPR-equation 101, commonly used to calculate the vapour pressure

Z = f (X)

f = exp(ApLVd101 +

BpLVd101

X+ CpLV

d101 · ln(X) +DpLVd101 · (X)E

pLVd101 )

6.3.3 12593: DIPPR106 - Evaporation molar.mosfun


DIPPR-equation 106

Z = f (X)

6.3. FUNCTIONS 139

f = ALV,h,nd106 · (1− X

T crit)B

LV,h,nd106 +CLV,h,n

d106 · X

Tcrit+DLV,h,nd106 ·( X

Tcrit )2+ELV,h,n

d106 ·( X

Tcrit )3

6.3.4 32032: gamma1.mosfun


Wilson equation for gamma component 1

γ = f(xi=1, xi=2, D

a,wilson, Db,wilson)

f = exp(−ln

(xi=1 +Da,wilson · xi=2

)+xi=2 · ( Da,wilson

xi=1 +Da,wilson · xi=2− Db,wilson

Db,wilson · xi=1 + xi=2)

)

6.3.5 32058: gamma2.mosfun


Wilson equation for gamma component 2

γ = f(xi=1, xi=2, D

a,wilson, Db,wilson)

f = exp(−ln

(xi=2 +Db,wilson · xi=1

)−xi=1 · ( Da,wilson

xi=1 +Da,wilson · xi=2− Db,wilson

Db,wilson · xi=1 + xi=2)

)

6.3.6 32084: wilsonparameter1.mosfun


Berechnung Parameter Lambda (Dwilson,a) der Wilsongleichung

Da,wilson = f (vi=1, vi=2, T )


f =vi=2

vi=1· exp

(−(Ca,wilson)/(T

)

6.3.7 32085: wilsonparameter2.mosfun


Berechnung Parameter Lambda (Dwilson,b) der Wilsongleichung

Db,wilson = f (vi=1, vi=2, T )

f =vi=1

vi=2· exp

(−(Cb,wilson)/(T

)

6.3.8 32086: DIPPR105 - modified - molar specific volume.mosfun


Liquid molar specific volume [m3/kmol] T as temperature [K], molebased

parameters

v = f (T )

f =(BL,n,rho

d105 )

(1+(1− T

CL,n,rhod105

)(DL,n,rhod105 )

)

AL,n,rhod105

6.4 Connector

6.4.1 12607: Condenser.moscon

Subnotation: 2951: Public notation.mosnot

Supernotation: 2951: Public notation.mosnot

Sub → Super

yDi → yi,tr=NTR with | i → i |pC → ptr=NTR

xC,i → xi,tr=NTR+1 with | i → i |

6.4. CONNECTOR 141

hD,V,n → hV,ntr=NTR

hL,nC → hL,ntr=NTR+1

FD,V,n → F V,ntr=NTR

FL,Reflux,nC → FL,n

tr=NTR+1

6.4.2 12609: Reboiler.moscon

Subnotation: 2951: Public notation.mosnot

Supernotation: 2951: Public notation.mosnot

Sub → Super

FL,in,nR → FL,n

tr=1

xin,nR,i → xi,tr=1 with | i → i |yR,i → yi,tr=0 with | i → i |pR → ptr=0

hV,nR → hV,ntr=0

hL,in,nR → hL,ntr=1

F V,nR → F V,n

tr=0


6.5 Transformation

Table 6.23: 32050: Asprey, implicit euler method.mostra

Description Application of the implicit euler method on the reac-

tor model published in Asprey and Macchietto (2002)

Discretization 32049: implicit euler.moseqs

Super Nota-

tion

2323: Asprey.mosnot

Independent

variable

y → t

Algebraic state

variables

r

Table 6.24: 32027: Asprey, orthogonal collocation.mostra

Description Application of the orthogonal collocation on the reac-

tor model published in Asprey and Macchietto (2002)

Discretization 32017: Orthogonal collocation on finite ele-

ments.moseqs

Super Nota-

tion

2323: Asprey.mosnot

Independent

variable

y → t

Algebraic state

variables

r

6.5. TRANSFORMATION 143

Table 6.25: 32822: Asprey, orthogonal collocation with step size er-ror.mostra

Description Orthogonal collocation on finite elements with step

size error

Discretization 32821: Orthogonal collocation on finite elements step

size error.moseqs

Super Nota-

tion

2323: Asprey.mosnot

Independent

variable

y → t

Algebraic state

variables

r


6.6 Variable lists

Table 6.26: 2334: Inital estimates.mosvar

Design variables

Symbol Value

θi=1 2.0

θi=2 0.5

θi=3 0.5

θi=4 0.4

u 0.1

xSF 15.0

Iteration variables

Symbol Value

r 1/3

State variables

Symbol Value

xB 5.0

xS 0.1

Indices

Symbol Value

i 4

6.6. VARIABLE LISTS 145

Table 6.27: Design variables from 10316: initial solution.mosvar andindex informations

Design variables

Symbol Value

Er=1 41800.0

Er=2 66880.0

R 8.314

Ti 400.0

e0.aj=0,c=1 −4.1394

e0.aj=0,c=2 1.7394

e0.aj=0,c=3 −3.0

e0.aj=1,c=1 3.2247

e0.aj=1,c=2 −3.5678

e0.aj=1,c=3 5.532

e0.aj=2,c=1 1.1678

e0.aj=2,c=2 0.7753

e0.aj=2,c=3 −7.532

e0.aj=3,c=1 −0.2532

e0.aj=3,c=2 1.0532

e0.aj=3,c=3 5.0

e0.hi 2000.0

e0.kr=1 65.5

e0.kr=2 1970.0

e0.ti=0 0.0

e0.xc=3,i=0,k=1 1.0

e0.xc=3,i=0,k=2 0.0

e0.xc=3,i=0,k=3 0.0

Indices

Symbol Value

NR 2

NC 3

NK 3

NI 50

NJ 3


6.7 Additional screenshots

6.7.1 Calculation of the chemical equilibrium


Variable OptimizeConstraints

ChangeReload28996: chemical equilibrium.mosevaEvaluation

FunctionsEquations

Equation Instances

(1)

(2)

(3)

(4)

(5)

(6)

(7)

(8)

Row HeightFont SizeName Spacesof [1..24]allDisplay

Figure 6.1: Specification of the optimization statement in MOSAIC - Con-strains

6.7. ADDITIONAL SCREENSHOTS 147


Constraints Variable Optimize

NEOS serverCode generation

1 variables are selected for minimization.10 variables are selected for optimization.The system is ready for optimization

( ) _g_PARAMS(36) = -10.04; % e0_g_s4PARAMS(37) = -14.93; % e0_g_s8PARAMS(38) = -31.21; % e0_g_s9PARAMS(39) = 0.0; % e0_n_in_s10PARAMS(40) = 0.0; % e0_n_in_s1PARAMS(41) = 1.0; % e0_a_s1_e1PARAMS(42) = 0.0; % e0_a_s1_e2PARAMS(43) = 0.0; % e0_a_s1_e3PARAMS(44) = 1.0; % e0_a_s10_e1PARAMS(45) = 0.0; % e0_a_s10_e2PARAMS(46) = 1.0; % e0_a_s10_e3PARAMS(47) = 2.0; % e0_a_s2_e1PARAMS(48) = 0.0; % e0_a_s2_e2PARAMS(49) = 0.0; % e0_a_s2_e3PARAMS(50) = 1.0; % e0_n_in_s2PARAMS(51) = 0.0; % e0_n_in_s3

%Get variable boundaries[LB, UB] = getBounds();

%Set optionsoptions = optimset('MaxFunEvals',10000,'MaxIter',10000,'TolCon',1e-006,'Display','Iter');

%OptimizeRES = fmincon(@( x_iter )objectiveFunction(x_iter,PARAMS),X_ITER,[],[],[],[],LB,UB,@( x_iter )getNonlinearConstrains(x_iter,PARAMS),options);

CreateMatlab - Constrained

Figure 6.2: Optimization code generation for Matlab using fmincon




Code generation NEOS server

Submit HistoryTerms of Use

The neos SERVER is as service, provided by the University of Wisconsin-Madison.It is not managed by the MOSAIC team. By submitting a job, you have accepted their Terms of Use :

These terms of use ("Terms") constitute a legal agreement between the submitter of the material ("You") and the Morgridge Institute for Research ("MIR"), a private not-for-profit research organization.

You acknowledge that by using the NEOS optimization service ("Service"), and by submitting materials to the Service (a "Submission"), You agree to be bound by the following Terms, including the warranty disclaimers, limitation of liability and privacy policy included below. You also acknowledge that You are free to reject these Terms and not use the Services by hitting cancel or leaving this page and by not submitting any materials to the Service. You further acknowledge that You must separately agree to these Terms each time You provide a Submission.

In consideration for the Services, You agree as follows:

1.No Warranties. The Services are provided "AS IS" and without any warranty of any kind, whether express or implied, including without any warranty as to title, merchantability, non-infringement, or fitness for a particular purpose. MIR does not warrant that the results of the Services will be accurate or complete. MIR does not warrant that the Services will return a valid result or any result whatsoever.

2.No Liability.You acknowledge that the Services, the software systems and algorithms employed by the Services, and the results of the Service are complex and sophisticated, and the possibility for error exists. Therefore, You are solely responsible for exercising independent professional judgment and to independently verify all results, conclusions, answers and recommendations of the Services.

Further, You acknowledge that these Services are being provided to You for no fee. Accordingly, neither MIR nor any of MIR's affiliates, including but not limited to the Wisconsin Alumni Research Foundation, will be liable to You for any damages, whether direct, indirect, consequential, punitive, or otherwise for any reason arising out of or in connection with these Terms or performance of, or failure to perform, the Services. If the foregoing disclaimer is not permitted by law, MIR's liability to You will not exceed $25.00.

3.Your submissions. By providing Your Submission for use in the Services, You represent to MIR that (i) You own or otherwise have the right to provide MIR a copy of each Submission; (ii) the Submission is non-confidential, is not a trade secret, and is not the subject of any non-disclosure obligations of any third party;

d (iii) th S b i i Y i i f th S b i i d MIR' i d f th i th S i ill t i l t l l di

Connecthttp://neos-1.chtc.wisc.edu:3332

Figure 6.3: NEOS submission panel - connect





Terms of Use HistorySubmit

Submit

Details

Nonlinearly Constrained Optimization

CONOPT

GAMSLanguage

Category:

Solver:

[email protected]:

Info eq17.. 0 e e0_x_s4 ((e0_n_s4)/((e0_n_s1 e0_n_s2 e0_n_s3 e0_n_s4 e0_n_s5 e0_n_s6 e0_n_s7 e0_n_s8 e0_n_s9 e0_n_s10))) ;eq18.. 0 =e= e0_x_s5 - ((e0_n_s5)/((e0_n_s1 + e0_n_s2 + e0_n_s3 + e0_n_s4 + e0_n_s5 + e0_n_s6 + e0_n_s7 + e0_n_s8 + e0_n_s9 + e0_n_s10))) ;eq19.. 0 =e= e0_x_s6 - ((e0_n_s6)/((e0_n_s1 + e0_n_s2 + e0_n_s3 + e0_n_s4 + e0_n_s5 + e0_n_s6 + e0_n_s7 + e0_n_s8 + e0_n_s9 + e0_n_s10))) ;eq20.. 0 =e= e0_x_s7 - ((e0_n_s7)/((e0_n_s1 + e0_n_s2 + e0_n_s3 + e0_n_s4 + e0_n_s5 + e0_n_s6 + e0_n_s7 + e0_n_s8 + e0_n_s9 + e0_n_s10))) ;eq21.. 0 =e= e0_x_s8 - ((e0_n_s8)/((e0_n_s1 + e0_n_s2 + e0_n_s3 + e0_n_s4 + e0_n_s5 + e0_n_s6 + e0_n_s7 + e0_n_s8 + e0_n_s9 + e0_n_s10))) ;eq22.. 0 =e= e0_x_s9 - ((e0_n_s9)/((e0_n_s1 + e0_n_s2 + e0_n_s3 + e0_n_s4 + e0_n_s5 + e0_n_s6 + e0_n_s7 + e0_n_s8 + e0_n_s9 + e0_n_s10))) ;eq23.. 0 =e= e0_x_s10 - ((e0_n_s10)/((e0_n_s1 + e0_n_s2 + e0_n_s3 + e0_n_s4 + e0_n_s5 + e0_n_s6 + e0_n_s7 + e0_n_s8 + e0_n_s9 + e0_n_s10))) ;

modeleq_system /all/ ;

solveeq_system using nlp minimizing e0_G ;

Show queue


Figure 6.4: NEOS submission panel - select optimizer and submit





Terms of Use Submit History

DeleteRefresh

submitted submission password evaluation status category solver language

2014-04-17 10:04:28.02983907 qzwRxcCf 28996: chemical eq... Done nco CONOPT GAMS2014-04-16 11:26:54.02982366 doDkPxWC 10321: minimize ti... Done nco Ipopt AMPL2014-04-16 11:25:59.02982362 ALiNmVMz 10321: minimize ti... Done go LINDOGlobal GAMS2014-04-16 11:25:52.02982361 YQtEzxwV 10321: minimize ti... Done go BARON GAMS2014-04-16 11:25:46.02982360 kXwaiucs 10321: minimize ti... Done nco CONOPT GAMS2014-04-16 11:25:39.02982359 tGAYihxZ 10321: minimize ti... Done nco Ipopt GAMS2014-04-16 11:07:16.02982317 SlvxWiFo 8267: Full statement... Done go LINDOGlobal GAMS2014-04-16 11:07:08.02982314 QohsbfYE 8267: Full statement... Done go BARON GAMS VARIABLE e0_x_s4.L = 0.00078667 VARIABLE e0_x_s3.L = 0.48153308 VARIABLE e0_x_s2.L = 0.08849933 VARIABLE e0_x_s1.L = 0.02427537 VARIABLE e0_x_s10.L = 0.05817422 VARIABLE e0_n_s10.L = 0.09514240 VARIABLE e0_n_s8.L = 0.01749372 VARIABLE e0_n_s1.L = 0.03970173 VARIABLE e0_n_s9.L = 0.03681193 VARIABLE e0_n_s2.L = 0.14473832 VARIABLE e0_n_s3.L = 0.78753467 VARIABLE e0_n_s6.L = 0.00060989 VARIABLE e0_n_s4.L = 0.00128657 VARIABLE e0_n_s7.L = 0.02620533 VARIABLE e0_n_s5.L = 0.48594910 VARIABLE e0_G.L = -4.88048E+1

EXECUTION TIME = 0.001 SECONDS 2 MB 24.2.1 r43572 LEX-LEG


Figure 6.5: NEOS submission panel - read results


Editors Analysis Optimization Optimal exp. Design Measurements Documentation ExtrasEvaluate

Save AsSaveNewSearchOpen28996: chemical equilibrium.mosevaLocation

Equation System Indexing Instance Info Variable Specification Parameter Specification Evaluation Results Description Keywords Import

Import Results

Import

Results: variable name (from code) [WHITE SPACE(S)] value

VARIABLE e0_greek_mu_s1.L = -1.00065E+1 VARIABLE e0_greek_mu_s8.L = -1.55360E+1 VARIABLE e0_greek_mu_s7.L = -2.87919E+1 VARIABLE e0_greek_mu_s9.L = -3.10720E+1 VARIABLE e0_x_s8.L = 0.01069643 VARIABLE e0_x_s5.L = 0.29713049 VARIABLE e0_x_s9.L = 0.02250842 VARIABLE e0_x_s4.L = 0.00078667 VARIABLE e0_x_s3.L = 0.48153308 VARIABLE e0_x_s2.L = 0.08849933 VARIABLE e0_x_s1.L = 0.02427537 VARIABLE e0_x_s10.L = 0.05817422 VARIABLE e0_n_s10.L = 0.09514240 VARIABLE e0_n_s8.L = 0.01749372 VARIABLE e0_n_s1.L = 0.03970173 VARIABLE e0_n_s9.L = 0.03681193 VARIABLE e0_n_s2.L = 0.14473832 VARIABLE e0_n_s3.L = 0.78753467 VARIABLE e0_n_s6.L = 0.00060989 VARIABLE e0_n_s4.L = 0.00128657 VARIABLE e0_n_s7.L = 0.02620533 VARIABLE e0_n_s5.L = 0.48594910 VARIABLE e0_G.L = -4.88048E+1

Language Specification

GAMS Functions as Equations

ChangeReloadNo lang spec file loaded.No lang spec file loaded.

Lang SpecLang SpecUser-defined

Predefined

Figure 6.6: Optimization results, imported into MOSAIC


6.7.2 Optimal control of a batch reactor



Save AsSaveNewSearchOpen10336: maximize B.mosvarVar Specs



e0 400.0 300.0 450.0

e0 400.0 300.0 450.0

e0 400.0 300.0 450.0

e0 400.0 300.0 450.0

e0 400.0 300.0 450.0

e0 400.0 300.0 450.0

Objective Variables


e0 -1.0E9 1.0E9

> >

< <

> >

< <

< <

> >

Design Variables

NSPC Variable N... Value

e0 2000.0

e0 2000.0

e0 65.5

e0 1970 0

Iteration Variables

NSPC Variable Nam... Initial Lower Bou... Upper Bou...

e0 0.726891908...0.0 1.0

e0 5.017903E-10 0.0 1.0

e0 0.721616451...0.0 1.0

e0 3.181678E-10 0.0 1.0

x - Mole fraction (mol/mol) Indices c - Number of collocation points i - Number of intervals k - Number of components

e[0]36443

e0

Name Space:

Figure 6.7: Variable specification for the maximization of the product con-centration




Save AsSaveNewSearchOpen10320: minimize time.mosvarVar Specs



e0 2000.0 100.0 3000.0

e0 2000.0 100.0 3000.0

e0 2000.0 100.0 3000.0

e0 400.0 300.0 450.0

e0 400.0 300.0 450.0

e0 400.0 300.0 450.0

Objective Variables


e0 0.0 1.0E9

> >

< <

> >

< <

< <

> >

Design Variables

NSPC Variable N... Valuee0 0.0

e0 1.0

e0 0.0

e0 0.0

Iteration Variables

NSPC Variable Nam... Initial Lower Bou... Upper Bou...

e0 1.279159E-10 0.0 1.0

e0 0.706018693...0.96 1.0

e0 0.064987812...0.0 1.0

e0 0.906719313...0.0 1.0

x - Mole fraction (mol/mol) Indices c - Number of collocation points i - Number of intervals k - Number of components

e[0]36443

e0

Name Space:

Figure 6.8: Variable specification for the minimization of the batch time


6.7.3 Transformation editor

Evaluate Analysis Optimization Optimal exp. Design Measurements Documentation ExtrasEditors

Notation Equation Function Parameter List Connector Equation System Interface Language Specification VarSpec ViewerTransformation

Variable Matching Index Matching Variable Predetermination DescriptionSet Notations

Superscripts Subscripts IndicesBase names

Name Description

ParameterJ JacobianM Mass Matrixr Rate (1/h)S Sensitivityt Time (h)u Dilution Factor (1/h)x Concentration (g/l)

Super Notation

Name Description

a collocation constanth step sizek step variablex dependent state variabley independent variable

Sub Notation

Equation Description

Orthogonal collocation on finite elements, main expression

Auxillary equation for the independent variable calculation, depending on the step size

Continuity equation as connection between the intervals

Import

Import32017: Orthogonal collocation on finite elements.moseqs

2323: Asprey.mosnotSuper Notation

EQS (Discretization)

Save AsSaveNewSearchOpen32027: Asprey, orthogonal collocation.mostraLocation

Figure 6.9: Transformation editor - Step 1, Discretization equation systemand super notation




Set Notations Index Matching Variable Predetermination DescriptionVariable Matching

Independent variable(s)

Discretization

Match

Super Notation

DeleteEditNew

Independent variable(s)Discretization naming Super naming

Independent Variable Matching

Break

Name Space:


Figure 6.10: Transformation editor - Step 2, Matching of independent vari-ables




Set Notations Variable Matching Variable Predetermination DescriptionIndex Matching

c - collocation points

std

std

Name Space:

Match

Used indices

Discretization Super Notation

Available indicesDiscretization naming Super naming

Index Matching

Break


Figure 6.11: Transformation editor - Step 3, Matching of indices




Set Notations Variable Matching Index Matching DescriptionVariable Predetermination

r - Rate (1/h)

std

std

Name Space:

Suggested Variables

Delete

New

Edit

Suggested variables

Like independent variable

< set as state variable

< set as default variable

Default index variables

BreakBreak

State variables

Predetermined state variables


Figure 6.12: Transformation editor - Step 4, Listing of time depending al-gebraic variables

6.7.4 Miscellaneous

id name description last modified

23329 EquilibriumSysV1 Wilson 09.08.13 11:486896 reboiler full with full reboiler with wilson 05.09.12 16:537180 equszs Flash with expanded wilson 03.04.12 13:4013981 Evaluation according Evaluation (wilson model) 18.10.12 13:5633106 system simple flash with Wilson 05.02.14 20:4031831 Evaluation with Dippr Kolonne zum Trennen von 16.01.14 16:4632447 1390902504:EvaluationTrennung des Gemischs 28.01.14 11:4832200 Evaluation with Dippr Trennung des Gemischs 27.01.14 15:0113318 Eval_Dynamic_Flash_C(i=1) - Water (i=2) Hold Up 08.10.12 18:2013734 Eval Dynamic Flash C(i=1) Water (i=2) Hold Up 15 10 12 15:37

Search100rows:0from:description:wilson

CloseOpen

Figure 6.13: Search panel of the model database

Chapter 7

List of literature

7.1 Own publications

Robert Kraus, Sandra Fillinger, Gregor Tolksdorf, Duc Hoang Minh, Vic-

tor Alejandro Merchan Restrepo, Gunter Wozny. Improving Model and

Data Integration Using MOSAIC as Central Data Management Plat-

form. Chemie Ingenieur Technik, 86(7):1130–1136 (2014). doi:10.1002/

cite.201400007.

Victor Alejandro Merchan Restrepo, Gregor Tolksdorf, Robert Kraus, Gun-

ter Wozny. Extending Documentation-Based Models towards an Effi-

cient Integration into Commercial Process Simulators. Chemie Ingenieur

Technik, 86(7):1117–1129 (2014). doi:10.1002/cite.201400014.

Erik Esche, David Muller, Robert Kraus, Gunter Wozny. Systematic ap-

proaches for model derivation for optimization purposes. Chemical En-

gineering Science, 115:215–224 (2014a). doi:10.1016/j.ces.2013.11.041.

Erik Esche, David Muller, Gregor Tolksdorf, Robert Kraus, Gunter Wozny.

MOSAIC: An Online Modeling Platform Supporting Automatic Dis-

cretization of Partial Differential Equation Systems. In Proceedings

of the 8th International Conference on Foundations of Computer-Aided

Process Design, volume 34, pages 693–698 (2014b). ISBN 978-0-444-

63433-7. doi:10.1016/B978-0-444-63433-7.50100-0.

Tilman Barz, Robert Kraus, Liming Zhu, Gunter Wozny, Harvey Arellano-

159

160 CHAPTER 7. LIST OF LITERATURE

Garcia. Generation of discrete first- and second-order sensitivities for

single shooting. AIChE Journal, 58(10):3110–3122 (2012). doi:10.1002/

aic.13720.

Robert Kraus, Victor Alejandro Merchan Restrepo, Harvey Arellano-Garcia,

Gunter Wozny. MOSAIC als online Plattform fur die integrierte Verwal-

tung von Modellen und Messdaten. In Jahrestreffen der Fachgemein-

schaft Prozess-, Apparate- und Anlagentechnik (PAAT) (2012b).

Robert Kraus, Victor Alejandro Merchan, Harvey Arellano-Garcia, Gun-

ter Wozny. Hierarchical simulation of integrated chemical processes

with a web based modeling tool. In 11th International Symposium on

Process Systems Engineering, volume 31, pages 155–159. Elsevier (2012a).

doi:10.1016/b978-0-444-59507-2.50023-8.

Victor Alejandro Merchan Restrepo, Robert Kraus, Harvey Arellano-Garcia,

Gunter Wozny. Einsatz einer webbasierten Modellierungsumgebung in

der Ausbildung von Prozessingenieuren. In Jahrestreffen der Fachge-

meinschaft Prozess-, Apparate- und Anlagentechnik (PAAT) (2012a).

Victor Alejandro Merchan Restrepo, Robert Kraus, Tilman Barz, Harvey

Arellano-Garcia, Gunter Wozny. Generation of first and higher order

derivative information out of the documentation level. In 11th Interna-

tional Symposium on Process Systems Engineering, volume 31, pages

950–954. Elsevier (2012b). doi:10.1016/b978-0-444-59506-5.50021-3.

Stefan Kuntsche, Tilman Barz, Robert Kraus, Harvey Arellano-Garcia, Gun-

ter Wozny. MOSAIC a web-based modeling environment for code gen-

eration. Computers & Chemical Engineering, 35(11):2257–2273 (2011a).

doi:10.1016/j.compchemeng.2011.03.022.

Robert Kraus, Victor Alejandro Merchan Restrepo, Stefan Kuntsche, Flavio

Manenti, Guido Buzzi-Ferraris, Gunter Wozny. Modelling in the docu-

mentation level using MOSAIC and numerical Libraries. In Sauro

Pierucci, ed., AIDIC Conference Series, volume 10 (2011). ISBN 978-

88-95608-58-7. doi:10.3303/ACOS1110023.

Stefan Kuntsche, Robert Kraus, Harvey Arellano-Garcia, Gunter Wozny.

MOSAIC, an Internet Tool for Co-operative Modeling in the Documenta-

tion Level and Code Generation. Chemical Engineering Greetings to

7.1. OWN PUBLICATIONS 161

Prof. Sauro Pierucci, pages 141–150 (2011b). doi:10.3303/MSC1101017.

Stefan Kuntsche, Robert Kraus, Harvey Arellano-Garcia, Gunter Wozny.

Modellierung auf der Dokumentationsebene und Einsatz von Daten-

banken zum Reuse von Teilmodellen. In ProcessNet - 8. Symposium

”Informationstechnologien fur Entwicklung und Produktion in der Ver-

fahrenstechnik” (2011d).

Harvey Arellano-Garcia, Robert Kraus, Gunter Wozny. A Novel Process

Concept for the Production of Ethyl Lactate. In Haan Andre B de, Harry

Kooijman, Andrzey Gorak, eds., Distillation Absorption 2010 (2010a).

Robert Kraus, Harvey Arellano-Garcia, Stefan Kuntsche, Gunter Wozny.

A Hierarchical Modeling Approach to Process Design and Simulation.

In AIChE Annual Meeting, Salt Lake City (2010a).

Robert Kraus, Stefan Kuntsche, Harvey Arellano-Garcia, Gunter Wozny.

Eine webbasierte Modellierungsumgebung fur Code-Generierung. In

ProcessNet - Jahrestreffen der Fachgemeinschaft ”Prozess-, Apparate-

und Anlagentechnik” (2010b).

Harvey Arellano-Garcia, Robert Kraus, Gunter Wozny. Neues Prozesskonzept

zur Produktion von Milchsaureethylester. In ProcessNet-Jahrestagung

2010 und 28. Jahrestagung der Biotechnologen, volume 82, pages 1429–

1429 (2010b). doi:10.1002/cite.201050547.

162 CHAPTER 7. LIST OF LITERATURE

7.2 Supervised theses

Gregor Tolksdorf. Modulare Diskretisierung von Differentialgleichungen in

einer webbasierten Modellierungsumgebung (2013).

Sandra Fillinger. Entwicklung und Umsetzung eines Automatisierungskon-

zepts fur eine Vakuumkolonne zur Auftrennung eines C13-C15-Aldehyd-

gemisches in Siemens Simatic PCS7 (2013).

Elchin Heybatov. Building and organizing the model library of chemical

reactors (2013).

Sandra Fillinger. Modellierung einer dynamischen Nichtgleichgewichts-

Trennstufe in der Simulationsumgebung gPROMS (2012).

Diego Nicolas Pulido Lopez. Implementation of Statistical Association Fluid

Theory (SAFT) and Perturbed Hard-Chain Theory (PC-SAFT) Equa-

tions of State in MOSAIC (2012).

Elisenda Munoz. Modeling of a Reactive Distillation Column for Vinyl Ac-

etate Process using gPROMS (2011).

Mariana Silva. Modelling of Fluid Dynamics of Foaming Systems in Packed

Columns (2011).

Bibliography

Uri M. Ascher, Linda R. Petzold. Computer Methods for Ordinary Differen-

tial Equations and Differential-Algebraic Equations. Society for Industrial

and Applied Mathematics, Philadelphia (1998). ISBN 0898714125.

S. P. Asprey, S. Macchietto. Designing robust optimal dynamic experi-

ments. Journal of Process Control, 12(4):545–556 (2002). doi:10.1016/

s0959-1524(01)00020-8.

Tilman Barz. Visualisierung modellbasierter Prozessdaten in der verfahren-

stechnischen Leitwarte - Ein Ansatz zur nutzerzentrierten Gestaltung

hoherer Prozessfuhrungssysteme. Ph.D. thesis, Technische Universitat

Berlin (2008).

Tilman Barz, Harvey Arellano-Garcia, Gunter Wozny. Handling Uncertainty

in Model-Based Optimal Experimental Design. Industrial & Engineering

Chemistry Research, 49:5702–5713 (2010). doi:10.1021/ie901611b.

Tilman Barz, Stefan Kuntsche, Gunter Wozny, Harvey Arellano-Garcia. An

efficient sparse approach to sensitivity generation for large-scale dynamic

optimization. Computers & Chemical Engineering, 35:2053–2065 (2011).

doi:10.1016/j.compchemeng.2010.10.008.

Lorenz T. Biegler. An overview of simultaneous strategies for dynamic opti-

mization. Chemical Engineering and Processing: Process Intensification,

46(11):1043–1053 (2007). doi:10.1016/j.cep.2006.06.021.

163

164 BIBLIOGRAPHY

Lorenz T. Biegler. Nonlinear Programming: Concepts, Algorithms, and Ap-

plications to Chemical Processes, volume 10 of MOS-SIAM Series on Op-

timization. Society for Industrial and Applied Mathematics, Philadelphia

(2010). ISBN 978-0898717020.

Lorenz T. Biegler. Optimization of Differential-Algebraic Equation Systems.

Technical report, Carnegie Mellon University, Pittsburgh, PA (2011).

Jerome Bracken, Garth P. McCormick. Selected Applications of Nonlinear

Programming. Jon Wiley & Sons, New York (1968).

I. T. Cameron, G. D. Ingram. A survey of industrial process modelling across

the product and process lifecycle. Computers & Chemical Engineering,

32(3):420–438 (2008). doi:10.1016/j.compchemeng.2007.02.015.

Edgar F. Codd. A relational model of data for large shared data banks.

Communications of the ACM, 13(6):377–387 (1970). doi:10.1145/362384.

362685.

M. Nicolas Cruz Bournazou, D. Domaschk, Tilman Barz, Gunter Wozny,

Harvey Arellano-Garcia. Evaluation of Integration Approaches to DAE

Systems in Engineering Applications. In 18th International Conference

Process Engineering and Chemical Plant Design. Technische Universitat

Berlin (2011). ISBN 978-3-7983-2361-2.

J. Czyzyk, M. P. Mesnier, J. J. More. The NEOS Server. IEEE Computa-

tional Science and Engineering, 5(3):68–75 (1998). doi:10.1109/99.714603.

Deutsche Forschungsgemeinschaft DFG. Proposals for Safeguarding Good

Scientific Practice (2013).

M. Eggersmann, L. von Wedel, W. Marquardt. Management and Reuse of

Mathematical Models in the Industrial Design Process. Chemical Engi-

neering & Technology, 27(1):13–22 (2004). doi:10.1002/ceat.200406114.

Erik Esche, David Muller, Gregor Tolksdorf, Robert Kraus, Gunter Wozny.

MOSAIC: An Online Modeling Platform Supporting Automatic Dis-

cretization of Partial Differential Equation Systems. In Proceedings of

BIBLIOGRAPHY 165

the 8th International Conference on Foundations of Computer-Aided Pro-

cess Design, volume 34, pages 693–698 (2014a). ISBN 978-0-444-63433-7.

doi:10.1016/B978-0-444-63433-7.50100-0.

Erik Esche, David Muller, Gunter Wozny. Structural Reformulation of Pro-

cess Models for Improved Numerical Behavior in Process Simulation and

Optimization (2014b). Submitted to Computers and Chemical Engineer-

ing.

Sandra Fillinger. Entwicklung und Umsetzung eines Automa-

tisierungskonzepts fur eine Vakuumkolonne zur Auftrennung eines

C13-C15-Aldehydgemisches in Siemens Simatic PCS7 (2013).

Bruce A. Finlayson. Nonlinear analysis in chemical engineering. Chemical

Engineering Series. McGraw-Hill (1980). ISBN 0-07-020915-4.

F. Forner, A. Klein, J.-U. Repke. Trennung homogener Azeotrope mittels

Zweidruckrektifikation - Eine Analyse des Betriebsverhaltens. Chemie

Ingenieur Technik, 77(6):763–771 (2005). doi:10.1002/cite.200500024.

B. A. Foss, B. Lohmann, W. Marquardt. A field study of the industrial

modeling process. Journal of Process Control, 8(5-6):325–338 (1998). doi:

10.1016/s0959-1524(98)00018-3.

Peter Fritzon. Principles of Object-Oriented Modeling and Simulation

with Modelica 2.1. Wiley (2000). ISBN 978-0471471639. doi:10.1002/

9780470545669.

William Gropp, Jorge More. Optimization environments and the NEOS

server. Approximation theory and optimization, pages 167–182 (1997).

J. Gross, G. Sadowski. Perturbed-Chain-SAFT. Supercritical Fluids

as Solvents and Reaction Media, pages 295–322 (2004). doi:10.1016/

b978-044451574-2/50012-2.

Joachim Gross, Gabriele Sadowski. Application of the Perturbed-Chain

SAFT Equation of State to Associating Systems. Industrial & Engineering

Chemistry Research, 41(22):5510–5515 (2002). doi:10.1021/ie010954d.

166 BIBLIOGRAPHY

Katalin Hangos, Ian T. Cameron. Process Modelling and Model Analysis,

volume 4 of Process Systems Engineering. Academic Press, London (2001).

ISBN 0-12-156931-4.

HSL. A collection of Fortran codes for large scale scientific computation

(2013).

http://www.hsl.rl.ac.uk

Zdzis�law Jaworski, Barbara Zakrzewska. Towards multiscale modelling in

product engineering. Computers & Chemical Engineering, 35(3):434–445

(2011). doi:10.1016/j.compchemeng.2010.05.009.

Anne Krogh Jensen, Rafiqul Gani. A computer aided system for generation

of problem specific process models. Computers chem. Engng, 20:S145–

S150 (1996). doi:10.1016/0098-1354(96)00035-X.

Stefan Kuntsche. Modular model specification on the documentation level:

concepts and application in a web-based modeling environment. Ph.D.

thesis, Technische Universitat Berlin (2013).

urn:nbn:de:kobv:83-opus-39943

Chiou Peng Lam, Huaizhong Li, Dong Xu. A model-centric approach for

the management of model evolution in chemical process modelling. Com-

puters & Chemical Engineering, 31(12):1633–1662 (2007). doi:10.1016/j.

compchemeng.2007.01.010.

Jeffery S. Logsdon, Lorenz T. Biegler. Accurate solution of differential-

algebraic optimization problems. Industrial & Engineering Chemistry Re-

search, 28(11):1628–1639 (1989). doi:10.1021/ie00095a010.

S. H. Oh, R. Luus. Use of orthogonal collocation method in optimal control

problems. International Journal of Control, 26(5):657–673 (1977). doi:

10.1080/00207177708922339.

C. C. Pantelides, D. Gritsis, K. R. Morison, R. W. H. Sargent. The math-

ematical modelling of transient systems using differential-algebraic equa-

BIBLIOGRAPHY 167

tions. Computers & Chemical Engineering, 12(5):449–454 (1988). doi:

10.1016/0098-1354(88)85062-2.

Diego Nicolas Pulido Lopez. Implementation of Statistical Association Fluid

Theory (SAFT) and Perturbed Hard-Chain Theory (PC-SAFT) Equa-

tions of State in MOSAIC (2012).

R. H. Sage, B. L. Hicks, W. N. Lacey. Phase Equilibria in Hydrocarbon

Systems. Industrial & Engineering Chemistry, 32(8):1085–1092 (1940).

doi:10.1021/ie50368a014.

Georg Schopfer, Lars v.Wedel, Wolfgang Marquardt. An environment archi-

tecture to support modeling and simulation in the process design lifecycle.

In AIChE Annual Meeting, Los Angeles (2000).

Amra Tihic. Group Contribution sPC-SAFT Equation of State. Ph.D. thesis,

Technical University of Denmark (2008).

Gregor Tolksdorf. Modulare Diskretisierung von Differentialgleichungen in

einer webbasierten Modellierungsumgebung (2013).

John Eugene Tolsma. Analysis of Heteroazeotropic Systems. Ph.D. thesis,

Massachusetts Institute of Technology (1999).

T. H. Tsang, D. M. Himmelblau, T. F. Edgar. Optimal control via col-

location and non-linear programming. International Journal of Control,

21(5):763–768 (1975). doi:10.1080/00207177508922030.

Andrea Walther, Andreas Griewank. Getting started with ADOL-C. In

Combinatorial Scientific Computing, pages 181–202. Chapman-Hall CRC

Computational Science (2012). doi:10.1201/b11644-8.

3rd World Conference on Research Integrity WCRI. Montreal Statement on

Research Integrity in Cross-Boundary Research Collaborations (2013).

Grant M. Wilson. Vapor-Liquid Equilibrium. XI. A New Expression for the

Excess Free Energy of Mixing. Journal of the American Chemical Society,

86(2):127–130 (1964). doi:10.1021/ja01056a002.

168 BIBLIOGRAPHY

Rodolphe Zerry. MOSAIC, eine webbasierte Modellierungs- und Simulation-

sumgebung fur die Verfahrenstechnik. Ph.D. thesis, Technische Universitat

Berlin. ISBN 978-3-8322-7148-0. (2008).

Concepts and implementation of Collaborative Modeling in MOSAIC · 2017-10-26 · Concepts and...

Documents

Transcript of Concepts and implementation of Collaborative Modeling in MOSAIC · 2017-10-26 · Concepts and...