DE MODELLERING IN GAMS VAN HET MODEL SELPE

DECEMBER 1986 ESC-39

DE MODELLERING IN GAMS VAN HET MODEL SELPE

F. VAN OOSTVOORN W.G. VAN ARKEL A.V.M. DE LANGE

- 2 -

ABSTRACT

The Energy Study Centre (ESC) is involved in energy and environmental policy and scenario studies for the Ministry of Economic Affairs and the Ministry of Environment. In the past five years a large sca~e LP energy model called SELPE (Static ESC Linear Programming Energy model) was developed [I])o

Initially this model was huilt with the use of in-house developed software toolso When the model became larger and more complex, the modifications and extensions of the model for new policy studies were more and more cumbersome, costly and error-proneo The pressure to change the model software to meet these challenges resulted in the reprogramming of the energy model SELPE in the modelling language GAMS (General Algebralc Modelling System)o GAMS is developed at the World Bank°

This report will give a comprehensive overview of the way the LP model SELPE is programmed and can be used in GAMS. First a brief description of GAMS is presentedo Next the major elements such as the nodes and flows of the energy network~ are discussed. Furthermore the complete model~ including equatlons and additional programs are presentedo The appendices contain a more detailed description of the 6AMS software, particularly useful as an users guideo

KEYWORDS

MATRIX GENERATORS MODELLING LANGUAGES LINEAR PROGRAMMING OPTIMIZATION ENERGY MODELS MATHEMATICAL MODELS

VOORWOORD

Het rapport bevat een verantwoording van de studiewerkzaamheden, die zijn uitgevoerd in het kader van het project SELPE: B+O 1984 en 1985. Het gaat hierbij in het bijzonder om de introductie en implementatie van de modelleertaal GAMS (General Algebraic Modelling System), zijnde het software-systeemm voor het LP-energiemodel SELPEo

Het rapport bevat derhalve een beschrijving van de wijze waarop het energiemodel SELPE in de modelleertaal OAMS is geprogrammeerd. Dit betekent dat behalve aan de karakteristieken van GAMS vooral aandacht wordt geschonken aan de wijze waarop SELPE in het GAMS-systeem is gespecificeerd. Hierbij komen alle onderdelen van het modelpakket SELPE aan de orde.

DANKWOORD

De auteurs danken met name J.J. Bisschop voor de vele suggesties en ideeën ten behoeve van de realisatie van dit project en W.J~ Jansen voor het nauwgezette typewerk van de verschillende versies van dit rapport.

-5 -

INHOUD

BIz.

ABSTRACT

2

VOORWOORD

3

I. INLEIDING HET BELANG VAN EEN MODELLEERTAAL 2oio Oorspronkelijke software-systeem 2.2. Keuze modelleertaal

12 14

3. EIGENSCHAPPEN GAMS 3,1. Algemeen 3.2. gysteembesohrijving

17 17

4. ALGEMENE OPZET SELPE IN GAMS 4.1. Modelstructuur 4.2. Proceshiërarchie binnen producers 4°3° Energiestromen

24 24 25 28

5. MODELBESCHRIJVING 5.1. Inleiding 5.2. Modelvergelijkingen 5.3. Beschrijving producers en eindvraagcategorieën 5.4. Gegevenstabellen 5.5. Overige modelonderdelen 5.6. Modeldelen

31

38 44 46 48

6o HUhPPROGR~MMA’S 6.1. Multi-objective programma MOLP 6.2. Stuurkaartenprogramma’s 6.3. CONVERS-programma 6.4. TEN-programma

5O 5O 51 52 52

7. CONCLUSIES

54

8. LITERATUUR

56

APPENDIX I : Gebruikershandleiding voor SELPE in GAMS APPENDIX II: Het grafische tekenprogramma TEN

31

-6 -

I. INLEIDING

Voor het analyseren en kwantificeren van beleidsopties, effecten van veranderingen in energieprijzen e.d. zijn~ gezien de complexiteit van de interacties in de energievoorziening, modellen een onmisbaar hulpmiddel. Bij het Energie Studie Centrum zijn al in het beginstadium van de ontwikkeling van modellen toboV, scenario- en beleidsstudies de voordelen van het gebruik van lineaire programmering voor het modelleren van de energievoorziening onderkend~ In 1981 was een relatief groot LP-model ontwikkeld van de energievoorziening, genaamd SELPE (Statistisch ESC Lineair Programmerings Energiemodel) voor het opstelllen van energiescenario’s en het uitvoeren van voorbereidende beleidsstudies voor EZ (DGE) en VROM (DGMH) [1,2]. Bij de opzet van het energie-milleu-model is getracht om zo goed mogelijk de substitutie tussen energiedragers in de energievoorziening en de daarmee verband houdende technologische ontwikkelingen, inclu~ sief de daaraan gerelateerde emlssies, te beschrijveno Voor de keuze van een passende modeltechniek kan men het gebruik van econometrische of procesmatige modellen overwegen. Voor het schatten van betrouwbare parameters van een econometrisch model van de energievoorziening is echter onvoldoende statistisch materiaal (tijdreeksen en dergelijke) aanwezig° Voorts zijn technologische ontwikkelingen moeilijk te beschrijven met behulp van econometrische modelleno Ten hoogste is op deze wijze een zeer globale weergave van technologische ontwikkelin~ gen mogelijk. Daarom is gekozen voor het opzetten van een LP-model~ met een gedetailleerde procesmatige beschrijving van de energievoorziening. Voor het schatten van de parameters wordt gebruik gemaakt van zowel historische statistische gegevens als technische en economische procesgegevens van bestaande en toekomstige technologieëno Dit type LP-modellen heeft overigens een rijke historie van meer dan dertig jaar en zijn vooral gebruikt voor het modelleren van raffinaderijen en andere basisindustrieëno

De recente ontwikkelingen in de energievoorziening hebben de belangstelling voor LP-modellen de laatste jaren echter sterk vergroot. Enige bekende voorbeelden van dergelijke LP-energiemodellen zijn onder andere BESOM/DESOM ontwikkeld bij BNL (U.S.A.) [3], Markal ontwikkeld voor de IEA [4], EFOM ontwikkeld bij EEG [5] en MESSAGE ontwikkeld bij IIASA [6]o

SELPE dat met bovengenoemde modellen in grote lijnen overeenkomt kan globaal als volgt worden gekarakteriseerd [7,8]: - Het model geeft een procesmatige beschrijving van de energievoorziening vanaf winnning en invoer~ via transport~ conversie en distributie tot en met eindverbruik. - De structuur van het complete energiesysteem is opgesteld als een netwerk van energiestromen. De netwerkstiuctuur maakt het qua aantal variabelen en vergelijkingen tamelijk omvangrijke model overzichtelijk en leent zich tevens goed voor het incorporeren van "concurrerende" toekomstige energietechnologieëno - De oplossing van het model genereert grootheden als: ¯ Optimale brandstofinzet. o Energie- en milieulasten van de verschillende sectoren (industrieën, gezinshuishoudingen, etc°)° . De energieprijsstijgingen, voor de verbruiker die bijvooorbeeld het gevolg zijn van bepaalde bestrijdingsmaatregelen en/of penetratie van duurdere energietechnologieëno ¯ Energiebaten (inkomsten) van de overheid, zoals aardgasbaten en aceijnzeno . Emissies totaal en per (Cao 17) subsectoren. o Energie-betalings-balans met buitenland. - Voor een berekening zijn een groot aantal invoergegevens nodig~ waar onder: ¯ Energieprijzen. ¯ Procesgegevens (kosten, rendement, etc.). ¯ Eindvraag naar energie. . Beleids- en aanbodrestricties.

Aangezien de ontwikkelingen in de energievoorziening en bijgevolg de beleidsvraagstelling regelmatig aan veranderingen onderhevig zijn, spree~t het vanzelf dat een model dat voor het analyseren en uitwerken van deze beleidsvragen wordt gebruikt~ ook regelmatig zal moeten worden aangepast°

Het LP-model SELPE was medio 1983 een relatief groot model en bevatte meer dan 600 variabelen en 500 vergelijkingen en een grote hoeveelheid invoergegevens. Het veranderen van de modelspecificatie en/of vele invoergegevens, zoals de procesparameters en modelexogenen (energieprijzen~ grenzen op intermediaire leveringen tussen processen etc.) vergde in toenemende mate mankracht en tijd en ging meer dan eens gepaard met fouten (bijvoorbeeld bij het invullen van onjuiste en/of strijdige data en vergelijkingen).

Het oorspronkelijke software-syteem bleek naarmate het model groter werd minder geschikt voor het snel en foutloos uitvoeren van veranderingen in en uitbreidingen aan een groot en complex model als SELPE. Het oorspronkelijke software-systeem waarin het model was geprogrammeerd, bestond namelijk uit een groot aantal programma’s nodig voor het vormen en aanbieden van het model aan het systeem AP~X III voor het genereren van een oplossing°

Aangezien variabelen, invoergegevens en vergelijkingen zich op afzonderlijke files bevonden, en in het oorspronkelijke software-systeem geen faciliteiten aanwezig waren om de correctheid van de vorming van het model te controleren~ was het in principe mogelijk om berekeningen uit te voeren met het model zonder de zekerheid te hebben met een correcte en gewenste modelspecificatie te hebben gewerkto In de praktijk werden de (gewijzigde) modellen gecontroleerd door de sing te analyseren~ doWoZo het model werd pas gecontroleerd na compilatie en executie van het model door het EP-oplossingspakket (APEX III) en dus nadat de nodige rekenkosten en tijd voor analyse aan een eventueel "fout" model waren besteed.

-10-

Het zelf ontwikkelde softwsre-systeem~ een soort van matrix-generator~ voldeed goed bij het aanbrengen van wijzigingen op beperkte schaal in de kleinere modelversieSo Nadat het model in omvang sterk toenam en vooral het snel kunnen veranderen van de modelspecificatie en/of invoerdata aan het begin en in het bijzonder tijdens de scenarioberekeningen zeer gewenst werd, schoot het software-systeem te kort. Bij wijze van proef werd daarom in 1984 het software-pakket GAMS (General Algebraic Modelling System) op de CDC-computer geïnstalleerd [9,10]. Door het programmeren van het grote LP-model SELPE in de modelleertaal GAMS moesten eerder genoemde beperkingen verbonden aan het gebruik van het zelf ontwikkelde software-systeem worden opgeheven.

Voor het tot stand komen van de hiervoor liggende versie van SELPE in GAMS gelden een aantal uitgangspunten° Allereerst is er naar gestreefd de meest recente, nog in de oorspronkelijke software geprogrammeerde versie van SELPE~ om te zetten (te programmeren) in de modelleertaal GAMS. De laatste versie van SELPE in het oorspronkelijke software-systeem betrof medio 1984 een model, dat resulteerde na uitbreiding van het aantal vraagsectoren van 7 naar 17 om een betere aansluiting te verkrijgen met het CPB-energievraagmodel CENECA [11,12]o

In de tweede plaats zijn bij het tot stand komen van SELPE in GAMS een aantal verbeteringen aangebracht in de modelspecificatieo Zo zijn bijvoorbeeld een aantal processen toegevoegd~ waardoor de substitutiemogelijkheden~ en zodoende de optimal~satieruimte en hiermee tevens de analyse-capaciteit van het model sterk wordt vergroot. Ten derde is de produktiecapaciteit van een proces in het model een endogene variable i.p.v, een exogene geworden. Ten vierde moet worden vermeld dat de waarden van modelgegevens~ zoals capaciteiten~ beschikbaarheidsfactoren, annuïteitenfactoren nu e×pliciete invoergegevens voor het model zijn°

-11

Tenslotte is bij de opzet van het model in GAMS zo goed mogelijk gebruik gemaakt van de vele facilite~ten, die GAM$ bezit. Met name is getracht een logische, gemakkelijk toegankelijke opzet van het model voor beleidsstudies te realiseren.

E.e.a. resulteerde eind 1985 in de vorming van een zgn. Basismodel van SELPE in GAMS. Dit Basismodel heeft in 1980 als ultgangspunt gefungeerd voor de NEV scenario-studie toboVo EZ (DGE) en de milieuscenario’s toboVo VROM (DGMR).

De opzet van het rapport is als volgt. In hoofdstuk 2 wordt aan de hand van een toe!ichting op het oorspronkelijke software systeem het belang geschetst van een modelleertaal bij het werken met grote LPmodellen voor het uitvoeren van scenario- en beleidsstudies. In hoofdstuk 3 worden vervolgens kort de belangrijkste eigenschappen van GAMS beschreveno Daarna wordt in hoofdstuk 4 de algemene opzet van SELPE in GAMS beschreveno In het daarop volgende hoofdstuk 5 wordt het bas~smodel SELPE beschreven. In hoofdstuk 6 worden de bij SELPE behorende hulpprogramma’s~ zoals het mult~-criteria programma MOLP en het grafische tekenprogramma TEN kort beschreveno Het rapport wordt tenslotte afgesloten met enige conclusies in hoofdstuk 7o

2. BELANG VAN EEN MODELLEERT~AL

Zoals ook reeds aangegeven in andere studies [10] is het bij het beoordelen van het functioneren van model-software van groot belang om te kijken naar de wijze waarop modellen worden gebouwd en vooral ook worden gebruikt voor beleidsstudies.

2.1o Oorspronkeli~jke software systeem In de eerste jaren waarin het SEL?E model operationeel was werd het nog relatief kleine model uitsluitend gebruikt voor het maken van berekeningen met een gegeven scenario(projectie) voor een groot aantal exogene variabelen, zoals de eindvraag naar energie, energleprijzen e.d. Door de aard van de vraagstelling van de opdrachtgeve~ kon worden volstaan met een beperkte hoevselheid veranderingen in de modelstructuur en input data alvorens opnieuw berekeningen werden uitgevoerd met het model. In de jaren daarna moest allereerst een steeds gevarieerder pakket van problemen, waaronder de effecten van prijsstijgingen van energie, optimale benutting van aardgasvoorraden en bestrijding van SO~- en NO ×-emissies opgelost worden. Ten tweede ging het hierbij voorts in toenemende mate om vragen die een meer gedetailleerde beschrijving van de energievoorziening vereisten. Het betrof bijvoorbeeld beleidsvragen m.b.t, bepaalde sectoren van de energievoorziening, zoals raffinaderijen, elektriciteitsopwekking, transport, etc. E.eoa. resulteerde in een sterk toenemende omvang van het model en aantal hulpprogramma’s. Bijgevolg werd het snel en foutloos veranderen van een bestaande modelspecifieatie en gegevenebestand ten behoeve van een nieuwe probleemstelling steeds moeilijker te realiseren. Het in verhouding vaak grote beslag aan mankracht, dat nodig was om telkenmale een nieuw of aangepast model te ontwikkelen, werd in toenemende mate als onacceptabel ervaren. Men ziet daarom ook vaak dat modellen maar eenmaal gebruikt worden voor een specifieke beleidsstudie. De mankracht nodig voor het aanpassen van het model voor een nieuwe studie, met een gewijzigde probleemstelling en modelspeclficatie, ontbreekt nl. eenvoudigweg.

