Automatised Implementation of CAPE-OPEN Interfaces: a Workfow for Equation-Based Flowsheet Modelling

Automatised Implementation of CAPE-OPEN Interfaces: A Workfow for Equation-Based Flowsheet Modelling

vorgelegt von M.Sc. Gregor Stefan Tolksdorf

von der Fakultät III - Prozesswissenschaften der Technischen Universität Berlin zur Erlangung des akademischen Grades Doktor der Ingenieurwissenschaften - Dr.-Ing. - genehmigte Dissertation

Promotionsausschuss:

Vorsitzender: Prof. Dr.-Ing. Felix Ziegler Gutachter: Prof. Dr.-Ing. habil. Jens-Uwe Repke Gutachter: Dr. Richard Baur Gutachter: Prof. Dr.-Ing. habil. Prof. h.c. Dr. h.c. Günter Wozny

Tag der wissenschaftlichen Aussprache: 30.09.2019

Berlin 2019 meinen Eltern

Vorwort

Die vorliegende Arbeit entstand während meiner Tätigkeit als wissenschaftlicher Mitarbeiter am “Fachgebiet Dynamik und Betrieb technischer Anlagen” (DBTA) der Technischen Universität Berlin. Von Mitte 2013 bis Ende 2017 wurde meine Forschung im Rahmen der Exzellenzinitiative des Bundes und der Länder im Exzellenzcluster “Unifying Concepts in Catalysis” (UNICAT) gefördert.

Ich möchte diese Stelle nutzen, um mich noch einmal bei meinen Gutachtern Prof. Wozny, Dr. Baur und Prof. Repke zu bedanken. Der Übergang der Profes- sur am Fachgebiet DBTA von Prof. Wozny, der das Fachgebiet bis 2015 über 22 Jahre lang geleitet hat, zu Prof. Repke, der die Nachfolge im Jahr 2016 übernom- men hat, machte meine Situation etwas komplizierter. Ich bedanke mich daher bei Prof. Repke für das Vertrauen, es mir fast bedingungslos zu ermöglichen, meine angefangene Arbeit erfolgreich zu beenden. Ich danke Dr. Baur für seinen Blick von außerhalb des Unibetriebs auf meine Arbeit und seine Kommentare im Zusammenhang mit meiner Forschung. Mein größter Dank gilt Prof. Wozny, der es mit seiner menschlichen, integren Art geschaft hat, mich davon zu überzeu- gen, als wissenschaftlicher Mitarbeiter eine Promotion anzustreben, in der ich mein Wissen und meine Fähigkeiten in der Schnittstelle von Informatik und Ver- fahrenstechnik praktisch anwenden kann. Aus unseren Gesprächen – Gesprächen zwischen unterschiedlichen Generationen – konnte ich viel Erfahrung mitnehmen und meine Ansichten zu Arbeits- und Lebenseinstellungen schärfen. Meine Zeit als wissenschaftlicher Mitarbeiter ist für mich auch immer mit den Kollegen verbunden, mit denen ich zusammenarbeiten durfte und die ein aus- gesprochen positives, fruchtbares Arbeitsklima geschafen haben. Allen voran muss ich Erik danken; niemand konnte annähernd so viel Verständnis für mein Promotionsthema und meine Alltagsarbeit an MOSAIC aufbringen wie er. Als nächstes möchte ich explizit meine Kollegen vom “Wimi-Jahrgang” 2013 erwäh- nen: Eva, Sandra und Sebastian. Unsere regelmäßigen Trefen in den ersten Monaten unserer gemeinsamen Zeit haben mir von Anfang an geholfen, über

v Vorwort den Tellerrand meines eigenen Themas hinaus zu schauen. Desweiteren haben mir für die Einarbeitung in MOSAIC und die darauf folgenden Erweiterungen die unzähligen Gespräche mit Robert (Kraus), David (Müller), Alejandro, Al- berto, Matthias und Johannes sowie meinen Flur-Kollegen Markus, Eva, Sandra, Saskia, Erik, Tim, Henning, Robert (Wilhelm), Thomas, Joris und Christian un- ablässig neue Inspiration für Verbesserungen gegeben. Für einige Fragen, die sich mir im Zusammenhang mit CAPE-OPEN stellten, gab es keinen besseren Experten als Jasper van Baten; ohne seine Hilfsbereitschaft und Antworten im Online-Forum würde ich mir jetzt wahrscheinlich immer noch wegen scheinbar unlösbarer Implementierungsprobleme den Kopf zerbrechen. Zum Abschluss danke ich meinen Eltern, die mich mein ganzes Leben lang bedingungslos unterstützt, nie an mir gezweifelt und sich gerne immer wieder von meiner Arbeit haben berichten lassen – auch wenn vielleicht nicht immer alles direkt verständlich war, was ich von mir gegeben habe. Ihnen widme ich diese Arbeit.

Recklinghausen, im Oktober 2019 Gregor Tolksdorf

vi Contents

Vorwortv

Abstract xi

Abbreviations xv

1 Introduction1 1.1 Motivation ...... 1 1.2 Short Introductory Example ...... 2 1.3 Research Question and Objectives ...... 3 1.4 Outline ...... 4

2 Theoretical Background and Related Developments5 2.1 Units of Measurement ...... 8 2.2 Unit Operations in Chemical Engineering ...... 12 2.3 Flowsheet Simulation ...... 14 2.3.1 Basic Ideas ...... 14 2.3.2 Physical Properties ...... 14 2.3.3 Solving a Flowsheet ...... 16 2.3.4 Customizing of Unit Operations ...... 18 2.4 CAPE-OPEN ...... 21 2.4.1 History and Ideas ...... 21 2.4.2 CAPE-OPEN Unit Operations ...... 23 2.4.3 CAPE-OPEN Thermodynamics and Physical Properties . 25 2.4.4 CAPE-OPEN Numerics ...... 26 2.4.5 CAPE-OPEN Common Interfaces ...... 28 2.4.6 Critical Acclaim ...... 28 2.5 Related Developments ...... 31 2.5.1 Functional Mockup Interface ...... 32 2.5.2 Systematic Modelling ...... 32 2.5.3 Interoperability and Implementation of CAPE-OPEN .. 33

vii Contents

2.5.4 Recapitulation of the Related Developments ...... 35

3 Problem Analysis 39 3.1 MOSAICmodeling ...... 39 3.1.1 Basics ...... 39 3.1.2 Workfow of Modelling ...... 41 3.1.3 Workfow of Code Generation ...... 57 3.2 Target Workfow and Gap Analysis ...... 64 3.2.1 Target Workfow ...... 64 3.2.2 Gap Analysis of Missing Features ...... 76

4 Concept and Implementation 81 4.1 Filling the Identifed Gaps ...... 81 4.1.1 Composition of Hierarchical Systems ...... 81 4.1.2 Engineering Units ...... 88 4.1.3 Function Calls ...... 101 4.1.4 Parameters ...... 103 4.1.5 Unit Operation Ports ...... 107 4.1.6 User-Defned LangSpecs (UDLS) ...... 110 4.1.7 Unit Operation Export-Editor ...... 116 4.2 Code Implementation and Distribution of Unit Operations . . . . 121 4.2.1 Applied Technologies ...... 121 4.2.2 Creation on Server ...... 125 4.3 Additional New Features Despite of Core Unit Operations . . . . 131 4.3.1 Filling Smaller Gaps ...... 131 4.3.2 Improving Usability and Convenience ...... 133

5 Application and Case Studies 137 5.1 Reusing a Compatible Unit Operation ...... 137 5.1.1 Membrane Separation ...... 137 5.2 Creating a New Unit Operation ...... 142 5.2.1 MixerSplitter ...... 142 5.3 Extending an Existing Model Towards CAPE-OPEN ...... 150 5.3.1 Existing Deisobutanizer Model ...... 150 5.3.2 Extension Towards CAPE-OPEN ...... 152 5.3.3 Execution as a CAPE-OPEN Unit Operation ...... 163 5.4 Documentation-based Flowsheeting ...... 168

viii Contents

6 Evaluation 171 6.1 Modelling Guidelines ...... 171 6.2 Achievements ...... 173 6.3 Limitations and Future Work ...... 174

7 Conclusions 181

A CAPE-OPEN Interfaces 183

B Export Editor Manual 189 B.1 Introduction ...... 189 B.2 Unit Model ...... 189 B.3 Unit Properties ...... 192 B.3.1 Variables / Fixed Parameters ...... 192 B.3.2 Adjustable Parameters ...... 192 B.3.3 Open Ports ...... 196 B.4 Options and Creation ...... 198 B.4.1 Code Generation ...... 198 B.4.2 Server ...... 201

C XML Schemas 205

D Database Tables 207

E UML Class Diagrams of MOSAICmodeling Elements 211

F Full Documentation of Example Models 215 F.1 CAPE-OPEN Membrane ...... 215 F.2 CAPE-OPEN MixerSplitter ...... 220 F.2.1 Additional MixerSplitter Screenshots ...... 226 F.3 CAPE-OPEN TwoCompundColumn ...... 228 F.3.1 Additional TwoCompoundColumn Screenshots ...... 259 F.4 Documentation-based Flowsheeting ...... 263 F.5 Public Notation ...... 273

G Publications 279

List of Figures 285

ix Contents

List of Tables 289

Bibliography 291

x Abstract

Deutsche Kurzfassung

Um fortlaufend neue, bessere Produktionsprozesse in immer kürzerer Zeit en- twickeln zu können, ist die chemische Industrie darauf angewiesen, das Verhal- ten der geplanten Anlagen simulieren zu können, bevor sie tatsächlich gebaut werden und in Betrieb gehen. Für eine aussagekräftige Simulation werden mathematische Modelle benötigt, die das Verhalten der einzelnen Prozesse und An- lagenteile sowie deren Zusammenwirken beschreiben und in die das Wissen von Physikern, Chemikern und Ingenieuren einfießt. Zur Erstellung und Verwal- tung solcher mathematischen Modelle existiert die vom Fachgebiet Dynamik und Betrieb technischer Anlagen an der Technischen Universität Berlin entwickelte, webbasierte Modellierungs- und Codeerzeugungsumgebung MOSAICmodeling. Mit dieser Software ist es möglich, ein bereits erstelltes und validiertes Modell in einem anderen Kontext oder auch in einer anderen Programmierumgebung weiter zu verwenden. In der vorgelegten Arbeit wird eine neue Methodik entwickelt und angewendet, durch die zusätzlich Schnittstellen gemäß des CAPE- OPEN -Standards automatisiert implementiert werden können.

MOSAICmodeling ist ein Vertreter der gleichungsbasierten Modellierungsum- gebungen, für die es im Allgemeinen schwierig ist, Modelle direkt in sogenannter Flowsheeting-Software (auch Fließbildsimulatoren genannt) einzusetzen. Um solche Herausforderungen zu bewältigen, wurde vor rund 20 Jahren zum Zweck des Austauschs von Simulationsmodellen in Fließbildsimulatoren der interna- tionale CAPE-OPEN -Standard entwickelt, der im Rahmen dieser Arbeit herange- zogen wird. Eine Analyse zeigt, dass für die Implementierung dieses Standards kombiniertes Wissen aus dem Bereich der Informatik und der Verfahrenstech- nik von großer Bedeutung ist. Die Entwicklung eines Mechanismus, mit dem eine automatisierte Implementierung des Standards ohne tieferes Programmier- wissen möglich ist, verspricht ein efektiveres Arbeiten der Verfahrensingenieure,

xi Abstract vermeidet fehleranfällige Handarbeit und kann zu einer erweiterten Verbreitung des Standards führen. Dies wiederum kann den Austausch von Wissen erle- ichtern und die Wiederverwendbarkeit der Modelle in unterschiedlichen Simula- tionsumgebungen steigern, wodurch die jeweils am besten geeignete Simulation- ssoftware gewählt werden kann und nicht zwangsläufg diejenige genutzt werden muss, mit der das Modell zuerst erstellt und simuliert wurde. Dazu wird in dieser Arbeit ein Workfow hergeleitet und vorgestellt, mit dem systematisch neue oder existierende, gleichungsbasierte Modelle von verfahrenstechnischen Grund- operationen entwickelt werden können, die sich automatisch als CAPE-OPEN - kompatible, sogenannte Unit Operations exportieren lassen. Nach Analyse der Grundlagen zu CAPE-OPEN, Fließbildsimulatoren und Unit Operations sowie Feststellung der Ausgangslage und Ermittlung der anstehenden Arbeiten, wird das Konzept umgesetzt und der Workfow in MOSAICmodeling implementiert. Die dafür entwickelten Module zur Erweiterung von MOSAICmodeling werden dargestellt und die für die Arbeit wichtigen Benutzeroberfächen erläutert.

Der hier entwickelte Ansatz konzentriert sich auf die Implementierung der für die Simulation notwendigen CAPE-OPEN -Schnittstellen. In weitergehenden Arbeiten sollte zukünftig untersucht werden, wie verbesserte Lösungsverfahren, die beispielsweise auf der Analyse der Struktur des erstellten Gleichungssys- tems basieren oder bei geänderten Randbedingungen intelligent die Startwerte der Simulation anpassen, in das System der automatisierten Codeerzeugung eingebettet werden können. Zudem gibt es Schnittstellenfunktionen, die für die eigentliche Simulation nicht implementiert werden müssen und zunächst wegge- lassen wurden, aber später die Arbeit mit den Unit Operations weiter erle- ichtern können (z. B. Editierdialoge und Reportfunktionen). Als Nachweis der erfolgreichen Umsetzung des Gesamtkonzepts wird anhand von drei Beispielen steigender Komplexität der Einsatz des entwickelten Workfows demonstriert. Eine zusätzliche Entwicklung in dieser Arbeit – das erweiterte, dokumentations- basierte Flowsheeting – ermöglicht den Einsatz des intuitiven Fließbildsimula- tionskonzepts bereits auf Modellierungsebene auch für die gleichungsbasierten Modelle, wie sie in MOSAICmodeling vorliegen. Dies dient als weiteres Element im Werkzeugkasten des Modellierers innovativer, verfahrenstechnischer Prozesse, für die es noch keine Entsprechungen im Standardbaukasten der üblichen Fließ- bildsimulatoren gibt.

xii English Abstract

In order to continuously develop new, innovative processes and products with at the same intensifed requirements regarding time-to-market chemical industry is eager to simulate the behaviour of process plants before they are built and operated. For meaningful simulations mathematical models describing the sub processes and the plant sections as well as their interaction are required. The knowledge of physicists, chemists and process engineers is included in such models. For collaborative model development and maintenance the Process Dynamics and Operations Group of Technische Universität Berlin created the webbased modelling and code generation tool MOSAICmodeling. This piece of software allows to re-use a previously created and validated model in another context or another programming language. This thesis provides a new methodology to additionally incorporate automatically implemented interfaces according to the CAPE-OPEN (CO) standard.

MOSAICmodeling is one example of an environment creating equation-based models. In general it is not trivial to incorporate this class of models in fowsheet simulation software. In order to overcome, among others, this hurdle, the global CO standard was developed roughly 20 years ago. This standards is taken into account in this thesis to fnd a way to enable fowsheet simulation for equation- based models. An analysis shows that implementing a model according to CO requires knowledge in the area of process engineering as well as in the area of computer science. The development of a mechanism allowing an automated implementation of this standard without in-depth programming knowledge seems to be promising to increase the process engineers’ efectivity. It reduces or even eliminates the need for error-prone manual implementation and can lead to a spreading use of the CO standard. This eases knowledge transfer regarding process simulation models and allows for re-usability of models in diferent simulation tools, therefore increasing the chance to use the best available software for simulation instead of the one the model was frst created in. Therefore in this thesis a workfow is derived and presented, enabling a systematic way to create new or re-use existing, equation-based models that can be exported automatically as CO-compatible unit operations. The basics of CO, fowsheet simulation, unit operations as well as the initial situation and the steps to fll the identifed gaps, are analysed and the workfow is implemented in MOSAICmodeling. The

xiii Abstract modules added to MOSAICmodeling are described and the important graphical user interfaces are commented on.

The approach developed in this thesis focuses on the CO interfaces necessary to execute a simulation model. In future work improved algorithms to solve the equation system, e.g. using automatic decomposition methods based on the equation system’s structure or intelligently adapt the inital values when the boundary conditions change, should be incorporated in the automatic code generation facilities. Additional CO interface functions exist regarding editing dialogs and reporting functionalities, that are not immediately necessary to perform a simulation but should be implemented later on to have a more convenient user experience. As a successful proof of the overall concept the application of the workfow is demonstrated with three examples with increasing complexity. An additional development of this thesis, the documentation-based fowsheeting, introduces the possibility of using the intuitive concept of fowsheeting in modelling of equation-based mathematical models, as encountered in MOSAIC- modeling. This is an additional means in the tool box of the process engineer dealing with innovative processes that cannot be easily be represented with the standard models available in common fowsheet simulators.

xiv Abbreviations

ACM Aspen Custom Modeler 45

BLOB Binary Large Object 127

CAPE Computer-Aided Process Engineering 1, 5, 6, 39

CO CAPE-OPEN xiii, xiv, 1, 2, 3, 5, 6, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 45, 64, 65, 66, 68, 69, 70, 71, 72, 74, 75, 77, 78, 79, 98, 101, 103, 105, 107, 110, 111, 114, 116, 119, 121, 123, 124, 125, 129, 130, 137, 138, 142, 143, 145, 146, 150, 152, 153, 154, 157, 158, 159, 160, 162, 163, 165, 169, 172, 173, 174, 175, 176, 178, 179, 181, 183, 198, 201, 207, 259

COBIA CAPE-OPEN Binary Interoperability Architecture 22, 27, 29

COFE CAPE-OPEN Flowsheet Environment 138, 146, 158, 159, 165, 226, 259

CO-LaN CAPE-OPEN Laboratories Network 21, 23, 25, 27, 28, 71, 124, 183

COM Component Object Model 22, 27, 29, 121

CORBA Common Object Request Broker Architecture 22, 27, 29, 121

DAE Diferential Algebraic Equation System 27, 57, 58

DDB Dortmund Data Bank 15

DLL Dynamic Link Library 121, 124, 129, 201

DTD Document Type Defnition 135

ESO Equation System Object 27, 33, 34, 36

FMI Functional Mockup Interface 32, 35

xv Abbreviations

GUI Graphical User Interface 39, 45, 48, 51, 52, 59, 60, 101, 103, 107, 111, 116, 117, 119, 123, 124, 125, 134, 139, 143, 146, 189, 190, 192, 196, 198, 202

GUID Globally Unique Identifer 73, 78, 114, 116, 119, 125, 127, 129, 130, 138, 146, 200

HTML Hyper Text Markup Language 40

IDE Integrated Development Environment 39

ISQ International System of Quantities 8, 10, 289

JSR Java Specifcation Request 8, 99, 100

LS Language Specifcator 56, 57, 58, 59, 62, 102, 103, 116, 134, 138, 139, 146, 179

LSS Language Specifcator Set 179

MathML Mathematical Markup Language 40, 42

MSI Microsoft Installer 124, 129, 130

MSM Windows Installer Merge Module 124

MSVS Microsoft Visual Studio 123, 124, 125, 127, 129

NEOS Network-Enabled Optimization System 59

NLE Nonlinear Algebraic Equation System 27, 33

NLP Nonlinear Programming 34

NTNU Norwegian University of Science and Technology 32, 36

ODE Ordinary Diferential Equation 57, 58

PDF Portable Document Format 56, 78, 130, 179

PMC Process Modelling Component 21, 22, 27, 28, 33, 34, 36

xvi Abbreviations

PME Process Modelling Environment 21, 22, 24, 27, 30, 33, 34, 36, 65, 66, 71, 72, 74, 75, 79, 124, 138, 158, 173, 175 preLS Predefned Language Specifcator 57, 58, 62, 110, 114

SI International System of Units 8, 9, 10, 24, 26, 93, 94

SIG Special Interest Group 21, 27, 30

SQL Structured Query Language 207

UAM User Added Module 19

UDLS User-Defned Language Specifcator 57, 58, 77, 98, 110, 111, 113, 114, 117, 123, 124, 129, 173

UML Unifed Modelling Language 3, 29, 64, 90, 211

URL Uniform Resource Locator 119, 202, 205

W3C World Wide Web-Consortium 40

WXS Windows Installer XML 119, 124, 129

XML Extensible Markup Language 3, 36, 94, 95, 116, 133, 135

xvii

1 Introduction

1.1 Motivation

Computer-based simulations play an important role in the area of process science and chemical engineering. Digital models are used for investigation and design of novel processes as well as improvement and optimization of existing process plants. The research area Computer-Aided Process Engineering (CAPE) covers this. This thesis deals with the mathematical models describing the physical behaviour of process plants. These models deliver, in form of simulations, insights into the performance of processes under defned conditions, including statements if the process goals will be met and desired product will have the expected quality. The process states usually considered are amounts of substance, temperatures, pressures, and composition of the material streams. Flowsheet simulators are common software products used for simulation of these chemical processes. The available fowsheeting softwares basically use the same concept, only difering in details. One diference is the particular (programming) language to be used when customized models shall be added to a fowsheet. In general it is not possible to move a model from one simulator directly into another. Roughly 20 years ago an initiative was started to promote a standard for the exchange of process simulation models that enables the re-use of existing models and the free choice between a variety of simulators to select the most appropriate one for a particular task. One result of this inititiative are the CO interface defnitions describing the interfaces between fowsheet simulators and models to be simulated within them. The challenge for process engineers is to correctly implement these interface for the innovative models they develop that are not available in the standard libraries of the simulation software products, in order to actually use the same model in diferent simulators. Implementing the interfaces requires mainly knowledge located in the area of computer science rather than in the area of chemical engineering. At that point this work comes into play, showing how a systematic procedure can aid in designing equation-

1 1 Introduction based mathematical models that can easily be transformed to be compliant to the CO standard and executed in diferent fowsheeet simulators. This way process engineers can focus more on the model formulation and do not need to invest time for the otherwise time-consuming and error-prone manual implementation of the standard.

1.2 Short Introductory Example

In this section a simple example is given on how the workfow to develop a model looks like (without CO and without the results of this work). The main goal of the standard modelling workfow is the mathematical description of a chemical process. The thermal separation of two components in a distillation column is a typical problem. This is not a new process, but many aspects relevant for general process modelling occur and can be demonstrated. The important point is that a custom model is developed instead of using an of-the-shelf model available in a fowsheet simulator. First the equations belonging to the model are written down. Functions for the calculation of physical properties are used with publicly available parameter data found in respective databases. The goal is to calculate the profles of temperature, fows, and composition inside the distillation column. Therefore boundary conditions like feed composition and design values like heating duty or refux ratio have to be set until the equation system is fully specifed. Solving this equation system corresponds to simulating the separation process. This simulation needs to be perfomed in a suitable program, able to handle the equation-based model formulation. For the execution a solver is always needed, in this case a solver for systems of algebraic, nonlinear equations. The simulation environments difer in their handling and in the set of available solvers. In order to be independent of particular simulators and solvers, the software MOSAICmodeling is used here. MOSAICmodeling is a modelling and code generation tool storing models according to open standards and able to generate code for diferent simulation environments. The model mentioned here is part of MOSAICmodeling’s model library and describes a distillation column to separate Iso-butane and N-butane. This column now shall be used in a fowsheet simulator, a type of process simulation software widely in use. The difculty now is that every fowsheet simulator has its own way of how self-made models can be entered. Additionally in this case the model shall be fexible enough to handle mixtures of components diferent to the initially chosen butanes. A

2 1.3 Research Question and Objectives solution has to be found how models and functions for physical properties can be exchanged between fowsheet simulators without reformulating the model for each and every simulation environment separately. In chapter 5.3 the model sketched here is taken as a starting point for applying the workfow and the results of this work in order to use the CO standard for execution of this model in fowsheet simulation environments.

1.3 Research Question and Objectives

The modelling and code generation software MOSAICmodeling is used according to a standard modelling workfow. In this work an extended workfow will be sug- gested enabling the execution of the equation-based models in common fowsheet simulators. The principles used for the extension must be of a general nature and have to be seen independent of the concrete modelling environment used here. Part of this is the open specifcation (using Extensible Markup Language (XML)1 defned by schema fles, human-readable), the systematic addition of properties (defning public parameters and port exchange quantities), the application of code templates combined with customization options, and eventually the preparation of confguration fles for automatic creation of executable fles. In summary, rapid prototyping of CO unit operations, enabling a quick start with the possibility for continuous improvement has to be achieved. In this regards this thesis has to meet the expectations raised within the outlook given in Mer- chan et al., 2014, p.1127: “In the future, the users should have the possibility to defne a proper interface code generation on their own.(...) The direct generation of CAPE-OPEN compatible dynamic libraries, e.g. in form of CAPE-OPEN unit operations, would increase the number of supporting platforms and speed up the simulating step within the modeling workfow.” The successful application shall be shown in at least two diferent fowsheet simulators. An additional aspect is the fowsheeting with equations on documentation level that has to be shown, too. Using such an approach the advantages of simultaneous solution can be used, while at the same time the convenient principles of unit-based modelling of fowsheet simulators are given.

1https://www.w3.org/TR/2008/REC-xml-20081126/ date of last access: 2019-03-09

3 1 Introduction

1.4 Outline

After the introductory section chapter 2 explains the theoretical background on which the workfow for systematic modelling and automatic creation of unit operations is based on. It also deals with publications related to systematic, equation-based modelling and implementation of CO interfaces. In an analysis of the as-is-state and target workfow in chapter 3, felds of work are defned to implement the improvements regarding the investigated modelling and code generation software MOSAICmodeling. These felds of work are picked up in chapter 4, explaining and implementing the concepts. Examples of successful application of workfow and automatic implementation are given in chapter 5. A discussion and evaluation of the achieved results can be found in chapter 6, especially taking into account the research questions and objectives. The developed workfow is set in a wider context, felds of further investigations and improvements of the prototypical implementation in MOSAICmodeling are pointed out. The conclusion (chapter 7) sums up the fndings of the whole thesis. In the appendices a user manual for the newly developed MOSAICmodeling editor is given, and several lists detail CO interfaces, XML schemas, database tables, Unifed Mod- elling Language (UML) diagrams, a full documentation of the examples, and the publications created in the course of preparing this thesis.

4 2 Theoretical Background and Related Developments

In chemical plants, substances are mixed, energy is added or removed, reactions occur, and fnally products are separated. The substances may be solid, liquid, or in gaseous state in arbitrary combination. One task of chemical engineers is to decide in which proportion the substances are mixed, which temperature and pressure is to be set, and how these settings have to change during production. Despite this simple principle the number of diferent substances that can possibly be used combined with the wide range of operating conditions lead to a huge number of potentially realizable processes. Operating companies have to produce in save and stable conditions and always look for improvements in the efciency of the processes. Main criteria are (besides costs in general) the amount of energy used (temperatures, pressures), less or cheaper educts, and avoiding emissions or undesired byproducts. There is always a need for new or improved process concepts, for example in case rare or toxic ressources shall be replaced by sustainable ones. Existing plants and concepts can be optimized or completely new processes can be developed. When it comes to capital investments in the order of hundreds of thousands of euros or more for such a new or refurbished process, no one will take the risk to build such a plant without being sure that this plant will actually produce what it is expected to do. This is why models of plants exist in computers. They do not only describe how to construct the plant and how to lay the pipes, but also how this process will behave when boundary conditions such as composition, temperature, or pressure change over time. The latter are models for simulation; their results provide information to decide, which apparatuses can be selected and which size they should have in order to fulfll the process goals. Simulation models predict the thermophysical behaviour of the process and therefore contain balance equations of conserved quantities (mass, energy, momentum) and relations regarding process equilibria (e.g. between liquid and vapor phase on a tray in a distillation column). Calculating the thermodynamic behaviour and related

5 2 Theoretical Background and Related Developments properties is usually one of the most time consuming parts in fnding a solution of a simulation model. In order to support process engineers in their simulation work, including the description of apparatuses (units), thermodynamics (property packages), and the solution process (numerics), useful tools for CAPE have been developed. When it became apparent that no tool is best in all aspects and that it makes sense to specialize in certain parts of the whole simulation, with CO a standard for the exchange and co-simulation of simulation models and property packages was developed. As this thesis is about automatised, easy-to-use implementation of the interfaces for CAPE, the following sections give an overview of these aspects that are essential for this work. Fig. 2.1 on page 7 gives a respective overview. Basic considerations about the measurement units, that have to be exactly defned in physical models to do proper calculations, are followed by an introduction of the concept of process unit operations as a representation of apparatuses. After describing the principles of the workhorse simulation tools (fowsheet simulators), the concept and history of the CO interface defnitions is covered, followed by a description of related developments regarding exchange of models, systematic modelling, and implementation of CO interfaces.

6 Flowsheeting Physical Properties Units of Measure Built-in unit operation - components - F in mol/s CAPE-OPEN unit operation - constants - T in K - calculation routines - p in bar

- ... - zi in mol/mol - ... (A)

F2, T2, p2, z2,i

(1) (B) (D) (C)

(3) F4, T4, p4, z4,i F6, T6, p6, z6,i (8)

g(x,u,θ)

F5, T5, p5, z5,i F7, T7, p7, z7,i numerics (solver)

Figure 2.1: Overview of relevant concepts for this thesis. In fowsheet simulators built-in unit operations can be combined with CO unit operations. Unit operations represent functional requirements such as distillation (A), pumping (B), or heating/cooling (D) and transform input information, energy, and material to respective outputs. With re-usable CO unit operations arbitrary customized requirements can be represented. The streams (1-8) entering and leaving the unit operations (A-D) mainly represent material fows, indicated by overall fow F , temperature T , pressure p and composition (molar fraction) zi. All these quantities have units of measurements. The physical properties of the material are managed with property packages containing information regarding the involved components including physical constants and calculation routines to perform e.g. equilibrium calculations. The underlying equation system (g) of the customized unit operation contains diferent types of variables: unknowns (x), design variables (u), and parameters (θ). Currently CO unit operations have to provide their own numerics to solve the contained equation system.

7 2 Theoretical Background and Related Developments

2.1 Units of Measurement

Units of measurement are systematically defned in the International System of Units (SI) and are closely related to the International System of Quantities (ISQ). The ISQ is defned by the international standard ISO 80000 (ISO, 2009), where the relevant terms (unit, quantity, dimension, etc.) are described. Com- mon programming languages in general do not have units of measurement as a build-in feature. This seems to be sufcient for most applications, otherwise they would. A recent Java Specifcation Request (JSR) specifcally adding the concepts of Units and Quantities to the JAVA programming language was accepted and is available online1. Although it was not added to the JAVA core, because of conficts with other standard defnitions regarding aspects of time, real-time and the defnition of a “second” that were considered more important than the introduction of SI, these eforts nevertheless were helpful checking the previously created, own solution developed for the purposes of this thesis. In the implementation section 4.1.2 a comparison of the custom solution approach and the standardization attempts follows.

Computers built and programmed for performing intensive mathematical calculations do not care if the numbers represent temperatures, pressures, or just numbers without any physical meaning. In the end it is the human being writing the executable code who is responsible to take care of the correct physical dimensionality of the quantities used in the model. In collaborations with shared program code or shared simulation models one has to agree which engineering units2 are to be used inside the collaboratively created model. This is especially important between groups of engineers using diferent sets of standard units, for example one group using engineering units based on SI and the other group using engineering units based on the imperial system. We see, when it comes to simulation of real world physical phenomena, the units of measurements must be considered to get precise, unambiguous descriptions of the chemical plants that engineers are modelling. That is why we have to defne what an engineering unit is and how the system of these units is structured.

First of all, some basic terms have to be defned, using the ISQ as a reference.

1https://jcp.org/aboutJava/communityprocess/fnal/jsr363/index.html date of last access: 2019-03-10 2Throughout this thesis engineering units are used as a synonym to units of measurement.

8 2.1 Units of Measurement

A quantity in the meaning of a physical quantity describes a physical property by relating it to a combination of a (real) number and a unit (of measurement). A unit always is of exactly one physical dimension, sometimes imprecisely called “quantity family”. Identical quantities can be expressed by diferent commbi- nations of numbers and units as long as the units (and therefore the quantities itself) are of the same physical dimension.

The units kilogram and pound are both of dimension mass, and setting the conversion factor to a fxed value of 0.5 the quantity “mass of the biggest potato bought last week in the grocery store” could be described by “0.182 kg” as well as by “0.364 lb”. Omitting the unit of a quantity changes the meaning and is only allowed for so-called “dimensionless”3 quantities. One example for a dimensionless quantity would be the number of nozzles of a tank. All the “physical dimensions” can be represented by the product of the powers of the base dimensions. Besides the mass used in the above example, the base dimensions are length, time, temperature, electric current, luminous intensity, and amount of substance. As special cases it makes sense to defne the additional dimensions angle, which could also be interpreted as dimensionless, and monetary value / currency / cost, which becomes handy modelling the economic feasibility of a plant. A partic- ularity of currencies compared to the other dimensions is the volatility in the conversion factors. While it is easy to convert masses as shown above, the exchange rates of currencies may change every single day, posing a challenge in introducing monetary values into modelling and simulation environment, as it will be shown later in the respective implementation section (4.1.2). These “non-standard” dimensions are not to be mixed up with so-called “derived” units. Base dimensions and base units are defned in the international system of units (SI), whereas derived units are composed by multiplying and dividing base units. Table 2.1 shows the seven base SI-units. One common example for a derived dimension/unit is the dimension velocity composed of the SI-dimensions length and time, or the SI-units “metre” and “second”, combined as “metre per second” or “m/s”, respectively. With the base dimensions it is possible to derive an infnite number of new dimensions, and not all derived dimensions have a clearly defned name like velocity or pressure. Even pressure is not a unique name as it is identical to the dimension energy per volume. This

3According to ISO 80000 the term “of dimension number” should be favoured over the deprecated “dimensionless”.

9 2 Theoretical Background and Related Developments

Table 2.1: Table of ISQ base quantities ISQ Dimension Related SI base unit Name Symbol Name Symbol Length L metre m Mass M kilogram kg Time T second s Electric current I ampere A Temperature Θ kelvin K Amount of substance N mole mol Luminous intensity J candela cd will later on pose a challenge in implementing the system of engineering units and making it available to the user of the modelling software extended in this thesis. Taking a look at modelling of physical processes, a signifcant part are physical property calculations. Functions calculating such properties often use some kind of correlation, valid only for a certain range of input values. Neglecting the engineering units of the involved quantities can lead to wrong or non-sensical results, in the best case raising an error instead of delivering misleading results. A typical example for such an error would be a function calculating the vapor pressure of a component, expecting a quantity of type temperature with the unit “◦C” to deliver a pressure with the unit “bar”. Now inserting a temperature with the unit “K” and expecting the returned result to be a value with the unit “Pa” would be valid from a dimensionality point of view, but wrong regarding the units. A large number of dimensionless quantities exist, where it is not obvious if it is possible to convert them from one unit to another. Mole fractions of unit “mol/mol”, angles of unit “rad”, and activity coefcients are all dimensionless, but a conversion from one into another does not physically make sense. Despite these complications, the engineering dimensions are one possibility to perform a frst consistency or plausibility check. The idea is to take an equation and compare the dimensions of the terms on the left and on the right hand side of the equal sign. If they are not identical, e.g. when a mass is on the left and an energy is on the right hand side, it is a hint that the equation is physically infeasible or at least not complete, yet. Another point to check for is that only variables of same dimension can be added or subtracted. Multiplication and division are no

10 2.1 Units of Measurement problem, however, because this is the way how derived dimensions are created (force is mass times acceleration,“F = m · a”). More complex, functional operations (exponential function, logarithms, sine, etc.) that use a non-dimensionless quantity as an argument have to be handled with care. In order to apply the consistency checks I recommend to use only dimensionless inputs to these functions. This is possible by explicitly introducing scaling or referencing quantities with a value of “1” and an engineering unit ftting to the actual argument. So the recommendation is to reformulate e.g. functional relations as “p = exp(T )” to be “p = pref · exp(T/T ref )”, with pref and T ref having the fxed value 1. This clean formulation can be widely applied to avoid the defnition of problematic units4 and can solve the problem of relations that otherwise showed an inconsistent dimensional setting5. Using this technique in equations reduces the number of engineering units and helps scaling all terms to be of similar order of magnitude (preferably “1”), in general leading to better numerical behaviour. In the CAPE-OPEN section I will return to this topic and see how engineering units and dimensions were defned in the interface defnition for simulation models in the area of computer-aided process engineering.

4e.g. eK or ln(P a) 5What dimensions do p and T have in p = exp(T )? It cannot be pressure and temperature! This equation can only be consistent with quantities of dimension number.

11 2 Theoretical Background and Related Developments

2.2 Unit Operations in Chemical Engineering

Units of measurement as covered in the previous section are not the only “units” relevant in computer-aided process engineering. As a representation of real-world apparatuses, so-called “unit operations” are at a methodologic, abstract level even more important. It can be assumed that the complexity of modern plants and processes exceeds the amount of information a single human can handle and understand. The overall process is therefore split into smaller pieces, sub-processes. From a functional point of view this is reduced to a level of basic functions like “heating”, “cooling”, “pressure change”, and “mixing” (compare to the overview in Fig. 2.1 on page 7). Realising these functions implies implementing apparatuses and machines (i.e. assets) in the plant that actually perform these tasks, e.g. heat exchangers, pumps, and tanks with stirrers. Unit operations are the frst part of the asset lifecycle comprising of the four steps functional requirements, functional design, asset specifcation and asset in operation (Wiedau et al., 2019). A non-trivial example for a typical unit operation is a distillation column for the separation of a mixture of two or more components. The mixture, called “feed” is inserted in the middle of the column, extracting the “lighter” fraction A at the head of the column, and the other, “heavier” fraction B at the bottom. The basic idea of unit operations in chemical engineering is reducing complexity by separating a process into to well-defned sub-processes, and apparatuses. This approach, the decomposition to basic functions on the one hand and the aggregation to whole systems in the other hand, can be applied not only in chemical engineering, but to complex systems in general. This is equivalent to computer science’s principles of “divide and conquer” and “separation of concerns” (Dijk- stra, 1982). For changing pressure and temperature level of a liquid fowing through a pipe it is common to have two apparatuses (pump, heat exchanger) for the two functions, but there is of course not always a one-to-one relation between function and apparatus. The function “heating a stream to a certain temperature level” can be distributed to several heat exchangers in a row, another function “reaction of components A and B to component C” can be distributed to several stirred tank reactors in parallel. On the other hand more than one function can be combined in one apparatus, for example in reactive distillation columns or membrane reactors where reaction and separation can be combined. The latter examples go in the direction of “process intensifcation”, a promising approach

12 2.2 Unit Operations in Chemical Engineering for new process concepts that nevertheless increases complexity on the level of unit operations, see Stankiewicz and Moulijn (2000) for an inspiring overview. These intensifed unit operations cannot be assumed a standard such as pumps and simple heat exchangers6 and always require deeper understanding of the thermophysical efects taking place in the unit. A common feature of all kind of unit operations is the input-output character: fows of material in certain conditions come in and fows of material in changed conditions go out. With this modular concept it is possible to use a manageable amount of unit operations connected with streams or apparatuses connected with pipes, to compose a myriad diferent processes of high complexity. This way in- venting new chemical process concepts does not become “reinventing the wheel”, but using the “wheels” in ever new combinations and operation conditions. Unit operations are the main way to structure process models in a systematic way. That is why they play such an important role in most used simulation environments in process engineering, the so-called fowsheet simulators, and why the CAPE-OPEN standard was developed to exchange models of unit operations between diferent simulation tools.

6When starting to model the internal behaviour of heat exchangers including phase changes, this picture changes and heat exchangers become complicated models that are no standard anymore, especially when dealing with dynamic, time dependent phenomena.

13 2 Theoretical Background and Related Developments

2.3 Flowsheet Simulation

2.3.1 Basic Ideas

The basic idea of fowsheet simulators is guiding their users through the modeling process by visualising the unit operation concept. Additionally, they help defning the setting and constraints of the process. This includes the selection of involved chemicals/components and their related physical properties as well as the operating conditions of the whole process, especially the conditions at the inlets. The approach is intuitive and well proved. The real process is mapped to the abstraction of boxes connected with arrows, where the boxes stand for the apparatuses or unit operations and the arrows stand for the pipes or streams7 connecting the apparatuses respectively unit operations (compare to the overview in Fig. 2.1 on page 7). A fowsheet simulator ofers standard unit operations such as splitter, mixer, pumps, heat exchangers, distillation columns, and more out of the box. These units are easy to confgure and already allow for many process concepts to be simulated. When all the inlet conditions of the process are specifed and the adjustable parameters of the unit operations are selected, the simulator will calculate the physical properties of all the connecting streams. This includes at least the amount of substance fowing and its composition, the temperature, and the pressure of all streams between the unit operations and of the process outlets. In the end the user gets information about the internal process conditions and the products, including the amount of heat and energy needed to run the plant under the given process specifcation. This can be used to give a frst estimation of the feasibility of the (new) process concept under investigation.

2.3.2 Physical Properties

Flowsheet simulators are made for process engineering, where substances are converted regarding temperature, pressure, and composition. So one step to be performed in each and every fowsheet simulation is the defnition of the participating substances. The involved components can have varying values for relevant properties, so it is important to specify them as precisely as possible. It would make no sense to try to simulate a distillation column to separate isomeres of a hydrocarbon like iso-butane and n-butane if it is not possible to

7Besides material streams arrows can also represent energy fows or fow of information (e.g. signals).

14 2.3 Flowsheet Simulation distinguish between the two inside the simulator. As described in the previous sub-section a library of unit operations is commonly available in simulators. An even more important point is the existence of a proper physical description of the substances, especially when it comes to the properties of mixtures of several components. In order to get the necessary thermodynamic properties, functions are usually called that directly read values from a database or use polynomials in combination with component specifc coefcients to calculate the desired set of temperature, pressure, and composition. Here the databases of the diferent simulators will difer regarding the number of supported substances and mixtures in combination with the strategy to calculate derived properties. A large, simulator- independent database is the Dortmund Data Bank (DDB), containing “nearly all worldwide available phase equilibrium data, excess properties, transport properties and pure component properties even for polymer and electrolyte systems” 8. Choosing an appropriate strategy (e.g. for phase equilibrium calculations NRTL (Renon and J. M. Prausnitz, 1968), Soave-Redlich-Kwong (Soave, 1972), Peng- Robinson (Peng and Robinson, 1976), UNIFAC (Fredenslund, Jones, and John M. Prausnitz, 1975), UNIQUAC (Abrams and John M. Prausnitz, 1975), PC- SAFT (Gross and Sadowski, 2001)) is the task of the user. Without understanding of the underlying principles, but choosing one of these strategies randomly, the results will not be trustworthy. That is why it is important to have qualifed users that know the limitations of the strategies and know which strategies to use in which circumstances. Simulators likely spend most of the simulation time dealing with the calculation of the properties of multi-component systems including their partial derivatives with respect to the state variables. A user may be tempted to try diferent physical property systems (i.e. strategies) and choose the fastest one, but, as stated above, this may lead to results that are as useful for feasibility statements as random numbers. Having a wide range of substances available and being able to add missing parameters to the physical properties system are crucial criteria when it comes to innovative process concepts with seldomly used substances and substances used in unusal combinations. As we will see later, this is also one main point in the CAPE-OPEN standard for exchange of process models besides the unit operations: the neatless integration of physical property managers of diferent

8http://www.ddbst.com/ddb.html date of last access: 2019-03-10

15 2 Theoretical Background and Related Developments vendors. Such specialised software vendors, that focus on the description of certain sets of components, may be the only sufciently exact source for physical properties under investigation in the process simulation.

2.3.3 Solving a Flowsheet

Selecting the list of compounds used in the simulation, adding unit operations to the fowsheet, connecting the units with streams, and setting the conditions of the process inlets does not directly give a solution of the model. The fowsheet has to be solved. In this case solving means calculating the properties of all streams involved in the current process, given the inlet conditions and settings of all the unit operation blocks. The outlets (i.e. outgoing streams) of a unit operation block can be calculated when the inlets (i.e. incoming streams) are defned or have been calculated in a previous step. This leads to one possible, trivial algorithm of how to solve such a fowsheet: take all unit operations with given inlet conditions, calculate their outlet streams, and check which other unit operations can now be calculated (as the outlet of one unit operation is the inlet of the next unit operation). The values of the outlets are the results of the calculation of the respective unit operation. Repeat this until all unit operations and therefore all streams have been calculated. Improving this sequential modular strategy is investigated for more than 30 years as publications e.g. by Kisala et al. (1987) and Montagna and Iribarren (1988) show, not to mention the work of Wegstein (1958) dealing with the acceleration of the iterative solution process in the 1950s. Block-sequential algorithms are very intuitive, as long as you do not need to force fxed values for the resulting outlets or do not have a circular process. The frst example contradicts the guideline of “outlets are calculated, inlets are given” by setting the output and calculating the inlet. This disregards the principle of causality in the fowsheet. One way of solving such a problem is performing a lot of simulation runs with varying inlet conditions until the resulting outlets are as expected. This is not a common simulation anymore, but kind of an optimization problem with the objective “minimise deviation from the wished outlets results by varying the inlet conditions”. This is a drawback of the block- sequential structure compared to an approach solving all the unit operations simultaneously (by composing a large equation system of all underlying systems of equations). In a simultaneous, equation-based approach for solving a steady- state system the variables to be calculated can be chosen freely as long as no linear dependency is introduced and the number of unknown variables matches

16 2.3 Flowsheet Simulation the number of equations. The second example (the circular process) will make the simple algorithm sketched above fail, as soon as there is no unit operation anymore with all inlet conditions specifed before every unit has been calculated, because any unit operation frst has to wait for the results of another unit operation before all its inlets are specifed. In order to solve such a circular process, one or more streams have to be temporarily cut to remove the circular dependencies. When initial guesses for the torn streams are provided, it is possible again to calculate the outputs based on the inputs (and the guess values). As soon as the unit operations having the torn streams as output are solved, the calculated results can be compared to the initial guess values. As long as there is a non-neglectable diference the guess values will be updated and the next iteration is started until in the best case the algorithm converges and all streams are consistent. There is however no guarantee for convergence and solution strategies (e.g. how to update the initial guesses) are a separate area of research, see e.g. Kulikov et al. (2005). The question which streams to cut best is not trivial. One aspects to consider is the number of unknown variables that have to be specifed when tearing a stream. In this regards the number should be as small as possible, because for each variable a good starting value has to be set. Usually the number of torn streams is positively correlated to the number of variables an initial guess has to be provided to, so one heuristic is to reduce the number of cuts in the circular process. Another aspect when manually choosing the streams to tear takes into account the process knowledge. In this regard the streams that can be estimated best in advance should be cut. As good initial guesses in general reduce the number of iterations in the recycle, one rule of thumb is that the algorithm will converge faster when the diference between the guess and the solution is minimal. When the starting values provided to the solver are not close to a (real, physical) solution, it becomes more likely that the algorithm needs many iterations or does not converge at all. Finding an initial guess that is inside a solution’s region of attraction is highly problem dependent. This becomes more important the more nonlinearities are present in the mathematical description of the process. Unfortunately the purpose of computer simulations of a process often is to improve understanding of its behaviour, so at the beginning it cannot be expected to know a solution of the simulated process in advance (otherwise we would not need the simulation). You know that you selected a sufciently good

17 2 Theoretical Background and Related Developments set of initial guesses close to a solution, when the solution algorithm converges. The advice “choose the starting values close to the solution of the process with the given operating conditions” is correct, but not helpful, when the solution- to-know is the result of the simulation. A typical approach to overcome these challenges of initialisation is starting with a more simplifed model (e.g. without a closed recycle or with a reduced number of components) to get an idea of the region of the solution. The complexity is increased step by step, recycles are closed, and the number of involved components increased, until the desired level of detail and complexity of the process model is reached. One example of a vendor advertising advanced solution strategies in this regards is the company Process Systems Enterprise (PSE)9.

2.3.4 Customizing of Unit Operations

One part of the success of commercial fowsheet simulators is the library of standard unit operations directly available. As described in the section about unit operations in chemical engineering, many complex processes can be described using a combination of basic unit operations like heat exchangers, pumps, mixers, splitters, reactors, columns, and more. These units have been on the market for a long time, were therefore tested many times, and could prove their reliability. But no library could contain all unit operations imaginable. So, when it comes to the design of innovative processes with unit operations integrating features not present in the standard library, simulation tools have to ofer other options. There are three distinct possibilities fowsheet simulators can integrate novel or customized unit operations:

1. highly customizable standard units

2. tool inherent, freely defnable units

3. using a standard interface to include external units

These three options difer in the knowledge the simulation environment has about what is actually going on inside the integrated unit operations. In option 1 for example, the simulator could provide a unit operation modeling a column with a vast number of customizable features, making it highly versatile for diferent kind of applications. But it still is a column and when the fowsheet is solved,

9https://www.psenterprise.com/concepts/equation-oriented date of last access: 2019-03-10

18 2.3 Flowsheet Simulation the algorithm can take into account this information and therefore automatically apply appropriate solution techniques. The second option is to ofer a means to freely defne any kind of unit operation inside the simulation environment. In this case the simulator does not know anymore, which kind of apparatus is modeled, but the solver may still have access to the set of variables and equations describing the unit’s behaviour. Since the unit is developed inside the simulation environment (suite), compatibility of fowsheet and unit operation can be assumed. An example of such a feature is Aspen Custom Modeler (Aspen Custom Modeler 2019), an additional part of the Aspen suite ofered by the company AspenTech10. It uses its own language to defne custom unit operations that can be integrated into Aspen fowsheets (e.g. Aspen Plus (Aspen PLUS 2019)). These models of course can only be directly used in conjunction with tools of the Aspen suite, not with other vendors’ process modelling environments. The third option, a standardized interface, is the option where the external unit operation is integrated independent of the software the unit was created in. Physical properties and solvers (or the equation system) could be handed over using the interface, too. Details about these options follow in the CAPE-OPEN section. In fact, at the moment the physical properties can be used consistently across the interface even within external unit operations, in contrast to solvers, that have to be included in the external unit. For the fowsheet’s solver the external unit is like a black box. The unit’s solving routine is called when all inputs are set and after waiting for the calculations to have fnished, control returns to the process modelling environment and the next unit will be called. The algorithm how to get a solution of the external unit’s equation system must be built into the unit operation itself, before it is compiled and added to the fowsheet. Another example of a process modelling environment with its option to create customized models of unit operations are the so-called “User Added Modules (UAMs)” of Chemstations’ fowsheet simulator CHEMCAD11 (ChemCAD 2019). In their approach a combination of options number two and three is applied. On the one hand the units defned by the user can only be integrated and executed within this particular simulator because of the non-standardized specifcation (option two). On the other hand a standardized, multi-purpose programming

10https://www.aspentech.com/ date of last access: 2019-03-10 11https://www.chemstations.com/CHEMCAD/ date of last access: 2019-03-24

19 2 Theoretical Background and Related Developments language (C++) has to be used and a separate solver has to be integrated into the code (option three). All three options have diferent benefcial attributes, and eventually the user has to decide, which option fts best to reach a certain goal. In the end, when it comes to future-proof, highly customized unit operations investigating new phenomena and solution algorithms, that have to be re-used and compared in diferent process modelling environments, only the option using standardized interfaces fulflls these requirements. This is why in this thesis an automatised workfow to implement such a standardized interface is developed and demonstrated.

20 2.4 CAPE-OPEN

2.4 CAPE-OPEN

CAPE-OPEN (CO) is a standard for the exchange of Process Modelling Com- ponents (PMCs) such as unit operations and thermodynamics, across Process Modelling Environments (PMEs) like fowsheet simulators. The name is composed of two terms, CAPE and OPEN. CAPE is the acronym for “computer aided process engineering”, whereas OPEN stands for the open, free-to-use nature of the standard. CO standardizes the way how PMCs are interfacing PMEs or other PMCs. The interface specifcations are maintained by the CAPE-OPEN Laboratories Network (CO-LaN) and are available online12. A list of all interfaces can be found in appendix A.

2.4.1 History and Ideas

The journal article by van Baten and Pons (2014), two experts with in-depth knowledge of the technology and history of CAPE-OPEN, gives an overview of the origins of the standard, the motivation for CO, and the industrial relevance. They describe the development from frst ideas in the early 90’s, over european (1997-1999) and global (1999-2002) projects, including the founding of CO-LaN in 2001, until the releases of the frst standard specifcation (2002) and an important update of the thermodynamics specifcation (version 1.1) in 2006. CO-LaN “is the nonproft organization that is responsible for updating, maintaining and publishing the CAPE-OPEN specifcation (van Baten and Pons, 2014, p. 1053)”. In 2018, its board of directors13 having all of the powers of the CO-LaN consists of representatives of the six full member companies Air Liquide, BASF, BP, Dow, Linde Engineering, and Shell. Software vendors, administrations, academic institutions, and individuals can be associate members, but have no votes in CO-LaN’s annual general meetings. The maintenance and improvement of the standard defnitions is done by Special Interest Groups (SIGs) that each focus on topics identifed as important in the respective area, e.g. unit operations and thermodynamics.

The idea behind CO is to enable interoperability between several process simulation tools by specifying one set of interface defnitions, that allows information exchange between unit operations, thermodynamics, process modelling environ-

12http://www.colan.org/specifcations/ date of last access: 2019-03-10 13http://www.colan.org/board-of-directors/ date of last access: 2019-03-10

21 2 Theoretical Background and Related Developments ments, and numerical solvers (Braunschweig et al., 1999, Belaud, Braunschweig, and White, 2002). A short description of the four main groups of interface specifcations is given in following subsections. Diferent parties beneft by this approach in contrast to a world where all pieces of software do only support own, proprietary interfaces:

• small software vendors and individuals selling or producing their own PMCs only need to implement a single interface instead of implementing several interfaces for each possible process modelling environment;

• operating companies can choose from a wider range of interoperating pieces of software and thus can avoid a vendor lock-in;

• larger software vendors can sell a future-proof platform for many special- ized PMCs without developing them themselves and therefore can ofer their customers even more benefts regarding process simulation and optimization.

Products by AspenTech, Invensys, and Honeywell are amongst a non-exhaustive list of commercial PMEs that implement support for CAPE-OPEN as of 2014 that can be found in van Baten and Pons, 2014, p.1055. The open nature of CO allowing its use without license fees or registration makes it impossible to give exact numbers on how wide-spread CO actually is and how often it is applied in productive use, but a critical mass appears to have been achieved that CO can be considered well-established (van Baten and Pons, 2014, p.1062). So far, all implementations of CO have to be developed using either Compo- nent Object Model (COM) or Common Object Request Broker Architecture (CORBA) as middleware. An important step in the evolution of CO is the CAPE-OPEN Binary Interoperability Architecture (COBIA). COBIA shall act as a new bridge between software components that is independent of a certain middleware. This way some unnecessary overhead related to the middleware can be avoided and the implementation will be simplifed. With COBIA all legacy COM-based CO implementations will be supported in a way that no reimple- mentation of already functioning COM components is necessary. On the other hand, a CORBA/COBIA interoperability is not anticipated, as CORBA is practically never the underlying middleware in productive CO use.14

14http://www.colan.org/experiences-projects/cape-open-binary-interop-architecture-cobia/ date of last access: 2019-03-10

22 2.4 CAPE-OPEN

As of October 2017 the second phase out of three of the COBIA development is well on its way, allowing frst COM-independent implementations on Windows platform. In the last phase other platforms and inter-platform interoperability is planned. (van Baten, 2017)

2.4.2 CAPE-OPEN Unit Operations

The CAPE-OPEN Unit Operation is defned as a business interface and on CO- LaN’s website15 its specifcation can be found. The current specifcation document was issued in August 2012 whereas an Errata & Clarifcation document dated March 2015 provides three corrections of the specifcation document and clearifes several issues that may be ambiguous in interpretation. The ofcial summary of the unit operation interface specifcation is given in appendix A. As the CO unit operation specifcation is of major importance for this thesis, some additional remarks are given here.

The specifcation document defnes that each CO Unit Operation has to implement the interface ICapeUnit, see Fig. 2.2 on page 24. This includes functions to get the ports of the unit, to validate the unit, to get the validation status, and to calculate the unit. The ports are defned in an additional interface (ICapeUnit- Port), stating that they have a type (material, energy, information), a direction (in, out, or in/out), and can connect to or disconnect from a stream. By implementing the utilities interface (ICapeUtilities), unit operations also have a set of parameters. These parameters are a means to customize the unit operation by on the one hand providing additional input information that is not given by any input port (typical example: geometry of a reactor) and on the other hand making additional values available that are not directly delivered via output ports (typical example: operating costs of a reactor). The parameters of unit operations are explicitly public parameters that the user of the unit operation is allowed to vary. Private parameters that should never be altered by any user of a unit operation should therefore not be part of the parameter set available when calling the getParameters function of the unit. It is possible to set parameter bounds preventing the user to set infeasible values to the parameters, so when for example a split factor has to be between 0 and 1, a value of “2” can

15http://www.colan.org/specifcations/unit-operation-interface-specifcation/ date of last access: 2019-03-10

23 2 Theoretical Background and Related Developments

ICapeUnit ICapeUnitReport +GetPorts() +GetReports() +Validate() +GetSelectedReport() +GetValStatus() +ProduceReports() +Calculate() +SetSelectedReport()

ICapeUnitPort ICapeUtilities +Connect() +Edit() +Disconnect() +GetParameters() +GetConnectedObject() +Initialize() +GetDirection() +SetSimulationContext() +GetPortType() +Terminate()

Figure 2.2: CO interface defnitions related to unit operations. The functions most relevant for this thesis are highlighted with a bold font.

be refused. In order to deliver reports a unit operation has to implement the report interface. Reports are produced and delivered upon request and usually summarize the results of the last calculation. The validation of the unit operation has to take place before the calculate function is called and is necessary whenever the unit was edited, a parameter was changed, the property package confguration has changed (e.g. diferent number of compounds), or a stream was connected or disconnected from a port. If validate has not been called and the validation status is not set to “valid”, calling calculate will not be successful. The calculate function is the core function of the unit operation where all calculations considering the public parameters and inlet conditions take place to set the outlets of the unit. The CO specifcation prescribes that the unit has to bring the outlets into thermodynamic equilibrium before setting the output values, fnishing the calculate function, and returning control to the fowsheet environment (PME). All the values of parameters, inlet quantities, and outlet quantities are basically interpreted as numbers (foating point or integer) without an engineering unit16. The engineering units of the material properties (e.g. pressure, temperature) are by default interpreted as units according to SI. As parameters can be the representation of any piece of information, there can be no default unit of measurement for these. As soon as a unit operation provides parameters that are

16This is equivalent to interprete them as “of dimension number”

24 2.4 CAPE-OPEN not dimensionless, it is necessary to tell the user which unit of measurement is expected when setting the parameter value. This shows the need of a concept of engineering units for anyone implementing a CO unit operation with parameters.

2.4.3 CAPE-OPEN Thermodynamics and Physical Properties

The Thermodynamics and Physical Properties interface specifcation is defned as a business interface and on CO-LaN website17 its specifcation can be found. It is the only interface specifcation of all CAPE-OPEN interfaces so far, that has two diferent versions (1.0 and 1.1) where both versions are still in use. Thermo 1.1 was issued in 2011 after reviewing the former version 1.0. The clarifcations “seemed important enough to justify a new document17.” For new implementations the use of thermo 1.0 is discouraged and thermo 1.0 is marked deprecated. An ofcial comment regarding version 1.1 of the thermo interface specifcation is given in appendix A. The thermo specifcation defnes interfaces that can be implemented by diferent CO components. The term “component” is in this context defned as follows: “A piece of software whose functionality is accessed via specifed interfaces, which can be deployed independently of other software and which can be used in the composition of other software systems without modifcation.” The standard distinguishes between four components:

• Physical Property Calculator - a software component that can calculate Physical Properties

• Equilibrium Calculator - a software component that can calculate the composition of mixtures at equilibrium

• Property Package - a software component that combines the function of a Property Calculator and an Equilibrium Calculator. A Property Package will provide compound constants and may also provide universal constants

• Property Package Manager - a software component that manages a set of Property Packages

For a CO Unit Operation there is no need to implement these components. It is only important to use the interfaces provided by these components in order

17http://www.colan.org/specifcations/thermodynamics-and-physical-properties-interface- specifcation-v1-1/

25 2 Theoretical Background and Related Developments to communicate with the property package. “Communication (...) requires the exchange of data describing the Material for which calculations are required. (...) A Material Object is a software object that is responsible for holding the data describing the state of a Material. Each client that uses CAPE-OPEN Thermodynamic and Physical Properties components must provide its own implementation of a Material Object because the confguration and data storage used in a Material Object will be diferent for each client (CO-LaN Consortium, 2011).” So each CO Unit Operation has to implement its own Material Object to use the inlet stream information and write the results of the calculations to the outlet stream(s). The standard defnes several property identifers, for

• universal constants,

• pure compound constants,

• temperature-dependent pure compound properties,

• pressure-dependent pure compound properties,

• non-constant single-phase mixture properties, and

• non-constant two-phase properties.

These items represent all properties listed in the specifcation document, so there are explicitly no identifers defned for three phase properties. The units of measurement for all properties are base SI units, so for quantities that are not of dimension number specifying the dimension is sufcient to determine the actual engineering unit. Whenever a CO Unit Operation uses a property package to get thermodynamic data (alternatively it could calculate it on its own without relying on another component), it has to be ensured, that the unit operation has to convert the values of the property package if a non-SI unit of measurement is expected in the unit operation’s calculation routine.

2.4.4 CAPE-OPEN Numerics

The Numeric interface specifcation consists of two specifcation documents that are defned as business interfaces, the frst one is “Numerical Solvers18”, and the

18http://www.colan.org/specifcations/numerical-solvers/

26 2.4 CAPE-OPEN second one is “Partial Diferential Algebraic Equations19”. The specifcation for numerical solvers was created in the frst CAPE-OPEN project and dates back to 1999. No revision has been applied since then and there is no SIG assigned with maintaining the specifcation. This business interface specifcation is about solution algorithms of stationary and dynamic simulations. The systems under consideration are Nonlinear Algebraic Equation Systems (NLEs) and Diferential Algebraic Equation Systems (DAEs). Infor- mation regarding equations, variables, and derivatives is specifed and handed over within a so-called Equation System Object (ESO). It is the numerical interface specifcation equivalent to the Material Object of the CO Unit Operation specifcation. The specifcation for partial diferential algebraic equations is based on the specifcation for numerical solvers and extends it with a description of systems including variables that are distributed on more than one temporal/spatial dimension. This way models of computational fuid dynamics are covered. The defnition of this PDAE specifcation was created in the global CO project and f- nally published in 2003. Like the numerical solvers interface it has never changed since. There is no SIG taking care of revising this specifcation. The idea of the CO Numeric Interfaces is enabling the exchange of equation system information in order to make it available to external solvers. The ESO is the means for handing the equations and variables over to a solver component responsible for calculating a solution. This concept allows for using special- ized algorithms that are not shipped with the unit operation or the PME. The only implementations and publications of the Numeric specifcation known to the author date back to the early 2000s (Schopfer et al., 2005) and were done by members of an institution involved in defning the standard. In contrast to basically all other implementations of any CO Unit Operation or Property Pack- age the middleware chosen was CORBA instead of COM. This implementation coming from an academic institution (RWTH Aachen) seems to be unique, and the fact that there has been no revision of the standard for more than eighteen years is a strong hint that it is very unlikely to fnd an implementation of these interfaces inside any widely used fowsheet simulator. In line with the specifcation of COBIA a decision will be made if the Nu- meric specifcation should be removed because of the basically non-existing implementations in proprietary software. If it had been relevant for the business

19http://www.colan.org/specifcations/partial-diferential-algebraic-equations/

27 2 Theoretical Background and Related Developments of the companies represented in the CO-LaN Management Board, there would be no question to keep it. Keeping the specifcation artifcially alive would bind ressources in SIGs that could be spent on interface specifcations that are actually used in practice and where a lot of experience exists. On the other hand, from the research point of view it is of course desirable to keep and revise the Numeric interface specifcation. The topic of improved analysis and solution algorithms of nonlinear equation systems of chemical engineering’s typical unit operations is of current interest, as publications of the last years show (e.g. Bublitz et al., 2017, Baharev, Domes, and Neumaier, 2017). Without an implementation in an available process simulator it will nevertheless be difcult to test and apply own solver developments in practice. Because of the lack of experiences in implementing and using the Numeric specifcation it is unclear if it is possible to use a CO Unit Operation with a Numeric PMC independent of the PME’s Numeric’s support status. A combination of unit operation and solver independent of the PME would prevent a situation where all users have to wait for the PME vendors to implement the numerics package; so this is an aspect worth investigating in case the CO Numeric specifcation will be kept alive within COBIA.

2.4.5 CAPE-OPEN Common Interfaces

The Common Interfaces include six interface specifcations that are used within the business interfaces. Examples of specifcations being part of the common interfaces package are error handling, collections, and parameters, that are all used within implementations of unit operations. A detailed description of these support interfaces is left out here, but a full listing can be found in Appendix A and online on CO-LaN’s specifcation homepage20.

2.4.6 Critical Acclaim

From the perspective of companies simulating processes, CO promises to tackle the problem of the so-called vendor lock-in. A vendor lock-in occurs, when a company uses software of one vendor and stores data in this vendor’s proprietary format and the costs of changing to another software vendor are very high. The operating company in this case sufers from a local software monopoly and is locked in this situation. Whenever the company decides to change to another

20http://www.colan.org/category/specifcations/commoninterfacespecifcations/ date of last access: 2019-03-10

28 2.4 CAPE-OPEN software vendor, all data has to be entered again in the new software because the proprietary format of the previous software is a black box for all programs not distributed by the vendor of this format. When the company uses software that supports CO, the data (i.e. simulation models) can be used in any CO- compliant fowsheet simulator. This way changing to another CO-compliant simulation software at least makes the model available as it is. Changing and extending these simulation models goes beyond what CO is meant for, as it is not possible to manipulate an existing CO component on source code level, because of the compiled nature of CO PMCs. Operating companies can beneft from CO by making third party modelling components available for interoperability. This way it may be possible to select only the parts of a software suite that are actually of use and that can be connected to other CO-compliant components, instead of always buying licenses for the biggest available software bundle. CO interface defnitions are freely available as human-readable text, but implementations are compiled, binary fles, making it impossible to directly read the content and have a look inside the source code. The CO unit operations are encapsulated; this encapsulation is interesting for software vendors focussing on the creation of highly specialised unit operations, because their unique knowledge is protected. They provide the special models to their users, who can use (execute) the unit operation, but cannot read or even manipulate the underlying equation system or algorithms. As long as CO is established, it will be hard for a vendor of fowsheet software to create a monopoly. Having choice of which software to use is in general what operating companies looking for the most appropriate fowsheet simulators want.

One point of criticism regarding the applicability of CAPE-OPEN on diferent platforms is the pseudo-independence of the underlying operating system. The interface defnitions are written down in english text and UML diagrams, but in order to implement the defnitions at one point a middleware is needed to manage the communication between the CO components. At the time CO was developed two middleware approaches were available: COM for Microsoft Win- dows operating system and CORBA for any architecture or operating system, e.g. Linux. Because of the fact that all big commercial fowsheet simulators are basically restricted to be used on computers with Microsoft Windows operating system, there is no known commercial CORBA implementation of e.g. unit

29 2 Theoretical Background and Related Developments operations in productive use. A development in direction of fowsheet simulation on Linux operating systems worth mentioning is DWSIM21, an open-source fowsheet simulator by Daniel Wagner, winning the CAPE-OPEN award 2012 for implementing the frst open source fowsheet simulator compliant to CO22. Un- fortunately the CO features of DWSIM are still restricted to Microsoft Windows and COM. From the perspective of free software the expectations on CORBA were not fulflled and it does not play an important role as expected in the late 1990s (Henning, 2006, Coatta, 2007). Eventually with the development of COBIA the strong dependence on the Microsoft Windows operating system is reduced (see section 2.4.1). Another point one needs to be aware in the defnition of the interfaces is related to the application of Physical Properties Packages. Having a CO-compliant property package means that it is possible to have a communication between this property package and another CO component; it does not mean that all the physical properties needed for a certain application are actually available. As CO only describes the interface for communication, not the actual information content, it is obvious that CO cannot guarantee for the content. Therefore it is inevitable to read the user’s manual of the property package at hand or to have contact to the vendor of the property package in order to be clear what coverage can be expected. The work on the CO standards continues: new specifcation are in development, old specifcations are clearifed or are marked deprecated, and unused specifcations can be withdrawn. The specifcations for CO Numerics are candidates for the latter option. The ideas infuencing CAPE-OPEN are widely accepted, otherwise there would neither have been a european nor a global initiative. The annual CO meetings are a discussion platform where an exchange between software vendors and operating companies is stimulated: there are software companies that regularly demonstrate new, improved implementations of the standard and the SIGs consist of members of operating companies as well as software vendors.

The average process engineer is not expected to have the experience and knowledge to implement the CO standard on its own to get a CO unit operation in reasonable time to execute it in a CO-compliant PME. In the author’s view the

21http://dwsim.inforside.com.br/ 22http://www.colan.org/category/cape-open-awards/

30 2.5 Related Developments burden of having to implement the standard yourself in order to get your own models running in a CO-compliant fowsheet poses a considerable threshold in using CO at all for highly innovative and specialised unit operations. Instead, mainly the standard units of the fowsheet simulators are used. Even the simulator’s freely customizable unit operations seem to be easier to use, as each software vendor can provide a manual for its own software describing how to implement a unit operation in this particular software eco system. Additionally, paying users can ask the vendor’s support for help. There is no such support for end users of CO, as many multi-purpose programming environments can be used to implement CO. There only is a CO forum, where you can ask specifc questions and in the author’s experience you get quick responses. Unfortunately in order to ask the right questions, you have to have an idea of what you do not know; as there is no handbook of CO and no online course systematically explaining the CO eco system and how to implement unit operations, acquiring the knowledge about implementation by asking specifc questions is very cum- bersome. Only very few process engineers will have time to become acquainted during daily business.

With this thesis manual, tidious, and error-prone implementation shall be replaced by a workfow including automatic implementation of CAPE-OPEN Unit Operations. In the end, in-depth programming knowledge in C++ or similar languages is not mandatory anymore. This will lead to a signifcant reduction of the “time-to-simulation”, meaning the time needed to get a highly special- ized unit operation running in a CO-compliant fowsheet environment when the model of the unit is given in an equation-oriented way. What originally would need several weeks or months, shall be done in one day, assuming a user manual and examples or a tutorial are given.

2.5 Related Developments

The objectives of this thesis mainly include an approach for systematic modelling, exchange of simulation models, and the automatic implementation of CAPE- OPEN unit operations. This chapter gives an overview of related publications of other authors to these topics. It will show that many single examples exist, but systematic modelling towards automatic implementation of CO unit operations has not yet been investigated in such detail.

31 2 Theoretical Background and Related Developments

2.5.1 Functional Mockup Interface

An important alternative approach for model exchange and co-simulation not fo- cussed on process simulation, but dynamic simulation in general, that has to be mentioned here is the Functional Mockup Interface (FMI) standard23. Compara- ble to CO twenty years ago, the FMI standard started with a European project in 2008, with the outcome of the defnition of a new standard to exchange models from diferent simulation environments24. An overview of the development history, application, and future developments was given at a Modelica conference in Japan in May 2018 (Junghanns and Blochwitz, 2018).

2.5.2 Systematic Modelling

MOSAICmodeling, the tool introduced and analyzed in chapter 3, is developed at the Process Dynamics and Operations Group at TU Berlin and supports a systematic modelling approach for building systems of equations. This group is not the only one dealing with systematic modelling in chemical engineering. For example, at the Norwegian University of Science and Technology (NTNU) in Trondheim, Prof. H. Preisig and his Process Systems Engineering group developed another interesting approach. Constructing and maintaining proper process models (Preisig, 2010), Visual Modelling (Preisig, 2014), and Constructing Pro- cess Models systematically (Preisig, 2015) are three examples of recent work dealing with a systematic, visual construction mechanism to create proper process models. This modelling system is used in teaching and research and helps to fnd a common understanding when talking about real world properties that have to be mapped to a mathematical model. The visual aspects of this approach are a convenient way to deliver the aforementioned information. When it comes to generation of code for model simulation, the underlying ontology shows its strength in transforming the model description in code for diferent languages. A description of the research felds is given on the group’s homepage25.

23https://fmi-standard.org/ date of last access: 2019-03-09 24https://fmi-standard.org/history/ date of last access: 2019-03-09 25http://folk.ntnu.no/preisig/ date of last access: 2019-03-09

32 2.5 Related Developments

2.5.3 Interoperability and Implementation of CAPE-OPEN

Several publication of the last ffteen years dealt with the implementation of CO and interoperability of heterogeneous modelling and simulation environments. In 2002, Köller and Töbermann published, as a result of the global CO project, a CO migration cookbook as a manual when and how to migrate legacy software to CO (Köller and Töbermann, 2002). One part of the global CO project was the development of a wizard, aiding the user in the creation of CO components. In 2003 von Wedel published his PhD thesis An Environment for Heteroge- neous Model Management in Chemical Process Engineering (von Wedel, 2003), focussing on the diferent aspects of integrating diferent, heterogeneous pieces of software, including models and execution environments. CAPE-OPEN is mentioned as an approach that would need a model library of PMCs that has to be managed. To this end CO PMCs must be either very easy to create or very ease to fnd in a well documented library. As long as the PMCs mainly belong to the few people or institutions that created them, there will be no free and publicly available library containing a noteworthy number of elements to look for appropriate models. So the remaining option is to make the creation of a PMC very easy. The article Development of a chemical process modeling environment based on CAPE-OPEN interface standards and the Microsoft .NET framework (Barrett and Yang, 2005) by Barrett and Yang demonstrated that is was possible to create a whole process modeling environment based on the CO interface defnitions. The process modeling environment already contained a small library of CO unit operations. These unit operations were hard-coded in Visual Basic, therefore still requiring programming knowledge to create new units and not making use of a model-based transformation approach as encountered in MOSAICmodeling. Also in 2005 Schopfer, Wyes, Marquardt, and von Wedel described A Li- brary for Equation System Processing based on the CAPE-OPEN ESO Interface (Schopfer et al., 2005). This is one of the rare publications applying the CO numeric interface defnitions that include the ESO defnition. As the ESO did not generate a lot of traction in the community, the need for delivering your own NLE solver came up for this thesis. Three years later, in 2008, Morales-Rodríguez et al. described the Use of CAPE-OPEN standards in the interoperability between modelling tools (MoT) and process simulators (Simulis⃝R Thermodynamics and ProSimPlus) (Morales- Rodríguez et al., 2008). They integrate a PME, in this case MoT (Sales-Cruz

33 2 Theoretical Background and Related Developments and Gani, 2003), as a PMC into another PME (ProSimPlus26). MoT delivers the unit operation model and the solver, therefore requiring an installation of the MoT software in order to execute the unit operation. The CO unit operation in this case uses additional confguration fles. It is not clear whether these confguration fles are created automatically and how many objects/fles the user of the unit operation actually has to handle. As a follow-up to his doctoral thesis von Wedel published another article dealing with An Integrated Environment for Heterogeneous Process Modeling and Simulation (Wedel, Kulikov, and Marquardt, 2008). This paper used CO ESO to interface the involved solver and equation system. It was once again highlighted that compatibility of diferent tools is still an issue and standardization approaches such as CO are not yet sufcient and can only be a frst step “towards a fully interoperable world of process modeling and simulation software (Wedel, Kulikov, and Marquardt, 2008, p.492)”. In his 2009 paper Rapid Prototyping of Unit Operation Models Using Generic Tools and CAPE-OPEN van Baten (2009) presented his CO unit operation wrappers for MATLAB (MATLAB 2019), Scilab (SciLab 2019), and MS Excel. This basically made the CO unit operations available to a very large group of engineers, as the three mentioned tools are known to a wide range of people and easy to use compared to the direct implementation of CO interfaces in a multi-purpose programming language such as C++. The wrappers themselves do not contain models, the models have to be entered by the user in the program’s repective syntax (MS Excel, Scilab, MATLAB). The wrappers therefore are some kind of code skeleton wizards that hide the skeleton and ofer an easy access to enter your own models. At the sixth CO U.S. Conference in November 2009 Cano et al. gave a presentation entitled Deployment of a gPROMS-based three-phase reactor model as a CAPE-OPEN unit operation within PRO/II (Cano et al., 2009). They demonstrated the combination of a PME (Pro/II27) including the PMC of another software provider (PSE’s gPROMS28) and at the same time being able to connect a CO compliant physical property package of any vendor. Interfacing IPOPT with Aspen Open Solvers and CAPE-OPEN (Chen, Shao, and Qian, 2009) is a paper dealing with the integration of a Nonlinear Program-

26http://www.prosim.net/en/software-prosimplus–1.php date of last access: 2019-03-24 27https://sw.aveva.com/engineer-procure-construct/engineering-process-design/pro-ii- process-engineering date of last access: 2019-03-24 28https://www.psenterprise.com/products/gproms date of last access: 2019-03-24

34 2.5 Related Developments ming (NLP) solver (IPOPT) into a fowsheet environment (Aspen Plus29) using, amongst other mechanisms, CAPE-OPEN. The paper seems to show that applying CO for the integration of numerics has some use-cases, at least for research purposes. In 2010 Domancich et al. published a paper dealing with the creation of two CO compliant unit operations. Systematic generation of a CAPE-OPEN compliant simulation module from GAMS and FORTRAN models (Domancich et al., 2010) describes the use of wrappers to incorporate GAMS30 or Fortran code. The focus of that paper therefore is to re-use legacy code in fowsheet simulators supporting CO. The 2011 journal article A thermodynamic equilibrium reactor model as a CAPE-OPEN unit operation (van Baten and Szczepanski, 2011) is an article about a single unit operation provided as a CO unit operation. The objective of this work is to develop a mechanism that makes creating a CO unit operation such a normal thing that it is nothing special anymore, but standard when publishing any relevant model. Toward an interoperable software platform for sustainable energy (Aubry, Panetto, and Dassisti, 2015) is an overview article published in 2015, dealing with the aspects relevant to build a platform providing interoperability across features, domains, and scales. CO is mentioned as one suitable candidate technology for simulation integration at process scale. Also in 2015, Gozálvez-Zafrilla et al. published a paper presenting the application of the aforementioned MATLAB CO unit operation wrapper. Imple- mentation of membrane models on a CAPE-OPEN tool to simulate a process including RO membranes (Gozálvez-Zafrilla et al., 2015) highlights the need for the implementation of process models that do not already exist as standard unit operations in fowsheet simulation tools. That aspect confrms the motivation of this thesis in helping users to create their innovative unit operations directly as CO unit operations, re-usable in any compliant fowsheet simulator.

2.5.4 Recapitulation of the Related Developments

The FMI standard is a promising development, but does not have its focus on chemical engineering. Therefore the widely used process simulators for process

29https://www.aspentech.com/products/engineering/aspen-plus/ date of last access: 2019-03- 24 30https://www.gams.com/latest/docs/UG_MAIN.html date of last access: 2019-03-24

35 2 Theoretical Background and Related Developments engineering do not yet ofer appropriate interfaces. So FMI is not yet an alternative to CAPE-OPEN. It may nevertheless be interesting in the longterm to integrate the CO process simulation models into the framework of the general exchange framework of FMI. Considering the apparent support of FMI outside chemical engineering positive synergies in the overall exchange of digital models can be expected by combining the outcomes of both initiatives. The systematic, visual, and ontology-based modelling approach worked on at NTNU could ofer new impulses in teaching systematic modelling with MO- SAICmodelling including new ways of how to communicate the content of models.

In contrast to the objective of this work, the wizards created by Köller and Töbermann (2002) were only able to create code skeletons instead of full implementations ready for compilation. The remaining option to provide CO unit operations, the “easy-creation-way” mentioned by von Wedel (2003) is dealt with in this thesis by creating CO unit operation PMCs in an automated way. Re- garding the publication of Schopfer et al. (2005) using the ESO interfaces it can be stated that in case the CO numeric interface was implemented in all the relevant PMEs, this interface would have been used in this work instead of investing time to fnd a solver that can be included directly into the unit operation. De- spite the fact that it is not clear how much manual work is still necessary in their approach, in overall Morales-Rodríguez et al. (2008) came quite close to what will be shown in this thesis. One aspect of a fully interoperable world described by Wedel, Kulikov, and Marquardt, 2008, the neutral defnition of models, is in this respect already pro- moted in MOSAICmodeling by applying an open approach using MathML and XML (defned be schema fles). As MOSAICmodeling supports code generation for MATLAB and Scilab, a frst step during this work was to transform the MO- SAICmodeling models to appropriate code ready for execution in the wrappers introduced by van Baten (2009). The setting described by Cano et al. (2009) ofers an additional way to execute MOSAICmodeling’s equation-based models in a fowsheet environment. Code generation for gPROMS was already ofered by MOSAICmodeling, so using gPROMS as an intermediate would be possible. The drawback would be that costly software licenses needed to be available for anyone wanting to execute a model of MOSAICmodeling as a CO unit operation in a fowsheet simulator. Therefore there still is a need to create a CO unit operation directly without the need for software licenses of other products. In

36 2.5 Related Developments contrast to the re-use of legacy code described by Domancich et al. (2010), this thesis emphasises a systematic approach for the creation of new models or the re-use of equation-based models already available in MOSAICmodeling. In conclusion up to now no general solution for an easy, systematic, and automatised creation of CAPE-OPEN unit operations is available. This thesis is a step forward in the direction of highly customized but at the same time seamlessly integratable unit operations for equation-based and fowsheet simulation.

3 Problem Analysis

In this chapter the state of MOSAICmodeling in 2012/2013, before the work on this thesis started, is described including the workfows for modelling and code generation. Only after the target workfow is described, the missing features are explicitly identifed in a gap analysis that is performed at the end of this chapter. The gap analysis is a fundamental requisite for building the roadmap for the following implementation of the features necessary to achieve automatic generation of CAPE-OPEN unit operations.

3.1 MOSAICmodeling

3.1.1 Basics

Basis of the current workfow in MOSAICmodeling are the principles presented in the doctoral thesis of Stefan Kuntsche (Kuntsche, 2013). MOSAICmodeling is a software supporting users to formulate and reuse mathematical models for CAPE, especially in simulation and optimization. In this regard two phases can be distinguished. The frst phase is the model development or modelling phase, the second one is code generation (and execution / post-processing). MOSAIC- modeling is written in JAVA1. JAVA is a programming language developed frst in the 1990s and still subject of improvements and extensions. By means of In- tegrated Development Environments (IDEs), in this case NetBeans2, Graphical User Interfaces (GUIs) can be created quite easily. The design of an intuitive GUI is important in the context of this work, as the users are mostly students and researchers in the area of process engineering and no professional program- mers. A software only accesible via command line may be alright for computer scientists but not for applications in chemical engineering MOSAICmodeling is meant for. This becomes important especially regarding the representation of equations. Equations and variables are the fundamental building blocks of math-

1https://www.oracle.com/technetwork/java/index.html date of last access: 2019-03-24 2https://netbeans.org/ date of last access: 2019-03-24

39 3 Problem Analysis ematical models. In MOSAICmodeling equations are entered in a LATEX language tailored for specifc needs: MosaicTeX. As LATEX is common for writing scientifc publications, especially when mathematical formulas are included, only a very small set of new, simplifying commands have to be learnt. A nice example for such a simplifed command is writing diferential operators, where MosaicTeX is considerably shorter:

• MosaicTeX: \dif{x}{t}

• LATEX: \frac{\diferentialD x}{\diferentialD t}

dx • rendered: dt

A study performed in a master’s thesis in 2014 (Baykal, 2014) has shown that users of MOSAICmodeling do not see learning these additional commands as an obstacle in learning to use MOSAICmodeling. A big advantage in using this derivative of LATEX is the possibility to clearly visualize the mathematical formulas directly in the modeling environment. This way all the equations and variables are shown two-dimensionally rendered in MOSAICmodeling, in contrast to other similar environments that show equations only as one-lined strings. One example is the string c_{p,i}^{LV} = \frac{x}{y}, that is rendered in the user LV x interface as follows: cp,i = y . In order to be future-proof and to guarantee the universality of the entered mathematical models the information is not only stored as simple MosaicTeX strings. Additionally Mathematical Markup Language (MathML) is used. MathML is a fle format related to the more famous Hyper Text Markup Language (HTML) fle format and specifed by the World Wide Web-Consortium (W3C). Since 2015/16 MathML in version 3.0 is integral part of HTML5 and standardized in ISO/IEC 40314:2016 3. In MOSAICmodeling only the “Presentation MathML” part of this standard is used. In the beginning around the year 2009 everything was implemented for fle systems. As MOSAICmodeling is meant to support collaboration between several, distributed participants in the area of model development, this was not sufcient. So R. Kraus implemented the use of databases in MOSAICmodeling for his doctoral thesis on collaborative modelling (Kraus, 2015). Since then all models are not stored locally anymore, but online in MySQL4 databases. The databases

3https://www.iso.org/standard/58439.html date of last access: 2019-03-24 4https://www.mysql.com/ date of last access: 2019-03-24

40 3.1 MOSAICmodeling are located on servers that can basically be accessed by MOSAICmodeling from anywhere via internet connection.

3.1.2 Workfow of Modelling

The workfow of modelling is about creating a completely defned model of the physical system. The model is stored platform-independently and serves as a basis for creating executable code. In the following subsection (3.1.3) the workfow of code generation in MOSAICmodeling is described. Most of the model parts / model elements presented now already were designed and presented in the doctoral thesis of Stefan Kuntsche (Kuntsche, 2013, pp.68-79). An exception are the two elements “transformation” and “optimization”. These were developed later and presented in the doctoral thesis of R. Kraus (Kraus, 2015, pp. 41-55). Eventually the goal of the modelling part in MOSAICmodeling is to build a fully defned equation system that is later on solved. For reasons of convenience, the meaning of the model elements in context of this thesis is repeated here. In general all elements of the modelling and simulation part of MOSAICmodel- ing that can be saved in the database can be connected with keywords. Therefore a flter can be applied when choosing elements from the database. The option “has to be included” as well as the option “must be excluded” are available for this flter. The more elements exist in the database the more efcient it is to use such a fltering option to reduce the search space, fnd desired elements, and ease the work with MOSAICmodeling.

Notation In the beginning is the Notation, in which the user has to enter all symbols to be used inside the equations. Numbers and mathematical operations are not part of the Notation, as these are always available inside MOSAICmodel- ing and unique in their meaning, e.g. there is no need to explain “+” as being the operator of the addition. So the Notation has to name the variables that are the operands inside the equations. The Notation incorporates the single parts that can be used to compose the names of the variables that will be applied during the course of modeling. Each variable in MOSAICmodeling has a “base name” and may also consist of the diferent additional naming parts “superscripts”, “subscript”, and “indices” (for numbering of similar variables). Table 3.1 on page 42 gives fve examples on how variable names may be composed. Base name “c” combined with the subscript “p” may stand for a heat capacity, whereas the same base name combined with subscript “o” and index “i”

41 3 Problem Analysis

Table 3.1: Examples for Variables full name base name superscripts subscript indices cp c - p - co,i c - o i LV pc p LV - c pin,abs p in, abs - - Ktr,i K - - tr, i may represent a reference concentration of the i-th component. In the next two examples the base name p is used. With superscript “LV” and index “c” it can be interpreted as vapor pressure of component c, in the other case with superscripts “in” and “abs” it is the absolute pressure at the inlet. The last example demonstrates the application of two indices to the base name “K”, describing an equilibrium constant of component “i” on tray “tr”. The user has to enter a short description for each symbol that is stored in the Notation. These descriptions are later on displayed throughout MOSAICmod- eling whenever a variable is selected. Like for basically all main model parts in MOSAICmodeling the Notation has its own editing area, in this case the Nota- tion Editor. The Notation is stored in the database with a unique ID and can be reused for an arbitrary number of models. Most importantly every equation and all equation systems need to reference a Notation. The description of the symbols can be extended later on, so it is not mandatory to know each and every possible meaning of a symbol in advance. At the same time it is also no problem to later-on add new symbols to the Notation. This is important when not all variables are present at the beginning or when the Notation is to be used for another model with more diferent variables. The parts of a variable only need to be defned in the Notation when actually being used in an equation.

Equation The core elements of each model in MOSAICmodeling are the equations. Every equation needs to load a Notation. The equation is generally entered as a LATEX/MosaicTeX expression. After entering the equation the user presses a button to tranform the LATEX input into MathML and display the rendered expression (see fgure 3.1). In case the LATEX expression contains errors it will not be rendered and it is not possible to save the equation as it is. This way it is tried to ensure that only basically correct equations without syntax error and without undefned

42 3.1 MOSAICmodeling X expression of an equation are displayed in the lower half E T A . Equation Editor of the Figure 3.1: EQU editor - MosaicTex input and rendered L

43 3 Problem Analysis variables are stored in the database. When variables are not yet defned the user can update and reload the respective Notation in order to save the (changed) equation. Another mandatory requirement before an equation can be saved is a description for the equation. In a free text feld comments and assumptions can be added that will be stored as the description of this element in the database. This is one aspect of the so-called documentation-oriented modelling approach that also helps identifying equations for later reuse. An optional feature of the Equation Editor is loading a Parameter List in order to mark elected variables. As parameters were primarily designed to be used in functions and not fully implemented for use in equations, they could not be reliably used here in 2013.

Function An equation explicitly calculating the value of one variable can be entered in MOSAICmodeling’s Function Editor as a function. This means that in this equation there is exactly one variable on the left hand side that is explicitly calculated by an expression on the right hand side. In analogy to programming languages the left hand side can be interpreted as function output, defned by a function body (right hand side) containing function inputs (variables). Such explicit equations have the advantage that there is no need to run a solver, because the expression can be evaluated directly by insertion of the values and has an unambiguous solution. In the Function Editor exactly the aforementioned elements are to be entered by the user. At frst the output variable (left hand side) is set, followed by the inputs. In the standard case the user next enters the function body containing the mathematical expression to calculate the left hand side. Sometimes the function body is not known (in advance) or the exact implementation of the calculation shall be defned later on. In this case no body is entered in the user interface of the Function Editor. Instead one of the options “Interface only” or “Empty function body” is chosen. Selecting the frst option allows MOSAICmodeling to automatically include a function implementation during code generation. Choosing the second option leads to actually empty function body implementations that have to be (manually) complemented after code generation. The latter case is interesting when constructs or commands have to be used inside the function body in the code implementation that are not language-independently supported in MOSAICmodeling. Examples for this are vector-valued inputs and vector-valued outputs or function bodies that cannot be expressed as explicit mathematical equations (e.g. if-then-else, scaling,

44 3.1 MOSAICmodeling or auxiliary calculations). Whatever is entered in the Function Editor in the standard case will be found as function implementation in the generated code, e.g. in MATLAB observable with the “function” keyword. A function entered in the Function Editor can be reused to calculate several variables in an equation system. Therefore later on, in the Equation System Editor, the user defnes explicit applications of the function matching variables existing in the equation system. This is equivalent to function calls in the generated code. Coming back to the Function Editor it is mandatory to load a Notation before any input, output, or function body is entered. This is a common necessity to all modelling editors in MOSAICmodeling. When an explicit function body is entered, the user is allowed to load an optional parameter list. The variables of the parameter list that match variables of the function body then become parameters. In consequence these parameters are later on considered given with fxed values instead of unknown function input variables that have to be calculated during numeric solution of the overall system. In order to be allowed to save a function it is again neccessary to enter a description in the Function Editor.

Parameter List and Interface In MOSAICmodeling the elements Parameter List and Interface are similar, as a Parameter List is a subset of the information contained in an Interface. In 2013 the editors for Parameter Lists and Inter- faces looked identical with the diference that for Parameter Lists some parts of the user interface were disabled. Anyway, in both cases a Notation has to be loaded. The content of the Notation is shown in an extra tab of the editors’ GUI. This way the user can directly see which symbols and letters can be used inside Parameter List and Interface.A Parameter List basically contains a listing of names of variables (Variable Namings) composed of elements of the loaded Notation. Every entry of an Interface contains, besides the Variable Naming, a feld name, a dimension (scalar/vector), a unit symbol (engineering unit) and a direction information (in/out). The Parameter List is used to mark variables inside functions (and later on also inside equations) as Parameters. These marked variables later on are viewed as given values that are not to be calculated. An Interface can be used in two diferent applications. On the one hand an Inter- face can defne Functions by specifying the inputs and outputs of the function header. In this case the Interface must provide exactly one entry with direction “out” and may provide several entries with direction “in”. The latter variables

45 3 Problem Analysis are the function inputs, whereas the variables with direction “out” defne the function output, the value to be calculated. On the other hand Interfaces can be used in defning so-called Ports and Streams. Every port and every stream in MOSAICmodeling needs an Interface. In this case all variables are contained that are to be handed over the boundaries of one unit operation to another unit operation. The direction is therefore usually set to “in/out”, making an interface applicable to an output of one unit as well as to the input of the next unit. While the feld dimension indicates if a variable is a scalar or a vector. In an Interface for streams a vector-valued entity for the composition is commonly used besides the scalar valued temperature and pressure. A Function Interface for calculation of vapor pressures would take a scalar temperature and a vector-valued composition as input values and have a vector-valued output for the vapor pressures of every component at the given temperature. A Pattern Assistance helps users in creating Interfaces. Templates for typical applications were provided in this assistance feature. Examples are CO calls for physical properties or stream data elements for models in Aspen Custom Modeler (ACM). When a Pattern Assis- tance is selected, it is possible to let MOSAICmodeling check if all elements of the currently edited Interface comply to the selected pattern. A feld to enter a description of the interface or parameter list was not present in 2013.

Equation System In the Equation System Editor existing Equation elements are integrated into a system of equations. Existing stored Equation System elements can also be integrated (see Fig. 3.2 on page 47). The generation of subsystems simplifes reusability by making it possible to add a whole set of equations at once to a new system. One use case for such a scenario is the combination of subsystems of diferent, previously tested unit operations into an integrated system. In case of two unit-operation-equation-systems combined in one new Equation System it is sufcient to add just these two elements, as all contained equations are automatically inherited. This way it is not necessary to add all equations separately and redundant work can be avoided. In principle users can select Equations and Equation Systems they have existing read or write access to. It is therefore not necessary to create all elements yourself as long as access rights to the desired elements were granted. Precondition to add Equations or Equation Systems is once again loading a Notation in the Equation System Editor. Basically the same Notation should be used for the new system as well as all included equations. Using Connectors allows deviations from this

46 3.1 MOSAICmodeling Equation System Editor ) in the Equation System / Equation Figure 3.2: EQS editor - adding a connected element (

47 3 Problem Analysis rule (see paragraph about Connectors). Besides Equations, Functions can be added, too. On level of an Equation Sys- tem a generic Function created in the Function Editor is matched with concrete variables of the equations. This is called a function application. A function application contains an implicit Connector connecting a generic name with an applied name of a variable. Each function application corresponds to a function call in the later on generated code of the Equation System. In the work of Kuntsche (Kuntsche, 2013) ports and streams were implmented in MOSAICmodeling for the frst time. In this context a prototypical example of a distillation column was created. The column consisted of several subsystems, connected via internal streams. In order to connect these subsystems with streams, ports had to be added beforehand. Entering this connection information in the user interface was possible but not mature, as automatic checks of consistency were not elaborated. The description of a port is consistent when the elements used in a port (i.e. Connector and Interface) are exactly matching. The same holds for streams, where the Interfaces of the ports have to match the Interface of the stream, unless another Connector builds a bridge between them. With this principle of implementation of ports and streams in MOSAICmodeling the concept of documentation based fowsheeting was introduced by Kuntsche (Kuntsche, 2013). Providing a description is mandatory in the Equation System Editor before the system can be stored. After saving the Equation System element in a preview all equations, functions, ports, and streams can be listed. All equations of integrated systems of equations are numbered and rendered appropriately in the GUI. This is a neat way of visually checking if all expected equations are actually part of the model or still is something missing. Regarding functions in the preview the function bodies are rendered as they are also displayed in the Function Editor. Selecting a generic function in the preview lists all related function applications and shows the matchings of generic input values and output value to variables of the equation system (see fgure 3.3). Ports and streams are sumarized as tables showing the matches of a variable in Equation Systems, port Interfaces, and stream Interfaces. For each variable the table has a row and for each namespace (i.e. equation system, interface) a column, see fgure 3.4 for an example of the namings in a port. Therefore a single stream connecting two unit operations may have up to fve columns corresponding to the Equation System of the frst unit, the Interface of the frst unit, the Interface of the stream, the Interface of

48 3.1 MOSAICmodeling Equation System Editor Figure 3.3: EQS editor - function application as shown in the preview of the

49 3 Problem Analysis ESeio xenlpr ssoni h rve fthe of preview the in shown as port external - editor EQS 3.4: Figure qainSse Editor System Equation

50 3.1 MOSAICmodeling

System 2 (Notation B) Notation A: {c, d} (1) 3·C = 2·D + E Notation B: {C, D, E} (2) C = 7 + D Connector (3) 2·C = 4·D Connector (Variable Matching): System 1 (Notation A) A.c => B.C

(1) c = 7 + d A.d => B.D (2) 2·c = 4·d

Figure 3.5: Connector - basic principle of variable matching when a system with one Notation (A) is added to a system with a difering Notation (B). The contained equations are added after renaming of the variables.

the second unit, and fnally the Equation System of the second unit.

Connector Connectors are an auxiliary means to connect variables accross the boundaries of single model elements. That is important in the composition of equation systems and when ports and streams come into play. Model elements (basically Equations, Equation Systems, Interfaces) may use difering Notations. In a scenario where system 1 with Notation A is to be added to a system 2 with Notation B, the variables of the of the frst system have to be connected with the variables of the second system (see Fig. 3.5 on page 51). Without such a connection it would not be clear that in this case variables with difering names have the same identity. When ports are added to an Equation System, a Connector establishes the connection between the internal variables of the Equation System and the names of the variables made public to the outside through the Interface. The same holds for the connection of two ports via stream. Here a Connector can be applied to overcome potential disambiguities caused by the use of difering Notations in Interfaces of ports and stream. In the Connector Editor the user is presented an overview of all matches of variables that are stored within the Connector. In order to create a new Con- nector the user loads the two Notations (that do not necessarily have to be diferent). The frst Notation, called “sub notation”, determines which variables the matching algorithm is looking for in order to replace/connect them by respectively with variables of the second Notation, called “super notation”. The

51 3 Problem Analysis sub notation stands for an inner layer whereas the super notation corresponds to an outer layer. In the above example system 1 is added as a subsystem to the other system, system 2. Therefore Notation A is sub notation and Notation B is super notation in Fig. 3.5. In ports the Notation of the Equation System always is sub notation and the Notation of the port’s Interface is super notation. When both Notations were loaded in the editor, all pairs of variables have to be entered that should later be matched when the Connector is applied. In the GUI a dedicated tab is provided that automatically matches the indices of paired vector-valued variables. When variables with two or more generic indices are entered, this corresponds to entries of matrices or tensors and it is not possible anymore to perform the matching automatically, as in MOSAICmodeling the order of indices is ignored and only the index names are considered. In 2013 there was no possibility to give the Connector a description, so every additional information had to be put into the fle name when saving. After saving it is possible to test the functionality of the Connector in the Connector Editor. In the respective tab an element like an Equation, Equation system, or Interface could be loaded and it was displayed which variables identifed inside this loaded element could be matched with the Connector currently opened in the editor. Three options to simplify the creation of a Connector are ofered when loading a Notation in the frst place in the Connector Editor. In the frst option the Notation is loaded as is and the user must type-in all variables to be matched manually. In the second option an Equation or an Equation System can be selected and the Notation as well as all identifed variables of the equations are loaded into the GUI to reduce typing efort. The third option loads a Notation by selecting an Interface. This option is very handy when it comes to creating a Connector for ports and streams as automatically all variables of the Interface are directly loaded in to the GUI, making tedious manual input obsolete.

Transformation In MOSAICmodeling the model element Transformation is used to discretize diferential equations. Equations containing derivatives are transformed into generic, algebraic equations by replacing the diferential operator with appropriate algebraic expressions. States in the numerator of diferential operators and diferential variables of the operator’s denominator get additional discretization indices. These continuous variables become therefore many dis- crete values pointwise replicating the continuous variables’ trend. The Transfor- mation can be applied to single Equations as well as systems of equations in the

52 3.1 MOSAICmodeling

Equation System Editor.

In the Transformation Editor the user enters the information necessary to fully defne a discretization instruction. In MOSAICmodeling for this purpose an Equation System is matched with a Notation. The Equation System describes the discretization instructions, whereas the Notation determines for which Equa- tions the Transformation can be applied. When Equations or Equation Systems use the Notation specifed in the Transformation, their diferential operators matching the operators defned in the Transformation can be replaced. The discretization instruction contains a pattern of the operators to be discretized. The independent/diferential variable of the Transformation has to be matched with a variable defned in the Notation of the system that will be discretized. Each Transformation replaces exactly one type of diferential operator. In case of a simple diferentiation this is in accordance with exactly one independent variable. If an operator of second order is to be replaced, two independent variables have to be set, respectively. When fnally all indices of the discretization instruction are matched with indices of the mapped Notation, the Transformation is ready to use. The independent variables of matching diferential operators are always replaced, the same holds for explicit state variables. Whenever additional, implicit states that do not occur in a system’s diferential operators shall be discretized, too, they have to be specifed in the Transformation Editor. Two options are available for these predetermined states. In the frst option the predetermined states are discretized exactly the same way the explicit states of the diferential operator’s numerator are discretized. In the other option the implicit states are discretized like the independent variable. Depending on the discretization method both options may lead to identical results. It does indeed make a diference when the discretization instruction adds diferent sets of discretization indices to states on the one hand and independent variables on the other hand. An example for such instructions is orthogonal collocation on fnite elements, adding more indices to the explicit states than to the independent variable. Here is a minimum example of how an equation looks like before and after application of a Transformation (using implicit Euler discretization method). Diferential equation: dx = x (3.1) dt

53 3 Problem Analysis

Discretized, algebraic equation(s):

xi − xi−1 = xi (3.2) ti − ti−1

In an Equation System several Transformations can be applied on diferent hierarchical levels. This way it is possible to discretize inner equations with instructions diferent from those applied to equations added in higher hierarchical levels. More on this can be found in Kraus, 2015, pp.49-55.

Evaluation/Simulation After composing the desired Equations and Functions in an Equation System, the model is ready to be prepared for simulation. In MOSAICmodeling the element Evaluation was introduced for this purpose. In an Evaluation exactly one Equation System can be loaded. When generic indices are used in this Equation System, information for the so-called “indexing” has to be provided. The indexing specifes the values the indices of index variables take, starting with 1 as lower bound and consecutively increasing to a maximum number / upper bound specifed by the user at this point. For an index enumer- ating the chemical components in a model, the number of components is the upper bound to be specifed in the indexing. Similarly for an index numbering the stages of a column the number of the last separator stage would be entered in the indexing. Only after all index bounds are set all equations and variables can actually be fully generated. This is called “instantiation” in MOSAICmodeling. Usually there are more unknowns than equations in an instantiated equation system. The user has to make a decision which variables are given and which variables are unknown and therefore have to be calculated by solving the equation system. The number of unknown variables in the end has to be identical to the number of linearly independent, instantiated equations. The decision which variables are considered given design variables and which not, is stored in so- called Variable Specifcation Lists (VarSpecs). Such a VarSpec can be reused in more than one Evaluation. In case of a reuse only those values are set that can be found in the VarSpec as well as in the instantiated equation system of the other Evaluation. This can be an important facilitation in case of larger systems with hundreds or thousands of variables. Without loading a VarSpec every time all variables would have to be assigned manually. The Variable Specifcation Lists do not only store the classifcation (fxed vs. unknown) and name of the variables, but also the numerical values. For

54 3.1 MOSAICmodeling variables fxed by the user, called “design variables” in MOSAICmodeling, the numerical value is the actual fxed value. For unknown variables the numerical value is defned as the “frst guess” or starting value. Additionally lower and upper bound separately defne the range of values for each unknown. The values of parameters have to be specifed, too. As described in previous paragraphs, parameters are never unknown, but always have a given value in MOSAIC- modeling. The values for parameters can be stored in separate VarSpecs and reused. Reusing parameter specifcations is very helpful for parameters of functions calculating physical properties with polynomials. These values depend on the physical component and are independent of a particular equation system. So systems with identical components will contain parameters with the same values. When all design values, initial guesses (starting values), and parameters have been specifed, the model is prepared for following code generation and simulation (see subsection 3.1.3). Subsequent to code generation and simulation results can be loaded/imported, leading to an update of the (starting) values of the unknowns. When a description has been entered, the Evaluation can be saved, containing the Equation System, the indexing information, and the specifcation lists for variables as well as parameters.

Optimization After defning a simulation as described in the previous paragraph, one possible next step in MOSAICmodeling is to proceed to optimization. In Kraus, 2015, pp.42-49, the concept of optimization in MOSAICmodeling is described as it was implemented in 2013. The equations of the simulation become constraints in the optimization. Out of the iteration values the user chooses the objective (variable) for the optimization. When choosing an objective it has to be considered that in MOSAICmodeling every optimization is expected to be a minimization. When a maximum is needed to be found, the value of the objective variable has to be multiplied by -1. Out of the design variables and unknows the user can explicitly choose decision variables and enter lower and upper bounds for them. These descision are intentionally given to the optimizer for variation in order to fnd an optimum of the objective variable. Based on these inputs in the optimization area of MOSAICmodeling code can be generated (see subsection 3.1.3). A reimport of results is not implemented in the Optimization Editor. The Variable Specifcation List (VarSpec) of the Optimization has the same format as in the Evaluation Editor. This way a VarSpec of the simulation can easily be used as a initial point for the optimization, setting values for the

55 3 Problem Analysis design variables and bounds for the unknowns. Information regarding the decision variables and the objective variable is only included in a VarSpec when it was saved in the Optimization Editor. An Optimization including constraints and a Variable Specifcation List could not be saved in 2013, but had to be set up every time when MOSAICmodeling had been closed before next code generation for optimization.

Documentation The focus of MOSAICmodeling as created by Kuntsche (Kuntsche, 2013) was put on close-to-documentation aspects, brought down to the concept of “modelling on the documentation level”. An important point therefore is the automatic generation of a documentation containing information about equations, equation systems, and whole simulations. The concept of documentation generation is summed up in Kuntsche, 2013, p.97. The user of MOSAICmodeling can select any model element in the Documen- tation Editor to create a documentation of the respective element. Depending on the element’s type specifc options are available. The options can be activated at will and infuence the extent of information put into the particular, generated documentation. For example the minimal content of the documentation of an Equation System contains description, Notation ID, and IDs of included Equations. Additionally extended information regarding Notation, Equations, Connectors, and Interfaces can be selected. The output format for the automatically generated documentation document based on the all information contained in a model element is restricted to “text” and LATEX. This is partly because of the prototypical state of this module that only implemented the easiest (i.e. text), and the most common (i.e. LATEX) format for scientifc content. Only the generation of LATEX output was maintained after frst implementation and is the only one that can be considered complete. LATEX especially fts in the context of MOSAICmodeling, as all the equations are entered and stored in this format and can therefore easily be reused for generation of a documentation. In the Portable Document Format (PDF) fle compiled based on the generated LATEX content, the equations are rendered as known from the MOSAICmodeling user interface. The MOSAICmodeling model elements available for documentation as of 2013 are Notation, Equation, Function, Parameter List, Connector, Equation System, Interface, Variable Specifcation, and Evaluation.

56 3.1 MOSAICmodeling

3.1.3 Workfow of Code Generation

The workfow of code generation is about transforming the platform-, and language- independent model into executable program code. Previously, in the workfow of modelling, a fully specifed system of equations, fxed quantities and unknown variables was established. This model is now converted by MOSAICmodeling’s “Language Specifcator (LS)”, also called Language Specifcations. This is possible for simulations as well as optimizations. Additionally an analysis feature is supported. The analysis results in information on the mathematical structure of the Evaluation under investigation, for example by returning the incidence matrix.

Language Specifcation In MOSAICmodeling two diferent kinds of LS exist. On the one hand there are Predefned Language Specifcator (preLS) that are coupled to the source code of MOSAICmodeling and can only be created and modifed by developers. On the other hand User-Defned Language Speci- fcators (UDLSs) exist, that can be created, shared, and modifed by the users of MOSAICmodeling themselves. Each LS, independent if predefned or user- defned, is designated for one class of equation systems. It is distinguished between purely algebraic (non-linear) systems (NLE/AE), Ordinary Diferential Equations (ODEs), DAEs, and optimizations. At the beginning of this work, in 2013, for optimization only preLS were possible. LS collect information, how numbers, equations, and variables have to look like in the targeted (programming/simulation) language. In some languages numbers have explicit sufxes or foating points, this is considered in the LS. Regarding variables MOSAIC- modeling distinguishes between human-readable names of variables and indexed LV variable names. Examples are “pi=1” for a descriptive name, and “X[23]” for a denomination using an index to identify the variable. For every calculation operator supported by MOSAICmodeling it is defned in the LS how it has to look like. An addition of two numbers x and y can in one language be denoted with the common “+” symbol, while in another language a command similar to “add(x,y)” may be the correct choice. Besides equations and variables LS mainly determine the structure of the code to be generated. This includes code blocks for defnition and initialization of variables and parameters as well as calls to the solver responsible to fnd a solution of the equation system. Often a print of the results is desired, this can directly be included, too. User-defned Langspecs were frst published in the doctoral thesis of Kuntsche (Kuntsche, 2013, pp.94-

57 3 Problem Analysis

96) and later on in 2018, after some extensions, in more detail described in a journal article (Tolksdorf, Esche, Wozny, et al., 2018). With preLS users had access to more options and parameters for code generation. This way the solution algorithm and tolerances could be made available for modifcation before code generation. In 2013, only with preLS it was possible to translate functions without explicitly defned mathematical function body represented by an equation into the targeted language. A specifc example are functions only defned by function interfaces. Another example are functions with vector-valued inputs, or outputs. Ports are another part of the models in MOSAICmodeling that could only be coped with when using a preLS. That was the only way to generate code reading the variables of inlet ports and writing calculated variables to the outlet ports. As this thesis is about generation of CAPE-OPEN Unit Operations (that per defnition contain ports) this is a remarkable aspect that has to be dealt with.

Evaluation In the Evaluation Editor 5 for establishing simulations a tab for code generation is on hand. In a text area status information for the model is displayed. Not before the model is fully specifed, the user can select an LS for code generation. In case of a preLS the available options for code generator and solver properties are shown in a table. A second table ofered more properties related to specifc environments. These so-called “Specifc Environ- ment Properties” were meant for aspects that do only occur in special models and languages. This was applied for CAPE-OPEN physical property packages in MATLAB, more precise the CAPE-OPEN package manager and the property package could be specifed before code generation in order to be able to skip this selection process during code execution. For all properties shown to the user in the code generation tab default values exist. When the default values are not appropriate for a certain simulation, the user is free to change the value. In 2013 a UDLS does not support code generation options in the simulation (Evaluation Editor). By pressing “generate code” the equation based model built up and specifed in MOSAICmodeling is translated into text that can be interpreted as source code for the language the LS was designed for. The generated code is shown in a separate tab. It can be selected and copied into the program it was created for. Code for MATLAB therefore has to be

5The term Simulation Editor is a synonym to Evaluation Editor and primarily used in chapter 4.

58 3.1 MOSAICmodeling copied into an m-fle. For some LS it is possible to perform a simulation directly after code generation without changing to another software. In this case the code is compiled, linked, and executed on a MOSAICmodeling server. Af- ter successful code execution the results were written back into a results tab in MOSAICmodeling. In case the simulation was not successful the user at least gets the exit/return message of the solver to get an idea of what went wrong or in which point the solution process stopped. The direct execution on MO- SAICmodeling’s server is implemented for C/C++, using GSL (Galassi, 2009), BzzMath (Buzzi-Ferraris and Manenti, 2012), or sDaCl (Barz et al., 2011) as solvers. For algebraic systems the results for the unknowns (also called iteration variables in MOSAICmodeling) are shown in a table. For diferential systems (ODE, DAE), the states can be plotted in a two-dimensional diagram. This way a frst visual check for plausibility of the solution can take place.

Optimization In the Optimization Editor an Evaluation is loaded, objective variable and decision variables are defned (see 3.1.2, Optimization). Regarding code generation for optimizations in MOSAICmodeling two options exist. The frst option is code generation for local execution. In 2013 LS for MATLAB and GAMS are available, but no settings can be modifed in the GUI. Code is only generated, not executed, and may consist of the content of several code fles. These fles have to be created separately and manually flled (copy and paste) with the respective parts of the generated code. Solver parameters and other options available in the particular languages can of course be varied in this step by manually modifying them. The second way to generate code for optimizations is using the NEOS server. “The Network-Enabled Optimization System (NEOS) Server is a free internet- based service for solving numerical optimization problems. Hosted by the Wis- consin Institutes of Discovery at the University of Wisconsin in Madison, the NEOS Server provides access to more than 60 state-of-the-art solvers in more than a dozen optimization categories. The NEOS Server ofers a variety of interfaces for accessing the solvers, and jobs run on distributed high-performance machines enabled by the HTCondor software. The NEOS Server is available free of charge for everyone, anywhere in the world.6” The code is submitted to an optimization server immediately after generation. The NEOS XML-RPC-API is used as an interface to communicate asyn-

6https://neos-guide.org/content/FAQ date of last access: 2019-03-24

59 3 Problem Analysis chronously. Due to this asynchronicity users can continue working with MO- SAICmodeling, while a synchronous call would freeze the GUI until the execution of the optimization is completed and the NEOS server responded. In MOSAICmodeling’s user interface the status of the optimization send to the NEOS server is shown and can be updated with a respective refresh button. When the program execution fnished on the NEOS server (status: Done) and an e-mail address was provided, a notifcation mail is sent to this address. Using the GUI the result fle can be investigated by checking the value of the objective variable. In 2013 MOSAICmodeling supported GAMS code for submission to the NEOS server. With this language appropriate for formulating optimization problems diferent solvers and algorithms for difering problem classes can be selected. Available options are listed online and can be found on the neos websites7.

Analysis The idea behind the Analysis feature in MOSAICmodeling has already been described in Kraus, 2015, pp. 83-100. The Analysis is used in two places inside MOSAICmodeling. In a dedicated analysis area an Evaluation can be loaded and investigated. Diferent mathematical decomposition methods are applied on the equation system of the loaded Evaluation and the resulting information on the mathematical structure is presented in the GUI. Therefore three difering views on the system are available. All three have in common that they are matrix/table views, with one line/row for each equation and one column for each variable. In the frst view the incidence matrix is shown. This matrix simply indicates with coloured dots which variables occur in which equations (see fgure 3.6). The Jacobian of an equation system will in general have non-zero entries wherever the incidence matrix has non-empty entries. In the second view, the block decomposition, (see Fig. 3.7 on page 62), the system is decomposed in a way that in the ideal case all equations can be re- arranged in a way that the system forms a triangular matrix. In this case all equations can in principle be solved sequentially, one after another. This ideal case is seldom for real applications. Usually at most a block-triangular structure can be achieved, where on the main diagonal blocks of several equations and variables exist that have to be solved simultanuously. This block decomposition is based on the Dulmage-Mendelsohn decomposition (Dulmage and Mendelsohn, 1958). The smaller the blocks to be solved simultanuously, the more decoupled

7https://neos-server.org/neos/ date of last access: 2019-03-10

60 3.1 MOSAICmodeling Figure 3.6: Analysis - Incidence matrix of the TwoCompoundColumn model

61 3 Problem Analysis

Figure 3.7: Analysis - Block decomposition based on a fgure by R. Kraus (Kraus, 2015, p.85, fgure 4.3)

the overall system is. Decoupled systems can be solved with less efort. In the third view, the bordered block decomposition (see Fig. 3.8 on page 63), variables are identifed that have an important infuence on the coupling in the overall equation system. These key variables are moved to the right border of the incidence matrix, whereas for the other variables a block-decomposed lower triangular form is seeked. In order to solve such a system good guesses of the key variables have to be made. With the key variables given the system’s remaining part can efciently be locally solved (due to the triangular form of the block- decomposed part). In the end the equations not used in the block-decomposed part are taken to check the quality of the guesses of the key variables. As long as the residuals of these equations are above a certain threshold (depending on the tolerance of the solver) this system is not solved and the solver will keep on varying the key variables and evaluate the inner blocks until a solution is found. Identifying the key variables gives useful information on which variables should be understood and well estimated in order to fnd a solution of the system at all. The other part in MOSAICmodeling where the analysis is used is in the code generation for simulations in the Evaluation Editor. The just described decompo-

62 3.1 MOSAICmodeling

Figure 3.8: Analysis - Bordered block decomposition based on a fgure by R. Kraus (Kraus, 2015, p.86, fgure 4.4)

sition methods were purposefully implemented by Kraus, 2015, into some preLS. During code generation an analysis of the system is executed. In one LS the block decomposition is applied, in another one the bordered block decomposition. The code generated in both cases can be executed in MATLAB and explicitely makes use of the advantageous features described above. So the block decomposition leads to a cheap sequential instead of an expensive simultaneous solution algorithm. The bordered block decomposition varies the key variables in an outer loop. In the inner runs the remaining block decomposed system is solved. When the size of the equation system increases, the probability to fnd a solution in the simultaneous approach decreases. This can be explained by the condition number of the problem inherent matrix of the equation system. The tendency of the bad infuence of the system’s size becomes more important when there is no initial guess known close to a solution. The mentioned decomposition algorithms are a promising approach to overcome this infuence, nevertheless fnd a solution at all, and better understand the investigated system.

63 3 Problem Analysis

3.2 Target Workfow and Gap Analysis

The state of MOSAICmodeling in 2013 has been described in the previous section. In order to identify the areas where the software has to be updated and extended a target workfow was defned. This workfow is visualized by a UML activity diagramm, see Fig. 3.9, and in detail described in the following. This includes the sub level workfows diferencing single activities of the top level workfow. Based on these workfows in section 3.2.2 on page 76 a gap analysis will determine the topics for the implementation covered in the following chapter.

3.2.1 Target Workfow

Activity: Run a mathematical model as A: Select Unit Operation appropriate model in a flowsheet from library

B: Check if model C: Build new, is CAPE-OPEN CAPE-OPEN compatible [model exists] [else] compatible model

D: Adjust model to CAPE-OPEN [else] requirements

[model is compatible]

E: Create CAPE-OPEN compliant Unit Operation

CAPE-OPEN Unit Operation

F: Insert and run Unit Operation in flowsheet

Figure 3.9: Activity diagram of the targeted top level workfow

64 3.2 Target Workfow and Gap Analysis

Overview

The target workfow shown in Fig. 3.9 on page 64 summarizes the fndings of this chapter. This includes the topics Units of Measurement, Unit Operations, Flowsheet simulation, CAPE-OPEN and the documentation-based modeling and code generation system of MOSAICmodeling. The main goal of applying this workfow is the execution of a mathematical model as a unit operation in a CO- compliant fowsheet environment. The frst activity in this workfow, activity A, is to select the model from the library. When the model of the unit operation does not yet exist in MOSAICmodeling, a new model has to be built up (either completely new or composed of existing elements), activity C. In case the model is already present in MOSAICmodeling (activity B), but not as a compatible unit operation, the model has to be adapted (activity D). No matter if a new model is created or an existing model is adapted, a step for implementation and automatic generation of a CO Unit Operation ready for integration in a fowsheet follows (activity E). Finally the CO Unit Operation can be executed in a CO-compliant PME (activity F ).

A: Select appropriate model

The frst task is to select an appropriate equation-based model that describes the relevant phenomena of the unit operation under investigation. Ideally a model ftting these needs already exists in the model library. At this point meaningful descriptions and assigned keywords help fnding equation systems fulflling the requirements. When there is a model identifed as appropriate, the workfow continues with activity B, else a new model has to be composed according to activity C.

B: Check compatibility

In order to be CO compatible, the model of a unit operation strictly has to describe the unit’s input-output behaviour. The inlet and outlet ports (to be connected to material, energy, or information streams) and their respective variables must be defned. Summation equations for feed compositions are forbidden, as the inputs of a CO unit operation are determined by either a previous unit operation or the fowsheet environment directly. Public parameters are optional, but if the model contains variables predestinated to be parameters, model adjustments should be considered (i.e. redefning design variables as parameters with no

65 3 Problem Analysis

Figure 3.10: The modelling and simulation system by Kuntsche. Figure taken from Kuntsche, 2013, p.19 (Figure 3.3)

change of the degree of freedom). An important point regarding thermodynamic consistency are the calls to physical property functions. As the properties of the material (input) streams are set by the PME, using a diferent property package internally will lead to inconsistencies. Therefore it is highly recommended to rely on external functions using CO property calls instead of implementing the thermodynamic properties with internal functions (e.g. polynomials with fxed parameters). When there are adjustments pending, the workfow continues with activity D, else the model is ready for code generation and compilation in activity E.

C: Creation of a new model

Regarding the creation of a new model the strategy proposed in Kuntsche, 2013, pp.18-19 (see Fig. 3.10), with its workfow for modelling and simulation, is adapted and extended for the simulation of single, custom unit operations. When it comes to integration of a unit operation into a fowsheet simulator, new aspects are added to the workfow. A visualization of the updated workfow is shown in Fig. 3.11 on page 67. Before integrating the unit in a PME, the user has to provide a model prepared for fowsheet simulation. So after an update of the model (i.e. its documentation) the user has to decide if the model is suf- fciently validated and compatible with CO (see activity B). If not, usual code generation for this single unit is performed, simulation steps are taken and new insights are gathered, e.g. by testing new points of operation. If yes, a CO Unit Operation is directly created (see activity E). This CO unit operation can be integrated into a fowsheet with other unit operations and the overall process can be simulated (see activity F ). The results of this overall simulation in the fowsheet environment can be fed back into the documentation of the mathematical

66 3.2 Target Workfow and Gap Analysis

Activity: Develop new, validated model of a unit operation

1. 2. Create/update Check: Is the documentation model validated? of model

3. [else] Generate simulation code for validation

[yes]

[else] E*: 4. Create CAPE-OPEN Perform the compliant [satisfying] simulation Unit Operation

F*: 5. Insert and run Evaluate the Unit Operation simulation results in flowsheet

*part of top level workflow

Figure 3.11: Activity diagram for developing new, validated models as basis for CAPE-OPEN unit operations

67 3 Problem Analysis

Activity: Adapt existing, validated model in order to get a CAPE-OPEN unit operation

1. 2. 3. Partition the model Separate physical Assign and check into logical units property functions engineering units

6. 5. 4. Identify and set Identify and set Identify and set public parameters system outputs system inputs

7. Harmonize thermodynamics

Figure 3.12: Activity diagram for adapting existing, validated models in order to make them CAPE-OPEN unit operations

model of the custom unit operation.

D: Adapting an existing model

An existing modell shall be made CO compatible step by step. One requisite is that the existing model has already been simulated once and a result set of variable values for a given operating point is known. In order to perform the adjustments a checklist can be worked through. An overview is given by Fig. 3.12. After each step, tests in form of simulation runs are performed. As the system has already been simulated, an appropriate simulation environment must be available. In case the model cannot be solved at one point, the changes of the current step must have caused this and a starting point to fx the problem is given by the previous simulation. The checklist consists of seven points; the key questions and intentions of those points are presented here:

68 3.2 Target Workfow and Gap Analysis

1. Partition of the overall model into logical units Can the overall model be partitioned into meaningful, logical subsystems? Goal is to have an internal hierarchy and (potentially) re-usable submod- ules. This is not always possible, but can be applied for example on column models composed of trays, condenser, and reboiler.

2. Separation of the physical property functions Does the system contain functions or equations meant to calculate physical properties, that can be replaced by CO property function calls? Goal is to separate the property function parts (enthalpies, vapor pressures, fu- gacities, activities, etc.) of the model from the other aspects. With a successful separation it will later on be easier to exchange the calculation routines used for the thermodynamic properties and apply the respective CO functions. The separation should take place by splitting up separate equation systems. In an extreme case this could even lead to physical property equation systems that do not even consist of any equations anymore, but only functions and function calls.

3. Assign and check engineering units Are all necessary engineering units defned and included? Variables in function calls, parameters, and variables in ports need to have engineering units assigned in order to be used for CO unit operations. The Notation used in the model must therefore include a set of engineering units that consists of at least the engineering units necessary for these quantities. Ideally all variables of the equation system get their proper units; this way internal consistency of the equation’s variable dimensions can be checked in advance. The left hand side and the right hand side of an equation must for example have units of the same dimension, an equation of type “temperature = pressure” would be recognized as being inconsistent. Additionally engineering unit assignment guarantees that the variables’ values can be correctly converted to appropriate units if necessary.

4. Identify and set system inputs What inlets does the system have? For the input material streams summation conditions of the molar fractions are forbidden and respective equations have to be removed from the model. The remaining molar fraction variable has to be set as a desgin variable frst and will later on in the fowsheet be automatically set by the previous unit or a given feed stream.

69 3 Problem Analysis

The input quantities total fow, pressure, temperature, and molar fraction should all be part of the equation system and used therein. Otherwise the values of the inlet streams would be neglected and changes in the fowsheet’s feed would have no efect on the internal system and the results of the unit operation.

5. Identify and set system outputs What outlets does the system have? The output quantities total fow, pressure, temperature, and molar fraction should all be part of the equation system and used therein. A unit operation is obligated to calculate, or at least set, the variables of the outlets, so that the subsequent unit gets all necessary stream information. It is not allowed to defne output quantities directly as design variables (e.g. distillate product purity). A simple workaround for these output quantities that shall not be calculated inside the model is given by equations in the form of zout = zsys. In this example the output is set to be equal to the value inside the system, with z being a placeholder for one of the previously mentioned quantities. The value of zsys is then set fxed (as design variable), therefore indirectly determining the value of the output variable zout.

6. Identify and set public parameters What public parameters does the model have? Variables inside the model that are never calculated, but always given, can be defned as (adjustable) public parameters. This excludes system inputs (quantities of input streams) that are defned by preceeding units, and natural constants that are fxed and must not be set by the user. The public parameters can later on be manipulated by the user of the unit operation before the simulation is executed. In the CO unit operation these parameters can get additional descriptions. Setting the engineering unit is mandatory, otherwise the public parameter is expected to be of dimension “number”, i.e. without any unit.

7. Harmonize thermodynamics Which property calculations can be switched to CAPE-OPEN? The model’s property calculations have to be switched to calculation with functions using CO interfaces in order to be consistent with the other units of the same fowsheet. Quantities like vapour pressure, enthalpy, fugacity (coefcient), and activity (coefcient) are typical candidates for this. The calculations should be, depending on the quantity, switched across the whole model,

70 3.2 Target Workfow and Gap Analysis

otherwise internal inconsistencies may occur. Especially in the region close to a change of one-phase and two-phase behaviour small diferences in the calculation routines predicting a diferent number of phases can make the solution process fail. The switch of the thermodynamics is crucial and should be elaborated thoroughly. Sometimes it is even better to ignore the rule of switching subsystem after subsystem, especially when recycles or states close to a change of the number of phases are involved. Instead, a policy switching property after property may be superior, but this depends on the actual case and the best way cannot always be predicted beforehand.

E: Create CAPE-OPEN Unit Operation

The CO compatible model contains exactly defned input and output ports, may have public parameters, and uses a consistent set of property packages. With this prerequisites given, an automatic implementation of the CO interface specifcation for Unit Operations is possible, as developed and shown in this thesis (see chapter 4, section 4.2, for details of concept and implementation). One aspect to be considered besides the actual model is the CO type library that is equivalent to a notation defning the classes and functions to be used in the interfaces. The type library must be available when executing CO components, is provided for free by CO-LaN, and should be included into the installer when a unit operation is compiled and packaged. After completion of this activity the user has a digital object at hand, representing the mathematical model as a CO Unit Operation, being ready for simulation in a fowsheet environment (PME).

F: Execute Unit Operation in Flowsheet

Having a CO Unit Operation at hand, it has to be installed on the computer where it will be used. The fnal integration in a CO-compliant fowsheet environment depends on the chosen simulator. A common approach is to open the model palette, navigate to the CO Units, and drag & drop the unit operation into the fowsheet. After connecting the streams to the unit operation and setting the values for the public parameters, the unit can be executed. This activity is not the focus of this thesis. For detailed information how to integrate and execute a unit operation the manuals and the support service of the respective fowsheet simulation software have to be consulted.

71 3 Problem Analysis

Summary

In the end, for the process engineer wanting to model and simulate a unit operation the three basic steps from composition of a mathematical model to its solution stay the same:

1. modelling: preparing a mathematical model of the unit operation

2. code generation: generating code (locally), depending on the programming language

3. execution: simulating/validating the unit operation

The sub steps of these three basic steps are listed and explained in the following paragraphs.

Modelling In the proposed extension of the workfow new steps in the modelling part are mandatory. The workfow for documentation-based modelling of a unit operation now consists of eight steps:

1.1 Defne notation

1.2 Set up equations (with parameters)

1.3 Compose (preferably hierarchical) equation system

1.4 Identify engineering units in the system and add them to the notation

1.5 Defne physical property functions (via interface) and apply them in the equation system

1.6 Extend equation system with ports to become a unit operation

1.7 Optional: Connect unit operation with other units via internal streams to a fowsheet

1.8 Set fxed values for design variables and initial values for unknown variables (degree of freedom = 0)

It is possible to go back to previous steps and add missing information anytime. This becomes necessary when the model is extended with additonal equations. In step 2 the characteristic public parameters of unit operation have to be marked

72 3.2 Target Workfow and Gap Analysis by adding them to the list of parameters. Step 4 is necessary to communicate with simulation environment that are sensitive to engineering units. Especially the engineering units of the public parameters have to be set. This provides the future user of the unit operation in a fowsheet environment with the information which unit of measurement is expected when entering the numerical value of a public parameter. Using interfaces to defne the functions calculating physical property data in step 5 is important to have consistent thermodynamics throughout a fowsheet composed of several unit operations. Without step 6 an essential property of unit operations, the ports, would be missing, making it impossible to integrate the system into a fowsheet. With the optional step 7 multiple unit operation models can be connected to build an internal fowsheet in the modelling environment. This fowsheet would act as a single unit operation from outside when exported as a CO unit operation. This is helpful when the model is composed of many modules, but it is desired to deliver one single object to a collaboration partner. In the PME only one unit operation is to be added including all the functionality of the linked units in the internal fowsheet.

Code generation In the code generation part of the workfow proposed in this work two cases are distinguished. The distinguishing feature is the goal to be achieved:

2a Goal: Simulation of a single unit operation 2a.1 Select Code generator for equation-based simulation 2a.2 Set options for code generation and solver 2a.3 Generate code 2a.4 Optional: compile code 2a.5 Export prepared simulation

2b Goal: Validation in a fowsheet 2b.1 Complete model regarding public parameters (lower and upper bounds) 2b.2 Select prepared code generation for CAPE-OPEN Unit Operations 2b.3 Add meta information (Globally Unique Identifers (GUIDs), model name, author, copyright, solver options) 2b.4 Generate code and let server directly compile it

73 3 Problem Analysis

2b.5 Save installer for the Unit Operation

When the goal is to set up the simulation of a single unit operation, part “a” of the code generation workfow is appropriate. In this case investigating the solv- ability in general and gaining experience regarding this particular model is the main point of interest. It can be examined in which range the initial guesses of the unknown variables have to be in order to fnd a physically consistent solution for the given set of design values and inlet conditions. When a solution for an operating point was successfully found, the sensitivity regarding the inlets and public parameters with fxed initial values (chosen based on the solution of the point of operation) of the unknown variables can be investigated. In the optional part 4 of this code generation workfow the code has to be compiled for programming languages relying on compilation. This does not apply for programming languages that interprete code on runtime (e.g. python, MATLAB). In the end in part 5 the prepared simulation is exported. This means that the code is available for immediate execution in the program that was chosen before starting the automatic code generation. In case of MATLAB this is accomplished by storing the code as an m-fle, for Python a py-fle is appropriate. Workfow 2b is for embedding a unit operation in a fowsheet with other unit operations. This should not be done before this unit was successfully simulated beforehand (workfow 2a). In order to integrate a unit operation into a fowsheet environment the CO standard is required. When simulating the unit operation in a PME, only the public parameters and the connections to the ports can be modifed, all internal properties and settings – in simple implementations also including the initial guesses for the unknown variables to be calculated – are fxed. That is why it is important to include the entire information before code generation (steps 1 to 3). Later changes directly lead to new code generation and creation of a new executable (dll fle / installer). At least these steps happen automatically (steps 4 and 5). The user only has to initiate them, there is no manual interaction necessary after specifying the options and properties for code generation.

Execution In the workfow of execution again the two cases “single unit simulation” und “integrated simulation” are distinguished:

3a Goal: Simulation of a single unit operation 3a.1 Start targeted program (and load prepared simulation)

74 3.2 Target Workfow and Gap Analysis

3a.2 Run simulation 3a.3 Examine Results

3b Goal: Validation in a fowsheet 3b.1 Install unit operation (msi-fle automatically registers dll-fle) 3b.2 Start CO PME, e.g. Aspen Plus, and load unit operation 3b.3 Connect streams, specify parameters 3b.4 Run simulation 3b.5 Examine Results

When only a single unit operation is to be solved (workfow “a”), merely the readily generated code is to be executed. Therefore the respective simulation software is started and the export of the code generation step is executed. An example for this is starting MATLAB and running the m-fle. The simulation can be run immediately in case of a compiled executable, e.g. by using a console. In the other case, making use of CO to integrate the unit operation in a fowsheet environment (workfow “b”), the unit operation has to be installed on the computer (step 1). Afterwards this CO Unit Operation is registered and available to all PMEs supporting CO. In step 2 the CO-compatible PME is started. The previously installed unit operation can be added to an empty or an existing fowsheet. Before starting the solution process the unit operation has to be connected with the other units and the values of the public parameters have to be checked (step 3). Finally the simulation can be run (step 4), trying to solve the whole fowsheet including the custom CO unit operation. Either way the results of the simulation run must be available to the user. The user has to examine the results in order to decide if the model equations, the parameters, the point of operation, or the initial values have to be updated. This thesis aims at development, implementation, and application of the described workfow with the three steps modelling, code generation, and execution. At the beginning of the work a gap existed between the original state and the desired, targeted workfow. In the following subsection an analysis will show which steps of the described workfow could not be performed when the work on this thesis started. Based on this analysis of the missing features a roadmap results to step-by-step close the gap and extend the investigated modelling environment MOSAICmodeling. The implementation and fnal specifcations are given in chapter 4.

75 3 Problem Analysis

3.2.2 Gap Analysis of Missing Features

In this subsection for each of the three parts of the proposed workfow for creating CO compatible unit operations the missing features of MOSAICmodeling are named that have to be fxed. Each identifed problem area is given an identifcation code (e.g. “M3” for hierarchical composition of systems) in order to relate to it in following chapters.

Modelling

M1 Notation Descriptions for contained symbols are present, but a description of the Notation itself is missing and cannot be entered. There is no way of pro- grammatically telling the Notation which engineering units are allowed for names of variables created with the symbols specifed in the Notation.

M2 Equations with Parameters Regarding parameters it cannot be distinguished between adjustable/public parameters and fxed/private parameters. In Parameter Lists it is not possible to assign engineering units to the parameters.

M3 Hierarchical composition of systems The complete hierarchy of equation systems is not visualized, only direct parent-child relationships are accessible in the Equation System Editor. The preview in Evaluation Editor and Equation System Editor does only show all equations of the whole system at once, there is no possibility to dynamically show specifcally the equations of a selected subsystem. The namespaces of hierarchical systems are not built systematically, therefore separating the hierarchical information from the representation of the variables and making it harder to understand the relations inside composed systems of equations. It is not possible to assign user-defned names to the equation systems (e.g. “fash”, “condenser”), making it harder to correctly identify the namespaces and variables.

M4 Engineering Units (Units of Measurement) Engineering units as own accessible elements are missing or only occur isolated and hard-coded. A modular design and extensibility as well as an integration in re-usable sets of engineering units are desired.

76 3.2 Target Workfow and Gap Analysis

M5 External functions for physical properties Engineering units must be available when defning Interfaces for physical property functions. In function applications scalar as well as vectorial variables must be allowed for inputs and outputs.

M6 Adding ports to model a unit operation Basic functionality is implemented, but engineering units and checks for plausibility of the connection of port and equation system are missing.

M7 Flowsheeting in MOSAICmodeling There is no visualization of ports and stream connections as known from fowsheet simulators (rectangles/boxes for unit operations and arrows for streams). Streams cannot be given names, making it harder to distinguish them. Clean connection and merge of variables accross unit operation boundaries in MOSAICmodeling, especially regarding index management, needs a revision. Naming and numbering of open ports as well as ports connected with streams (in fowsheets) can be ambiguous (compare to remarks regarding “hierarchical composition” above).

M8 Setting classifcation and values of variables As there is no unit conversion, values for variables cannot be entered in an engineering unit selected by the user, but have to ft to the implicit engineering unit determined by the model (i.e. equation system). Customized sorting of variables based on the diferent parts of the variable names (base name, superscripts, subscript, indices) is not possible, making it hard to fnd and cluster similar variables for value assignment. Regarding parameters it cannot be distinguished between adjustable/public parameters (necessary for CO parameters) and fxed/private parameters (necessary e.g. for constants like π or R).

Code Generation

Here only the new parts (validation in a fowsheet environment, case b) of the proposed workfow are considered.

CG1 Public Parameters Parameter classifcation (contrast of adjustable/public to fxed/private) and defnition of parameter bounds are missing (adjustable parameters for unit operations do need bounds).

77 3 Problem Analysis

CG2 Code generation for CO Unit Operations (combination of several UDLS) Code generation explicitly making use of the external ports is missing in the user-defned language specifcators. There is no feasible code generation mechanism for generating multiple fles at once. Customizable implementation of external, user-defned function calls is missing in language specifcators. Descriptions of user-defned language specifcators including the available code generation options must be available to the users when selected for code generation.

CG3 Adding meta information (GUIDs, model name, author, copyrights, solver options) It must be possible to generate new random GUIDs. Model name, author, and copyright informationen must be included in code generation for unit operations. Solver options (when available) must be visible and modifable upon user request. Additional documentation (e.g. PDF fles) should be includable into the unit operation to be created, exported, and installed on the user’s computer.

CG4 Automatic code generation and compilation on server It must be possible to choose between 32 bit and 64 bit unit operations. An asynchronous procedure for execution on the server is not implemented. Sticking to synchronous calls would cause an undesired freeze of the user interface when waiting for the server to complete its tasks (compilation, linking, creation of dll fle, and packaging of the installer).

CG5 Installer for unit Operation A convenient design of the installer has to be developed (logos, available installation options, meaningful descriptions). A license agreement must be included in the installer.

Execution

Here again only the new parts (validation in a fowsheet environment, case b) of the proposed workfow are considered.

E1 Installation of Unit Operation The CO type library must be included in the installer. During deinstallation of a unit operation the type library must only be removed from the computer when this particular unit operation was the last CO component

78 3.2 Target Workfow and Gap Analysis

on this computer. This is vital for remaining CO software on this computer to still work as expected. An optional feature installing a documentation of the unit operation (i.e. a documentation of its model) should be available in the installer.

E2 Start PME and load CAPE-OPEN Unit Operation Correct registration of the unit operation on the computer has to be ensured. Meta-information must be included in the unit operation in order to show this information when selecting a unit operation for integration in a fowsheet.

E3 Connect streams and set parameter values The type of the port must be correctly implemented in order to be able to connect a stream of the respective type in the fowsheet environment. Public parameters of the model including their default values and bounds must actually be available in the unit operation before running a simulation in the PME.

E4 Run simulation The CO unit operation created based on the user’s model should be robust regarding changes in the inputs / point of operation, and parameter values.

E5 Examine Results The results of the last simulation run need to be available to the user. The mere display of the calculated values of the ports connected to output streams is not sufcient. The fnal values of all unknowns have to be available for reimport into the original model.

4 Concept and Implementation

This chapter details concept and implementation of equation-based fowsheeting and the workfow for systematic modelling as introduced in the previous chapter 3. The implementation afects several aspects covering MOSAICmodeling, the relational database used in the backend, and the additional scripts running on the server accessing the database. So this chapter deals on the one hand with the work packages defned to fll the gaps previously identifed. On the other hand the editor explicitly created for the export of unit operations is explained. With its graphical user interface this editor is the immediate point of connection between the user and the routine creating the CAPE-OPEN unit operations.

4.1 Filling the Identifed Gaps

In this section the concepts are described that will fll the gaps previously identifed in the area of modelling and code generation in order to be able to apply the workfow and perform equation-based fowsheeting in and with MOSAIC- modeling. The structure of this section is not aligned to the single steps of the workfow, but clustered in logical work packages that may be involved in more than one step. For example the logical work package related to the engineering units plays a role in several steps of the workfow. The codes that have been introduced in section 3.2.2 to identify the gaps are picked up and connected to the work packages. The covered gaps are always named at the beginning of each of the following subsections. The implementation regarding the part execution is described in section 4.2.

4.1.1 Composition of Hierarchical Systems

Afected missing features: M3 (Hierarchies), M7 (Flowsheeting)

One goal of documentation-based modelling is the simplifed reusability of approved model elements. The better model parts are documented, the easier it

81 4 Concept and Implementation Heacyve fa qainsse nthe in system equation an of view Hierarchy 4.1: Figure iuainEditor Simulation

82 4.1 Filling the Identifed Gaps is to decide if this model is suited to fulfll the current project’s objectives. When a model is considered suitable, it can be combined with other re-used model parts or new models, to compose a bigger, overall model. The Equation System Editor was enhanced in the course of this thesis, providing the possibility to assign the enclosed subsystems, called Connected Elements, user-defned names. These names can be chosen independent of the names that are used to store the connected elements in the database and are only valid inside the particular overall system. The namespaces automatically assigned inside MOSAICmodeling will include the information of the user-defned names when working on the model in the Simulation editor1. This feature makes it more convenient to sort and fnd the variables when it comes to the assignment of initial values and design variables.

Basics of the Hierachy Panel

In order to get a good overview of the equations contained in the sub equation systems, the modelling environment should visualize the relations / structural hierarchies between the subsystems. The hierarchies in this context do not relate to transitions regarding diferent scales in space or time, but in sub-systems and super-systems. From an information processing point of view the relations of sub- and super-systems form a tree structure with a root equation system, inner systems, as well as leaf-level equations and leaf-level functions. At each level of this tree the equations are internally numbered, starting with 0. This way each system and each equation is uniquely identifed. Fig. 4.1 on page 82 shows a screenshot of the hierarchy panel as implemented in MOSAICmodeling for this thesis. On the left hand side the model tree is displayed. The frst equation is identifed by number “00000”, whereas the equation system of the total condenser has hierarchy number “01”. The root system (in this example having the global MOSAICmodeling id 103857) has an exceptional position. It does not have an internal number as it is the only, unique element on its root level. On the right hand side of the panel the equations of the (sub) system selected in the hierarchy on the left hand side are displayed. In case there is no selected element, automatically all equations are displayed. This is equivalent to selecting the root equation system. For this thesis the existing, systematic numbering

1The term Evaluation Editor is a synonym to Simulation Editor and was primarily used in chapter 3.

83 4 Concept and Implementation of the subsystems has been visualized in form of the hierarchy panel. With this panel users fnally got a convenient overview of the model’s composition. With a right-click on an element in the hierarchy tree the selected element can be opened in its respective model editor. This works for equations (Equation Editor), equation systems (Equation System Editor), and functions (Function Editor). The hierarchy panel is included in the Equation System Editor as well as in the Simulation Editor.

Connection policies

When composing equations and equation systems to bigger systems, diferent possible rules exist how the variables are incorporated in the overall system. This is described by the term connection policy. The three possible policies are named integrate, encapsulate, and streams. They have been introduced by S. Kuntsche in his doctoral thesis (Kuntsche, 2013). Nevertheless the exact meaning and the rules of integrate and encapsulate have been updated in the course of this thesis. The two updated policies are explained on MOSAICmodeling’s web site and repeated here for the reader’s convenience: “The basic contract of the naming policy ‘integrate’ is as follows: • Basic rule: If an equation or equation system (sub element) is added to a super equation system (super element), the sub element’s variables will get the namespace of the super element

• Additional rule using diferent notations: if a sub element is connected to a super element and both elements use diferent notations, then all variable names of the sub element have to be translated (by a connector) into the super notation.

• Attention: In any time the meaning of each variable has to be uniquely defned by the notation of its namespace. If diferent notations are used in sub and super element, each variable has to be translated. Otherwise the meaning of some variables coming from the sub element would be undefned in the notation (and therefore in the namespace ) of the super element.

• Result: After parsing, all variables have a top level naming according to the super notation in the top level namespace. (http://www.mosaic-modeling.de/?page_id=594)”

84 4.1 Filling the Identifed Gaps

“The basic contract of the naming policy ‘encapsulate’ is as follows: • Basic rule: if an equation or equation system (sub element) is added to a super equation system (super element), the sub element’s variables will get an own namespace.

• Additional rule using a connector: If a sub element is added to a super element by using a connector, only those variable names of the sub element that are translated by the connector will get the super element’s namespace.

• Result: When considering the sub element, only the variables translated by a connector have a top level naming according to the super notation. (http://www.mosaic-modeling.de/?page_id=597)”

As soon as an equation system or an equation to be added to a super-system does contain a notation not being identical to the one of the super-system, the connection policy is automatically set to “encapsulate”. This way it is prevented that variables not part of the super-system’s notation are directly put into the super-system’s namespace. According to this it is highly recommended to use connection policy “encapsulate” always with a connector. Without a connector two separate systems would arise that have no connection to each other. The behaviour of the connection policy “encapsulate” mirrors its state as a pre-stage of the streams principle. According to this principle only those variables are handed over to another system, that are mapped inside the connector (encapsulate) or port (streams), respectively. The diference between these two options lies in the arising model hierarchy: While using encapsulate one system is superior (sub-/super-system principle, the sub-system is added to the super-system), the policy streams leads to two unit operation equation systems on the same level, both being part of a common fowsheet equation system and connected by streams.

The connection policy “streams” can only be used for equation systems modelled as unit operations and therefore containing ports. These unit subsystems do only expose those variables that are part of a port. It is prevented that other variables are undesirably available in connected systems. As soon as ports are found in a loaded sub equation system, the connection policy is automatically preset to streams connnection policy.

85 4 Concept and Implementation

Besides the internal element number and the connection information the hierarchy panel optionally shows if a transformation is applied on an equation or equation system. It is also indicated which discretization style is applied when using the transformation(s):

• s: only state variables get discretization indices

• a: all concerned variables get discretization indices

• sa: combined occurence of both options

Transformations have been introduced to MOSAICmodeling in the course of my own Master’s thesis. The transformation feature is described in section 3.1.1 of this thesis and also in the doctoral thesis of R. Kraus (Kraus, 2015, pp.49-55).

Connecting Functions

Functions use an implicit connector when they are applied to an equation system, so in this case it is neither necessary nor possible to specify a connection policy. In the hierarchy view instead of the internal IDs that are shown in case of equations and equation systems, an “f” for “function” and the number of function applications/calls are displayed. The functions are not ordered in the tree, neither by name, nor by ID. This refects the fact that the function defnitions later on in the created code appear in an arbitrary order as well. This has at the same time no infuence on the order of the function calls later on in the program code. MOSAICmodeling automatically fnds a valid calling sequence. An example are the functions b = f(a) (4.1) and c = f(b) (4.2) that have to be called in exactly this order, because of their dependency. The result of the frst function is used as an input in the second function. Assuming a third function call a = f(c) (4.3) is introduced, no valid calling sequence exists anymore, because of the circular dependency (the frst function needs the result of the third function, while the third function needs the result of the second function). When such an inconsis- tency is identifed, the user is informed that these function calls cannot be used

86 4.1 Filling the Identifed Gaps this way. It is not possible to resolve the circular dependency automatically. One option to resolve this manually is to convert at least one of the functions contained in the circle into an equation. After removing the function call and adding the respective equation the solver will be able to iteratively fnd a solution for the system containing equations and function calls.

Generic Expressions and Index Pools

One strength of MOSAICmodeling is the possibility to use generic template equations that are not instantiated before the Simulation Editor. This is implemented with variables having generic, un-instantiated indices. A commonly seen example are equations like

yi = Ki · xi (4.4) that are unfolded/instantiated to

yi=1 = Ki=1 · xi=1, (4.5)

yi=2 = Ki=2 · xi=2 (4.6) after the values for the indices have been specifed. The indices of the diferent, composed subsystems have to be aligned. This is of importance as soon as more than one notation is used inside • a unit operation equation system,

• a system using connection policy “encapsulate”, or

• a system containing unit operations connected with each other. Aligning the indices in this context means that variables matched with a connector or a port must formally have the same index, therefore the diferent names of this index are collected in a set or “pool” of index names. In such a case there is not the one and only name of an index, because of the potentially diferent names used in equally important, connected unit operations. For the display in the user interface one of the possible names is selected as representative, still ofering the possibility to display all the other names, too. The screenshot in Fig. 4.2 on page 89 shows a pool indicated by a folder symbol, with the selected, representative name “e[0]103857.i”. A typical example is the index of the number of components: own namespaces exist at least for the equation system and,

87 4 Concept and Implementation in case of unit operations, for the ports, therefore leading to several potentially diferent names for one and the same index. For each index pool the numerical integer value for the so-called “Maximum- ValueSymbol” of each index is clearly set. The grouping of indices into index pools simplifes the assignment of the MaximumValueSymbol’s numerical value, because all contained indices get the same value once the pool representative’s value is set. In the example in Fig. 4.2 the selected index stands for the number of components in a distillation column. The index values 1 and 2 are connected to the meanings “I-Butane” and “N-Butane”, respectively.

Referencing Usages

In all editors a section has been added that can display a list of element ref- erences. This section is called Usages and shows the elements that include the currently opened element. In Fig. 4.1 on page 82 and Fig. 4.2 on page 89 it can be seen in the upper part of the screenshots. Besides ID and name of the containing elements, the model element type and the related description stored in the database are loaded. With this Usages panel it is possible not only to navigate “down” the hierarchy, but also navigate “up” to systems or model elements that use the currently opened element and are afected by changes in it. In the example the simulation with ID 103860 is included/used in the unit operation model elements with the IDs 104019 and 104171.

With the subject area “Composition of Hierarchical Systems” especially the gaps regarding hierarchical composition of systems (M3) and fowsheeting in MOSAICmodeling (M7) have been flled.

4.1.2 Engineering Units

Afected missing features: M1 (Notation), M2 (Parameters), M4 (Units), M5 (Functions), M6 (Ports), M8 (Classifcations and Values), CG1 (Public Param- eters), CG2 (CAPE-OPEN Interfaces)

The units of measurement, in this thesis mainly called engineering units, have an infuence on several parts of the workfow and of the modelling environment. The meaning and the application have been covered in chapter 2. In this section

88 4.1 Filling the Identifed Gaps ) with meanings added for values 1 Simulation Editor (I-Butane) and 2 (N-Butane) Figure 4.2: Index pool (selected line in the lower half of the

89 4 Concept and Implementation it is described how the engineering units have been implemented in the equation- based modelling environment MOSAICmodeling. One requirement was to stick to the principles “documentation-based” and “modular” also for new elements related to the engineering units. Therefore an open concept has been developed, allowing for fexible customization. The user is free to defne nearly arbitrary units of measure, as long as they can be composed by using the base dimensions of the SI system. It is in the responsibility of the creating user to add meaningful descriptions in order to foster reusability of the engineering units.

Overview of the modular concept

The engineering units are required in all editors in which variables are involved. The same is true for notations, the central modelling element in MOSAICmod- eling. Therefore the units are attached to the notations to prevent loading them separately in all the editors. At frst the engineering units have to be created once in a new, dedicated editor, the Engineering Unit Editor (see Fig. 4.4 on page 92). The units are stored the same way as all other elements in the modelling database. They can be re-used and made accessible to other users. In a further editor, the Engineering Unit Set Editor (see Fig. 4.6 on page 96) these units are composed to re-usable sets. These sets are stored in the modeling database, too. When an Engineering Unit Set is to be used for a model, it has to be assigned to the notation used in this model. Each notation can have at most one associated engineering unit set. An engineering unit set can on the other hand be assigned to an arbitrary number of notations, as the meaning of the engineering units symbols is defned independent of the later on assigned notations. A visualization as a UML class diagram is shown in Fig. 4.3 on page 91. It states that a notation knows at most one Engineering Unit Set. An Engineering Unit Set does not know any notation, but can be used in an arbitrary number of notations. The Engineering Unit Set is an aggregation of an arbitrary number of Engineering Units that it can access. The Engineering Unit does not know in which Engineering Unit Sets it appears. In the previous section on hierarchical systems it was explained that the modelling environment acts as an observer that is able to make a connection between a model elements and the model elements that include it. This way it is despite of the non-navigability possible to determine on the one hand the engineering unit sets a unit is included in and on the other hand the notations that include

90 4.1 Filling the Identifed Gaps

Notation

0..*

0..1

Engineering Unit Set

0..*

Engineering Unit

Figure 4.3: UML class diagram of the relations between Notation, Engineering Unit Set, and Engineering Unit.

a certain engineering unit set.

Engineering Unit Editor

The Engineering Unit Editor ofers the user the possibility to defne new engineering units. Of course existing units can be loaded and used to create new, derived engineering units. When the user has write access, the engineering unit can be saved with modifcations, otherwise it has to be saved using another name. In order to specify an engineering unit the following information is expected:

1. Unit identifer. Expects a short LATEX expression to be rendered when displaying the Engineering Unit in combination with a numerical value to represent a physical quantity. An example of an identifer for a unit of m dimension “velocity” is “\frac{m}{s}”, later on rendered as “ s ”.

2. Unit name. Expects a short String giving the name of the Engineering Unit (if there is one). An example of a name for a unit of dimension “pressure” is “Pascal”.

91 4 Concept and Implementation iue4.4: Figure niern ntEditor Unit Engineering loigt en new defne to allowing niern Units Engineering .

92 4.1 Filling the Identifed Gaps

3. Unit description. Expects a String containing a meaningful description of this Engineering Unit. In contrast to identifer and name a whole text can be written.

4. Relative unit. This checkbox can be checked to make a unit “relative”. Relative units do not have an absolute zero, and usually cannot be scaled meaningfully to an (absolute!) base SI unit. An example for a relative unit actually is Degree Celsius (of dimension “temperature”), because 10 ◦C is not ten times as much as 1◦C, and there is no scaling factor to convert 10 ◦C to an unambiguous value in Kelvin (absolute). In the frst implementation MOSAICmodeling only allows to convert relative units into other relative units. Therefore the elements KelvinRelative and CelsiusRelative have been added besides the non-relative versions Kelvin and Celsius. Whenever extensions are planned in the direction of dimensionality checks, this has to be considered (and maybe the specifcation has to be changed).

5. Dimension name. Expects the name (if there is one) of the physical dimension (or unit family) the unit belongs to.

6. Dimension description. Expects a String containing a meaningful description of this units physical dimension. In contrast to the dimension name a whole text can be written.

7. Dimension exponents. Expects a rational number for each physical base dimension. The rational number is composed of an integer valued numerator and a positive integer valued denominator. This becomes clear when looking at an example: the physical dimension “velocity” is represented by the product of the base dimension “length” to the power of one and the base dimension “time” to the power of minus one. Therefore the numera- tors of all other base dimensions have to be zero, whereas length has a one and time a minus one. The denominators most times can stay at one, only √ for units like P a an actual fraction has to be represented, in this case setting the denominator to 2 in order to represent the root. A dynamically updated preview supports the user in setting the exponents by immediate visualization of the dimension expression.

8. Conversion to SI. Expects a mathematical expression entered as LATEX string how to convert a value given in the current unit to the corresponding value in the respective SI base unit. In the mathematical term the value

93 4 Concept and Implementation

EngineeringUnit - identifier: String - name: String - description: String - relativeQuantity: Boolean - conversionToSI: String - conversionFromSI: String - dimension: EngineeringDimension 0..* 1 EngineeringDimension - dimensionExponents: Rational[8] - familyName: String - description: String

Figure 4.5: UML class diagram of the relation between EngineeringUnit and En- gineeringDimension including attributes.

of the current unit has to be represented by the letter “x”. An example is the conversion of “bar” to “Pascal”: x/(105). If there is no conversion necessary, it is sufcient to just enter “x”.

9. Conversion from SI. Expects a mathematical expression entered as LATEX string how to convert a value given as an SI unit to the corresponding value in this unit. In the mathematical term the value of the SI unit has to be represented by the letter “y”. An example is the conversion of K (absolute) to ◦C: y − 273.15. This example shows that even if there is no scaling factor (i.e. multiplication), a conversion is still possible by entering the shift that exists between the zero in the Kelvin scale and the zero in the Celsius scale. If there is no conversion necessary, it is sufcient to just enter “y”.

All this information is stored in the database as an XML element. The XML schema defning the structure of the XML can be found in appendix C. The schema is merely a serialization of the EngineeringUnit class containing the felds storing the user input to the nine felds listed above. The class diagram depicted in Fig. 4.5 on page 94 shows the two classes EngineeringUnit and EngineeringDi- mension having the respective attributes. The class EngineeringDimension en-

94 4.1 Filling the Identifed Gaps capsulates the engineering dimension / unit family information. In the diagram the exponents of the base dimensions are consistently modelled with the type Rational and multiplicity 8 (for the seven physical bases and the additional monetary/currency dimension). An EngineeringDimension can potentially be used for many EngineeringUnits, whereas an EngineeringUnit object can only know and reference one EngineeringDimension object at a time. Users not sure which engineering units are practically in use or how they are defned can have a look at resources in the internet, where a comprehensive list of applied units can be found2.

Engineering Unit Set Editor

The Engineering Unit Set Editor depicted in Fig. 4.6 on page 96 lets the user create sets of engineering units to be used in notations (and therefore indirectly in all elements). Existing sets can be modifed by adding new units or removing contained units. Removing an engineering unit should be well-thought, as the specifcation of existing models can be damaged when the removed unit is still used in Notations, Parameter Lists, Interfaces, or Variable Specifcation Lists. Adding and removing are the two only functions of this editor. All engineering units can be added that at least exists read access to. In order to save changes in an Engineering Unit Set write access is mandatory, otherwise the set can be saved as copy. The Engineering Unit Set is stored as a separate element in the modelling database. The XML schema defning the structure of the XML can be found in appendix C. In the implementation (in a JAVA class) the engineering units are grouped in a map in order to have immediate access to units of the same dimension. This is relevant for users that want to enter a variable’s numerical value in an engineering unit that is not the same as the one defned in the model beforehand, but an automatically convertible one (see the following section for a comprehensive description).

Application of Engineering Unit Feature

The engineering units are a new feature introduced to MOSAICmodeling in the course of this thesis. Another new concept has been implemented in the backend that empowers the user to decide independent of an administrator whether a feature, e.g. the engineering units, shall be activated. This way the user can decide

2http://unitsofmeasure.org/ucum.html date of last access: 2019-03-16

95 4 Concept and Implementation iue4.6: Figure niern ntStEditor Set Unit Engineering loigt ops e of set a compose to allowing niern Units Engineering .

96 4.1 Filling the Identifed Gaps on its own if the options ofered by the use of engineering units will be visible in the user interface, directly depending on the activation status. So users that are not familiar to MOSAICmodeling may start modelling without engineering units. More experienced user will enable the Engineering Units to beneft from the advantages of using them. One exception of a user interface that cannot be used without the engineering unit feature is the Interface Editor. As MOSAIC- modeling Interfaces are explicitly used for external functions, ports, and streams (that all heavily rely on exact defnitions of engineering units), the Interface Ed- itor is deactivated when the user decides to disable Engineering Units.

When engineering units shall be used inside a model, at frst the Engineering Unit feature has to be activated. Only with this feature access to the editors for Engineering Units and Engineering Unit Sets exists. First goal, when using engineering units, is to create an Engineering Unit Set containing all the necessary Engineering Units and adding this set to the model’s Notation. In case such a set does not already exist, a new one has to be created and flled with units. Again it is possible to select existing elements from the database. If a desired Engineering Unit cannot be found in the database, it has to be created in the respective Engineering Unit Editor. In the Notation the content of the associated Engineering Unit Set is displayed. Internally a default unit is assigned whenever an engineering unit is expected, but not specifed, yet. This default unit is displayed as “ANY” and used until an actual unit is assigned. Whenever two engineering units are compared, the ANY-unit has wildcard status. This means a connection of two variables with at least one of them having ANY-unit, is never forbidden. A dimensional analysis will of course never be complete as long as one variable has this default unit. This is why it should always be a goal to assign Engineering Units to all variables present in the model before the frst simulation is performed.

In the Notation the frst possibility to assign Engineering Units to names of variables exists, before they are actually used in equations. For example it can be defned that all variables created with the base name “T” will get the Engi- neering Unit “Kelvin”. The list of units available in the Engineering Unit Set as well as the preassignments of Engineering Units to names of variables in the No- tation can be updated later on. In all following editors that explicitly use names of variables (Parameterlist Editor, Interface Editor, Function Editor, Connec-

97 4 Concept and Implementation tor Editor, Equation System Editor (Function Application, ports), Simulation Editor (simulation)), the Engineering Units will be available via the Notation. The pre-assignments defned in the Notation can thereby be overruled by more specifc assignments. Only if they are not overruled, they persist throughout the modelling process.

The Connector is the central element for the assignment of Engineering Units. Whenever an Equation or an Equation System is added to a super level Equation System, a Connector can be applied, assigning Engineering Units to all matched variables. This way it is basically sufcient to prepare a single connector assigning all Engineering Units to the whole model, that is applied at the end of the modelling process to the top level Equation System. At this point in future work the consistency of the engineering dimensions in the equations can be checked. In doing so it is tested if both sides of an equal sign the same dimension and only variables with the same dimension are added. This has already been described in section 2.1. The Engineering Units next play a role when the simulation is prepared and initial values as well as design values are assigned. While Nota- tion, Connector, function application, Parameter List, and Interface defne the Engineering Unit inside the model, the Simulation Editor ofers the possibility to enter the value according to another Engineering Unit of the same unit family / engineering dimension. One example is the defnition of a pressure, that is interpreted in “Pascal” inside the model, but can be assigned a design/initial value in “bar”. Internally the variables have exactly one value, but two Engineer- ing Units: One unit related to the view (display unit) for entering the value and one unit coming from the model defnition (model engineering unit) that is determined by the Engineering Unit of the top level variable naming and actually linked to the value of the variable. Due to the fact that only units of the same dimension can be selected for entering the variable’s value and for each unit the conversion expressions are known, it is no problem to automatically calculate the value that fts the desired unit.

Essential for the application of engineering units is eventually the successful code export considering all unit conversions and correct incorporation of all interfaces to external programs. As a variable inside program code can only have exactly one value at one point in time, in the generated code the engineering unit defned in the model (i.e. model engineering unit in contrast to display unit) is

98 4.1 Filling the Identifed Gaps used. When function calls or equations of subsystems needs values according to other units (of the same engineering dimension), the conversion terms defned in the Engineering Unit Editor are automatically entered. This way physical property functions expecting a pressure in bar will get the appropriate converted value of the variable that is technically defned having the unit Pa in the model. Considering the UDLS it was taken care of that the information of the applied engineering units is available in the UDLS. With the help of a UDLS it is possible to implement CO public parameters as well as CO ports correctly. That aspect, correct implementation of CO unit operations including public parameters and physical property calls is essentially one of the main goals of this thesis.

Comparison to JAVA Standardization Approach JSR 363

In september 2016 a standard for Units of Measurement for the JAVA programming language was released in the fnal version (JSR number 363). At this point the specifcation and implementation of respective engineering units in MOSAIC- modeling was at a stage were frst examples were already created. This is why JSR363 was not used in the course of this thesis. Units of measure / engineering units are an important topic when it comes to the exchange of models. For the future an implementation considering JSR363 may bring additional benefts. So the current implementation in MOSAICmod- eling is compared to the specifcation of JSR363. The common aspects of both approaches are described and important points that have to be considered when re-implementing the units according to the new standard are named. MOSAICmodeling as well as JSR363 use the central terms Physical Quantity, Unit, and Dimension. The classes in JSR363 are defned as interfaces, that have to be implemented. In the ideal case the classes “Variable”, “EngineeringUnit”, and “EngineeringDimension” that are already present in MOSAICmodeling can act as possible implementations of the JSR interfaces.

Dimension For the interface “Dimension” the methods pow, root, and getBaseD- imensions have to be implemented, that do not exist in MOSAICmodeling, yet. Especially for getBaseDimensions the concept of a base of dimensions needed to be introduced to MOSAICmodeling. A mapping based on the existing classes seems very likely to be possible.

99 4 Concept and Implementation

Unit The interface “Unit” contains in contrast to the current implemention function signatures for calculation with engineering units. Examples are multiplication with a scalar value or with another unit, the division by a scalar or by another unit, pow, and root. Additionally the concept of JSR363 has the concept of a “UnitConverter”, encapsulating functionality for conversion of units of the same dimension. In MOSAICmodeling the only allowed conversion is from and to SI. The conversion formula is stored within each engineering unit. Here it has to be investigated in detail how the functions of the interface “UnitConverter” can be aligned with the concepts present in MOSAICmodeling. This seems to be considerably more work compared to the interface “Dimension”.

PhysicalQuantity/Variable The concept of the interface “Physical Quantity” as a representation of a tuple of value and unit corresponds to the class Variable in MOSAICmodeling. This interface declares functions to calculate with quantities. This includes addition and subtraction of another quantity, multiplication with a scalar value, multiplication with another quantity, division by a scalar, division by another quantity, building the inverse of a quantity, and conversion to a quantity of another unit. The calculation routines do not exist in MOSAIC- modeling’s class Variable, but it seems viable to implement these in the future.

A general remark regarding JSR363 is the use of the concept of Java “Gener- ics”. The basic idea is that for each unit that shall be assigned to quantities, an own class exists. This way it is possible to check on class level if diferent quantities are compatible. In MOSAICmodeling there is only one class representing units of measurement, EngineeringUnit, and the diferentiation of units takes place on instance/object level. Due to the fact that objects are not created until runtime, they dynamically take the attribute values the user has specifed in the engineering unit editor. This includes the name of the engineering unit that is not known at compile time. Before the basic diferences in the concepts are not clarifed, the present implementation of engineering units will not be easily migrated to be an implementation according to JSR363. In worst-case the self-defnition of engineering units by the user has to be restricted and all units of measurement have to be added by the MOSAICmodeling developers. This would partly contradict the customizability of model formulation, an approach identifed as a core principle so far within MOSAICmodeling.

100 4.1 Filling the Identifed Gaps

With the subject area in this subsection the gaps involving engineering units, i.e., M1 (Notation), M2 (Parameters), M4 (Units), M5 (Functions), M6 (Ports), M8 (Classifcations and Values), CG1 (Public Parameters), and CG2 (CAPE- OPEN Interfaces), have been flled.

4.1.3 Function Calls

Afected missing features: M5 (Functions), CG2 (CAPE-OPEN Interfaces)

In CO unit operations physical property functions are called. These calls have to be part of the model. An analysis performed in the course of this thesis showed that it is possible to describe the use of functions in MOSAICmodeling as a process of three phases, consisting of function defnition, generic function call, and implemented function call (see Fig. 4.7 on page 102):

1. The function defnition is formulated generically, comparable to functions in programming languages like C or Java. The function defnition does not need to know how the variables are named that are used when the function is called. Important is the type defnition of the variables, including the engineering unit and the mathematical dimension (scalar vs. vector), and the name that is used inside the function body.

2. The generic function call is applied before the indices are instantiated. At that point in time it is not known how long certain vectors will be or how many elements the vectors will contain. The exact number of function calls therefore is not necessarily defned, yet. The function is to be called for each variable / vector element.

3. The implemented function call is equivalent to an actual function call in the resulting code. Scalar as well as vector-valued variables can be used, depending on the function defnition. In case the generic function call says that the function is to be called for each stage of a column model and the index for the number of stages is instantiated to cover the values from 1 to 20, this results in 20 actual, implemented function calls.

Elements 1 and 3 occur in generated code, element 2 exists in the xml model elements of equation systems and as a visualization including an input formula in

101 4 Concept and Implementation

Figure 4.7: Class diagram of Function, Function Application, and Function Ap- plication Implementation with examples

Table 4.1: Function call matrix, allowed combinations have a checkmark Function Call Scheme AB CDE z = f(x) ✓ - --- zi = f(x) ✓ - ✓ -- z = f(xi) - ✓ --- zi = f(xi) ✓ ✓ - ✓ ✓ zi = f(xk) - ✓ -- ✓ the GUI. According to these three elements the three classes Function, Function- Application, and FunctionApplicationImplementation3 exist. For this thesis the class FunctionApplicationImplementation was introduced. Before, the elements 2 and 3 were mixed up in class FunctionApplication. The specifcation of what is allowed in MOSAICmodeling Functions was formulated more precisely. Vector-valued inputs and outputs are now considered systematically. Vector-valued variables are only allowed if an interface is used for function defnition. In this case it is not possible to defne a function body and function parameters have to be explicitly included in the interface as function inputs. The defnition of the function body then follows later in the LS in connection with the code generation. When function inputs, as well as function outputs, shall be scalar values, the option to defne the function body explicitly (instead of relying on an interface defnition) can be selected. In this case an additional parameter list can be loaded. The variables of the funciton body that

3Implementation detail: On source level the application classes are actually called Function- Appliance and FunctionApplianceImplementation, respectively.

102 4.1 Filling the Identifed Gaps are part of the parameter list must not be added as separate function inputs anymore. This is helpful when coefcients of polynomials can be provided as parameters, because these do not change from call to call – in contrast to input variables. The possibility to use vector-valued variables in function defnitions and in function calls increased the number of distinguishable cases. In the course of this thesis the specifcation of the possible function calls has been systematically written down and implemented. The possible function calls are listed in Tab. 4.1. The fve cases for diferent defnitions of a function interface have the following meaning:

A scalar output z, scalar input x

B scalar output z, vector input xi

C vector output zi, scalar input x

D vector output zi, vector input (same index) xi

E vector output zi, vector input (diferent index) xk

Fig. 4.8 on page 104 shows the user interface to create a (generic) function call. In this example a vector-valued function was defned via interface, having two scalar and one vector-valued input. The function’s engineering units have been set by the interface as well. The engineering units of the function call have to be compatible to the function’s engineering units. In the “Applications (Func- tion Call)” area in the GUI the variables of the generic function are matched to the variables of the equation system that will be used in the function call. The function body is, as metioned before, defned later during code generation by an appropriate LS. The user interface shown in Fig. 4.8 was extended in this thesis by engineering units and the table for displaying the parameters.

With the subject area in this subsection especially the gaps regarding functions for physical properties (M5) and code generation for CO Interfaces (CG2) have been flled.

4.1.4 Parameters

Afected missing features: M2 (Parameters), M8 (Classifcations and Values), CG1 (Public Parameters)

103 4 Concept and Implementation iue4.8: Figure ucinApplication Function o vector-valued for Function nthe in qainSse Editor System Equation

104 4.1 Filling the Identifed Gaps

Parameters in MOSAICmodeling were originally introduced for functions. They served as placeholders for the coefcients of physical property polynomials. Later is was allowed to use them in equations, too. Parameters were in both cases fxed variables, serving as constants in contrast to varying function inputs.

The CAPE-OPEN defnition says: Unit Operations have a list of parameters (this list may be empty). In the context of CO parameters are explicitly understood as quantities that can be varied before the execution of a simulation. One example are set points of controllers, that could be changed from simulation run to simulation run. In this case the fxed parameters of function must be separated from the adjustable parameters according to CO, because the fxed function parameters must not be varied by the user. Due to the fact that the word “parameter” was already in use in MOSAICmodeling, the meaning of this term has been updated for this thesis in order to cover the diferent aspects. Therefore a new classifcation of parameters was introduced: Adjustable Parameter versus Fixed Parameter. The adjustable parameters are in the current implementation used for the parameters according to the CO defnition of public parameters. The fxed parameters are used as constant, non-modifable quantities.

Fig. 4.9 on page 106 shows the graphical user interface of the simulation editor, where the parameters defned in the model are listed. There it is now possible to select for each parameter separately its classifcation, either FIXED or AD- JUSTABLE. The value that can be entered in this panel can be understood as default value in case of the adjustable parameter. In the editor for the export of unit operations that is later in this chapter presented (section 4.1.7), lower and upper bounds for the adjustable parameters can be set. Parameter value boundaries have specifcally been introduced in the course of this thesis to refect the properties of public parameters defned in the CO standard.

When a parameter shall be changed to a quantity that is iteratively calculated (in MOSAICmodeling called “iteration variable”), it has to be removed from all parameter lists of the particular model. This is independent of the parameter’s classifcation. The user has to be aware of this, as changing between iteration variable and parameter will lead to additional manual efort. That is the dif- ference to design variables that can be set constant in unit operations, while at the same it is easy to move them to the list of iteration variables. The fxed parameters, as used for function parameters, are conceptionally never used as

105 4 Concept and Implementation PrmtrCasfainin Classifcation Parameter 4.9: Figure iuainEditor Simulation loigt hoebtenFXDadADJUSTABLE and FIXED between choose to allowing

106 4.1 Filling the Identifed Gaps iteration variables4. In their case it is unproblematic to have them mentioned in parameter lists. With the subject area in this subsection especially the gaps regarding parameters and their classifcation (M2, M8, and CG1) have been flled.

4.1.5 Unit Operation Ports

Afected missing features: M6 (Ports), M7 (Flowsheeting), CG2 (CAPE-OPEN Interfaces)

In MOSAICmodeling the ports and streams have been introduced and implemented by S. Kuntsche. It is documented in his doctoral thesis (Kuntsche, 2013, pp.117-121,147-154). Here only the extensions and modifcations are described that were implemented for the documentation-based fowsheeting in MOSAIC- modeling and the automatic creation of CO unit operations.

Ports

In this thesis additional consistency checks have been implemented that have to be performed before a port can be added to an equation system. Fig. 4.10 shows the GUI to add a port including Interface and Connector. The confrmation button is not activated before the consistency check was performed. This way it is assured on the level of the Equation System Editor that Interface and Connector chosen for the port ft together. One aspect of this is that each entry in the Connector has to match a variable in the interface. After engineering units have been introduced to MOSAICmodeling, it is checked that they match, too. These checks nevertheless can only check the current state of the model. When an involved Connector or Interface is changed, it is the responsibility of the user to re-check the port consistency. Regarding the automatic creation of CO unit operations it was necessary to have stricter rules for port connections. Faulty port connections can in general not be corrected automatically, leading to an abort of the unit operation creation process. Vari- ables of output ports need to exist in the equation systems. Therefore they are automatically created in case they do not exist when an output port is connected to an equation system. Ports should in general not be added before the equa-

4In a parameter identifcation problem (optimization) the function parameters to be identifed are not fxed parameters in the sense described here.

107 4 Concept and Implementation Adn ott neuto ytmi the in system equation an to port a Adding 4.10: Figure qainSse Editor System Equation fe hcigteconfguration the checking after

108 4.1 Filling the Identifed Gaps tion system is complete, therefore avoiding changes in Connector and connected variables of the equation system. In case bigger changes in the equation system have to be applied, especially regarding the variables that are used across system boundaries, the user has to check if the port’s Connector still fts to the equation system. When in doubt, a new equation system with new ports should be created.

Streams and Flowsheeting

For streams the connection rules have been set stricter, too, and consistency checks are mandatory. Not before the interfaces of ports and stream match, it is possible to create the stream and connect two unit operations in MOSAIC- modeling. Again there has to be a one-to-one connection of all involved variables in the connectors and the interface, including a match of the engineering units. The connection of several unit operations inside MOSAICmodeling can be called “documentation-based fowsheeting”. At frst this works without visualization applying the concepts of interfaces, connectors, ports, and streams. As an extension of the previous implementation, for this thesis the users are allowed to give the streams explicit, user-defned names, besides the automatically generated “stream ID”. Nevertheless, human beings in general can process and understand the connections of a fowsheet faster, when presented graphically. In the course of this thesis a visualization was integrated in the ofcial version of MOSAICmodeling. This feature is available in the Equation System Editor and the Simulation Editor. An example is given in the screenshot in Fig. 4.11 on page 110. It can be immediately seen that the unit in the center has one input and two outputs. The ports are indicated by the small circles at the left and right boundaries of the rectangle representing the unit operation. On the left hand side the process input is highlighted by a big arrow labeled IN, connected to the feed port of the unit operation. The two output ports of the unit (“Distillate” and “Bottom”) are connected to the process outputs, highlighted with big arrows labeled OUT. The displayed fowsheets are pure visualizations. Editing the connections within this window is not possible. Only the positions in this view can be moved, for example in order to make screenshots for additional documentation purposes that show the connection better than purely textual descriptions can do. Supporting dynamic graphical editing of the connections would be a major extension related with a considerable amount of work.

109 4 Concept and Implementation

Figure 4.11: Visualization of a fowsheet with a single Unit Operation in MOSAICmodeling

With the subject area in this subsection especially the gaps regarding ports (M6), Flowsheeting (M7), and CO interfaces (CG2) have been flled.

4.1.6 User-Defned LangSpecs (UDLS)

Afected missing features: CG1 (Public Parameters), CG2 (CAPE-OPEN Inter- faces), CG3 (Meta Information)

In section 3.1.3 it was described that S. Kuntsche introduced two diferent options to create program code. One the one hand there are the predefned Language Specifcators (preLS) defned by the developers of MOSAICmodeling. On the other hand there are the user-defned Language Specifcators (UDLS) that can be defned by the users themselves. Regarding the creation of CO unit operations, it is one goal of this thesis to extend, and improve the capabilities of the UDLS in order to be independent of the preLS. The following three subsections describe the extensions introduced to the UDLS to implement the missing features CG1 to CG3 as defned in section 3.2.2.

Public Parameters

The group of parameters has been split into fxed/private parameters and adjustable/public parameters. In order to directly access these groups of parame-

110 4.1 Filling the Identifed Gaps ters in the UDLS, new loop blocks for code generation have been introduced to the Language Specifcation Editor. Now it is possible to access all parameters including design variables (as before), or only the fxed variables (design variables and fxed parameters), or only the adjustable/public parameters. In contrast to the design variables and fxed parameters, the adjustable/public parameters have explicit lower and upper bounds. This is refected in the UDLS with respective felds called “_LOWER_BOUND_”, and “_UPPER_BOUND_”, that are available in the loop block of the adjustable/public parameters. In the user interface this loop block is called ExternalParameters in contrast to Constant- Parameters for the fxed parameters. When these felds are used correctly, later on the user is only allowed to specify parameter values that lie in between the bounds specifed in MOSAICmodeling.

Code Generation for CAPE-OPEN Interfaces

Regarding code generation for the implementation of CO interface two main aspects exist: on the one hand ports and on the other hand calls to external property calculation routines. For the ports new loop blocks have been introduced to the UDLS. With the block for the InputPorts all information regarding the inputs can be accessed. This comprises ID, name of the block, and feed variables. The block for the system outputs is called OutputPorts and provides access to the output information in analogy. The variables contain the information which quantity of a stream they represent. For the prototypical implementation in this thesis only the most important type – material streams – is supported. The other two stream types defned in the CO interfaces, the so-called energy streams and general information streams could be added in future work. This will become relevant when control loops are modeled, as they require information streams to represent control signals (signals are in this sense neither material nor energy). Regarding ports in the UDLS it is important to access the information that is already present in the model’s equation system.

In contrast to the ports, calls of external property package functions need additional information in the UDLS that is not already part of the equation system. As described in section 4.1.3, functions in MOSAICmodeling are defned in the Function Editor. In case of CO function calls the function inputs and function outputs are preset by a MOSAICmodeling Interface. This way the function body stays undefned until code generation. The defnition of the function body now

111 4 Concept and Implementation iue4.12: Figure UDLS xenlfntostbdfiga xenleulbimpoet call property equilibrium external an defning tab functions external

112 4.1 Filling the Identifed Gaps takes place in the External Functions tab of the UDLS editor (see Fig. 4.12 on page 112). In order to complement the missing information the Interface defning the function must be loaded. In the upper right area the felds defned by the Interface are displayed. Function calls have by defnition exactly one output, marked by “Direction: Out”. The number of function inputs (“Direction: In”) is not bounded, but has to be fxed for one interface. The additionally known information from the Interface are the mathematical dimension (scalar versus vector), the symbol of the variable (as a LATEX string), and the name of the variable. For the implementation of the function defnition (lower left part of the editor tab) and the function calls (lower right part of the editor tab) each variable of the interface needs a so-called handle. This handle has to be defned by the user and entered in the table. The handles act as placeholders for the variables in the GUI. Now the specifc code necessary to implement the function in the targeted programming language can be written down. This has to be done once by the user. Regarding the function calls up to three code functionalities have to be specifed:

1. The Vector Input Creation code is optional and is only needed if the function has vector-valued inputs. The code entered here is used to group scalar variables in vectors that can be handed over to the function as inputs.

2. The Call Code is obligatory and is used to actually call the function in the generated code. Here the user has to use, depending on the function output, either the handle for the scalar or for the vector valued function output. The information which one to use can be easily read from the interface variable defnition table in the upper right area of this editor tab. Implementation detail: When having vector-valued function outputs some programming languages require the output variable to be defned beforehand.

3. The Vector output Assignment Code is optional and only used with vector- valued functions. The code to be entered here will be used to split the resulting result vector into the scalar variables used in the rest of the code.

Other UDLS can be used to have an orientation how to implement functions. They can even be used to directly import previously saved function implementation specifcations. This is what the button next to the search button is good for, see Fig. 4.12 on page 112. By adding a description to the UDLS, other users can

113 4 Concept and Implementation make better decisions if a particular language specifcator will fulfll their needs. When for example the implemented function interfaces are listed, it is relatively easy to decide if the language specifcator contains the features that one wants to import into another UDLS. The advantage of this approach is the high level of customizability and possibility of fast adaptability of function implementations.

Meta-Information

Using preLS it is possible to use code generation properties that customize the generated code. These properties were implemented by a developer. For this thesis code generation properties have also been implemented to be used with UDLS. Fig. 4.13 on page 115 shows a screenshot of the new user interface that enables users of MOSAICmodeling to create and provide code generation properties for UDLS. On the left hand side new properties are entered. A property needs four pieces of information:

• The Type classifes the values this property can take. Possible types are String, Integer, Float, Boolean, and GUID.

• The Name identifes this property later on in the user interface for code generation.

• The Handle can be used inside the code elements of the UDLS Editor as a placeholder for the value of this property.

• The Default value is the value that is used if the user does not specify another value.

On the right hand side the options for the values can be specifed. If values are given in this table, the user will only be allowed to chose one of these values for code generation. In the lower left area a name can be specifed that is used when the generated code is exported as a fle. At this point it is allowed to use one of the properties’ handles specifed above. In the example (Fig. 4.13) a property called Model name is defned and the respective handle is used for the fle export name. So in case the user of this UDLS does not change this property before code generation and fle export, the name of the exported fle will be “MOSAIC_model”. The second property of the example is of type String, too. In contrast to the pre-

114 4.1 Filling the Identifed Gaps code generation properties with an example for enumerated string values UDLS Figure 4.13:

115 4 Concept and Implementation vious property the possible values are restricted. For the Sundials solver strategy 5 the specifc options are “KIN_NONE”, “KIN_LINESEARCH”, and “KIN_FP”, that have been listed in the options table (Sundials reference: Hindmarsh et al., 2005). For the automatic generation of CO unit operations additional code generation properties are necessary, naming author, copyright info, and especially GUID.A GUID is composed of 32 hexadecimal digits and is a unique identifer for the created unit operation and its underlying model. More on this is explained in the following section covering the Unit Operation Export Editor.

4.1.7 Unit Operation Export-Editor

Afected missing features: CG1 (Public Parameters), CG2 (CAPE-OPEN Inter- faces), CG3 (Meta Information), CG4 (Generation and Compilation)

The Unit Operation Export Editor was specifcally created for this thesis. The GUI is similar to the structure of the other editor in MOSAICmodeling. Based on a MOSAICmodeling Simulation step by step all the information necessary to automatically create a CO unit operation is entered. Especially the following gaps of the workfow for code generation are flled:

CG1 Description and boundaries of public parameters can be set.

CG2 Multiple code fles can be generated at once by collecting the necessary LS in the Unit Export Editor.

CG3 New random GUIDs can be generated. Solver options and other code generation options like model name and copyright information are displayed and can be modifed.

CG4 LS diferentiating between 32bit and 64bit unit operations can be selected. An asynchronous procedure for the creation of a unit operation on the server is implemented.

The data entered by the user can be saved in MOSAICmodeling’s database as well, composed in the new model element “Unit Operation”. The internally used fle extension for this element is “mosuop” (MOSaic Unit OPeration). The XML schema fle defning the structure of these XML fles is listed in appendix C.

5The continuously updated user guide with the list of KINSOL solver strategies is available online: https://computation.llnl.gov/sites/default/fles/public/kin_guide.pdf date of last access: 2019-03-16

116 4.1 Filling the Identifed Gaps

According to the schema, a “.mosuop” XML fle contains the following data:

• description - the description entered in the GUI

• evaluation - the location ID of the Evaluation representing the mathematical model of the unit operation

• variable_specifcation - the location ID of the Variable Specifcation List determining the initial values of the iteration variables as well as the fxed values of the design variables and fxed parameters

• parameters - the public parameter variables including description and bounds

• ports - the open ports including description and type

• lang_specs - the location IDs of the multiple UDLS referenced for code creation

• codegen_properties - the code generation properties including the selected options (name and value)

A short manual for the new editor follows now. The longer version of the manual including more screenshots is located in appendix B. Details regarding the implementation and compilation of unit operations follow in section 4.2.

Short Manual

The editor for the export of unit operations is split into three areas (see Fig. 4.14 on page 118): Unit Model, Unit Properties, as well as Options & Creation.

Unit Model In the frst area a simulation represented by a MOSAICmodeling Evaluation is loaded. All the equations, functions, and indexing information is displayed, but not modifable here. For editing exclusively the respective editors for modelling and simulation have to be used.

Unit Properties In the second area all internal model quantities as well as public/adjustable parameters and available ports are displayed. For the variables to be calculated by the solver (iteration variables) the initial values can be set. The values for the design variables and the fxed parameters are set, too. For the adjustable parameters additionally lower and upper bounds and a description can be entered. These parameters will be available to the user of the unit operation

117 4 Concept and Implementation iue4.14: Figure ntEpr Editor Export Unit Evaluation ). GUI hwn h oe si saotdfo h oddsmlto (MOSAICmodeling simulation loaded the from adopted is it as model the showing

118 4.1 Filling the Identifed Gaps and their values can be varied from simulation run to simulation run. Regarding the unit operation’s external ports all information known from the simulation is shown (ID, name, direction). The port’s type is at the moment restricted to “Material” (i.e. total fow, pressure, temperature, composition). Additionally a port description can be entered.

Options & Creation In the third area (see Fig. 4.15 on page 120) the language specifcators are chosen that will create the unit operation’s code fles. Therefore the model library of MOSAICmodeling contains a folder named “CAPE OPEN Wizard”, containing the language specifcators capable of generating all the necessary source fles and header fles for a C++ unit operation (according to the CO interface defnitions). A language specifcator for a fle of type “Windows Installer XML (WXS)” is prepared, too. It has to be selected if an installer for the unit operation shall be created. After choosing the language specifcators all the code generation options and properties are displayed on the right hand side. Especially the GUIDs uniquely identifying the unit operation are important. With the in-built GUID generator the IDs can be change via graphical user interface. The button for (local) code generation is enabled as soon as a target directory to store the fles on a local drive is selected. Two additional options can be selected for the local code generation. The frst advises MOSAICmodeling to store the local fles in a dedicated folder called “Source”, the second option will create an additional (empty) folder called “Build”. The most important feature of this editor is the automatic creation of a unit operation on a dedicated server, delivering an installer of the CO unit operation without the need to provide any software locally. After pressing the respective button the view automatically changes to the next tab called Server, where all the unit operations available to the current user6 and their status are listed. With the refresh button the display is updated. As soon as the creation on the server has fnished, the status will change to the value “1” and the Uniform Resource Locator (URL) to directly access the unit operation online is given. This URL can be copied and sent to colleagues or collaboration partners that can donwload the unit operation via web browser. Selecting a successfully created unit operation in the table and pressing the button saying “Save File”, leads to a direct download without the need to start a browser.

6Only unit operations the user already has created code for are listed.

119 4 Concept and Implementation iue4.15: Figure ntEpr Editor Export Unit GUI hwn h oegnrto panel. generation code the showing

120 4.2 Code Implementation and Distribution of Unit Operations

4.2 Code Implementation and Distribution of Unit Operations

Afected missing features: CG2 (CAPE-OPEN Interfaces), CG3 (Meta Informa- tion), CG4 (Generation and Compilation), CG5 (Installer), E1 (Installation), E2 (Load), E3 (Streams and Parameters), E4 (Run), E5 (Results)

With MOSAICmodeling as a modelling and code generation tool it is possible to collect the information necessary for a CO unit operation and create corresponding code. For correct code not only the rules of the chosen programming language have to be followed, but also the rules determined by the interface def- initions of the CO standard. It would not be sufcient if this worked only for a selected, manually implemented example. It has to work in way that basically any model of a unit operation entered in MOSAICmodeling can be translated automatically. In the next step the code has to be compiled to get an executable fle. This last step is not performed by MOSAICmodeling itself, but either by the user itself or automatically on a dedicated server connected to the MOSAIC- modeling database. An overview of the implementation procedure when choosing the automatic way is given in Fig. 4.16 on page 122. The following subsections describe the technologies and aiding software used to implement and compile the unit operations, and how the unit operation is provided to the user. This includes more detailed descriptions of what is shown in Fig. 4.16.

4.2.1 Applied Technologies

C++ and AmsterCHEM’s COM CAPE-OPEN Wizard

The implementation of the CO standard was performed in this thesis using the programming language C++. This language is popular and a lot of related resources can be found online. Additionally it is directly possible to create Dynamic Link Library (DLL) fles that use COM middleware. At the time of this thesis COM is the de facto standard for middleware when implementing CO. The alternative CORBA has basically vanished in this context (some general reasons are named by Henning (2006)). Another vital reason for choosing C++ is the COM CAPE-OPEN Wizard 7 developed by AmsterCHEM8. With this wizard the

7This software can only be accessed after contacting AmsterCHEM. 8https://www.amsterchem.com date of last access: 2019-03-16

121 4 Concept and Implementation

Legend MOSAICmodeling MOSUOP Control flow model options Data flow - equations - solver strategy Control - ports - GUID interaction - parameters - name - ... - ... File transmission UDLS

Local Computer WXS .cpp / .h

Python MOSAIC Database DB Table Scripts

Windows Server

Server File System .cpp / .h CMake - logos - license text - ... Visual Studio CO TypeLib MSM DLL

WXS Candle

Light

MSI

- logos (config) - license (config) - dll - CO type library - ...

Figure 4.16: This overview of the implementation procedure shows the control and data fows to create an installer fle starting with a mosuop fle. The diferent parts in section 4.2 refer to this Fig. and contain detailed explanations of what actions take place.

122 4.2 Code Implementation and Distribution of Unit Operations basic header and source fles building a CO unit operation were created once. Files that are independent of a specifc model (e.g. the CO base class) could directly be used. This comprises also the areas data types, error handling, and COM interface. A second group of fles could directly be used, but needed some enhancements. This includes the classes taking care of the connection to the CO physical properties (Material.h etc.), where additional functions related to physical properties were introduced. The third group of fles only contained code stubs that had to be implemented according to the particular model. These are mainly the two fles describing the unit operation’s equation system: the header fle and the source that directly implement the interface defned for CO unit operations.

The challenge was to fnd a universal approach to fll these stubs with code adjusted to every unit operation model with all the diferent equations, param- eteres, and ports. It was important to take care of correct processing of the variables of the input ports and their matching to the inner variables of the equation system. Additionally a solver had to be included that has to fnd a solution of the model that can be written to the correct variables of the output ports. The public parameters and the ports are defned in the header fle’s constructor. At this point the engineering dimensions of the public parameters must be set, which can vary from model to model. The result of using am- sterCHEM’s wizard and the implementation of the actual model is refected in the UDLS model elements that can be loaded in the Unit Export Editor. The UDLS fles are transparent and therefore the implementation is open for review and improvement.

Windows-Server, Visual Studio, KINSOL, CMake and Python

MOSAICmodeling is executed on the user’s client computer (Local Computer in Fig. 4.16 on page 122). In order to compile a unit operation according to the CO standard appropriate software must be present. For this thesis a dedicated Windows server was set up (Windows Server in Fig. 4.16), freeing the user of installing the software on its own machine. The software used for compilation on the server is Microsoft Visual Studio (MSVS), see Visual Studio and related Control interaction in Fig. 4.16. MSVS can be started via script without the need to open any GUI. This is an important aspect, otherwise manual action of a user would be necessary and it would not be possible to automatize these

123 4 Concept and Implementation steps. In MSVS the locations of the fles have to be given. Besides the actual code fles create by the language specifcators the libraries and header fle of the solver as well as the CO type library have to be included.

For this thesis the solver KINSOL of the SUNDIALS suite (Hindmarsh et al., 2005) has been chosen. SUDIALS stands for SUite of Nonlinear and DIf- ferential/ALgebraic equation Solvers and includes with KINSOL9 a solver for nonlinear algebraic equation systems. The necessary solver fles are stored on the server, ready to be included into the MSVS project. The CO type libraries are available at the CO-LaN10 and are also stored on the dedicated Windows Server (CO TypeLib box inside the Server File System on the left in Fig. 4.16 on page 122). For each unit operation a MSVS project is created, confgured by specifying the pathes to the fles to be included. In order to create these projects the software CMake11 is used. CMake can be started via script as well and is controlled with a confguration fle that is available as a UDLS in MOSAIC- modeling. When the code for a unit operation is generated, the model’s name goes into the CMake confguration fle, eventually enabling the MSVS project to create a DLL fle with this appropriate name.

On the server, scripts using the programming language Python (Rossum, 1995) are continuously running to control the creation process. Within these scripts successively CMake and MSVS are called to create the DLL of the CO unit operation (boxes on the right of Fig. 4.16). This was an overview of the applied software. Details regarding the scripts and procedures on the server follow in section 4.2.2.

Installer File

CO unit operations are included as registered DLL fles into fowsheet simulation software. The distribution of a DLL is simplifed when shipped inside an installer fle. The user has the advantage that additional fles can be included in the installer, e.g. user manuals. The installer automatically takes care of writing the correct entries in the Windows registry.

9https://computation.llnl.gov/projects/sundials/kinsol date of last access: 2019-03-16 10http://www.colan.org/software-tools/cape-open-type-libraries-and-primary-interop- assemblies/ date of last access: 2019-03-16 11https://cmake.org date of last access: 2019-03-16

124 4.2 Code Implementation and Distribution of Unit Operations

In order to create an installer the programs candle and light exist. They have originally been developed by Microsoft and are now freely available. Based on appropriate WXS fles they collect the required date and create a Microsoft Installer (MSI) fle (see boxes WXS, Candle, Light, and MSI in Fig. 4.16). The MSI fle is an executable fle that is eventually the only fle used to install a unit operation and include it in CO-compliant PMEs. As CO-LaN provides the CO type libraries as Windows Installer Merge Module (MSM) fles that can directly be included in MSI fles, it is straight forward to install them together with the unit operation. The installation of the type libraries is only mandatory if no CO component has been installed beforehand. Only a few lines of code in the WXS fle were necessary to include the type libraries. The typical GUI that is shown when an installer is executed on windows operating systems is automatically generated with a simple command in the WXS fle. This way the unit operation installer seamlessly integrates into the windows environment.

4.2.2 Creation on Server

The work of the process engineer is simplifed by creating the CO unit operation on the server and providing an installer confguring the unit in the windows registry. It is not necessary anymore to get used to programs like MSVS Studio or CMake or to know the details of the implementation of the CO standard in C++. Fig. 4.17 on page 126 shows the GUI in MOSAICmodeling that is used to access the unit operations in the Unit Export Editor that have been created on the server. The communication between MOSAICmodeling and the server taking care of the creation process is described in the following.

Database Exchange Table

For the unit operation export a new table has been added to the MOSAICmod- eling database. In Fig. 4.16 on page 122 this is represented by the database symbol DB Table in the MOSAIC Database area in the center. This table is named unitOperationExchange and has seven columns:

• userId*, the id of the user in MOSAICmodeling

• guid*, the GUID of the unit operation to be created

• bit*, a number indicating if the unit operation is compiled in 32 or 64 bit

125 4 Concept and Implementation iue4.17: Figure ntEpr Editor Export Unit rae ntoperations. unit created GUI hwn h evrpnlicuigti srsifraino l automatically all of information user’s this including panel server the showing

126 4.2 Code Implementation and Distribution of Unit Operations

• status, a number indicating the status of this row

• message, a string giving more information according to the current status

• content, a Binary Large Object (BLOB) containing the (compressed) unit operation’s source code fles generated by MOSAICmodeling

• ts, a timestamp indicating the time of creation or last change of this row

The columns marked with a star are altogether a unique key, so the combination of User-ID, GUID, and bit is always unique in this table. The feld status gets a positive number ("5") when a new row is created. With each following process step this status number is reduced. As soon as a value of 1 is reached, the creation of the unit operation is fnisched. In case an error occurs in a process step, the status is multiplied with -1. This way it is easy to see if the error occured more at the beginning or more at a later process step.

The feld message contains - in case of a success - the direct link to the unit operation installer on the server. When an error occured and the status feld is negative, the message feld will give an explanatory description what frst went wrong in which process step. During processing, before fnishing the creation and when no error occured, the message feld contains the name of the unit operation that is being created.

The column content contains the compressed code fles that have been generated by MOSAICmodeling. These source fles are downloaded to the windows server by the continuously running scripts, decompressed, and processed to a unit operation. The compiled unit operation is not stored in the database table, but on the dedicated server responsible for creation and distribution. The term “exchange” in the database table’s name basically refers to the transmission of the code fles in direction from the database to the server and the transmission of status messages in the opposite direction.

Internal Workfow

By pressing either the button “Create 32-bit Unit” or the button “Create 64-bit Unit” in the code generation tab of the Unit Export Editor all associated language specifcators are called to generate the source code fles. These are stored in a zip-compressed folder that is written to the MOSAICmodeling database table

127 4 Concept and Implementation

MOSAIC Database DB Table .zip Read Script

Windows Server Make Script Server File System

msifiles Unit Operation - logos - license text .cpp / .h CMake - KINSOL libs - CO TypLib MSM - ... Visual Studio DLL MSBuild

WXS Candle

Light Public User MSI - logos (config) Legend - license (config) Control flow - dll - CO type library Data flow - ... Control interaction

Figure 4.18: This focus of the implementation procedure shows the control and data fows on the server to create an installer fle fnally available in a user-specifc public folder.

128 4.2 Code Implementation and Distribution of Unit Operations

UnitOperationExchange, more specifcally into the column “content” as a BLOB. The status of this row is set to “5”. The following procedures are visualized in Fig. 4.18 on page 128, focussing the previous overview on the action happening on the MS Windows server. On the MS Windows server “cape.open.dbta.tu- berlin.de” two python scripts are running continuously. The frst script regularly checks if new entries with status “5” have been added to the database table. If yes, the status is set to “4”, signalling that a new entry has been discovered. Subsequently the python class UnitOperationSourceReader is called. This class loads the BLOB object out of the database, decompresses the fles, and ex- tracts them to a dedicated position in the fle system. On the server also the libraries of KINSOL (i.e. the solver for nonlinear equation systems) are already stored, so they can directly be referenced in the MSVS project. The python fles that control the whole workfow on the server are stored in the location “C:\Users\Public\Documents”.

Under “C:\Users\Public\Documents\unitcreation\msifles” all fles are located that are later on used processing the WXS fle to create a complete MSI fle. This includes license text, banner logo, and CO type library. The user specifc fles are located below the folder “user” in a directory having a name that is equal to the user’s MOSAICmodeling ID. This is for example “C:\Users\Public\Documents\ user\158” for the user with id 158. For each unit operation, respectively “application GUID”, another subfolder is created that will contain the fles extracted from the UnitOperationExchange database table. When the source-reader class has fnished these steps, the database status is set to a value of “3”, indicating that the fles now have been received and sorted to their correct locations on the server. At this point the second continuously running script springs into action that waits for rows with status “3”. This script sets the status to “2” and calls the python class UnitOperationMaker. This class copies the fles of the msifles- folder into the folder of this unit operation and creates a build folder. It calls subsequently CMake, the MSVS compiler (msbuild.exe), as well as compiler (candle.exe) and linker (light.exe) for the MSI fle.

CMake is called to create a MSVS project based on all source and header fles. With Microsoft Visual Studio these fles are compiled and linked. When MSVS was successful, it created a DLL fle that corresponds to the executable

129 4 Concept and Implementation unit operation. To make the work with that unit operation more convenient, a windows installer fle is created in the next step. Therefore the programs candle and light are subsequently executed. They process a WXS that has automatically been adjusted to the particular unit operation by calling the respective UDLS for code generation. The WXS fle includes the command to incorporate the CO type library into the installer. This way this CO unit operation is usable independent of any other CO tools, as it delivers all the necessary fles itself to be recognized as a CO component. A license fle can be included in the installer fle as well. For the prototype created in the course of this thesis an academic open source license has been included. This can be changed by replacing the respective text in the license fle that is stored on the MS Windows server.

When the MSI fle was created successfully, it is copied to the public folder on the Windows server (e.g. to “C:\inetpub\wwwroot\mosaic\user\\ \.msi”). This directory is explicitly enabled for external read access. The msi fle is uniquely located on the server (the path contains user id and GUID, so the path cannot be guessed if the GUID is unknown) and can for example be downloaded via browser. The respective url12 is written to the database, altogether with the new status “1”. In the user interface of MO- SAICmodeling the corresponding link is displayed. This link can be copied and distributed to colleagues or collaboration partners in order to provide the functionality of this CO unit operation.

The MOSAICmodeling user interface can be used to download and locally save the fle directly without starting a browser. This msi fle takes care of installation, repairing, and deinstallation of the unit operation. An advantage is that the CO type libraries are only removed from the computer when no other software uses them.13 During installation additional optional fles like the already mentioned user manual can be delivered. Choosing the “repair” mode of the installer allows to install the optional parts later. In the prototyp implemented for this thesis only a PDF containing a MOSAICmodeling user manual is listed as optional feature. The main reason to do so, was to show that this is easily done and can be extended to other fles, too.

12http://capeopen.dbta.tu-berlin.de/mosaic/user///.msi 13This does principally only work as long as all programs and components reference the same type library, otherwise the reference counting will fail.

130 4.3 Additional New Features Despite of Core Unit Operations

4.3 Additional New Features Despite of Core Unit Operations

Besides the gaps identifed in the analysis in chapter 3, additional potential for improvements existed. The enhancements to MOSAICmodeling that are not immediately related to the implementation of the CO unit operations, but that have nevertheless been added in the course of this thesis, are grouped into the two areas flling smaller gaps and improving usability and convenience.

4.3.1 Filling Smaller Gaps

VarSpecViewer The so-called VarSpecViewer is a new editor in MOSAICmod- eling that has been introduced to enable the review and editing of Variable Spec- ifcation Lists. This way values, boundaries, and classifcation can be checked and modifed independent of simulation and optimization. In this context the import of values for variables and parameters has been signifcantly improved. Due to this improvement the values can be imported not only based on a formatted list, but also based on another variable specifcation list. A test import has been implemented that can be used to check which variables will be afected by the import and which values will not be imported (because of a missing match). During import it is even possible map the used namespaces to be even more fexible. When desired the variables do not only import value, lower bound, and upper bound, but also the variable classifcation (iteration vs. design variable). Also new and integrated into the VarSpecViewer is the export of variable specifcation lists (see Fig. 4.19 on page 132). With this export it is possible to create an output that can e.g. directly be processed in MS Excel.

This helps flling the gaps M8 (Classifcation and Values) and E5 (Results).

Optional Features and Refactored Tests As already mentioned the users of MOSAICmodeling can activate and deactivate the Engineering Unit feature themselves. This has been implemented for other features as well, including the already existing feature for the initial evaluation of a simulation inside MO- SAICmodeling (before code generation). This feature includes the evaluation of all explicit functions (“Calculate Functions”) on the one hand and the evaluation of all equations (“Test Iteration”) at the initial point on the other hand. The evaluation has been refactored and the results of the equation evaluation are

131 4 Concept and Implementation Sreso fthe of Screenshot 4.19: Figure VarSpecViewer hwn h e aibeseicto xotfuntionality. export specifcation variable new the showing

132 4.3 Additional New Features Despite of Core Unit Operations sorted now. The results are opened in an extra window and the sorting criterion is the absolute deviation from zero. On top of the list are the equations with the biggest “error” or “residual” when entering the initial guesses and design values. This is an indication in which equations better initial guesses should be provided to reduce the error at the inital point.

This helps flling the gaps M4 (Units) and M8 (Classifcation and Values).

Descriptions In the course of this thesis all model element classes got a feld for a description. This does not only hold for the newly introduced elements (Engineering Unit, Engineering Unit Set, and Unit Export), but also especially for Variable Specifcation Lists and Notations.

This helps flling the gap M1 (Notation).

4.3.2 Improving Usability and Convenience

• The XML model elements are now stored in a zip-compressed way. This leads to a reduction of the fle size to up to 90 percent for Variable Spec- ifcation Lists. This will help reduce the trafc to databases, especially signifcant for the ones that are located far away.

• The connection data to the diferent servers have been outsourced into an extra module. This module can be exchanged independent of the rest of the code when additional databases and servers are to be used.

• The database tables related to the analysis feature have been restructured. Due to the new structure models can now be analyzed that previously were too large. This has been achieved by simply spliting up the existing table into several smaller tables. The limiting restriction was caused by the maximum length of one table row. The new, added tables are – analyserCode (idUser*, idEvaluation*, status, code, ts), – analyserIncidence (idUser*, idEvaluation*, row, col, val, ts), – analyserBlock (idUser*, idEvaluation*, rowP, colQ, info, rowPointer, colPointer, ts) and – analyserBorderedAndPCA (idUser*, idEvaluation*, bbtRowP, bbtColQ, PCA, ts).

133 4 Concept and Implementation

The analysis feature is relevant for future work related to automatic code generation (see section 6.3). Another new aspect is the analysis of systems containing functions with undefned bodies, that is now enabled, too. This has been achieved by “scalarization” of the vector-valued function inputs and outputs, that now can be matched with the scalar variables present in equation systems generated with MOSAICmodeling. This way it is nevertheless only possible to identify the incidence matrix, the Jacobian cannot be calculated when the function bodies are undefned and there is no traceable relation between inputs and outputs. The structure of old and new database tables can be found in appendix D.

• The Optimization (mosopt) was introduced as a new element ftting to the Optimization Editor. In this element the Variable Specifcation List can be defned separately from the list stored in the underlying simulation. Due to the new storable and loadable model element it is not necessary anymore to reselect the decision variables and objective functions every single time. The Optimization now includes a description - as all other elements do, too.

• The description of the LS selected in the simulation is now displayed in the GUI. Previously there was no information but the language specifcator’s name. Now it is possible to list and explain all the code generation properties in kind of a mini-manual that is shown besides the code generation options table.

• A title bar including login information (time, date, name) has been added to MOSAICmodeling. This helps when models are discussed together with colleagues at one computer, because the diferent users may have access to diferent fles. This way it is easily recognized if change of the user has to be done in order to see specifc model elements. As the title bar is also shown in full screen mode the user can immediately check if there is still time before the next appointment.

• The fle management has been improved. This manifests itself in a faster access to the fles and folders tree, and is among others achieved by hiding empty structures that do not contain any fles. Additionally it is now possible to choose the way fles are sorted inside a folder. The two options are “sort-by-name” and “sort-by-id”. The whole system of giving read and

134 4.3 Additional New Features Despite of Core Unit Operations

write access to fles and folders has been revised and clearly specifed to always provide a predictable behaviour.

• The concept of the creation of new users and the editing of existing accounts and groups was improved. The implementation was performed by a student assistant. An automatization of the creation process of new accounts for MOSAICmodeling was not part of this improved concept, whereby manual tasks were still to be performed.

• In the course of this thesis for all classes of model elements in MOSAICmod- eling appropriate XML schemas according to the venetian blind scheme have been created. These schema fles are listed in appendix C. Based on these schemas it is at least theoretically possible to identify invalid elements before they are actually loaded and iterpreted. Schema fles are more powerful in this regards than the in former times used Document Type Defnition (DTD) fles. In pratice it is hard to apply, as in the past the defnitions of the model elements changed. So old elements that were valid when they were created, may now be invalid according to an updated schema fle. A script was written to test all elements of the model database. Due to the fact that an automatic correction is not feasible, it was not tried to fx all invalid elements that were identifed in this script in the course of this thesis. The majority of invalid elements only had minor problems that for example occur when a description feld is made mandatory that was optional or non-existing beforehand. None of the existing elements will in such a case be compliant to the schema, even it is no problem for the software to interprete a non-existing description as an empty description. With the schema fles it is possible to give other software products the chance to read and write the MOSAICmodeling model elements. This way it is possible to separate the data (i.e. model) from the software (i.e. MOSAIC- modeling), allowing to use the most appropriate software to work with the data in cases where MOSAICmodeling might not deliver the best features available on the market.

135

5 Application and Case Studies

In this chapter the proposed top level workfow for development and execution of a CO Unit Operation (Fig. 3.9 on page 64) is applied on three diferent units. Additionally an example for documentation-and-equation-based fowsheeting inside MOSAICmodeling is shown at the end of this chapter in section 5.4. The full documentation of these examples is listed in appendix F.

5.1 Reusing a Compatible Unit Operation

5.1.1 Membrane Separation

In the frst example demonstrating the application of the target workfow and the automatic implementation of a CO Unit Operation a model from the literature is chosen. The model of a simplistic membrane was presented in a paper dealing with rapid-prototyping of Unit Operations (van Baten, 2009). As demonstrated in a conference paper (Tolksdorf, Esche, van Baten, et al., 2016) this model has already been entered into the MOSAICmodeling database. In step A of the workfow we can select this existing model from the MOSAICmodeling library. It is independent of the involved compound’s physical properties and consists of ten equations:

1. component mass balance for component 1

F F R R P P F · xi=1 = F · xi=1 + F · xi=1 (5.1)

2. component mass balance for component 2

F F R R P P F · xi=2 = F · xi=2 + F · xi=2 (5.2)

3. fow cut equation F P = θ · F R (5.3)

137 5 Application and Case Studies

4. separation factor equation

P R xi=1 xi=2 α = P · R (5.4) xi=2 xi=1

5. summation condition for the permeate

P P (xi=1 + xi=2) = 1 (5.5)

6. summation condition for the retentate

R R (xi=1 + xi=2) = 1 (5.6)

7. isothermality criterion for the permeate

T P = T F (5.7)

8. isothermality criterion for the retentate

T R = T F (5.8)

9. isobaric criterion for the permeate

pP = p (5.9)

10. isobaric criterion for the retentate

pR = p (5.10)

In MOSAICmodeling three ports had been added mapping fow, pressure, temperature, and composition variables to the respective feed, permeate and retentate material streams. Table 5.1 lists all these variables. The quantities θ and α are defned as public parameters and all variables have engineering units assigned. Considering step B in the workfow, the model already is CO compatible. Therefore the next step to perform is the creation of a CO-compliant Unit Operation (activity E). Following the manual given in appendix B on page 189 the prepared MOSAICmodeling evaluation containing

138 5.1 Reusing a Compatible Unit Operation

Table 5.1: Ports of the membrane model Interface Name Feed Permeate Retentate F F F F P F R p pF pP pR T T F T P T R F P R xi xi xi xi the model and appropriate intial values has been loaded in the Unit Export Ed- itor. Description, lower bound, and upper bound of the public parameters have been added in the respective editor panel, as shown in Fig. 5.1 on page 140. According to the user manual allLS necessary to create a 64 bit unit operation have been loaded into the editor (Fig. 5.2 on page 141) and new GUIDs have been created and set. After pressing the Create 64-bit Unit button the installer for this membrane unit operation was automatically created. Changing from a 64 bit to a 32 bit unit operation involves selecting the LS dedicated to 32-bit instead of the 64-bit one and assigning three new GUIDs. This takes - including automatic generation on the server - approximately two minutes. Each down- loadable CO Unit Operation is bundled in an installer taking care of installation and deinstallation of the particular unit operation. The 64-bit unit operation was inserted and executed in a CAPE-OPEN Flowsheet Environment (COFE) fowsheet, whereas ASPEN PLUS in the version available for this work can only handle 32-bit units. As these two unit operations consist of identical equation systems and MOSAICmodeling always includes the same solver (KINSOL out of the sundials suite), it is not surprising that the calculated results are identical and independent of the PME (COFE versus ASPEN PLUS), when using the same feed conditions and parameter values. This membrane separation example does not involve thermodynamic calculations or physical property calls and has been selected to apply the target workfow and show the basic functionality of the Unit Export Editor.

139 5 Application and Case Studies iue5.1: Figure ntEpr Editor Export Unit GUI hwn h dutbeprmtr ftemmrn eaainexample. separation membrane the of parameters adjustable the showing

140 5.1 Reusing a Compatible Unit Operation and the selected code generation options of the membrane LS showing the used GUI separation example. Unit Export Editor Figure 5.2:

141 5 Application and Case Studies

5.2 Creating a New Unit Operation

5.2.1 MixerSplitter

In the second example of demonstrating the target workfow a model of an integrated mixer and splitter unit (called MixerSplitter) is built from scratch. In step A of the workfow we decide that there is no existing model in the library to be reused and we continue with activity C, i.e. building a new, CO-compatible model. At this point the activity diagram for the development of new models (Fig. 3.11 on page 67) comes into play. In the frst step of this workfow the model’s equation system is created by writing down all equations, assigning engineering units to all variables, determining the public parameters and adding ports for the inputs and outputs. External functions take care of the thermodynamic calculations and will make use of the CO interface defnitions. The generic equation system consists of the following eight equations:

1. component mass balance

NIS NOS ∑ Fin ∑ Fout · x = x · (5.11) F sca in,i i F sca in=1 out=1

2. outlet fow split NIS Fout ∑ Fin = b · (5.12) F sca out F sca in=1

3. outlet fow composition

xout,i = xi (5.13)

4. outlet pressure p p out = (5.14) psca psca

5. outlet temperature T T out = (5.15) T sca T sca 6. energy balance including heating duty

NIS NIS h ∑ Fin Q ∑ hin Fin · = + · (5.16) hsca F sca hsca · F sca hsca F sca in=1 in=1

142 5.2 Creating a New Unit Operation

7. system pressure equation p p = in=1 (5.17) psca psca

8. outlet summation for two outlets

bout=1 + bout=2 = 1 (5.18)

For this particular example of a MixerSplitter the number of components as well as the number of inlets and outlets is set to 2 in the model’s indexing section. The engineering units assigned to the variables are listed in table 5.2.

Table 5.2: Units of measurement of the mixer and splitter model Variable Base Name Unit of Measurement b 1 mol F s J h mol p P a J Q s T K mol x mol

As can be seen in the equations and in table 5.3 on page 145, constant scaling factors for total fow, enthalpy, pressure, and temperature have been used and other divisions than these have been avoided. When all the scaling factors are chosen in the correct order of magnitude, each term is not only dimensionless but also in the same order of magnitude (i.e. with absolute values around 1). This way there are no divisions by small numbers close to zero and this equation system’s numerical features are improved. The outlet split factor and the heating duty are the public parameters of this unit operation that can be modifed in the fowsheet simulator later on, when the CO unit operation is executed. Fig. 5.3 on page 144 shows the MOSAICmodeling GUI of the Unit Export Editor where the parameter bounds are set. In MOSAICmodeling four ports have been added mapping fow, pressure, temperature, and composition variables to the respective inlet and outlet material streams. Table 5.4 on page 145 lists all these variables.

143 5 Application and Case Studies iue5.3: Figure ntEpr Editor Export Unit GUI hwn h dutbeprmtr ftemxradslte example splitter and mixer the of parameters adjustable the showing

144 5.2 Creating a New Unit Operation

Table 5.3: Parameters of the mixer and splitter model Parameter Classifcation Value Lower Bound Upper Bound Q ADJ 10.05E3 -100E6 100E6

bout = 1 ADJ 0.5 0 1 F FIX 3E3 - - h FIX 43E3 - - p FIX 100E3 - - T FIX 300 - -

Table 5.4: Ports of the mixer and splitter model Interface Name Inlet1 Inlet2 Outlet1 Outlet2

F Fin=1 Fin=2 Fout=1 Fout=2

p pin=1 pin=2 pout=1 pout=2

T Tin=1 Tin=2 Tout=1 Tout=2

xi xin=1,i xin=2,i xout=1,i xout=2,i

The frst of the two external functions calculates the enthalpy of a stream and is applied on both inlets, see Equ. (5.19). The second external function uses the system’s enthalpy, pressure, and composition to calculate the temperature, see Equ. (5.20).

h = f(p, T, zi) (5.19)

T = f(h, p, zi) (5.20)

In the second step of the workfow for creating a new unit operation model (Fig. 3.11 on page 67) one is asked if the model is validated. In context of this workfow a solution for at least one point of operation must be available before a model is considered validated. A “point of operation” comprises of approximate inlet conditions and the fxed design values (e.g. set points). When there is a mapping of inlet condition and design values to a solution, the model is “validated for this operating point”. As the model has just been built, there is no solution, yet, and the steps three (generation of simulation code) to fve (evaluation of the simulation results) have to be performed. At this point the next iteration inside

145 5 Application and Case Studies this workfow starts, as we are not satisfed as long as we have not executed this model as a CO unit operation in a fowsheet environment. When updating the model in step 1 basically the solution of the simulation is set as the initial guess of all the iteration variables (e.g. including the values of the outlets) that are calculated by the model. As there is a solution available the model is now considered validated in step two and the workfow continues with the activities E and F that are part of the top level workfow (Fig. 3.9 on page 64). In analogy to the previous example all language specifcators necessary to create a 64 bit unit operation have been loaded into the editor (Fig. 5.4 on page 147) and new GUIDs have been created and set. The rest of the workfow is identical to the procedure in section 5.1, including installation and integration in a fowsheet environment. In detail this MixerSplitter example adds a new dimension of complexity as the results now explicitly depend on the property package including the physical components and thermodynamic system used. The results in Fig. 5.5 (ASPEN PLUS, page 148) and Fig. 5.6 (COFE, page 149) have both been calculated by using the KINSOL solver and the same property package provided by ASPEN Properties. Without the CO interface defnitions for property packages (“COThermo”) it would not have been possible to use the ASPEN properties in ASPEN PLUS as well as in COFE in order to get exactly the same results and ensure thermodynamic consistency across diferent simulation environments. In appendix F.2 additional screenshots of this scaledMixerSplitter unit operation are shown. The successful execution of this scaledMixerSplitter CO Unit Operation in two diferent, CO-compliant fowsheet environments confrms the mechanism of automatic implementation of CO interfaces developed in this thesis.

146 5.2 Creating a New Unit Operation MixerSplitter and the selected code generation options of the LS showing the used GUI Unit Export Editor example Figure 5.4:

147 5 Application and Case Studies APNPU eut itn fthe of listing results PLUS ASPEN 5.5: Figure fApnProperties Aspen of MixerSplitter xml sn ISLfrslto n thermodynamics and solution for KINSOL using example

148 5.2 Creating a New Unit Operation CO simulation example using thermodynamics of Aspen Properties via MixerSplitter results of the interfaces and KINSOL solver for solution COFE Figure 5.6:

149 5 Application and Case Studies

5.3 Extending an Existing Model Towards CAPE-OPEN

5.3.1 Existing Deisobutanizer Model

The model chosen to demonstrate the extension of an existing model towards CO was not developed by the author of this thesis but found in the model library of MOSAICmodeling. It is called “Deisobutanizer”, and mathematically describes a distillation column as part of a process to separate I- and N-Butane. The column model consists of four equation systems each representing a distinguishable part of the column (see Fig. 5.7):

• trays

• feed

• total condenser

• partial reboiler

NTR=35 tr=NTR+1 tr=NTR Condenser

Feed Trays tr=17

tr=1 Reboiler tr=0

Figure 5.7: Block diagram of the initial Deisobutanizer model showing the four model parts

150 5.3 Extending an Existing Model Towards CAPE-OPEN model showing parts of the hierarchy Deisobutanizer Figure 5.8: Screenshot of the initial

151 5 Application and Case Studies

Overall 28 generic equations are contained. After defning the index information to represent the two components and 35 trays, the system expands to 375 instantiated equations. DIPPR functions are used to calculate enthalpies and vapor pressure, and the phase equilibrium is modelled with a Raoult approach. Parameter Lists are used to defne the fxed parameters for the polynomials used to calculate the properties with DIPPR. The parameter specifcations are stored in a specifcation list (ID 47577), that is reused throughout the whole workfow until the DIPPR functions are replaced by CO function calls. There are no adjustable/public parameters defned, yet. The subsystems are connected using connection policy “integrate”, in case of feed, condenser, and reboiler additionally using connectors to rename the (connecting) variables. Tab. 5.5 (page 152) and Tab. 5.6 )(page 153) list the Connector for the condenser and the reboiler, respectively. Fig. 5.8 on page 151 is a screenshot of the model opened in MOSAICmodeling, showing parts of the hierarchy and the frst equations.

Table 5.5: Connector connecting the condenser to the trays system Condenser Name Trays Name

D,L,Reflux,n L,n F Ftr=NTR+1 F D,L,n F D,L,n D,V,in,n V,n F Ftr=NTR T D T D D,L,n L,n h htr=NTR+1 D,V,in,n V,n h htr=NTR D p ptr=NTR+1 D xi xtr=NTR+1,i D,in yi ytr=NT R,i

5.3.2 Extension Towards CAPE-OPEN

In step A of the workfow (Fig. 3.9 in chapter 2 on page 64) we can select the existing model with id 47583 (including the result list with id 102464) from the MOSAICmodeling library. Step B reveals that the model is not CO compatible,

152 5.3 Extending an Existing Model Towards CAPE-OPEN

Table 5.6: Connector connecting the reboiler to the trays system Reboiler Name Trays Name

B,L,in,n L,n F Ftr=1 F B,L,n F B,L,n B,V,n V,n F Ftr=0 T B T B B,L,in,n L,n h htr=1 B,V,n V,n h htr=0 B p ptr=0 B B xi xi B,in xi xtr=1,i B yi ytr=0,i as the check identifes the following issues: • The model has no ports, neither for inputs (feed) nor for outputs (distillate, bottom).

• The feed’s inlet temperature T f is not set as a given value.

• A forbidden summation equation for the liquid input of the feed system is defned.

• There is no public parameter defned. This is an optional criterion with lower priority, as it does not necessarily infuence the result of the existing model.

• The physical properties are calculated with fxed polynomials instead of calls to external CO functions. This is itself an optional criterion with higher priority, as thermodynamic consistency cannot be ensured when using diferent approaches for physical properties within one fowsheet. As the list of issues is non-empty and adjustments are pending, the next step according to the workfow is activity D, the systematic adaptation of an existing model to fulfll the CO requirements. This is when the workfow of Fig. 3.12 on page 68 comes into play.

153 5 Application and Case Studies

NTR=35 EQS-ID: 47505 tr=NTR conn Condenser ID: 47507

EQS-ID: 47471 EQS-ID: 47470 Feed Trays tr=17 EQS-ID: 47549 conn tr=1 ID: 47573 Reboiler

Figure 5.9: Block diagram of the Deisobutanizer model after model partition (EVA-ID: 93623) showing the four model parts and relevant IDs.

1. Model Partition The model already was partitioned in four subsystems, but with using the connection policy “integrate”. This poses the risk of introducing hidden dependencies between the systems, when diferent variables of two systems are unintendedly matched because of an unwanted naming collision. Therefore the partitioning was rechecked and condenser connection as well as reboiler connection were changed to “encapsulate” policy. This is indicated in Fig. 5.9 on page 154 by separating the condenser and the reboiler blocks from the trays block. The connection is now explicitly ensured by the applied Connectors, that have not been changed compared to the initial state (see Tabs. 5.5 and 5.6). The number of generic and instantiated equations has not changed compared to the initial state. After partitioning, the system has been stored (EQS-ID 93621) and validated in an evaluation (EVA-ID 93623). The results are stored in a Variable Specifcation List (ID 103209).

2. Function Separation In the function separation step each sub system is analyzed for equations and functions calculating physical properties. As these elements will later on be replaced by CO function calls, they are put in an extra equation system, making it easier to exchange the thermodynamic system. For each sub system all functions calculating physical properties have been separated from the other equations by building three systems:

154 5.3 Extending an Existing Model Towards CAPE-OPEN

EQS-ID: 103248 EQS-ID: 103237 Condenser Trays conn no Functions ID: 47507 EQS-ID: 103244 Functions (Thermo)

Feed no Functions no Functions Functions (Thermo) EQS-ID: 103249 Functions Reboiler (Thermo) conn ID: 47573 no Functions Functions (Thermo)

Figure 5.10: Block diagram of the Deisobutanizer model after function separation showing the four model parts and the separated subsystems

1. an equation system without thermodynamic calculations, called “no Func- tions”,

2. an equation system comprising of functions and equations calculating thermodynamic properties, called “Functions”, and

3. an enclosing equation system combining the other two, called “Functions added”.

Fig. 5.10 indicates the additional logical layer introduced by separating the (physical property, thermodynamic) functions from the (remaining) equations. A screenshot of the user interface in MOSAICmodeling and the resulting hierarchy is shown in Fig. 5.11 on page 156. The number of generic and instantiated equations has not changed compared to the initial state. This step has been validated with a simulation (EQS-ID 103234, EVA-ID 103252), the results are stored in a Variable Specifcation List (ID 103253).

3. Engineering Units In step three the whole system is analyzed for identifcation of engineering units necessary to describe the (external) function calls, the expected public parameters, and the variables to be part of ports (i.e. port

155 5 Application and Case Studies Sreso fthe of Screenshot 5.11: Figure Deisobutanizer oe fe ucinsprto EAI 103252) (EVA-ID separation function after model

156 5.3 Extending an Existing Model Towards CAPE-OPEN interface variables). In case of this deisobutanizer example, functions calculating enthalpies (units: K, P a, mol/mol, J/mol) and vapor pressures (units: K, P a) have to be considered. Variables in material ports in general need the SI engineering units for molar fow (mol/s), temperature (K), pressure (P a), and molar fraction (mol/mol). The set of these identifed units needs to be added to the Notation used in the model. For the Deisobutanizer example the “public notation” of the MOSAICmodeling library was used. As this notation already has an assigned Engineering Unit Set that contains more than these mandatory units, nothing needs to be done at this point. In case the notation does not have all necessary units, either another Engineering Unit Set including these engineering units has to be assigned to the Notation or the assigned Engineering Unit Set has to be extended. The frst option may invalidate existing models, if the Notation has been used beforehand by other modelers that rely on the specifc set of units in that set. Considering this the second option is to be preferred when an existing Notation is reused. If there is no write access to the Notation (or the respective Engineering Unit Set), a new Notation has to be set up, in- corporating at least all the symbols and engineering units (via Engineering Unit Set) that occur in function calls, public parameters, and ports (Interfaces).

4. Input Identifcation and Defnition The column model has one ingoing material stream, called “feed” and represented by the respective sub equation system. An analysis of the feed system showed that it contains two summation equations for the molar fractions that have to be removed from the model to comply to the rule that ingoing streams may not calculate the inlet composition. The remaining equations are on the one hand used to make sure that only liquid feeds enter the column and on the other hand calculate the molar specifc liquid enthalpies of the feed components. As the enthalpy can later on easily be calculated without an explicit summation by calling CO property functions, the feed system was reduced to one equation (eq. 5.21) and calls of the DIPPR100 function (EQS-ID 103267, EQS-ID 103268, and EQS-ID 103266). This leads to a reduction of the number of equations to 24 generic equations and 370 instantiated equations.

NC f,L,n ∑ f f,L,n 0 = h − xi · hi (5.21) i=1 The standard Interface in MOSAICmodeling used for all ports that will con-

157 5 Application and Case Studies nect to material streams (Interface-ID 103258) contains four generic variable namings (including proper engineering units) for total fow, pressure, temperature, and molar fraction. Tab. 5.7 shows the matching of the Interface’s variables to the variables in the feed and trays equation systems that represent the internal names of the feed port variables (Connector-ID 103259). The validation of this step in a fowsheet software is postponed to completion of the next step when the remaining output ports have been added to make this model a regular unit operation.

Table 5.7: Feed connector for input port defnition Interface Name Unit EQS Name mol f,L,n F s Ftr=17 p P a pf T K T f mol f zi mol xi

5. Output Identifcation and Defnition Compared to the input port the identifcation and defnition of the output ports is straight forward without modifcation of the equation systems. The distillate output port connects to the condenser equation system (Connector-ID 103260), the bottom output port connects to the reboiler system (Connector-ID 103261). Tab. 5.8 lists the respective matching of the Interface’s names and the names of the variables in the equation systems.

Table 5.8: Connector for output port defnitions Interface Name Unit Distillate Name Bottom Name

mol D,L,n B,L,n F s F F

p P a ptr=NTR+1 ptr=0 T K T D T B mol B zi mol xi,tr=NTR+1 xi

With adding all the input and output ports the system can be visualized as a fowsheet inside MOSAICmodeling. This is shown in Fig. 5.12. The adjustment

158 5.3 Extending an Existing Model Towards CAPE-OPEN

Figure 5.12: Screenshot of the Deisobutanizer model unit operation after port addition (EVA-ID 103274)

steps four and fve have been validated with a simulation (EQS-ID 103271, EVA- ID 103274), the results are stored in a Variable Specifcation List (ID 103354). Additionally the simulation with EVA-ID 103274 was loaded in the Unit Export Editor and a unit operation model was saved with UOP-ID 1033391. An export, installation, and execution of this CO unit operation was successfully performed using COFE as CO-compliant PME. From this step onwards the CO validation always takes place by executing the unit operation in COFE, where feed conditions ftting to a feed fow rate of 5.7mol/s are used.

6. Public Parameters The design value “pressure drop from one tray to the next” ∆p was selected to be a public parameter of the column model. There- fore a new Parameter List (PAR-ID 103375) containing ∆p was created in the Parameter List Editor and added to all equations that include calculations with the pressure drop2. The parameters section in the simulation editor now lists ∆p as a parameter (EVA-ID 103357). In contrast to all other (fxed/private) parameters used in the DIPPR function polynomials, the pressure drop’s parameter classifcation is now set to ADJUSTABLE, making it a public parameter in the CO unit operation export. Fig. 5.13 shows a screenshot of the respective section

1At this point there was no public parameter involved. Due to the following step in the workfow, a public parameter has been defned in equations this simulation includes, therefore infuencing this system in a way that the original state present after step 5 cannot be exactly loaded again. 2This infuences all equation systems and evaluations that use these equations. Therefore the previously created simulations (e.g. 103274) now also show ∆p as a parameter, even if not intended when originally creating these simulations in the frst place.

159 5 Application and Case Studies in the Unit Export Editor. The lower bound of the pressure drop parameter is set to 0, whereas the upper bound is set to 1E6 (equivalent to 10 bar). The unit operation was successfully exported, installed, and executed within COFE. Changes of the unit’s pressure drop parameter in COFE infuenced the results as expected.

7. Thermodynamics Generalization In order to switch the calculation of physical properties to CO function calls, again an analysis has to take place. Due to the separation of equations related to thermodynamic calculations in step 2 of this workfow, it is exactly defned which subsystems containing thermo-related function calls now have to be replaced by equation systems using CO calls. Tak- ing a look at Fig. 5.11 on page 156 and considering the refactored feed equation system of workfow step number 4, the following subsystems are identifed for replacement:

• Trays: EQS 103235

• Feed3: EQS 103266

• Condenser: EQS 103247

• Reboiler: EQS 103250

Regarding the trays system the two equations summing up the enthalpies (equ. 5.22 and equ. 5.23) are replaced by the three equations 5.24 to 5.26.

NC L,n ∑ L,n 0 = htr − xtr,i · htr,i (5.22) i=1

NC V,n ∑ L,n LV,n 0 = htr − ytr,i · (htr,i + htr,i ) (5.23) i=1

L,n L,cal,n htr = htr (5.24)

V,n V,cal,n htr = htr (5.25)

3Before step 4 the feed system with ID 103242 would have been the one containing the functions (see Fig. 5.11).

160 5.3 Extending an Existing Model Towards CAPE-OPEN Figure 5.13: Screenshot of the Deisobutanizer model unit operation after addition of a public parameter.

161 5 Application and Case Studies

NC ∑ L,n V,n L,n V,n zi,tr · ( (Ftr · xi,tr + Ftr · yi,tr)) = Ftr · xi,tr + Ftr · yi,tr (5.26) i=1

Equ. 5.26 is added to access the overall composition on each tray. This adds in the end 70 new equations to the overall system, increasing the equation count from 370 to 440. The overall composition is an information that is given to the CO function calculating the fugacity coefcients for the vapor phase and the liquid phase. These calls replace the DIPPR calls to the vapor pressure that were used in the initial system based on a simpler Raoult approach. The DIPPR100 function applications for enthalpy calculation are replaced by calls to a respective CO property package function.

Regarding the feed system the equation summing up the enthalpies (equ. 5.27) is replaced by equ. 5.28.

NC f,L,n ∑ f f,L,n 0 = h − xi · hi (5.27) i=1

hL,f,n = hL,cal,f,n (5.28)

The DIPPR100 function application to calculate the enthalpies is replaced by a respective function call to the CO property package.

Regarding the condenser system, equ. 5.29 was as an exception added to the “non-function” sub system that is not directly related to the physical properties function calls.

T out = T D − ∆T (5.29)

This equation, increasing the equation count from 440 to 441, was added to improve the robustness of the condenser model, as it allows to add a temperature diference in order to guarantee a single (subcooled) liquid phase after conden- sation. The previous approach, found in the Deisobutanizer model, calculated the bubble point temperature. This made the model sensitive to small temperature deviations of thermodynamic calculations of underlying property packages, causing numerical challenges when the number of phases changes between one

162 5.3 Extending an Existing Model Towards CAPE-OPEN and two during the solution process. The temperature diference ∆T has been added to the Parameter List to be adjustable in the Simulation Editor, making it a public parameter in the CO Unit Operation. In analogy to the trays systems the equation summing up the enthalpies (equ. 5.30) was replaced (equ. 5.31), calls to a CO property package are used instead of the DIPPR100 function, and fugacity coefcients are calculated instead of vapor pressures (DIPPR101) in order to determine the phase equilibrium con- D stant Ki at the given temperature.

NC D,L,n ∑ D D,L,n 0 = h − xi · hi (5.30) i=1

hD,L,n = hD,L,cal,n (5.31)

Regarding the reboiler system exactly the same happens as described in the previous paragraph: the equations summing up the enthalpies (equ. 5.32, 5.33) were replaced (equ. 5.34, 5.35), calls to a CO property package are used instead of the DIPPR100 function, and fugacity coefcients are calculated instead of vapor B pressures (DIPPR101) in order to determine the phase equilibrium constant Ki at the given temperature.

NC B,L,n ∑ B B,L,n 0 = h − xi · hi (5.32) i=1

NC B,V,n ∑ B B,L,n B,LV,n 0 = h − yi · (hi + hi ) (5.33) i=1

hB,L,n = hB,L,cal,n (5.34)

hB,V,n = hB,V,cal,n (5.35)

Fig. 5.14 shows a screenshot of the resulting equation system (EQS-ID 103857) in the Simulation Editor (EVA-ID 103860).

5.3.3 Execution as a CAPE-OPEN Unit Operation

After adjusting the existing Deisobutanizer distillation column model to become a CO-compatible unit operation, the Unit Export Editor of MOSAICmodeling

163 5 Application and Case Studies Sreso ftefnal the of Screenshot 5.14: Figure Deisobutanizer oe ntoeainatrsicigalpoet acltosto calculations property all switching after operation unit model CO

164 5.3 Extending an Existing Model Towards CAPE-OPEN is used to create an installer of this unit operation. For the export the name of the unit operation has been changed to “TwoCompoundColumn”, making it clear that the use of the model is now not restricted to I- and N-Butane anymore, as the property package of the fowsheet environment now determines the actual compounds used. The 32 bit installer of the TwoCompoundColumn was used to install the unit operation and insert it in ASPEN Plus, as Fig. 5.15 shows. Unfortunately adding a unit operation to a fowsheet and solving a unit operation is not the same, as can be seen in Fig. 5.16 on page 167. The solver stopped when the property package refused to perform a fash calculation at a temperature of more than one million Kelvin, indicating that the solver was not close to fnd a solution in the expected temperature range. This is a numerical issue independent of the fowsheet environment, as the generated unit operation always uses the same solver that is included by MOSAICmodeling (here: SUNDIAL’s KINSOL).

In summary the application of the workfow to extend a given model to become a CO unit operation was successful, as the insertion of the model into ASPEN Plus and COFE has shown (see appendix F.3.1 for additional screenshots of the COFE integration). Strategies for the actual numerical solution of equation based models in fowsheet environments are not in the scope of this thesis, nevertheless in the evaluation chapter some suggestions for improvements in this direction are given.

165 5 Application and Case Studies Sreso fthe of Screenshot 5.15: Figure enelre ofcso h ntoperation. unit the on focus to enlarged been TwoCompoundColumn netdi SE ls h rwn raisd h icehas circle the inside area drawing The Plus. ASPEN in inserted

166 5.3 Extending an Existing Model Towards CAPE-OPEN in ASPEN Plus. TwoCompoundColumn Figure 5.16: Screenshot of the results when running the

167 5 Application and Case Studies

5.4 Documentation-based Flowsheeting

In the last example the extensions implemented regarding documentation-based fowsheeting are demonstrated. Within this example a process fowsheet of several splitter and mixer unit operations is composed. Fig. 5.17 on page 169 shows a screenshot of this cascade of simple units with overall one input and four outputs. Two models build the basis for the seven units: a splitter model consisting of two equations and a mixer model containing one equation. The mixer returns an outlet z that adds the two inlets x and y (eq. 5.36).

z = x + y (5.36)

The splitter uses a splitting factor α to separate the inlet x into the outlets y and z. The value for α is restricted to the interval [0,1]. Values outside of this range would cause one outlet to have a negative fow, thus making it act like an inlet and therefore contradict the defnition of being an outlet. The splitter is represented by equations 5.37 and 5.38.

y = x · α (5.37)

z = x · (1 − α) (5.38)

The mixer as well as the splitter equation systems are stored separately and act as templates for unit operations. In order to compose a fowsheet based on these equation systems two diferent approaches are tested in this example. Either way an Interface with exactly one variable (called Q for “quantity”) is used for ports as well as streams to defne the information crossing the equation systems’ boundaries. In the frst approach the equation system of the splitter model is extended with ports once to become a unit operation that is reused fve times. The second possible approach is applied on the mixer model. In this case the model is extended with ports and stored twice, resulting in two unit operations with diferent IDs in the library of MOSAICmodeling. In Fig. 5.18 on page 170 the reused splitter unit is identifed by “60516: unit_Splitter1” whereas the two mixer units are called “60522: unit_Mixer4” and “60523: unit_Mixer7”. Due to the connection policy “streams” the reused splitter equation systems are clearly separated and distinguishable by their internal index inside the equation system of the process. For the simulation of this cascade of simple splitter and

168 5.4 Documentation-based Flowsheeting

Figure 5.17: Visualization of the equation-based fowsheeting example showing the cascade of splitter and mixer unit operations

mixer unit operations the input value of the frst splitter, the last output (port number 5), as well as all but one splitting factor are fxed. The goal of this simulation therefore is to calculate the remaining outlets and the remaining split factor in order to get the desired output value at output port number 5. Appendix F.4 lists all equations, variables, and stream connections as well as initial values and results. This example demonstrates the stream connection and visualization possibilities added within the implementation of this thesis. In contrast to the previous examples it is explicitly not meant to be exported as a CO unit operation, but as a model to be simultaneously solved in an equation-oriented simulation environment as opposed to sequential fowsheet environments. This once again shows the fexibility of the documentation-based, platform independent modelling and code generation approach of MOSAICmodeling.

169 5 Application and Case Studies Heacyadeutoso h qainbsdfwheigeapemdligtecsaeo pitrand splitter of cascade the modelling example fowsheeting equation-based the of equations and Hierarchy 5.18: Figure ie ntoperations unit mixer

170 6 Evaluation

6.1 Modelling Guidelines

In the course of this work some guidelines were developed. Considering them when creating the model of a unit operation will help to avoid some known pitfalls on the way to automatic implementation:

• In principle all quantities of input streams have to be selected as design variables inside MOSAICmodeling. Following this rule, it is clear that summation conditions (of mole fractions) must not be stated for input streams, as these are not calculated, but given by previous units or as a process feed in the fowsheet environment. A normalization is nevertheless allowed, when it is desired to guarantee molar fractions between zero and one. On the other hand the summation conditions for output streams are mandatory. This is because of the convention that every unit operation has to fash the outlets before returning the control to the fowsheet environment or the next unit operation. If there are no plausible molar fractions given to the fash algorithm, it will consequently fail, leading to a stop of the fowsheet calculation.

• Material ports always use F , p, T , and zi as variables. In case a model internally uses Ni instead of the variables for total fow and molar fraction, a conversion has to be performed. For inlets this means in in,port in,port Ni = F · zi , pin = pin,port, and T in = T in,port.

out Outlet variables, internally given as Ni are converted inversely: out,port ∑ out F = i Ni out,port ∑ out out (zi ) · i Ni = Ni pout = pout,port

171 6 Evaluation

T out = T out,port

• In a model with ingoing or outgoing enthalpy fows (e.g. h˙ ), the enthalpy fows also have to be converted to a representation relying on F , p, T , and

zi again. In this case some thermodynamic calculation using a property package is necessary. On the one hand pressure, temperature, and composition of the input have to be taken into account when calculating the incoming enthalpy fow, on the other hand the enthalpy fow of the outlet is used to calculate the respective output temperature.

hin = hcal (6.1)

cal in in in h = f(p ,T , zi ) (6.2)

out out out out T = f(h , p , zi ) (6.3) The calculation of input enthalpies and output temperature is demonstrated in the MixerSplitter example (section 5.2).

• Ideally the equation system built is independent of the later on used set of components in the material streams. That is why all calculations related to physical properties of the components should be performed by calling respective functions. During frst model creation it is absolutely valid to use fxed polynomials with component-dependent parameters as function bodies, the DIPPR functions being one example. At this point the order

of the components zi has to be fxed in order to match the correct parameters for the diferent components when the functions are called. At last when switching over to a use as a CO unit operation, the property calculations should be performed using the CO thermodynamics interface defnitions instead of the explicit polynomials. This way the thermodynamics are consistent throughout the whole fowsheet and the functions automatically adopt the component order given by the property package. See the respective part in section 6.3.

172 6.2 Achievements

6.2 Achievements

A workfow has been developed, describing how to systematically create the model of a unit operation, export it as a CAPE-OPEN unit operation, and execute it. The workfow in MOSAICmodeling to build models is extended and not fundamentally changed. With the workfow to adapt existing equation systems a recipe exists, how to integrate an existing model with easy steps into a fowsheet. A new editor in MOSAICmodeling has been added. It enables the creation of valid CO unit operations and integration into CO-compliant process modelling environments without the need for expert programming knowledge. A user manual was written (see appendix B) and in three examples the successful application of the workfow was demonstrated, giving users enough material to learn the handling of this new editor themselves. This work therefore lowered the threshold for using CAPE-OPEN, freeing the process engineer of programming work and making him/her focus on the actual modelling. The open structure of UDLS and Unit Export Editor make it easy to change the code to be generated. When using CO property calculation the parameters of the calculation are provided by the property package and the user cannot unintendly mix up wrong parameters in manually implemented function bodies when the order of the components changes. Consistency of thermodynamic calculations throughout the whole fowsheet can be ensured when using CO property calculations in all unit operations, independent of the fowsheet environment. Changing the calculation routines for physical properties in the model is way easier when usingCO, as it is easily done by choosing another property package in the PME’s user interface. The model does not even have to be touched for this (as long as the number of components does not change). With public parameters the creator of a unit operation can guide the user of the unit operation which options (i.e. public parameters) can be varied in which boundaries. The reusability of a unit operation is in principle improved using CO compared to proprietary approaches. In addition to the improvements immediately connected to CO, this work provided a way of documentation-based fowsheeting. For that purpose the units, as they are created in MOSAICmodeling, are visualized showing their ports and connections between each other in a diagram, using rectangles for the units and arrows for the streams. This kind of visualization is known from the process fow

173 6 Evaluation diagrams used in fowsheet simulators. This way the advantages of convenient visualization known from the modular-sequential fowsheet simulators are combined with the freedoms of equation-based modelling. The respective example in section 5.4 showed how it is now possible to set a fowsheet’s output quantity as a design variable and calculate all values by simultaneously solving the overall equation system. This kind of “calculating from the end to the beginning” is not immediately possible within a sequential fowsheet with its pure input-output behaviour. In summary the achievements enabled a more efective work in research and education. This is because of the improvement of the platform-independent modelling and code generation software MOSAICmodeling and the new possibility of a direct model export as an executable CO unit operation. So the process engineer can concentrate on proper model development without the need to know the details of the implementation of the CO interfaces.

6.3 Limitations and Future Work

In this section known limitations of the developed mechanism for automatic implementation of CO unit operations are named and further opportunities for the improvement of this approach are mentioned.

The code templates used for systematic implementation of the unit operations are very generic, in order to support a variety of diferent models. This comes with the drawback of non-optimality of the generated code regarding performance when compared to an implementation dedicated to a particular mathematical model including more knowledge of the specifc model structure. The automatically created code nevertheless can be adapted to certain requirements, as long as it is not immediately compiled after generation. Due to this transparent behaviour the advantages of automatic model implementation can be used and at the same time the disadvantages of the generic approach can be avoided. Using MOSAICmodeling’s analysis feature improvements regarding the convergence behaviour can be expected, because it would explicitly include the model’s mathematical structure in the solution algorithm. A block decomposition inside a unit operation is according to previous experience sometimes crucial when working with a limited set of available solvers (e.g. SUNDIAL’s KINSOL or fsolve in Scilab/MATLAB).

174 6.3 Limitations and Future Work

The CO interfaces related to the reporting facilities of a unit operation have not been implemented, yet. Besides the information available after solution of a model it would also be nice to get additional information about the intermediate states and results when the system did not converge. The reports could provide this information (especially the results) in a way that a re-import with MOSAICmodeling’s import feature would be possible. This would help improving the model or the intial values for further simulation runs in other simulation environments or with other set points.

When the set points or feed conditions change, the model in MOSAICmodel- ing actually has to be updated, as the initial guess values will not be appropriate anymore, because they were chosen for other conditions. In an extension of the code generation in MOSAICmodeling it would be a frst attempt to cover this by somehow storing intermediate results when the unit operation is solved in an external recycle, with only moderate changes of the conditions between two subsequent iterations. At the moment the unit operation always starts with the same initial guess values, ignoring the previous results and therefore making the calculation routine unnecessarily slow.

A similar challenge in the interaction between PME, unit operation, and physical property package is the topic of leaving the unit operation’s range of validity. Whenever a PME sets inlet conditions that are out of the range the unit operation is designed for, the user should at least get a warning. By allowing the user setting lower and upper bounds for the variables related to the inlet streams inside MOSAICmodeling it would be possible to generate code that defnes functions checking these bounds similar to the bounds of the public parameter values. These bound-checking functions could be called during the unit’s validate procedure and at the beginning of each call of evaluate, issuing a warning or aborting the simulation when infeasible states are to be epected. A second way to violate a validity range occurs when the unit operation’s solver calls the physical property package with a temperature or pressure too low or too high. This is what actually happend when executing the TwoCompoundColumn example of chapter 5 in the fowsheet environments. In this case the property packages usually issue an internal warning or return values that indicate infeasible calculations. These error codes have to be caught inside the function calls generated by MOSAIC-

175 6 Evaluation modeling in order to write appropriate information into the solve log or prompt a message that the current calculation run had to be aborted due to an infeasible state handed over to the property package.

For the simulation of a single unit operation an explicit defnition of the functions calculating the physical properties may be feasible. Examples are the DIPPR functions with respective compound-specifc parameter values. In this case the user has to be aware that the unit operation will under all circumstances calculate with this particular setting. Whenever this unit operation is executed in a fowsheet the components defned in the fowsheet would be ignored, because of the hard-coded parameter values in the functions calculating the physical properties. In the worst case the set of components is changed in the fowsheet and all units but this one are using the new setting. This is usually not the desired behaviour. That’s why it should be the goal of any modeler who is using CO, not to hard-code any physical property information inside the equation system. A limitation of this statement is given by MOSAICmodeling’s nature of creating scalar variables for all quantities indentifed by the generic equation system and the indexing information given in the evaluation. In other words: in MOSAICmodeling the user is forced to set the number of components to a fxed value before code generation. Of course one option would be to export the model for several diferent numbers of components and later on choosing the appropriate version when adding a unit operation to a fowsheet. But one problem will still remain, as for each version of the unit operation feasible initial guesses have to be provided. In order to give feasible initial guesses of variables related to components, the components must be known in advance. This is an issue that cannot be resolved as long as the initial guesses have to be set before the export of the unit operation. For unit operations that will only be used with a fxed number of components it is a viable option to use fxed parameter property functions to generate feasible initial guesses before switching to the generic approach using CO property packages.

A closely related challenge comes up as soon as the number of components the unit operation expects does not match the number of components that are present in the fowsheet’s property package. As MOSAICmodeling instantiates every single variable and has to match all inlet quantities to variables present inside the equation system, the simulation of the unit operation will immedi-

176 6.3 Limitations and Future Work ately fail when the unit operation expects more components than available in the inlet. The other way around, when the unit operation has less components than the property package, the unit will fail to set the complete information at its outgoing ports. That is why the unit operation’s validate function will reject this setting and such a simulation cannot even be started. Anyway, if this is nevertheless not prohibited in validate, in both cases (i.e. too little / too many components) a workaround would be setting all unmatched or unknown components to be equal to zero. While this might be a valid attempt when the unit operation supports more components than available in the property package, setting the output composition of a surplus component to zero will ultimately annihilate this component in this branch of the fowsheet. In such a case mass conservation cannot be guaranteed at all. So automatically setting surplus compositions to zero is not a good approach. In order to overcome this challenge a normalising code could be generated for all unit operations. This normalisation code stores the surplus amount of material at the inlet and bypasses this amount of mass directly to output variables. The inlet streams are normalised regarding the remaining components, making the calculations of this unit operation at least consistent for the expected number of components. It is not clear at all how the bypassed components should be distributed to several outlet ports. So the general advise here is to reject such a setting in the unit’s validate function and take care of this situation on fowsheet level instead of unit operation level. This can be done by either replacing this unit operation by a better ftting one or introducing bypass (splitting and mixing) units around the unit operation under investigation, taking care that no material is lost due to this unit that cannot handle the correct number of components.

An issue specifc to the implementation in MOSAICmodeling is related to so- called calculated variables. For these variables usually it makes no sense to specify initial values as they are directly calculated during the solution iterations. In the case of externally calculated functions without explicit function body MOSAIC- modeling should provide the option to specify initial values. In order to help specifying the initial guesses for the iteration variables, MOSAICmodeling ofers the option to calculate the frst iteration run, giving feedback if the chosen set of values is at least at frst glance close to a solution. This makes at the moment no sense when external functions are involved, as they can not be calculated inside MOSAICmodeling and therefore always are evaluated to zero, preventing

177 6 Evaluation any meaningful feedback regarding the frst iteration. This is the point where setting initial values would be feasible to help specifying the initial guesses of the iteration variables.

A preparational step before the actual simulation could signifcantly improve the CO unit operation’s performance in complex fowsheets with recycles and repeated simulations. The idea behind this is reducing the time spent for calculation of values provided by external calculation routines, that may take a signifcant amount of time. During this proposed initialization step the physical property values needed for the simulation are calculated beforehand and temporarily stored in property tables. Therefore the user has to specify the expected average or median values of temperatures, pressures, and compositions. The second information the user has to provide are the expected lower and upper values for these variables that will hold for a certain propability (e.g. 90 %). The program will based on this information create a mesh and evaluate the property function in all nodes. It is up to the mesh creation algorithm to make the mesh fner grained in areas with higher probability. This initial evaluation step will of course be very time consuming, so it is only feasible if a high number of simulation runs will follow, e.g. during an optimization. During the actual simulation runs the physical property information is not again calculated by calling an external function, but by retrieving the value with a simple lookup in the tables generated in the initialization step. If there is no perfect match of the requested conditions, a linear interpolation using the bounding box of the nearest values will deliver an acceptable value (assuming a continuously diferentiable underlying “real” property function). An intelligent algorithm able to identify discontinuities in the table of property data could refne the grid in these areas, making it more unlikely to make big errors when interpolating instead of calculating an exact value. Only for points outside the grid (i.e. points lying outside the boundaries specifed by the user) no interpolation takes place. In this case the external function is actually called and the retrieved result is added to the table in order to be able to perform a lookup the next time. This way the property package can give feedback instead of blindfoldedly taking an extrapolated value. Whenever an initialization step was performed, some kind of persistence mechanism (maybe directly the mechanism specifed by CO) should be provided to reuse the gathered information several times and informing the user which areas are covered by a particular lookup table. As long as such a lookup table

178 6.3 Limitations and Future Work can be used, there is no need for an additional initialization step. This leads to the requirement of an option to switch the initialization step on and of. Maybe a public parameter could be introduced that has no mathematical functionality inside the equation system and serves only as sequence control variable. It has to be investigated if this kind of parameter could be defned on the level of language specifcators, as a new data type for the code generation options, independent of the equation system. The development of respective code that can be created automatically seams to be complex, but would ofer a lot of new possibilities.

The installer generated for the unit operation could be enhanced by adding a PDF documentation of the exported model as present in MOSAICmodeling. This documentation is based on the description felds of all elements. MOSAIC- modeling has a dedicated documentation module, creating LATEX code. When this LATEX code is compiled to a PDF fle, it can be included as an optional component to the unit operation installer. In case it is intended not to provide a documentation fle (avoid disclosing of internal knowledge, intellectual property), the option must exist, not to deliver the PDF fle with the installer. Otherwise the protection function of CO (the model can be used, but internals are hidden) would be lost. On the other hand an export policy oriented towards the free and open source community may help indentifying model errors by more people having the chance to have a look at the underlying equations.

In the Unit Export Editor of MOSAICmodeling the language specifcators so far have to be selected one-by-one. The introduction of a new element, called Language Specifcator Set (LSS), could improve the user experience. Similar to a Variable Specifcation List or an Engineering Unit Set this element could be stored separately and would collect a set of LS elements including their properties. In the library specifc LSS could be provided for the use in the unit operation editor, containing all the language specifcators most commonly used for a standard export, including diferent versions for 32-bit and 64-bit unit operations. The application would not be limited to the Unit Export Editor. In all editors used for code generation that are loading language specifcators, such LSS elements can help creating several code fles at once for simulation and optimization. At the moment these fles have to be created one after another or the content of several fles is written into a single fle, causing the need for a manual separation afterwards.

179 6 Evaluation

The documentation-based fowsheeting at the moment is restricted to a read- only visualization functionality. In a frst extension at least the positioning in the visualization could be stored, avoiding a repositioning every time the preview ist refreshed. A further extension could add an editing option, allowing to connect the unit operations graphically. This way the inconvenient/formal way using the internal streams editor would be complemented with a more intuitive alternative.

180 7 Conclusions

As stated before, implementing a model according to the CAPE-OPEN (CO) interface defnitions requires knowledge in the area of process engineering as well as in the area of computer science. The development of a mechanism allowing an automated implementation of this standard without in-depth programming knowledge seems to be promising to increase the process engineers efectivity. It reduces or even eliminates the need for error-prone manual implementation and can lead to a spreading use of the CO standard. The basics of CO, fowsheet simulation, unit operations, and engineering units have been presented in the theoretical background chapter. The targeted workfow has been derived and explained in the analysis chapter. It enables a systematic way to create new or re-use existing, equation-based models that can be exported automatically as CO-compatible unit operations. The analysis of the existing gaps between initial situation and the targeted workfow resulted in steps to fll these identifed gaps. These steps have been performed in the concept and implementation chapter. The approaches, technologies, and modules added to MOSAICmodeling were described and the important graphical user interfaces were commented on. The application chapter highlighted the successful use of the workfow by application on four diferent examplary systems, including one example for documentation- based fowsheeting, enabled as well by this thesis. In the evaluation chapter modelling guidelines as well as the achievements of this work were given, mainly the extended modelling workfow with a recipe to create CO unit operations in an automated way without programming knowledge. The issues that nevertheless could not be solved yet and topics of future work followed. To name some of them, improved algorithms to solve the equation system, e.g. using automatic decomposition methods based on the equation systems structure or intelligently changing the inital values when the boundary conditions change, have to be incorporated in the automatic code generation facilities. In summary this work made a contribution to systematic modelling, and use of CO for exchange of models in process simulation.

181

Appendix A

CAPE-OPEN Interfaces

This appendix lists all CO interface specifcations as they can be found online on CO-LaN web site (http://www.colan.org/specifcations). It contains the business interfaces as well as the common interfaces with a short description as it is given in the documentation set.

Business interface specifcations: Partial Diferential Algebraic Equations Numerical solvers Thermodynamics and Physical Properties v1.0 Thermodynamics and Physical Properties v1.1 Unit Operation Petroleum Fractions Chemical Reactions

• Partial Diferential Algebraic Equations “This interface defnes, on top of the Solvers specifcation, numerical services for systems with some variables distributed along one or several dimensions. In Partial Diferential Algebraic Equations the dependent model variables depend on one or more independent variables. Independent variables are for instance spatial co-ordinates, particulate co-ordinates (in case of population balance models) or time (in case of dynamic models). Thus, models of computational fuid dynamics are also included in this class of problems.” http://(...)/specifcations/partial-diferential-algebraic-equations/

• Numerical Solvers “Focuses on the solution algorithms that are necessary for carrying out steady state and dynamic simulation of lumped systems. In particular, this

183 Appendix A CAPE-OPEN Interfaces

includes algorithms for the solution of large, sparse systems of non-linear algebraic equations (NLAEs) and mixed (ordinary) diferential and algebraic equations (DAEs). Algorithms for the solution of the large sparse systems of linear algebraic equations (LAEs) that often arise as sub-problems in the solution of NLAEs and DAEs are also considered. The CAPE-OPEN standard introduces new concepts, such as models and the equation set object (ESO), which is a software abstraction of a set of non-linear algebraic or mixed (ordinary) diferential and algebraic equations. This document is a deliverable of the CAPE-OPEN project and has not been revised ever since. There is no Special Interest Group chartered with maintaining this interface specifcation.” http://(...)/specifcations/numerical-solvers/

• Thermodynamics and Physical Properties v1.1 “The Thermodynamic and Physical Properties Interface is a business interface specifcation for thermodynamic software components being used by PMEs. It is important to point out that, through the revision issued in 2011, the interface design has not been changed whatsoever since its original release): the IDL and the corresponding type library remain unchanged. Still many clarifcations have been brought to the original document. Developers are especially asked to carefully read sections 7 and 8 of the new document: it provides useful information on how to implement the Thermodynamic and Physical Properties interfaces in version 1.1 of the CAPE-OPEN standard. It is hoped that this new document will help developers implement more easily the corresponding interfaces so that the end-users enjoy an even better experience through CAPE-OPEN interfaces.” http://(...)/specifcations/thermodynamics-and-physical-properties-interface- specifcation-v1-1/

• Thermodynamics and Physical Properties v1.0 “The Thermodynamic and Physical Properties Interface is a business interface specifcation for thermodynamic software components being used by PMEs. The frst public release of the document describing the Thermodynamic and Physical Properties interface specifcation dates back to March 2002 and is labelled as release 1.06. This document carries the logo of the Global

184 CAPE-OPEN project since it was issued during that project funded by the European Commission.” http://(...)/specifcations/thermodynamics-and-physical-properties-interface- specifcation/

• Unit Operation “The Unit Operation Interface is a business interface specifcation for unit operation modules being used within modular and steady-state PMEs. A Unit Operation may have several Ports that allow it to be connected to other Unit Operations and to exchange material, energy or information with them. For example, in the material case (which is also the most common), the Port is associated with a Material Object. Ports are given directions (input, output, or input-output). Unit operation also have sets of Parameters. These represent information that is not associated with the Ports, but that the Unit Operationss wish to expose to their clients. Typical examples include equipment design parameters (e.g. the geometry of a reactor) and important quantities computed by the module (e.g. the capital and operating cost of a reactor).” http://(...)/specifcations/unit-operation-interface-specifcation/

• Petroleum Fractions “The Petroleum Fractions interface specifcation allows Unit Operations to read and modify properties specifc to the petroleum industry, such as cloud point, pour point, and Reid vapour pressure. The interfaces defned also allow run-time re-characterization of the properties of hypothetical compounds representing a petroleum fraction (e.g. Normal Boiling Point, Molecular Weight, Specifc Gravity, Critical Temperature, etc. . . ). Therefore, the interfaces allow for extending plug-and-play of Unit Opera- tion components to the specifc process operations present in the petroleum and gas industry (e.g. refning, upstream, etc. . . ). Many of these specifc Unit Operations are reactors (cat-crackers, hydro-cracker, etc. . . ) that change compound property values (of petroleum fractions). Dealing with petroleum fractions rather than pure compounds requires special treatment. Only interactions between a PME and Unit Operations on pseudo-compounds are considered. Furthermore only Property Packages native to the PME are considered. Hence interaction regarding petroleum fractions between

185 Appendix A CAPE-OPEN Interfaces

PME and external Property Packages is not in the scope. Curve properties are excluded from the scope. Functionality of blend rules is not carried through the existing and newly proposed CAPE-OPEN interfaces.” http://(...)/specifcations/petroleum-fractions/

• Chemical Reactions “The Chemical Reactions interface specifcation describes two primary CAPE- OPEN components: Reactions Package and Reactions Package Manager, and introduces the concept of a Reaction object as a mechanism for pass- ing reaction data between a CAPE-OPEN compliant Process Modelling Environment (PME) and a Reactions Package component. A Reactions Package Manager component is a factory for the set of Reac- tions Packages that it manages and it may act as a tool for constructing new Reactions Packages. A Reactions Package contains the defnition of a set of kinetic reactions for a defned set of compounds and phases. It allows a client to request the calculation of Reaction Properties, for example the reaction rate. A Reactions Package may allow a client to reconfgure the reactions that it defnes, for example to change activation energies. Equilibrium Reactions are supported by combining the concepts of the Re- actions Package and the CAPE-OPEN thermodynamic Property Package. The resulting Property Package supports both the Property Package and the Reactions Package interfaces. The combined set of interfaces allows a client to request the calculation of equilibrium reaction properties and thermodynamic property calculations from a single package.” http://(...)/specifcations/chemical-reactions/

Common interface specifcations: Persistence Error handling Parameter Identifcation Collection Utilities Simulation context specifcation

• Persistence “Persistence interface defnes how models and model elements are stored and retrieved. Most simulation environments allow the possibility to store

186 at any moment the state of a simulation case, in order to be able to restore it at any time in the future. In the CAPE-OPEN distributed environment, where diferent pieces of the simulation may be implemented by diferent vendors, the Persistence interface proposes a standard mechanism to provide this feature. This interface is diferent from all others, as it does not defne any new method. Instead, it explains how to use standard persistence mechanisms provided by middleware (COM and CORBA) for this purpose.” http://(...)/specifcations/persistence-common-interface-specifcation/

• Error handling “Error Handling defnes how to manage execution errors (abnormal termi- nations). When a request is made, if this request is successful it raises no error, otherwise it raises an error. When an error occurs, the execution is immediately aborted. This Error Handling interface gives a classifcation and a hierarchy of potential errors occurring in CAPE-OPEN compliant components. All CAPE-OPEN components must implement it.” http://(...)/specifcations/error-handling-common-interface-specifcation/

• Parameter “Defnes a standard access to component parameters. This specifcation is used by CAPE-OPEN components wishing to expose some of their internal data to their clients. The interface is made up of two diferent parts, each corresponding to a diferent client need: the frst part is a fxed, static aspect that describes the Parameter, such as a type, name, description, dimensionality etc. The second part deals with value of the parameter itself. It is expected that the parameter values will change quite frequently both within and outside of the component that needs it.” http://(...)/specifcations/parameter-common-interface-specifcation/

• Identifcation “Identifcation interface provides the means for all CAPE-OPEN software components to be identifed by name and textual description. All CAPE- OPEN software components must implement it.” http://(...)/specifcations/identifcation-common-interface-specifcation/

• Collection “The Collection Common interface defnes a standard way of managing

187 Appendix A CAPE-OPEN Interfaces

collections of items. The aim of the Collection Common interface is to give a CAPE-OPEN software component the possibility to expose a list of objects to any client of the component. The client will not be able to modify the collection, i.e. removing, replacing or adding elements. However, since the client will have access to any CAPE-OPEN interface exposed by the items of the collection, it will be able to modify the state of any element.” http://(...)/specifcations/collection-common-interfaces-specifcation/

• Utilities “The Utilities Common Interface specifcation gathers a number of useful functionalities that can be requested from process modelling components. This interface provides the means to set the simulation context, to collect component parameters, to manage lifecycle of components (creation and termination) and to edit, that is, to open a Graphical User Interface for the component.” http://(...)/specifcations/utilities-common-interface-specifcation/

• Simulation context specifcation “The COSE (CAPE-OPEN Simulation Environment) Interfaces or PME Interfaces are horizontal interface specifcations. They defne services provided by CAPE-OPEN compliant PMEs. Services of general use are defned, such as diagnostics and Material Template system in order to be called by any CAPE-OPEN PMC using a callback pattern. The Diagnostic interface allows communication of verbose information from the PMC to the PME (and hence to the user). PMCs should be able to log or display information to the user while executing a fowsheet The Material Template interface provides the mechanisms for accessing CAPE-OPEN Property Packages managed by the COSE, in order to allow PMCs to directly choose and confgure material objects as needed. The COSE Utilities provide a small list of other useful functions. This document results from polishing the document issued by the Global CAPE- OPEN project.” http://(...)/cose-simulation-context-common-interface-specifcation/

188 Appendix B

Export Editor Manual

B.1 Introduction

The Unit Export Editor has the same base structure as all the other editors in the modeling and simulation part of MOSAICmodeling:

• The top most element of the export editor’s user interface is the fle panel with its buttons for Open, Search, New, Save, and Save As.

• Below the fle panel the upper area of the editor’s main part contains the three panels with the element’s meta information, i.e. Description, Keywords, and Usages. As these panels can be found in all the other editors, further descriptions of these are omitted here.

• The lower area of the main editor part contains the panels related to the content of the element. In this case the information is split into the three sections Unit Model, Unit Properties, and Options & Creation.

When saving a unit operation export with this editor, the stored element gets a mosuop (mos - MOSAIC, uop - unit operation) fle extension. This element contains all the settings made in the three content sections described in the following. It does explicitly not contain any dll, executable, or installer fle, but only the information necessary for code creation (remember: MOSAICmodeling is a modelling and code generation tool, not a dedicated simulator).

B.2 Unit Model

In the section Unit Model (see Fig. B.1 on page 191) the user has the only option to load a previously created simulation. This is done by using the available buttons Search or Select. When a simulation has been loaded into the Unit Export

189 Appendix B Export Editor Manual

Editor, the text feld next to the Evaluation label displays ID and name of the MOSAICmodeling simulation element (respective fle extension: moseva). The button Reload next to the search button will update the GUI by freshly loading the current evaluation from the database again. The simulation’s information is displayed in analogy to the simulation editor. The tab Generic Unit corresponds to the tab Generic System in the simulation editor. The equation system with its hierarchy, generic equations, generic Functions, and fowsheet sections is accessible for review. The tabs Indexing and Instantiated Unit correspond to Indexing and Instantiated System in the simulation editor. In contrast to the simulation editor the Indexing section of the Unit Export Editor is read- only, the instantiation view behaves exactly as known from the simulation editor (read-only per defnition, as it is no more than a convenient visualization of the combined content of the two previous tabs). Any manipulations regarding equation system and indexing/simulation have to take place in the equation system and simulation editor, respectively.

190 B.2 Unit Model showing the model as it is adopted from the loaded simulation (MOSAICmodeling GUI Unit Export Editor Evaluation) Figure B.1:

191 Appendix B Export Editor Manual

B.3 Unit Properties

The section Unit Properties is divided into three areas:

• Variables / Fixed Parameters

• Adjustable Parameters

• Open Ports

In each of these sections existing information coming from the loaded simulation can be reviewed.

B.3.1 Variables / Fixed Parameters

In section Variables / Fixed Parameters (Fig. B.2) the Variable Specifcation List defning the values for the iteration and design variables as well as fxed parameters is displayed. Initially the values (not the specifcation list itself) are adopted from the underlying simulation, but it is recommended to save an own specifcation list specifc to this editor. In the sub tab Iteration and Design the value of the design variables as well as value, lower bound, and upper bound of the iteration variables can be changed. The Import Values button allows to load values from Variable Specifcation Lists or appropriately formatted simulation results. It is also possible to change the set of design and iteration variables by using the arrow buttons, as long as in the end the degree of freedom is zero again. In the sub tab Fixed Parameters and Calculated Variables (Fig. B.3) the unit’s fxed parameters are listed on the left hand side. If the only parameters added to an equation system are the public parameters of the unit operation, this table of private/fxed parameters will be empty. In case a parameter meant to be public is listed here, the classifcation of the parameter has to be changed in the simulation editor to ADJUSTABLE. On the right hand side of this tab the calculated variables of the simulation are listed in a table. This table is read- only. Any changes to variables calculated by functions have to take place in the modelling and simulation part of MOSAICmodeling.

B.3.2 Adjustable Parameters

In section Adjustable Parameters (Fig. B.4 on page 195) the adjustable parameters are listed as defned in the model and the simulation. In contrast to the

192 B.3 Unit Properties

Figure B.2: Unit Export Editor GUI showing the iteration variables and design variables adopted from the underlying unit operation simulation

193 Appendix B Export Editor Manual

Figure B.3: The Unit Export Editor GUI shows the fxed parameters and calculated variables adopted from the underlying unit operation simulation. The values of the fxed parameters can be changed.

194 B.3 Unit Properties shows the adjustable parameters adopted from the underlying unit operation GUI Unit Export Editor simulation. The bounds as well as the description can be complemented here. Figure B.4: The

195 Appendix B Export Editor Manual parameter specifcation in the simulation editor, the value is now called Default and lower bound as well as upper bound can now be specifed. These bounds directly infuence the range of values the user of the exported unit operation will be allowed to enter in the fowsheet environment. If the user does not explicitly specify a value for the public parameter, the default value is used. Besides the parameter values the user interface of the Adjustable Parameters section allows to set the direction of the parameter (in or out) and add a description. The direction “in” indicates that the parameter has to be read before the simulation is executed, whereas “out” could be applied for parameters that are calculated during simulation and displayed for information purposes (without being handed over in a stream). At the time writing this manual, the concept of public parameters as implemented in MOSAICmodeling does only make sense with direction “in”. The description may help the user in the fowsheet simulator to determine the exact meaning of the parameters and which public parameter to adjust in order to achieve the goals of the fowsheet simulation.

B.3.3 Open Ports

In section Open Ports (Fig. B.5 on page 197) the open ports of the loaded unit operation model are displayed. The information already known from the simulation includes id, name, and direction. Additional felds shown in the user interface are Description and Type. The (optional) description can be used to complement the port’s name with additional relevant information for documentation purposes. The port type is currently restricted to “MATERIAL”, therefore automatically containing variables for total fow, pressure, temperature, and composition. In future work this may be extended to also allow “ENERGY” (for variables with engineering units of type energy) and “INFORMATION” (including variables of arbitrary engineering unit).

196 B.3 Unit Properties showing the open ports of the currently loaded unit operation GUI Unit Export Editor Figure B.5:

197 Appendix B Export Editor Manual

B.4 Options and Creation

The section Options and Creation is divided into two areas,

• Code Generation and

• Server.

B.4.1 Code Generation

In section Code Generation the language specifcators generating all the single code fles of the unit operation are loaded (Fig. B.6). Using the Add LangSpec button one or many language specifcators can be chosen from the library to be added to the table of language specifcators available for this unit operation’s code generation. With the Search button a single language specifcator can be added when its ID is known. Each row in the table of available language specifcators has the option to be explictly selected. Only those language specifcators are marked as selected in the table will actually be used for code generation. The un- selected language specifcators are kept in the table to be able to quickly change the confguration of the unit operation, e.g. when changing between code generation for 32-bit and 64-bit. Highlighted language specifcators can be deleted from this table by using the Remove button. For convenience reasons the buttons Select All and Unselect All have been added to quickly change the status of all language specifcators listed in the table at once. At the time this manual is written, a set of recommended language specifcators is stored in the library in a folder called “CAPE OPEN Wizard”. The language specifcators necessary to create a standard set of source, header, and resource fles to compose a C++ CO Unit Operation are located in subfolders . The language specifcator in the folder CMake helps creating a MS Visual Studio project, whereas the fles in the folder Windows Installer create fles of type “wxs” (Windows Installer XML) for a unit operation installer either for 32-bit or for 64-bit fowsheet simulators. It is recommended to add all fles of the “CAPE OPEN Wizard” folder to the table of available language specifcators and explicitly select the language specifcator for either 32-bit or 64-bit. On the right hand side of the Code Generation tab a table list the union of all options found in all available language specifcators. When loading the language specifcators for the frst time, the default values defned in the language specifcators are used to set the property values. The user of course can modify

198 B.4 Options and Creation button creates code locally Generate Code shows the code generation panel. Language Specifcators can GUI buttons send code to the server in order to build a unit operation and pack it in Unit Export Editor Create Unit be loaded and respective code generation options can be set. The whereas the an installer for a later download. Figure B.6: The screenshot of the

199 Appendix B Export Editor Manual all these values and save the settings. As soon as the unit export is saved once, the property values are restored according to the saved unit export. Typical properties that will occur in basically all unit operations are

• GUIDs,

• model information,

• solver options, and

• meta information.

The globally unique identifers (GUIDs) uniquely defne this unit operation, and allow version management of the same unit operation. The model information includes the name of the model as it will be displayed in the unit operation selection dialog in the fowsheet environment and the description shown along- side. The unit operation name is used to name the installer fle. In case of the example shown in fgure B.6 on page 199 the installer fle is named “TwoCom- poundColumnMUnit” whereas the model’s name is the slightly shorter “TwoCom- poundColumnM”. Solver options may include the solution strategy. In the given example for sundials KINSOL the three values available to choose are KIN_LINESEARCH, KIN_NONE, and KIN_FP. In order to understand the meaning of those options the KINSOL manual has to be consulted. The sundials installation path listed as a property in the example is relevant for local code generation, as it is up to the user where the sundials libraries are located on the computer. The version of the unit operation and information related to the vendor belongs to the meta information and can be adjusted as desired. Whenever a row in the table of properties is selected, the table below lists the language specifcators this property is used in. The model name for example is used in fve diferent fles: two source fles, two header fles, and the wxs fle of the windows installer.

On the left hand side below the buttons related to the table of available language specifcators new UUIDs (Universally Unique Identifer, synonym to GUID) can be generated by pressing the button generate GUID. The GUID is a long random number displayed in the respective text feld. When the text feld is non-empty, the buttons Set AppGUID, Set Class GUID, and Set Version GUID can be used to copy the text feld’s GUID to the value column of the

200 B.4 Options and Creation respective property in the options table.

In the lower left corner of the Code Generation tab the actual code generation can be triggered. For local code generation the target folder can be selected via the Choose Location button. With “Generate Code ...” the simulation and the selected language specifcators are evaluated and fles are generated in the chosen target folder. The checkboxes besides the code generation button ofer additional options for the local code generation. Per default a folder with the unit operation name of the options table is created inside the selected target location. When the checkbox Create in Source is selected, an additional subfolder called “source” is created and the code is automatically moved into this source folder. The second checkbox, reading Create Build folder adds a folder named “Build” on the same level the source folder would be created. In casae of the build folder no code fles are moved. The source folder as well as the build folder are a good preparation for the following local compilation and linking steps, e.g. performed with MS Visual Studio. The two remaining buttons, Create 32-bit Unit and Create 64-bit Unit, both start background routines that create not only the fles specifed by the language specifcators, but also directly a Windows Installer fle including the compiled CO Unit Operation DLL fle, either for 32-bit or 64-bit fowsheet environments. When using the 32-bit button, the respective 32-bit wxs fle must be selected in the table of available language specifcators. The same holds for the 64-bit button, respectively. After code submission to the server the view automatically changes to the next tab (Server).

B.4.2 Server

In section Server (see Fig. B.7 on page 203) all unit operations are displayed that have been created on the server by the user currently logged in and that are available to this user. The table contains fve columns:

1. Guid represents the unit operation’s UUID.

2. Status is an integer number indicating the progress during creation as well as the return value in case the creation is fnished or aborted. It starts with a value of 5 and counts down by one with each creation step. When the status becomes 1, the unit operation installer has successfully been created and will be available for download. In case an error occured, the status

201 Appendix B Export Editor Manual

number becomes negative. The closer to zero, the later the error occured. The column “Message” will contain more specifc information regarding the status. See table B.1 for a detailed listing.

3. Bit indicates if this row belongs to a 32-bit or a 64-bit unit operation.

4. Message gives additional information to the current status. When the creation was successfull, it contains the URL where the unit operation can be downloaded from. In case an error occured, it gives an information in which step of the creation process the procedure aborted. See table B.1 for a detailed listing.

5. Timestamp indicates when the creation of the unit operation was started.

As this is an asynchronous process, it is no problem to continue working with MOSAICmodeling while the server creates the unit operation installer fle. The Refresh button updates the table to get the current status of the creation process, there is no automatic refresh initiated by the server. It takes up to two minutes, in average one minute, to create the unit operation installer for the column example (approximately 450 equations). The button Save File downloads the windows installer fle of the unit operation export that is selected in the table. This does only work if the creation was successful and the status is set to 1. The text feld below the table always shows the message of the selected row. This makes it easier to copy the URL of the successfully created unit operation installer. One way to hand the unit operation over to colleagues or collaboration partners is by sending them this link, e.g. via email. Entering this link in a browser will enable a download without using the MOSAICmodeling GUI.

202 B.4 Options and Creation button donwloads the selected unit operation installer fle to a Save File showing the unit operations of the user currently logged in that have been send GUI Unit Export Editor to the server for creation. The location specifed by the user. Figure B.7:

203 Appendix B Export Editor Manual

Table B.1: Server creation status and meaning Status Meaning The compressed, generated code fles have been written 5 to the server and are waiting to be read and processed. The code fles have been received and handed over to the 4 read process for further processing. The reader on the server has created the necessary 3 folder structure and moved the decompressed source fles to the appropriate locations. The unit operation maker has been called to process the fles 2 and create the unit operation installer fle. The unit operation installer was created successfully and 1 is available for download. -1 An error occured creating the msi fle (light.exe). -2 An error occured creating the wxs object (candle.exe). -4 Building the dll failed (msbuild.exe) -5 Project confguration incomplete (cmake.exe)

204 Appendix C

XML Schemas

All schema fles of the MOSAICmodeling model elements are listed online and are directly accessible via the following URL: mosaic.service.tu-berlin.de/mosaic/public/papers/dissertation/tolksdorf/xsd/ The schema fles have basically been designed according to the venetian blind styling rule.

MOSAICmodeling model elements:

• connector.xsd

• engineering_unit.xsd

• eq_system.xsd

• equation.xsd

• evaluation.xsd

• interface.xsd

• notation.xsd

• optimization.xsd

• parameterlist.xsd

• transformation.xsd

• UDLS.xsd

• unit_operation.xsd

• unit_set.xsd

205 Appendix C XML Schemas

• variablespecifcation.xsd

Re-used (i.e. referenced in the above elements) types and enumerations:

• direction_enum.xsd

• index_directive_type.xsd

• location_string_type.xsd

• namespace_type.xsd

• port_type_enum.xsd

206 Appendix D

Database Tables

This section lists Structured Query Language (SQL) statements to create the database tables afected and newly created during the work on this thesis. The table unitOperationExchange is the direct connection point between the MO- SAICmodeling database and the scripts creating the CO Unit Operation installer fles on the dedicated MS Windows server. See chapter 4.2 for a detailed explanation.

Listing D.1: unitOperationExchange.sql CREATE TABLE ‘unitOperationExchange‘ ( ‘userId‘ smallint(6) NOT NULL, ‘guid‘ char(36) CHARACTER SET utf8 NOT NULL, ‘status‘ tinyint (4) NOT NULL, ‘bit‘ tinyint (2) NOT NULL DEFAULT ’64’ COMMENT ’feld␣indicating␣if␣ the␣unit␣operation␣is␣a␣32␣or␣64␣bit␣dll’, ‘message‘ text CHARACTER SET utf8 NOT NULL, ‘content‘ longblob COMMENT ’column␣to␣store␣the␣zipped␣source␣fles’, ‘ ts ‘ timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (‘userId‘,‘guid‘,‘bit‘) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; The database table related to the analysis feature (analyser) was split up into several smaller database tables in order to support analysis of larger equation systems. The structure of the old table as well as the new tables are listed here. The explanation for this changes can be found in section 4.3.

Listing D.2: old-analyser.sql CREATE TABLE ‘analyser‘ ( ‘idUser‘ int(11) NOT NULL, ‘status‘ varchar(10) NOT NULL,

207 Appendix D Database Tables

‘code‘ longtext NOT NULL COMMENT ’Code,␣which␣will␣be␣executed␣on␣the ␣server’, ‘row‘ longtext COMMENT ’row␣vector␣of␣the␣incidence␣matrix’, ‘ col ‘ longtext COMMENT ’column␣vector␣of␣the␣incidence␣matrix’, ‘ val ‘ longtext COMMENT ’value␣vector␣of␣the␣incidence␣matrix’, ‘rowP‘ longtext COMMENT ’row␣permuation’, ‘colQ‘ longtext COMMENT ’column␣permuation’, ‘ info ‘ longtext COMMENT ’info␣vector␣of␣the␣decomposition’, ‘rowPointer‘ longtext COMMENT ’row␣pointer␣for␣the␣subsystems’, ‘ colPointer ‘ longtext COMMENT ’column␣pointer␣for␣the␣subsystem’, ‘bbtRowP‘ longtext, ‘bbtColQ‘ longtext, ‘PCA‘ longtext, ‘ ts ‘ timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (‘idUser‘) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Listing D.3: new-analyserBlock.sql CREATE TABLE ‘analyserBlock‘ ( ‘idUser‘ int(5) NOT NULL, ‘idEvaluation‘ int(10) NOT NULL, ‘rowP‘ longtext, ‘colQ‘ longtext, ‘ info ‘ longtext, ‘rowPointer‘ longtext, ‘ colPointer ‘ longtext, ‘ ts ‘ timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (‘idUser‘,‘idEvaluation‘) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Listing D.4: new-analyserBorderedAndPCA.sql CREATE TABLE ‘analyserBorderedAndPCA‘ ( ‘idUser‘ int(5) NOT NULL, ‘idEvaluation‘ int(10) NOT NULL, ‘bbtRowP‘ longtext, ‘bbtColQ‘ longtext, ‘PCA‘ longtext, ‘ ts ‘ timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (‘idUser‘,‘idEvaluation‘) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

208 Listing D.5: new-analyserCode.sql CREATE TABLE ‘analyserCode‘ ( ‘idUser‘ int(5) NOT NULL, ‘status‘ varchar(10) NOT NULL, ‘idEvaluation‘ int(10) NOT NULL, ‘code‘ longtext, ‘ ts ‘ timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (‘idUser‘,‘idEvaluation‘) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Listing D.6: new-analyserIncidence.sql CREATE TABLE ‘analyserIncidence‘ ( ‘idUser‘ int(5) NOT NULL, ‘idEvaluation‘ int(10) NOT NULL, ‘row‘ longtext, ‘ col ‘ longtext, ‘ val ‘ longtext, ‘ ts ‘ timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (‘idUser‘,‘idEvaluation‘) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

209

Appendix E

UML Class Diagrams of MOSAICmodeling Elements

In this appendix the UML class diagrams of the new elements introduced to MOSAICmodeling in the course of this thesis are listed. This list comprises

• the Optimization (mosopt, Fig. E.1),

• the Engineering Unit (moseng, Fig. E.2),

• the Engineering Unit Set (mosust, Fig. E.2), and

• the Unit Operation (mosuop, Fig. E.3).

UML diagrams of the previously existing model elements can be found in the works of Kuntsche (Kuntsche, 2013) and Kraus (Kraus, 2015).

211 Appendix E UML Class Diagrams of MOSAICmodeling Elements

Optimization

+ description: String + evaluation: Evaluation + initialSpecification: ShortcutSpecificationList + parameterSpecification: ShortcutSpecificationList + paramSpecLocation: LocationString + resultList: ShortcutSpecificationList + languageSpec: LanguageSpecificator + userProperties: Map> + neosSpecification: String[]

LanguageSpecificator

ShortcutSpecificationList

Evaluation

Figure E.1: UML class diagram of the optimization element with connections to other MOSAICmodeling elements

212 EngineeringUnitSet

+ description: String + engineUnits: Collection

EngineeringUnit

+ identifier: String + name: String + description: String + conversionToSI: String + conversionFromSI: String + dimension: EngineeringDimension + relativeQuantity: boolean

EngineeringDimension

+ description: String + familyName: String + dimensionExponents: Rational[]

Figure E.2: UML class diagram of the EngineeringUnit, EngineeringUnitSet, and EngineeringDimension elements

213 Appendix E UML Class Diagrams of MOSAICmodeling Elements

UnitOperation

+ description: String + evaluation: Evaluation + initialSpecification: ShortcutSpecificationList + parameterSpecification: List + unitLanguageSpecElements: List + langSpecChosenOptions: Properties + openPorts: List

PortSpecificationElement

+ description: String + port: ExternalPortImplementation + type: UnitPortType

LangSpecSelectionElement

+ langSpec: LanguageSpecificator + selected: boolean

UnitParameterSpecificationElement

+ description: String + parameter: Parameter + direction: PortDirection

ShortcutSpecificationList

Evaluation

Figure E.3: UML class diagram of the UnitOperation element with connections to other MOSAICmodeling elements

214 Appendix F

Full Documentation of Example Models

Here the full models of the examples described in chapter 5 are listed. All model documentations were created automatically with the documentation editor of MOSAICmodeling. The comparatively large public notation applied in the examples has been moved into a separate subsection (section F.5) in order to avoid unnecessary repetition of the same information.

F.1 CAPE-OPEN Membrane

Evaluation ’43890: eva_membrane_separation_without_h.moseva’

Description: Membrane Separation Example. All feed quantities given. No total fow equation. Equation System: 43887: unit_membrane_separation_without_h.moseqs IndexSpecifcation: e[0]43887.NC = 2 e[0]43887>p[3](out) ’retentate_port’.NC = 2 e[0]43887>p[2](out) ’permeate_port’.NC = 2 e[0]43887>p[1](in) ’feed_port’.NC = 2

Variable Specifcation: 43889: var_membrane_separation_without_h_initial.mosvar Parameter Specifcation: 42323: var_parameterSpecAlphaTheta.mosvar Results Specifcation: 43932: var_membrane_separation_without_h_solution.mosvar

Equation instances:

215 Appendix F Full Documentation of Example Models

Eq: 43931: equ_component_balance_generic.mosequ (using Nota: 41865: nota_membrane_separation.mosnot). Description: Component balance generic.

e0p1.F · e0p1.xi =1 = e0p3.F · e0p3.xi=1 + e0p2.F · e0p2.xi=1 (F.1)

e0p1.F · e0p1.xi =2 = e0p3.F · e0p3.xi=2 + e0p2.F · e0p2.xi=2 (F.2) Eq: 41870: equ_fow_cut_theta.mosequ (using Nota: 41865: nota_membrane_- separation.mosnot). Description: Flow cut permeate/retentate. Parameter List: 42322: par_alpha_theta.mospar. e0p2.F = e0.θ · e0p3.F (F.3) Eq: 41873: equ_separation_factor_alpha.mosequ (using Nota: 41865: nota_- membrane_separation.mosnot). Description: Separation factor equation. Pa- rameter List: 42322: par_alpha_theta.mospar. e0p2.x e0p3.x e0.α = i=1 · i=2 (F.4) e0p2.xi=2 e0p3.xi=1 Eq: 41867: equ_sum_permeate.mosequ (using Nota: 41865: nota_membrane_- separation.mosnot). Description: Summation condition permeate.

(e0p2.xi=1 + e0p2.xi=2) = 1 (F.5) Eq: 41868: equ_sum_retentate.mosequ (using Nota: 41865: nota_membrane_- separation.mosnot). Description: Summation condition retentate.

(e0p3.xi=1 + e0p3.xi=2) = 1 (F.6) Eq: 43923: equ_temperature_equality.mosequ (using Nota: 41865: nota_- membrane_separation.mosnot). Description: Temperature defnition: output = input. e0p2.T = e0p1.T (F.7) e0p3.T = e0p1.T (F.8) Eq: 43926: equ_pressure_equality.mosequ (using Nota: 41865: nota_membrane_- separation.mosnot). Description: Pressure defnition: output = input. e0p2.p = e0p1.p (F.9) e0p3.p = e0p1.p (F.10)

Variable Specs ’43889: var_membrane_separation_without_h_initial.mosvar’

Design variables

216 F.1 CAPE-OPEN Membrane

e0p1.F = 100.0 e0p1.T = 273.15 e0p1.p = 101350.0

e0p1.xi=1 = 0.85 e0p1.xi=2 = 0.15

Iteration variables

e0p2.F = 37.5 e0p2.T = 273.15 e0p2.p = 100000.0

e0p2.xi=1 = 0.994 e0p2.xi=2 = 0.006 e0p3.F = 62.5 e0p3.T = 273.15 e0p3.p = 100000.0

e0p3.xi=1 = 0.75 e0p3.xi=2 = 0.25

Parameter Specs ’42323: var_parameterSpecAlphaTheta.mosvar’

Paramaters

e0.α = 70.0 e0.θ = 0.6

Results ’43932: var_membrane_separation_without_h_solution.mosvar’

Design variables

e0p1.F = 100.0 e0p1.T = 273.15 e0p1.p = 10000.0

e0p1.xi=1 = 0.85 e0p1.xi=2 = 0.15

217 Appendix F Full Documentation of Example Models

Iteration variables

e0p2.F = 37.49999999998812 e0p2.T = 273.15 e0p2.p = 10000.0

e0p2.xi=1 = 0.9956440127229609 e0p2.xi=2 = 0.0043559872768069 e0p3.F = 62.499999999980204 e0p3.T = 273.15 e0p3.p = 10000.0

e0p3.xi=1 = 0.762613592366531 e0p3.xi=2 = 0.2373864076268297

Notation ’41865: nota_membrane_separation.mosnot’

Base line symbols

F Flow T Temperatur (K) α Separation factor θ Fraction of permeate fow to retentate fow: θ=FˆP/FˆR h Enthalpy p Pressure (Pa) x Flow fraction

Superscripts

F Feed P Permeate R Retentate in Input quantity out Output quantity

Subscripts

et Ethanol wa Water

218 F.1 CAPE-OPEN Membrane

Indices

i 1..NC number of components

219 Appendix F Full Documentation of Example Models

F.2 CAPE-OPEN MixerSplitter

EQ System ’76796: process_MixerSplitter_scaled_with_externalFunctions.moseqs’

Description: ’Unit operation modeling a MixerSplitter system. This unit has to be instantiated with in=2 and out=2 (two inlets and two outlets).’ Notation: ’2951: Public_notation.mosnot’ Connected Elements

• (0) 76795: unit_MixerSplitter_scaled_with_externalFunctions.moseqs Naming policy: streams Used Connector: none

Hierarichal view of contained equations:

Equation System: 76796: process_MixerSplitter_scaled_- with_externalFunctions.moseqs

Description: Unit operation modeling a MixerSplitter system. This unit has to be instantiated with in=2 and out=2 (two inlets and two outlets).

Connected EQ-Systems:

• 76795: unit_MixerSplitter_scaled_with_externalFunctions.moseqs

Connection Level (1) – EQ-Systems connected to 76796: process_MixerSplitter_- scaled_with_externalFunctions.moseqs:

220 F.2 CAPE-OPEN MixerSplitter

Equation System: 76795: unit_MixerSplitter_scaled_with_- externalFunctions.moseqs

Description: Unit operation modeling a MixerSplitter system. This unit has to be instantiated with in=2 and out=2 (two inlets and two outlets).

Connected EQ-Systems:

• 76785: eqs_MixerSplitter_scaled_with_externalFunctions.moseqs

Connection Level (2) – EQ-Systems connected to 76795: unit_MixerSplitter_- scaled_with_externalFunctions.moseqs:

Equation System: 76785: eqs_MixerSplitter_scaled_with_- externalFunctions.moseqs

Description: MixerSplitter equation system including functions to calculate enthalpy and temperature.

Applied Functions:

• Fun: 51528: CO temperature with phx function.mosfun (using Nota: 20972: PublicNotationT.mosnot) Desc.: Function to calculate the temperature based on enthalpy, pressure and composition.

T = f (h, p, xi) (F.11)

with f = calc. by: CO Calculate Temperatur phx fash applied as T = f(h, p, xi) (F.12)

221 Appendix F Full Documentation of Example Models

• Fun: 42352: fun_enthalpy_general_by_interface.mosfun (using Nota: 20972: PublicNotationT.mosnot) Desc.: Function defned by interface to calculate the enthalpy, given pressure, temperature, and composition n h = f (T, p, xi) (F.13)

with f = calc. by: applied as hin = f(Tin, pin, xin,i) (F.14)

Connected EQ-Systems:

• 76787: eqs_MixerSplitter_base_scaled.moseqs

Connection Level (3) – EQ-Systems connected to 76785: eqs_MixerSplitter_- scaled_with_externalFunctions.moseqs:

Equation System: 76787: eqs_MixerSplitter_base_- scaled.moseqs

Description: MixerSplitter equation system without any functions.

Connected Equations:

• Eq: 76789: equ_scaled_E_outletFlow_split.mosequ (using Nota: 84474: nota_MixerSplitter.mosnot) Desc.: "Equilibrium" of the outlets. The "splitting factor" b_- out times the overall inlet fow determines the fraction of the outlet fow with index out. Parameter List: 76798: par_scaled_-

222 F.2 CAPE-OPEN MixerSplitter

MixerSplitterParameters.mospar

NIS Fout ∑ Fin = b · (F.15) F sca out F sca in=1

• Eq: 76793: equ_scaled_H_enthalpy_overall.mosequ (using Nota: 84474: nota_MixerSplitter.mosnot) Desc.: The overall enthalpy ([J/mol]) is the sum of all inlet enthalpies fows ([J/mol]*[mol/s]) plus the heat duty Q ([J/s]) divided by the overall inlet fows([mol/s]). Parameter List: 76798: par_scaled_- MixerSplitterParameters.mospar

NIS NIS h ∑ Fin Q ∑ hin Fin · = + · (F.16) hsca F sca hsca · F sca hsca F sca in =1 in=1

• Eq: 76788: equ_scaled_M_mole_balance_components.mosequ (using Nota: 84474: nota_MixerSplitter.mosnot) Desc.: Component "mole" balance. In this model it is assumed that there is no reaction and we have a linear depency between mass and mole amount of a stream and component (molar weight). All outlets have the same composition, that’s why we use x_- i instead of x_out,i here. Parameter List: 76798: par_scaled_- MixerSplitterParameters.mospar

NIS NOS ∑ Fin ∑ Fout · x = x · (F.17) F sca in,i i F sca in =1 out=1

• Eq: 76791: equ_scaled_E_outletPressure.mosequ (using Nota: 84474: nota_MixerSplitter.mosnot) Desc.: The outlet pressure has to be equal to the system pressure. Parameter List: 76798: par_scaled_MixerSplitterParameters.mospar p p out = (F.18) psca psca

• Eq: 76790: equ_S_outlet_summation.mosequ (using Nota: 84474: nota_MixerSplitter.mosnot)

223 Appendix F Full Documentation of Example Models

Desc.: The outlet fraction has to be equal to the system fraction. Pa- rameter List: 76798: par_scaled_MixerSplitterParameters.mospar

bout =1 + bout =2 = 1 (F.19)

• Eq: 51390: equ_E_outletFraction.mosequ (using Nota: 84474: nota_MixerSplitter.mosnot) Desc.: The outlet fraction has to be equal to the system fraction.

xout,i = xi (F.20)

• Eq: 76792: equ_scaled_E_outletTemperature.mosequ (using Nota: 84474: nota_MixerSplitter.mosnot) Desc.: The outlet temperature has to be equal to the system temperature. Parameter List: 76798: par_scaled_- MixerSplitterParameters.mospar

T T out = (F.21) T sca T sca

• Eq: 76794: equ_scaled_I_pressure_overall.mosequ (using Nota: 84474: nota_MixerSplitter.mosnot) Desc.: The system pressure in this model is defned by the pressure of the frst inlet. Parameter List: 76798: par_scaled_- MixerSplitterParameters.mospar

p p = in=1 (F.22) psca psca

Notation ’84474: nota_MixerSplitter.mosnot’

Base line symbols

F Flow (mol/s) Q Heating duty (W=J/s) T Temperature (K) b Split factor (-)

224 F.2 CAPE-OPEN MixerSplitter

h Enthalpy (J/mol) p Pressure (Pa) x Molar fraction, liquid (mol/mol)

Superscripts

sca Scaling

Indices

i 1..NC Component index in 1..NIS Inlet stream index out 1..NOS Outlet stream index

225 Appendix F Full Documentation of Example Models

F.2.1 Additional MixerSplitter Screenshots

The two additional screenshots of the MixerSplitter example are taken from the integration into COFE. The frst one (Fig. F.1) shows the result when using the property package provided by ASPEN, the second one (Fig. F.2) uses the so-called TEA property package. Both times the same increased heating duty is applied. The results difer slightly with a resulting temperature diference in stream 3 of roughly 2 Kelvin. The difering property packages must be the cause for this deviation.

Figure F.1: COFE results of the MixerSplitter simulation example with increased heatung duty using ASPEN properties

226 F.2 CAPE-OPEN MixerSplitter simulation example with increased heatung duty using a TEA property MixerSplitter package Figure F.2: COFE results of the

227 Appendix F Full Documentation of Example Models

F.3 CAPE-OPEN TwoCompundColumn

Evaluation ’103860: eva_unit_Column_subcooled_CAPE-OPEN_feed57.moseva’

Description: Evaluation of the CAPE-OPEN equation system modelling a (binary?) column using fugacity coefcients for the equilibria. All physical properties are calculated via CAPE-OPEN interfaces. Equation System: 103857: unit_Column_subcooled_CAPE-OPEN.moseqs IndexSpecifcation: e[0]103857.NC = 2 e[0]103857>p[1](in) ’Feed’.NC = 2 e[0]103857>e[0]103856>e[2]103850.NC = 2 e[0]103857.NTR = 35 e[0]103857>e[0]103856>e[1]103677.NC = 2 e[0]103857>p[2](out) ’Distillate’.NC = 2 e[0]103857>p[3](out) ’Bottom’.NC = 2

Variable Specifcation: 103859: Initial values subcooled CAPE-OPEN column (Feed 57).mosvar Parameter Specifcation: 103858: Adjustable Parameters CAPE-OPEN.mosvar Results Specifcation: none.

Hierarchical view of equations:

Equation System: 103857: unit_Column_subcooled_CAPE- OPEN.moseqs

Description: Complete column with partial reboiler (encapsulated) and total condenser (encapsulated) models. The functions calculating physical properties have been separated inside the subsystems. The feed system has been reduced to only calculate the feed enthalpy. Ports are added here to make this a unit operation. -Equilibrium constants are based on fugacity coefcients: phiL/phiV

228 F.3 CAPE-OPEN TwoCompundColumn

Assumptions: -Constant pressure drop -adiabatic and steady-working column -No excess enthalpies

Connected EQ-Systems:

• 103856: eqs_Column_subcooled_CAPE-OPEN.moseqs

Connection Level (1) – EQ-Systems connected to 103857: unit_Column_- subcooled_CAPE-OPEN.moseqs:

Equation System: 103856: eqs_Column_subcooled_CAPE- OPEN.moseqs

Description: Complete column with partial reboiler (encapsulated) and total condenser (subcooled, encapsulated) model. The functions calculating physical properties have been separated inside the subsystems.

-Equilibrium constants are based on fugacity coefcients: phi_L/phi_V -The molar specifc enthalpies at system temperature are calculated via CAPE-OPEN function call -The molar enthalpies are calculated via CAPE-OPEN function call

Assumptions: -Constant pressure drop -adiabatic and steady-working column -No excess enthalpies

Connected EQ-Systems:

• 103850: Partial Reboiler CAPE-OPEN.moseqs

229 Appendix F Full Documentation of Example Models

• 103677: Total Condenser subcooled CAPE-OPEN.moseqs

• 103473: Feed reduced CAPE-OPEN.moseqs

• 103855: Trays CAPE-OPEN.moseqs

Connection Level (2) – EQ-Systems connected to 103856: eqs_Column_- subcooled_CAPE-OPEN.moseqs:

Equation System: 103850: Partial Reboiler CAPE- OPEN.moseqs

Description: Equation system to calculate reboiler conditions with the use of following functions: -CAPE-OPEN for fugacity coefcients and enthalpy

Applied Functions:

• Fun: 47428: General equilibrium constant.mosfun (using Nota: 2951: Public_notation.mosnot) Desc.: Calculation of equilibrium in [1] For Raoults law: A=Component’s vapor pressure B= system pressure For Equations of state: A=component’s fugacy coefcient in a mixture of liquid phase B= component’s fugacy coefcient in a mixture of vapor phase Uses Param List: 7930: Public_parameter_functions.mospar

K = f (A, B) (F.23)

with A f = (F.24) B applied as B L V Ki = f(φi , φi ) (F.25)

230 F.3 CAPE-OPEN TwoCompundColumn

• Fun: 103517: fun_fugacityCoefcient_vapor.mosfun (using Nota: 20972: PublicNotationT.mosnot) Desc.: Function to calculate the fugacity coefcient of the vapor phase, given temperature, pressure, and composition. V φi = f (T, p, zi) (F.26)

with f = calc. by: applied as V B B B,in φi = f(T , p , xi ) (F.27)

• Fun: 103457: fun_equilibrium_enthalpy.mosfun (using Nota: 20972: PublicNotationT.mosnot) Desc.: Function defned by interface to calculate the enthalpy, given pressure, temperature, and composition n h = f (T, p, xi) (F.28)

with f = calc. by: applied as B,L,cal,n B B B h = f(T , p , xi ) (F.29)

B,V,cal,n B B B h = f(T , p , yi ) (F.30)

• Fun: 103518: fun_fugacityCoefcient_liquid.mosfun (using Nota: 20972: PublicNotationT.mosnot) Desc.: Function to calculate the fugacity coefcient of the liquid phase, given temperature, pressure, and composition. L φi = f (T, p, zi) (F.31)

with f = calc. by: applied as L B B B,in φi = f(T , p , xi ) (F.32)

Connected EQ-Systems:

• 103832: Partial Reboiler Functions CAPE-OPEN.moseqs

• 103251: Partial Reboiler no Functions.moseqs

231 Appendix F Full Documentation of Example Models

Connection Level (3) – EQ-Systems connected to 103850: Partial Reboiler CAPE-OPEN.moseqs:

Equation System: 103832: Partial Reboiler Functions CAPE- OPEN.moseqs

Description: Calculate reboiler conditions with the use of following functions: -CAPE-OPEN for enthalpies and fugacity coefcients

Connected Equations:

• Eq: 103845: equ_Molar specifc vapor enthalpy calculated.mosequ (using Nota: 2951: Public_notation.mosnot) Desc.: Molar specifc enthalpies of the liquid phase in J/kmol

hB,V,n = hB,V,cal,n (F.33)

• Eq: 103843: equ_Molar specifc liquid enthalpy calculated.mosequ (using Nota: 2951: Public_notation.mosnot) Desc.: Molar specifc enthalpies of the liquid phase in J/kmol

hB,L,n = hB,L,cal,n (F.34)

Equation System: 103251: Partial Reboiler no Functions.moseqs

Description: Equation system to calculate reboiler conditions with the use of following functions: -DIPPR-functions for molar specifc enthalpies and vapor pressure calculations -Function for equilibrium constant calculatations based on Raoult’s law

Connected EQ-Systems:

232 F.3 CAPE-OPEN TwoCompundColumn

• 47548: Basic partial reboiler.moseqs

Connection Level (4) – EQ-Systems connected to 103251: Partial Reboiler no Functions.moseqs:

Equation System: 47548: Basic partial reboiler.moseqs

Description: Basic partial reboiler model Calculation units: Flows: [kmol/s] Enthalpies: [kJ/kmol] Assumption: -No excess enthalpies

Connected Equations:

• Eq: 47525: Heat balance.mosequ (using Nota: 2951: Public_- notation.mosnot) Desc.: Heat balance of a steady-working partial reboiler in [kW]

0 = F L,B,in,n · hL,B,in,n − F V,B,n (F.35) · hV,B,n − F L,B,n · hL,B,n + QB

• Eq: 47524: General equilibrium constant liquid vapor phase.mosequ (using Nota: 2951: Public_notation.mosnot) Desc.: Equilibrium constant calculations based on iso-fugacy criterion. K-values can be adjusted in dependence on the used excess model, the real fuid behavior is described with . Equation dimension in [1] Parameter List: 44098: SRK_Parameters.mospar

B B yi Ki = B (F.36) xi

• Eq: 47551: Molar component balances.mosequ (using Nota: 2951: Public_notation.mosnot)

233 Appendix F Full Documentation of Example Models

Desc.: Steady molar component balance of partial reboiler in [kmol/s] Parameter List: 7930: Public_parameter_functions.mospar

L,B,n,in B,in V,B,n B L,B,n B 0 = F · xi − F · yi − F · xi (F.37)

• Eq: 47528: Molar summation relation vapor phase.mosequ (using Nota: 2951: Public_notation.mosnot) Desc.: Summation relation for vapor stream [1] Parameter List: 7930: Public_parameter_functions.mospar

NC ∑ B 1 = yi (F.38) i=1

• Eq: 47527: Molar summation relation liquid phase.mosequ (using Nota: 2951: Public_notation.mosnot) Desc.: Summation relation for liquid stream [1] Parameter List: 7930: Public_parameter_functions.mospar

NC ∑ B 1 = xi (F.39) i=1

Equation System: 103677: Total Condenser subcooled CAPE- OPEN.moseqs

Description: Equation system to calculate the total condenser conditions with the use of following functions: -DIPPR-functions for molar specifc enthalpies and vapor pressure calculations -Function for equilibrium constant calculatations based on Raoult’s law

Applied Functions:

234 F.3 CAPE-OPEN TwoCompundColumn

Equations of state: A=component’s fugacy coefcient in a mixture of liquid phase B= component’s fugacy coefcient in a mixture of vapor phase Uses Param List: 7930: Public_parameter_functions.mospar

K = f (A, B) (F.40)

with A f = (F.41) B

applied as D L V Ki = f(φi , φi ) (F.42)

with f = calc. by: applied as V D D D,in φi = f(T , p , yi ) (F.44)

n h = f (T, p, xi) (F.45)

with f = calc. by: applied as D,L,cal,n out D D h = f(T , p , xi ) (F.46)

235 Appendix F Full Documentation of Example Models

with f = calc. by: applied as L D D D,in φi = f(T , p , yi ) (F.48)

Connected EQ-Systems:

• 103652: Total Condenser no Functions subcooled.moseqs

• 103678: Total Condenser Functions CAPE-OPEN (subcooled).moseqs

Connection Level (3) – EQ-Systems connected to 103677: Total Condenser subcooled CAPE-OPEN.moseqs:

Equation System: 103652: Total Condenser no Functions subcooled.moseqs

Description: Equation system to calculate the total condenser conditions.

Connected Equations:

• Eq: 103653: equ_temperatureDiferenceSubcooled.mosequ (using Nota: 2951: Public_notation.mosnot) Desc.: Temperature diference equation for the distillate. Parameter

236 F.3 CAPE-OPEN TwoCompundColumn

List: 103375: par_deisobutanizer.mospar

T out = T D − ∆T (F.49)

Connected EQ-Systems:

• 47504: Basic total condenser.moseqs

Connection Level (4) – EQ-Systems connected to 103652: Total Condenser no Functions subcooled.moseqs:

Equation System: 47504: Basic total condenser.moseqs

Description: Total condenser model Calculation units: Flows: [kmol/s] Enthalpies: [kJ/kmol] Assumption: -No excess enthalpies

Connected Equations:

• Eq: 47480: Molar summation relation vapor phase.mosequ (using Nota: 2951: Public_notation.mosnot) Desc.: Summation relation for vapor phase referring to condensate [1] Parameter List: 7930: Public_parameter_functions.mospar

NC ∑ D 1 = yi (F.50) i=1

• Eq: 47479: Molar summation relation liquid phase.mosequ (using Nota: 2951: Public_notation.mosnot) Desc.: Summation relation for liquid stream [1] Parameter List: 7930:

237 Appendix F Full Documentation of Example Models

Public_parameter_functions.mospar

NC ∑ D 1 = xi (F.51) i=1

• Eq: 47477: Molar component balances.mosequ (using Nota: 2951: Public_notation.mosnot) Desc.: Steady molar component balances of a total condenser in [kmol/s] Parameter List: 7930: Public_parameter_functions.mospar

V,D,in,n D,in Reflux,L,D,n L,D,n D 0 = F · yi − (F + F ) · xi (F.52)

• Eq: 47478: Molar refux ratio.mosequ (using Nota: 2951: Public_- notation.mosnot) Desc.: Refux ratio in [1] Parameter List: 7930: Public_parameter_- functions.mospar

RD · (F V,D,in,n − F Reflux,L,D,n) = F Reflux,L,D,n (F.53)

• Eq: 47476: Heat balance.mosequ (using Nota: 2951: Public_- notation.mosnot) Desc.: Heat balance of a steady-working total condenser in [kW] (con- densation heat >=0)

0 = F V,D,in,n · (hV,D,in,n − hL,D,n) − QD (F.54)

• Eq: 47475: General equilibrium constant liquid vapor phasae.mosequ (using Nota: 2951: Public_notation.mosnot) Desc.: General equation to describe the two phase equilibrium in [1] Parameter List: 44098: SRK_Parameters.mospar

D D yi Ki = D (F.55) xi

238 F.3 CAPE-OPEN TwoCompundColumn

Equation System: 103678: Total Condenser Functions CAPE- OPEN (subcooled).moseqs

Description: Equation system for the total condenser thermo calculations.

Connected Equations:

• Eq: 103679: equ_Molar specifc enthalpy calculated.mosequ (using Nota: 2951: Public_notation.mosnot) Desc.: Molar specifc enthalpies of the liquid phase in J/kmol

hD,L,n = hD,L,cal,n (F.56)

Equation System: 103473: Feed reduced CAPE-OPEN.moseqs

Description: Functions and equations for calculating equilibrium molar specifc enthalpy.

Connected Equations:

• Eq: 103483: equ_Molar specifc enthalpy calculated.mosequ (using Nota: 2951: Public_notation.mosnot) Desc.: Molar specifc enthalpies of the liquid phase in J/kmol

hL,f,n = hL,cal,f,n (F.57)

Equation System: 103855: Trays CAPE-OPEN.moseqs

Description: Equation system for the deisobutanizer trays. Properties are calculated via CAPE-OPEN interface: enthalpies, fugacity coefcents

239 Appendix F Full Documentation of Example Models

Connected EQ-Systems:

• 103851: Trays Functions CAPE-OPEN.moseqs

• 103236: Trays no Functions.moseqs

Connection Level (3) – EQ-Systems connected to 103855: Trays CAPE-OPEN.moseqs:

Equation System: 103851: Trays Functions CAPE- OPEN.moseqs

Description: -CAPE-OPEN functions calculating fugacity coefcients and enthalpies.

Connected Equations:

• Eq: 103854: equ_overall_tray_composition.mosequ (using Nota: 2951: Public_notation.mosnot) Desc.: Equation to calculate the overall composition of a tray.

NC ∑ L,n V,n L,n V,n zi,tr · ( (Ftr · xi,tr + Ftr · yi,tr)) = Ftr · xi,tr + Ftr (F.58) i=1 · yi,tr

• Eq: 103852: equ_Molar specifc liquid enthalpy calculated tray.mosequ (using Nota: 2951: Public_notation.mosnot) Desc.: Molar specifc enthalpies of the liquid phase in J/kmol

L,n L,cal,n htr = htr (F.59)

• Eq: 103853: equ_Molar specifc vapor enthalpy calculated tray.mosequ (using Nota: 2951: Public_notation.mosnot)

240 F.3 CAPE-OPEN TwoCompundColumn

Desc.: Molar specifc enthalpies of the liquid phase in J/kmol

V,n V,cal,n htr = htr (F.60)

Applied Functions: • Fun: 47428: General equilibrium constant.mosfun (using Nota: 2951: Public_notation.mosnot) Desc.: Calculation of equilibrium in [1] For Raoults law: A=Component’s vapor pressure B= system pressure For Equations of state: A=component’s fugacy coefcient in a mixture of liquid phase B= component’s fugacy coefcient in a mixture of vapor phase Uses Param List: 7930: Public_parameter_functions.mospar K = f (A, B) (F.61)

with A f = (F.62) B applied as D L V Ki = f(φi , φi ) (F.63)

B L V Ki = f(φi , φi ) (F.64)

L V Ktr,i = f(φtr,i, φtr,i) (F.65)

with f = calc. by: applied as V φtr,i = f(Ttr, ptr, ztr,i) (F.67)

V D D D,in φi = f(T , p , yi ) (F.68)

241 Appendix F Full Documentation of Example Models

n h = f (T, p, xi) (F.69)

with f = calc. by: applied as B,L,cal,n B B B h = f(T , p , xi ) (F.70)

L,cal,n htr = f(Ttr, ptr, xtr,i) (F.71)

V,cal,n htr = f(Ttr, ptr, ytr,i) (F.72)

L,cal,f,n f f f h = f(T , p , xi ) (F.73)

D,L,cal,n out D D h = f(T , p , xi ) (F.74)

B,V,cal,n B B B h = f(T , p , yi ) (F.75)

with f = calc. by: applied as L D D D,in φi = f(T , p , yi ) (F.77)

L φtr,i = f(Ttr, ptr, ztr,i) (F.78)

242 F.3 CAPE-OPEN TwoCompundColumn

Equation System: 103236: Trays no Functions.moseqs

Description: Basic tray model without functions for property calculations.

Connected EQ-Systems:

• 47469: Basic tray.moseqs

Connection Level (4) – EQ-Systems connected to 103236: Trays no Functions.moseqs:

Equation System: 47469: Basic tray.moseqs

Description: Tray model Calculation units: Flows: [kmol/s] Enthalpies: [kJ/kmol] Pressure:: [Pa] Assumption: -No excess enthalpies -Constant pressure drop

Connected Equations:

• Eq: 47433: Molar summation relations liquid phase.mosequ (using Nota: 2951: Public_notation.mosnot) Desc.: Summation relation for liquid phase at tray tr [1] Parameter List: 7930: Public_parameter_functions.mospar

NC ∑ 1 = xi,tr (F.79) i=1

• Eq: 47432: Molar component balances.mosequ (using Nota: 2951: Public_notation.mosnot) Desc.: Steady molar component balance of tray tr in [kmol/s] Param-

243 Appendix F Full Documentation of Example Models

eter List: 7930: Public_parameter_functions.mospar

f,L,n f L,n V,n L,n V,n 0 = Ftr ·xi +Ftr+1 ·xi,tr+1 +Ftr−1 ·yi,tr−1 −Ftr ·xi,tr −Ftr ·yi,tr (F.80)

• Eq: 47429: General equilibrium constant liquid vapor phase.mosequ (using Nota: 2951: Public_notation.mosnot) Desc.: General equilibrium constant calculation for a VLE on a tray in [1] ytr,i Ktr,i = (F.81) xtr,i • Eq: 47436: Pressure drop top tray.mosequ (using Nota: 2951: Public_- notation.mosnot) Desc.: Pressure drop from top tray to next unit in [Pa] Parameter List: 103375: par_deisobutanizer.mospar

∆p = ptr=NTR − ptr=NTR+1 (F.82)

• Eq: 47434: Molar summation relations vapor phase.mosequ (using Nota: 2951: Public_notation.mosnot) Desc.: Summation relation for vapor phase at tray tr [1] Parameter List: 7930: Public_parameter_functions.mospar

NC ∑ 1 = yi,tr (F.83) i=1 • Eq: 47431: Heat balances.mosequ (using Nota: 2951: Public_- notation.mosnot) Desc.: Heat blance around tray tr at steady state in [kW]

f,L,n f,L,n L,n L,n V,n V,n L,n L,n V,n V,n 0 = Ftr ·h +Ftr+1 ·htr+1 +Ftr−1 ·htr−1 −Ftr ·htr −Ftr ·htr (F.84)

• Eq: 47435: Pressure drop.mosequ (using Nota: 2951: Public_- notation.mosnot) Desc.: Pressure drop from tray tr-1 to tr in Pa Parameter List: 103375: par_deisobutanizer.mospar

∆p = ptr−1 − ptr (F.85)

244 F.3 CAPE-OPEN TwoCompundColumn

Variable Specs ’103859: Initial values subcooled CAPE-OPEN column (Feed 57).mosvar’

Design variables

L,f,n e0.Ftr=10 = 0.0 L,f,n e0.Ftr=11 = 0.0 L,f,n e0.Ftr=12 = 0.0 L,f,n e0.Ftr=13 = 0.0 L,f,n e0.Ftr=14 = 0.0 L,f,n e0.Ftr=15 = 0.0 L,f,n e0.Ftr=16 = 0.0 L,f,n e0.Ftr=18 = 0.0 L,f,n e0.Ftr=19 = 0.0 L,f,n e0.Ftr=1 = 0.0 L,f,n e0.Ftr=20 = 0.0 L,f,n e0.Ftr=21 = 0.0 L,f,n e0.Ftr=22 = 0.0 L,f,n e0.Ftr=23 = 0.0 L,f,n e0.Ftr=24 = 0.0 L,f,n e0.Ftr=25 = 0.0 L,f,n e0.Ftr=26 = 0.0 L,f,n e0.Ftr=27 = 0.0 L,f,n e0.Ftr=28 = 0.0 L,f,n e0.Ftr=29 = 0.0 L,f,n e0.Ftr=2 = 0.0 L,f,n e0.Ftr=30 = 0.0 L,f,n e0.Ftr=31 = 0.0 L,f,n e0.Ftr=32 = 0.0 L,f,n e0.Ftr=33 = 0.0 L,f,n e0.Ftr=34 = 0.0 L,f,n e0.Ftr=35 = 0.0 L,f,n e0.Ftr=3 = 0.0 L,f,n e0.Ftr=4 = 0.0 L,f,n e0.Ftr=5 = 0.0 L,f,n e0.Ftr=6 = 0.0 L,f,n e0.Ftr=7 = 0.0

245 Appendix F Full Documentation of Example Models

L,f,n e0.Ftr=8 = 0.0 L,f,n e0.Ftr=9 = 0.0 e0p1.F = 57.0 e0p1.T = 329.0 e0p1.p = 700798.0

e0p1.zi=1 = 0.4 e0p1.zi=2 = 0.6 e0p2.p = 700000.0

e0p2.zi=1 = 0.9 e0p3.zi=1 = 0.08

Iteration variables

V,n e0.Ftr=0 = 158.4129 L,n e0.Ftr=10 = 194.8796 V,n e0.Ftr=10 = 160.2927 L,n e0.Ftr=11 = 195.0488 V,n e0.Ftr=11 = 160.4496 L,n e0.Ftr=12 = 195.2057 V,n e0.Ftr=12 = 160.5933 L,n e0.Ftr=13 = 195.3494 V,n e0.Ftr=13 = 160.7233 L,n e0.Ftr=14 = 195.4794 V,n e0.Ftr=14 = 160.8399 L,n e0.Ftr=15 = 195.596 V,n e0.Ftr=15 = 160.9434 L,n e0.Ftr=16 = 195.6995 V,n e0.Ftr=16 = 161.0345 L,n e0.Ftr=17 = 195.7906 V,n e0.Ftr=17 = 161.1153 L,n e0.Ftr=18 = 138.8714 V,n e0.Ftr=18 = 161.1764 L,n e0.Ftr=19 = 138.9325 V,n e0.Ftr=19 = 161.2516 L,n e0.Ftr=1 = 193.169 V,n e0.Ftr=1 = 158.5866 L,n e0.Ftr=20 = 139.0077

246 F.3 CAPE-OPEN TwoCompundColumn

V,n e0.Ftr=20 = 161.3435 L,n e0.Ftr=21 = 139.0996 V,n e0.Ftr=21 = 161.4554 L,n e0.Ftr=22 = 139.2115 V,n e0.Ftr=22 = 161.5905 L,n e0.Ftr=23 = 139.3466 V,n e0.Ftr=23 = 161.7522 L,n e0.Ftr=24 = 139.5083 V,n e0.Ftr=24 = 161.944 L,n e0.Ftr=25 = 139.7001 V,n e0.Ftr=25 = 162.1685 L,n e0.Ftr=26 = 139.9246 V,n e0.Ftr=26 = 162.4278 L,n e0.Ftr=27 = 140.1839 V,n e0.Ftr=27 = 162.7222 L,n e0.Ftr=28 = 140.4783 V,n e0.Ftr=28 = 163.0505 L,n e0.Ftr=29 = 140.8066 V,n e0.Ftr=29 = 163.4086 L,n e0.Ftr=2 = 193.3427 V,n e0.Ftr=2 = 158.7705 L,n e0.Ftr=30 = 141.1647 V,n e0.Ftr=30 = 163.7904 L,n e0.Ftr=31 = 141.5465 V,n e0.Ftr=31 = 164.1873 L,n e0.Ftr=32 = 141.9434 V,n e0.Ftr=32 = 164.5893 L,n e0.Ftr=33 = 142.3454 V,n e0.Ftr=33 = 164.9858 L,n e0.Ftr=34 = 142.7419 V,n e0.Ftr=34 = 165.3666 L,n e0.Ftr=35 = 143.1227 V,n e0.Ftr=35 = 165.7232 L,n e0.Ftr=36 = 143.4793 L,n e0.Ftr=3 = 193.5266 V,n e0.Ftr=3 = 158.9624

247 Appendix F Full Documentation of Example Models

L,n e0.Ftr=4 = 193.7185 V,n e0.Ftr=4 = 159.1598 L,n e0.Ftr=5 = 193.9159 V,n e0.Ftr=5 = 159.3596 L,n e0.Ftr=6 = 194.1157 V,n e0.Ftr=6 = 159.5588 L,n e0.Ftr=7 = 194.3149 V,n e0.Ftr=7 = 159.7543 L,n e0.Ftr=8 = 194.5104 V,n e0.Ftr=8 = 159.9434 L,n e0.Ftr=9 = 194.6995 V,n e0.Ftr=9 = 160.1235 e0.T D = 325.0

e0.Ttr=10 = 332.7298 e0.Ttr=11 = 332.4867 e0.Ttr=12 = 332.2654 e0.Ttr=13 = 332.0659 e0.Ttr=14 = 331.8876 e0.Ttr=15 = 331.7295 e0.Ttr=16 = 331.5902 e0.Ttr=17 = 331.4683 e0.Ttr=18 = 331.3753 e0.Ttr=19 = 331.2625 e0.Ttr=1 = 335.5268 e0.Ttr=20 = 331.1262 e0.Ttr=21 = 330.9624 e0.Ttr=22 = 330.7672 e0.Ttr=23 = 330.5363 e0.Ttr=24 = 330.2663 e0.Ttr=25 = 329.9546 e0.Ttr=26 = 329.5999 e0.Ttr=27 = 329.2032 e0.Ttr=28 = 328.768 e0.Ttr=29 = 328.3006 e0.Ttr=2 = 335.2075 e0.Ttr=30 = 327.8102

248 F.3 CAPE-OPEN TwoCompundColumn

e0.Ttr=31 = 327.3079 e0.Ttr=32 = 326.8063 e0.Ttr=33 = 326.318 e0.Ttr=34 = 325.8544 e0.Ttr=35 = 325.4245 e0.Ttr=3 = 334.8799 e0.Ttr=4 = 334.5484 e0.Ttr=5 = 334.2179 e0.Ttr=6 = 333.893 e0.Ttr=7 = 333.5782 e0.Ttr=8 = 333.2774 e0.Ttr=9 = 332.9938 e0.hL,f,n = −144379.4577 V,n e0.htr=0 = −123600.2526 L,n e0.htr=10 = −143481.6503 V,n e0.htr=10 = −126130.4033 L,n e0.htr=11 = −143636.7472 V,n e0.htr=11 = −126319.7675 L,n e0.htr=12 = −143778.3266 V,n e0.htr=12 = −126490.9907 L,n e0.htr=13 = −143906.2469 V,n e0.htr=13 = −126644.3586 L,n e0.htr=14 = −144020.7572 V,n e0.htr=14 = −126780.5758 L,n e0.htr=15 = −144122.4138 V,n e0.htr=15 = −126900.6531 L,n e0.htr=16 = −144211.9953 V,n e0.htr=16 = −127005.8023 L,n e0.htr=17 = −144290.4248 V,n e0.htr=17 = −127097.3452 L,n e0.htr=18 = −144350.0292 V,n e0.htr=18 = −127166.554 L,n e0.htr=19 = −144422.7299 V,n e0.htr=19 = −127250.6761 L,n e0.htr=1 = −141732.1952 V,n e0.htr=1 = −123859.3621

249 Appendix F Full Documentation of Example Models

L,n e0.htr=20 = −144510.9822 V,n e0.htr=20 = −127352.3327 L,n e0.htr=21 = −144617.4823 V,n e0.htr=21 = −127474.313 L,n e0.htr=22 = −144745.0798 V,n e0.htr=22 = −127619.4365 L,n e0.htr=23 = −144896.6267 V,n e0.htr=23 = −127790.3417 L,n e0.htr=24 = −145074.7503 V,n e0.htr=24 = −127989.1945 L,n e0.htr=25 = −145281.5446 V,n e0.htr=25 = −128217.3246 L,n e0.htr=26 = −145518.1919 V,n e0.htr=26 = −128474.8223 L,n e0.htr=27 = −145784.551 V,n e0.htr=27 = −128760.156 L,n e0.htr=28 = −146078.7804 V,n e0.htr=28 = −129069.9016 L,n e0.htr=29 = −146397.089 V,n e0.htr=29 = −129398.68 L,n e0.htr=2 = −141928.4364 V,n e0.htr=2 = −124126.9111 L,n e0.htr=30 = −146733.7144 V,n e0.htr=30 = −129739.3817 L,n e0.htr=31 = −147081.2 V,n e0.htr=31 = −130083.6972 L,n e0.htr=32 = −147430.9778 V,n e0.htr=32 = −130422.8875 L,n e0.htr=33 = −147774.1788 V,n e0.htr=33 = −130748.6532 L,n e0.htr=34 = −148102.5157 V,n e0.htr=34 = −131053.9243 L,n e0.htr=35 = −148409.0574 V,n e0.htr=35 = −131333.4163 L,n e0.htr=36 = −148688.748 L,n e0.htr=3 = −142130.7659

250 F.3 CAPE-OPEN TwoCompundColumn

V,n e0.htr=3 = −124399.2776 L,n e0.htr=4 = −142336.429 V,n e0.htr=4 = −124672.5526 L,n e0.htr=5 = −142542.4708 V,n e0.htr=5 = −124942.7596 L,n e0.htr=6 = −142745.9033 V,n e0.htr=6 = −125206.0833 L,n e0.htr=7 = −142943.8766 V,n e0.htr=7 = −125459.0808 L,n e0.htr=8 = −143133.8353 V,n e0.htr=8 = −125698.8504 L,n e0.htr=9 = −143313.6408 V,n e0.htr=9 = −125923.1419 e0.ptr=10 = 701092.0 e0.ptr=11 = 701050.0 e0.ptr=12 = 701008.0 e0.ptr=13 = 700966.0 e0.ptr=14 = 700924.0 e0.ptr=15 = 700882.0 e0.ptr=16 = 700840.0 e0.ptr=17 = 700798.0 e0.ptr=18 = 700756.0 e0.ptr=19 = 700714.0 e0.ptr=1 = 701470.0 e0.ptr=20 = 700672.0 e0.ptr=21 = 700630.0 e0.ptr=22 = 700588.0 e0.ptr=23 = 700546.0 e0.ptr=24 = 700504.0 e0.ptr=25 = 700462.0 e0.ptr=26 = 700420.0 e0.ptr=27 = 700378.0 e0.ptr=28 = 700336.0 e0.ptr=29 = 700294.0 e0.ptr=2 = 701428.0 e0.ptr=30 = 700252.0

251 Appendix F Full Documentation of Example Models

e0.ptr=31 = 700210.0 e0.ptr=32 = 700168.0 e0.ptr=33 = 700126.0 e0.ptr=34 = 700084.0 e0.ptr=35 = 700042.0 e0.ptr=3 = 701386.0 e0.ptr=4 = 701344.0 e0.ptr=5 = 701302.0 e0.ptr=6 = 701260.0 e0.ptr=7 = 701218.0 e0.ptr=8 = 701176.0 e0.ptr=9 = 701134.0 e0.xi=1,tr=10 = 0.29796 e0.xi=1,tr=11 = 0.31555 e0.xi=1,tr=12 = 0.33161 e0.xi=1,tr=13 = 0.34614 e0.xi=1,tr=14 = 0.35916 e0.xi=1,tr=15 = 0.37071 e0.xi=1,tr=16 = 0.3809 e0.xi=1,tr=17 = 0.38982 e0.xi=1,tr=18 = 0.39659 e0.xi=1,tr=19 = 0.40486 e0.xi=1,tr=1 = 0.10097 e0.xi=1,tr=20 = 0.41492 e0.xi=1,tr=21 = 0.42708 e0.xi=1,tr=22 = 0.44166 e0.xi=1,tr=23 = 0.45901 e0.xi=1,tr=24 = 0.47944 e0.xi=1,tr=25 = 0.50319 e0.xi=1,tr=26 = 0.53043 e0.xi=1,tr=27 = 0.56114 e0.xi=1,tr=28 = 0.59515 e0.xi=1,tr=29 = 0.63203 e0.xi=1,tr=2 = 0.12293 e0.xi=1,tr=30 = 0.67112 e0.xi=1,tr=31 = 0.71157

252 F.3 CAPE-OPEN TwoCompundColumn

e0.xi=1,tr=32 = 0.7524 e0.xi=1,tr=33 = 0.79255 e0.xi=1,tr=34 = 0.83105 e0.xi=1,tr=35 = 0.86707 e0.xi=1,tr=3 = 0.14561 e0.xi=1,tr=4 = 0.1687 e0.xi=1,tr=5 = 0.19188 e0.xi=1,tr=6 = 0.21479 e0.xi=1,tr=7 = 0.23713 e0.xi=1,tr=8 = 0.25859 e0.xi=1,tr=9 = 0.27893 e0.xi=2,tr=10 = 0.70204 e0.xi=2,tr=11 = 0.68445 e0.xi=2,tr=12 = 0.66839 e0.xi=2,tr=13 = 0.65386 e0.xi=2,tr=14 = 0.64084 e0.xi=2,tr=15 = 0.62929 e0.xi=2,tr=16 = 0.6191 e0.xi=2,tr=17 = 0.61018 e0.xi=2,tr=18 = 0.60341 e0.xi=2,tr=19 = 0.59514 e0.xi=2,tr=1 = 0.89903 e0.xi=2,tr=20 = 0.58508 e0.xi=2,tr=21 = 0.57292 e0.xi=2,tr=22 = 0.55834 e0.xi=2,tr=23 = 0.54099 e0.xi=2,tr=24 = 0.52056 e0.xi=2,tr=25 = 0.49681 e0.xi=2,tr=26 = 0.46957 e0.xi=2,tr=27 = 0.43886 e0.xi=2,tr=28 = 0.40485 e0.xi=2,tr=29 = 0.36797 e0.xi=2,tr=2 = 0.87707 e0.xi=2,tr=30 = 0.32888 e0.xi=2,tr=31 = 0.28843 e0.xi=2,tr=32 = 0.2476

253 Appendix F Full Documentation of Example Models

e0.xi=2,tr=33 = 0.20745 e0.xi=2,tr=34 = 0.16895 e0.xi=2,tr=35 = 0.13293 e0.xi=2,tr=3 = 0.85439 e0.xi=2,tr=4 = 0.8313 e0.xi=2,tr=5 = 0.80812 e0.xi=2,tr=6 = 0.78521 e0.xi=2,tr=7 = 0.76287 e0.xi=2,tr=8 = 0.74141 e0.xi=2,tr=9 = 0.72107 e0.yi=1,tr=0 = 0.10558 e0.yi=1,tr=10 = 0.36662 e0.yi=1,tr=11 = 0.38612 e0.yi=1,tr=12 = 0.40374 e0.yi=1,tr=13 = 0.41952 e0.yi=1,tr=14 = 0.43353 e0.yi=1,tr=15 = 0.44588 e0.yi=1,tr=16 = 0.45669 e0.yi=1,tr=17 = 0.46609 e0.yi=1,tr=18 = 0.4732 e0.yi=1,tr=19 = 0.48183 e0.yi=1,tr=1 = 0.13234 e0.yi=1,tr=20 = 0.49228 e0.yi=1,tr=21 = 0.50481 e0.yi=1,tr=22 = 0.51972 e0.yi=1,tr=23 = 0.53727 e0.yi=1,tr=24 = 0.5577 e0.yi=1,tr=25 = 0.58112 e0.yi=1,tr=26 = 0.60755 e0.yi=1,tr=27 = 0.63682 e0.yi=1,tr=28 = 0.66858 e0.yi=1,tr=29 = 0.70227 e0.yi=1,tr=2 = 0.15998 e0.yi=1,tr=30 = 0.73716 e0.yi=1,tr=31 = 0.77239 e0.yi=1,tr=32 = 0.80707

254 F.3 CAPE-OPEN TwoCompundColumn

e0.yi=1,tr=33 = 0.84035 e0.yi=1,tr=34 = 0.8715 e0.yi=1,tr=35 = 0.9 e0.yi=1,tr=3 = 0.1881 e0.yi=1,tr=4 = 0.21631 e0.yi=1,tr=5 = 0.24419 e0.yi=1,tr=6 = 0.27135 e0.yi=1,tr=7 = 0.29744 e0.yi=1,tr=8 = 0.32216 e0.yi=1,tr=9 = 0.34527 e0.yi=2,tr=0 = 0.89442 e0.yi=2,tr=10 = 0.63338 e0.yi=2,tr=11 = 0.61388 e0.yi=2,tr=12 = 0.59626 e0.yi=2,tr=13 = 0.58048 e0.yi=2,tr=14 = 0.56647 e0.yi=2,tr=15 = 0.55412 e0.yi=2,tr=16 = 0.54331 e0.yi=2,tr=17 = 0.53391 e0.yi=2,tr=18 = 0.5268 e0.yi=2,tr=19 = 0.51817 e0.yi=2,tr=1 = 0.86766 e0.yi=2,tr=20 = 0.50772 e0.yi=2,tr=21 = 0.49519 e0.yi=2,tr=22 = 0.48028 e0.yi=2,tr=23 = 0.46273 e0.yi=2,tr=24 = 0.4423 e0.yi=2,tr=25 = 0.41888 e0.yi=2,tr=26 = 0.39245 e0.yi=2,tr=27 = 0.36318 e0.yi=2,tr=28 = 0.33142 e0.yi=2,tr=29 = 0.29773 e0.yi=2,tr=2 = 0.84002 e0.yi=2,tr=30 = 0.26284 e0.yi=2,tr=31 = 0.22761 e0.yi=2,tr=32 = 0.19293

255 Appendix F Full Documentation of Example Models

e0.yi=2,tr=33 = 0.15965 e0.yi=2,tr=34 = 0.1285 e0.yi=2,tr=35 = 0.1 e0.yi=2,tr=3 = 0.8119 e0.yi=2,tr=4 = 0.78369 e0.yi=2,tr=5 = 0.75581 e0.yi=2,tr=6 = 0.72865 e0.yi=2,tr=7 = 0.70256 e0.yi=2,tr=8 = 0.67784 e0.yi=2,tr=9 = 0.65473 e0.ztr=1,i=1 = 0.115 e0.ztr=1,i=2 = 0.885 e0.ztr=10,i=1 = 0.329 e0.ztr=10,i=2 = 0.671 e0.ztr=11,i=1 = 0.347 e0.ztr=11,i=2 = 0.653 e0.ztr=12,i=1 = 0.364 e0.ztr=12,i=2 = 0.636 e0.ztr=13,i=1 = 0.379 e0.ztr=13,i=2 = 0.621 e0.ztr=14,i=1 = 0.393 e0.ztr=14,i=2 = 0.607 e0.ztr=15,i=1 = 0.405 e0.ztr=15,i=2 = 0.595 e0.ztr=16,i=1 = 0.415 e0.ztr=16,i=2 = 0.585 e0.ztr=17,i=1 = 0.43 e0.ztr=17,i=2 = 0.57 e0.ztr=18,i=1 = 0.46 e0.ztr=18,i=2 = 0.54 e0.ztr=19,i=1 = 0.48 e0.ztr=19,i=2 = 0.52 e0.ztr=2,i=1 = 0.14 e0.ztr=2,i=2 = 0.86 e0.ztr=20,i=1 = 0.5 e0.ztr=20,i=2 = 0.5

256 F.3 CAPE-OPEN TwoCompundColumn

e0.ztr=21,i=1 = 0.52 e0.ztr=21,i=2 = 0.48 e0.ztr=22,i=1 = 0.55 e0.ztr=22,i=2 = 0.45 e0.ztr=23,i=1 = 0.58 e0.ztr=23,i=2 = 0.42 e0.ztr=24,i=1 = 0.61 e0.ztr=24,i=2 = 0.39 e0.ztr=25,i=1 = 0.64 e0.ztr=25,i=2 = 0.36 e0.ztr=26,i=1 = 0.66 e0.ztr=26,i=2 = 0.34 e0.ztr=27,i=1 = 0.68 e0.ztr=27,i=2 = 0.32 e0.ztr=28,i=1 = 0.7 e0.ztr=28,i=2 = 0.3 e0.ztr=29,i=1 = 0.72 e0.ztr=29,i=2 = 0.28 e0.ztr=3,i=1 = 0.165 e0.ztr=3,i=2 = 0.835 e0.ztr=30,i=1 = 0.74 e0.ztr=30,i=2 = 0.26 e0.ztr=31,i=1 = 0.77 e0.ztr=31,i=2 = 0.23 e0.ztr=32,i=1 = 0.8 e0.ztr=32,i=2 = 0.2 e0.ztr=33,i=1 = 0.83 e0.ztr=33,i=2 = 0.17 e0.ztr=34,i=1 = 0.853 e0.ztr=34,i=2 = 0.147 e0.ztr=35,i=1 = 0.885 e0.ztr=35,i=2 = 0.115 e0.ztr=4,i=1 = 0.19 e0.ztr=4,i=2 = 0.81 e0.ztr=5,i=1 = 0.215 e0.ztr=5,i=2 = 0.785

257 Appendix F Full Documentation of Example Models

e0.ztr=6,i=1 = 0.24 e0.ztr=6,i=2 = 0.76 e0.ztr=7,i=1 = 0.264 e0.ztr=7,i=2 = 0.736 e0.ztr=8,i=1 = 0.287 e0.ztr=8,i=2 = 0.713 e0.ztr=9,i=1 = 0.309 e0.ztr=9,i=2 = 0.691 e0e0e1.QD = 2876181.2371 e0e0e1.RD = 6.4503 D e0e0e1.yi=1 = 0.92552 D e0e0e1.yi=2 = 0.074483 e0e0e2.QB = 2878859.4289 e0e0e2.hB,L,n = −141544.4552 e0p2.F = 22.2439 e0p2.T = 325.0348

e0p2.zi=2 = 0.1 e0p3.F = 34.7561 e0p3.T = 335.8337 e0p3.p = 701512.0

e0p3.zi=2 = 0.92

Parameter Specs ’103858: Adjustable Parameters CAPE-OPEN.mosvar’

Parameters

e0.∆p = 42.0 e0e0e1.∆T = 5.0

258 F.3 CAPE-OPEN TwoCompundColumn

F.3.1 Additional TwoCompoundColumn Screenshots

In the four additional screenshot related to the TwoCompoundColumn some more setting in COFE and ASPEN can bee seen. Fig. F.3 shows the dialog to select a unit operation in COFE. In the example the unit operation named “TwoCompoundColumn32F” is selected. Fig. F.4 shows the property package dialog in COFE to select a property package. In the example the model set “Soave Redlich Kwong” is selected and the compounds “Isobutane” and “N-Butane” are included. Fig. F.5 shows that a “COCO_TEAPropertyPackManager” using CAPE-OPEN Thermo version 1.1 could be loaded inside ASPEN PLUS. Fig. F.6 shows the feed material defnition of the TwoCoumpoundColumn fowsheet in ASPEN PLUS.

Figure F.3: COFE unit operation selection dialog with highlighted 32-bit TwoCompoundColumn model created with MOSAICmodeling

259 Appendix F Full Documentation of Example Models

Figure F.4: COFE property package defnition dialog with SRK as selected model set including the compounds I-Butane and N-Butane

260 F.3 CAPE-OPEN TwoCompundColumn interfaces CO Figure F.5: ASPEN PLUS using COCO/TEA property package loaded via

261 Appendix F Full Documentation of Example Models APNPU edmtra ento of defnition material feed PLUS ASPEN F.6: Figure TwoCompoundColumn fowsheet

262 F.4 Documentation-based Flowsheeting

F.4 Documentation-based Flowsheeting

Evaluation ’107519: eva_fowsheet_cascade_unit_reuse.moseva’

Description: Flowsheet simulation of a cascade of splitters and mixers. Equation System: 107518: fowsheet_MixerSplitter_unit_reuse.moseqs IndexSpecifcation: Variable Specifcation: 107520: varSpec_reused_unit_cascade_initial.mosvar Parameter Specifcation: none. Results Specifcation: 109022: varSpec_reused_unit_cascade_result.mosvar

Hierarchical view of equations:

Equation System: 107518: fowsheet_MixerSplitter_unit_- reuse.moseqs

Description: Flowsheet equation system

Connected EQ-Systems:

• 60516: unit_Splitter1.moseqs

• 60523: unit_Mixer7.moseqs

• 60522: unit_Mixer4.moseqs

Connection Level (1) – EQ-Systems connected to 107518: fowsheet_MixerSplitter_- unit_reuse.moseqs:

263 Appendix F Full Documentation of Example Models

Equation System: 60516: unit_Splitter1.moseqs

Description: Splitter unit 1

Connected EQ-Systems:

• 36027: eqs_splitter_simple.moseqs

Connection Level (2) – EQ-Systems connected to 60516: unit_Splitter1.moseqs:

Equation System: 36027: eqs_splitter_simple.moseqs

Description: equation system for a simple splitter

Connected Equations:

• Eq: 36024: equation_splitter_simple_2.mosequ (using Nota: 36021: nota_unit_template.mosnot) Desc.: equation 2 for the simple splitter describing z fraction

z = x · (1 − α) (F.86)

• Eq: 36023: equation_splitter_simple_1.mosequ (using Nota: 36021: nota_unit_template.mosnot) Desc.: equation 1 for the simple splitter describing y fraction

y = x · α (F.87)

264 F.4 Documentation-based Flowsheeting

Equation System: 60523: unit_Mixer7.moseqs

Description: Mixer unit 7

Connected EQ-Systems:

• 36025: eqs_mixer_simple.moseqs

Connection Level (2) – EQ-Systems connected to 60523: unit_Mixer7.moseqs:

Equation System: 36025: eqs_mixer_simple.moseqs

Description: equation system for a simple mixer

Connected Equations:

• Eq: 36022: equation_mixer_simple.mosequ (using Nota: 36021: nota_unit_template.mosnot) Desc.: equation describing a simple mixer

z = x + y (F.88)

Equation System: 60522: unit_Mixer4.moseqs

Description: Mixer unit 4

Connected EQ-Systems:

265 Appendix F Full Documentation of Example Models

• 36025: eqs_mixer_simple.moseqs

Connection Level (2) – EQ-Systems connected to 60522: unit_Mixer4.moseqs:

Equation System: 36025: eqs_mixer_simple.moseqs

Description: equation system for a simple mixer

Connected Equations:

• Eq: 36022: equation_mixer_simple.mosequ (using Nota: 36021: nota_unit_template.mosnot) Desc.: equation describing a simple mixer

z = x + y (F.89)

Internal Streams

• Stream 0 Interface: 60512: itfc_InOut.mosint

– Port I: Connected element ID: 0 Port ID at connected element: 2 Connector: none

– Port II: Connected element ID: 1 Port ID at connected element: 1

266 F.4 Documentation-based Flowsheeting

Connector: none

• Stream 1 Interface: 60512: itfc_InOut.mosint

– Port I: Connected element ID: 0 Port ID at connected element: 3 Connector: none

– Port II: Connected element ID: 2 Port ID at connected element: 1 Connector: none

• Stream 2 Interface: 60512: itfc_InOut.mosint

– Port I: Connected element ID: 1 Port ID at connected element: 3 Connector: none

– Port II: Connected element ID: 3 Port ID at connected element: 2 Connector: none

• Stream 3 Interface: 60512: itfc_InOut.mosint

– Port I: Connected element ID: 2

267 Appendix F Full Documentation of Example Models

Port ID at connected element: 3 Connector: none

– Port II: Connected element ID: 5 Port ID at connected element: 1 Connector: none

• Stream 4 Interface: 60512: itfc_InOut.mosint

– Port I: Connected element ID: 2 Port ID at connected element: 2 Connector: none

– Port II: Connected element ID: 3 Port ID at connected element: 1 Connector: none

• Stream 5 Interface: 60512: itfc_InOut.mosint

– Port I: Connected element ID: 3 Port ID at connected element: 3 Connector: none

– Port II: Connected element ID: 4 Port ID at connected element: 1 Connector: none

268 F.4 Documentation-based Flowsheeting

• Stream 6 Interface: 60512: itfc_InOut.mosint

– Port I: Connected element ID: 4 Port ID at connected element: 3 Connector: none

– Port II: Connected element ID: 6 Port ID at connected element: 2 Connector: none

• Stream 7 Interface: 60512: itfc_InOut.mosint

– Port I: Connected element ID: 5 Port ID at connected element: 2 Connector: none

– Port II: Connected element ID: 6 Port ID at connected element: 1 Connector: none

Interface ’60512: itfc_InOut.mosint’

Notation: ’60511: nota_PortsAndStreams.mosnot’ Variable list

269 Appendix F Full Documentation of Example Models

Equation instances

Equation instances:

Eq: 36023: equation_splitter_simple_1.mosequ (using Nota: 36021: nota_- unit_template.mosnot). Description: equation 1 for the simple splitter describing y fraction. e0s0.Q = e0p1.Q · e0e0.α (F.90)

e0p2.Q = e0s0.Q · e0e1.α (F.91)

e0s4.Q = e0s1.Q · e0e2.α (F.92)

e0p3.Q = e0s5.Q · e0e4.α (F.93)

e0s7.Q = e0s3.Q · e0e5.α (F.94)

Eq: 36024: equation_splitter_simple_2.mosequ (using Nota: 36021: nota_- unit_template.mosnot). Description: equation 2 for the simple splitter describing z fraction. e0s1.Q = e0p1.Q · (1 − e0e0.α) (F.95)

e0s2.Q = e0s0.Q · (1 − e0e1.α) (F.96)

e0s3.Q = e0s1.Q · (1 − e0e2.α) (F.97)

e0s6.Q = e0s5.Q · (1 − e0e4.α) (F.98)

e0p4.Q = e0s3.Q · (1 − e0e5.α) (F.99)

Eq: 36022: equation_mixer_simple.mosequ (using Nota: 36021: nota_unit_- template.mosnot). Description: equation describing a simple mixer. e0s5.Q = e0s4.Q + e0s2.Q (F.100)

e0p5.Q = e0s7.Q + e0s6.Q (F.101)

Variable Specs ’107520: varSpec_reused_unit_cascade_initial.mosvar’

Design variables

270 F.4 Documentation-based Flowsheeting

e0e0.α = 0.5 e0e1.α = 0.5 e0e2.α = 0.5 e0e4.α = 0.5 e0p1.Q = 100.0 e0p5.Q = 40.0

Iteration variables

e0e5.α = 0.0 e0p2.Q = 0.0 e0p3.Q = 0.0 e0p4.Q = 0.0 e0s0.Q = 0.0 e0s1.Q = 0.0 e0s2.Q = 0.0 e0s3.Q = 0.0 e0s4.Q = 0.0 e0s5.Q = 0.0 e0s6.Q = 0.0 e0s7.Q = 0.0

Results ’109022: varSpec_reused_unit_cascade_result.mosvar’

Design variables

e0e0.α = 0.5 e0e1.α = 0.5 e0e2.α = 0.5 e0e4.α = 0.5 e0p1.Q = 100.0 e0p5.Q = 40.0

Iteration variables

e0e5.α = 0.6000000000000001

271 Appendix F Full Documentation of Example Models

e0p2.Q = 25.0 e0p3.Q = 25.0 e0p4.Q = 10.0 e0s0.Q = 50.0 e0s1.Q = 50.0 e0s2.Q = 25.0 e0s3.Q = 25.0 e0s4.Q = 25.0 e0s5.Q = 50.0 e0s6.Q = 25.0 e0s7.Q = 15.0

Notation ’36021: nota_unit_template.mosnot’

Base line symbols

α Split factor alpha [0,1] x Variable x y Variable y z Variable z

Indices

k 1..Nk Index for free use

Notation ’60511: nota_PortsAndStreams.mosnot’

Base line symbols

Q Variable for the ports and streams level

272 F.5 Public Notation

F.5 Public Notation

For this thesis the public notation of DBTA (ID: 2951) was copied and extended/adjusted. The notation 20972: PublicNotationT.mosnot is a super set of the original notation. Therefore only the more comprehensive notation is listed here as it fully includes the smaller notation.

Notation ’20972: PublicNotationT.mosnot’

Base line symbols

A Area (mˆ2); Parameter 1 B Parameter 2 C Parameter 3 Cp Heat capacity (kJ/K) D Parameter 4 DeltaT Diference in temperature (K) Deltap Pressure drop (Pa) E Parameter 5, Efciency factor F Flow (kg/s), (kmol/s), (L/h) Force (N), Parameter 6 G Parameter 7 H Enthalpy (kJ) HU Holdup m: (kg), n: (kmol) I Impulse / momentum (kg/msˆ2) K Equilibrium Factor; Gain factor (Controller) L Liquid molar fow M Molar weight (kg/kmol) N number of moles P Power (kJ) Q Heat duty (kJ/s) R Refux ratio; Ideal gas constant (kJ/kmol K), Parameter 6 (validity range) Re Reynoldszahl (-) T Temperature (K) or (◦C) U Internal energy (kJ); Heat transfer coefcient (kW/mˆ2 K) V Volume (mˆ3); Input value 1 W Physical work (kJ); Input parameter 2 X Turn over (chemical) (kmol/kmol); Input parameter 3 Y Input parameter 4

273 Appendix F Full Documentation of Example Models

Z Function value ∆T Diference in temperature (K) ∆ν this is mean ∆p Pressure drop (Pa) α scalar value β greek beta ϵ Void fraction (mˆ3/mˆ3) η Dynamic viscosity (Pa s), Level of efciency [Superscript: ef] (-) γ Activity coefcient ν Stoichiometric coefcient (-) ϕ alternative phi symbol, e.g. fugacity coefcient π Mathematical constant pi ρ Mass density m: (kg/mˆ3), n: (kmol/mˆ3) σ Surface tension (N/m) τ That’s tau. θ Temperature (◦C) ε alternative epsilon, e.g. void fraction (mˆ3/mˆ3) φ Fugacity coefcient ϑ alternative theta, e.g. for temperature ξ Mass fraction (kg/kg) a Specifc surface area (mˆ2/mˆ3) a∆ test naming av Auxiliary variable b small b c Molar concentration (kmol/mˆ3) cp Specifc heat capacity m: (kJ/kg K), n: (kJ/kmol K) d Diameter (m) e Control deviation (Controller) epsilon Void fraction (mˆ3/mˆ3) eta Dynamic viscosity (Pa s), Level of efciency [Superscript: ef] (-) f Factor g Gravitational constant (m/sˆ2) h Specifc Enthalpy m: (kJ/kg), n: (kJ/kmol) hu Specifc holdup m: (kg/kg), n: (kmol/kmol), v: (mˆ3/mˆ3) k Pre-exponential factor (reaction rate) l Length (m)

274 F.5 Public Notation

n Number of moles (mol) nu Stoichiometric coefcient (-) p Pressure (Pa) pi Mathematical constant pi q Specifc heat duty (kJ/mˆ3) r Reactive term m: (kg/s), n: (kmol/s) (specifc: m: (kg/s mˆ3), n: (kmol/s mˆ3)) rho Density m: (kg/mˆ3), n: (kmol/mˆ3) sigma Surface tension (N/m) t Time (s) u Specifc internal energy m: (kJ/kg), n: (kJ/kmol), Manipulated variable (controller) v Specifc volume (mˆ3/kg), molar volume (mˆ3/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 in general (mol/mol); Molar fraction in 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 phase 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 R Reactor

275 Appendix F Full Documentation of Example Models

Reflux Refux stream S Solid SpI Splitter 1 in Flowsheet SpII Splitter 2 in Flowsheet SpIII Splitter 3 in Flowsheet T Temperature T LV Boiling temperature [K] V Vapour phase α Phase alpha β Phase beta a Parameter 1 act Active add Addend, additional avg Average b Parameter 2 c Parameter 3 cc Counter current cold Cold cp Heat capacity crit Critical d Parameter 4 e Parameter 5 eff Efective 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

276 F.5 Public Notation

max Maximum value (range of validity) mega x 10ˆ6 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

Subscripts

B Boiler C Condenser D D-Part (Controller: dead time) ; Destillate I I-Part (Controller: integrate) P P-Part (Controller: propotional) R Reboiler γ Greek gama symbol cp Heat capacity d100 DIPPR 100 d101 DIPPR 101 d102 DIPPR 102 d105 DIPPR 105 d106 DIPPR 106 d107 DIPPR 107 eta Dynamic viscosity

277 Appendix F Full Documentation of Example Models

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) sub1 test and debug subscript sub2 test and debug subscript 2 sub3 next subscript

Indices

η 1..Neta greek index c 1..Nc index c col 1..Ncol column index i 1..NC Number of components idx 1..NIDX that’s an index idx1 1..NIDX1 index number 1 idx3 1..NIDX3 index 3 in 1..NIS Number of inlet streams j 1..NU Number of units (cascade) (NU) k 1..Nk Number of flm segments (NFS) l 1..Nl Number of components, second index m 1..Nm Number of flm segments, second Index (NFS-1) n 1..NR Number of reactions nr 1..Nnr Number of reactions out 1..NOS Number of outlet streams row 1..Nrow row index s 1..NS Number of Streams (Processes) t 1..NT SI Number of Taylor series indices tr 1..NT R Number of trays

278 Appendix G

Publications

This thesis is partially based on already published contributions. In the following these are divided into Journal articles, papers within conference proceedings, oral presentations without papers, and a list of all supervised theses. All contributions are ordered by date of publication.

Journal Articles

1. Kraus, R.; Fillinger, S.; Tolksdorf, G.; Minh, D. H.; Merchan, V. A.; Wozny, G. (2014): Improving Model and Data Integration Using MOSAIC as Central Data Management Platform; Chemie Ingenieur Technik, 86 (7), 1130-1136 10.1002/cite.201400007

2. Merchan, V. A.; Tolksdorf, G.; Kraus, R.; Wozny, G. (2014): Extend- ing Documentation-Based models towards an Efcient Integration within Commercial Process Simulators; Chemie Ingenieur Technik, 86 (7), 1117- 1129 10.1002/cite.201400014

3. Esche, E.; Hofmann, C.; Illner, I.; Müller, D.; Fillinger, S.; Tolksdorf, G.; Bonart, H.; Wozny, G., Repke, J.-U. (2016): MOSAIC - Enabling Large- scale Equation-Based Flowsheet Optimization; Chemie Ingenieur Technik, 88 (1-2), 620-635 10.1002/cite.201600114

4. Merchan, V. A.; Esche, E.; Fillinger, S.; Tolksdorf, G.; Wozny, G. (2016): Computer-Aided Process and Plant Development: A Review of Common

279 Appendix G Publications

Software Tools and Methods and Comparison against an Integrated Col- laborative Approach; Chemie Ingenieur Technik, 88 (1-2), 50-69 10.1002/cite.201500099

5. Bublitz, S.; Esche, E.; Tolksdorf, G.; Mehrmann, V.; Repke, J.-U. (2017): Analysis and Decomposition for Improved Convergence of Nonlinear Pro- cess Models in Chemical Engineering; Chemie Ingenieur Technik, 89 (11), 1503-1514 10.1002/cite.201700041

6. Tolksdorf, G.; Esche, E.; Wozny, G.; Repke, J.-U. (2018): Customized Code Generation based on User Specifcations for Simulation and Optimization, Computers & Chemical Engineering 10.1016/j.compchemeng.2018.12.006

Conference Papers

1. Wozny, G.; Zerry, R.; Kuntsche, S.; Kraus, R.; Merchan-Restrepo, V.A.; Esche, E.; Müller, D.; Hoang Minh, D.; Fillinger, S.; Tolksdorf, G. (2013): Trends and Prospects in Process Modeling and Optimization, in: Pro- ceedings of the 21st Polish National Conference on Chemical and Process Engineering – Kolberg, Poland. ISBN: 978-83-7518-594-2 p. 39-41*

2. Esche, E.; Müller, D.; Tolksdorf, G.; Kraus, R.; Wozny, G. (2014): MO- SAIC: An Online Platform Supporting Automatic Discretization of Partial Diferential Equation Systems, in: Proceedings of the 8th International Conference on Foundations of Computer-Aided Process Design - FOCAPD 2014, Computer-Aided Chemical Engineering, 34, 693-698

3. Tolksdorf, G.; Fillinger, S.; Wozny, G.; Manenti, F.; Rossi, F.; Buzzi- Ferraris, G.; Pierucci, S.; Fedorova, M.; Gani, R. (2015): A-Posteriori Integration of University CAPE Software Developments, in: Proceedings of the 12th International Conference on Chemical and Process Engineering - ICheaP12, Chemical Engineering Transactions, 43, 1345-1350

4. Tolksdorf, G.; Esche, E.; van Baten, J.; Wozny, G. (2016): Tailor-Made Modeling and Solution of Novel Process Units by Modular CAPE-OPEN- based Flowsheeting, in: Proceedings of the 26th European Symposium

280 on Computer Aided Process Engineering - ESCAPE 26, Computer-Aided Chemical Engineering, 38, 787-792

5. Penteado, A.; Esche, E.; Wilhelm, R.; Godini, H.; Salerno, D.; Tolksdorf, G.; Merchan, V. A.; Wozny, G. (2016): Modeling, Simulation, and Eco-

nomic Evaluation of a Hybrid CO2 Capture Process for Oxidative Coupling of Methane, in: Proceedings of the 26th European Symposium on Com- puter Aided Process Engineering - ESCAPE 26, Computer-Aided Chemical Engineering, 38, 1231-1236

6. Tolksdorf, G.; Esche, E.; Wozny, G.; Repke, J.-U. (2017): Automatic Generation of Simulation Code for Embedding Custom Unit Operations in CAPE Software, in: Proceedings of the 27th European Symposium on Computer Aided Process Engineering - ESCAPE 27, Computer-Aided Chemical Engineering, 40, 463-468

7. Fillinger, S.; Tolksdorf, G.; Bonart, H.; Esche, E.; Wozny, G.; Repke, J.-U. (2017): Linking Process Simulation and Automatic 3D Design for Chemi- cal Plants, in: Proceedings of the 27th European Symposium on Computer Aided Process Engineering - ESCAPE 27, Computer-Aided Chemical En- gineering, 40, 2311-2316

8. Esche, E.; Tolksdorf, G.; Fillinger, S.; Bonart, H.; Wozny, G.; Repke, J.- U. (2017): Support of Education in Process Simulation and Optimization via Language Independent Modelling and Versatile Code Generation, in: Proceedings of the 27th European Symposium on Computer Aided Process Engineering - ESCAPE 27, Computer-Aided Chemical Engineering, 40, 2929-2934

9. Bublitz, S.; Esche, E.; Tolksdorf, G.; Repke, J.-U. (2018): Improving Con- vergence Behavior of Nonlinear Equation Systems in Intensifed Process Models by Decomposition Methods, in: Proceedings of the 28th European Symposium on Computer Aided Process Engineering, Computer-Aided Chemical Engineering, 43, 403-408

10. Esche, E.; Bublitz, S.; Tolksdorf, G.; Repke, J.-U. (2018): Automatic De- composition of Nonlinear Equation Systems for Improved Initialization and Solution of Chemical Engineering Process Models, in: Proceedings of the

281 Appendix G Publications

13th International Symposium on Process Systems Engineering - PSE 2018, Computer-Aided Chemical Engineering, 44, 1387-1392

11. Pimentel Santa Rosa, L. S.; Pontes, K. V.; Penteado, A.; Tolksdorf, G.; Es- che, E.; Repke, J.-U. (2018): Using MOSAICmodeling and CAPE-OPEN Interfaces for Property Calculations in MATLAB, in: Congresso Brasileiro de Engenharia Quimica, Blucher Chemical Engineering Proceedings, 1(5), 4392–4395

Oral Presentations Without Proceedings

1. Tolksdorf, G. (2013): MOSAIC - A Modeling and Code Generation Tool, CAPE-OPEN Annual Conference 2013, Lyon, France, September 18-19, 2013

2. Fillinger, S.; Tolksdorf, G. (2014): Austausch von Modellen in der Prozess- simulation unter Verwendung standardisierter Schnittstellen, Pro-cessNet- Arbeitsausschuss “Modellgestützte Prozessentwicklung und -optimierung”, Hanau, Germany, May 27, 2014

3. Tolksdorf, G. (2015): The MOSAIC Approach - Self-made CO-UOs With- out Programming Knowledge, CAPE-OPEN Annual Conference 2015, Am- sterdam, The Netherlands, October 13-14, 2015

4. Fillinger, S.; Tolksdorf, G.; Esche, E.; Wozny, G. (2015): Automatisierte 3D-Visualisierung und standardisierter Datenaustausch in der Anlagenpla- nung, Jahrestrefen der ProcessNet-Fachgemeinschaft “Prozess-, Apparate- und Anlagentechnik” - PAAT 2015, Bruchsal, Germany, November 16-17, 2015

5. Tolksdorf, G. (2017): Cape-Open Easy Access for Students and Academics: Using MOSAICmodeling for Automatized Impementation of Unit Opera- tions, CAPE-OPEN Annual Conference 2017, London, England, October 12-13, 2017

6. Bublitz, S.; Esche, E.; Tolksdorf, G.; Repke, J.-U. (2017): Verbesserung der numerischen Konvergenz nichtlinearer Prozessmodelle mittels systematis- cher Zerlegung, Jahrestrefen der ProcessNet-Fachgemeinschaft “Prozess-,

282 Apparate- und Anlagentechnik” - PAAT 2017, Würzburg, Germany, No- vember 20-21, 2017

Supervised Theses

1. Baykal, A. (2014): Entwicklung und Evaluierung interaktiver, comput- ergestützter Lernmaterialien für eine mathematische Modellierungssoft- ware (MOSAIC), Master’s Thesis

2. Scholz, K. (2018): Systematische, verfahrenstechnische Modellierung und Simulation unter Verwendung standardisierter Software-Schnittstellen: An- wendung auf einen Trennwandkolonnen-Prozess zur Destillation von Fettsäuren, Diplomarbeit

283

List of Figures

2.1 Flowsheeting overview ...... 7 2.2 CO Interface for Unit Operations ...... 24

3.1 EQU - LATEX equation rendered ...... 43 3.2 EQS - adding a connected element ...... 47 3.3 EQS - function application ...... 49 3.4 EQS - external port ...... 50 3.5 Conn Editor - basic variable matching ...... 51 3.6 Analysis - Incidence matrix ...... 61 3.7 Analysis - Block decomposition example ...... 62 3.8 Analysis - Bordered block decomposition example ...... 63 3.9 Top level workfow activity diagram ...... 64 3.10 Kuntsche modelling and simulation system ...... 66 3.11 Activity diagram for model development ...... 67 3.12 Activity diagram for model adaptation ...... 68

4.1 Hierarchy view ...... 82 4.2 Index pool in simulation ...... 89 4.3 UML Engineering Unit Set ...... 91 4.4 Engineering Unit Editor ...... 92 4.5 UML class diagram of EngineeringUnit and EngineeringDimension 94 4.6 Engineering Unit Set Editor ...... 96 4.7 Function class diagram with examples ...... 102 4.8 Function Application for vector-valued Function ...... 104 4.9 Parameter Classifcation in Simulation Editor ...... 106 4.10 Adding a port to an equation system ...... 108 4.11 Visualization of a fowsheet ...... 110 4.12 UDLS external functions ...... 112 4.13 UDLS code generation properties ...... 115 4.14 Unit Operation Export Editor GUI - Model ...... 118

285 List of Figures

4.15 Export Editor GUI - Code Generation ...... 120 4.16 Implementation overview ...... 122 4.17 Export Editor GUI - Server Panel ...... 126 4.18 Implementation focus ...... 128 4.19 VarSpecViewer ...... 132

5.1 Export Editor GUI - Adjustable Parameters of membrane separation example ...... 140 5.2 Export Editor GUI - Code generation options of membrane separation example ...... 141 5.3 Export Editor GUI - Adjustable Parameters of MixerSplitter example ...... 144 5.4 Export Editor GUI - Code generation options of MixerSplitter example ...... 147 5.5 ASPEN PLUS - Results of MixerSplitter simulation example . . . 148 5.6 COFE - Results of MixerSplitter simulation example ...... 149 5.7 Initial Deisobutanizer model block diagram ...... 150 5.8 Initial Deisobutanizer model screenshot ...... 151 5.9 Deisobutanizer model block diagram after model partition . . . . 154 5.10 Deisobutanizer model block diagram after function separation . . 155 5.11 Deisobutanizer function separation screenshot ...... 156 5.12 Deisobutanizer port addition screenshot ...... 159 5.13 Deisobutanizer parameter addition screenshot ...... 161 5.14 Final Deisobutanizer with CAPE-OPEN ...... 164 5.15 TwoCompoundColumn in ASPEN Plus ...... 166 5.16 TwoCompoundColumn results in ASPEN Plus ...... 167 5.17 Visualization of Equation-based Flowsheeting ...... 169 5.18 Hierarchy of Equation-based Flowsheeting Example ...... 170

B.1 Export Editor GUI - Model ...... 191 B.2 Export Editor GUI - Iteration and Design Variables ...... 193 B.3 Export Editor GUI - Fixed and Calculated Variables ...... 194 B.4 Export Editor GUI - Adjustable Parameters ...... 195 B.5 Export Editor GUI - Open Ports ...... 197 B.6 Export Editor GUI - Code Generation ...... 199 B.7 Export Editor GUI - Server Panel ...... 203

286 List of Figures

E.1 UML - Optimization ...... 212 E.2 UML - Engineering unit and unit set ...... 213 E.3 UML - Unit operation ...... 214

F.1 COFE - Results of MixerSplitter simulation example (increased heating duty) using ASPEN properties ...... 226 F.2 COFE - Results of MixerSplitter simulation example (increased heating duty) using TEA properties ...... 227 F.3 COFE unit operation selection: 32-bit TwoCompoundColumn . . 259 F.4 COFE property package defnition: SRK with I-Butane and N- Butane ...... 260 F.5 ASPEN PLUS: TEA property package loaded via CAPE-OPEN . 261 F.6 ASPEN PLUS feed material defnition ...... 262

If not stated otherwise, all images, graphics or fgures in this thesis were created by the author himself.

287

List of Tables

2.1 Table of ISQ base quantities ...... 10

3.1 Examples for Variables ...... 42

4.1 Function call matrix, allowed combinations have a checkmark . . 102

5.1 Ports of the membrane model ...... 139 5.2 Units of measurement of the mixer and splitter model ...... 143 5.3 Parameters of the mixer and splitter model ...... 145 5.4 Ports of the mixer and splitter model ...... 145 5.5 Connector connecting the condenser to the trays system . . . . . 152 5.6 Connector connecting the reboiler to the trays system ...... 153 5.7 Feed connector for input port defnition ...... 158 5.8 Connector for output port defnitions ...... 158

B.1 Server creation status and meaning ...... 204

289

Bibliography

Abrams, Denis S. and John M. Prausnitz (1975). “Statistical thermodynamics of liquid mixtures: A new expression for the excess Gibbs energy of partly or completely miscible systems”. In: AIChE Journal 21.1, pp. 116–128. issn: 0001-1541. doi: 10.1002/aic.690210115 (cit. on p. 15). Aspen Custom Modeler (2019). url: http://home.aspentech.com/products/ pages/aspen-custom-modeler (visited on 03/24/2019) (cit. on p. 19). Aspen PLUS (2019). url: http://home.aspentech.com/products/engineering/ aspen-plus (visited on 03/24/2019) (cit. on p. 19). Aubry, Alexis, Hervé Panetto, and Michele Dassisti (2015). “Toward an interoperable software platform for sustainable energy”. In: Computer Science and Information Systems 12.3, pp. 1079–1100. issn: 1820-0214. doi: 10.2298/ CSIS141110012A (cit. on p. 35). Baharev, Ali, Ferenc Domes, and Arnold Neumaier (2017). “A robust approach for fnding all well-separated solutions of sparse systems of nonlinear equations”. In: Numerical Algorithms 76, pp. 163–189. issn: 1572-9265. doi: 10. 1007/s11075-016-0249-x. url: https://doi.org/10.1007/s11075-016- 0249-x (cit. on p. 28). Barrett, William Martin and Jun Yang (2005). “Development of a chemical process modeling environment based on CAPE-OPEN interface standards and the Microsoft .NET framework”. In: Computers & Chemical Engineering 30.2, pp. 191–201. issn: 00981354. doi: 10.1016/j.compchemeng.2005.08.017 (cit. on p. 33). Barz, Tilman et al. (2011). “An efcient sparse approach to sensitivity generation for large-scale dynamic optimization”. In: Computers & Chemical Engineering 35.10, pp. 2053–2065 (cit. on p. 59). Baykal, Ali Can (2014). “Entwicklung und Evaluierung interaktiver, comput- ergestützter Lernmaterialien für eine mathematische Modellierungssoftware (MOSAIC)”. MA thesis. Technische Universität Berlin (cit. on p. 40).

291 Bibliography

Belaud, Jean-Pierre, Bertrand Braunschweig, and M. White (2002). “The CAPE- OPEN Standard: Motivations, Development Process, Technical Architecture and Examples: Chapter 4.4”. In: Software architectures and tools for computer aided process engineering. Ed. by Bertrand Braunschweig and Rafqul Gani. Computer-aided chemical engineering. Amsterdam and Boston: Else- vier, pp. 303–332. isbn: 0444508279 (cit. on p. 22). Braunschweig, Bertrand et al. (1999). CAPE-OPEN: Experiences from a Stan- dardization Efort in Chemical Industries. Aachen (cit. on p. 22). Bublitz, Saskia et al. (2017). “Analysis and Decomposition for Improved Con- vergence of Nonlinear Process Models in Chemical Engineering”. In: Chemie Ingenieur Technik 89.11, pp. 1503–1514. issn: 0009286X. doi: 10.1002/cite. 201700041 (cit. on p. 28). Buzzi-Ferraris, Guido and Flavio Manenti (2012). “BzzMath”. In: 22nd European Symposium on Computer Aided Process Engineering. Ed. by I. D. L. Bogle and Michael Fairweather. Vol. 30. Computer Aided Chemical Engineering. Amster- dam and Boston: Elsevier and IChemE, pp. 1312–1316. isbn: 9780444594310. doi: 10.1016/B978-0-444-59520-1.50121-4 (cit. on p. 59). Cano, Alejandro et al. (2009). Deployment of a gPROMS-based three-phase reactor model as a CAPE-OPEN unit operation within PRO/II (cit. on pp. 34, 36). ChemCAD (2019). url: http://www.chemstations.com/ (visited on 03/24/2019) (cit. on p. 19). Chen, Weifeng, Zhijiang Shao, and Jixin Qian (2009). “Interfacing IPOPT with Aspen Open Solvers and CAPE-OPEN”. In: 10th International symposium on process systems engineering. Ed. by Rita Maria de Brito Alves, Cláudio Augusto Oller do Nascimento, and Evaristo Chalbaud Biscaia JR. Vol. 27. Computer-aided chemical engineering. Amsterdam and Boston, Mass: Elsevier, pp. 201–206. isbn: 9780444534729. doi: 10.1016/S1570-7946(09)70254-8 (cit. on p. 34). Coatta, Terry (2007). “Corba: Gone but (Hopefully) Not Forgotten”. In: Queue 5.4. issn: 1542-7730. doi: 10.1145/1255421.1388786. url: http://doi.acm. org/10.1145/1255421.1388786 (cit. on p. 30). Dijkstra, Edsger Wybe (1982). Selected writings on computing: A personal perspective. Edsger W[ybe] Dijkstra. (Texts and monographs in computer science). New York, Heidelberg, Berlin: Springer-Verl. isbn: 0-387-90652-5 (cit. on p. 12).

292 Bibliography

Domancich, Alejandro O. et al. (2010). “Systematic generation of a CAPE-OPEN compliant simulation module from GAMS and FORTRAN models”. In: Chem- ical Engineering Research and Design 88.4, pp. 421–429. issn: 02638762. doi: 10.1016/j.cherd.2009.07.022 (cit. on pp. 35, 37). Dulmage, A. L. and N. S. Mendelsohn (1958). “Coverings of bipartite graphs”. In: Canadian Journal of Mathematics 10.0, pp. 517–534. issn: 0008-414X. doi: 10.4153/CJM-1958-052-0 (cit. on p. 60). Fredenslund, Aage, Russell L. Jones, and John M. Prausnitz (1975). “Group- contribution estimation of activity coefcients in nonideal liquid mixtures”. In: AIChE Journal 21.6, pp. 1086–1099. issn: 0001-1541. doi: 10.1002/aic. 690210607 (cit. on p. 15). Galassi, Mark et al (2009). GNU scientifc library reference manual. Third edition (v1.12). Bristol: Network Theory Limited. isbn: 0954612078 (cit. on p. 59). Gozálvez-Zafrilla, José M. et al. (2015). “Implementation of membrane models on a CAPE-OPEN tool to simulate a process including RO membranes”. In: Desalination and Water Treatment 56.13, pp. 3494–3500. issn: 1944-3994. doi: 10.1080/19443994.2014.995718 (cit. on p. 35). Gross, Joachim and Gabriele Sadowski (2001). “Perturbed-Chain SAFT: An Equation of State Based on a Perturbation Theory for Chain Molecules”. In: Industrial & Engineering Chemistry Research 40.4, pp. 1244–1260. issn: 0888- 5885. doi: 10.1021/ie0003887 (cit. on p. 15). Henning, Michi (2006). “The Rise and Fall of CORBA”. In: Queue 4.5, pp. 28–34. issn: 1542-7730. doi: 10.1145/1142031.1142044. url: http://doi.acm. org/10.1145/1142031.1142044 (cit. on pp. 30, 121). Hindmarsh, Alan C et al. (2005). “SUNDIALS: Suite of nonlinear and diferential/algebraic equation solvers”. In: ACM Transactions on Mathematical Soft- ware (TOMS) 31.3, pp. 363–396 (cit. on pp. 116, 124). ISO (2009). Quantities and units - Part 1: General. Standard. Geneva, CH: In- ternational Organization for Standardization (cit. on p. 8). Junghanns, Andreas and Torsten Blochwitz (2018). “10 years of FMI: Where are we now? Where do we go?” In: Proceedings of the second Japanese Mod- elica conference. Ed. by Yutaka Hirano and Sameer Kher. Tokyo, p. 6. url: https://www.modelica.org/events/modelica2018japan/presentation/ 10_Years_of_FMI.pdf (cit. on p. 32). Kisala, T. P. et al. (1987). “Sequential modular and simultaneous modular strategies for process fowsheet optimization”. In: Computers & Chemical Engineer-

293 Bibliography

ing 11.6, pp. 567–579. issn: 00981354. doi: 10.1016/0098-1354(87)87003-5 (cit. on p. 16). Köller, Jörg and J.-Christian Töbermann (2002). Global CAPE-OPEN Migration Cookbook. url: http://www.colan.org/wp- content/uploads/2016/06/ D822_migration_cookbook.pdf (visited on 03/24/2019) (cit. on pp. 33, 36). Kraus, Robert (2015). Concepts and implementation of collaborative modeling in MOSAIC. doi: 10.14279/depositonce-4487 (cit. on pp. 40, 41, 54, 55, 60, 62, 63, 86, 211). Kulikov, V. et al. (2005). “Modular dynamic simulation for integrated particulate processes by means of tool integration”. In: Chemical Engineering Science 60.7, pp. 2069–2083. issn: 00092509. doi: 10.1016/j.ces.2004.11.037 (cit. on p. 17). Kuntsche, Stefan (2013). Modular model specifcation on the documentation level: Concepts and application in a web-based modeling environment: Berlin, Techn. Univ., Diss., 2013. url: http://dx.doi.org/10.14279/depositonce-3642 (cit. on pp. 39, 41, 48, 56, 57, 66, 84, 107, 211). CO-LaN Consortium (2011). Thermodynamic and Physical Properties v1.1. url: http://www.colan.org/wp-content/uploads/2015/05/CO%5C_Thermo%5C_ 1.1%5C_Specification%5C_311.pdf (visited on 11/01/2018) (cit. on p. 26). MATLAB (2019). url: https://www.mathworks.com/products/matlab.html (visited on 03/24/2019) (cit. on p. 34). Merchan, Victor Alejandro et al. (2014). “Extending Documentation-Based Mod- els towards an Efcient Integration into Commercial Process Simulators”. In: Chemie Ingenieur Technik 86.7, pp. 1117–1129. issn: 0009286X. doi: 10 . 1002/cite.201400014 (cit. on p. 3). Montagna, J. M. and O. A. Iribarren (1988). “Optimal computation sequence in the simulation of chemical plants”. In: Computers & Chemical Engineering 12.1, pp. 71–79. issn: 00981354. doi: 10.1016/0098-1354(88)85006-3 (cit. on p. 16). Morales-Rodríguez, Ricardo et al. (2008). “Use of CAPE-OPEN standards in the interoperability between modelling tools (MoT) and process simulators (Simulis® Thermodynamics and ProSimPlus)”. In: Chemical Engineering Re- search and Design 86.7, pp. 823–833. issn: 02638762. doi: 10.1016/j.cherd. 2008.02.022 (cit. on pp. 33, 36).

294 Bibliography

Peng, Ding-Yu and Donald B. Robinson (1976). “A New Two-Constant Equation of State”. In: Industrial & Engineering Chemistry Fundamentals 15.1, pp. 59– 64. issn: 0196-4313. doi: 10.1021/i160057a011 (cit. on p. 15). Preisig, Heinz A. (2010). “Constructing and maintaining proper process models”. In: Computers & Chemical Engineering 34.9, pp. 1543–1555. issn: 00981354. doi: 10.1016/j.compchemeng.2010.02.023 (cit. on p. 32). Preisig, Heinz A. (2014). “Visual Modelling”. In: Proceedings of the 8th In- ternational Conference on Foundations of Computer-Aided Process Design. Vol. 34. Computer Aided Chemical Engineering. Elsevier, pp. 729–734. isbn: 9780444634337. doi: 10.1016/B978-0-444-63433-7.50106-1 (cit. on p. 32). Preisig, Heinz A. (2015). “Constructing Process Models Systematically”. In: Chem- ical Engineering Transactions 43, pp. 1381–1386. doi: 10.3303/CET1543231 (cit. on p. 32). Renon, Henri and J. M. Prausnitz (1968). “Local compositions in thermodynamic excess functions for liquid mixtures”. In: AIChE Journal 14.1, pp. 135–144. issn: 0001-1541. doi: 10.1002/aic.690140124 (cit. on p. 15). Rossum, G. van (1995). Python tutorial. Tech. rep. CS-R9526. Amsterdam: Cen- trum voor Wiskunde en Informatica (CWI) (cit. on p. 124). Sales-Cruz, Mauricio and Rafqul Gani (2003). “A modelling tool for diferent stages of the process life”. In: Dynamic Model Development. Vol. 16. Computer Aided Chemical Engineering. Elsevier, pp. 209–249. isbn: 9780444514653. doi: 10.1016/S1570-7946(03)80076-7 (cit. on p. 33). Schopfer, G. et al. (2005). “A library for equation system processing based on the CAPE-OPEN ESO Interface”. In: European Symposium on Computer- Aided Process Engineering-15, 38th European Symposium of the Working Party on Computer Aided Process Engineering. Vol. 20. Computer Aided Chemical Engineering. Elsevier, pp. 1573–1578. isbn: 9780444519870. doi: 10.1016/ S1570-7946(05)80104-X (cit. on pp. 27, 33, 36). SciLab (2019). url: https://www.scilab.org (visited on 03/24/2019) (cit. on p. 34). Soave, Giorgio (1972). “Equilibrium constants from a modifed Redlich-Kwong equation of state”. In: Chemical Engineering Science 27.6, pp. 1197–1203. issn: 00092509. doi: 10.1016/0009-2509(72)80096-4 (cit. on p. 15). Stankiewicz, Andrzej I. and Jacob A. Moulijn (2000). “Process Intensifcation: Transforming Chemical Engineering”. In: Chemical Engineering Progress, pp. 22– 34 (cit. on p. 13).

295 Bibliography

Tolksdorf, Gregor, Erik Esche, Jasper van Baten, et al. (2016). “Tailor-Made Modeling and Solution of Novel Process Units by Modular CAPE-OPEN-based Flowsheeting”. In: 26th European Symposium on Computer Aided Process En- gineering. Vol. 38. Computer Aided Chemical Engineering. Elsevier, pp. 787– 792. isbn: 9780444634283. doi: 10.1016/B978- 0- 444- 63428- 3.50136- 3 (cit. on p. 137). Tolksdorf, Gregor, Erik Esche, Günter Wozny, et al. (2018). “Customized Code Generation based on User Specifcations for Simulation and Optimization”. In: Computers & Chemical Engineering. issn: 00981354. doi: 10.1016/j. compchemeng.2018.12.006 (cit. on p. 58). van Baten, Jasper (2009). Rapid Prototyping of Unit Operation Models Using Generic Tools and CAPE-OPEN. Nashville (cit. on pp. 34, 36, 137). van Baten, Jasper (2017). COBIA - Phase 2. url: http://www.colan.org/wp- content/uploads/2017/10/Y17_COEU_COBIA.pdf (visited on 05/09/2018) (cit. on p. 23). van Baten, Jasper and Michel Pons (2014). “CAPE-OPEN: Interoperability in Industrial Flowsheet Simulation Software”. In: Chemie Ingenieur Technik 86.7, pp. 1052–1064. issn: 0009286X. doi: 10.1002/cite.201400009 (cit. on pp. 21, 22). van Baten, Jasper and Richard Szczepanski (2011). “A thermodynamic equilibrium reactor model as a CAPE-OPEN unit operation”. In: Computers & Chemical Engineering 35.7, pp. 1251–1256. issn: 00981354. doi: 10.1016/j. compchemeng.2010.07.016 (cit. on p. 35). von Wedel, Lars (2003). “An Environment for Heterogeneous Model Management in Chemical Process Engineering”. Dissertation. Aachen: Rheinisch-Westfälische Technische Hochschule (cit. on pp. 33, 36). Wedel, Lars von, V. Kulikov, and Wolfgang Marquardt (2008). “LNCS 4970 - An Integrated Environment for Heterogeneous Process Modeling and Simulation”. In: Collaborative and Distributed Chemical Engineering, pp. 477–492 (cit. on pp. 34, 36). Wegstein, J. H. (1958). “Accelerating convergence of iterative processes”. In: Communications of the ACM 1.6, pp. 9–13. issn: 00010782. doi: 10.1145/ 368861.368871 (cit. on p. 16). Wiedau, Michael et al. (2019). “ENPRO Data Integration: Extending DEXPI Towards the Asset Lifecycle”. In: Chemie Ingenieur Technik 91.3, pp. 240– 255. issn: 0009286X. doi: 10.1002/cite.201800112 (cit. on p. 12).

296