Modellierung und Optimierung einer extraktiven Trennwandkolonne

Transcrição

Institut für Chemie
Masterstudiengang Chemie
Forschungsbericht Chemische Verfahrensentwicklung
Modellierung und Optimierung einer extraktiven
Trennwandkolonne
Vorgelegt von:
Nils Ayral, Enno Gent, Gabriele Tomaschun
Betreuender Gutachter:
Hon.-Prof. Dr. Jürgen Rarey
Oldenburg, 19. Juli 2015
Inhaltsverzeichnis
1 Einleitung und Motivation
1
2 Grundlagen
2.1 Thermische Trennverfahren – Rektifikation . . . . . . . . . .
2.2 Trennung binärer Azeotrope und eng siedender Gemische . .
2.3 Realisierung der extraktiven Rektifikation . . . . . . . . . .
2.3.1 Industrielles Beispiel: Aromaten-Aliphaten-Trennung
2.4 Das vorliegende Trennproblem . . . . . . . . . . . . . . . . .
3
3
4
6
7
8
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Simulation
11
3.1 Direkte Sequenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Trennwandkolonne . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4 Optimierung der Trennwandkolonne
4.1 Scans . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1 Vorgehen . . . . . . . . . . . . . . . . .
4.1.2 Ergebnisse . . . . . . . . . . . . . . . . .
4.2 Optimierung mittels evolutionärem Algorithmus
4.2.1 Vorgehen . . . . . . . . . . . . . . . . .
4.2.2 Arbeitsweise evolutionärer Algorithmen .
4.2.3 Ergebnisse . . . . . . . . . . . . . . . . .
4.3 Vergleich zwischen Scan und Solver . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
18
18
20
24
24
26
28
30
5 Zusammenfassung und Ausblick
33
A Programmcode Scan
35
B Programmcode Solver
43
C Übersicht Solveroptionen
49
Literaturverzeichnis
53
Erklärung
55
Kapitel 1
Einleitung und Motivation
Die extraktive Rektifikation ist ein Verfahren zur Trennung von eng siedenden Stoffgemischen und Azeotropen. Dabei wird die Trennung mit Hilfe einer Zusatzkomponente,
dem sogenannten Extraktions- oder Schleppmittel, welches jedoch in einer zweiten
Rektifikationskolonne regeneriert werden muss, ermöglicht. Um die Kosten einer
solchen Anlage zu minimieren, können die Extraktions- und die Regeneratorkolonne
zu einer Trennwandkolonne vereinigt werden.
Ziel dieses Design-Projects ist die Optimierung einer in Aspen Plus simulierten extraktiven Trennwandkolonne (engl. EDWC, extractive devided wall column) mit Hilfe des in Microsoft Excel implementierten evolutionären Algorithmus (EA) der Firma Frontline Systems. Diese Aufgabenstellung enthält drei wesentliche Teilprobleme: (i) die Simulation einer extraktiven Trennwandkolonne in
Aspen Plus, (ii) das Schaffen einer Schnittstelle zwischen Aspen Plus und Excel mit Hilfe der Programmiersprache Visual Basic und (iii) die systematische
Variation sowie eine gezielte Optimierung kostenrelevanter Betriebsparameter der
Simulation aus Excel heraus. Letztendlich soll – unter der Randbedingung von
Produktreinheiten > 99 % – der Betriebspunkt mit den geringsten Energiekosten
gefunden werden. Abbildung 1 fasst die Motivation des vorliegenden Design-Projects
grafisch zusammen.
Ziel des vorliegenden Design-Projects ist hingegen nicht die bis ins kleinste Detail
ausgearbeite Simulation einer extraktiven Trennwandkolonne. Im Fokus dieser Arbeit
stehen vielmehr die Teilprobleme (ii) und (iii), die in letzter Konsequenz auf die
Anwendung des evolutionären Algorithmus als Optimierungsverfahren abzielen. In
diesem Sinne ist das zugrunde liegende Trennproblem auch keins von brennender wissenschaftlicher Aktualität. Es handelt sich um die Separation eines azeotropen BenzolCyclohexan-Gemisches (als Modellsystem für eine Aromaten-Aliphaten-Trennung)
mit Hilfe des Schleppmittels N -Formylmorpholin (NFM). Dieser Prozess findet auch
2
c
im technischen Maßstab Anwendung und ist als Morphylane Prozess der Firma
Krupp Uhde GmbH patentrechtlich geschützt.
Abbildung 1: Problemstellung im vorliegenden Design-Project.
Kapitel 2
Grundlagen
Die Trennung von Stoffgemischen gehört zu den wichtigsten verfahrenstechnischen
Grundoperationen. Dabei ist die Isolierung möglichst reiner Komponenten für anschließende chemische Reaktionen das Ziel. Im Allgemeinen können Stoffgemische
thermisch oder mechanisch getrennt werden. Letztere Trennverfahren sind nicht
Gegenstand der vorliegenden Arbeit und werden nicht weiter erläutert.
2.1 Thermische Trennverfahren – Rektifikation[1,2]
Bei thermischen Trennverfahren erfolgt die Trennung des Stoffgemisches entweder
durch Zufuhr von Energie oder durch Zugabe eines Schleppmittels (engl. entrainer),
welches mit einer der Komponenten bevorzugt wechselwirkt.
Ein Beispiel für ein Trennverfahren mit Energie als Trennhilfsmittel ist die
Rektifikation, die als Hintereinanderschaltung vieler Destillationsschritte in einer aus
Einbauten (z.B. Glockenböden oder andere Füllkörper) zusammengesetzten Kolonne
zu verstehen ist. Durch die große Dichtedifferenz auf jeder darin verbauten Trennstufe
können der Dampf und die Flüssigkeit leicht voneinander getrennt werden. Im
Gegensatz zu einer Kaskade von Einfachdestillationen hat die Rektifikationskolonne
den Vorteil, dass der Dampf direkt in die Flüssigkeit der darüber liegenden Stufe
eingeleitet wird und somit ein intensiverer Stoff- und Wärmeaustausch ermöglicht wird.
Weitere Vorteile der Rektifikation sind die kontinuierliche Durchführbarkeit sowie
der Umstand, dass ausschließlich Fluide auftreten, welche mechanisch vergleichsweise
einfach handhabbar sind. Darüber hinaus hilft die gute Expertise im Umgang mit
Dampf-Flüssig-Gleichgewichten (VLEs) – an dieser Stelle seien das McGabe-ThieleVerfahren und andere Shortcut-Methoden genannt – ganz erheblich bei der Auslegung
von Rektifikationskolonnen.
4
2.2 Trennung binärer Azeotrope und eng siedender Gemische
Im Folgenden soll die Arbeitsweise einer Rektifikationskolonne anhand von Abbildung 2 erläutert werden.
Abbildung 2: Prinzipieller Aufbau einer Rektifikationskolonne.[3]
Zunächst wird der Zulauf, auch Feedstrom oder kurz Feed genannt, in einen
der mittleren Böden der Kolonne eingespeist. Der Kolonnenteil unterhalb dieses
Feedbodens wird als Abtriebsteil bezeichnet und in ihm wird die schwer flüchtige
Komponente angereichert. In dem Teil oberhalb des Feedbodens, dem sogenannten
Verstärkungsteil, ist die leichtflüchtige Komponente in entsprechend höherem Anteil
enthalten. Insgesamt bildet sich ein Temperaturgradient vom Sumpf (heißer) bis
zum Kopf (kälter) der Kolonne aus. Da auf jedem Kolonnenboden ein intensiver
Austausch zwischen der kälteren herabfließenden Flüssigkeit und dem heißeren aufsteigenden Wärmestrom erfolgt, wird die Einstellung des Dampf-Flüssig-Gleichgewichts
kontinuierlich gestört, was letztlich die Triebkraft für die Stofftrennung darstellt.[4]
2.2 Trennung binärer Azeotrope und eng
siedender Gemische[2,3]
Das Auftreten azeotroper Punkte, in denen zwei oder mehrere Komponenten die
gleiche Flüssig- und Dampfphasenzusammensetzung haben und der Trennfaktor
α12 = 1 ist, stellt ein Problem bei der Stofftrennung dar. Aber auch eng siedende
5
2 Grundlagen
Systeme, in denen der Trennfaktor nur wenig von eins abweicht, sind ohne Weiteres
kaum rektifikativ zu trennen. Denn je näher α12 am Wert 1 liegt, desto mehr
theoretische Böden werden für die gleiche Stofftrennung benötigt. Im azeotropen
Grenzfall α12 = 1 bedürfe es sogar unendlich vieler Böden. Da jeder zusätzliche
Boden aber zusätzlichen Materialkosten entspricht, wird eine solche Stofftrennung
schnell unwirtschaftlich. Daher bedient man sich Sonderverfahren, um Azeotrope
und eng siedende Systeme durch Rektifikation aufzutrennen.
α12 =
γ1 P1S
K1
=
K2
γ2 P2S
(1)
Wie Gleichung 1 zu entnehmen ist, hängt α12 von den Sättigungsdampfdrücken PiS
PS
und Aktivitätskoeffizienten γi ab. Folglich stellt die Veränderung des Verhältnisses P1S ,
2
welches beispielsweise durch Druckänderungen erzielt werden kann, eine Möglichkeit
dar, das azeotrope Verhalten zu beeinflussen oder sogar ganz zum Verschwinden zu
bringen. Beispiele für solch eine Azeotropentrennung sind die Vakuumrektifikation
und die Zweidruckrektifikation.
Eine elegantere Möglichkeit zur Trennung von azeotropen Gemischen ist die
Azeotropentrennung unter Verwendung eines Schleppmittels (häufig auch
als Entrainer oder Solvent bezeichnet), welches bevorzugt mit einer der beiden
Komponenten im Gemisch wechselwirkt und auf diese Weise das Verhältnis der
Aktivitätskoeffizienten γγ12 beeinflusst. Beispiele für solch eine Azeotropentrennung
sind die azeotrope und die extraktive Rektifikation.
Bei der azeotropen Rektifikation bildet das Schleppmittel mit einer der Komponenten ein leichter siedendes und leichter zu trennendes Azeotrop (oft ein Heteroazeotrop).
Bei der extraktiven Rektifikation erhöht das schwersiedende Schleppmittel/der Entrainer die Flüchtigkeit einer Komponente relativ zur anderen, indem es mit dieser
einen Komponente bevorzugt wechselwirkt. Konkret bedeutet dies, dass die eine
Komponente in den Sumpf der Kolonne mitgeschleppt wird und die andere am Kopf
abgezogen werden kann. In einem zweiten Rektifikationsprozess muss die mitgeschleppte Komponente vom Entrainer abgetrennt werden. Um diesen Trennprozess
ohne großen Aufwand durchführen zu können, sollte der Siedepunktsunterschied mindestens 40 K betragen. Weiterhin sollte der Entrainer kostengünstig und thermisch
stabil sein sowie keine weiteren Azeotrope ausbilden.
6
2.3 Realisierung der extraktiven Rektifikation
2.3 Technische Realisierung der extraktiven
Rektifikation[5]
Es existieren mehrere Möglichkeiten eine extraktive Rektifikation technisch zu realisieren. Drei im Hinblick auf das vorliegende Trennproblem nennenswerte Kolonnenanordnungen werden im Folgenden kurz vorgestellt.
Abbildung 3: Kolonnenkonfigurationen bei der extraktiven Rektifikation. Abbildungen modifiziert nach Referenz [6].
Direkte Sequenz (siehe Abb. 3, ¶). Das zu trennende Gemisch und der Entrainer (Solvent) werden in eine erste Kolonne eingespeist, an deren Kopf die nicht
mitgeschleppte Komponente A entnommen wird. Das Gemisch aus der mitgeschleppten Komponente B und dem Entrainer wird im Sumpf dieser Extraktionskolonne
abgezogen und in eine zweite Kolonne, die sogenannte Regeneratorkolonne, eingespeist. Hier lässt es sich aufgrund der deutlichen Siedepunktsunterschiede relativ
einfach trennen, sodass B als Kopfprodukt erhalten und der Entrainer im Sumpf
regeneriert wird. Schließlich wird der Entrainer in die erste Kolonne zurückgeführt.
Dies ist die konventionelle Anordnung für eine extraktive Rektifikation.
Thermisch gekoppelte Anordnung (Abb. 3, Ë). Im Gegensatz zur direkten
Sequenz, bei der das Gemisch aus B und Entrainer im Sumpf der Extraktionskolonne
entnommen wird, wird es bei der thermisch gekoppelten Anordnung an der Seite
entnommen. Es wird nun auch nicht mehr in einen mittleren Boden, sondern in den
Sumpf der zweiten Kolonne eingespeist. In dieser zweiten Kolonne wird B als Kopfpro-
7
2 Grundlagen
dukt und ein entsprechend um B verarmtes B-Entrainer-Gemisch im Sumpf erhalten.
Letzteres wird in die erste Kolonne zurückgeführt. Will man die thermisch gekoppelte
Anordnung mit der direkten Sequenz vergleichen, so entspricht der Kolonnenteil
oberhalb der Seitenentnahme der linken Extraktionskolonne aus Ê und die zweite
Kolonne plus dem Teil unterhalb der Seitenentnahme der rechten Regeneratorkolonne.
Bei gleicher Trennleistung ist die thermisch gekoppelte Anordnung energiesparender
als die direkte Sequenz und benötigt einen Verdampfer weniger.
Extraktive Trennwandkolonne (Abb. 3, Ì). In dieser Anordnung ist die zweite
Kolonne, die genau wie in Ë der Aufreinigung von B dient, in die große Kolonne
eingefasst, aber mittels einer Trennwand räumlich von dieser getrennt. Auch die
übrige Funktionsweise ist identisch mit der thermisch gekoppelten Anordnung, sodass
von einer thermisch gekoppelten, integrierten Trennwandkolonne gesprochen werden
kann. Die Trennwandkolonne bietet den Vorteil von noch weiter verringerten Energieund Materialkosten. Ihr entscheidender Nachteil besteht allerdings darin, dass zusätzliche kostenrelevante Betriebsparameter berücksichtigt werden müssen, welcheseine
effiziente Auslegung und praktische Anwendung dieses Kolonnentyps bis etwa zur
Jahrtausendwende unmöglich machten. Frühe erfolgversprechende Untersuchungen
gehen auf die Firma Krupp Uhde GmbH zurück. Ihr gelang es unter Verwendung
eines evolutionären Algorithmus (EA), möglichst kostengünstige Kombinationen von
Betriebsparametern in einer entsprechenden Prozesssimulation aufzuspüren und diese
mit einer kleinen Testanlage zu verifizieren.[5] Das diesem Bericht zugrunde liegende
Desgin-Project
k basiert auf ebenjenen Untersuchungen.
2.3.1 Industrielles Beispiel: Aromaten-Aliphaten-Trennung[5]
extraktive
Seit circa 15 Jahren werden erste Trennwandkolonnen in der Industrie eingesetzt.
Pionier auf diesem Gebiet ist Krupp Uhde, die zusammen mit Aral Aromatics (inzwischen: Arsol Aromatics) eine erste Trennwandkolonne entwickelten. Sie basiert
c
auf dem patentrechtlich geschützten Morphylane Prozess – einer direkten Sequenz
zur Trennung von Aromaten und Aliphaten mit Hilfe von N -Formylmorpholin als
Entrainer. Die zunächst noch als Pilot Plant konstruierte und ausgelegte Anlage
zeigte schnell vielversprechende Ergebnisse, die den Weg zu einer großtechnischen
Anwendung von extraktiven Trennwandkolonnen ebnen. Die folgende Grafik stellt
c
den klassischen Morphylane Prozess und die darauf basierte Trennwandkolonne
auf Basis von Daten aus dem Jahre 2005 gegenüber.
8
2.4 Das vorliegende Trennproblem
Abbildung 4: Vergleich der Konzepte der extraktiven Rektifikation.[6]
Hervorhebenswert ist die beeindruckende Energieersparnis von 16 % gegenüber
der direkten Trennsequenz. Ebenfalls von Vorteil sind die geringeren Materialkosten,
da weniger Bauteile benötigt werden, sowie die Platzersparnis von 60-80 %. Unterm
Strich bietet die Trennwandkolonne somit immense Investitions- und Betriebskosteneinsparungen.
2.4 Das vorliegende Trennproblem
Das diesem Bericht zugrunde liegende Trennproblem ist die Trennung eines AliphatenAromaten-Gemisches, welches durch das Modellsystem Cyclohexan-Benzol repräsentiert sein soll. Der Siedepunktsunterschied beider Komponenten beträgt lediglich
0.7 K, sodass eine schleppmittelfreie, rektifikative Trennung wirtschaftlich unmöglich
ist.
Die extraktive Rektifikation unter Verwendung des Schleppmittels N -Formylmorpholin eignet sich hingegen hervorragend zur Trennung dieses Stoffgemisches. Dieser Umstand soll kurz anhand der beiden in Abbildung 5 gezeigten T-x,y-Diagramme
erläutert werden. Ihnen ist zu entnehmen, dass ein Gemisch aus Cyclohexan und
2 Grundlagen
9
Benzol bei 77.3 ◦ C ein Azeotrop von der ungefähren Zusammensetzung 1:1 (eher
9:11) aufweist, wohingegen das Benzol-NFM-Gemisch kein Azeotrop bildet und aufgrund der großen Siedepunktsdifferenz von 156 K leicht zu trennen ist. Folglich stellt
N -Formylmorpholin ein geeignetes Schleppmittel zur extraktiven Rektifikation eines
Cyclohexan-Benzol-Gemisches dar.
Abbildung 5: Mit UNIFAC berechnete T-x,y-Diagramme der binären Gemische
C6 C6 /C6 C12 und C6 C6 /NFM.
Kapitel 3
Simulation
Alle im Folgenden beschriebenen Simulationen wurden mit Hilfe von Aspen Plus
in der Programmversion 8.6 realisiert. Als Rechenmethode wurde UNIFAC ausgewählt. Als Feedstrom wurden 200 kmol/h Benzol und 100 kmol/h Cyclohexan
vorgegeben. Als Energiepreise wurden die in Aspen defaultmäßig eingestellten
1.77939 · 10−8 US$/cal für Wärme und 8.87502 · 10−10 US$/cal für Wasser verwendet.
3.1 Direkte Sequenz
Zunächst wurde die direkte Sequenz simuliert. In Abbildung 6 sind das zugrunde
liegende Schema sowie das Flowsheet der fertigen Aspen Plus Simulation gegenüber
gestellt.
Abbildung 6: Schematische (links)[6] und simulierte Darstellung (rechts) der direkten
Sequenz.
12
3.2 Trennwandkolonne
Dabei sind die einander entsprechenden Kolonnen gleichfarbig hervorgehoben. In
der ersten kolonne (grün) wird Cyclohexan am Kopf erhalten und das Benzol-NFMGemisch dem Sumpf entnommen. Es wird anschließend in die Regeneratorkolonne
(rot) eingespeist und getrennt. Das Sumpfprodukt NFM wird in die erste Kolonne
zurückgeführt.
Durch Simulation der direkten Sequenz konnte bereits ein gutes Gefühl für sinnvolle
Betriebsparameter erhalten werden, welches sich als hilfreich bei der Auslegung
der im nächsten Abschnitt beschriebenen Trennwandkolonne erweisen sollte. Eine
Kostenoptimierung wurde jedoch nicht vergenommen.
Nachdem die relativ einfache direkte Trennsequenz erfolgreich simuliert werden
konnte, erfolgte die Simulation der deutlich anspruchsvolleren extraktiven Trennwandkolonne. Abbildung 7 zeigt eine Gegenüberstellung des zugrunde liegenden
Schemas und des dazugehörigen, jedoch noch stark vereinfachten Flowsheets der
Aspen Plus Simulation. Erneut sind einander entsprechende Kolonneteile gleichfarbig hervorgehoben.
Abbildung 7: Schematische (links)[6] und simulierte Darstellung (rechts) der extraktiven Trennwandkolonne.
13
3 Simulation
Das Benzol-Cyclohexan-Gemisch wird in einen mittleren Boden und der NFMStrom in einen höheren Boden der grün unterlegten Kolonne („COLLEFT“) eingespeist. Das leichtersiedende Cyclohexan wird direkt am Kopf abgezogen und das
mitgeschleppte Benzol fließt zusammen mit dem NFM in die blau unterlegte Stripperkolonne („STRIP“) hinab, in dessen Sumpf das Löungsmittel regeneriert und an
„COLLEFT“ zurückgeführt wird. Am Kopf der Stripperkolonne wird der mit Benzol
angereicherte Benzol-NFM-Dampf auf die Kolonnen „COLLEFT“ und „COLRIGHT“
aufgeteilt. In der letztgenannten wird das Benzol vom restlichen NFM abgetrennt
und als Kopfprodukt erhalten, während das NFM in die Stripperkolonne hinabfließt.
Das finale Flowsheet, welches neben der vollständigen Kolonnenanordnung auch
die Namen aller Stoff- und Wärmeströme enthält, ist in der folgenden Abbildung
dargestellt.
Abbildung 8: Finales Flowsheet Trennwandkolonne.
Im Vergleich zur vereinfachten Darstellung aus Abbildung 7 sind der Mixer
„MIXSOLV“ für den Makeup-Strom sowie der Wärmetauscher „EXC“ nach der
Stripperkolonne hinzugekommen. Letzerer kühlt den regenerierten NFM-Strom auf
85 ◦ C ab, ehe er „COLLEFT“ zugeführt wird. In einer realen Kolonne sollten die
beim Abkühlen aufgenommene Energiemenge „QEXC“ sowie die beim Kondensieren
der Kopfprodukte freigesetzten Wärmemengen „QCLEFT“ und „QCRIGHT“ zur
14
Deckung des Energiebedarfs „QRSTRIP“ im Verdampfer genutzt werden. Eine entsprechende Modifikation des Flowsheets gelang uns jedoch nicht. Von entscheidender
Bedeutung für die angestrebte Kostenminimierung dieser Trennwandkolonne sind die
Energiekosten, deren Betrag unmittelbar mit den Wärmeströmen – allen voran dem
des Verdampfers „QRSTRIP“ – zusammenhängt. Aufgrund technischer Schwierigkeiten konnten nämlich weder Gesamtjahreskosten noch Betriebs- und Materialkosten
berücksichtigt werden (für Details siehe Anmerkung S. 20).
Kostenrelevante Betriebsparameter. Weiterhin enthält Abbildung 8 eine
Übersicht der kostenrelevanten Betriebsparameter. Sie werden in verschiedenen
Kästchen aufgeführt, die entsprechend ihrem zugehörigen Kolonnenbauteil grün,
blau oder rot eingefärbt sind. So wirken sich für „COLLEFT“ beispielsweise die
Bodenzahl nstages COLLEFT, der Zulaufboden des Entrainers stage NFMIN, der
Feedboden stage FEED und die Flowrate des Entrainers flowrate NFMIN auf die Kosten aus. Nimmt man die Bodenzahlen der beiden übrigen Kolonnen nstages STRIP
und nstages COLRIGHT hinzu, ergeben sich bereits sechs kostenrelevante Parameter.
Dazu kommen noch drei weitere, namentlich die Rücklaufverhältnisse der beiden
Kolonnen reflux ratio COLLEFT und reflux ratio COLRIGHT sowie das Verhältnis der
Dampfströme VLEFT/VRIGHT, die vom Stripper auf diese beiden Kolonnen aufgeteilt werden. Insgesamt handelt es sich bei der Kostenminimierung der simulierten
Trennwandkolonne also um ein neundimensionales Problem, das dem Auffinden des
globalen Minimums einer neundimensionalen Hyperfläche entspricht.
Das Lösen einer solchen Aufgabenstellung erfordert jedoch das Erzeugen enormer
Datenmengen, die ihrerseits nur nach einer immensen Rechenzeit erhalten werden
können. Weiterhin gilt es zu bedenken, dass jeder Satz dieser neun Parameter nicht
nur seine eigenen Kosten besitzt, sondern auch über seine eigenen Produktreinheiten verfügt, was sich als problematisch im Hinblick auf die Vergleichbarkeit der
Ergebnisse auswirkt. Das Problem der nicht vergleichbaren Produktreinheiten kann
allerdings dadurch umgangen werden, dass zunächst einmal nur die ersten sechs
genannten Parameter an Aspen Plus übergeben werden. Sobald die Simulation
gestartet wird, ist es intern mit Hilfe von DesignSpecs möglich, die Rücklaufverhältnisse von „COLLEFT“ und „COLRIGHT“ so einzuregeln, dass die gewünschte
Produktreinheit von >99 % sichergestellt ist. Da aus den angepassten Rücklaufverhältnissen auch noch das Verhältnis VLEFT/VRIGHT berechnet werden kann,
lässt sich das ursprünglich neundimensionale Problem auf ein sechsdimensionales
reduzieren, indem drei Parameter in jeder Simulation „on the fly“ berechnet werden.
3 Simulation
15
Aufgrund ihrer Sonderstellung werden diese 3 Parameter auch verblasst in einer
grauen Box dargestellt.
Aber auch das Aufspüren des globalen Minimums einer nur noch sechsdimensionalen Hyperfläche ist an das Erzeugen großer Datenmengen geknüpft. Es bedarf
einer vollständig automatisierten Vorgehensweise, die in diesem Fall über eine Verzahnung mit Microsofts Excel realisiert wird. Mit Hilfe der beiden Strategien
a) systematische Variation in Form eines Scans und b) gezielte Optimierung der kostenrelevanten Betriebsparameter unter Anwendung eines evolutionären Algorithmus
soll die Kostenoptimierung im folgenden Kapitel vorgenommen werden.
Kapitel 4
Optimierung der Trennwandkolonne
Das Finden des globalen Minimums einer sechsdimensionalen Hyperfläche erfordert
eine vollständig automatisiere Vorgehensweise. Sie sollte sicherstellen, dass ausreichend viele (und dazu noch möglichst gute) Kombinationen aus den sechs Parametern
identifiziert werden. Im Idealfall sollte sie sogar in der Lage sein, die zum globalen
Kostenminimum gehörende Kombination zu finden.
Bewerkstelligt wird dies mit Hilfe eines selbstgeschriebenen Computerprogramms,
das auf der einen Seite verschiedene Parameterkombinationen durchspielt und diese
als Input an Aspen Plus übermittelt, wo auf der anderen Seite die Simulation
stattfindet und relevante Größen wie Kosten, Wärmemengen, Produktreinheiten,
Fehlermeldungen etc. als Output zurückgegeben werden. Weiterhin müssen die so
erzeugten Daten verwaltet und gesammelt werden. Aufgrund der guten Dokumentation in der Literatur bietet sich zur Variation des Inputs und Verwaltung des
Outputs Microsofts Tabellenkalkulationssoftware Excel an. Die notwendige Schnittstelle zwischen Aspen Plus und Excel wird mit Hilfe der in Microsoft Office
Produkten implementierten Programmiersprache Visual Basic (kurz VBA, engl.
für Visual Basic for Applications) hergestellt. Abbildung 9 fasst die soeben erläuterte,
programmiertechnische Herausforderung dieses Design-Projects grafisch zusammen.
Abbildung 9: Programmiertechnische Herausforderung.
18
4.1 Scans
Ein weiterer Vorteil von Excel ist der darin implementierte evolutionäre Algorithmus (EA) der Firma Frontline Systems. Er ist für die Optimierung vieldimensionaler
Probleme ausgelegt und soll daher zur gezielten Optimierung der Trennwandkolonne
herangezogen werden. Neben diesem gezielten Verfahren enthält dieses Kapitel ebenfalls die Ergebnisse einer systematischen Variation der Betriebsparameter in Form
eines Scans. Er wird in Unterkapitel 4.1 erläutert und dient im Wesentlichen dem
„Kennenlernen“ der Simulation (kosteneffiziente Punkte, Anteil fehlerhafter Simulationen, sinnvolle Parameterkombinationen) sowie als Referenz für die in 4.2 vorgestellten
Ergebnisse unter Anwendung des evolutionären Algorithmus. In Abschnitt 4.3 werden
die Ergebnisse des Scans und des EA schließlich verglichen.
4.1 Scans
4.1.1 Vorgehen
Nachdem die Trennwandkolonne erfolgreich simuliert werden konnte, musste eine
Schnittstelle zwischen Aspen Plus und Excel geschaffen werden. Es wurde ein
Programm geschrieben, welches zunächst nur einen Satz aus sechs Betriebsparametern
aus Excel einliest, diesen als Input an Aspen übergibt und nach erfolgter Simulation
die gewünschten Outputgrößen zusammen mit dem dazugehörigen Input in ein ExcelArbeitsblatt überträgt. Dieses Programm stellt den Kern des Scans dar. Sobald es
stabil funktionierte, wurde es auf beliebig viele Sätze erweitert, indem nun für jeden
Parameter Ober- und Untergrenzen sowie dazugehörige Inkremente vorgegeben und
diese mit Hilfe einer Schleifenkonstruktion im Programm eingelesen und abgearbeitet
wurden.
Anmerkung: Da die Anwendung des evolutionären Algorithmus in Kapitel 4.2
wesentliche Teile vom Programmcode des Scans übernimmt und darüber hinaus um
einige weitere ergänzt werden muss, wurde zunächst der Scan programmiert. Weil er
weiterhin als Referenz für die Ergebnisse des EA dient und die damit verbundene
Erzeugung einer repräsentativen Datenmenge für einen Teilbereich der Hyperfläche
(insgesamt wurden 29025 Kombinationen gerechnet) eine Woche dauerte, konnte in
der Zwischenzeit am Programmcode für die Anwendung des EA gearbeitet werden.
Im Folgenden wird die Arbeitsweise des Scans knapp anhand eines Flussdiagramms erläutert. Der kommentierte, vollständige Programmcode ist inklusive einem
exemplarischen Output in Anhang A ab Seite 35 aufgeführt.
19
Abbildung 10: Flussdiagramm Scan.
Abbildung 11: Gewählte Scanparameter.
Zunächst müssen im Excel-Arbeitsblatt die gewünschten Scanparameter vorgegeben werden (siehe Abb. 11). Danach wird durch Klicken auf die Schaltfläche
„Run Scan“ ein Programm ausgeführt, welches prüft, ob die Simulation geladen wurde
und sie gegebenenfalls lädt (zu diesem Zweck sind der Dateipfad und -name oben links
im Arbeitsblatt eingetragen). Anschließend werden die Ober- und Untergrenzen sowie
Inkremente eines jeden Parameters eingelesen und eine Schleifenkonstruktion ausgeführt, in der alle vorgegebenen Kombinationen berücksichtigt werden. Innerhalb dieser
Schleifen werden stets die Parameter an Aspen übergeben, die Simulation zurückgesetzt und danach ausgeführt, der Konvergenzstatus der Simulation überprüft und
zusammen mit den Inputparametern und Outputgrößen in das Excel-Arbeitsblatt
20
4.1 Scans
geschrieben (Abb. 23 auf S. 36 zeigt ein Beispiel). Nachdem auf diese Weise alle
Kombinationen abgearbeitet wurden, wird der Scan gestoppt.
Anmerkung: Aufgrund eines technischen Problems (wir vermuten es lag an der
uns zugänglichen Programmversion von Aspen Plus) konnten weder die Betriebsnoch die Materialkosten aus der fertigen Simulation an Excel übergeben werden.
Sie konnten zwar mit Hilfe des Aspen Process Economic Analyzers berechnet
werden, wurden jedoch nicht im „Variable Explorer“ gelistet, demjenigen Verzeichnis, dem sämtliche anderen relevanten Outputgrößen entnommen wurden. In der
Folge konnten keine für Optimierungen gebräuchlichen Gesamtjahreskosten (engl.
total annualized costs, TACs) berechnet werden. Auch die Berücksichtigung aktueller Preise für die verwendeten Chemikalien oder Bauteile wurde damit hinfällig.
Letztendlich konnten nur die Energiekosten an Excel übergeben werden, was eine
merkliche Verkürzung der Rechenzeit mit sich brachte, da der Aspen Process
Economic Analyzer deaktiviert werden konnte. Mit der Begründung jedoch, dass
die Energiekosten einem signifikanten Anteil der Betriebskosten entsprechen und
dass sich die vorliegende Arbeit für die Optimierung unter Anwendung des EA und
nicht einer möglichst realistisch ausgearbeiteten Simulation verschrieben sieht, soll
die Verwendung von Energiekosten als Grundlage der Optimierung gerechtfertigt
sein.
4.1.2 Ergebnisse
Die gewählten Scanparameter sind Abbildung 11 zu entnehmen. Insgesamt wurden
29025 Kombinationen verschiedener Betriebsparameter (= 5 · 3 · 3 · 5 · 3 · 43, Spalte
G) gerechnet. Die Rechenzeit betrug dabei circa 7 Tage. Mit Ausnahme der NFMFlowrate, für die insgesamt 43 Werte berücksichtigt wurden, wurden für die übrigen
Parameter relativ schmale Grenzen von lediglich 3 bis 5 Werten eingesetzt. Die
Auswahl der Parameter erfolgte dabei nicht willkürlich, sondern auf Basis fehlerfrei
konvergierter Simulationen wie beispielsweise der Folgenden:
21
1. nstages COLLEFT = 50
2. stage NFMIN = 6
3. stage FEED = 24
4. nstages COLRIGHT = 5
5. nstages STRIP = 6
6. flowrate NFMIN = 535 kmol/h
Fehlerbehaftete Simulationen. Abbildung 12 zeigt den Anteil nicht konvergierter, fehlerbehafteter Simulationen. Mit 69.3% (linkes Diagramm.) werden etwa
zwei von drei Simulationen nicht korrekt beendet. Der Anteil fehlerfrei konvergierter
Simulationen scheint mit 30.7% verhältnismäßig hoch, würde aber sicherlich deutlich
kleiner ausfallen sobald der Scanbereich weniger schmal um fehlerfreie Simulationen gefasst wäre. Im rechten Diagramm ist aufgeschlüsselt, an welcher Stelle der
Simulation keine Konvergenz erreicht werden konnte. Dies betrifft hauptsächlich den
„$OLVER01“ und nur in geringerem Maße die Blöcke „COLLEFT“, „MIXSOLV“
und „SPLITTER“.
Abbildung 12: Anteil nicht konvergierter Simulationen.
Expemplarischer Ausschnitt der Hyperfläche. Abbildung 13 zeigt die Energiekosten in Abhängigkeit der NFM-Flowrate und der Bodenzahl von „COLLEFT“.
Hohe Kosten entsprechen dabei einer blassgelben und niedrige einer tiefvioletten
Färbung. Erwartungsgemäß führen hohe Flowrates auch zu hohen Energiekosten,
da größere Mengen N -Formylmorpholin im Verdampfer erhitzt werden müssen. Zu
geringe Flowrates führen zu ebenfalls zu hohen Energiekosten, da sie mit schlechteren
22
4.1 Scans
Abbildung 13: Zweidimensionaler Ausschnitt der Hyperfläche.
Trennleistungen verbunden sind, die wiederum mit erhöhten Rücklaufverhältnissen
ausgeglichen werden, was schließlich zu einem größerem Energiebedarf vom Verdampfer führt. Auf diese Weise gibt es zu jeder Bodenzahl eine optimale Flowrate. Bei
mehr als 45 Böden beträgt sie 460 kmol/h (roter Rahmen in Abb. 13). Bei weniger
als 45 Böden nimmt die Trennleistung rapide ab, was letztlich zu einem starken
Anstieg der Energiekosten führt (Pfeil in Abb. 13).
Nicht in der Abbildung dargestellt sind die Energiekosten für Ströme < 450 kmol/h.
Sie steigen so rapide an (für 440 kmol/h sind es bereits doppelte Kosten von
> 9 · 106 US$/Jahr), dass sie nicht sinnvoll in der Farbcodierung berücksichtigt
werden können. Die Ergebnisse der zugrunde liegenden Simulationen sind ohnehin
fragwürdig, da sie nicht zur Konvergenz gebracht werden konnten. Im Gegensatz
dazu konvergierten alle 21 · 21 = 441 in der Abbildung aufgeführten Simulationen,
sodass das qualitative Verhalten der Trennwandkolonne als richtig wiedergegeben
anzusehen ist.
Übersicht der Ergebnisse. Abbildung 14 zeigt die Scanergebnisse in Form
eines Histogramms. Parameterkombinationen, die zu geringen Energiekosten führen sind links angesiedelt und Kombinationen mit höheren Kosten entsprechend
weiter rechts. Zur besseren Übersichtlichkeit sind alle Simulationen mit Energiekosten > 4.55 · 106 US$/Jahr zu einem Balken zusammengefasst. Tatsächlich setzen
sie sich aus vielen Intervallen geringer Intensität und zum Teil hoher Kosten zusammen. Grundlage des Histogramms sind die 8908 fehlerfrei konvergierten Simulationen.
Die fehlerhaften 69.3% wurden nicht berücksichtigt.
23
Unter den 8908 Kombinationen befinden sich lediglich 0.45% im kostengünstigsten
Intervall. Die 10 besten Parameterkombinationen sind in Abb. 15 aufgeführt. Sie
weisen alle fast identische Energiekosten von 4 479 193 ± 3 US$/Jahr auf und zeigen die
Bevorzugung einer NFM-Flowrate von 460 kmol/h, 7 Böden in der rechten Kolonne
und einem Zulaufboden von 7 bzw. 25 für NFM bzw. das Benzol-Cyclohexan-Gemisch
(vgl. Flowsheet der Simulation auf S. 13). Die Bodenzahl der Stripper- sowie der
Extraktionskolonne (zumindest ab 45 Böden, siehe Abb. 13) wirken sich hingegen
weniger stark auf die Energiekosten aus. Unter den 10 gezeigten Kombinationen führt
vermutlich die letzte zu den geringsten Gesamtjahreskosten, da sie die wenigsten
Trennböden benötigt.
Abbildung 14: Histogramm Scanergebnisse.
Abbildung 15: Die 10 besten Sätze von Betriebsparametern im Scan.
24
4.2 Optimierung mittels evolutionärem
Algorithmus
Zur gezielten Optimierung der Betriebsparameter wurde der in Excel integrierte
Solver der Firma Frontline Systems genutzt. Dieser bietet die Möglichkeit mittels
unterschiedlicher Optimierungsalgorithmen den Wert einer Zielzelle (die Energiekosten) in Abhängigkeit anderer Zellen (den Betriebsparametern) zu optimieren. Neben
dem verwendeten evolutionären Algorithmus gibt es weiterhin die Optimierungsverfahren GRG Nonlinear und Simplex-LP. Beide Verfahren wurden nicht auf das
vorliegende Problem angewendet.
Da der Solver ausschließlich innerhalb von Excel arbeitet und der Programmcode
nicht eingesehen werden kann, musste eine Schnittstelle zwischen dem Solver und
Aspen geschaffen werden, die das Abgreifen von Zwischenergebnissen zu Analysezwecken ermöglicht. Konkret bedeutet dies, dass bei beispielsweise 20 gewünschten
Optimierungsschritten, 20 einzelne Solveriterationen durchzuführen sind und nach
jeder einzelnen die Ergebnisse in das Excel-Arbeitsblatt übertragen werden. Die
vielen internen Parametervariationen, die dabei in einer einzelnen Solveriteration
durchgeführt werden, konnten jedoch nicht nachvollzogen werden. Es ist ohnehin
davon auszugehen, dass das Nachvollziehen der exakten Arbeitsweise des EA seitens
Frontline Systems auch gar nicht erwünscht ist.
4.2.1 Vorgehen
Im Folgenden wird die Optimierung mittels EA anhand des in Abbildung 16 dargestellten Flussdiagramms erläutert. Der kommentierte, vollständige Programmcode
ist inklusive einem exemplarischen Output in Anhang B ab Seite 43 aufgeführt.
Nach dem Eingeben der Betriebsparameter und ihrer jeweiligen Ober- und Untergrenzen, welche für die Nutzung des EA zwingend erforderlich sind, wird die
Optimierung durch Betätigen der Schaltfläche „Solve“ gestartet (siehe Abb. 17).
Es wird ein VBA-Programm ausgeführt und eine Schleife gestartet, die von 1 bis
zur gewünschten Anzahl der Optimierungsschritte „#“ läuft. Zu Beginn eines jeden
Optimierungsschrittes wird der Solver zurückgesetzt. Anschließend werden die be-
25
Abbildung 16: Flussdiagramm zur Anwendung des EA.
Abbildung 17: Gewählte Solverparameter und -grenzen.
nötigten Solveroptionen1 sowie Ober- und Untergrenzen an den Solver übergeben
und der Optimierungsalgorithmus über eine einzelne Solveriteration gestartet. Dabei
ist zu beachten, dass mit Ausnahme der NFM-Flowrate alle übrigen Parameter
ganzzahlige Größen sind und dass dies dem Solver entsprechend mitgeteilt wird.
Abschließend werden die Ergebnisse dieser einen internen Solveriteration tabellarisch
aufgetragen (siehe dazu Abb. 26 auf S. 44), die erhaltenen Parameter für den nächsten
Optimierungsschritt in Spalte B eingetragen und der nächste Optimierungsschritt
gestartet.
1
Excels Solver verfügt über eine ganze Reihe von Optionen. Diese sind auf der Homepage
https://msdn.microsoft.com/de-de/library/office/ff195446.aspx dokumentiert und der Vollständigkeit halber in Anhang C aufgelistet. Eine systematische Untersuchung, inwiefern sich die
Veränderung einer jeden Solveroption auf die Optimierung auswirkt, wurde nicht durchgeführt.
26
Die Schnittstelle zwischen Aspen und dem Solver bildet die Zelle E11. Ihr ist die
benutzerdefinierte Funktion „cost“ zugewiesen, die dem in B4–B9 aufgeführten Satz
von Betriebspsarametern seine jeweiligen Energiekosten zuordnet. „Cost“ aktualisiert
sich bei jeder Veränderung der Parameter, indem ein VBA-Code aufgerufen wird
(siehe Anhang B), welcher den Inhalt der Zellen B4–B9 an Aspen übergibt, die
Simulation durchführt und das Ergebnis in Form von jährlichen Energiekosten als
Funktionswert ausgibt. Im Falle einer fehlerhaften Simulation wird eine Straffunktion
aktiviert, die E11 den Wert 1 · 1011 zuordnet. Dieser immens hohe Wert bewirkt, dass
der dazugehörige Satz an Betriebsparametern bei einer Optimierung nicht weiter
berücksichtigt wird oder zumindest nur eine geringe Priorität erhält.
4.2.2 Arbeitsweise evolutionärer Algorithmen
Die grundsätzliche Funktionsweise evolutionärer Algorithmen ist in Abbildung 18
dargestellt. Da sie an Vorgänge aus der biologischen Evolution angelehnt ist, werden
entsprechende biologische Termini wie Generation, Population, Individuen, Mutation,
etc. verwendet.
Abbildung 18: Arbeitsweise eines evolutionären Algorithmus.[7]
In der Initialisierung wird die erste Generation von Lösungskandidaten/Individuen innerhalb der angegebenen Grenzwerte erzeugt. Diese Generation enthält
27
neben den vorgegebenen Startwerten weitere zufällige oder nach bestimmten Kriterien
erzeugte Lösungskandidaten. Jedes Individuum besitzt seine eigenen Eigenschaften
(hier die 6 Betriebsparameter) und die Gesamtheit aller Individuen wird als Population bezeichnet. Im Schritt Evaluation werden die Individuen mit Hilfe einer
Fitnessfunktion beurteilt, die Individuen mit erhöhter Fitness auch eine höhere Fortpflanzungswahrscheinlichkeit zusichert. Bewertungsgrundlage der Fitnessfunktion ist
im vorliegenden Fall ein kleiner Wert Zielfunktion „cost“. Im Schritt Rekombination
werden die Eigenschaften guter Lösungskandidaten kombiniert und in Mutation
werden diese Eigenschaften (mehr oder weniger stark) per Zufall verändert. Nach
diesen vier Schritten wird eine weitere Generation von Lösungskandidaten erzeugt
und die Schritte Evaluation, Rekombination und Mutation so lange wiederholt bis
entweder eine geeignete Lösung gefunden oder die maximale Iterationsanzahl erreicht
wurde.
Generelle Anmerkungen:
(i) Durch die Arbeitsweise eines EA erhöht sich gegenüber linearen Optimierungsalgorithmen die Wahrscheinlichkeit, das globale Optimum zu finden anstatt in
ein Lokales zu laufen.
(ii) EA liefern meist nicht die besten, aber häufig sehr gute Ergebnisse nahe
dem globalen Minimum und das in kurzer Zeit. Ein auf diese Ergebnisse
aufgesetztes lineares Optimierungsverfahren sollte die erhaltenen Resultate
weiter optimieren.
(iii) EA verschiedener Hersteller sind in der Regel auch verschieden umgesetzt,
sodass sie auf unterschiedlichen Wegen zum Ziel führen. Ihnen liegen beispielsweise nicht äquivalente Mutations- und Rekombinationsoperatoren zugrunde.
Mathematische Details der jeweiligen Vorgehensweise sind dabei Firmengeheimnis.
(iv) Oft werden EA auch mit künstlichen neuronalen Netzen oder lokaler Suche
kombiniert.
(v) Es gibt eine ganze Reihe von Solveroptionen in Excel, die der Übersicht halber
in Anhang C aufgeführt sind. Die im nächsten Abschnitt vorgestellten Ergebnisse wurden teilweise für verschiedene Optionen erhalten. Eine systematische
Untersuchung, inwiefern sich die Veränderung einer jeden Solveroption auf die
Optimierung auswirkt, wurde nicht durchgeführt.
28
4.2.3 Ergebnisse
Abbildung 19 zeigt die Ergebnisse von fünf Optimierungen und dem besten Scanergebnis. Dargestellt sind die Energiekosten in Abhängigkeit des jeweiligen Optimierungsschrittes. Zur besseren Übersichtlichkeit wurden die einzelnen Graphen
gemäß dem Erstelldatum benannt und auf die Angabe der dazugehörigen Grenzen,
Startwerte und Solveroptionen verzichtet. Sie werden mitunter im Fließtext erwähnt.
Ferner sind die Ergebnisse nur bis zum 13ten Optimierungsschritt aufgeführt, da
danach keine Verbesserung der Ergebnisse mehr beobachtet werden konnte.
Abbildung 19: Ergebnisse EA.
Die Blindprobe vom 15.04.2015 liefert bereits ein adäquates Ergebnis innerhalb von 11 Iterationen (etwa 30 Minuten Rechenzeit pro Iteration). Die nach den
Iterationen 9 bis 11 erhaltenen Energiekosten sind bereits niedriger als bei 98.6%
der fehlerfrei konvergierten Simulationen aus dem Scan. Die optimierten Parameter
liegen außerhalb des Scanintervalls.
Der Versuch vom 21.04.2015 zeigt exemplarisch den Nachteil eines nicht linearen
Optimierungsverfahrens: bei einem schlechten Startwert, zu groß gefassten Randbedingungen und einer zu kleinen Populationsgröße kann die Optimierung starken
Schwankungen ausgesetzt sein. Die hohen Energiekosten weit außerhalb des dargestellen Bereichs (Iteration 7–11) sind Ergebnisse der Straffunktion bei fehlerhaft
29
konvergierten Simulationen. Trotzdem wurde in der 12ten Iteration eine einigermaßen
kostengünstige Kombination gefunden.
Der Versuch vom 24.04.2015 zeigt das Verhalten des Algorithmus bei engen
Grenzen und einem bereits recht guten Wert nach der Initialisierung. Auf der einen
Seite gibt es zwar kaum Schwankungen, dafür kann das Finden einer besseren
Lösung auf der anderen Seite einige Zeit in Anspruch nehmen. So wurde nach der
10ten Iteration keine Änderung der Betriebsparameter mehr beobachtet, obwohl
insgesamt ganze 79 Iterationen durchgeführt wurden. Dieser Umstand spricht für
eine bereits sehr gute Lösung. Im Übrigen sind die Energiekosten ab Iteration 10
schon günstiger als alle fehlerfrei konvergierten Simulationen aus dem Scan, was für
die gute Performance des Solvers spricht. Die optimierten Parameter liegen auch hier
außerhalb des Scanintervalls.
Der Versuch vom 27.05.2015, bei dessen Kriterienauswahl unsere bis dahin gesammelten Erfahrungen eingeflossen ist, liefert nach 11 Iterationen den insgesamt
besten Wert. Für diese Optimierung wurde eine mäßig gute Initialisierung erhalten
und deutlich größere Grenzen als bei 24.04.2015 vorgegeben. Infolgedessen waren
stärkere Schwankungen der Energiekosten zu erwarten, welche auch beobachtet
wurden. Aufgrund einer kleineren Populationsgröße im Vergleich zur Blindprobe
dauerten die Iterationen nur circa 15 statt 30 Minuten. Auch hier liegen optimierten Parameter außerhalb des Scanbereichs. Die zugehörigen Energiekosten sind mit
4 468 587 US$/Jahr die geringsten, die in der vorliegenden Arbeit erzielt werden konnten. Die Randbedingungen bzw. Solverparameter, die dieser Optimierung zugrunde
liegen, sind in Anhang B in Abb. 25 bzw. dem Programmcode ab Z. 26 aufgeführt.
Die optimierten Betriebsparameter sind zusammen mit dem besten Scanergebnis
Abbildung 20 zu entnehmen.
Der Versuch 29.05.2015 zeigt eine Optimierung innerhalb der Grenzen des
Scans. In diesem Test sollte herausgefunden werden, ob der Solver auch hier bessere
Ergebnisse erzielen kann als der einigermaßen hochaufgelöste Scan. Tatsächlich gelang
dieses Vorhaben nach einigen erfolglosen Versuchen erst mit Hilfe der Solveroptionen
vom 27.05.2015 und nach der 13ten Iteration. Dieses Resultat unterstreicht erneut
die Performance des EA als Optimierungstool.
30
4.3 Vergleich zwischen Scan und Solver
4.3 Vergleich zwischen Scan und Solver
Abbildung 20 zeigt das Flowsheet der Aspen-Simulation zusammen mit den besten
Ergebnissen des Scans und des Solvers.
Abbildung 20: Gegenüberstellung der besten Scan- und Solverergebnisse.
Zeigt der Vergleich der Energiekosten lediglich marginale Unterschiede mit einem
leichten Preisvorteil für die Solverergebnisse, so sind die Unterschiede für Materialkosten relevante Parameter umso deutlicher. Denn hier ist die mittels EA optimierte
Trennwandkolonne klar im Vorteil: die Bodenzahl aller drei Kolonnensegmente ist
31
geringer als beim Scan und auch die NFM-Flowrate ist merklich kleiner. Bedenkt
man zudem den Zeitfaktor – zur Erinnerung: das Abscannen eines Bereich mit kleinen
Parametervariationen dauerte circa eine Woche und die Optimierung mit geschickt
gewählten Solveroptionen lediglich drei Stunden – wird der Vorteil eines EA zur
Optimierung der extraktiven Trennwandkolonne noch offensichtlicher.
Nichtsdestotrotz sind auch die mittels Solver erhaltenen Resultate ausbaufähig.
Da davon auszugehen ist, dass der Solver bereits ein Ergebnis nahe des globalen
Minimus gefunden hat, könnte dieses im Folgenden durch Anwendung eines linearen,
gradientenbasierten Optimierungsverfahrens genauer identifiziert werden. Ferner
muss erwähnt werden, dass die der Optimierung zugrunde liegende Simulation
noch nicht detailliert ausgearbeitet worden ist und dass nach wie vor das Problem
der optimierten Energiekosten und nicht das der optimierten Gesamtjahreskosten
behandelt wurde.
Kapitel 5
Zusammenfassung und Ausblick
Ziel des Design-Projectsk war die Simulation und Kostenoptimierung einer extraktiven
Trennwandkolonne zur Trennung eines Benzol-Cyclohexan-Gemisches mit Hilfe eines
evolutionären Algorithmus (EA). Zur Simulation wurde Aspen Plus und zur
Optimierung der in Microsoft Excel implementierte, evolutionäre Algorithmus der
Firma Frontline Systems verwendet. Das Design-Project basiert auf 2004 publizierten
Untersuchungen der Krupp Uhde GmbH.
Zunächst wurde die einfacher zu realisierende direkte Trennsequenz simuliert.
Die dabei gesammelten Erfahrungen über sinnvolle Betriebsparameter erwiesen
sich als äußerst hilfreich bei der Auslegung der komplizierter realisierbaren Trennwandkolonne. Die Simulation der Trennwandkolonne selbst erfolgte mittels zweier
Rektifikationskolonnen und einer Stripperkolonne.
Für die Optimierung wurden 9 kostenrelevante Betriebsparameter berücksichtigt,
von denen 3 unter der Maßgabe einer mindestens 99%igen Produktreinheit in Aspen
und die übrigen 6 aus Excel heraus variiert wurden. Die Schnittstelle zwischen
der Simulation auf der einen Seite und Excel auf der anderen wurde mit Hilfe
der Programmiersprache Visual Basic geschaffen. Während die Übergabe der
Betriebsparameter von Excel zu Aspen problemlos funktionierte, war es nicht
möglich die Betriebs- und Materialkosten in automatisierter Weise aus Aspen in
Excel zu übertragen. Für die anstehenden Untersuchungen musste stattdessen auf
die Energiekosten zurückgegriffen werden.
Noch bevor der evolutionäre Algorithmus zum Einsatz kam, wurde ein kleiner
Bereich um eine fehlerfrei konvergierende Simulation herum abgescannt. Die erhaltenen Daten dienten in erster Linie als Referenz für die Optimierung mittels EA,
gaben allerdings auch Aufschluss über den Anteil fehlerhafter Simulationen sowie
34
über generelle Trends kostengünstiger Kombinationen der Betriebsparameter. Ferner
wurde gezeigt, dass im untersuchten Bereich weniger als 1% aller Simulationen zu
kosteneffizienten Punkten führte.
Die Optimierung mittels EA erfolgte für verschiedene Randbedingungen und
Solveroptionen. Dabei konnte gezeigt werden, dass die Anwendung des EA gegenüber
dem Scan deutlich schneller zu kostengünstigeren Ergebnissen führt (führen kann)
und sich hervorragend zum Aufspüren von Betriebsparametern nahe des globalen
Kostenminimums eignet. Es wurde aber auch gezeigt, dass bei einer ungeschickten
Wahl der Randbedingungen und Solveroptionen weniger gute Ergebnisse erzielt
werden können. Das beste Solverergebnis ist sowohl im Hinblick auf die Energiekosten
als auch im Hinblick auf die mutmaßlichen Materialkosten günstiger als das beste
Scanresultat.
Zusammenfassend lässt sich sagen, dass die Optimierung einer extraktiven Trennwandkolonne unter Anwendung eines evolutionären Algorithmus prinzipiell möglich
ist und bereits in einem Zeitraum von 1-2 Monaten durchgeführt werden kann. Sie
erfordert Erfahrung im Umgang mit den Programmen Aspen Plus und Excel
sowie elementare Kenntnisse der Programmiersprache Visual Basic. Dass die Qualität der erhaltenen Resultate maßgeblich von der Qualität der zugrunde liegenden
Simulation abhängt, liegt zwar auf der Hand; dennoch galt das Hauptaugenmerk
dem Erstellen eines Programms zur externen Optimierung und nicht einer bis ins
letzten Detail ausgearbeiteten Simulation.
In künftigen Studien könnte jedoch an diesem Defizit gearbeitet werden. Zunächst
sollte aber dafür Sorge getragen werden, dass die Simulation hinsichtlich der Gesamtjahreskosten anstelle von Energiekosten optimiert werden kann. Sofern geschehen,
stünden schon alle Tools bereit, um das vorliegende Trennproblem eingehender zu
bearbeiten oder sich einem anderen, chemisch relevanteren und aktuelleren Problem
zu widmen. Darüber hinaus könnte geprüft werden, ob sich die Simulationen auch
parallel starten lassen, was, wenn es denn ginge, zu einer erheblichen Verkürzung
der Rechenzeit führen würde und somit die Ausarbeitung einer noch detaillierten
Simulation erlauben sollte. Im Rahmen einer fundierten und tiefergehenden Studie
von tatsächlicher technischer Relevanz könnte auch die kommerziell erhältliche Version von Frontline Systems’ EA erworben werden und zum Einsatz kommen. Ferner
könnten bei einem Trennproblem, das von mehr als 6 Betriebsparametern abhängt,
Scans in Abhängigkeit ausgewählter Parameter durchgeführt werden, um neuronale
Netze hinsichtlich der Kostenfunktion anzulernen und so die Optimierung mittels
EA zu erleichtern. Ein entsprechendes Vorgehen wurde von Ge et al. berichtet. [8]
Anhang A
Programmcode Scan
Auf den folgenden Seiten ist der kommentierte Programmcode für die Scans aufgeführt.
Der Übersichtlichkeit halber sind das dazugehörige Flussdiagramm (mit Verweisen
auf die jeweiligen Programmzeilen, Abb. 21) und ein Ausschnitt aus der ExcelArbeitsmappe (Abb. 22) abgebildet. Darüber hinaus enthält dieser Anhang einen
Screenshot, der beispielhaft die in Excel verwalteten Daten eines Scans zeigt (Abb. 23).
Abbildung 21: Flussdiagramm zur Erläuterung des Programmcodes.
Abbildung 22: Ausschnitt Arbeitsmappe mit Scanparametern (gehören zu Abb. 13).
36
Abbildung 23: Verwaltete Daten bei einem Scan.
A Programmcode Scan
Es folgt der Programmcode:
Option Explicit
Global APsim As IHapp
Global ws As Worksheet
5
10
15
20
Sub Main()
Dim APsim As IHapp
Set APsim = OpenSimulation()
End Sub
Public Sub runscan()
’declarations
Dim start(5), fin(5), incr(5) As Double
Dim i As Integer
Dim ws As Worksheet
Set ws = ActiveSheet
’simulation loaded?
If APsim Is Nothing Then
Call OpenSimulation
End If
a = 20 ’a is the line the results should be written in
niter = ws.Cells(5, 11)
25
’read upper limit and increments
For i = 0 To 5
fin(i) = ws.Cells(i + 4, 5)
incr(i) = ws.Cells(i + 4, 6)
Next
30
35
40
45
50
55
60
’loop over all parameters
i = 1
start(0) = ws.Cells(4, 4)
Do While start(0) <= fin(0)
ws.Cells(6, 11) = i
’check for old results (very helpful if the scan has broken)
If ws.Cells(a, 8) = ““ _
Or ws.Cells(a, 9) = ““ _
Or ws.Cells(a, 18) = ““ Then
’************the “heart“ of the scan************
Call ExcelToAspenScan(start())
APsim.reinit
Application.Wait (Now + TimeValue("00:00:05"))
APsim.run
Call CheckSimStat(a, APsim)
Call PrintInputScan(i, a, start())
37
38
65
70
75
80
85
90
95
100
105
110
115
120
Call PrintOutputScan(a)
’********************************************
End If
start(5) = start(5) + incr(5)
a = a + 1
i = i + 1
Loop
Loop
Loop
Loop
Loop
Loop
MsgBox “Scan finished successfully ;-)“
End Sub
Sub OpenSimulation()
Dim path As String
Dim file As String
path = ws.Cells(1, 2)
file = ws.Cells(2, 2)
Set APsim = GetObject(path + file)
End Sub
Sub ExcelToAspenScan(start())
’nstages COLLEFT
APsim.Tree.Data.Blocks.COLLEFT.Input.Elements("NSTAGE").Value = start(0)
APsim.Tree.Data.Blocks.COLLEFT.Input.PROD_STAGE.Elements("LLEFT").Value = start(0)
APsim.Tree.Data.Blocks.COLLEFT.Input.PROD_STAGE.Elements("C6H12").Value = 1
APsim.Tree.Data.Blocks.COLLEFT.Input.FEED_STAGE.Elements("VLEFT").Value = start(0)
’stage NFMIN
APsim.Tree.Data.Blocks.COLLEFT.Input.FEED_STAGE.Elements("NFMIN").Value = start(1)
’stage FEED
APsim.Tree.Data.Blocks.COLLEFT.Input.FEED_STAGE.Elements("FEED").Value = start(2)
’nstages COLRIGHT
APsim.Tree.Data.Blocks.COLRIGHT.Input.Elements("NSTAGE").Value = start(3)
APsim.Tree.Data.Blocks.COLRIGHT.Input.PROD_STAGE.Elements("LRIGHT").Value = start(3)
APsim.Tree.Data.Blocks.COLRIGHT.Input.PROD_STAGE.Elements("C6H6").Value = 1
APsim.Tree.Data.Blocks.COLRIGHT.Input.FEED_STAGE.Elements("VRIGHT").Value = start(3)
’nstages STRIP
APsim.Tree.Data.Blocks.STRIP.Input.Elements("NSTAGE").Value = start(4)
APsim.Tree.Data.Blocks.STRIP.Input.PROD_STAGE.Elements("NFMHOT").Value = start(4)
APsim.Tree.Data.Blocks.STRIP.Input.PROD_STAGE.Elements("VSTRIP").Value = 1
APsim.Tree.Data.Blocks.STRIP.Input.FEED_STAGE.Elements("LLEFT").Value = 1
APsim.Tree.Data.Blocks.STRIP.Input.FEED_STAGE.Elements("LRIGHT").Value = 1
’flowrate NFMIN
APsim.Tree.Data.Streams.NFMIN.Input.TOTFLOW.Elements("MIXED").Value = start(5)
APsim.Tree.Data.Blocks.STRIP.Input.Elements("BASIS_B").Value = start(5)
End Sub
A Programmcode Scan
Public Sub CheckSimStat(a, APsim)
Dim ihn, tmp As IHNode
Dim tmp1, tmp2, tmp3, tmp4, tmp5 As String
125
130
135
140
145
150
155
160
165
170
175
180
tries = 0
tryagain:
Set ihn = APsim.Tree.Data
’- - - - - - - - - - - ’avoid Runtime Error 91
If ihn Is Nothing Then
tries = tries + 1
If tries < 5 Then
GoTo tryagain
Else
tryagain2:
APsim.reinit
APsim.run
GoTo tryagain
End If
End If
’- - - - - - - - - - - Set ihn = ihn.Elements("Results Summary")
Set ihn = ihn.Elements("Run-Status")
Set ihn = ihn.Elements(“Output“)
Set ihn = ihn.Elements("PER_ERROR")
errstat = ihn.Value
If errstat = 0 Then
ws.Cells(a, 24) = ““
ws.Cells(a, 25) = ““
ElseIf errstat = 1 Then
’write the error dialogue of Aspen Plus
ws.Cells(a, 24) = "Problem(s):"
Set tmp = ihn.Elements("1")
tmp1 = tmp.Value
tmp2 = tmp.Value
tmp3 = tmp.Value
tmp4 = tmp.Value
tmp5 = tmp1 + tmp2 + tmp3 + tmp4
ws.Cells(a, 25) = tmp5
End If
End Sub
Sub PrintInputScan(i, a, start())
Dim ws As Worksheet
ws.Cells(6,
ws.Cells(a,
ws.Cells(a,
ws.Cells(a,
ws.Cells(a,
ws.Cells(a,
ws.Cells(a,
ws.Cells(a,
End Sub
11) = i
1) = i
2) = start(0)
3) = start(1)
4) = start(2)
5) = start(3)
6) = start(4)
7) = start(5)
39
40
185
190
195
200
205
210
215
220
225
230
235
240
245
250
Public Sub PrintOutputScan(a)
Dim ws As Worksheet
Dim ihn As IHNode
’RR COLLEFT & RR COLRIGHT
ws.Cells(a, 8) = APsim.Tree.Data.Blocks.COLLEFT.Output.Elements("RR").Value
ws.Cells(a, 9) = APsim.Tree.Data.Blocks.COLRIGHT.Output.Elements("RR").Value
tries = 0
’VLEFT/VRIGHT
tryagain:
tries = tries + 1
If tries < 5 Then
GoTo tryagain
Else
APsim.reinit
APsim.run
GoTo tryagain
End If
End If
’- - - - - - - - - - - Set ihn = ihn.Elements("Flowsheeting Options")
Set ihn = ihn.Elements("Calculator")
Set ihn = ihn.Elements("CALCULAT")
Set ihn = ihn.Elements(Öutput")
Set ihn = ihn.Elements("WRITE_VAL")
Set ihn = ihn.Elements("3")
tries = tries + 1
If tries < 5 Then
GoTo tryagain
Else
APsim.reinit
APsim.run
GoTo tryagain
End If
End If
’- - - - - - - - - - - ws.Cells(a, 10) = ihn.Value
’Purity C6H12 [%]
tryagain2:
TOTFLOW = APsim.Tree.Data.Streams.C6H12.Output.Elements("TOT_FLOW").Value
If TOTFLOW = Leer Then
tries = tries + 1
If tries < 5 Then
GoTo tryagain2
Else
APsim.reinit
APsim.run
GoTo tryagain2
End If
End If
A Programmcode Scan
’- - - - - - - - - - - tmp = APsim.Tree.Data.Streams.C6H12.Output.MOLEFLOW.MIXED.Elements("C6H12").Value
ws.Cells(a, 11) = (tmp / TOTFLOW) * 100
255
’Purity C6H6 [%]
TOTFLOW = APsim.Tree.Data.Streams.C6H6.Output.Elements("TOT_FLOW").Value
tmp = APsim.Tree.Data.Streams.C6H6.Output.MOLEFLOW.MIXED.Elements("C6H6").Value
260
’Purity NFM [%]
TOTFLOW = APsim.Tree.Data.Streams.NFMHOT.Output.Elements("TOT_FLOW").Value
tmp = APsim.Tree.Data.Streams.NFMHOT.Output.MOLEFLOW.MIXED.Elements("NFM").Value
265
’Temp NFMHOT [K]
ws.Cells(a, 14) = APsim.Tree.Data.Streams.NFMHOT.Output.TEMP_OUT.Elements("MIXED").Value
270
275
280
285
’Heat duties [Gcal/h]
ws.Cells(a, 15) = APsim.Tree.Data.Streams.QRSTRIP.Output.Elements("QCALC").Value
ws.Cells(a, 16) = APsim.Tree.Data.Streams.QEXC.Output.Elements("QCALC").Value
ws.Cells(a, 17) = APsim.Tree.Data.Streams.QCLEFT.Output.Elements("QCALC").Value
ws.Cells(a, 18) = APsim.Tree.Data.Streams.QCRIGHT.Output.Elements("QCALC").Value
’Energy costs [US$/year]
tryagain3:
tries = tries + 1
If tries < 20 Then
GoTo tryagain3
End If
End If
Set ihn = ihn.Elements(“Results Summary“)
Set ihn = ihn.Elements(“Utility-Sum“)
Set ihn = ihn.Elements(“NET_COST“)
ws.Cells(a, 19) = ihn.Value * 24 * 365.25
290
’Operating costs [US$/year] –> not accessible :-(
’supposed path in variable exporer:
’“Data.Sizing and Costing.ExecutiveSummary.INVESTMENT:.Total Operating Cost“
’ws.Cells(a, 20) =
295
’Capital costs [US$] –> not accessible :-(
’supposed path in variable exporer:
’“Data.Sizing and Costing.ExecutiveSummary.INVESTMENT:.Total Project Capital Cost“
300
’Total annualized costs [US$] –> not accessible :-(
’Formula:
’TAC = (Capital cost)/(payback period) + energy costs
’payback period = 5 years
305
’Date and time
ws.Cells(a, 23) = Now
End Sub
41
Anhang B
Programmcode Solver
Auf den folgenden Seiten ist der kommentierte Programmcode für die Anwendung des
evolutionären Algorithmus aufgeführt. Der Übersichtlichkeit halber sind das dazugehörige Flussdiagramm mit Verweisen auf die jeweiligen Programmzeilen (Abb. 24) und
ein Ausschnitt aus der Excel-Arbeitsmappe (Abb. 25) abgebildet. Darüber hinaus
enthält dieser Anhang einen Screenshot, der beispielhaft die in Excel verwalteten Daten einer Optmierung mit dem Solver zeigt (Abb. 26). Die darin aufgeführten Daten
gehören zu dem besten Ergebnis, das mit Hilfe des Solvers erzielt wurde (27.04.2015
in Abb. 20). Die dazugehörigen Solveroptionen sind dem Programmcode ab Zeile 26
zu entnehmen.
Anmerkung: Beim Betrachen des Programmcodes fällt auf, dass in jedem Optimierungsschritt erneut die selben Solveroptionen (ab Z. 26) und Randbedingungen (ab
Z. 45) vorgegeben werden. Diese Vorgaben sind jedoch nicht redundant und können
nicht außerhalb der Optimierungsschleife gemacht werden, da der Solver in jedem
Optimierungsschritt zurückgesetzt wird und diese Informationen benötigt, ehe er
gestartet werden kann.
44
Abbildung 24: Flussdiagramm zur Erläuterung des Programmcodes.
Abbildung 25: Ausschnitt der Arbeitsmappe mit den Start- und Randbedingungen.
Abbildung 26: Verwaltete Daten bei der Verwendung des Solvers.
45
Es folgt der Programmcode:
Option Explicit
Global APsim As IHapp
Global ws As Worksheet
5
10
15
20
Sub Main()
Dim APsim As IHapp
Set APsim = OpenSimulation()
End Sub
Sub Solverer()
Dim ws As Worksheet
Dim niter, again, Iter, maxiter As Integer
niter = 1
again = 1
maxiter = 50
For i = 1 To maxiter
ws.Cells(13, 5) = niter
ws.Cells(14, 5) = Now
again = 1
SolverReset
Iter = 1
25
30
35
40
45
50
55
60
’Set solver options
SolverOptions Iterations:=Iter, _
Precision:=“0,000001“, _
Convergence:=“0,0001“, _
StepThru:=True, _
Scaling:=False, _
Derivatives:=1, _
SolveWithout:=False, _
MutationRate:=“0,1“, _
RandomSeed:=0, _
PopulationSize:=15, _
MaxTimeNoImp:=1
SolverOk SetCell:=“$E$11“, _
MaxMinVal:=2, _
ValueOf:=0, _
ByChange:=“$B$4:$B$9“, _
Engine:=3, _
EngineDesc:=“Evolutionary“
’Set boundary conditions
SolverAdd CellRef:=“$B$4“,
ActiveWorkbook.Save
Relation:=4,
Relation:=1,
Relation:=3,
Relation:=4,
Relation:=1,
Relation:=3,
Relation:=4,
Relation:=1,
Relation:=3,
Relation:=4,
Relation:=1,
Relation:=3,
Relation:=4,
Relation:=1,
Relation:=3,
Relation:=1,
Relation:=3,
FormulaText:=“Ganzzahlig“
FormulaText:=“$E$4“
FormulaText:=“$D$4“
46
65
70
75
80
SolverSolve UserFinish:=True, ShowRef:=“showdown“
SolverFinish KeepFinal:=1
Call PrintInpSolver(niter)
ws.Cells(13, 5) = niter
ws.Cells(14, 5) = Now
niter = niter + 1
Next
If MsgBox(“Iterations finished, continue?“, vbYesNo) = vbYes Then
GoTo continue
i = 1
Else
again = 0
End If
End Sub
Sub PrintInpSolver(niter)
Dim ws As Worksheet
85
a = niter + 16
90
ws.Cells(a,
ws.Cells(a,
ws.Cells(a,
ws.Cells(a,
ws.Cells(a,
ws.Cells(a,
ws.Cells(a,
1)
2)
3)
4)
5)
6)
7)
=
=
=
=
=
=
=
niter
ws.Cells(4,
ws.Cells(5,
ws.Cells(6,
ws.Cells(7,
ws.Cells(8,
ws.Cells(9,
2)
2)
2)
2)
2)
2)
95
Costs = ws.Cells(11, 5)
ws.Cells(a, 8) = Costs
ws.Cells(a, 9) = Now
End Sub
100
Sub Costs()
Dim ws As Worksheet
Dim a As Double
105
a = Cost(a)
End Sub
110
115
120
125
Function Cost(a)
Dim ws As Worksheet
Dim para1, para2, para3, para4, para5 As Integer
Dim para6 As Double
If APsim Is Nothing Then
Call OpenSimulation
End If
Call ReadPara(para1, para2, para3, para4, para5, para6)
Call ExcelToAspen(para1, para2, para3, para4, para5, para6)
APsim.reinit
APsim.run
’*****************************************************
’*****check simulation status and determine costs*****
Dim ihn As IHNode
Set ihn = ihn.Elements(“Run-Status“)
130
135
140
145
150
Set ihn = ihn.Elements(“PER_ERROR“)
errstat = ihn.Value
If errstat = 0 Then
’energy costs
tryagain:
tries = tries + 1
If tries < 50 Then
GoTo tryagain
End If
End If
Set ihn = ihn.Elements(“Utility-Sum“)
Set ihn = ihn.Elements(“NET_COST“)
Cost = ihn.Value * 24 * 365.25
ElseIf errstat = 1 Then
’penalty function!
Cost = 100000000000#
End If
’*****************************************************
End Function
155
Sub ReadPara(para1, para2, para3, para4, para5, para6)
Dim ws As Worksheet
160
165
170
175
180
185
190
para1
para2
para3
para4
para5
para6
End Sub
=
=
=
=
=
=
ws.Cells(4,
ws.Cells(5,
ws.Cells(6,
ws.Cells(7,
ws.Cells(8,
ws.Cells(9,
2)
2)
2)
2)
2)
2)
Sub ExcelToAspen(para1, para2, para3, para4, para5, para6)
’nstages COLLEFT
APsim.Tree.Data.Blocks.COLLEFT.Input.Elements("NSTAGE").Value = start(0)
APsim.Tree.Data.Blocks.COLLEFT.Input.PROD_STAGE.Elements("LLEFT").Value = start(0)
APsim.Tree.Data.Blocks.COLLEFT.Input.PROD_STAGE.Elements("C6H12").Value = 1
APsim.Tree.Data.Blocks.COLLEFT.Input.FEED_STAGE.Elements("VLEFT").Value = start(0)
’stage NFMIN
APsim.Tree.Data.Blocks.COLLEFT.Input.FEED_STAGE.Elements("NFMIN").Value = start(1)
’stage FEED
APsim.Tree.Data.Blocks.COLLEFT.Input.FEED_STAGE.Elements("FEED").Value = start(2)
’nstages COLRIGHT
APsim.Tree.Data.Blocks.COLRIGHT.Input.Elements("NSTAGE").Value = start(3)
APsim.Tree.Data.Blocks.COLRIGHT.Input.PROD_STAGE.Elements("LRIGHT").Value = start(3)
APsim.Tree.Data.Blocks.COLRIGHT.Input.PROD_STAGE.Elements("C6H6").Value = 1
APsim.Tree.Data.Blocks.COLRIGHT.Input.FEED_STAGE.Elements("VRIGHT").Value = start(3)
’nstages STRIP
APsim.Tree.Data.Blocks.STRIP.Input.Elements("NSTAGE").Value = start(4)
APsim.Tree.Data.Blocks.STRIP.Input.PROD_STAGE.Elements("NFMHOT").Value = start(4)
APsim.Tree.Data.Blocks.STRIP.Input.PROD_STAGE.Elements("VSTRIP").Value = 1
APsim.Tree.Data.Blocks.STRIP.Input.FEED_STAGE.Elements("LLEFT").Value = 1
APsim.Tree.Data.Blocks.STRIP.Input.FEED_STAGE.Elements("LRIGHT").Value = 1
’flowrate NFMIN
APsim.Tree.Data.Streams.NFMIN.Input.TOTFLOW.Elements("MIXED").Value = start(5)
APsim.Tree.Data.Blocks.STRIP.Input.Elements("BASIS_B").Value = start(5)
End Sub
47
Anhang C
Übersicht Solveroptionen
Auf der Homepage https://msdn.microsoft.com/de-de/library/office/ff195446.aspx
dokumentierte Solveroptionen:
SolverOptions (MaxTime, Iterationen, Precision, AssumeLinear, StepThru, Schätzungen, Ableitungen, SearchOption, IntTolerance, Skalierung, Konvergenz, AssumeNonNeg, PopulationSize, RandomSeed, Mehrfachstart, RequireBounds, MutationRate,
MaxSubproblems, MaxIntegerSols, SolveWithout, MaxTimeNoImp)
MaxTime. Optionaler Variant-Wert. Der maximale Zeitaufwand (in Sekunden),
den Solver zur Lösung des Problems aufwendet. Der Wert muss eine positive ganze
Zahl sein.
Iterations. Optionaler Variant-Wert. Die maximale Anzahl Iterationen, die Solver
bei der Lösung des Problems aufwendet. Der Wert muss eine positive ganze Zahl
sein.
Precision. Optionaler Variant-Wert. Eine Zahl zwischen 0 (Null) und 1, die den
Grad an Genauigkeit angibt, mit der Nebenbedingungen (einschließlich ganzzahliger Nebenbedingungen) erfüllt werden müssen. Die Standardgenauigkeit beträgt
0.000001. Eine geringere Genauigkeit wird durch weniger Dezimalstellen angezeigt,
beispielsweise 0.0001. Im Allgemeinen benötigt Solver um so mehr Zeit zur Lösung
von Problemen, je höher die angegebene Genauigkeit ist (je kleiner die Zahl).
AssumeLinear. Optionaler Variant-Wert. Falls True, wird von Solver ein lineares
Modell zu Grunde gelegt. Diese Option beschleunigt zwar den Lösungsvorgang, sollte
jedoch nur verwendet werden, wenn alle Beziehungen in dem Modell linear sind. Der
Standardwert ist False.
50
StepThru. Optionaler Variant-Wert. Falls True, hält Solver bei jedem Lösungsversuch an. Sie können ein Makro an Solver übergeben, das bei jeder Pause ausgeführt
wird. Verwenden Sie dazu das Argument ShowRef der Funktion SolverSolve. Wenn
False, hält Solver nicht bei jedem Lösungsversuch an. Der Standardwert ist False.
Estimates. Optionaler Variant-Wert. Bestimmt den Ansatz, nach welchem anfängliche Schätzwerte für die Grundvariablen bei jeder eindimensionalen Suche ermittelt
werden: 1 steht für lineare Schätzungen, 2 für quadratische Schätzungen. Bei einer
linearen Schätzung wird eine lineare Extrapolation, ausgehend von einem tangentialen Vektor, vorgenommen. Bei der quadratischen Schätzung wird eine quadratische
Extrapolation vorgenommen; dies führt bei nichtlinearen Problemen u.U. zu besseren
Ergebnissen. Der Standardwert ist 1 (lineare Schätzung).
Derivatives. Optionaler Variant-Wert. Bestimmt Vorwärtsdifferenzierung oder zentrale Differenzierung bei Schätzungen für partielle Ableitungen der gesuchten Funktion und Nebenbedingungsfunktionen: 1 stellt die Vorwärtsdifferenzierung dar, 2 stellt
die zentrale Differenzierung dar. Die zentrale Differenzierung erfordert mehr TabellenNeuberechnungen. Möglicherweise können jedoch Probleme gelöst werden, bei denen
Ihnen zuvor mitgeteilt wurde, dass Solver die Lösung nicht weiter verbessern kann.
Die Option der zentralen Differenzierung sollten Sie bei Nebenbedingungen wählen,
deren Werte sich in der Nähe der Grenzwerte schnell ändern. Der Standardwert ist 1
(Vorwärtsdifferenzierung).
SearchOption. Optionaler Variant-Wert. Geben Sie mit den Search-Optionen den
Suchalgorithmus an, der bei jeder Iteration verwendet wird, um die Suchrichtung zu
bestimmen: 1 repräsentiert das Newton-Suchverfahren, 2 das Gradient-Suchverfahren.
Die Variante Newton, bei der ein Quasi-Newton-Verfahren eingesetzt wird, ist die
Standardeinstellung.
IntTolerance. Optionaler Variant-Wert. Eine Dezimalzahl zwischen 0 (Null) und
100, mit der prozentuale Toleranz der Ganzzahloptimalität angegeben wird. Dieses
Argument ist nur gültig, wenn ganzzahlige Nebenbedingungen definiert wurden.
Es gibt an, dass Solver beendet werden kann, wenn eine machbare ganzzahlige
Lösung gefunden wurde, deren Ziel innerhalb dieses Prozentsatzes des bekannten
Grenzwerts für das Ziel der erfüllten ganzzahligen optimalen Lösung liegt. Eine
größere prozentuale Toleranz beschleunigt tendenziell den Lösungsvorgang.
C Übersicht Solveroptionen
51
Scaling. Optionaler Variant-Wert. Wenn das Ziel oder die Nebenbedingungen sich
um mehrere Größenordnungen unterscheiden, z. B. beim Maximieren des prozentualen
Gewinns bei Multimillionen-Investitionen, legen Sie diese Option als True fest, damit
Solver die Werte für Ziel und Nebenbedingung während der Berechnung intern auf
ähnliche Größenordnungen angleicht. Wenn diese Option False ist, führt Solver seine
Berechnungen mit den ursprünglichen Werten für Ziel und Nebenbedingungen aus.
Der Standardwert ist True.
Convergence. Optionaler Variant-Wert. Eine Zahl zwischen 0 (Null) und 1, mit der
die Konvergenztoleranz für die Methoden GRG Nonlinear Solving und Evolutionary
Solving angegeben wird. Bei der GRG-Methode wird Solver beendet, wenn die
relative Änderung im Wert der Zielzelle für die letzten fünf Iterationen kleiner
als diese Toleranz ist. Bei der Evolutionary-Methode wird Solver beendet, wenn
mindestens 99% der Mitglieder der Grundgesamtheit „Passwerte“ aufweisen, deren
relative, d.h. prozentuale Differenz kleiner als diese Toleranz ist. In beiden Fällen
zeigt Solver die Nachricht an „Solver hat die aktuelle Lösung durch Konvergieren
erreicht. Alle Nebenbedingungen wurden eingehalten“.
AssumeNonNeg. Optionaler Variant-Wert. Wenn True gilt, geht Solver von einem
unteren Grenzwert von 0 (Null) für alle anpassbaren (veränderbaren) Zellen aus, für
die im Listenfeld Nebenbedingung nicht explizit untere Grenzwerte angegeben wurden
(die Zellen müssen nicht negative Werte enthalten). Wenn False gilt, werden von
Solver nur die im Listenfeld Nebenbedingung angegebenen Grenzwerte verwendet.
PopulationSize. Optionaler Variant-Wert. True, wenn Solver von einem unteren
Grenzwert von 0 (Null) für alle Entscheidungsvariablenzellen ausgehen soll, für die
kein expliziter unterer Grenzwert im Listenfeld Nebenbedingungen festgelegt ist
(die Zellen müssen nicht-negative Werte enthalten). False, wenn Solver nur die im
Listenfeld Nebenbedingung angegebenen Grenzwerte verwenden soll.
RandomSeed. Optionaler Variant-Wert. Eine positive ganze Zahl gibt einen festen
Ausgangswert für den Zufallszahlengenerator an, der von der Evolutionary SolvingMethode und der Mehrfachstartmethode für die globale Optimierung angewendet
wird. Dies bedeutet, dass Solver bei jeder Ausführung für ein unverändertes Modell
die gleiche Lösung findet. Der Wert Null gibt an, dass Solver bei jeder Ausführung
einen anderen Ausgangswert für den Zufallszahlengenerator verwenden soll, wodurch
sich bei einem unveränderten Modell für jede Ausführung unterschiedliche Lösungen
ergeben können.
52
MultiStart. Optionaler Variant-Wert. True, wenn Solver eine Mehrfachstart-Methode
für die globale Optimierung bei der GRG Nonlinear Solving-Methode verwenden soll,
wenn SolverSolve aufgerufen wird. False, wenn Solver die Methode GRG Solving nur
einmal ausführen soll, ohne Mehrfachstart beim Aufruf von SolverSolve.
RequireBounds. Optionaler Variant-Wert. True, wenn die Evolutionary SolvingMethode und die Mehrfachstart-Methode nach einem Aufruf von SolverSolve sofort
einen Wert von 18 zurückgeben soll, wenn für eine der Variablen entweder der obere
oder der untere Grenzwert nicht definiert ist. False, wenn diese Methoden eine
Problemlösung ohne Grenzwerte für alle der Variablen versuchen sollen.
MutationRate. Optionaler Variant-Wert. Eine Zahl zwischen 0 (Null) und 1 zur
Angabe der Rate, mit der die Evolutionary Solving-Methode „Mutationen“ an
den vorhandenen Elementen der Grundgesamtheit vornimmt. Durch eine höhere
Mutationsrate wird tendenziell die Verschiedenheit (1-Alpha) der Grundgesamtheit
erhöht, und möglicherweise ergeben sich bessere Lösungen.
MaxSubproblems. Optionaler Variant-Wert. Die maximale Anzahl Teilprobleme,
die Solver in Problemen mit ganzzahligen Nebenbedingungen und Problemen, die
mit der Evolutionary Solving-Methode gelöst werden, untersucht. Der Wert muss
eine positive ganze Zahl sein.
MaxIntegerSols. Optionaler Variant-Wert. Die maximale Anzahl der machbaren
(oder ganzzahlig machbaren) Lösungen, die Solver in Problemen mit ganzzahligen
Nebenbedingungen und Problemen, die mit der Evolutionary Solving-Methode gelöst
werden, in Erwägung zieht. Der Wert muss eine positive ganze Zahl sein.
SolveWithout. Optionaler Variant-Wert. True, wenn Solver alle ganzzahligen Nebenbedingungen ignorieren und die „Relaxation“ des Problems lösen soll. False, wenn
Solver die ganzzahligen Nebenbedingungen beim Lösen des Problems verwenden soll.
MaxTimeNoImp. Optionaler Variant-Wert. Bei Verwendung der Evolutionary
Solving-Methode die maximale Zeitspanne (in Sekunden), für die Solver Lösungsversuche fortsetzt, ohne signifikant verbesserte Lösungen zu finden, die der Grundgesamtheit hinzugefügt werden können. Der Wert muss eine positive ganze Zahl
sein.
Literaturverzeichnis
[1] B. Lohrengel, Einführung in die thermischen Trennverfahren, 2. Aufl., Oldenbourg Verlag, München 2012.
[2] M. Baerns, A. Behr, A. Brehm, J. Gmehling, K.-O. Hinrichsen, H. Hofmann,
U. Onken, R. Palkovits, A. Renken, Technische Chemie, 2. Aufl., Wiley-VCH,
Weinheim 2013.
[3] A. Behr, D. W. Agar, J. Jörissen, Einführung in die Technische Chemie, Spektrum Akademischer Verlag, Heidelberg 2010.
[4] A. Brehm, Praktikumsskript: Rektifikation, Carl von Ossietzky Universität
Oldenburg 2012.
[5] B. Kolbe, S. Wenzel, Chem. Eng. Process., 43, 339, 2004.
[6] T. Diehl, B. Kolbe, K. Gehrke, ERTC Petrochemical Conference, Prague 2005.
[7] J. Ryll, M. Seemann, Diplomarbeit, Fachhochschule Regensburg, 2005.
[8] X. Ge, X. Yuan, C. Ao, K.-K. Yu, Comput. Chem. Eng., 68, 38–46, 2014.
Erklärung
Hiermit versichern wir, dass wir diese Arbeit selbstständig verfasst und keine anderen
als die angegebenen Quellen und Hilfsmittel benutzt haben. Außerdem versichern wir,
dass wir die allgemeinen Prinzipien wissenschaftlicher Arbeit und Veröffentlichung,
wie sie in den Leitlinien guter wissenschaftlicher Praxis der Carl von Ossietzky
Universität Oldenburg festgelegt sind, befolgt haben.
Oldenburg, den 19. Juli 2015
————————–
Nils Ayral
————————–
Enno Gent
————————–
Gabriele Tomaschun

Modellierung und Optimierung einer extraktiven Trennwandkolonne

Transcrição

Documentos relacionados

Lesen Sie die ArciSoft Success-Story eines internationalen

Banyan Tree Seychelles ab 3`990.-

Übungsaufgaben Aufgabe 1: (Formularelemente 1) Aufgabe 2 (Solver)

Brush installieren - Das Render

Neue Artikel im Shop bei unserem Sponsor ``OC-Card`

Das Duschboard ein verkanntes Genie?

Playground-Landscape_Der Kletterwald.

Flyer Bestückungsmodul für flexible Solarzellen

Unterrichtsvorschlag downloaden

Beispiel: VBA - Excel - Lauftext in einer Zelle - Visual