De belangrijkste redenen waarom de oorspronkelijke modelsoftware niet aan bovengenoemde eisen kon voldoen, kan als volgt worden toegelicht. De oude opzet van de SELPE software bestond uit een groot aantal programma’s georganiseerd rond het LP-oplossingssysteem APEX III, zie figuur 2.1. De oude software was in feite een soort matrixmgenerator met de volgende onderdelen. Een file (VERGE)~ die alle vergelijkingen van het model bevat en een fi!e (VAR), die alle variabelen van het model bevat. Het programma (OMZET) voegt deze files tezamen, waardoor een model (structuur) wordt gevormd in MPS-format, die gedocumenteerd wordt op een file genaamd MODEL. De rij-struotuur van wiskundige vergelijkingen wordt dan omgezet in de kolom-structuur, die het MPSformat van het LP-oplossingssysteem vereist. In de file (INDIR) wordt volgens APEX voorschrift de waarde van de indirects alsmede de sturing van APEX III vastgelegd. De indirects kunnen per berekening (optimalisatierun met APEX III) verschillende waarden hebben. Vervolgens wordt de eerder gevormde file (MODEL), waarop het mode! met nog onbenoemde waarden voor de indirects is beschreven, tezamen met de daarop aansluitende file (INDIR), via een CDC-stuurkaartprogramma tot uitvoering gebracht. APEX berekent nu een optimale op!ossing en geeft een rapport hiervan in standaardvorm. Met het FORTRAN programma (TABEL) kunnen vervolgens de resultaten~ die zijn vastgelegd op de file FULL/SPEC), in leesbare (presenteerbare) tabellen worden omgevormd.

Het belangrijkste en meest kritische onderdeel van de modelvorming is ongetwijfeld de generatie van het mode!, d.w.z, het samenvoegen van vergelijkingen en variabelen van het LP~model probleem. Daarnaast is het van belang dat de file met de indirects (INDIR) aansluit op de indirects die in het model zijn gedefinieerdo Het leveren van een consistente input voor de matrix-generator (OMZET) blijkt een belangr!jke bron van fouten, omdat bij een wijziging in het model drie files afzonderlijk moeten worden veranderd° Dit is moeilijk consistent uit te voeren en leidt tot vele tijdrovende correcties. Met een niet-consistente en dus onjuiste specificatie van het model was het zelfs ook mogelijk om een oplossing te genereren. Om dit te verhinde~ ren was het mogelijk hiervoor een controle programma te schrijven.

-14-

Dit zou echter een forse inspanning vergen, waarbij het onzeker blijft of daarmee alle fouten in de modelvorming voorkomen kunnen worden.

2°2° Keuze modelleertaal

De toename van het aantal gebruikers~ de gevarieerdheid van de vraagstelling, en de bijgevolg vele uitbreidingen van het model~ leidde tot een toenemende behoefte aan een beter software-systeem voor SELPEo Dit software-systeem zou aan de volgende eisen moeten voldoen° - De modelstruetuur en data van bestaande modellen moeten snel en foutlooe tob.Vo uiteenlopende studies en probleemstellingen kunnen worden veranderd° - Het documenteren van het model moet vergemakkelijkt worden om snel en herhaald gebruik van het model voor verschillende etud~es en door verschillende beleidsanalisten mogelijk te maken. Voorts moet de rapportage van de resultaten versneld worden. - Een goede communicatie tussen verschillende modelmakers en tussen modelmakers en opdrachtgevers (beleidsvoorbereiders) is gediend met een overzichtelijke en logische programmering van de verschillende modelonderdelen~ zoals modelstructuur~ variabelen, data en oplossing (outputs); - Ontwikkelde sub-modellen met een veel grotere mate van detail dan het Baslsmodel SELPE en hulpprogramma’s moeten relatief snel ontwikkeld en

eenvoudig op elkaar "aangesloten" kunnen worden.

Ongeveer twee jaar geleden kon een keus gemaakt worden uit globaal drie opties voor het verbeteren van de model-software. Allereerst kon bestaande software worden verbeterd. Ten tweede kon gebPuik gemaakt worden van de commerciële matrix-generator, genaamd PDS-Magen. Ten derde kon gebruik gemaakt worden van een modelleertaal genaamd GAMSo De modelleertaal was reeds succesvol toegepast bij diverse studiecentra, maar (nog) niet commercieel beschikbaar [13,14,15].

Ter toelichting het volgende° Een modelleertaal kan wellicht het be~te worden gedefinieerd aan de hand van bepaalde eisen~ die men als modelbouwer aan een modelleertaa~ zou willen stellen, zie ook R. Fourer E16] hierover. Te denken valt dan aan de volgende eis: Elk model (LP-probleem) moet in eenvoudige wiskundige termen kunnen worden gedefinieerd onafhankelijk van de wijze waarop de computer het model moet verwerken (leest)° Deze eis betekent allereerst dat een model geformuleerd moet kunnen worden in de conventionele wiskundige notatie° De computer zelf moet kunnen zorgdragen voor de "vertaling" van het in de modelleertaal geformuleerde model (LP-probleem) naar de inputformat van de oplossingssysteem (bij LP is dit het MPS-format). De keuze van de modelleertaal als softwaresysteem voor SELPE was gebaseerd op de volgende overwegingen. De eerste optie, nl. het zelf ontwikkelen van een modelsoftwaresysteem dat aan de eerder (blz. 14) genoemde eisen moet kunnen voldoen zou een te grote inspanning qua mankrachtp specifieke kennis en te lange looptijd met zich meep brengen° Dit was niet acceptabel. De commerciële matrixgenerator PDS-Magen is volledig ontwikkeld en is vooral succesvol m.b.t, het data management van grote LP~modellen. De modelvorming blijft echter gebaseerd op het omzetten van de rij-struetuur van de in de conventionele wiskundige notatie geschreven vergelijHingen in de kolomstructuur, die de computer kan lezen. Het vormen van het model is hierdoor gebonden aan een somputergerichte definitie van het model in het software systeem, waardoor een belangrijke foutenbron aanwezig blijft° Aangezien juist de modelleertalen ontwikkeld zijn om dit type fouten te vermijden en wel door een "mensgerichte" modeldefinitie mogelijk te maken is uiteindelijk gekozen voor het gebruik van de modelleertaal GAMSo Een andere overwegin~en die bij de keuze van belang is geweest betrof het feit dat een modelleertaal als GAMS een logische volgende stap is na de matrix-generator in de ontwikkeling naar een meer ’~mensgericht" model-software-systeem.

-16-

Figuur 2 1 : Stroomschema voor berekeningen met oorspronkelijke software-systeem

3° EIGENSCHAPPEN GAMS

3.1. Algemeen Het General Algebraic Modelling Sy~tem (GAMS) is de afgelopen jaren ontwikkeld bij de modellenondersteuningsgroep van de Wereld Bank [14,15]. Het doel was om een modelleertaal te ontwikkelen waarmee globaal gesproken de produktiviteit van de modelbouw verbeterd kan worden. GAMS bezit hiertoe de volgende eige~schappen: I. Het is een hogere taal voor een compacte weergave van grote en complexe modellen (lineair en nlet-lineair); 2o Het bezit een automatische interface voor verschillende oplossingscodes; 3o Het systeem bevat algebraïsche relaties, waarmee zgn. "symbolische" vergelijk~ngen kunnen worden gedeclareerd; 4. Via een compiler en/of executie procedure kunnen symboliache en data fouten worden gedetecteerd, waarvan verslag wordt gedaan tob.vo correctie; 5o Het is mogelijk o.a. door zelf aangebrachte statements, data checks uit te voeren op de modelspecificatie voordat deze (in APEX) wordt geëxecuteerd; 6, Met behulp van zgn. "utility programe" kan met modellen buiten GAMS gecommuniceerd worden; 7~ Voor naamgeving in GAMS zijn 10 karakters beschikSaar; 8. Er zijn veel mogelijkheden voor het opnemen van toelichtingen en commentaar.

Ter toelichting kan het volgende worden opgemerkt. Met een compacte weergave wordt vooral beoogd de meest grote en comple×e modellen toch overzichtelijk te kunnen programmeren om de toegankelijkheid van het model voor anderen dan de programmeur te vergroten. Voorts wordt hierdoor de overdraagbaarheid van een model bevorderd.

Ten aanzien van punten 2 en 3 het volgende. Over de voordelen en wenstheid van een automatische interface tussen het in wiskundige termen geformuleerde model in GAMS en de oplossingsalgorithme is

reeds in het vorige hoofdstuk aandacht geschonkeno

~outendetectie (punt 4 en 5) komt verderop in het rapport nog wat uitgebreider aan de orde~ Hetzelfde geldt voor de "util~ty programs" (punt 6)~ waarvan het gebruik in Appendix II aan de orde komt°

Het feit dat i.p.Vo 8 of minder~ zoals gebruikelijk, nu 10 karakters beschikbaar zijn (punt 7) voor een goed leesbare codering (naamgeving) van de modelelementen (bijv. processen) is van belang, omdat bij zeer grote modellen hiervoor altijd karakters te kort komen° Tenslotte kan het geven van toelichting (punt 8) op de juiste plaatsen de toegankelijkheid en overdraagbaarheid van het model sterk vergrotenD

3.2. Systeembeschrijving Het GAM$~systeem bestaat uit twee delen, waardoor het model afzonderm lijk gecompileerd en geëxecuteerd kan worden: ao 6AMSC: het compilatie-subsysteem; bo GAMSE: het executie-subsysteem

Het compilatie-subsysteem bestaat uit het compileerprogramma, terwijl het executie-subsysteem uit een aantal computerprogramma’s en stuurprocedures bestaat. Hieronder vallen ook de interfaces die de GAMS~ input naar verschillende oplossingssystemen~ zoals APEX, MINOS en CONOPT kunnen vertalen.

In een geïntegreerd systeem zouden alle verwerkingen als één geheel op elkaar moeten aansluiteno ~et aantal files is dan geminimaliseerd tot twee, nl. de modelinputfile en de oplossingsoutput. Bij het GAMS-systeem wordt echter met 3 files gewerkt. De derde file biedt de mogelijkheid kleine veranderingen in het model aan te brengen en nog~ maals het oplossingsalgoritme te executeren zonder het gehele model opnieuw te compileren ("continued compiiation" optie).

-194

Kortom het OAMS-systeem bevat dus drie files~ t.w.: a. De modelfile Hierin is het model overzichtelijk beschreven en zijn alle structurele informatie en modelgegevens opgenomen° bo De modeloutputfile Hierin wordt de (N)LP-oplossing op een overzichtelijke manier volledig geprint.0ok de door de gebruiker gewenste (tabellen-)outputs worden hierop weggeschreveno c. De workfile Hierin wordt alle informatie in gecompileerde vorm opgeslageno Voorts zijn alle executie-outputs hierin opgeslagen~ bijvo de lossing van het aangeroepen oplossingsalgorithme. Bij het opnieuw aanroepen van een oplossingsalgorithme wordt allereerst opnieuw deze basis-oplossing gecreëerd door G~MS, die vervolgens wordt aangeboden aan het oplossingsalgorithme. Hierdoor worden veel tijd en computerkosten vermedeno

Bij het werken met GAMS zijn globaal drie gebruikersmogelijkheden te onderscheiden: I. Initiële compilatie; 2o Executie van het model; 3. Voortgaande compilatie ("continued compilation")o

Hieronder kunnen de gebruiksmogelijkheden kort worden toegelicht, zie ook figuur 3oio Voor een meer uitgebreide toelichting wordt overigens verwezen naar de gebruikershandleiding in appendix Io

Compilatie Allereerst wordt een model in GAMSC gecompileerd. Bij deze initiële compilatie wordt een workfile en een verslag (logfile) gecreëerd~ die alle gegevens (statements) uit het programma bevat in gecompileerde vorm. Het programma wordt ook op syntax-fouten ondeìzocht, die vervolgens worden vermeld in workfile en verslag. De workfile kan pas na correctie van de fouten voor de executie van het model binnen 6AMSE gebruikt worden.

De volgende stap is het executeren van het model in G~MSE. Na executie van nog niet geëxecuteerde statements wordt de mod~~~~trix gevormd tot een inputfile voor de betreffende oplossingsalgorithme (meestal in APEX III). Eoeoa. wordt echter onderbroken, indien door checks fouten worden gedetecteerd in de specificatie va~ het mode!. Uitsluitend een model dat geen fouten in de modelmatrix Devät kan naar Apex III worden toegestuurd. De oplossing (output) wordt in standaard format in GAMS opgeslagen in de workfileo Voorts wordt een logfile gevormd, die een verslag van het tijdsverloop van de executie bevat.

Tenslotte kunnen met behulp van deze standaard-outputs naar wens verschillende output-tabellen gegenereerd worden (report writing). Deze outputtabellen maken het interpreteren en verwerken van modelresultaten gemakkelijker. Tevens kunnen totaaloverzichten worden uitgelezen.

Voortgaande compilatie Bij het gebruik van GAMS speelt de workfile een belangrijke rol. Deze file maakt het mogelijk dat een model in afzonderlijke stappen wordt gecompileerd, geëxecuteerd en indien gewenst zonder veel extra rekentijd kan worden veranderd. De laatste optié~ het wijzigen van het model vindt als volgt plaats.

De GAMS-compiler compileert de nieuwe inputfile met daarop de veranderingen en voegt tevens de gecompileerde informatie toe aan de aangeboden workfile.

In de ihputfile staan voorts toekenningsstatements waarmee de oude data kunnen worden overschreven. Tenslotte kan m.b.v, het Solvestatement het oplossingssysteem (hier APEX III) opnieuw worden aangeroepen. Het zal duidelijk zijn dat deze optie van voortgaande compilatie de rekenkosten aanzienlijk beperkt.

Zo kunnen bijvoorbeeld per scenario en/of zichtjaar de parameterwaarden in de tabellen worden aangegeven en/of veranderd, zonder dat het model opnieuw geheel gecompileerd en geëxecuteerd moet worden. Uitgaande van een bestaande basisoplosslng kunnen aldus de gevolgen van kleine veranderingen in de data per scenario snel met het basismodel worden doorgerekend, zie figuur 3°2° Tenslotte dient nog een mogelijkheid genoemd te worden waarmee in het geval van scenario-studies de handelbaarheid van het model in GAMS vergroot kan worden. Het gaat hierbij om het opsplitsen van het model in delen, waarvan sommige delen bijvo de structuur van het model vatten, die niet per scenario verschilt en andere delen data bevatten welke wel per scenario verschillen. Het deel waarin de procesdata zijn weergegeven kan bijv. los van de overige modeldelen gevuld den met gegevens uit een PC-file, die door de ESC-data base is gevuld. Voor een meer uitvoerige toelichting raadplege men appendix Io

- 22 -

Figuur 3.1.: Het GAMS-systeem voor de gebruiker

I

GAMS-model

l

GAMSE

manrixgenerator

repor~-writer

wijzigingen

L~_-

APEX-III "-- -~

report ]

model SELPE]

~workfile: ~FMODEL1 rekenprocedure jaar 2000 I

model 2000

~ rekenprocedure Jaar 2010

"solve-card" model 2010 --

J GAMSC + GAMSE I

~ GAMSC + GAMSE ~ i reporting ~

wijzigingen] 2010 ~

- 24 -

4. ALGEMENE OPZET SELPE IN GAMS

4.1. Modelstructuur

De energievoorziening wordt in het model beschreven d.m.v, een aantal energieconversies en onderlinge leveringen van energie° Dit betekent dat de modelstructuur in principe wordt gevormd door een netwerk van processen en energiestromen tussen deze processeno

In de hiervoor liggende Basismodel van SELPE in GAMS vormen de conversieprocessen de knooppunten van het modelnetwerk, terwijl de (verzameling van) onderlinge leveringen van energie~ de relaties tussen de knooppunten vormen. De knooppunten, waarbinnen conversies van energie worden gedefinieerd zijn dus producenten en/of sonsumenten van energiedragers. Deze energieverwerkende organisaties (beslissers) worden in het onderhavige model producers genoemd. Het kan hierbij gaan om een energiebedrijf~ zoals de Gasunie~ Vegin~ maar ook bepaalde specifieke energie-omzettingen, -distributies e.d. Producers leveren en/of ontvangen energiedragers. Binnen een producer zijn dus tussen processen geen onderlinge leveringen van energie mogelijk, m.a.w. de producers zijn eenduidig gedefinieerd als de knooppunten van het modelnetwerk. In de volgende paragraaf 4.2. zal het begrip producer nader worden toegelicht. Het tweede element van het modelnetwer~ t.w. de energieleveringen aan, tussen en van producers (knooppunten) worden in GAMS gedefinieerd in drie tabellen, genaamd "Resource", "Intermed" en "Delivery".

In de tabel "Resource" worden de op de leveringen naar producers (winning en invoer) betrekking hebbende energiestromen gedefinieerd. De onderlinge leveringen tussen producers worden gedefinieerd in tabel "Intermed" en de leveringen van producers aan de eindvraag-categorieën (de gegeven eindvraag naar energie) wordt in tabel "Delivery" gedefinieerd. In paragraaf 4.3. zullen deze tabellen worden toegelicht.

- 25 -

4°2° Proceshiërarchie binnen Producers

In het hier voorliggende Basismodel in GAMS zijn de conversieprocessen binnen een producer (knooppunt) verder gedesaggregeerd op verschillende niveaus. Dit is gebeurd om verschillende typen van energieconversies te kunnen onderscheiden en zo de gewenste beschrijving van de energievoorziening te realiseren° In het Basismodel worden vijf (binnen een producer drie niveaus) onderscheiden~ toWo het niveau van sectoren, producers, plants, units en processes~ zie ook figuur 4.1 en

PRODUCER

PLANT-Io

PLANT-2--

¯ UNIT-I I~ ~UNIT-I 2~

PROCES-111

~ROCES-11

PROCES-113’~ <

Figuur 4.1.: Grafische weergave van de hiërarchische structuur binnen een knooppunt (producer) van het SELPE-netwerk

-26 -

I~ieronder volgt een toelichting op de vijf niveaudefinitieso

N~veau-1: Sectors Sub-sectoren van het Basismodel zijn bijv. de gas-, olie- en industrie-sector van de energievoorzieningo Op dit niveau worden de uitkomsten van berekeningen in balansvorm gepresenteerd~ Door de definitie van de verschillende subsectoren kunnen diverse energieleveringen en consumpties worden samengevoegd, afhankelijk van de wensen mob.t. de op te stellen energie- en emissiebalansen.

Niveau-2= Produeers Allereerst worden op dit niveau de knooppunten in het modelnetwerk, die de energievoorziening beschrijven, gedefinieerd. Een producer representeert meestal een organisatie (beslisser), die in de energievoorziening een specifieke functie (activiteit) vervult, zoals de olie- en gaswinning, raffinage, gasverkoop etc°° Bij de activiteiten van deze (soms fictieve) organisaties kan men in het algemeen denken aan importeren~ winnen, omzetten, distribueren en consumeren van energiedragerso De meeste producers representeren echter een bepaalde vorm van conversie van energie en een beperkt aantal producers houdt zich uitsluitend met distributie van energie bezig, zoals bijvo de verdeling van olieprodukten. Die olieprodukten worden ontvangen van de producers raffinaderijen en invoer en verder verdeeld over de verschillende verbruikers (ook producers), zoals de centrale openbare elektriciteitsproduktie, chemie, huishoudingen e.d.. Op het aggregatieniveau van "producers" dienen bijgevolg de belangrijkste beslissers die energie aan elkaar leveren in de energievoorziening te worden onderscheiden, Binnen een producer kan op verschillende wijzen energie worden opgewekt° Hiertoe worden binnen een producer, op drie niveaus, conversie-activiteiten onderscheiden° De drie niveaus worden hieronder nader toegelichto

N~veau-3: Plants Dit betreft het meest geaggregeerde niveau waarop een conversie-activiteit (techniek) wordt geiefinieerdo In feite betreft het meestal een groep van gelijksoortige energietechnieken~ zoals warmtekrachtop-

- 27 -

wekking, stoomproduktie~ opwe~king proceswarmte dom. V. fornuizen e.d.~

Niveau-4: Unlts Op dit niveau wordt een groep van gelijksoortige energietechnieken verder opgesplitsto Te denken valt hierbij voor W/K-opwekking aan technieken, zoals tegendrukturbines, gasturbines, etc°° Binnen de stoomproduktie worden technieken~ zoals ketels, warmtepompen~ zonnecollectoren etc. onderscheiden. Binnen het "unit-niveau" worden dus een aantal qua p
Niveau-5: Proeesses Een proces is het meest gedesaggregeerde niveau waarop energieconversies worden weergegeveno Op dit niveau wordt een proces naar specifieke brandstofinput en -output en overige modelparameters, eenduidig gedefinieerdo Zo wordt bijvo op dit niveau een gasturbine opgesplitst in een gasturbine met aardgas en een gasturbine met raffinaderijgas als input. Op dit niveau wordt bijgevolg ook onderscheid gemaakt in em~ssies en wijze van bestrijding daarvan.

De hierboven genoemde hiërarchie en classificatie van technieken op verschillende aggregatieniveaus is expliciet weergegeven in de tabel "set hierarchy of processlabels~’o In deze tabel wordt een volledig overzicht (procesboom) gegeven van alle technieken in het Basismodel, op de (vier) verschillende aggregatieniveaus. Met behulp van een hulpprogramma (zie ook paragraaf 6°4°) kan vanuit deze tabel alle in deze procesboom weergegeven relaties "automatisch,~ expliciet worden gegenereerd in een tabelvorm, die GAMS leest en nodig heeft om het model te declareren. Dit gebeurt in de vorm van een aantal "master-

- 28 -

listen", waarin voor elk niveau de technieken in het model gedeclareerd worden. Het betreft bijgevolg een "masterlist" voor alle in het model gespecificeerde producers~ plants, units en processeso Voorts zijn er "masterlisten" om de relaties tussen de producer~ en plants, plants en units~ unitB en processes en producers en proc~sses te beschrijven.

PRODUCER

PLANT

UNIT

PROCES

/ Gasturbine\~ Gasturbine

~ Aardgas W/K ~,~~ STEG ~ Gâs~urb~n~/ as R f ina e ij-g

~ Chemie

Proces~ Tegendrukwarmte

turbine

Stoom

Figuur 4.2.: Gedeelte van de proces-hiërarchie van producer chemie

4.3. Energiestromen

De leveringen van energie in de energievoorziening worden in het modelnetwerk weergegeven door energiestromen naar, tussen en van producers (knooppunten van het netwerk)° De energiestromen naar, tussen en van producers worden gedefinieerd in een drietal tabelleno In de tabel "Resource" worden alle energiestromen naar producers gedeflnieerdo In tabel "Intermed" worden de energieleveringen tussen producers onderling gedefinieerd en in tabel "Delivery" worden de leveringen van producers aan de eindvraagcategorieën gedefinieerd.

In deze tabellen worden overigens niet alleen de leveringen aan, tussen en van producers gedefinieerd, maar bevatten ook gegevens over de omvang, kosten etc. van deze leveringen Hieronder volgt een nadere toelichting op deze structuur- en gegevenstabelleno - ,,Resource~~ In de tabel "Resource" worden alle leveringen aan producers gedefinieerd. De tabel "Resource" bevat derhalve een definitie van alle invoer- en winningstromen van energiedragerso Volledigheidshalve zijn ook de inputs van stromingsbronnen, zoals wind~ zonnewarmte etc. naar producers opgenomen in deze tabel. Voorts kunnen indien nodig in deze tabel invoer- en winningskosten worden toegekend aan de inputs van de producerSo De eerste datakolom bevat namen van ontvangende produoers en de tweede datakolom bevat de namen van energiedragers, die worden geleverd. De volgende datakolommen bevatten kosten en boven- en ondergrenzen op leveringen. - ,Intermed" Alle onderlinge leveringen tussen producers worden beschreven in de tabel "Intermed". De eerste datakolom bevat namen van de produoers, die leveren en de tweede datakolom bevat de namen van de ontvangende producerso De derde kolom bevat de namen~ van de energiedragers die aan elkaar geleverd worden. De laatste vier datakolommen hebben betrekking op respectievelijk de boven- en ondergrenzen, transportverliezen en de kosten van de leveringen. - ~’Delivery" In de tabel "Delivery" worden alle leveringen van producers aan de eindvraag categorieën beschreven. De tabel "Delivery~’ heeft dezelfde opbouw als de "Intermed~’ tabel, maar bevat nu de exogene finale vraag naar energiedragers per verbruikscategorie. Het betreft 17 verbruikssectoren waaraan door "producers~~ energie wordt geleverd. Deze 17 verbruikssectoren zijn overigens eerder tezamen met de producers reeds gedefinieerd in een ~asterlist. De finale vraag naar energiedragers anders dan elektriciteit, stoom, proceswarmte~ warm tapwater betreft grotendeels de vraag naar grondstoffen. De vraag naar grondstoffen wordt meestal rechtstreeks door de betreffende energie-industrieën geleverdo Een zeer klein deel van de energiedragers, bijv. cokes, LPG~ etco~ betreft de vraag naar energie

waarvoor niet-expliciet een verbrandingsproces is gespecificeerd producers~ zoals voeding- en genotmiddelen, papierindustrie etc°°

- 31 -

5. MODELBESCHRIJVINO

5oio Inleiding De in hoofdstuk 4 gegeven toelichting op de algemene opzet van SELPE in GAMS en de wijze waarop hierin de energievoorziening d.m.v, een modelnetwerk wordt weergegeven zal in dit hoofdstuk nader worden geconcretiseerd. Hierbij zal een meer inhoudelijke beschrijving van het Basismodel worden gegeven. Allereerst zullen de modelvergelijkingen worden toegelicht, die het model beschrijven in kwantificeerbare termen. Vervolgens zal in paragraaf 5.3. een meer concrete beschrijving van de in het model aanwezige producers, eindvraag categorieën, plants, units en processen volgen° Vervolgens wordt aandacht geschonken aan de gegevens waarmee het model wordt gespecificeerd, zie paragraaf 5°4° In paragraaf 5.5. worden de overige onderdelen van het model besproken. Het hoofdstuk wordt afgeloten met een totaal overzicht van alle onderdelen (secties) van het mode!.

5°2° Modelvergelijkingen Voor het goede begrip van de werking van SELPE is het nuttig de in GAMS gedeclateerde (symbolische) algebraïsche modelvergelijkingen van het basismodel toe te lichten. Overigens wordt hierbij niet de GAMSnotatie gevolgd om de leesbaarheid te vergroteno Men kan globaal zes typen vergelijkingen onderscheiden, t.w.: - Energiestromen-vergelijkingen - Capaciteitsvergelijkingen~ - Overige restricties, w.o. emlssievergelijkingen; - Doelfunctie.

- 32 -

Energlestromen-vergelijk~ngen Energie-balansvergelijkingen: Xik + [Wiv + ~aik’k * zik’k + ~Jip * Yp : [Zikk’ + ~vikg V k’ p k’ g

(1)

Voor alle Hierin is: xik = de import van energiedrager i door producer k in PJ/jaar w.

= de binnenlandse winning van energiedrager i in veld v uitgedrukt in PJ/jaar

Zik,k = de intermediaire levering van energiedrager i door producer k’ aan producer k in PJ/jaar aik,k = de coëfficiënt behorende bij Zik,k waarin transportverliezen verrekend zijn Jip

= "yield" van energiedrager i in proces p

yp

= de variabele die het procesniveau van proces p weergeeft in PJ/jaar

Vikg

= de levering aan de finale verbruiker g door producer k van energiedrager i in PJ/jaar

Bovenstaande vergelijking realiseert dat de som van de ingaande stromen in een knooppunt (producer) gelijk is aan de som van de uitgaande stromen, rekening houdend met eventuele omzettingen en/of rendementsverliezen binnen het knooppunt (producer). De balansvergelijking zorgt er voor dat alle energie, waaraan in het knooppunt behoefte is, ook geleverd wordt.

De som van de ingaande stromen bestaan uit importen, binnenlandse winning, netto binnenlandse leveringen. De som van uitgaande stromen is gelijk aan binnenlandse leveringen aan andere producers en de eindvraag naar energie te leveren door producer k.

- 33 -

Vergel~jkingen voor het energieverbruik binnen producers:

(2)

+ ~Wiv + ~aik’k * Zik’k ~ ~-Jip ~ Yp voor alle p v k~ Jip < o

Voor ×ik’ Wiv’ aik’~’ Zik~k~ Jip en yp zie vergelijking (I).

Deze vergelijking is ingevoerd om te voorkomen dat er onderlinge leveringen tussen processen binnen een knooppunt (Droducer) zullen plaatsvindeno De vergelijking zorgt er daarom voor, dat de aan een producer geleverde energie gelijk is aan de energie, die binnen een producer (door de processen) benut wordt°

Proceelevelvergelijkingen:

De onderstaande vergelijkingen zorgen ervoor dat geen strijdigheden tussen proceeoutputs op de verschillende aggregatie-niveaus kunnen ontstaan. Allereerst wordt het proceslevel op unit-niveau bepaald:

Yu = ~Yp

voor alle u(nits)

(3a)

P

Hierin is: Yu ~ proceslevel op unit-niveau Voor yp z~e vergel~jl~ing (I). Vervolgens definiëren we het proceslevel op plant-niveau:

Ypl = [Yu voor alle pl(ants) u

Hierin is: Ypl : proceslevel op plant-niveau Voor Yu zie vergelijking (3a)o

(3b)

Vergelijkingen voor teruglevering aan openbare net door zelfopwekkers (producenten van elektriciteit buiten de openbare ele~triciteitsbedrijven):

Bovenstaande wordt beschreven door middel van twee gekoppelde vergelijkingen. Allereerst wordt de elektriciteitsproduktie van zelfopwek~ kers op p~ant-niveau bepaald°

elpl : ~Yp ~ Jep P

voor alle pl(ants)

(4)

Hierin is: elpl = de variabele die de totale elektriciteitsproduktie per plant in PJ!jaar weergeeft Jep = "yield" van elektriciteit in proces p

Voor yp zie vergelijking (I)o

Vervolgens wordt geëist dat de teruglevering van (een gedeelte van) deze elektriciteit aan het openbare net groter is dan de zelfopgewekte elektriciteit vermenigvuldigd met een reserve-capaciteitsfactor.

Ze~ ~ ~repl * elpl pi

voor alle k

Hierin is: Zek = de levering van elektriciteit door producer k in PJ/jaar aan het openbare net repl = de reserve-factor behorende bij plant pi Voor elpl zie vergelijking (4)°

(5)

- 35 -

Capaciteltsvergelijkingen: Procescapaciteitsvergelijkingen:

Cp ~ b P ~uP ~yp* e P Hierin is: c

P b P u P e P

voor alle processen

(6a)

capaciteit van proces p (PJ/jaar of MW) omrekeningsfactor van proces p beschikbaarheidsfactor van proces p elektriciteitsdeel van de output (PJ/jaar) van proces p, indien dit deel groter dan nul is

De omrekeningsfactor is nodig om, indien de dimensies van capaciteit en output verschillen~ deze toch te kunnen relateren aan elkaar.

Voor yp zie vergelijking (I)o

Onderstaande vergelijking realiseert dat het opgestelde vermogen (capaciteit) van elke unit gelijk is aan de som van de capaciteiten van de tot deze unit behorende processeno

cu : ~Cp voor alle u(nits) (6b) P Hierin is: cu = de capaciteit op unit-niveau (PJ/jaar of MW)

Voor c zie vergelijking (6a)o P Cpl = ~cu voor alle pl(ants)

(óc) u

Hierin is: Cpl = de capaciteit op plant-niveau (PJ/jaar of MW) Voor c zie vergelijking (6b). u

Vergelijking (6c) impliceert dat de capaciteit op plant-niveau van een techniek gelijk is aan de som van de capaciteiten van de units die tot deze plant behoren.

Reserve-oapaciteitvergelij king:

(7)

~Cpl ~ rCpl >_- ~(Zek~ + xe) ~ rf pi k’

Hierin is: Cpl = capaciteit op plant-niveau in PJ/jaar of MW rCpl : reservefactor behorende bij plant pi Zek, = de intermediaire levering van elektriciteit in PJ/jaar van producer k’ aan de producer, die de openbare elektriciteitsvoorziening verzorgd x ~ import van elektriciteit in PJ/jaar e rf = universele reservefactor voor de elektriciteitsvoorziening

Overige restricties Overige restricties betreffen een vergelijking, die de levering (aandee!) van cokesgas en hoogovengas aan de openbare elektriciteitsopwekking weergeeft en een restrictie, die de verhouding tussen cokesen hoogovengas bepaald (vergelijkingen GASRESTR.I en 2). Voorts vergelijkingen voor het aandeel van piekelektriciteit in totale behoefte aan elektriciteit en de daaraan gerelateerde plek-capaciteit (vergelijkingen ELEKRESTRo I en 2).

Vervolgens is ook een vergelijking in het model aanwezig voor de specificatie van de emissie.

dkr = ~ (yp/rp) * Orp

voor alle k,r

(8)

P

Hierin is: dkr = de totale uitstoot van stof r door producer k, uitgedrukt in tonnen. o ~ emissie van stof r door proces p in tonnen per PJ. rp r = efficiency van proces p. P Voor yp zie vergelijking (I)o Deze vergelijking bepaalt voor iedere producer de totale uitstoot van milieu-belastende stoffen, zoals NO en SOlo x

- 37 -

Doelfunctie Tenslotte wordt de vergelijking, die de totale kosten van de Nederlandse energievoorziening voor een bepaald zichtjaar definieert, weergegeven. Deze luidt:

( impor tkosten)

(winningskosten) i v + ~ alp * COip * cb

P

( invester ingskosten)

P (proceskosten)

+ ~yp * COp P + [ [ [COik,k ~ Zik,M k k’i

(distributiekosten)

( lever ingskosten) gk i

Hierin is: TC

= de totale kosten van de Nederlandse energievoorziening voor een bepaald zichtjaar in mln guldens

COik

= de kosten per eenheld import van energiedrager door producer k in min guldens

co. iv

= de kosten per eenhe~d winnlng van energiedrager in veld v uitgedrukt in mln guldens

af P

= de annuïteitenfactor voor proces p die bepaald wordt uit de levensduur en rente van dit proces

coi P

= de investeringskosten in min guldens per eenheid capaciteit van proces p

(9)

- 38 -

eb P

-- de nieuw gebouwde capaciteit van proces p in PJ/jaar of MW de kosten per eenheid procesoutput (yp) van proces p in min guldens

COik,k =

de distributiekosten per eenheid intermediaire levering van energiedrager i door producer k~ aan producer k in mln guldens

COikg ~ de kosten per eenheid levering aan de finale verbruiker g van energiedrager i door producer k in min guldens

Voor Xik~ Wiv, yp, Zik,k en Vikg zij verwezen naar vergelijking (I).

5.3. Beschrijving producers en eindvraagcategorieën

In het Basismodel van SELPE is getracht de energievoorziening zo goed mogelijk te beschrijven rekening houdend met eerdere modelversies van SELPEo Hieronder worden de in het model aanwezige producers nader toegelicht, zie ook figuur 5oio

GAMS-naam

Toelichting/definitie

NAM-ETC

Deze producer betreft de winning van Nederlandse aardgasen olievoorradeno Bij de winning van aardgas wordt onderscheid gemaakt tussen on-, offshore en Slochterenvelden. Bij de winning van ruwe olie wordt onderscheid gemaakt tussen on- en offshore produktie.

GASUNIE

Hieronder vallen alle onder beheer of in nauwe relatie met de Gasunie uit te voeren activiteiten. Hieronder valt ook het maken van vloeibaar aardgas~ aanlanding van LNG en een toekomstige optie voor kolenvergassingo

GU-TRANS

Binnen deze producer is het aardgastransport vanaf Gasunie naar industriesectoren~ VEGIN e.d. gedefinieerd.

VEGIN

Hieronder vallen de inkoop van aardgas (van GU-TRANS) en eventueel ook de toekomstige produktie van gas uit kolen.

- 39 -

VEG-DISTR : Distributie van aardgas van VEGIN naar andere sectoren, zoals landbouw, gezinshuìshoudingen eodoo

OIL-REF

: De raffinage van ruwe aardolie, d.w.z, de inputs betreffen ruwe olie en elektriciteit, stoom en proceswarmte als hulpinputs. De outputs zijn alle in het model gedefinieerde olieprodukten, zoals LPG, raffinage-gas, benzine, lichte- en middendestillaten enz..

REF-DISTR : Hierin worden de via raffinage geproduceerde en dom,V.

invoer verkregen olieprodukten gedistribueerd naar andere producers, zoals chemie, transport, openbare elektriciteitsopwekking, enz..

REF-UTIL

: Dit betreft de energie (stoom, warmte, elektriciteit) opwekking binnen de raffinaderijen. Hierbij zijn verschillende fornuizen-, ketels- en W/K-opties onderscheiden. Inputs als raffinage-gas en stookolie komen rechtstreeks van de producer "OIL-REF".

RFUT-EL-DI: Distributie, doWoZ, de levering van elektriciteit, in

producer ’~REF-UTIL" geproduceerd aan raffinaderijen (OIL-REF) en openbare net (PUBL-EL-TR). RFUT-HE-DI: De stoomdistributie en wel voornamelijk naar raffinade-

rijen (OIL-REF). COAL-EXTR : Winning van kolen, incl. ondergrondse kolenvergassing. COCO-STOR : Deze producer ontvangt kolen uit invoer en winning en

vervult de functie van "overslag van kolen aan diep water". Hier vandaan worden kolen direct en indirect (via produeer COAL-TRANS) aan diverse producers, zoals cokesfabrieken geleverdo COAL-TRANS: Deze producer is nodig voor het weergeven van de leve-

ranties van kolen, waarbij transport vanuit de "overslag aan diep water" naar binnenlands gelegen verbruikers nodig iso Zodoende kunnen de extra kosten en energieverliezen, die het transport met zich meebrengt in rekening worden gebracht° COKES-FACT: Cokesfabrieken. COAL-LIQ : Methanolproduktie uit kolen~

- 40 -

PUBL-EL-PP: Dit is de openbare elektriciteitsopwekkingo Binnen deze

producer worden verschillende opwekkingsopties onderscheiden, zoals pieklastproduktie mob.v, gasturbines, STEG-, conventionele olie- en gaseenheden, maar ook verschillende typen (qua emissies/kosten) kolencentrales, kerncentrales~ vuilverbrandingseenheden etc°°

PUBL-EL-TR~ Transport van elektriciteit via het openbare (hoogspannings) net van openbare opwekking, uit invoer van elektriciteit en openbare opwekking naar andere producers, zoals industrieën, gezinshuishoudingen eodoo

PUBL-EL-DI: Distributie van elektriciteit via het openbare (laagspannings) net van de openbare opwekking (PUBL-EL-PP) naar andere producers, zoals gezinshuishoudingen, landen tuinbouw e.d..

DIST-EL-PP: Openbare W/K-opwekking, waarbij opties als tegendrukturbine en STEG worden onderscheiden.

DIST-EL-DI: Elektriciteitsdistributie van openbare W/K-opwekking. DIST-HE-DI: Stoomlevering van openbare W/K-opweiklng. HEAT-PRODP: Wijk- en stadsverwarming, waarbinnen zich ook opties als geothermie en warmtepompen bevinden. HEAT-PR-TR: Stoomtransport van wijk- en stadsverwarming. HEAT-PR-DI: Stoomdistributie van wijk- en stadsverwarming. BLASTFURN : Hoogoven gasproduktie (bijprodukt van staalbereiding). CHEMFAC-HI: De produktie van chemisch restgas e.a. bijprodukten uit het verwerken van lichte- en middendestillaten als grondstof in de chemie. Dit is in feite een onderdeel van de chemiesector (zie producers CH en PE), maar i.v.m, het bestaan van onderlinge leveringen afzonderlijk gespecificeerd in het Basismodel. GASIFI-HI : Kolenvergassing voor (zware) industrie° BIOMASS

: Centrale optie voor verwerking van afval, toWo vast af-

val, rioolwater en mest. Dit resulteert in de produktie van stoom voor elektriciteit- en warmte-opwekking en biogas tob.v, energie-opwekking in diverse producers (industrieën).

-41 -

In de producers voeding- en genotmiddelen, landbouw, gezinshuishoudingen, papier en overige industrie wordt overigens ook decentraal energie opgewekt met als input "waste" (biomass).

Aangezien de proceshiërarchie binnen de producers, die de omzetting van energie in de vraagsectoren weergeven~ een grote gelijkenis vertonen, wordt hieronder volstaan met een korte definitie van deze producers en daarna een algemene beschrijving van de energie-omzettingen in deze producerso

GAMS-naam TRANS CS GO AG CM HH

IEE

FO TE PA

CH PE FE IS OM OI

Toelichting!definitie Transportsector, waarin personenvervoer, zwaar transport, binnenvaart, trein en luchtvaart worden onderscheiden. Bouwniöverheid Overheidssector Land- en tuinbouw Dienstensector Gezinshuishoudingen, waarbinnen Ooao technieken als geisers voor tapwater en ketels voor ruimteverwarming worden onderscheiden~ Onderlinge leveringen door industrieën van gas, elektriciteit en atoom. Voeding- en genotmiddelen Textiel Papier en karton Overige chemie Nafta- ofwel petrochemie Kunstmest Ijzer en staal basismetaal) Overige metaal Overige industrie

- 42 -

~ levering energie ~ ~nooppunt (producer)

Figuur 5oio: Modelnetwerk van SELPE, waarbij alle knooppunten (’~producers") weergegeven zijn

- 43 -

Binnen producers (industriesectoren FO~ TE~ PA~ CH~ PE, FE, IS, OM en Of) worden de volgende processen onderscheiden: - Voor de W/K-optie (COGE) worden de technieken zoals tegendrukturbines (BP)~ condensatieturbines (CO), STEG-eenheden (SG)~ gasturbines (GT) en gasmotoren (GE) onderscheiden; - Voor de optie stoomopwekking (HEGE) in deze producers, worden ketels (BO), warmtepompen (HP) en zonnecollectoren onderscheiden; - Proeeswarmte (PROC) kunnen veelal met verschillende brandstoffen worden opgewekto Tenslotte zijn er windturbine-opties aanwezig in de verschillende producers.

Tenslotte een toelichting op de eindvraagcategorieën~ die in het Basismodel worden onderscheiden. De leveringen aan de eindvraagcategorieën door producers zijn de exogene eindvraag waaraan elke oplossing van het LP-model moet voldoen. De eindvraagcategorieën bevinden zich in het modelnetwerk op hetzelfde aggregatieniveau als de producers, maar zijn geen knooppunt waarbinnen energie-conversie plaatsvindt. De eindvraag betreft energie in de termen van elektriciteit, stoom, proceswarmte en grondstoffen (petro-cokes~ stookolie, etc.)° De volgende eindvraagcategorieën worden onderscheiden: FDEXPORT : De uitvoer van energiedragers

FDTRANSP FDCOMMER FDHHOLDS FDBUNKER FDAORICU FDFOODBE FDTEXTIL FDPAPER FDOTHCHE FDPETRO FDFERTIL FDIRONST FDOTHMET FDOTHIND FDCONSTR FDGOVERN

: : : : : :

De De De De De De

vraag naar energie voor transportbehoeften eindvraag in de dienstensector eindvraag in de gezinshuishoudingen eindvraag van bunkers eindvraag van land- en tuinbouw eindvraag van voedings- en genotmiddelen

: De eindvraag van textielindustrie : De eindvraag van de papier- en karton-industrie ~ De eindvraag van de overige chemie : De eindvraag van de petrochemie : De eindvraag van de kunstmestindustrie : De eindvraag van de ijzer- en staalindustrie : De eindvraag van de overige metaalindustrie : De eindvraag van de overige industrie : De eindvraag van de bouwnijverheid : De eindvraag van de overheidssector

In figuur 5oio vindt men een overzicht van alle producers en alle 17 einvraagcategorieën, waarin de totale eindvraag is opgesplitst. Het betreft alle bovengenoemde industrie- en overige vraagsectoren en de bunker- en exportvraag naar energie.

5.4. Gegevenstabellen

In GAMS kunnen drie typen modelgegevens (input-waarden) worden onderscheiden, t.w. parameters, variabelen en scalarso De parameterwaarden zijn in het algemeen waarden van coëfficiënten die behoren bij bepaalde beslissingsvariabelen in het model. Het betreft in de eerste plaats de procesparameters~ die te vinden zijn in de "IN-OUT" tabel van dit Basismodel en voorts kosten- en rendementscoëfficiënten op energieleveringen naar~ tussen en van producerso Van deze laatste groep parameters zijn de waarden te vinden in de eerder in hoofdstuk 4 besproken tabellen ’~Resource~’~ "Intermed" en "Delivery", die de relaties naar, tussen en van producers beschrijven. De laatste drie tabellen zijn reeds besproken, daarom zal hieronder alleen tabel "IN-OUT" worden toegelicht.

In de zgn. "IN-OUT" tabel vindt de karakterisering van de specifieke technieken op procesniveau plaats. Alle parameters van een proces worden hier een waarde toegekend. Het betreft, de volgende parameters; type input en output (energiedrager), emissies, efficiency, beschikbaarheidsfactor~ omrekeningsfactor (verbindt de dimensie van de capaciteit bijv. MWe en produktie in PJ/jr), annuïteiten-factor~ specifieke investeringskosten, overige vaste en variabele kosten. De gegevens in de tabel "IN-OUT" van het Basismodel zijn gebaseerd op gegevens uit een data base opgesteld tijdens een scenario-studie voor VROM [2] en voor EZ/DGE (het RS’84 scenario) [17]. Uit deze tabel (in feite een data base voor technologieën) worden de inputwaarden gelezen, die nodig zijn voor de modelvorming in GAMS.

- 45 -

Met het toekennen van bepaalde waarden aan variabelen kan indien dig~ vooraf een boven- en!of ondergrens of een vaste waarde worden opgelegd aan de exogene en beslissings(endogene) variabelen t.b.Vo een modelberekeningo Het betreft bijv. het toekennen van bepaalde waarden voor de aanwezige produ~tiecapac~teit en/of beschikbaarheid van energiedragers.

Het opleggen van waarden aan de variabelen van het model is verdeeid over een aantal tabellen~ toWo "Proceschar", "Unitchar~~~ ~’Plantbound", ~’Resource’~~ ’~INTERMED~~ en "DELIVERY". In tegenstelling met de eerdergenoemde tabel "IN-OUT" bevatten deze gegevenstabellen de meer scenario-gerelateerde gegevens. De karakterisering van processen in de tabel "IN-OUT" heeft nlo een meer permanent karakter per zichtjaar en/of planperiode en!of studie.

De drie laatstgenoemde tabellen zijn reeds eerder besproken° Het gaat hierbij om de toekenning van waarden aan variabelen, die energiestromen naar, tussen en van produeers betreffen° Meer in het bijzonder worden in de tabel "Delivery" de waarden van de (exogene) eindvraagvariabelen vastgelegd en in de twee overige tabellen worden de waarden van de (endogene) beslissingsvariabelen gedef~nieerd. In de tabel "Proceschar"~ ~’Un~tchar" en "Plantbound" kunnen waarden worden opgelegd aan de output en capaciteit van processen op het aggregatieniveau van "Processes", "Units" en "Plants~’o Hieronder worden de drie laatstgenoemde tabellen nader toegelicht. - "Proceschar" In de tabel "proceschar" kunnen voor alle processen boven en/of ondergrenzen op produktiecapaciteiten (LOWER en UPPER) en/of op produktieniveaus (outputs) van processen (PLLOWER en PLUPPER) worden geplaatst° De capaciteiten hebben de dimensie MW(e) of PJ/jr en het produktieniveaus (outputs) bezitten de dimensie PJ/jr.

- 46 -

- "Unitohar" Tabel "Unitchar" bevat evenals de tabel "Proceschar" waarden voor de boven- en ondergrenzen van produktiecapaciteiten en/of produktieniveaus~ maar op een meer geaggregeerd procesniveau. De waarden zijn gedefinieerd als een sommatie van de procesgrenzen, voorzover deze processen deel uitmaken van de betreffende "unit"~ zie ook vergelijking (6b) in paragraaf 5.2. - ,,Plantbound,~ Tabel "Plantbound’~ bevat dezelfde zezevens als de tabel "Unitehar"~ maar dan op een meer geaggregeerd niveau° De waarden zijn gedefinieerd als een sommatie van de unitgrenzen~ voorzover de units deel uitmaken van de betreffende "plant".

Voor de volledigheid moeten nog twee tabellen genoemd worden, waarin de parameterwaarden van enige specifieke vergelijkingen kunnen worden bepaald° Het gaat om een tabel "RCAPFAC" met de zgn. reserve capaciteitsfactoren (zie vergelijking (7) in paragraaf 5°2°) van alle elektriciteitsproducerende processen, die in het Basismodel aanwezig zijn. Voorts zijn in de tabel "RESTRIDAT" coëfficiënten van een paar modelvergelijkingen, t.wo de restricties op cokesgas- en hoogovengasinzet (vergelijkingen GASRESTRo I en 2) en in de elektriciteitsopwekking voor de gewenste piekelektriciteit (vergelijkingen ELEKRESTR. I en 2) opgenomen°

5°5° Overige modelonderdelen

Checks op modeldata In het Basismodel zijn een aantal checks op de eerder genoemde gegevenstabellen gedeclareerdo De eerste groep checks betreft: de som van de inputs van een proces moet gelijk zijn aan 100% en de efficiencies van processen mogen niet groter zijn dan I. De tweede groep checks betreft de eis, dat de distribut~everllezen (leveringen tussen produeers) tussen 0 en I moeten liggen. De derde groep checks betreft een controle op de sommaties van capaciteiten, zodat bijv. voorkomen wordt dat de som van de deelcapaciteiten groter is dan de "overal!" capaciteit op een meer geaggregeerd niveau van de processeno Deze

laatste check is van belang i.v.m, de consistentie in de hiërarchie van processeno

Tenslotte moet een belangrijke check genoemd worden~ die er voor zorgt dat alle energlestromen die naar~ tussen en vanaf de producers stromen (gedefinieerd in tabellen "RESOURCE"~ "INTERMED~’ en "DELIVERY~’) ook voorkomen in de proceskarakteristieken van de processen van deze producers~ die in de gegevenstabel "INOUT" zijn gespecificeerd.

Terzijde moet worden opgemerkt, dat het inbouwen van checks in feite het incorporeren van de kennis van de modelbouwer in het modelprogramma behelsto Het tijdig, d.w.z, voor de executie van de oplossingsalgorithme kunnen detecteren van fouten in de aan te leveren invoergegevens, blijkt van groot belang omdat het veel tijdsbesparing bij het prepareren van nieuwe modelversies oplevert.

Solv-statement Door het solve-statement wordt het betreffende oplossingsalgorithme aangeroepen en start de executie van het model. ~eportlng De standaard output is een overzicht van berekeningsresultaten in GAMS die niet overzichtelijk ~s. Door een aantal reporting statements wordt hierult zelf ontworpen oploss~ngstabellen gegenereerd. Deze ~~report-generation" kan automatisch of op afzonderlijke aanroep van de workfile plaatsvinden en wel na het ~n GAMS lezen van de zgn° standaard oplossing (weggeschreven op de workfile). Voor het Basismodel is een tabel gecreëerd~ waarin de waarden van de variabelen en bijbehorende grenzen per plant~~ unit~ en procesniveau worden weergegeven. De kosten van ~e energieproduktie verschillen per proces. Veranderingen ~n het aandeel van de verschillende energieprocessen in de totale produktie van een bepaalde energiedrager kunnen dus leiden tot een veranderlngen in de gemiddelde prijs, d~e de verbruiker moet be-

talen voor de betreffende energiedragero Door middel van enige reporting statements (rekenregels) worden uit de gegeven standaard-oplossing de gemiddelde marktprijzen per producer berekendo Woor een meer uitgebreide toelichting raadplege men de literatuur hierover [18]. De definitieve programmering van de reporting zal echter afhangen van de specifieke behoefte van de opdrachtgever en aard van de studie~ zodat hieraan in het kader van het opstellen van het Basismodel verder geen aandacht is geschonkeno

5.6. Modeldelen

Het is nuttig een totaal overzicht te geven van alle in GAMS geprogrammeerde onderdelen van het model° Hoewel de programmering in GAMS een groot aantal regels kent bestaat er een relatief grote vrijheid in de wijze waarop het model kan worden opgezeto Gegeven de probleemstelling, het modeltype~ de beschikbaarheid van gegevens en de wijze waarop het model gebruikt wordt is het Basismodel geprogrammeerd in een aantal secties. Deze secties kunnen bijvoorbeeld overeenkomen met een bepaalde opsplitsing van het model~ zoals aangegeven in figuur 2 van Appendix II. De secties bevatten globaal de volgende onderdelen van het model:

GAMS-Naam

Toelichting/inhoud

Sectie I: SETS

Bevat een beschrijving/vastlegging van de structuur, d.m.v, een declaratie van alle in het model aanwezige structuurelementen en hun onderlinge relaties in zgn. masterlisten (zie ook hoofdstuk 4)°

Sectie 2: CHECKS

Bevat checks, d.w.z, statements~ die de in sectie I vastgelegde modelstructuur controleren op omissies. Deze sectie is bij het gebruik van het hulpprogramma "CONVERS" niet nodig (hierop wordt in hoofdstuk 6 verder ingegaan).

Sectie 3: TABLES

Bevat alle data tabellen en de gegevens relaties en de declaratie van relaties tussen de mode~elementen~ WoOo tussen producers (zie hoofdstuk 4), die eerder in sectie I zijn gedefinieerd.

Sectie 4: MODEL

Bevat alle algebraïsche modelvergelijkingen.

Sectie 5: CHECKS

Bevat een aanta! checks om de in sectie 3 ~eschreven data en relaties te cnntrolereno

Sectie 6: SOLVE

Bevat het solve-statement, waardoor begonnen wordt met de executie van het model door het oplossingsalgorithme.

Sectie 7: REPORT

Bevat de programmering van de report-tabellen met overzichten van berekende resultaten afgeleid uit de standaard oplossing~ zoals opgeslagen in GAMS. Deze tabellen worden meestal door de zebruiker van het model bepaald n.a.v, de vraagstelling.

6. HULPPROGRAMMA’S

Voor het werken met het model SELPE kunnen niet alle functies in GAMS worden geprogrammeerdo Daarom zijn voor specifieke doeleinden enige hulpprogramma’s ontwikkeld, die hieronder worden toegelichto Het betreft een programma in GAMS~ genaamd MOLP en voorts het stuurkaartenprogramma GPS en de hulpprogramma’s CONVERS en TEN, die niet in GAMS zijn geschreven.

Het werken met de niet in GAMS geschreven hulpprogramma~s vereist overigens wel het gebruik van de "utility" programma’s van GAMS als een interface tussen de wel en niet in GAMS geschreven programma’s. Een koppeling bet~’eft meestal het overbrengen van modelgegevens.

6.1. Multi-objective programma MOLP

Allereerst moet het in GAMS geschreven hulpprogramma "Multi-Objective Linear Program" (MOLP) genoemd worden [19]. Het programma beschrijft een afwegingsmechanisme waarmee de uitkomsten van meerdere doelfuncties met elkaar vergeleken kunnen worden. In SELPE zijn een aantal doelfuncties gespecificeerd~ zoals minimalisatie van kosten~ SO2- en NO -emissies en olie-invoero MOLP bevat meerdere methoden van de mulx ti-objectieve analyse om de doelfuncties tegen elkaar af te wegen. Het gebruik van MOLP is als volgt samen te vatten: I. Men kan in MOLP alle SELPE-voorwaarden (het LP-model) invoeren; 2. Men kan de preferenties van een beslisser invoeren met als neven keuzemogelijkheid het berekenen van de optima van de verschillende doelfuncties; 3o MOLP kan aan de computer gegevens ter verwerking aanbieden en daarna de uitvoer hiervan laten afdrukken.

De invoer van MOLP bestaat uit: I. Het stelsel vergelijkingen van SELPE;

2. Gebruikersinformatie over~ - Doelfuncties De gebrui~er moet aangeven welke doelfuncties de beslisser in beschouwing wil nemen~ welke boven- en ondergrenzen er op deze doelfuncties moeten staan en welke doelfunctie prioriteit heeft in de situatie dat er alternatieve optima bestaan bij optimal~satie naar een bepaalde doelfunctie~ - Multi-objectieve methode(s) waarop MOLP moet aansluiten.

De uitvoer bestaat uit: I. Uitgebreide informatie over de oplossing° Deze kan optimaal~ infeasible of unbounded zijn; 2o Informatie voor de interactieve multi-objective metheden waarop de uitvoer van MOLP betrekking heeft betreft: - de pay-off matrix - de ideale vector - de nadir vector - een efficiënte oplossing - de ratio

Voor een meer uitgebreide toelichting op het gebruik van de multiobjective methoden voor SELPE wordt verwezen naar publikaties hierover

E20,21]o

6.2. Stuurkaartenprogramma~s

Procedure tob.V, het maken van stuurkaartenprogramma’s voor GAMS is als volgt. Voor het compileren en executeren van GAMS-modellen zijn stuurkaartenprogramma’s nodig. Voor iedere bewerking (executie, initiële compilatie, voortgaande compilatie) moet het GAMS-pakket anders aangestuurd worden en zoh dus een ander stuurkaartenprogramma vereist zijn° Om dit te vermijden is er een CCL~programma (Cyber Control Language) geschreven, genaamd GPS, dat m.b.v, een aantal gegevens "automatisch" een stuurkaartenprogramma samenstelt voor de desbetreffende bewerking.

Ook is de mogelijkheid ingebouwd om tegelijk met het cataloggen van een nieuw gevormde workfile de vroegere/laagste cycle hiervan te purgen. Voor een uitgebreidere toelichting raadplege men hoofdstuk 4 van appendix Io

6°3° CONVERS-programma Een programma, genaamd "CONVERS" kan vanuit de procesboom in sectie (zie o.a. paragraaf 4o2o), waarin een bepaalde proceshiërarchie voor de producers in het Basismodel is gedefinieerd, automatisch de bijbehorende relaties tussen de proceslevels (in masterlisten van sectie I) deelarereno Dit programma biedt verschillende voordeleno Allereerst worden fouten bij de opstelling van de masterlisten vermeden en voorts kunnen zodoende snel veranderingen in de proceshiërarchie worden aangebracht.

6.4. TEN-programma Gedurende de uitvoering van berekeningen met het energie model SELPE is meerdere malen ervaren dat een grafische weergave van de LP-oplossing in de vorm van een netwerk een belangrijk hulpmiddel zou kunnen zijn voor een betere presentatie van de resultaten aan de opdrachtgevero Het modelleren van SELPE in GAMS maakt e.e.a, zelfs gewenst, omdat het energiestromen-netwerk nu niet meer zo duidelijk zichtbaar is als bij het model in het oorspronkelijke software-systeemo De netwerk-weergave van de energievoorziening vindt in GAMS nlo op een meer impliciete (via tabellen en declaraties) wijze plaats, zie hoofdstuk 4. Voor verslaglegging en documentatie van het model en de resultaten is het netwerk echter een belangrijk hulpmiddel.

Het in Fortran geprogrammeerde programmasysteem TEN kan op semi-automatische wijze uit een oplossing van het SELPE/G~MS-systeem een energie-netwerk genereren. Dit netwerk moet resultaten produceren voor de directe gebruiker via een grafische terminal en voor een opdrachtgever via een plotter° Het programma voldoet voorts aan de volgende eisen:

ao De programmatuur is compatible met het SELPE-model in GAMSo Veranderingen die in het model worden aangebracht kunnen eenduidíg doorwerken in de programma’s die het netwerk genereren. b. Gebruikers kunnen op eenvoudige wijze de programmatuur hanteren via een "menu-driven" dialoog° Co De te produceren grafisehe weergave van de modelnetwerken kan zowel op een grafische terminal als via een plotter plaatsvinden.

Voor een meer uitgebreide toelichting van dit tekenprogramma wordt verwezen naar Appendix IIo

- 54 -

7o CONCLUSIES

In de vorige hoofdstukken is een korte toelichting gegeven op het Basismodel SELPE~ zoals dit is geprogrammeerd in de modelleertaal GAMS. Hieronder volgt een samenvatting van de belangrijkste resultaten van de programmering van SELPE in het software-systeem GAMSo De volgende opmerkingen lijken gerechtvaardigd: - Het model SELPE in GAMS geeft een zeer gedetailleerde besehrijving van de energievoorziening. Voorts sluit de vraagzijde goed aan op het CPB-energiemodel CENECA, waardoor snel de door het CPB geleverde invoergegevens in SELPE gespecificeerd kunnen worden° De emissies kunnen nu ook in voldoende mate in detail berekend worden~ - De aanwezigheid van "checks~~ in GAMS zorgt voor een ~~foutloze’~ modelspecificatie toboVo het rekenen met SELPEo Het relatief grote model (ca. 2000 vergelijkingen en 2230 variabelen) kan hierdoor afhankelijk van de vraagstelling eenvoudig en snel gewijzigd worden~ bijvo door toevoegen en/of verwijderen van processen~ producers, invoeropties~ data~ etCo: - Voor het aanbrengen van kleine veranderingen in de data, bijv. voor het doorrekenen van varianten, behoeft niet opnieuw het bestaande model te worden gecreëerdo Met behulp van de ~~eontinued eompilation~~ optie kan snel de nieuwe informatie gecompileerd en geëxecuteerd worden (compileren en executeren in GAMS is uitsluitend voor de aanvullende data nodig), waardoor veel rekentijd en -kosten vermeden worden. - Het is mogelijk om voor een studie een specifieke ~~reporting" van de oplossingsresultaten te genereren. De reporting in GAMS is echter minder geschikt om direct in rapporten te verwerkeno

Bovengenoemde opmerkingen tonen aan dat de gewenste verbeteringen mob.t, de modelsoftware grotendeels zijn geëffectueerd. Op een paar punten dient men echter acht te slaan. Het model is zeer omvangrijk, waardoor steeds zwaardere eisen worden gesteld aan het verwerken en aanbrengen van invoer- en uitvoergegevens voor een modelberekeningo Hieraan zal dan ook in de toekomst extra aandacht moeten worden geschonken. Met name kan hierbij gedacht worden aan het inschakelen van

de micro-computer, die veelal over faciliteiten beschikt specifiek gericht op de verwerking van omvangr~jke gegevensbestandeno

8o LITERATUUR

[I] Boonekamp, PoGoMo; NoJo Koenders en F. van Oostvoorn De energievoorziening in de vier MDE-scenario’s gebaseerd op berekeningen met het energiemodel SELPE ESC-’23~ Petten, juli 1983

[2] Oostvoorn, F. van en W.Go van Arkel Optimale strategieën voor de bestrijding van zure tegen veroorzakende SO~- en NO -emissies gebaseerd op berekeningen met X

SELPE ESC-30~ Petten~ oktober 1984

[3] Marcuse, W. et.al. A dynamic time dependent model for the analysis of alternative energy policieso Operational Research ~75~ edo KoBo Haley~ 1976~ Amsterdam, North Holland Publishing Company

[4] Fishbone, L.G. et.al. Users guide for MARKAL (BNL/KFA version 2o0)~ a multi-period linear programming model for energy system analyses BNL-51701, 1983~ USA and W-Germany

[5] Voort9 E. van de et.al. Energy supply modelling package EFOH-12C Mark I, Mathematieal description Cabay~ België, 1984

E6] Schrattenholzer~ Lo The energy supply model MESSAGE, RR-81-31 IIASA~ Laxenburg, Austria

- 57 -

[7] Boonekamp, P.G.M. Beechrijving van SELPE~ ee~ model van de Nederlandse energievoorziening ESC-17, Petten~ april 1982

[8] Arkel, W.G. van en Fo van Oostvoorn Ontwikkeling van een milieusector in het energiemodel SELPE: modeldefinitie, enige proefberekeningen van emissies en een overzicht van bestrijdingstechnie~en. Project afges!oten oktober 1983 ESC-WR-84-14, Petten, augustus 1984

[9] Bisschop~ J. and A. Meeraus Selected aspects of a general algebraic modelling language Lecture notes in control and information sciences 23, New York~ Springer-Verlag 1980~ pp. 223-233

[10] Bisschop~ J. and A. Meeraus On the development of a general algebraic modelling system in a strategic planning environment Mathematical Programming Study 20 (1982) 1-29, North Holland Publishing

[11] Centraal Planbureau CENECA~ een model voor het energieverbruik Monografie nr. 27~ Den Haag, 1985

[12] Boonekamp~ P.G.M. Uitbreiding en herspecificatie van het energiemodel SELPE toboVo de berekeningen voor het EZ-Referentiescenario 1984 ESC-WR-85-01, Petten~ januari 1985

[13] Kendrick, DoAo~ Ao Meeraus and Jung Sun Suh Oil refinery modelling with the GAMS language Discussion Paper 80-3, Center for Economie Research The University of Texas~ 1980, Austin, Texas~ 78712 [14] World Bank General Algebraic Modelling System (GAMS): Preliminary User’s Guie~ Version Io0o Development Research Center, The World Bank~ 1818 H Street NoWo Washington D.Co 20433, February 1982

[15] Kendrick~ DoAo snd Ao Meeraus GAMS, An introduction (draft 1984) The World Bank, Washington D.C. ~orthcoming

[16] Fourer, Ro "Modelling language versus matrix generators for linear programming" In ACM transactions on mathematical software, VOlo 9, no. 2, June 1983~ po 143-183

[17] Boone~amp, P.G.M. en J.J.Co Bruggink Het EZ-referent~escenario 1984, enige bere~eningen met het energiemodel SELPE ESC-29~ 1984

[18] KoK, M. en Co Roos Fair prices exist always in commodity networks Delft Progress Report, 9, 1984

[19] Hengst-Van der Hoek~ Ho den "Multi-objective Linear Program" (MOLP) t.b.v. SELPE ESC-WR-85-22, Petten, september 1985

- 59 -

[20] Kok~ Mo Optimaliseren met meervoudige doelstellingen ~n het energiemodel SELPE ESC-WR-85-19, Petten, juli 1985

[21] Kok~ Mo Conflict analysis via Multiple Object~ve Programming, with experiences in Energy Planning Proefschrift, TH Delft, 10 juni 1986

[22] Roos Lindgreen, E. TEN-USER MANUAL ENR-verslag -208~ juli 1985 [23] Lange, A.VoMo de Beschrijving van interfaces tussen TEN-systeem en GAMS Verschijnt binnenkort

fvol I .tap

INHOUD

BLZ ¯

io SYSTEEMBESCHRIJVING

1.5

2- GEBRUIKERSOPTIES

1.6

2.1o Initiële compilatie

1.7

2°2° Executie

Iol0

2.3. Voortgaande compilatie

I .16

3. OPSPLITSEN MODEL IN VERSCHILLENDE DELEN

1.24

AANSTURINGSPROCEDURE VAN HET GAMS-PAKKET

I .30

4.1o Inleiding

1030

4.2. File-parameters

I .31

4.3. Voorbeelden

I ,32

4°4. Executie- en GAMS-parameters

1.33

4°5. Stuurprogramma bij het opdelen van een model

1.34

BIJLAGE I: Toelichting schema-techniek

1,37

i. SYSTEEMBESCHRIJVING

Het GAMS-systeem bestaat uit twee delen, waardoor het model afzonderlijk gecompileerd en ge~xecuteerd kan worden (zie ook figuur 3.1o): ao GAMSC: het eompilatie-subsysteem b. GAMSE: het executie-subsysteem

Het compilatie-suhsysteem bestaat uit het compileerprogramma, terwijl het executie-subsysteem uit een aantal computerprogramma’s en stuurprocedures bestaat. Hieronder vallen ook de interfaces die de GAMSinput naar verschillende oplossingssystemen, zoals APEX~ MINOS en CONOPT, kunnen vertaleno

In een geïntegreerd systeem zouden alle verwerkingen als één geheel op elkaar moeten aansluiten. Het aantal files is dan geminimaliseerd tot twee, nlo de modelinputfile en de oplossingsoutputo Bij het GAMSsysteem wordt echter met 3 files gewerkt. De derde file biedt de mogelijkheid kleine veranderingen in het model aan te brengen en nogmaals het oplossingsalgoritme te executeren zonder het gehele model opnieuw te compileren ("continued eompilation" optie)°

Kortom het GAMS-systeem bevat dus drie files,

t.w=:

ao De modelfile

Hierin is het model overzichteliJk beschreveno Hierin zijn alle structurele informatie en alle overige (data) gegevens opgenomen. De modeloutputfile Hierop wordt de (N)LP-oplossing volledig geprint op een overzichtelijke manier. Ook de door de gebruiker gewenste (tabellen-) outputs worden hierop weggesehreveno De wo~kfileo Hierln wordt alle informatie in gecompileerde vorm opgeslagen. Voorts zijn alle executie-outputs hierin opgeslagen~ bijv. de oplossing van het aangeroepen oplosslngsalgorítmeo Bij het opnieuw aanroepen van een oplossings-algoritme wordt allereerst opnieuw een basis-oplossing gecreëert door GAM$, díe vervolgens wordt aangeboden aan het oplossingsalgoritmeo Hierdoor worden veel tijd en eomputerkosten vermeden~

2. GEBRUIKERSOPTIES

De gebruiksmogelijkheden van het GAMS-pakket vallen (technisch gezien) in drie delen uiteen: i. Initiële compilatie 2. Executie van het model 3. Voortgaande compilatie ~"continued compilation")

Bij de compilatie van een in een algemene programmeertaal (zoals FORTRAN,COBOL,PASCAL) geschreven programma worden de te verwerken gegevens niet meegecompileerd, maar het gecompileerde programma haalt tijdens de executie de gegevens uit een file of uit een database. Het voordeel van afzonderlijke gegevens is dat ze gemakkelijk veranderd en verwerkt kunnen worden door andere programma’s/pakketteno

Bij het programmapakket GAMS bestaat een programma niet alleen uit statements maar ook uit de te verwerken gegevens. Als nu enkele gegevens veranderd moeten worden zou het totale model weer opnieuw gecompileerd moeten worden, wat het pakket voor de gebruiker uiterst star zou maken. GAMS biedt echter de mogelijkheid om op basis van een reeds gecompileerd programma een nieuw programma(-onderdeel) te compileren. Dit programma(-onderdeel) bevat dan een tabel met nieuwe gegevens, statements die reeds bestaande gegevens overschrijven of nieuwe gegevens crëeren (bijv. outputtabellen ten behoeve van de reporting).

Aangezien bij de algemene programmeertalen de gegevens niet tegelijkertijd worden gecompileerd maar afzonderlijk worden aangeleverd bieden deze talen deze mogelijkheid van vernieuwde of anders gezegd voortgaande compilatie niet.

De drie eerdergenoemde gebruiksmogelijkheden worden hierna afzonderlijk uitgebreid toegelichto

2oio Initiële Compilatie

Bij iedere initiële compilatie wordt er een workfile gecreëerd. Deze workfile bevat alle informatie (alle gegevens en statements) uit het programma (vaak een algebraisch model) in gecompileerde vorm, zie eehema i~

Bij een compilatie wordt het model onderzocht op syntax-fouteno Indien zo’n fout gedetecteerd is wordt de fout geanalyseerd en verbeterd teneinde het aantal mogelijke vervolgfouten zo klein mogelijk te houden.

De foutmeldingen worden zowel in de compilatie-listing als in de compilatie-logfile gepriat. De logfile is een verslag van de compilatie waarop alle fouten nog eens uitgeprint staan met een omschrijving, alsmede het totaal aantal fouteno

Afhandeling van fo~te~ hij de co~pilatie of executie Indien er een fout optreedt bij de compilatie of bij de executie van het programma, wordt het GAMS-programma niet correct verlateno Hierdoor worden niet alle gegevens uit het werkgeheugen teruggeschreven naar de workfile, zodat de desbetreffende workfile geen waarde heeft°

PI Compilatie

Schema io: Ini~iële compilatie-proces

Opm~: Voor een verklaring van de schematechniek zie bijlage.

Verkl~~ing Schema 1

Inp~tfiles

] I 1

: Het compiler subsysteem

~ I 2

: Tekstfile waarop het gehele model staat

Processen

I PI

~ Compilatie proces

Outputfiles

O1-i

: Workfile waarop in gecompileerde vorm alle informatie staat

O1-2

: Compílatie-listing met eventuele foutmeldingen

01-3

: Logfile ~aarop mogelijke foutmeldingen worden weggeschreven met een verklaring

- Ioi0 -

2.2° Executie

In tegenstelling tot de algemene programmeertalen kan de gevormde workfile niet zelfstandig ge~xecuteerd worden, maar moet dit gebeuren met behulp van een executie-systeem welke bij het GAMS-pakket behoort. Bij de executie worden alle nog niet geëxe~uteerde statements uitgevoerd° Voorbeelden van deze statements zijn bijv.: - Toekenningsstatements: - Printopdracht

a(1)=b(1) :

display tabel

Een bijzonder statement is het SOLVE-statement. Deze houdt in dat een oplossingsalgoritme wordt aangeroepen met de bijbehorende GAMS-interfaceo Deze interface vormt de data in de workfile om tot een inputfile voor het betreffende oplossings-algoritme en genereert daarna de stuurinformatie waarna het oplossings-algoritme wordt opgestart.

Bij beëindiging van het oplossiags-pakket wordt de outputfile waarop de (optimale) oplossing is weergegeven door het GAMS-executiesysteem ingelezen en in de workfile opgeslagen. Hiern~ worden deze oplossingsgegevens volgens een GAMS-standaardformaat uitgeprinto Deze data kunnen later alsnog via een report-writer opnieuw gerangschikt worden en bijvoorbeeld gesommeerd worden afgedrukt.

Ook bij de executie wordt een logfile gevormd. Deze bevat dan een verslag van het tijdsverloop van de executie. In schema 2 wordt dit executie-proces schematisch weergegeveno In schema 3 zijn de compilatie- en executiestap in i proces geintegreerdo

De wisselwerking alsmede de intermediaire files tussen het GAMSpakket en het oplossingspakket zijn voor de gebruiker transparant, dow.Zo het geheel is een "blackbox". Het is niet noodzakelijk dat de gebruiker over gedetailleerde informatie, zoals bijv. inputformaten van het oplossings-pakket, dient te beschikken. Deze "transparency" betekent echter niet dat de gebruiker niet aan de files zou kunnen komen° Dit is mogelijk~ maar heeft weinig of geen nut omdat de opbouw van de vergelijkingen niet rechtstreeks terug te leiden is tot de GAMS-vergelijkingeno

- Ioli -

Gebruik database faniliteiten. De GAMS-database is niet specifiek gericht op niet-numerieke data. Dit betekent dat in een data-matrix alleen numerieke informatie (=informatie in cijfers) kan worden opgeslageno Alphanumerieke informatie (= ínformatie in alphabetische karakters en/of in cijfers) kan niet in een tabel worden opgenomen (zie tabel A,)o De alphanumerieke informatie kan alleen als kolomnaam of rijnaam in de database worden opgenomen, Een manier om dit te omzeilen is door de alphanumerieke data in een aparte tabel/domein te plaatsen en een verwijzing in de tabel op te nemen (zie tabel Bo)o

TYPE I=GASTURBINE 2=WKK

Pronesl

TYPE

gasturbine

Proeesl

REFTYPE

i

INVESTCOST

8.0

INVESTCOST

8.0

VARCOST

4.9

VARCOST

4°9

* Energie in GAS * Energie uit ELEKTRICITEIT WARMTE

Tabel A.

* Energie in

(%) i00.0 (%)

GAS * Energie uit

95.0 5.0

(%)

ELEKTRICITEIT WARMTE

Tabel B.

i00.0 (%) 95°0 5°0

- 1.13 -

Verklaring: Schema 2

Inputfiles Het executie subsysteem Oplossingsalgoritme (bijv. APEX-III~ CONOPT) Workfile waarin het gecompileerde model is opgeslagen (idem aan file 01-i in Schema i)

~ PI

: Executie proces

Outputfiles

01-i

: Workfile waarin alle data-informatie is opgeslagen, inclo een (N)LP-oplossing

01-2

: Executie-verslag (bijvo een (N)LP-oplossing) afgedrukt in standaard GAMS-formaat

01-3

: Logfile waarop het executie-tijdsverloop wordt weggeschreven

1o15 -

V~rklari~g: Schema 3

Inputfiles

I I

: Het executie-subsysteem

1 2

: Oplossingsalgorítme (bijv. APEX-III, CONOPT)

1 3

: Het compilatfe-subsysteem

I 4

~ Tekstfile waarop het gehele model staat

Compilatie proces

I Pl

Executie proces

Outp~tfiles

01-i : Workfile waarop in gecompileerde vorm alle informatie staat 01-2 : Compilatie-listing met eventuele foutmeld~ngen 01-3 en 02-3

: Compilatie- en executie-logfile

02-1

: Workfile waarin alle data-informatie is opgeslagen incl. een (N)LP-oplossing

02-2

~ Executie-verslag

- 1.16 -

2°3. Voortgaande Compilatie

Bij de inleiding is reeds gezegd dat de data in een workfile veranderd kunnen worden en dat nieuwe data en statements toegevoegd kunnen worden aan de bestaande workfileo De GAMS-compiler compileert de nieuwe inputfile en voegt de gecompileerde informatie toe aan de aangeboden workfile~ zie schema 4.

In deze inputfile kunnen toekenningsstatements staan die de oude data overschrijven waarna d.moVo het SOLVE-statement een oplossings algoritme opnieuw wordt aangeroepeno Ook kunnen nieuwe algebraische vergelijkingen zijn gedefinieerd, of een compleet model-onderdeel zijn opgenomen bijvo datachncks of report-writers. In figuur 1 is aangegeven welke delen van een model bijvo met de optie "continued compil~tion" aan een Basismodel gekoppeld zouden kunnen worden°

Hierbij moet men erop toezien, dat in de betref~en~e inputfile een variabele niet opnieuw gedeclareerd wordt° Dit veroorzaakt nlo compilatie-fouten met als reeds eerder genoemd gevolg, dat niet alle informatie in de workfile staat. Kortom een tabel-declaratie mag maar één keer gemaakt worden, maar de data in de tabel mogen echter steeds opnieuw overschreven worden°

Dit probleem is bij de report-writer van GAMS opgelost door de workfile niet verder te gebruiken° Voor volgende oplossings-runs moet dan de workfile gebruikt worden die eerder als input diende voor de report-writer, zie ook schema 5.

In schema 5 wordt schematisch weergegeven op welke wijze de executie van een model kan verlopen van initi~le compilatie en executie tot en met verschillende aanroepen van een oplossings-algoritme met bijbehorende reportso De report-writer kan men natuurlijk ook gebruiken om alleen van de optimale oplossing een report te produceren°

- 1.17 -

BAS ISMODEL

CHECKS

OVERIG

Fig_uur io: Overzicht van modeldelen, die eventueel aan een Basis~odel kunnen worden gekoppeld

~Terklaring: Schema 4

Inputfiles

I 1

: Tekstfile waarop de data-veranderingen/reportwriter staat

1 2

: Workfile waarin het gecompileerde model is opgeslagen (idem aan file 01-I in Schema i)

I 3

: Het (volledige) GAMS-systeem

I 4

: Oplossingsalgoritme (bijVo APEX-III, CONOPT)

I Pl

Voortgaand compilatie proces

("continued compilation")

Executie proces

Outputfiles

01-I

: Compilatie-verslag van de "inputfile"

01-2

: Workfile waarop in gecompileerde vorm alle informatie staat

02-1

: Workfile waarin alle data-informatie is opgeslagen inclo een nieuwe (N)LP-oplossing

02-2

: Executie-verslag (bijvo een (N)LP-oplossing)

- 1o20 -

Schema 5°: Reporting schema

Om het schema overzichtelijk te houden worden geen logfiles getekend. Deze worden echter wel aangemaakt,

- Io21 -

~erklaring.~ Schema 5

Inputfiles

I 1

Het compilatie-subsysteem

1 2

Tekstfile waarop het report-writer-progra~na staat

1 3

Workfile waarin de oplossingsdata zijn opgeslagen

1 4

Het executie-subsysteem

I Pl

; Voortgaand compilatie- en executie-proces

Outputfiles

01-i : Workfile waarin de report-writer(s) zijn gecompileerd Deze workfile wordt niet meer gebruikt 01-2

: Executie-verslag (report-tabellen)

- 1o22 -

Schema 6.: Volledig overzicht van compilatie t/m reporting Opm.: Om het schema overzichtelijk te houden worden geen logfiles getekendo Deze worden echter wel aangemaakt,

- Io23 -

Verklaming: Schema

Inputfiles

I 1

~ Het (volledige) GAMS-systeem

1 2

: Tekstfile waarop het reportwriter-programma staat

I 3

: Tekstfile waarop de data-veranderingen staan

I 4

: Tekstfile waarop het reportwriter-programma staat

PI

Initieel compilatie proces

P2

Initieel executie proces

P3

Voortgaanà compilatie- en executie-proces (iteratie(n))

P4

Voortgaand compilatie- en executie-proces report-writer (iteratie(n))

Outputfiles

O1-I

: Workfile waarin de report-writer(s) zijn gecompileerd Deze workfile wordt verder niet gebruikt

O2-1

: Workfile waarin alle data-informatie is opgeslagen, inclo een (N)LP-oplossing

O3-1

: Workfile inclo een nieuwe (N)LP-oplossing in iteratieslag(n)

04-1

: Workfile waarin de report-writer is gecompileerd in iteratieslag(n) Deze workfile wordt verder niet gebruikt

01-2

: Initieel compilatie-verslag

02-2

: Initieel executie-verslag (le (N)LP-oplossing), afgedrukt in het standaard GAMS-formaat

03-2

: Verslag van de voortgaande compilatie en executie in iteratieslag(n) ((n-l)e (N)LP-oplossing)

04-2

: Executie-verslag (report-tabellen) van iteratieslag(n)

- 1.24 -

3o OPSPLITSEN MODEL IN VERSCHILLENDE DELEN

Een model wordt meestal niet voor het uitwerken van één scenario gebruikt maar juist voor het opstellen van meerdere verschillende scenario’So In dat geval beschikt men over een aantal files, die voor een groot gedeelte~ bijvo qua modelstructuur hetzelfde zijn°

Het kan dan nuttig zijn om het model op te delen in verschillende modeldelen~ bijv. delen die de structuur beschrijven en delen die de data bevatten, zie voor een voorbeeld hiervan figuur 2.

Het modelstructuur-deel en het modelvergelijkingen-deel blijven onveranderd en hiervan bestaat dan ook in principe één versie. De modeldata zijn in dit voorbeeld gisplitst in twee delen: i. De procesdata 2. De overige data~

Van ieder data-deel kunnen voorts verschillende versies bestaan per scenario.

Met dit opgedeelde model kan nu op twee manieren worden gewerkt en wel door: i~ De modeldelen achter elkaar te compileren en daarna de laatst gevormde workfile door middel van het executiesysteem te executeren. Dit is een omslachtige manier vooral omdat men dan een aantal overbodige intermediaire workfiles creeerto Deze mogelijkheid is daarom uitsluitend aan te bevelen wanneer het model nog niet van fouten vrij is, zie schema 7o

2~ De verschillende modeldelen (files) worden samengevoegd tot een modelfile díe na de compilatie geexecuteerd wordt. De gebruiker krijgt nu maar één compilatie-listing en niet een aantal op zichzelf staande listingen. Vooral als het samenvoegen van de files een "blackbox" is voor de gebruiker is dit een aan te bevelen manier~ zie schema 8.

I

- 1o25

STRUCTUUR

Data-deel i geeft bijv. de pro¢esgegevens

DATA 1 ]

DATA 2

Data-deel 2 geeft bijv. de overige data weer

~QUATION

Het vergelijkingem-deel beschrijft het model in algebraische termen

Figuur 2__.: Voorbeeld van opsplitsing van model in delen

- 1o26 -

Modeldeel n

P4 Executie

Schema 7.: Gebruiksprocedure (i), indien het model opgesplitst is in modeldelen Opmo: Om het schema overzichtelijk te houden worden geen logfiles getekend. Deze worden echter wel aangemaakt.

- 1o27 -

Verklaring: Schema 7

Inputfiles

I i

Het complete GAMS-systeem

1 2

Het oplossings-algoritme

1 3

Tekstfíle met Modeldeel 1

1 4

Tekstfile met Modeldeel 2

1 5

Tekstfile met Modeldeel n

Fl

: Compilatie modeldeel 1

P2

: Compilatie modeldeel 2

P3

: Compilatie modeldeel n

P4

: Executie proces

Outputfiles

01-I

: Workfile waarin modeldeel 1 gecompileerd is opgeslagen

O2-1

: Workfile waarín de modeldelen i en 2 zijn opgeslagen

O3-i

~ Workfile waarin de modeldelen i t/m n zijn opgeslagen

01-2 02-2 O3-2

Compilatie-listingen van de gecompileerde modeldelen

04-i

Executie-verslag, inclo een (N)LP-oplossing

04-2

Workfile waarin alle data-informatie ís opgeslagen, in~l. de data van een (N)LP-oplossing

- 1o28 -

03-2

Schema 8.: Gebruiksprocedure (2), indien model is opgesplitst in delen Opmo: Om het schema overzichtelijk te houden worden geen logfiles getekend, Deze worden echter wel aangemaakt°

- 1.29 -

Verklami~: Schema 8 Inputfiles I i

: Het compilatie-subsysteem

1 2

: Het executle-subsysteem en het oplossings-algoritme

I 3

: Tekstfile met Modeldeel 1

I 4

: Tekstfile met Modeldeel 2

I 5

: Tekstfile met Modeldeel n

PI

: Samenvoegen van de modeldelen tot een modelfile

P2

: Compilatie proces

P3

: Executie proces

Outputfile

01-i

: Samengevoegd model

02-1

: Compilatie-listing met eventuele foutmeldingen

02-2

: Workfile waarin het gecompileerde model is opgeslagen (idem file 01-i in Schema i)

O3-1

: Workfile waarin alle data-lnformatie is opgeslagen, inclo de data van een (N)L~-oploesing

03-2

: Executie-verslag, inel. een (N)LP-oplossing

- 1o30

4. AANSTURINGSPROCEDURE VAN HET GA~~S-PAI(KET

4.1. Inleiding

Voor het werken met GAMS zijn een aantal stuurkaartenprogra~na~s nodig. Dit gebeurd in de vorm van een file die men aan het computersysteem aanbiedt en waarop een aantal commando’s staan ter besturing van het computersysteem. Deze commando’s betreffen bijvoorbeeld het ophalen van een file van het achtergrondgeheugen of het aanroepen van een software-pakketo

Aangezien voor iedere gebruiksmogelijkheid van het GAMS-pakket de computer anders aangestuurd moet worden en de gebruiker niet met verschillende stuurfiles moet worden belast, is een programma geschreven dat de stuurfiles per run samenstelto Het programma vormt aan de hand van opgegeven parameters de betreffende stuurfile en biedt deze vervolgens de computer aan ter executie°

De invoergegevens kunnen als volgt worden onderverdeeld in: i. Fileparameters (bijv. een permanent file name) 2° Executieparameters (bijv. beschikbare executietijd) 3° GAMS-parameters (bijvo pagina-lengte)

De algemene aa~roep-syntax is als volgt:

ATTAXEQ,ID=U5BDL,GSP,#FILE-parameters#, [#EXECUTIE-parameters#], [#G~MS-parameters#]o

De FILE-parameters moeten bij elke aanroep worden meegegeven. Deze sturen namelijk de selectie of de aanroep van een initiële, of een voortgaande ("continued") compilatie. In paragraaf 2 worden de para= meters toegelicht. Aan de hand van enige voorbeelden in paragraaf 4.3. wordt getracht de stuurprocedure duidelijk te maken. De EXECUTIE- en GAMS-parameters worden besproken in paragraaf 4.4.. Deze parameters zijn optioneel, omdat deze per default reeds bepaald zijn en een verandering niet voor iedere run nodig iSo Men denke hierbij bijv.

- 1o31 -

aan de executie-errorlimit of de pagina-lengteo In paragraaf 4°5° wordt tenslotte de aanroep van het prograrama beschreven, indien het model is opgedeeld in diverse modeldelen.

4°2. FILE-parametersI)

[#optionmode#],[ [ID=#permid#],~ [PF=#pfnaam#],I [WFI=#wfi-naam#],l [WfO=#wfo-naam#]

#option-mode#

"c"

Catslog de nieuwe workfile (default)

"r"

Report-mode: de nieuw gevormde workfile wordt niet gecatalogged

"p" Purge-mode: de nieuw gevormde workfile wordt gecatalogged en de (eventueel) laagste cycle wordt gepurged

#permid#

= ID waarop de permanent files staan

#pfnaam#

= Permanent-file-naam van het (volledige) model of van de file met veranderingen

#wfi-naam#

= Permanent-file-naam van de inputworkfile

#wfo-naam#

= Permanent-file-naam van de (nieuwe) outputworkfile

l)ao Wanneer bij de aanroep van het stuurprogramma alleen een wfinaam opgegeven wordt dan wordt de wfo-naam gelijk aan de opgegeven wfi-naamo. bo Wanneer bij de aanroep een PF-naam en een WFI-naam worden opgegeven schakelt GAMS automatisch over op vervolgcompilatieo

- 1o32 -

4.3° Voorbeelden

Ao ATTAXEQ,ID=U5BDL,GSP,PF=testI,ID=uStest,WFO=testwfl

Het model "testl" (id=uStest) wordt gecompileerd en geëxecuteerd waarna de workfile gecatalogged wordt op ID=u5teSto

Bo ATT~XEQ,ID=USBDL,GSP,PF=veranderingl,ID=u5test,WFI=testwfl

Continued ~ompilation:de file met de modelveranderingen wordt gecompileerd/geëxecuteerd en daarna wor~t de nieuwe workfile gecatalogged onder dezelfde workfile-naamo

C. ATT~XEQ,ID=U5BDL,GSP,P,PF=verandering2,1D=u5test,WFl=testwfl

Idem als onder B., maar nu wordt de laagste cycle van de nieuwe workfile "gepurged", indien deze bestaat.

Do ATTAXEQ,ID=U5BDL~GSP,PUR,PF=verandering3,1D=u5test,WFI=testwfl WFO=testwf2

Idem als onder C., de nieuwe workfile wordt nu onder een andere naam gecatalogged terwijl een eventnele vorige cycle onder de naam "testwf2" wordt "gepurged"o

E. ATTAXEQ,ID=U5BDL,GSP,R,PF=reportI,ID=u5test,WFI=testwfl

De reportwriter, die op "reportl~’ staat wordt gecompileerd en geë~ecuteerdo De nieuw ontstane workfile wordt niet "geeatelogged"o

- 1o33 -

4.4. Executie- en GAMS-parameters

#executie-parameters# [T=#cp-time#]I, [lO=#io-time#]~~ [CL=#memorylength#] [PR=#day-night#]

#cp-time#

central processor time

(octale waarde)

#io-time#

input/output-time limit

(octale waarde)

#memorylength#

geheugengrootte

(octale waarde)

#batch-priority#

dag- (0), of nachtverwerking (i) (default: dagverwerking)

#GAMSparameters# [LOG=#1og-mode#], [MSG=#msg-mode#], [EL=#erlimit#], [PL=#printlimit#], [PS=#ps-mode#], [DC=#dc-mode#], [R=#ref-mode#].

#1og-mode#

= ON: Compilation/execution logfile printed OFF: Compilation/execution logfile suppressed

#msg-mode#

= ON: GAMSmessage printed OFF: GAMSmessage suppressed

#erlimit#

= Max° number of errors with executing

#printlimit# = Max. number of lines printed

#ps-mode#

= Pagesize (number of printlines on each page)

1o34 -

#dc-mode#

= Dollarcontrolline= mode ON~ Dollarcontrol-lines printed OFF: Dollarcontrol-lines suppressed

#rel-mode#

3o

= Compilation referencemode

Variahle

Varie~ble

listing

~~ref erence

map

map

map

x

x

-

x

x

5. 6.

x

Label xreference

x

4°5° Stuurprogramma bij het opdelen van een model

In hoofdstuk 3 is beschreven dat het model kan worden opgedeeld in een aantal delen° Het samenvoegen van de modeldelen vormt een "blackbox" voor de gebruiker, zodat hij geen bemoeienis heeft met de aaneenschakelingo

Aangezien van ieder modeldeel verschillende versies kunnen bestaan zal in het algemeen een versienummer of iets degelijks opgenomen zijn in de filenaam. Een permanentfile-naam bestaat dus uit een naamgedeelte dat het modeldeel identificeert en een naamgedeelte dat dat de versie aangeefto

Van deze eigensehap wordt gebruik gemaakt om met het stnnrprogramma de diverse delen te laten samenvoegen° Het vaste filenaam-gedeelte wordt opgenomen in de default-sectie van het stuurprogramma en het variante naamdeel moet bij aanroep van het stuurprogramma worden opgegeveno

- 1o35 -

Indien bij de aanroep van het stuurprogramma geen PF-filenaam is opgegeven, wordt de concatenatieprocedure aangeroepen om de verschillende modeldelen samen te voegen tot een modelfile~

De aanroep veranderd als volgt:

De inputparameter [PF=#pfnaam#]

verandert in [Sl="ídentl"]~, [s2="ident2"]~, [s3="ident3"]l~ [s4="ident4"]

ident (n): variant file-naamdeel van modeldeel(n)

Hieronder volgt een voorbeeld van de hierboven beschreven stuurprocedureo Het model is zoals in figuur I in Hoofdstuk 3 is beschreven opgedeeld in de volgende delen: - Structuur - Procesdata - Overige data - Vergelijklngen

De vaste file-naamdelen zijn: i. "SETS" 2o"10" 3o"DT" 4,"EQU" Deze namen zijn in de defaultsectie van de stuurprocedure vastgelegd.I)

I) De procedureheader ziet er dan als volgt uit: .PROC,GSP,0PT=$$,o.etCoo,PARTI=$SETS$,PART2=$10$, PART3=$DT$,PART4=$EQU$,SI=$$,S2=$$~S3=$$,S4=$$.

- I~36 -

De variante filenaamdelen zijn: 2."2000" en "201~’ 3."LAAG" en "HOOG"

Voor~eeld:

a. ATTAX~Q,ID=U5BDL,GSP,ID=u5test,WFO=testwfI,S2=2010, S3=hoog

Bereken het model voor het 2010 HOOG scenario zonder ~ilieuvergelijkingeno

bo ATTAXEQ~ID=U5BDL~GSP~ID=u5test,WFO=test~fI,S2=2000, S3=laag,S4=m

Bereken het model voor het 2000 LAAG scenario met milieuvergelijkingen.

- 1.37 -

BIJLAGE i.

Toelichting schema-techniek

Techniek

De schema-techniek, die gebruikt wordt om de verwerkingsprocedures (processen) te beschrljven~ is afgeleid van de ISAC- ontwikkelingsmethodiek° Deze flowschema’s geven een duidelijk overzicht van de inputs en outputs van de te beschrijven processeno Ieder proces wordt beschreven door alle relaties tussen inputs~ outputs en processtappen schematisch weer te geven. }let proces wordt begrensd door een "box", wat buiten de "box" ligt is de "omgeving", die inputs afgeeft en geproduceerde outputs opaeemto In de "box" worden dan de processtappen getekend met alle verwerkingsrelaties en alle interne- en externe informatie-relaties.

Alle inputs hebben een opeenvolgend nummer (bijv. Ii) evenals de processtappen (bijvo PI)o De procesoutputs krijgen een aanduiding~ die verwijst naar het genere~ende proces met daarachter een vervolgnummer (bijv. 01-I en 01-2).

Symbolen

ao De files, die van boven het proces instromen zijn de inputs. De files die geproduceerd worden verlaten het proces van ondereno

b. Software-pakket bijvo GAMS of een onderdeel hiervan bijv. GAMSEo

1.38 -

Co Tekstfile waarop het model staat of waarop een modeldeel staat°

do Verslag :outputfile die afgedrukt kan worden o

e. Binaire outputfile afkomstig van het software-pakket

f°

Dit is een direct access-file (idem als boven)waarin gelezen en geschreven kan worden° Er wordt bij verwerking geen nieuwe file gevormd, de oude file wordt aangepast° Voor de overzichtelijkheid wordt het voorgesteld alsof er één inputfile en een outputfile bestaat. Om veiligsredenen (zie par 2.1) wordt in werkelijkheid de inputfile eerst gekopieerd en dan pas ter verwerking aangeboden aan het software-pakketo

guide.fvo

-11.1 -

APPENDIX II HET GRAFISCHE TEKENPROGRAMMA TEN

-IIo2-

-11o3-

INHOUD 1o INLEIDING 2o SPECIFICATIES VAN HET NETWERK 3°

HET PROGRAMMA TEN

PAG.

-11o4-

-IIo5-

I. INLEIDING Voor de generatie van een netwerk worden gegevens uit SELPE gehaald. Het Basismodel SELPE bevat een aantal hoofdelementen (zie ook hoofdstuk 4) die als lijsten en tabellen in de output van een GAMS-oplossing voorkomen. De relevante lijsten en tabellen zijn: GAMS-naam Toelichting/definitie

MEPR

Een lijst van energieproducenten gegeven door tekstlabels "prname"

MEDC

Een lijst van vraagcategorieën gegeven door tekstlabels "vrname"

MEC

: Een lijst met energiedragers gegeven door tekstlabels "energytype"

RESOURCE: Een tabel waarin de energiestromen naar producenten zijn beschreven in de vorm "prname" en "energytype" INTERMED: Een tabel waarin de energiestromen tussen producenten zijn beschreven in de vorm "prname"~ "vrname" en "energytype" DELIVERY: Een tabel waarin de energiestromen tussen producenten en vraagcategorieën zijn beschreven in de vorm "prname"~ "vrname" en "energytype"

GAMS biedt de mogelijkheid om resultaten van een LP-run vast te leggen in een workfile waaruit m.b.v. "utilities" (zie ook hoofdstuk 6) bepaalde gegevens kunnen worden weggeschreven naar een file buiten GAMS. In figuur I. is een voorbeeld weergegeven van een simpel "energiesysteem" met twee producers PRODA en PRODB, terwijl één vraagcategorie is gespecificeerd VRAAG° Aangegeven zijn de importstromen EDA, EDB en EDD terwijl tussen PRODA en PRODB een intermediaire stroom loopt° Zowel PRODA en PRODB leveren aan de vraagsector, nl. respectievelijk de energievormen EDC en EDBo In totaal zijn hier dus vier energiedragers (energytype) onderscheiden.

2. SPECIFICATIES ~AN HET NETWERK

Naast deze basisonderdelen bevat de tekening informatie~ die nuttig is voor de gebruiker. Het gaat hierbij om de volgende gegevens: - Naam van de producer; - Naam van de vraageatezorie; - Soort energiedrager~ - Hoeveelheid energie die door een stroom wordt gerepresenteerd.

Deze gegevens zijn te leveren vanuit GAMS mob.V, de eerder genoemde "utilities", nl. de zogenaamde GAMS Data Pull Reutines. Afhankelijk van het type apparaat waarop het netwerkfiguur wordt geprojecteerd~ kan via kleur (plotter of kleurenscherm) of lijnsoort (stippellijn e°d.) de diverse energiedragers worden onderscheiden. Bovendien bestaat de mogelijkheid om bepaalde onderdelen weg te laten en tekst toe te voegen ter identificatie van bijvo een deel van het netwerk. De plaats van de onderdelen binnen het netwerk worden als coördinaten ~ngebracht voor het vormen van een standaard netwerk° Dit netwerk kan interactief worden aangepast en zal steeds worden getoetst aan de GAMS-data die worden aangeboden.

Het positioneren van de plaats van de producers in het totale beeld en het bepalen van de onderlinge verbindingen tussen de producers (knooppunten van het netwerk) blijft echter "handwerk", dat slechts tegen hoge kosten ook geautomatiseerd kan worden.

3- HET PROGRAMMA TEN

Het tekenprogramma is opgeleverd in de vorm van een aantal programmafiles en enkele files met data. Deze files zijn: LGO

: Programma (object)

TEN

: FORTRAN-programma (source)

PROCATT: Procedure TEN TENDIAL: Dialoog met TEN TENTABL: Standaard netwerk van huidige energiemodel

De documentatie is vastgelegd in een user’s manual [22]° De gehele data flow voor het maken van een grafisehe voorstelling van het energie-netwerk is weergegeven in figuren 2 en 3. Hierin wordt door GAMS een workfile ge~enereerd met de uit~omsten van een run, vanuit deze file wordt door het programma GAMSDAT de benodigde informatie overgebracht naar de file LOADDAT. Het Fortranprogramma GAMSDAT [23], maakt gebruik van GAMS-utilitieso

De file LOADDAT bevat de gegevens die samen met het netwerk uit TENTABLE door TEN interactief kunnen worden omgezet in een plotfile (NPFILE) die met behulp van een grafisch softwarepakket (UNIPOST) op het beeldscherm of op de plotter kan worden afgedrukto Een netwerk kan worden opgezet moboV. TEN of via SUEDIo In figuren 4 en 5 is een voorbeeld uitgewerkto

-11.8-

Figuur Io~ Voorbeeld van een netwerk

EDA i00o0 ~ ~

EDB IY~ORTI EDD

I0 o0 20.0

Figuur 2o~ Het opzetten van een netwerk

TEN

Figuur 3.: Processen en Data-flow

i

STUURDAT

]~ TENTABL TEN

NPFILE

UNIPOST /

~

~ CALCOMP

-ILI0-

Figuur 4.: Voorbeeld van een netwerk (LOADDAT)

/PRNAME

2

PRODA PRODB

/VRNAME VRAAG /ENERGYTYPE EDA EDB EDC EDD / IMPORT -

3

LENGTH OF VECTORS:

2

PRODA

EDA

PRODB

EDB

i0o00

PRODB

EDD

20.00

/ INTERMED PRODA /DELIVERY

1 PRODB 2

i00o0

LENGTH OF VECTORS: EDA LENGTH OF VECTORS:

I

i

I

i

2

50°0 2

PRODA

VRAAG

EDC

50.0

PRODB

VRAAG

EDB

80.0

/ ENDATA

3

Figuur 5o: Voorbeeld van een netwerk (TENTABL)

/PRNAME PRODA PRODB

2 10.0 20.0

50.0 50°0

1 1

/VR-DCNAME VRAAG

i 30°0

40.0

1

/ENERGYTYPE EDA EDB EDC EDD

4 1 1 1 1

/IMPORT PRODA o0 PRODB .0 PRODB o0 /INTERMED PRODA /DELIVERY PRODA 13.3 PRODB 20.0 /GLOBAL: MEPR MEDC IMPO INTE DELI

/

TEXT /ENDDATA

fvol la2.rap

EDA 13 o0 EDB 42.0 23oO EDD 40o0 23.0

1 44.0 1 42.0 I 40 o0

i

2

I

i

2

i

i

2

I

1 PRODB

EDA

i

1

0

EDC 55°0 EDB 52°0

1

i

2

1

1

2

44.0

2 VRAAG 33.3 VRAAG 52°0 33.3 55.0

.50 °50 °50 °50 °50

1 1 i I 1

1 1 i