Energy Technology Systems Analysis Programme

http://iea-etsap.org/index.php/documentation

Documentation for the TIMES Model

PART IV
October 2016

Authors: M. Gargiulo
K. Vailancourt
R. De Miglio

1
 General Introduction

This documentation is composed of five Parts.

Part I provides a general description of the TIMES paradigm, with emphasis on the model’s
general structure and its economic significance. Part I also includes a simplified mathematical
formulation of TIMES, a chapter comparing it to the MARKAL model, pointing to
similarities and differences, and chapters describing new model options.

Part II constitutes a comprehensive reference manual intended for the technically minded
modeler or programmer looking for an in-depth understanding of the complete model details,
in particular the relationship between the input data and the model mathematics, or
contemplating making changes to the model’s equations. Part II includes a full description of
the sets, attributes, variables, and equations of the TIMES model.

Part III describes the organization of the TIMES modeling environment and the GAMS
control statements required to run the TIMES model. GAMS is a modeling language that
translates a TIMES database into the Linear Programming matrix, and then submits this LP to
an optimizer and generates the result files. Part III describes how the routines comprising the
TIMES source code guide the model through compilation, execution, solve, and reporting; the
files produced by the run process and their use; and the various switches that control the
execution of the TIMES code according to the model instance, formulation options, and run
options selected by the user. It also includes a section on identifying and resolving errors that
may occur during the run process.

Part IV provides a step-by-step introduction to building a TIMES model in the VEDA-Front

End (VEDA-FE) model management software. It first offers an orientation to the basic
features of VEDA-FE, including software layout, data files and tables, and model
management features. It then describes in detail twelve Demo models (available for download
from the ETSAP website) that progressively introduce VEDA-TIMES principles and
modeling techniques.

Part V describes the VEDA Back-End (VEDA-BE) software, which is widely used for
analyzing results from TIMES models. It provides a complete guide to using VEDA-BE,
including how to get started, import model results, create and view tables, and create and
modify user sets, and step through results in the model Reference Energy System. It also
describes advanced features and provides suggestions for best practices.

2
PART IV: Getting Started with the
VEDA-TIMES Demo Models

3
 TABLE OF CONTENTS FOR PART IV

1 INTRODUCTION .................................................................................................. 8
1.1 Downloading and setting up the DemoS models .................................................................................... 8

2 INTRODUCTION TO VEDA FRONT END ........................................................... 9

2.1 Folders and subfolders ............................................................................................................................. 9
2.2 VEDA-FE Navigator and types of workbook files ............................................................................... 10
2.3 VEDA-FE workbook tables ................................................................................................................... 12
2.3.1 Basic tables needed for any model .................................................................................................. 12
2.3.2 Tables need for scenario and transformation files........................................................................... 13
2.3.3 Advanced tables .............................................................................................................................. 13
2.3.4 Commodity definition tables ~FI_COMM...................................................................................... 14
2.3.5 Process definition tables ~FI_PROCESS ........................................................................................ 15
2.3.6 Flexible import tables ~FI_T .......................................................................................................... 16
2.3.7 Transformation Insert and Update tables ~TFM_INS and ~TFM_UPD ........................................ 18
2.3.8 User constraints and their tables ..................................................................................................... 19
2.4 VEDA-FE database tools ....................................................................................................................... 21
2.4.1 Browser ........................................................................................................................................... 21
2.4.2 RES viewer ..................................................................................................................................... 22
2.4.3 Commodity/Process Master ............................................................................................................ 23
2.4.4 Attribute Master Table .................................................................................................................... 23
2.4.5 Case Manager .................................................................................................................................. 25

3 TIMES DEMO MODELS .................................................................................... 28

3.1 DemoS_001 - Resource supply ............................................................................................................... 28
3.1.1 SysSetting template ......................................................................................................................... 30
3.1.1.1 Region-Time slices ..................................................................................................................... 30
3.1.1.2 TimePeriods sheet ...................................................................................................................... 31
3.1.1.3 Import Settings sheet .................................................................................................................. 31
3.1.1.4 Interpol_Extrapol_Defaults sheet ............................................................................................... 32
3.1.1.5 Constants sheet ........................................................................................................................... 32
3.1.1.6 Defaults sheet ............................................................................................................................. 33
3.1.2 B-Y Template.................................................................................................................................. 33
3.1.2.1 RES&OBJ sheet ......................................................................................................................... 34
3.1.2.2 EnergyBalance sheet .................................................................................................................. 34
3.1.2.3 Pri_COA..................................................................................................................................... 35
3.1.2.4 DemTechs_TPS.......................................................................................................................... 36
3.1.2.5 Demands ..................................................................................................................................... 37
3.1.3 Solving the model ........................................................................................................................... 37
3.1.4 Results analysis in VEDA-BE ........................................................................................................ 37
3.2 DemoS_002 - More demand options and multiple supply curves....................................................... 43
3.2.1 B-Y Templates ................................................................................................................................ 44
3.2.1.1 EnergyBalance sheet .................................................................................................................. 44
3.2.1.2 Pri_COA/GAS/OIL sheets ......................................................................................................... 44
3.2.1.3 Sector_Fuels sheet ...................................................................................................................... 45
3.2.1.4 DemTechs_RSD and DemTechs_TRA sheets ........................................................................... 45
3.2.1.5 Demands sheet ........................................................................................................................... 46
3.2.2 Results ............................................................................................................................................. 46

4
3.3 DemoS_003 - Power sector: basics ........................................................................................................ 49
3.3.1 SysSettings file................................................................................................................................ 49
3.3.1.1 TimePeriods sheet ...................................................................................................................... 49
3.3.1.2 Constants sheet ........................................................................................................................... 50
3.3.2 B-Y Templates ................................................................................................................................ 51
3.3.2.1 EnergyBalance sheet .................................................................................................................. 51
3.3.2.2 Pri_COA/GAS/OIL sheets ......................................................................................................... 51
3.3.2.3 Pri_RNW and Pri_NUC sheets .................................................................................................. 52
3.3.2.4 Sector_Fuels sheet ...................................................................................................................... 53
3.3.2.5 Con_ELC sheet .......................................................................................................................... 53
3.3.2.6 DemTechs_ELC sheet ................................................................................................................ 54
3.3.2.7 Demands ..................................................................................................................................... 55
3.3.3 Results ............................................................................................................................................. 55
3.4 DemoS_004 - Power sector: sophistication ........................................................................................... 57
3.4.1 SysSettings file................................................................................................................................ 58
3.4.1.1 Region-Time Slices .................................................................................................................... 58
3.4.1.2 Interpol_Extrapol_Defaults ........................................................................................................ 58
3.4.1.3 Constants .................................................................................................................................... 59
3.4.2 B-Y Templates ................................................................................................................................ 59
3.4.2.1 Con_ELC.................................................................................................................................... 59
3.4.2.2 Pri_COA/GAS/OIL .................................................................................................................... 61
3.4.2.3 Demands ..................................................................................................................................... 61
3.4.3 Scenario files ................................................................................................................................... 62
3.4.3.1 Scen_Peak_RSV and Scen_Peak_RSV-FLX ............................................................................. 62
3.4.4 Results ............................................................................................................................................. 62
3.5 DemoS_005 - 2-region model with endogenous trade: compact approach ........................................ 65
3.5.1 SysSettings file................................................................................................................................ 66
3.5.1.1 Region-Time Slices .................................................................................................................... 66
3.5.2 B-Y Templates ................................................................................................................................ 66
3.5.2.1 EnergyBalance, EB1, EB2 ......................................................................................................... 66
3.5.2.2 Pri_COA/GAS/OIL .................................................................................................................... 67
3.5.2.3 Con_ELC.................................................................................................................................... 68
3.5.3 Trade files ....................................................................................................................................... 68
3.5.3.1 Scen_Trade_Links ...................................................................................................................... 69
3.5.3.2 Scen_Trade_Param..................................................................................................................... 69
3.5.4 Scenario files ................................................................................................................................... 70
3.5.4.1 Scen_ELC_CO2_Bound ............................................................................................................ 70
3.5.4.2 Scen_UCCO2_BND – user constraint ....................................................................................... 70
3.5.5 Results ............................................................................................................................................. 71
3.6 DemoS_006 - Multi-region with separate regional templates ............................................................. 74
3.6.1 SysSettings file................................................................................................................................ 75
3.6.1.1 Region-Time Slices .................................................................................................................... 75
3.6.2 B-Y Templates ................................................................................................................................ 76
3.6.3 SubRES_NewTechs ........................................................................................................................ 76
3.6.3.1 SubRES_NewTechs_Trans ........................................................................................................ 77
3.6.4 Results ............................................................................................................................................. 77
3.7 DemoS_007 – Adding complexity .......................................................................................................... 77
3.7.1 SysSettings file................................................................................................................................ 79
3.7.1.1 Interpol_Extrapol_Defaults ........................................................................................................ 79
3.7.2 B-Y Templates ................................................................................................................................ 79
3.7.2.1 EnergyBalance ........................................................................................................................... 79
3.7.2.2 Con_REF – primary commodity group definition ..................................................................... 80
3.7.2.3 Pri_PP......................................................................................................................................... 82
3.7.2.4 Sector_Fuels ............................................................................................................................... 82

5
 3.7.2.5 DemTechs_TRA......................................................................................................................... 83
3.7.2.6 Demands ..................................................................................................................................... 84
3.7.2.7 Emi ............................................................................................................................................. 84
3.7.3 SubRES_NewTechs ........................................................................................................................ 84
3.7.3.1 PRI_TRA .................................................................................................................................. 84
3.7.4 Scenario files ................................................................................................................................... 85
3.7.4.1 Scen_DemProj_DTCAR ............................................................................................................ 85
3.7.4.2 Scen_Refinery ............................................................................................................................ 85
3.7.4.3 Scen_TRA_CO2_BOUND ........................................................................................................ 86
3.7.4.4 Scen_UC Growth ....................................................................................................................... 86
3.7.4.5 Scen_ElasticDem ....................................................................................................................... 87
3.7.5 Results ............................................................................................................................................. 89
3.8 DemoS_008 - Split Base-Year (B-Y) templates by sector: demands by sector .................................. 90
3.8.1 SysSettings file................................................................................................................................ 92
3.8.1.1 TimePeriods ............................................................................................................................... 92
3.8.1.2 Defaults ...................................................................................................................................... 93
3.8.2 B-Y Template VT_REG*_PRI_V08 .............................................................................................. 93
3.8.2.1 EnergyBalance ........................................................................................................................... 93
3.8.2.2 Pri_COA, Pri_GAS, Pri_OIL, Pri_PP, Con_REF ...................................................................... 94
3.8.2.3 Pri_RNW and Pri_NUC ............................................................................................................. 94
3.8.2.4 Pri_ELC...................................................................................................................................... 94
3.8.3 B-Y Template VT_REG*_ELC_V08 ............................................................................................. 94
3.8.3.1 Con_ELC.................................................................................................................................... 94
3.8.3.2 Emi ............................................................................................................................................. 95
3.8.4 BY Template VT_REG*_IND_V08 ............................................................................................... 95
3.8.4.1 DemTechs_IND ......................................................................................................................... 95
3.8.4.2 Emi ............................................................................................................................................. 96
3.8.5 BY Template VT_REG*_RCA_V08 .............................................................................................. 96
3.8.5.1 DemTechs_AGR ........................................................................................................................ 96
3.8.5.2 DemTechs_RSD and DemTechs_COM ..................................................................................... 96
3.8.5.3 Demands ..................................................................................................................................... 97
3.8.5.4 Emi ............................................................................................................................................. 98
3.8.6 BY Template VT_REG*_TRA_V08 .............................................................................................. 98
3.8.6.1 DemTechs_TRA......................................................................................................................... 98
3.8.6.2 Demands ..................................................................................................................................... 98
3.8.6.3 Emi ............................................................................................................................................. 98
3.8.7 SubRES_NewTechs ........................................................................................................................ 98
3.8.7.1 IEA-ETSAP_ETechDS .............................................................................................................. 98
3.8.8 Scenario files ................................................................................................................................... 99
3.8.8.1 Scen_UC_CO2BND................................................................................................................... 99
3.8.8.2 Scen_UC_NUC_MaxCAP ......................................................................................................... 99
3.8.9 Results ........................................................................................................................................... 100
3.9 DemoS_009 - SubRES sophistication (CHP, district heating) and Trans files ................................ 101
3.9.1 B-Y Template VT_REG*_ELC_V09 ........................................................................................... 103
3.9.1.1 Con_ELC.................................................................................................................................. 103
3.9.1.2 BY_Trans ................................................................................................................................. 104
3.9.2 SubRES_NewTechs_Trans ........................................................................................................... 105
3.9.3 SubRES_New-IND ....................................................................................................................... 105
3.9.4 SubRES_New-CHP-DH ............................................................................................................... 106
3.9.5 Scenario files ................................................................................................................................. 108
3.9.5.1 Scen_IND_NewRES ................................................................................................................ 108
3.9.5.2 Scen_UC_DH_MinProd........................................................................................................... 108
3.9.6 Results ........................................................................................................................................... 109
3.10 DemoS_010 - Demand projections and elastic demand ..................................................................... 110

6
 3.10.1 Demand files ................................................................................................................................. 110
3.10.1.1 ScenDem_DEM_Ref ............................................................................................................... 110
3.10.1.2 Dem_Alloc+Series ................................................................................................................... 111
3.10.2 Results ........................................................................................................................................... 112
3.11 DemoS_011 - Linking input templates and VEDA-BE sets .............................................................. 113
3.11.1 Scen_Bounds-UC-wSets ............................................................................................................... 113
3.11.2 Results ........................................................................................................................................... 114
3.12 DemoS_012 – More modelling techniques .......................................................................................... 115
3.12.1 B-Y Template VT_REG*_Pri_V12 .............................................................................................. 116
3.12.1.1 TOTCO2 .................................................................................................................................. 116
3.12.2 SubRES_NewTechs (ELC sheet) .................................................................................................. 116
3.12.3 Scenario files ................................................................................................................................. 117
3.12.3.1 Scen_NUC_DiscInv – lumpy investments ............................................................................... 117
3.12.3.2 Scen_TRADSL_Tax ................................................................................................................ 118
3.12.3.3 Scen_CO2_Tax ........................................................................................................................ 118
3.12.3.4 Scen_Solar_Subsidies .............................................................................................................. 119
3.12.3.5 Scen_UC_CO2_Regions .......................................................................................................... 119
3.12.4 Results ........................................................................................................................................... 119

7
1 Introduction
This Part of the TIMES documentation provides a step-by-step introduction to building a
TIMES model in the VEDA-Front End (VEDA-FE) model management software, using a series
of twelve DemoS models (available for download from the ETSAP website) to progressively
demonstrate VEDA-TIMES principles and modeling techniques. The remainder of Section 1
describes how to access and set up the TIMES DemoS models. Section 2 provides an orientation
to the basic features of VEDA-FE, including software layout, commonly used data files and
tables, and model management features. Section 3 then walks through the twelve DemoS models,
providing for each a summary of the VEDA-TIMES features and model attributes introduced, a
detailed guide to the templates and tables used, and a look at the model results.

1.1 Downloading and setting up the DemoS models

The complete set of VEDA-TIMES DemoS models is available, along with all five Parts of
the TIMES documentation, on the ETSAP Documentation web page (http://www.iea-
etsap.org/index.php/documentation) under ‘VEDA-TIMES Demo Models’. You will also need
VEDA-FE and Back End (BE) installed in order to follow along with this manual. VEDA
Installation instructions are available at http://support.kanors-emr.org/.

The DemoS model zip folder include two sub-folders:

 ETSAP_DemoS_VFE. In this folder there are 12 subfolders, one for each of the twelve
Demos. This folder should be pasted into your VEDA_Models folder
(C:\VEDA\VEDA_Models, if you did not change the path during installation).
 DemoS_VBE. This folder contains a database with predefined tables for analyzing model
results. This folder should be pasted into your VEDA-BE Databases folder
(C:\VEDA\Veda_BE\Databases, if you did not change the path during installation).

To open the first DemoS from VEDA-FE and set up the VEDA-BE database:

 Launch VEDA-FE, and use the VEDA Navigator (described in Section 2.2) to browse to
the folder in which the DemoS_001 is stored. (C:\VEDA\VEDA_Models\DemoS_001, if
you have followed the default installation).
o At this point VEDA-FE will load DemoS_001 into the Navigator.
 Launch VEDA-BE, select Open from the File menu, and browse to the folder where you
have stored the DemoS_VBE database.
o When the DemoS_VBE database is loaded, the list of pre-defined tables can be
seen under Table definition at the top left of the main window. To view a
particular table, scroll down/up the list and select one table, then click the View
Table(s) button. The table will open with a pre-defined layout than can be
modified in a very flexible manner. Note that not all the tables can be used for the
first demo steps, in which only a few simple results will be available. If a VEDA-
BE table is inconsistent or empty, you will get a pop up message saying that table
is empty.

8
2 Introduction to VEDA Front End
This section provides a brief introduction to using VEDA-FE and VEDA Excel template
workbooks for building, browsing, and running a TIMES model. VEDA-FE is used to facilitate
TIMES model building based on a modular approach and heavily reliance on flexible Excel
workbooks integrated into a core database visible via tabular and diagrammatic browsing tools. It
is also used to develop and manage model runs. The main tools available in VEDA-FE are:

 A Navigator to oversee the management of the Excel workbooks.

 A Browser to view all model data (based on filter and search facilities).
 Reference energy system (RES) diagramming and Commodity/Process Masters with
data views.
 A Case Manager window for composing and submitting model runs.

These are described in Section 2.4, following a description of the VEDA-FE template folder
structure, file types, and tables used to create model input. VEDA-FE is complimented by VEDA
Back End (BE) for analysis of model run results. (See Part V of this documentation for more on
VEDA-BE.)

2.1 Folders and subfolders

All VEDA-TIMES model input data is organized in Excel workbooks (or files). VEDA-FE
then integrates information from all of these workbooks into a single database to generate a
TIMES model. The models managed by VEDA-FE are normally stored in a specific folder (by
default \VEDA\VEDA_Models). Within this folder, there is a sub-folder for each individual
model a user is working with, including all of the VEDA-TIMES Demo Models
((\VEDA\VEDA_Models\DemoS_001, etc.). The sub-folder structure is identical for each
individual model (Figure 1, left side) and includes:

Figure 1. Sub-folders structure for each VEDA-FE model

9
  The B-Y Templates, the SysSettings files and the BY_Trans file.
 A sub-folder (SubRES_TMPL) to store all SubRES files and associated transformation
files.
 A sub-folder (SuppXLS) to store all scenario files, as well sub-folders for trade files
(Trades) and demand files (Demands) (Figure 1, right side).
 The Logs folder, which provides a location for VEDA-FE to write a variety of log files,
including QA_Checks, error messages, and run summaries. Its contents are accessible via
the LOGs button in the Case Manager.
 Users are not concerned with the other sub-folders.

2.2 VEDA-FE Navigator and types of workbook files

VEDA-FE opens displaying the VEDA-Navigator (Figure 2), which provides a
comprehensive view of all the files in the various folders managed by VEDA-FE for the current
model. The specific folder pathway associated with the active model is displayed on the top bar
of the VEDA-Navigator form (in Figure 2, MODEL: C:\VEDA\VEDA_Models\TIMES
DEMOS\DemoS_012). Clicking on this bar will open a window where the user can change the
active model, by selecting a previously opened model from the list shown, or opening a new one
by clicking the New button and navigating to the path of the new model folder.

Figure 2. The VEDA-FE Navigator

The VEDA-Navigator is the main vehicle for accessing, importing, and coordinating the
various files that make up a model. Its front screen is divided into sub-windows according to the
various types of files managed by VEDA-FE:

 B-Y (Base Year) Templates: These templates can be used to set up the base-year
structure of the model (existing process stock and the base-year end-use demand levels),
such that the overall energy flows reflect the energy balance. In other words, the start

10
 year of the model can be calibrated to the energy balance in the B-Y Templates. The B-Y
templates are named as VT_<workbook name>_<sector>_<Version> (e.g.
VT_REG_PRI_V1). The number of B-Y templates and their names depend on both the
model structure (e.g., the number of regions and sectors) and the organisation of the input
data (e.g., how many regions and sectors in each file). The B-Y templates are introduced
in DemoS_001 (Section 3.1) and are modified throughout the evolution of the 12 Demo
steps.
 SysSettings: This file is used to declare the very basic structure of the model including
regions, time slices, start year, etc. It also contains some settings for the synchronization
process and can include some additional information. There is only one such file; it has a
fixed name that stands for System Settings. The SysSettings file is described in Section
3.1.1.
 BY_Trans: These transformation files are used to update the information included in the
B-Y templates (update existing values for existing attributes) and/or to insert new
information (insert new attributes for existing processes) in the B-Y templates. They
work like a scenario file (described below), but the rule-based filters and the update/insert
changes apply only to those processes and commodities already existing in the B-Y
templates. The BY_Trans file is introduced in DemoS_009 (Section 3.9.1.2).
 Scenarios: Scenario files are used to update existing information and/or to insert new
information in any part of the RES, including B-Y templates, SubRES files, and Trade
files. They are also used to include any additional user constraints in the model. The
naming convention is: Scen_<scenario name>. These files can only manipulate (insert or
update) information associated with previously declared RES components. New
commodities and processes may not be added via scenario files, only new attributes.
Scenario files are introduced in DemoS_004 (Section 3.4.3). Several different
applications of scenario files are illustrated through the remainder of the Demos.
 SubRES: The SubRES files are used to introduce new processes and commodities in the
RES that are not part of the B-Y templates. However, while the B-Y templates are
region-specific, the SubRES are region independent. For each SubRES file, there is a
corresponding transformation (Trans) file allowing the introduction of regional
specificity of process attributes, including the availability (or not) of processes in each
region. The naming conventions are: SubRES_<name> and SubRES_<name>_Trans.
SubRES files are introduced in DemoS_006 (Section 3.6.3).
 Demand Scen: The demand files include all the information necessary to project end-use
demands for energy services in each region, such as macroeconomic drivers and
sensitivity series. Multiple demand files may be used, to model different demand growth
scenarios for instance, and the naming convention is: ScenDem_<scenario name>. This
section of the Navigator also contains a single file permitting assignment of a demand
driver as well as a sensitivity (or elasticity) series each end-use demand to its driver in
each region: Dem_Alloc+Series. Demand files and tables are described in DemoS_010
(Section 3.10.1).
 Trade Scen. The trade files include all of the attribute specifications for the trade
processes. Multiple trade files may be used, to model different trade scenarios or for
different commodities. The naming convention is: ScenTrade_<scenario name>. This
section of the Navigator contains also a single file in which all uni- or bilateral trade links

11
 between regions are declared: ScenTrade__Trade_Links. Trade files are introduced in
DemoS_005 (Section 3.5.3).

The VEDA-Navigator enables easy access to any of the Excel files constituting the currently
open model. Double-clicking directly on any file name (or the Excel icon next to it, in the case of
the BY_Trans and SysSettings files) will open that file in Excel, while clicking on the bar above
each section of the Navigator will open the associated folder in Windows Explorer. (For example
clicking on SubRES in Figure 2 will open the folder VEDA\VEDA_Models\DemoS_012
\SubRES_TMPL).
The VEDA-Navigator also provides feedback as to the status of the various files and the
integrated database managed by VEDA-FE. The consistency of the files and database is
immediately evident based upon whether the central button is marked as SYNC in red (as shown
on the left side of Figure 2) or as ALL OK in blue (right side of Figure 2). The status of
individual templates is indicated by their colors in the template lists, according to the legend at
the bottom of the form. A file is shown as inconsistent (in red) when it has a newer date/time
stamp than in the database. Note: you may need to do a Refresh (from the Window menu, or hit
F5) to see the current status of the files after a recent change.
Hitting the SYNC button will synchronize all files in the application folder marked as
inconsistent. You may force synchronization of other files by checking the checkbox next to
their names before hitting SYNC.

2.3 VEDA-FE workbook tables

The VEDA-FE import program reads each sheet in each file in sequence, looking for VEDA-
FE tables to be read, which are identified by table tags including the special character " ~ ".
VEDA-FE tables must be separated from the rest of the worksheet, which may contain any other
contents, by blank rows and columns. Rows and columns starting with the character " * " or
with “\I:”, which stands for "ignore", are not read.
The most common types of tables are briefly described in this section. More information on
how to use them for specific cases is shown in the sections associated with each step of the
demo.

2.3.1 Basic tables needed for any model

The following tables are needed in any VEDA-TIMES model.

 Tables that exist only in the SysSetting file. (Section 3.1.1 describes how to use these
tables).
o ~BookRegions_Map to declare the workbook name and the list of region names.
o ~TimeSlices to declare the time-slice resolution for the model.
o ~StartYear to declare the start year of the model.
o ~ActivePDef to declare the set of active periods.
o ~TimePeriods to declare the time horizon of the model for the ActivePdef.
o ~ImpSettings to define some settings for the synchronization process.
o ~Currencies to define a default currency for the whole model.
o ~DefUnits to define default units by activity, capacity, and commodity for each
sector in the model.

12
  Commodity Definition Tables (~FI_COMM) for commodity declaration and definition.
These tables can be used in BY, SubRES and SysSetting files. They are described further
in Section 2.3.4.
 Process Definition Tables (~FI_PROCESS) for process declaration and definition. These
tables can be used in BY, SubRES and SysSetting files. They are described further in
Section 2.3.5.
 Flexible Import Tables (~FI_T) for topology and parameter definition. These tables can
be used in BY and SubRES files. They are described further in Section 2.3.6.

2.3.2 Tables need for scenario and transformation files

The following tables can be used to improve and update the model in scenario files and
transformation files.

 Transformation Insert Tables (~TFM_INS) in scenario and transformation files, used to

define absolute values via additional parameters that were not defined in the base year
templates.
 Transformation Update Tables (~TFM_UPD) in scenario and transformation files
operate on existing data defined in previous scenarios. Updates are applied to seed values
that are picked up from the closest alphabetically preceding scenario. As shown in
Section 2.3.7, Insert and Update tables can use rules to pick out the processes and
commodities whose data is to be adjusted.
 Transformation Direct Insert Tables (~TFM_DINS) are also used to insert data, but
unlike in Insert tables, it is forbidden to define subsets of technologies using
text/wildcards, and for each attribute all the required dimensions must be defined (no
defaults). These tables can be useful when working with large, detailed source data
tables, because VEDA-FE’s processing of DINS tables is much faster than that of Insert
tables.

2.3.3 Advanced tables

The following tables are special and/or advanced tables that can be used in different types of
files to support users in model building.

 Special tags exist for emission commodity tables. With this type of table identifier the
data are manipulated during the import process to provide for special calculations on
emissions factors.
o ~COMEMI to link emissions to commodity consumption. An example on how to
use this table is shown in Section 3.7.2.7.
o ~COMAGG to define an aggregated commodity TOTCO2.
 Fill tables in scenario files (~TFM_FILL) allow extraction of values from the rest of the
model database for use in Update or Insert tables. An example is shown in Section
3.7.4.1.
o The TFM_FILL table is also available in SubRES transformation file. The only
difference is that it can only be populated with numbers from the BASE scenario.
o The fill operation will color the Region cells upon processing to indicate the
number of records found, as follow:
 Blue color represents only one record found, and

13
  Purple color represents that more than one record was found for the
specified parameter and its dimensions while filling the region value in the
relevant row.
o The user can specify whether multiple values are to be summed, averaged, or
counted.
 Different tags exist for transformation tables indicating that the import process is
different than from the standard input tables ~FI_T. With this type of table identifier the
data are manipulated during the import process and not imported as provided. They are
supported in the BY_Trans file, SubRES files, and all scenario files.
o ~TFM_AVA to declare the availability of processes in different regions.
 Special tables that exist only in the demand module:
o ~DRVR_Allocation to allocate a driver to each end-use demands.
o ~Series to define sensitivity and calibration series.
o ~DRVR_Table to define demand driver indexes (base-year =1).
 Special tables that exist only in the trade module:
o ~TradeLinks to declare uni- or bilateral trade links between regions.
 User constraints are identified with specific identifiers (~UC_Sets: )

2.3.4 Commodity definition tables ~FI_COMM

Commodity definition tables (~FI_Comm) are used to declare the non-numerical
characteristics of commodities. The columns headers are fixed but their order can be changed.
Each commodity needs to be declared (only) once in such a table as shown in Figure 3. They are
supported in B-Y Templates, SubRES files, and the SysSettings template. Commodities that are
declared in a SubRES can only be used in that SubRES. Care must be taken that commodities are
declared only once, as problems can arise if the same commodity is declared twice with
conflicting attributes, such as different time slice levels. In large complex models, therefore, a
best practice would be to declare them in a single template location only, such as the SysSettings
template.

Figure 3. How to use ~FI_COMM (table from DemoS_001)

The valid column headers for a commodity table ~FI_COMM are described in Table 1.

Table 1. Valid column headers for a commodity table ~FI_COMM

Header Description
Csets* The sets to which commodities belong. Valid entries are: NRG (energy), MAT
(material), DEM (demand service), ENV (emissions) and FIN (financial).
These declarations are inherited until the next one is encountered. In this
example, COA (Solid Fuels) is an energy commodity (NRG).
Region* The region name. By default, it is applied to all regions of the model when not
specified. The region designation is used only in the B-Y templates and not
allowed in SubRES.

14
 CommName The commodity name (COA).
CommDesc The commodity description (Solid Fuels).
Unit The commodity unit throughout the model (PJ). It is responsibility of the user
to be consistent with units.
LimType The sense of the balance equation for the commodity. Valid entries are LO
(Production>=Consumption, FX (Production=Consumption), UP
(Production<=Consumption). When not specified, the default is LO.
CTSLvl The commodity time-slice tracking level. Valid entries are ANNUAL,
SEASON, WEEKLY and DAYNITE. When not specified, the default is
ANNUAL.
PeakTS* Peak time slice monitoring. Valid entries are: ANNUAL to generate the
peaking equation for all time slices or any specific time slices already defined
in the SysSettings file (comma-separated entries allowed). If not specified the
default is ANNUAL.
CType Electricity commodities indicator (ELC).
* Note: Comma separated elements are allowed.

2.3.5 Process definition tables ~FI_PROCESS

Process definition tables (~FI_Process) are used to declare the non-numerical characteristics
of processes. The columns headers are fixed but their order can be changed. Each process needs
to be declared (only) once in such a table as shown in Figure 4. They are supported in B-Y
Templates and SubRES files.

Figure 4. How to use ~FI_PROCESS (table from DemoS_001)

The valid column headers for a process table ~FI_PROCESS are described in Table 2.

Table 2. Valid column headers for a process table ~FI_Process

Header Description
Sets* The sets to which processes belong. The process set indicates the nature of a
process. Valid entries are: ELE (thermal or other power plant), CHP (combined
heat and power), PRE (generic process), DMD (demand device), IMP (import
process), EXP (export process), MIN (mining process), HPL (heating plant),
IPS for inter-period storage, NST for night storage device, STG for general
timeslice storage, STS for simultaneous DayNite/Weekly/Seasonal, STK for
simultaneous DayNite/Weekly/Seasonal and interperiod storage process. These
declarations are inherited until the next one is encountered. In this example,
there are three mining processes (MINCOA*), one import process (IMPCOA1)
and one export process (EXPCOA1), all related to the supply of solid fuels
(COA).
Region The region name where the process exists (comma-separated entries allowed).

15
 By default, it is applied to all regions of the model when not specified.
The region designation is used only in the B-Y templates and not allowed in
SubRES.
TechName The process name (e.g. MINCOA1), up to 32 characters. (However, it is
recommended to limit process names to 27 characters as VEDA-FE may
internally add digits for vintaging issues or dummy imports.)
ProcessDesc The process description (e.g., Domestic supply of Solid Fuels Step 1), up to 255
characters.
Tact The activity unit of the process (in Figure 4, for example, it is in PJ). It is the
user’s responsibility to be consistent with units.
Tcap The capacity unit of the process. It is the user’s responsibility to be consistent
with units.
Tslvl The process time-slice operational level. Valid entries are ANNUAL, SEASON,
WEEKLY and DAYNITE. When not specified, the default is based on the Sets
declaration: DAYNITE (for ELE, STGTSS, and STGIPS), SEASON (for CHP
and HPL), ANNUAL (for all others).
PrimaryCG The Primary Commodity Group (PCG) of the process. Normally none specified
as VEDA allocates the PCG by default. A declaration is needed only when the
user wants to create a new PCG and/or override the default PCG.
Vintage Vintage tracking. Valid entries are YES or NO. When not specified, the default
is NO.
* Note: Comma separated elements are allowed.

2.3.6 Flexible import tables ~FI_T

The Flexible Import Table (~FI_T) is used to create model topology (process inputs and
outputs) in B-Y templates and SubRES. It also provides a very flexible structure (hence the
name) for specifying numerical parameter values. With this type of identifier, the data is
imported as provided and not modified during the import process.
Unlike in most other table types (with the exception of UC tables, described in Section 2.3.8),
the ~FI_T table tag is not placed directly above the upper-leftmost table cell. Instead it is placed
in the row immediately above the table headers and in the column before the first column
containing values. This placement allows any number of columns to be designated for row
identifiers, rather than data, as shown in Figure 5.

Figure 5. How to use the ~FI_T table

16
 Indexes for the data, including attribute, region, year, and timeslice may be specified as either
row identifiers or column headers, so that a table may be laid out to match the configuration of
source data with minimal user intervention.
The ~FI_T table has six distinct regions. Valid entries in each of these are:
 Row ID Col Headers. The valid row ID column headers for a ~FI_T flexible import table
are described in Error! Not a valid bookmark self-reference..

Table 3. Valid row ID column headers for a flexible import table ~FI_T
Header Description
Region* Region declaration
TechName Technology Name
Comm-IN* Input Commodity
Comm-IN-A* Auxiliary Input Commodity
Comm-OUT* Output Commodity
Comm-OUT-A* Auxiliary Output Commodity
Attribute Attribute declaration; single entries permitted
Year Year declaration; comma-separated entries allowed
TimeSlice* Time slices declaration; comma-separated entries allowed
LimType Valid entries are: UP (Upper), LO (Lower), FX (Fixed) and N (Non-
binding)
CommGrp User Defined Commodity Group
Curr Currency declaration
Stage For multi-stage stochastic models
SOW State of the World (Stochastic models)
Other_Indexes To enter special dimensions that are required in certain attributes
* Note: Comma separated elements are allowed.

 Row Identifiers: elements of the dimension indicated in the row ID column headers.
 Data Area Column Headers: Elements of the following dimensions (elements of multiple
dimensions can be separated by ~)
o Attribute
o Year
o TimeSlice
o LimType
o Commodity
o CommGrp (only the internal VEDA commodity groups: DEMO/DEMI/NRGO/
NRGI/MATO/MATI/ENVO/ENVI/FINO/FINI can be used as column headers)
o Region
o Currency
 Data: numerical entries
 Table level declarations: Declarations like those made in column headers can be included
in the table header (following a colon) and will apply to all data that doesn’t have a
different value for that index specified. For example, ~FI_T: DEMAND would assign

17
 DEMAND as the attribute for all values in the table that don’t have an attribute
specification at the column or row level.
 Comments: a comment row is identified by the character " * " or “\I:” as the first
character in any of the cells below the Row ID Col Headers or the first character in any of
the column headers. (However, caution should be exercised in using " * " to indicate a
comment, because it may also be used to indicate a wildcard or an operation in some
cells. “\I:” is the safer choice to indicate a comment row/column.)

2.3.7 Transformation Insert and Update tables ~TFM_INS and ~TFM_UPD

~TFM_INS is a transformation table used to insert new attributes and values in a rule-based
manner. In this example from DemoS_001, it is used to declare three new attributes (G_DYEAR,
Discount, and YRFR) by row as shown in Figure 6.

Figure 6. How to use ~TFM_INS table

~TFM_UPD is a transformation table used to update pre-existing data in a rule-based

manner. For example, in Figure 7 it sets default prices (ACTCOST) for the backstop dummy
processes for energy commodities (IMP*Z - dummy IMPort processes ending with “Z”) and
demands (IMPDEMZ - a dummy IMPDEMZ process that can feed any demand).

Figure 7. How to use ~TFM_UPD table

Valid column headers for data entry in transformation insert and update tables (to update
existing values or insert new values) are presented in the top portion of Table 4. These tables can
identify the items whose data is to updated or inserted using the criteria in the bottom portion of
Table 4.

Table 4. Valid column headers for transformation tables

Header Description
Insert or update values
Attribute Name of the attribute; single entries permitted
Year Year declaration; comma-separated entries allowed; default value = start year
TimeSlice Time slices declaration; comma-separated entries allowed;
default=ANNUAL.
LimType Valid entries are: UP (Upper), LO (Lower), FX (Fixed) and N (Non-binding)
CommGrp User Defined Commodity Group
Curr Currency declaration; default=CUR.

18
 Stage For multi-stage stochastic models
SOW State of the World (Stochastic models)
Other_Indexes To enter special dimensions that are required in certain attributes
AllRegions Data value that is applicable to all regions
<Regions> Region-specific data values; these will supersede any declaration in
AllRegions column
Commodity and process filtering
PSet_Set1 To identify processes based on TIMES set membership
PSet_PN2 To identify processes based on names
PSet_PD2 To identify processes based on descriptions
PSet_CI2 To identify processes based on commodity inputs
PSet_CO2 To identify processes based on commodity outputs
CSet_Set1 To identify commodities based on TIMES set membership
CSet_CN2 To identify commodities based on names
CSet_CD2 To identify commodities based on descriptions
Top_Check To restrict application of attribute data to those process-commodity
combinations where the specified topology already exists in the model, rather
than creating new topology. Valid entries: I/O/A. “I” will retain those
combinations where commodities are input to processes. “O” =>
Output; “A”=> Input or output. No topology check is performed by default.
Attrib_Cond To filter based upon whether an attribute is present or missing (precede with
“-“) for specified processes.
Val_Cond Used in conjunction with Attrib_Cond to filter on the value of the specified
attribute. Define using '<', '>', ‘<>’, or '='. The condition will be tested across
all dimensions (for example, years) for the specified process, region, and
attribute.
1
Comma separated elements are allowed. Each of these fields can have comma-separated entries that are
joined by OR.
2
Comma separated elements and wild cards characters are allowed. The possible wild cards are:
“*” is used as wild card; for example *GAS* would refer to all elements that have GAS in the name with
any possible characters before and after GAS.
“-“ before the text used for exclusions; for example, *GAS*,-ELCGAS would refer to all elements that
have GAS in the name except for ELCGAS.
“?“ can be used to specify a single character; for example, ???GAS means there are 3 characters before
GAS.

2.3.8 User constraints and their tables

User constraints provide the modeller with a flexible framework to add case-study specific
constraints to the standard equation set embedded in TIMES. With the help of user constraints,
virtually any possible linear relationship between core variables in TIMES can be formulated,
and some input attributes can also be brought in as coefficients. User constraints can also be
written to link variables across consecutive time slices or periods. Section 6.4 of Part II of the
TIMES documentation contains an extensive discussion of the user constraint types available and
their mathematics.
Defining user constraints in VEDA-FE templates is a two step process. They are first
declared with one or more ~UC_SETS: tags, which indicate their type and domain of coverage.
Then their data is specified using a table with similar structure to that of a ~FI_T table, as shown
in Figure 8.

19
 Figure 8. Defining a user constraint in VEDA-FE

Available UC sets are described in Table 5. Each set definition holds for the entire sheet,
unless redefined. All the existing set definitions are applied to all user constraints in a table.

Table 5. UC sets available in VEDA-FE

~UC_SETS: Signification Application
R_E Region_Each REG1: apply to one particular region
R_S Region_Sum REG1,REG2: apply to more than one region (comma
separated)
AllRegions: will apply to all regions
T_E Time period_Each
T_S Time period_Sum
TS_E Time slice_Each
TS_S Time slice_Sum
T_SUC Time period
successive

A UC table is then structured similarly to a Flexible Import table, with the ~UC_T tag
separating the column headings into row identifiers (UC_INDEXES) and data column headers.
Valid row ID (UC_INDEX) column headers are:

Table 6. UC_INDEXES for user constraint tables

UC_INDEXES Description
Column Header
UC_N Short Name of the UC
Region Name of the region(s)
PSet_PN* Comma separated list of process names
PSet_PD* Comma separated list of process description
Pset_CI* Comma separated list of (input) commodities to define a set of processes
Pset_CO* Comma separated list of (output) commodities to define a set of
processes
Cset_CN* Comma separated list of commodity names
Cset_CD* Comma separated list of commodity description
Side LHS/RHS; RHS is applicable only in the case of dynamic (across
periods) constraints.
Attribute Any of the UC attributes available in the current TIMES code

UC_ATTR  Allows modifiers to be applied to the variables used in the UC.

These include the GROWTH modifier, to create a constraint that
limits the percentage growth in a variable over periods; modifiers to
pull input data, such as COST and EFF, into the UC's coefficients;

20
 and the NEWFLO modifier that applies the UC coefficient to the
flows of the new vintage of a process only. More details are found in
Section 6.4.6 of Part II.
 The contents of this column are comma separated values of
UC_Name and UC_GrpType. Several pairs can be separated by “;”
 A pair can have UC_Name/GrpType in any order; any element in the
list ACT, CAP, NCAP, FLO, IRE, COMCON, COMPRD,
COMNET is taken as GrpType and the other one is designated as the
UC_Name. Valid UC_Names are provided and described in Section
6.4.6 of Part II.
 UC_ATTR can have a ~ appended to it; the default is LHS.
Year Comma separated list of years is allowed
LimType UP/LO/FX/N
Top_Check To control the process-commodity combinations via topology when both
indexes exist for the attribute in question. Valid entries: I/O/A. “I” will
retain those combinations where commodities are input to
processes. “O” => Output; “A”=> Input or output. Default = A.
* Wild cards allowed

Valid data column headers are:

 Any of the UC attributes available in the current TIMES code
 Years (including 0 for interpolation setting)
 Region
 UP/LO
 LHS/RHS

Multiple values can be separated by “~”. Any specification without a region identifier in the
column is applied to the region in the row identifier area. If there is no region, it applies to all
regions in the active R_E/R_S specification.
A user constraint definition can span multiple rows of the table (to attach numbers/attributes
and other indexes to different sets of processes/commodities).

2.4 VEDA-FE database tools

Once the templates have been imported and assembled as a model database within VEDA-
FE, it is possible to review the resulting data by means of powerful filtering tools and dynamic
data cubes (pivot tables), and it is also possible to view the RES by requesting that the network
diagram be displayed.

2.4.1 Browser
The database browser can be accessed from the main menu (Basic Functions, Browse/Edit,
TIMES View or VEDA View) or by pressing F7. The TIMES View shows the data with
TIMES attribute names, while the VEDA View shows the same information, but with the
attribute names as used in the files1. The browser allows the user to view subsets of the
assembled data in a cube by selecting the scenario(s), region(s), process(es), commodity(ies),

1
A variety of alternate attribute names, or aliases, are available for many TIMES parameters, as shown in
the Attribute Master (see Section 2.4.4).

21
and/or the attribute(s) of interest: the new nuclear power plants in REG1 in the example shown in
Figure 9.

Figure 9. Browser for the model database

First, elements are selected manually or via search tools (right-click) in the different
dimensions, and then the information is displayed in a default layout by clicking the Browse
button. It is possible to rearrange the layout of the cube by adding/removing dimensions
(columns and rows) to/from the table by dragging/dropping components from/to the area above
the current row designator columns.
When the cursor is placed over a dimension a crosshair appears. Then, holding the left mouse
button down and sliding to a new position, a green line will appear indicating that the dimension
may now be dropped there. Any dimension not positioned as part of the row/column table layout
definition appears at the top of the page. These dimensions have their values summed in the
cube. For each dimension on top of the page, if more than one value exists for that dimension, its
name will be displayed between two asterisks reinforcing that some values in the cube may be
aggregates. Note that for any dimension where only a single value exists, said dimension is
automatically moved up top. Using the pull-down arrow associated with each header, individual
entries may temporarily be removed by unselecting them from the list of elements.

2.4.2 RES viewer

The RES viewer can be accessed from the main menu (Basic Functions, RES). It is possible
to navigate around the model by clicking on the name of a commodity or process, allowing the
user to see: 1) in the case of a commodity, all processes producing and consuming that
commodity; and/or 2) in the case of a process, all input and output flows. The right panel of
Figure 10 shows the RES viewer as zoomed in on commodity ELCNUC. We see the single

22
process that produces it and the two that consume it. The legend in the left panel defines the
color coding of the commodities and processes shown. By clicking on any item, the user can
cascade through the RES to better visualize the interrelationships and competing processes
throughout the network.

Figure 10. Schematic representation of the RES

2.4.3 Commodity/Process Master

The Commodity/Process Master viewer can be accessed from the main menu (Advanced
Functions). This feature can be used to examine a proccess or commodity’s declaration,
connectivity, and data details. As in the RES viewer, it is possible to navigate around the model
viewing all the commodities/processes immediately before/after the focus item in the RES. In
addition, the Information and Data tabs provide all of the declaration and data information
about the focus commodity/process (see Figure 11 and Figure 12). It is also possible to get a full
list of commodities/processes in the model by clicking the label All Commodities (Processes).

Figure 11. Commodity Master view

2.4.4 Attribute Master Table

The Attribute Master table is available under Advanced Functions/Attribute Master (as
shown in Figure 13).

23
 Figure 12. Process Master view and data view

Figure 13. How to find the Attribute Master Table

The Attribute Master table (Figure 14) shows all the TIMES attributes/parameters supported
by VEDA-FE and can assist in creating the FI_T, TFM_INS and UPD tables. The table uses the
following color code:

 Grey cells indicate a VEDA-FE default applied to an attribute.

 Green or red cells are used to specify whether an attribute is interpolated/extrapolated
by default or not (a user rule can always be defined).
 Light blue cells indicate that an attribute index is required.

The table consists of the following columns.

 Attribute: lists the name of each supported attribute that can be used in VEDA-FE tables.

24
 Figure 14. Attribute Master table

 Years: specifies whether the attribute can be defined by year (YES) or not (NO). For
attributes that can be, the color of the cell indicates the defaultinterpolation/extrapolation
(I/E) behavior. If green, there is a default I/E applied. If red, there is not.
 Commodity/Process: specifies whether an attribute may be defined by commodity,
process, or both.
 Timeslice column: specifies whether attribute can be defined by timeslice and lists any
default applied by VEDA-FE.
 Limtype: specifies whether a limit type is required (light blue) and lists any default
applied by VEDA-FE.
 Currency: shows the default currency that will be inserted if none is specified.
 Stage and SOW: these columns indicate where this information is required for attributes
used in the stochastic version of TIMES.
 Other_Indexes: list additional information required by an attribute.
 Alias: lists alternative names for the TIMES attribute that can be used in templates.
 Description: provides a description of the attribute.

2.4.5 Case Manager

The Case Manager, available from the Basic Functions menu, or by pressing F9, is used to
compose and submit a model run. Figure 15 illustrates the main features of the Case Manager, as
follows:

25
 Figure 15. Case Manager

A. Select, Delete, LST, LOGs and Save buttons. Select can be used to choose a previously
saved run configuration (run name, run description, scenarios, regions, ….), while Delete
is used to delete an existing configuration.
LST opens the list file associated with a completed run, with information about the run
and equations if enabled.
LOGs opens a QA check log file with information and any warnings about a completed
run. (See Part III of the TIMES documentation for more on the LST and QA check files.)
Save is used to save a new configuration or update an existing one.
B. The first row is used to specify a scenario name (spaces in the name are not allowed),
while the second row can be used for scenario description.
C. The Scenarios and Regions lists are used to check and uncheck which scenarios and
regions are included in a run configuration. In Figure 15, for example, the scenario New-
IND is unchecked, so its data will not be included in the model run. The colored letters in
the scenario panel indicate the scenario type. (E.g., white is the BASE scenario from the
VT files, light blue are the SubRES, and purple are the Scenario files).
D. Indicates the VEDA installation folder. Clicking on the path here will open a browse to
select the installation folder .
E. Indicates the TIMES source code (model generator) installation folder. A left click on
GAMS Source will open the folder.

26
 F. Indicates the folder in which the results of this run will be saved. It is possible to create a
new save folder by selecting New Folder from the dropdown menu here. A left click on
GAMS Work folder will open the folder.
G. This button is used to choose the reference prices in the TIMES elastic demand variant.
H. The Cplex button opens a window used to set up options for the CPLEX solver. The
dropdown menu allows selection of an alternative solver on your computer.
The RUNfile_Tmpl button opens the run file used by TIMES when the model is
submitted to be solved. The dropdown allows selection from alternative versions of the
run file.
Control Panel provides access to a selection of control panel switches (described in Part
III of the TIMES documation) and TIMES variants (described in Parts I and II).
I. Create DD is used to create a data dictionary (DD) file without solving the model.
Close DMD Console if checked will automatically close the “DOS” window at the end
of the run.
P/w Linear VarCost used to reduce run size by projecting linear variable costs.
J. Ending Year allows selection of the ending year of a run.
Period Defs allows selection among period definitions (saved in the SysSetting file).
K. Summary of run option selections.

More information on VEDA-FE and description of additional features are available at

http://support.kanors-emr.org/. Each of the remaining sections of this document describes one
incremental step of the VEDA-TIMES Demo Models.

27
3 TIMES demo models
This section explains how to progress in the use of TIMES features and variants using the set
of VEDA-TIMES Demo Models. This is a set of VEDA-TIMES models that start from an
energy balance and focus on building a model incrementally employing a standard approach to
describe the underlying Reference Energy System (RES) as well as specific naming conventions.
The first step model starts with a simple supply curve feeding a single demand. The Demos
then grow step by step to build out the RES, adding new commodities, processes (or
technologies) and regions, while introducing new attributes (or parameters) and more advanced
TIMES modelling features, and explaining the why of the different choices made in VEDA-FE
for building these models.
The VEDA-TIMES Demo Models consist of several incremental steps. Steps 1 to 12 are
considered the Basic Demo models (Table 7), and are described in this section.). For each step, it
provides:

 A brief description of the step model and the objectives in terms of VEDA-TIMES
features demonstrated;
 A summary of attributes introduced and files created, modified, and/or replaced;
 A step-by-step description of the template tables created and/or modified in each file; and
 A brief look at the results.

Table 7. The Basic Demo models

Demo Folder name Short description
001 DemoS_001 Resource supply
002 DemoS_002 More demand options and multiple supply curves
003 DemoS_003 Power sector: basics
004 DemoS_004 Power sector: sophistication
005 DemoS_005 2-region model with endogenous trade: compact approach
006 DemoS_006 Multi-region with separate regional templates
007 DemoS_007 Adding complexity
008 DemoS_008 Split Base-Year (B-Y) templates by sector: demands by sector
009 DemoS_009 SubRES sophistication (CHP, district heating) and Trans files
010 DemoS_010 Demand projections and elastic demand
011 DemoS_011 Linking input templates and VEDA-BE sets
012 DemoS_012 More modelling techniques

3.1 DemoS_001 - Resource supply

Description. This is the first step and therefore represents a very simple model that serves as
the starting point for the development of a more complex model: it includes a single supply curve
and a single demand for one commodity in a single region over two time periods.
Objective. The objective is to introduce examples of how to implement in VEDA-FE
templates the most basic types of energy commodities and processes that are normally part of a
typical TIMES model, along with their respective attributes: a three-step supply curve, an import
and an export option, one generic demand and one demand process for one energy commodity
(i.e. coal).

28
 This first demo is used also to introduce the SysSettings workbook, the base year template (or
VT template), and how to use the most common VEDA-FE tables.

Attributes introduced2: Files created

G_DYEAR EFF SysSettings
Discount AFA VT_REG_PRI_v01
YRFR INVCOST
CUM FIXOM
COST LIFE
ACT_BND DEMAND

The first step model is built using only two files: the default SysSettings file and one B-Y
Template (VT_REG_PRI_V01). The base year transformation file (BY_Trans) is created by
default; it is empty at this stage. Figure 16 shows the VEDA-FE Navigator (see Section 2.2) for
the DemoS_001. This is the first window you will see when you switch from an other model to
the DemoS_001.

Figure 16. The files included in DemoS_001

The reference energy system (RES) of this first demo can be viewed in VEDA-FE (see
Section 2.4.2 for more information), and it is shown in Figure 17. The RES shows an energy
service demand called TPSCOA satisfied by an end-use demand device called DTPSCOA,
which uses as its input the commodity called COA. The COA commodity can be also
exogenously exported outside the model boundary with the export technology called EXPCOA1.

2
The meaning of all the attributes, along with their qualifier indexes, as said above can be found in
VEDA-FE, Advanced Functions menu, Attributes Master (Figure 14).

29
The production of the COA commodity is based on one import technology (IMPCOA1) and on a
three step local supply curve with the technologies MINCOA1, MINCOA2 and MINCOA3.

Figure 17. Reference energy system DemoS_001

The next two sections explain how this TIMES model for delivering the commodity
TPSCOA at the minimum cost is built in VEDA-FE sheet by sheet for the two templates of this
first demo.

3.1.1 SysSetting template

This file is used to declare the very basic structure of any VEDA-TIMES model, including its
regions, time slices, start year, etc. It also contains some settings for the synchronization process
and can include some additional information. In this example, this file contains the following
sheets:

 Region-Time slices
 TimePeriods
 Import Settings
 Interpol_Extrapol_Defaults
 Constants
 Defaults
 Commodity Group. (This sheet is not used in the basic Demos. In general it can be used
to build user commodity groups.)

3.1.1.1 Region-Time slices

This sheet contains two tables (Figure 18):

 ~BookRegions_Map is used to define

1. The workbook name (here, REG), which needs to be the same for each B-Y Template
of a region.
2. The list of model region names (REG1). In this first step, there is only one region and
one file.

30
  ~TimeSlices is used to define the time-slice resolution for the model at different
hierarchical levels: SEASON, WEEKLY and DAYNITE. In this first step, there is only
one time slice defined by the user for the seasonal level and called ANNUAL.

Figure 18. Regions and time slices definition in the SysSettings file for DemoS_001

3.1.1.2 TimePeriods sheet

This sheet contains three tables (Figure 19):

 ~StartYear is used to define the start year of the model (2005 for this example and all the
other steps).
 ~ActivePDef is used to select the set of active periods (Pdef-1, by default) from all those
defined in the following table.
 ~TimePeriods is used to specify period definitions by specifying the number of years for
each period. In this step, only a single period definition has been created (Pdef-1), which
contains 1 year for the first period (start year) and 2 years for the second period.

Figure 19. Start year and time period definition in the SysSettings file

3.1.1.3 Import Settings sheet

This sheet contains one table (Figure 20):

 ~ImpSettings is used to declare some settings for the synchronization process (1= active;
0=non active).
o Check #DIV/0 and #REF errors in Templates – VEDA will produce a log after the
import process identifying errors made by the user.
o Dummy Imports – These backstop dummy processes can be introduced in the
model automatically by VEDA in order to avoid infeasibilities that may arise

31
 when there is not enough energy carrier produced or when a demand cannot be
supplied. These aid in the model debugging process.
o Vintage Bounds - VEDA can automatically generate bounds to prohibit
investments in processes when a newer vintage becomes available, assuming that
the last two characters of the process name are used for the first year of
availability.
o DumVarforUC – This dummy variable option can be introduced in the model
automatically by VEDA for each User Constraint in order to avoid infeasibilities
due to a user constraint. These aid in the model debugging process.

Figure 20. Import settings in the SysSettings file

3.1.1.4 Interpol_Extrapol_Defaults sheet

This sheet normally contains two tables, one for setting user interpolation rules applied to all
the other files unless the user specifies new rules in other templates to overwrite this information,
and one for setting the default prices of dummy import processes. There is only the second table
in the current version (Figure 21).

 ~TFM_UPD (transformation update table) is a transformation table used to update pre-

existing data in a rule-based manner. In this example, it sets default prices (ACTCOST)
for the backstop dummy processes for energy commodities (processes with names
matching IMP*Z – dummy IMPort processes ending with “Z”) and demands (IMPDEMZ
- a dummy IMPDEMZ process that can feed any demand). These costs should be a few
orders of magnitude higher than real import costs in your model in order to ensure that
these processes only become active when real fuel supplies are insufficient or
unavailable.
 More information about this type of table is available in Section 2.3.7.

Figure 21. Dummy import prices in the SysSettings file

3.1.1.5 Constants sheet

This sheet contains one table (Figure 22):

 ~TFM_INS is a transformation table used to insert new attributes and values in a rule-
based manner. In this first step, it is used to declare three new TIMES attributes.

32
 o G_DYEAR - discounting year; this is a user input and in this example is 2005.
o DISCOUNT - overall discount rate for the energy system; this is a user input and
in this example is 5% and is constant for the entire modelling horizon. The same
rate is used for depreciation of investments.
o YRFR - fraction of year for each time slice; this is a user input and in this
example is 100% for the single ANNUAL time slice.
 More information about this type of table is available in Section 2.3.7.

Figure 22. Constant declarations in the SysSettings file

3.1.1.6 Defaults sheet

This sheet contains two tables (Figure 23):

 ~Currencies is used to define a default currency for the whole model; this is a user input.
In this example the default unit is million 2005 euros (MEuro05). It is important to note
that for TIMES this is just a label called MEuro05. It is the user’s responsibility to be
consistent with costs and units in the model.
 ~DefUnits is used to define units for activity, capacity and commodity for each sector in
the model: petajoules (PJ) and petajoules per year (Pja) in this case. Again, it is the user’s
responsibility to ensure consistency in the units used in any TIMES model. It is possible
to use any units, but it is important to be coherent across the model.

Figure 23. Default declarations in the SysSettings file

3.1.2 B-Y Template

The B-Y templates are used to set up the base structure of the model, and in principle it is
possible to build a full model using just B-Y templates. This is the approach used for this first
example. Later when the model grows to include more commodities, technologies, sectors,
regions, and additional information to run different scenarios, we will demonstrate the flexibility
and modularity of VEDA-FE using different types of workbooks to input information.
In this first example the B-Y Template is used to set up the base-year process stock and the
base-year end-use demand levels, such that the overall energy flows reflect the energy balance.

33
3.1.2.1 RES&OBJ sheet
This sheet contains some pictures showing the normal completion of a run in VEDA-FE with
the value of the objective function and the same objective function in the VEDA-BE table. It is
also showing the reference energy system of this model step using the VEDA-FE feature Go-To
RES described in Section 2.4.2.

3.1.2.2 EnergyBalance sheet

This sheet contains the energy balance at the model start year (2005) for REG1 (Figure 24).
The energy balance in itself is not imported into the model; the table is not identified with any
VEDA table header (cell starting with the character “~”). However, it allows the user to calibrate
the model start year with appropriate historical energy flows. A typical energy balance comprises
two dimensions:

 Different types of energy commodities in columns. In this simple example, the different
types of energies are partially aggregated in categories (e.g. solid fuels, renewable
energies, etc.). The first row of the table includes codes defined by the modeller that are
used to name the energy commodities in the model.
 Steps of the whole supply-demand chain in rows. This simple example shows three main
sections: primary energy supply, energy conversion and final energy consumption. For
each energy commodity, the primary energy supply minus the energy used for conversion
yield the remainder for final energy consumption. The first column of the table includes
codes defined by the modeller that are used to name energy processes in a uniform
manner in the model.

Figure 24. Initial energy balance at start year 2005 for REG1 – Covered in DemoS_001

34
 The portion of the energy balance that is developed in this first step model is identified using
a different color (orange): primary supply of solid fuels (COA).
A greater level of disaggregation can be added along both commodity and sector dimensions
using additional user assumptions as data sources. In this example, shares are provided below the
energy balance table to split the total domestic production of solid fuels (COA) into more than
one step. This way, it is possible to set up in the model a supply curve defined by the maximum
production and cost of each step.

3.1.2.3 Pri_COA
This sheet shows how to declare commodities and processes (in their respective declaration
tables) and to describe specific supply processes (in a flexible import table): primary supply of
solid fuels (COA) in this example.
In any TIMES model, all commodities and processes in the model need to be declared once
in commodity tables (identified with ~FI_Comm) and process tables (identified with ~FI_
Process) with a structure as explained in Sections 2.3.4 and 2.3.5 and shown in Figure 25 and
Figure 26.

Figure 25. A typical commodity declaration table

Figure 26. A typical process declaration table

Unlike the tables used to declare commodities and processes, the tables used to describe
specific processes are very flexible (~FI_T). They are built using first Row ID column headers
before and below the ~FI_T tag to identify the process names (TechName), descriptions
(TechDesc), commodity inputs (Comm-IN), and commodity outputs (Comm-OUT), as well as
the years of data (Year) when relevant. Then Data column headers after the ~FI_T are used to
describe these processes. The number and arrangement of rows and columns is totally flexible in
these tables. More information about the ~FI_T tables is available in Section2.3.6.
In the first model step, a flexible import table is used to describe the primary supply options
for COA (Figure 27):

 A 3-step domestic coal supply curve through three mining processes (MINCOA*), each
characterized with the cumulative amount of resources available over the modelling
horizon (CUM), the annual cost per unit of energy (COST) and a bound on the annual

35
 production (ACT_BND) for the start year 2005 and the following period 2006. Bounds
need to be combined with the LimType (UP), which is indicated in a specific column in
this example. When not specified, it is UP by default (see Attribute Master Table, Section
2.4.4).
 Import and export options are characterized with the COST and ACT_BND attributes.

*Blue cells are linked to the energy balance.

Figure 27. Description of supply options in a flexible table

3.1.2.4 DemTechs_TPS
This sheet shows how to declare commodities and processes (in their respective tables) and to
describe specific demand processes (in a flexible import table): a demand process to deliver the
total primary supply coal demand, in this example.
A new DEM commodity (TPSCOA -Demand Total Primary Supply – COA) and a new DMD
process (DTPSCOA – Demand technology Total Primary Supply – COA) are declared in the
commodity and process tables (Figure 28), as described in the previous section.

Figure 28. Declaration of demand commodities and processes

A flexible import table is used to describe the demand option for total solid fuels (Figure 29):

 A demand process for the total primary supply of COA (DTPSCOA) is characterized
with an efficiency (EFF), an annual availability factor (AFA), an investment cost
(INVCOST), a fixed operation and maintenance cost (FIXOM), and a technical lifetime
(LIFE). By default this technical lifetime is also used as the economic lifetime, unless a
specific economic lifetime (ELIFE) is defined.

36
 Figure 29. Description of a simple demand processes

3.1.2.5 Demands
This sheet is used to specify the demand (DEMAND) value for the TPSCOA at the base year
2005 (Figure 30). This value comes from the energy balance and represents the total final COA
consumption and the total consumed for energy conversion. This demand is constant over the
time horizon of the analysis due to the default interpolation/extrapolation applied to the attribute
Demand. The future values can be changed by specifying new inputs for the future years/periods.

*Blue cells are linked to the energy balance. Here, the demand value is
equivalent to the sum of Total Conversion plus Total Final consumption.
Figure 30. Definition of base year demand values

3.1.3 Solving the model

The model is solved via the FE Case manager (Basic Functions, Case Manager), explained
more in detail in Section 2.4.5.
For all step models, all cases (runs) are pre-defined by default (Figure 31) with a name and a
description (here, DemoS_001; Demo Step 001), the components to be included in the run
(BASE, SysSettings), the Regions (REG1), the Ending Year (2006), and the Period Defs (Pdef-
1). It is important to note that the BASE component represents all the base year information
included in all B-Y Templates together (only VT_REG_PRI_V01 in this example).
The optimizer options (CPLEX button) and the model variants (Control Panel) are also set
by default. The model can be launched by clicking the SOLVE button. The model will be solved
using the TIMES source code indicated under GAMS Source Code folder and the results files
stored in the folder indicated below GAMS Work folder.

3.1.4 Results analysis in VEDA-BE

The results of a model run in VEDA-FE can be imported into VEDA-BE through the VEDA-
BE menu command Results, Import/Archive.
A results database distributed with the Demo models called DemoS_VBE already contains
pre-defined tables as well as commodity/process sets and all step runs described in this manual.
This database should be pasted into the VEDA-BE/Databases folder. Then it can be opened in
VEDA-BE by selecting Open Database from the File menu and browsing to the VEDA-
BE/Databases/ DemoS_VBE folder.

37
 Figure 31. VEDA-FE Case Manager for submitting model runs

The list of pre-defined tables can be seen under Table definition at the top left of the main
window. To view a particular table, scroll down/up the list and select it, then click the View
Table(s) button. The table will open with a pre-defined layout than can be modified in a very
flexible manner. Not all of the tables can be used for the first demo steps, in which only few
results and information will be available. If a VEDA-BE table is inconsistent or empty you will
get a pop up message saying that table is empty.
For more information on the capabilities and use of VEDA-BE, see Part V of the TIMES
documentation.
The main VEDA-BE tables that can be checked for the first DemoS are:

 __Check Dummy Imports (Figure 32)

Figure 32. __Check Dummy Imports table in VEDA-BE

38
 o In an healthy model this table should be empty. If not, it means the model has
some infeasibilities and is using some dummy technologies (built by default in
VEDA-FE) to satisfy the commodity/demand production.
o This table is built by selecting the attribute VAR_FOUT and the ProcessSet
DUMIMP (this is a user-defined process set).
 _SysCost
o This table (Figure 33), built selecting the attribute Reg_Obj, shows the total
system cost discounted to the G_DYEAR defined in the SysSettings file (in this
example 2005). Figure 34 shows the total system cost in million euros for the
model run to 2006, based on two periods (2005 and 2006) for a total of three
years.

Figure 33. _SysCost table in VEDA-BE

Figure 34. Total system cost in DemoS_001

o The Scenario label shows the scenario name (DemoS_001) for the run we are
viewing, while under the column Region we see the region name (REG1) and the
value of the objective function. The column Total is shows the total by row (over
regions). In this case, we only have the single region REG1, so the value is the
same.
o The _SysCost table provides a key model run indicator. In TIMES models, the
Objective-Function is to minimize the total discounted cost of the system,
properly augmented by the ‘cost’ of lost demand (when using the elastic demand
features). See Parts I and II of the TIMES documentation for more on the model
objective function.

39
 All costs
o This table can be used to show the undiscounted cost elements of the model
solution (Figure 35).

Figure 35. All costs table in VEDA-BE

o The cost elements, each an individual attribute selected in the table definition,
comprise capital costs for investing in and/or dismantling processes (Cost_Inv),
fixed O&M costs (Cost_Fom), activity costs (Cost_Act), flow costs including
import and export prices (Cost_Flo), implied costs of endogenous trade
(Cost_ire), taxes and subsidies (Cost_Flox, Cost_Comx), salvage value of
processes and commodities at the end of the planning horizon (Cost_Salv), and
welfare loss resulting from reduced end-use demands (Cost_Els).
o The undiscounted cost elements (in million euros) that are part of the solution for
this first step for REG1 are shown below (Figure 36).

Figure 36. All system costs results by element

o The attribute column in this case shows both the attribute name and description,
while the Period columns show the value of each attribute in each model period,
except the salvage value (Cost_Salv), which does not take a period index.
 Demands (Figure 37)
o This table is used to show the energy service demand(s). In this case there is only
the single demand called TPSCOA, which is in PJ (Figure 38).

40
 Figure 37. Demands table in VEDA-BE

o The Demands table shows, from left to right, for the scenario DemoS_001, region
REG1, process (or technology) DTPSCOA, a flow out (Var_FOut – production or
output from the process) for the commodity Demand Total Primary Supply –
COA (TPSCOA), the values for the periods 2005 and 2006.

Figure 38. TPSCOA demand

 Fuel Supply (Figure 39)

o This table is built selecting the attribute VAR_FOut (flow out) and the process set
IRE (that includes all the process defined in ~FI_PROCESS tables as MIN, IMP
and EXP). In other words, this table can be used to check the output from all the
processes that belong to import and mining sets. The export process is
characterised with an input and not an output, so it not possible to check the
behavior of the export process by selecting only VAR_FOut.
o The COA demand is met in a significant proportion with imports (6,462.67 PJ)
and the rest with domestic resources through the first two steps of the supply
curve. (The third step is not used, because it has higher COST than the imports,
see Figure 40.) The demand and supply balance of COA is constant between 2005
and 2006, as described above in Section 3.1.2.5.

41
 Figure 39. Fuel Supply table in VEDA-BE

o In this example the marginal technology, that is, the technology that would
produce the next additional unit of the COA commodity, is the import technology.
This information will be reflected in the commodity marginal price for COA,
which will be equal to the production cost of the COA commodity from the
marginal technology.

Figure 40. Fuel Supply results by process and period

 Prices_All
o This table (Figure 41), built selecting the attribute EQ_CombalM, can be used for
showing commodities’ marginal prices in the run.

Figure 41. Marginal prices table in VEDA-BE

42
 o As noted above, the marginal price of COA (solid fuels) is the same as the
production cost from the marginal technology (import of solid fuels). In this
example, it is 2.75 MEuro/PJ in both periods (Figure 42). The marginal price of
TPSCOA (Demand Total Primary Supply – COA) in 2005 depends on the new
capacity investment that must happen in that year to serve the demand. The
marginal price for 2005 can be calculated by taking in account the marginal prices
of the solid fuels commodity, the investment cost of the demand technology, the
operating cost for the demand technology, and finally the salvage cost. In 2006
there isn’t any new investment, so the marginal price will be only a function of
the fuel cost.

Figure 42. Marginal prices results for DemoS_001

3.2 DemoS_002 - More demand options and multiple supply curves

Description. The second step model includes a greater number of supply, demand, import
and export options for additional commodities in a single region over two time periods.
Objective. The objective is to show how to expand the model with more examples of
commodities (energy and emissions) and of typical processes along with their respective
attributes, including emission coefficients. On the supply side, it includes more three-step supply
curves (e.g., for oil & gas in addition to coal), extraction processes, and import and export
options, as well as the introduction of new sector fuel processes (processes used to change fuel
names into sectoral commodity names). The demand side is also expanded with the presentation
of two demands for energy services (residential and transportation) and corresponding end-use
devices in each sector. Emission commodities (e.g. CO2) and emission tracking are also
introduced at the end-use device level in both the residential and transport sectors.

Attributes introduced: Files updated

STOCK VT_REG_PRI_v02
ENV_ACT
START

Files. The second step model is built by modifying the B-Y Template (VT_REG_PRI_V02)
to add processes as well as energy and emission commodities. The SysSettings file is the same as
in the DemoS_001.

43
3.2.1 B-Y Templates
3.2.1.1 EnergyBalance sheet
The energy balance is the same as in the first step although a larger portion is covered in this
second step model (Figure 43). In addition to the primary supply of solid fuels (COA), the model
covers the primary supply of natural gas (GAS) and crude oil (OIL) as well as the demand for
GAS and OIL in the residential and transportation sectors (rather than for the aggregated primary
supply as for COA).
A higher degree of disaggregation is also provided. On the supply side, the same level of
disaggregation as for COA is provided for GAS and OIL, with shares to split the total domestic
production in more than one step. On the demand side, fuel consumption is split by sector and by
end use in the residential sector (space heating, appliances, and other). GAS is allocated at 100%
to the Other end use in the residential sector and OIL at 100% to the single end use D1 in the
transportation sector.

Figure 43. Energy balance at start year 2005 for REG1 – Covered in DemoS_002

3.2.1.2 Pri_COA/GAS/OIL sheets

These new Pri_GAS and the Pri_OIL sheets have exactly the same structure as the Pri_COA
sheet (which has not been modified from the first step) including:

44
  A commodity table to declare additional energy commodities (NRG): GAS - Natural gas
(PJ) and OIL - Crude oil (PJ).
 A process table to declare additional supply options for GAS and OIL: mining processes
(MINGAS* and MINOIL*), import processes (IMPGAS1, IMPOIL1), and export
processes (EXPGAS1, EXPOIL1).
 A flexible import table to describe the primary supply options for GAS and OIL: 3-step
domestic supply curves through three mining processes, as well as import and export
options. All are characterized with the same attributes.

3.2.1.3 Sector_Fuels sheet

This is a new sheet that is used to construct sector fuel processes (FTE-*), which produce
sector fuels from primary fuels, e.g.: GAS becomes RSDGAS and OIL becomes TRAOIL in this
example (Figure 44). This is done to make it easy to track fuel consumption at the sectoral level
as well as to add sectoral emissions (which could be constrained separately). These technologies
can be also used to add additional information on the sectoral commodities, for example
additional costs to simulate a sectoral tariff for GAS or an investment cost to simulate new
investments in infrastructure and so on. The same approach is used to declare the new
commodities and processes in their respective tables.

Figure 44. Introduction of sector fuel processes

3.2.1.4 DemTechs_RSD and DemTechs_TRA sheets

Demand processes (DMD) are introduced in these sheets (Figure 45). They consume an
energy commodity (RSDGAS, TRAOIL) to produce directly the energy service commodity:
residential–other (DROT) and transport (DTD1) in this example. In both sectors, there are
existing (ROTEGAS and TOTEOIL) and new processes (ROTNGAS and TOTNOIL).

 The existing processes are characterized with their existing installed capacity (STOCK),
corresponding in this case to the energy consumption required to produce these energy
services in the base year as given by the energy balance and the additional fuel split
assumptions. They also have an efficiency (EFF), an annual availability factor (AFA) and
a life time (LIFE).
 Existing processes characterised in VEDA B-Y Templates with a base year STOCK can
not increase their capacity endogenously through new investment because when
synchronizing the templates, by default VEDA-FE inserts the attribute NCAP_BND with
interpolation/extrapolation rule number 2, setting an upper bound of EPS (epsilon, or
effectively zero) for all years. (For more information on interpolation/extrapolation see

45
 Table 8 in Section 3.3.2.2) New technologies thus are needed to replace the existing
capacity as it retires or increase the amount of capacity available after the base year.
 The new processes do not have an existing installed capacity, but they are available in the
database to be invested in to replace the existing ones and meet the demand for energy
services. They are characterized with an investment cost (INVCOST), a fixed operation
and maintenance cost (FIXOM), and the year in which they become available (START).
The model can invest in these new technologies only beginning in that START year.
 Finally, emission commodities (ENV) are also introduced along with these processes:
CO2 emissions in the residential (RSDCO2) and the transport (TRACO2) sectors in this
example (in kt). An emission coefficient (ENV_ACT in kt/PJoutput) is provided for each
process based on the technology output. It is also possible to define emissions
coefficients based on fuel input (see Section 3.7.2.7).

Figure 45. End-use demand processes

3.2.1.5 Demands sheet

The demand table is expanded to include the demand for the new energy services created at
this step: residential–other (DROT) and transport (DTD1). The 2005 values come from the
energy balance sheet and then will be constant, as explained in Section 3.1.2.5, until new data is
input for future years.

3.2.2 Results
There are more demands for energy services (Figure 46) and fuel supply options (Figure 47)
in this second step model compared with the first step. Also, a new piece of information
available at this second step is CO2 emissions by sector (Figure 48), which are computed from
the input coefficients provided for each process and the activity of each process. These three
tables can be viewed in the same way as explained for DemoS_001, and if results for both
DemoS_001 and DemoS_002 have been imported, then it will be possible to see and compare
results for the two scenarios.The main findings from the results analysis are:

 The domestic demand for transportation (DTC1) represents the major proportion (44%)
of total domestic demand for energy. This sector relies on oil and also accounts for the

46
 largest part of the CO2 emissions (TRACO2), although no coefficient was provided for
solid fuels combustion emissions.

Figure 46. Results - Demands table for DemoS_002

Figure 47. Results – Fuel Supply table for DemoS_002

 The demand for residential–other (DROT) and transportation (DTC1) is first fully
satisfied with the existing demand processes (ROTEGAS and TOTEOIL) in the base year
2005, but the new demand processes (ROTNGAS and TOTNOIL) start penetrating in
2006. The new processes are more efficient and require less energy to satisfy the demand.
The existing processes satisfy less demand in 2006 because their STOCK in 2006 is
lower than in 2005. The STOCK decreases between the base year value and zero linearly
over the technical LIFE. For example, for ROTEGAS the base (2005) stock is 5486 PJ
and will be zero in 2015 (because the residual technical life is 10 years). The stock value
between 2005 and 2015 is linearly interpolated between 5486 PJ and 0 PJ.
 A large proportion of the oil imported in 2005 is destined to export markets (exports
reach their upper limit because the export price is no higher than that of the marginal oil
supply, the import price), while in 2006 the demand from export markets decreases to

47
 zero and more oil is produced domestically to meet the domestic demand for
transportation oil.

Figure 48. Results – Emissions by Sector table for DemoS_002

Objective-Function = 496 637 M euros (see the _SysCost table in VEDA-BE).

All the system cost components can be seen from the VEDA-BE table All costs. As the
model includes different types of energy commodities, it is relevant to have a look at their
respective marginal prices (Figure 49). Marginal prices of oil are the highest due to higher
production costs and import prices. Marginal (shadow) prices for process activity (Figure 50)
allow us to understand why the third step of the supply curve for fossil fuels (MINCOA3,
MINGAS3, MINOIL3) are not part of the optimal solution, as they are more expensive. For
example the VAR_ActM for MINCOA1 is -0.75. This means that if we relax the upper activity
bound of this technology of by GJ than the objective function will decrease by 0.75 euros, while
forcing the production of 1 GJ from MINCOA3 will increase the objective function by 0.25
euros.
In TIMES, the shadow prices of commodities play a very important diagnostic role. If some
shadow price is clearly out of line (i.e., if it seems much too small or too large compared to
anticipated market prices), this indicates that the database may contain some errors. For instance,
if the shadow price of a commodity is zero and the quantity supplied is non zero, as pointed out
by the second theorem of Linear Programming, it means that there is more supply than demand
for that commodity. The examination of shadow prices is just as important as the analysis of the
quantities produced and consumed of each commodity and of the technological investments.

Figure 49. Results – Prices_Energy table for DemoS_002

48
 Figure 50. Results – marginal process activity prices in DemoS_002

3.3 DemoS_003 - Power sector: basics

Description. The third step model demonstrates the modelling of a simple power sector in a
single region over more than two time periods. From the base year of 2005, the time horizon is
expanded from 2006 to 2020.
Objective. The objective is to show how to model a typical power sector with different types
of power plants (e.g., thermal, nuclear and renewable) along with their respective attributes and
the transmission efficiency of the network. Other objectives are to add more time periods, to
show how to project future demands (e.g. constant or growing), and to explain the powerful
interpolation/extrapolation rules existing in VEDA-TIMES, as well as the difference between
model years and data years.

Attributes introduced: Files updated

COM_IE SysSettings
CAP2ACT VT_REG_PRI_v03

Files. The third step model is built by modifying:

1. the SysSettings file to add more time periods and declare the transmission efficiency of
the electricity network.
2. the B-Y Template (VT_REG_PRI_V03) to model the power sector and insert
interpolation/extrapolation rules.

3.3.1 SysSettings file

3.3.1.1 TimePeriods sheet
The ~TimePeriods table is used to extend the time horizon of the model by adding three
active periods of five years each (Figure 51). These specifications are saved as a new time period

49
definition (Pdef-5). The time horizon is extended to 2020, with the milestones years being 2005,
2006, 2010, 2015 and 2020.

Figure 51. New time periods definition in the SysSettings file

The changes to the period definitions can also be seen within VEDA-FE, by selecting
MileStone Years from the Advanced Functions menu, as shown in Figure 52. In addition to
showing the currently selected definitions, the MileStone years tool can be used to modify the
definition or add a new set of definitions in an easy way. Input desired period lengths in the
yellow area, adding new periods below the currently defined ones as desired. These changes will
be reflected in the period specifications shown on the right. You may then choose to Save and
overwrite the previous definition, or enter a new name in the dropdown menu in the lower left
hand corner of the form to create a new set. These changes will then be reflected in the
SysSettings file.

Figure 52. Milestones years from the new time period definition
With the introduction of the interpolation/extrapolation rules, it is possible to run the model
on a longer time horizon without having to declare data values for all periods up to 2020.

3.3.1.2 Constants sheet

The transformation table is also used to insert a new constant in the model: the transmission
efficiency (COM_IE) for the electricity (ELC) commodity in REG1 (Figure 53).

Figure 53. New constant declarations in the SysSettings file

50
3.3.2 B-Y Templates
3.3.2.1 EnergyBalance sheet
The energy balance is the same as in the second step although a larger portion of it is covered
in this third step model (Figure 54). The energy used for conversion into electricity and the total
electricity generation are now included.

Figure 54. Energy balance at start year 2005 for REG1 – Covered in DemoS_003

3.3.2.2 Pri_COA/GAS/OIL sheets

These sheets were all modified in a similar way to show the use of interpolation/extrapolation
rules in VEDA-TIMES (Figure 55). With the introduction of the interpolation/extrapolation
rules, it is possible to run the model for a longer time horizon without having to declare data
values for all periods up to 2020.
To activate an interpolation/extrapolation (I/E) rule for a specific process, insert a data row
and write a "0" as the Year. In this example, an interpolation/extrapolation rule will be enabled
for the processes MINCOA1, MONCOA2 and EXPCOA1. Then, an interpolation/extrapolation
code is indicated under the attribute. In this example, option 5 will be applied to the activity
bound (ACT_BND) of these processes. The option codes for the interpolation/extrapolation rules
are presented in Table 8. The code 5 means full interpolation and forward extrapolation of the
attribute.
In this example, MINCOA1 has an activity bound of 6074 PJ in the year 2005, and due to the
I/E rule, the 2005 value is kept constant over the time horizon. Just remember that the
ACT_BND is not I/E by default, so when no I/E rule is explicitly specified in the template, the
bound will be applied only to the periods defined in the year column.

51
 Default interpolation/extrapolation mechanisms are embedded in the TIMES code itself (for
more information see Section 3.1.1 of Part II of the TIMES documentation). It is also useful to
check the Attribute Master table in VEDA-FE (see Section 2.4.4) for more information about
which attributes are interpolated/extrapolated by default and which are not.

Figure 55. PRI_COA sheet with interpolation/extrapolation rules

Table 8. Interpolation/extrapolation codes in TIMES

Option Action Applies to
code
0 (or none) Interpolation and extrapolation of data in the default way as predefined in All
TIMES (see below)
<0 No interpolation or extrapolation of data (only valid for non-cost parameters). All
1 Interpolation between data points but no extrapolation. All
2 Interpolation between data points entered, and filling-in all points outside the All
interpolation window with the EPS value.
3 Forced interpolation and both forward and backward extrapolation throughout All
the time horizon.
4 Interpolation and backward extrapolation All
5 Interpolation and forward extrapolation All
10 Migrated interpolation/extrapolation within periods Bounds, RHS
11 Interpolation migrated at end-points, no extrapolation Bounds, RHS
12 Interpolation migrated at ends, extrapolation with EPS Bounds, RHS
14 Interpolation migrated at end, backward extrapolation Bounds, RHS
15 Interpolation migrated at start, forward extrapolation Bounds, RHS
YEAR Log-linear interpolation beyond the specified YEAR, and both forward and All
(≥ 1000) backward extrapolation outside the interpolation window.

3.3.2.3 Pri_RNW and Pri_NUC sheets

As with supply curves for fossil fuels, mining processes are created for the uranium resources
and the renewable potential (Figure 56). They are considered unlimited and at no cost in this
simple example.

52
 Figure 56. Description of new supply options

3.3.2.4 Sector_Fuels sheet

Additional sector fuel processes (FTE-*) are defined and characterized in this sheet, namely
to produce the electricity sector fuels from primary fuels, including fossil fuels (e.g. COA to
ELCCOA) and other sources (e.g. NUC to ELCNUC). The same approach is used to declare the
new commodities and processes in their respective tables.

3.3.2.5 Con_ELC sheet

A series of processes are created to represent different types of power plants (Figure 57).
These are conversion processes that consume electricity sector fuels (ELCGAS, ELCNUC, etc.)
to produce electricity (ELC).

 The existing processes are characterized with their existing installed capacity (STOCK)
in GW (calculated from the information given in the energy balance in terms of energy
consumption for electricity production and technical attribute values). They also have an
efficiency (EFF), an annual availability factor (AFA), fixed and variable O&M costs
(FIXOM, VAROM), a life time (LIFE), and a CO2 emission coefficient (ENV_ACT).
 By default, all attribute values apply to the base year 2005 when not specified. It is
possible to declare any attribute values for future years using the command "~" followed
by the year, as for the installed capacity attribute in this case (STOCK~2030). By default,
an existing installed capacity (STOCK) decreases to zero at the end of its lifetime (e.g.,
after 30 years for ELCTECOA00). By specifying an installed capacity value for 2030, as
for ELCTENUC00, a new retirement profile is defined (constant in this example), and it
is not necessary to specify a life duration.
 The new processes do not have an existing installed capacity, but they are available in the
database to be invested in to replace the existing ones and meet the demand for
electricity. They are characterized in addition with an investment cost (INVCOST) as
well as the year where they become available (START).
 A new attribute is introduced (CAP2ACT) allowing the conversion between the process
capacity and activity units. In this example a coefficient of 31.536 PJ/GW is needed
(1GW * 365 days * 24 hours = 8760 GWh = 31.536 PJ). When not specified and when
both capacity and activity are tracked in the same unit, the CAP2ACT is equal to 1.

53
 The same approach is used to declare the new commodities and processes in their respective
tables (Figure 58) including the declaration of existing and new power plants as ELE processes.
The process names follow a convention where T=thermal, C=CHP, R=Renewable, N=Nuclear.

Figure 57. Existing and new power plants

Figure 58. Declaration of electricity commodities and processes

3.3.2.6 DemTechs_ELC sheet

The total demand for electricity (ELC) is modelled in a simplistic manner as for solids fuels
(COA). A flexible table is used to describe the demand device for electricity (Figure 59):

 A process for the total demand of ELC (DTPSELC) is characterized with an efficiency
(EFF), an annual availability factor (AFA), an investment cost (INVCOST) a fixed
operation and maintenance cost (FIXOM), and a life time (LIFE).

54
 Figure 59. Description of a simple electricity demand processes

3.3.2.7 Demands
The end-use demand table is expanded to include the demand for electricity (TPSELC) in the
base year as well as for future years (Figure 60). While the demand for other fuels or for energy
services will be kept constant over time (extrapolated at a constant level by default), the demand
for electricity is set up to increase by an annual growth rate of 1% through 2020.

Figure 60. Definition of base year and future years demand values

3.3.3 Results
The demands for energy and energy services are extended to the 2020 horizon (Figure 61),
increasing by 1% per year (TPSELC) or remaining constant (all others). The effects of the
interpolation/extrapolation rules applied on the activity bound of certain supply processes can be
seen below (
Figure 62). The activity of the first two mining processes (first two steps of the domestic
supply curves) for fossil fuels (COA, GAS, OIL) is controlled by the annual activity bound (set
constant for each period by the interpolation rule) and the cumulative bound (CUM). The
combination of these two conditions leads to a significant increase in imports to meet the
growing demand for energy. Exports are also kept constant using the same
interpolation/extrapolation rules. More primary supply options exist now with the addition of the
electric fuels such as nuclear and renewables.
Results from the new electricity sector are introduced (Figure 63 and Figure 64). The total
generating installed capacity increases from 466.3 GW in 2005 to 541.6 GW in 2020. Most of
this increase is coming from new coal-fired power plants (ELCTNCOA00), the most expensive
process but the least expensive fuel. The installed capacity of nuclear and renewable power
plants remain constant as specified in the B-Y Template. Electricity production is coming mainly
from fossil fuels (64%), with a smaller contribution from nuclear (26%) and renewables (9%).
The oil plants are working only in the base year, as calibrated to the energy balance, because the
fuel is too expensive compared to the other available options.

55
Figure 61. Results – demand for energy services in DemoS_003

Figure 62. Results – fuel supply options in DemoS_003

Figure 63. Results – electricity capacity in DemoS_003

56
 Figure 64. Results – electricity activity in DemoS_003

Objective-Function = 3,185,019 M euros (see the _SysCost table in VEDA-BE). This cost is
significantly higher compared to the optimal cost obtained with DemoS_002 because of the
addition of the electricity sector. All the system cost components can be seen in the VEDA-BE
table All costs, as well as the marginal fuel prices in Price_Energy and the process activity in
Process Marginals.

3.4 DemoS_004 - Power sector: sophistication

Description. The fourth step model expands the modelling to a more sophisticated power
sector in the same single region over the 2020 horizon.
Objective. The objective is to introduce the concepts of time slices, peak, and peak reserve
capacity. Time slices are added to the model to adequately capture the timing of the electricity
demand, and the peak reserve capacity requirement is illustrated through scenario variants, with
and without peak reserve capacity factor. This step model is also used to show how
interpolation/extrapolation specifications can be moved to the SysSettings file and applied to all
instances of an attribute in the model using a single declaration.

Attributes introduced: Files updated

PEAK SysSettings
COM_FR VT_REG_PRI_v04
COM_PEAK Files created
COM_PKRSV Scen_Peak_RSV
COM_PKFLX Scen_Peak_RSV-FLX

Files. The forth step model is built:

1. by modifying the SysSettings file to add new time slices and to insert default
interpolation/extrapolation options;
2. by modifying the B-Y Template (VT_REG_PRI_V04) to declare the contribution of
power plants to the peak and add the load curve of electricity demand;
3. by creating scenario files to illustrate the peak reserve capacity requirement (Figure 65).

57
 Figure 65. The files included in DemoS_004

3.4.1 SysSettings file

3.4.1.1 Region-Time Slices
The ~TimeSlices table is used to create four time slices (Figure 66) and replace the previous
single ANNUAL time slice. There are four time slices combining two seasons (W- Winter and S-
Summer) and two intraday periods or day-night periods (D- Day and N- Night).

Figure 66. New time slices definition in the SysSettings file

3.4.1.2 Interpol_Extrapol_Defaults
A table is added for setting the default interpolation/extrapolation rules (Figure 67). A
transformation table used to update pre-existing data (~TFM_UPD) in a rule-based manner, it
sets the default interpolation/extrapolation rule, indicated by the 0 in the Year column, for the
attribute defined in the Attribute column and all the processes defined in the model. In this case,
this is the same interpolation/extrapolation rule used for each of the supply processes (see Figure
30) in the B-Y Template. It is now moved into the SysSettings file and applied to the activity
bound (ACT_BND) of all processes at once.

58
 Figure 67. Default table for interpolation/extrapolation rules in the SysSettings file

3.4.1.3 Constants
The existing transformation table is also used to insert new constants in the model: fractions
of year for the new time slices (YRFR) replace the single ANNUAL time slice (100%) as
declared in the previous steps (Figure 68). The timeslice name is identified in the first column
(TimeSlice), while their fractions (for the attribute called YRFR) over one year are declared for
AllRegions as for the other constants of the model. The fraction values, as with any other input
in the model, are the user’s responsibility. In this case, it is important that they sum to 100%.

Figure 68. New time slice declarations in the SysSettings file

3.4.2 B-Y Templates

3.4.2.1 Con_ELC
A new attribute is declared for all existing and new processes representing power plants
(Figure 69):

 Their contribution to peak (Peak), i.e., the fraction of a process’s capacity that is
considered to be secure and thus will most likely be available to contribute to the peak
(and reserve capacity) load in the highest demand time-slice of a year for a commodity
(electricity or heat only). In this case, the capacity contribution of all thermal and nuclear
power plants is 100%, while the capacity contribution of the renewable power plant is
50%. Indeed, many types of supply processes can be regarded as predictably available
with their entire capacity contributing during the peak and thus have a peak coefficient
equal to 1 (100%), whereas others (such as wind turbines or solar plants) are attributed a
peak coefficient less than 1 (100%), since they are on average only fractionally available
at peak. (E.g., a wind turbine typically has a peak coefficient of 0.25 or 0.3 maximum).

Another important change to mention is the start year of one new process (ELCTNOIL00)
that can be installed from the 2005 base year to cover the additional capacity needed for the
reserve equation (5%), as defined in the scenario files.

59
 Figure 69. Peak contribution for different types of power plants

Additional information is required to complete the declaration of the electricity commodity

and processes in their respective tables (Figure 70 and Figure 71). Along with the new time
slices, it is possible to specify the tracking level of the electricity commodity (ELC) in the
CTSLvl column: DAYNITE. (When not specified, as in the previous step, the default is
ANNUAL.) PeakTS (peak time slice monitoring) directs TIMES to generate the peak equation
for the specified time slices. It is possible to declare any of the time slices defined in the
SysSettings file, or ANNUAL (the default) to generate the peaking equation for all time slices.
Since it is left blank here, the peak equation will be generated in all time slices once it has been
requested using COM_Peak (see Section 3.4.3.1). Finally, it is important that the user enter ELC
in the Ctype column when declaring an electricity commodity that may be produced by
combined heat and power (CHP) plants, as this commodity will be in DemoS_009.
For the electricity processes, the process table is used to define the time slice level of
operation in the Tslvl column (Figure 71). For example, the coal-fired and the nuclear power
plants are defined at the SEASON time slice level, meaning that their operational level does not
vary across DAYNITE time slices. (When not specified, the default is based on the Sets
declaration: DAYNITE (for ELE), SEASON (for CHP and HPL) ANNUAL (for all others).)

Figure 70. Declaration of time slice level for electricity commodity

60
 Figure 71. Declaration of time slice operational level for processes

3.4.2.2 Pri_COA/GAS/OIL
These sheets were all modified back to remove the interpolation/extrapolation rules: the flag
to activate an interpolation/extrapolation rule (additional rows with a "0" as the Year) and the
rule code in the attribute column.

3.4.2.3 Demands
A table is added to define the load curve of the demand for electricity (TPSELC) in the base
year, which will also apply for future years (Figure 72). The attribute (COM_FR) is introduced
to declare the fraction of the electricity demand occurring in each time slice.

Figure 72. Definition of load curve for the electricity demand

The TPSELC commodity is the demand commodity produced by a demand technology (end-
use technology) called DTPSELC (Figure 73) and defined in the sheet DemTechs_ELC. This
technology takes as input the ELC commodity that will be consumed by timeslice as defined by
the COM_FR attribute for TPSELC.

Figure 73. Demand technology producing DTPSELC

61
3.4.3 Scenario files
3.4.3.1 Scen_Peak_RSV and Scen_Peak_RSV-FLX
Two scenario files are created to insert new information in the RES that can be retained or
not in the configuration of the model at the time of solving the model (see Section 2.4.5). A
transformation table ~TFM_INS is used to declare new attributes (Figure 74):

 COM_Peak - Specify that the peaking equation will be generated for the ELC
commodity.
 COM_PKRSV - Declare the capacity fraction (%) that is required for the peak reserve.
This is the option used in the first scenario file (Peak_RSV).
 COM_PKFLX - Declare the fraction (%) by which the actual peak demand exceeds the
average calculated demand, by time slice. This is the option used in the second scenario
file (Peak_RSV- FLX) for the Summer-Day time slice (SD), although in practice
COM_PKFLX is typically used alongside COM_PKRSV.

The TIMES peak equation allows the user to require that the total capacity of all processes
producing a commodity at each time period and in each region exceed, by a certain percentage,
the average demand in the time-slice when the highest demand occurs. This peak reserve factor
(COM_PKRSV) insures against several contingencies, such as possible commodity shortfall due
to uncertainty regarding its supply (e.g. water availability in a reservoir), unplanned equipment
down time, and random peak demand that exceeds the average demand during the time-slice
when the peak occurs. This constraint is therefore akin to a safety margin to protect against
random events not explicitly represented in the model. Optionally, COM_PKFLX can be used to
reflect the fact that the actual system peak demand is greater than the average demand in the
model’s peak slice, allowing COM_PKRSV to represent a more typical utility reserve margin.

Figure 74. Declaration of the peak reserve in a scenario file

3.4.4 Results
Three cases are solved with this step model, with a different selection of scenario files
(Figure 75): the DemoS_004 case is solved using only the two components (BASE, SysSettings),
while the DemoS_004a case is solved adding one scenario file (Peak_RSV), and the
DemoS_004b case is solved adding the other scenario file (Peak_RSV-FLX). The different cases
can be loaded in the FE Case Manager using the Select menu. Choosing the Single option will
solve each case individually, while choosing the Batch option will launch multiple cases
simultaneously (i.e., the cases will be launched automatically by VEDA-FE one after the other).

62
 Figure 75. Solving different cases using different scenario files

The impacts of the improvements made in the electricity sector on the electricity generating
capacity are shown in Figure 76, namely.

 The effect of adding new time slices and of specifying the seasonal operational level for
the coal-fired power plant in DemoS_004, compared with DemoS_003: there is a switch
from coal-fired generation to natural gas-fired generation due to its greater flexibility
(time slice level DAYNITE for gas, as opposed to SEASON for coal) to satisfy the
electricity demand. The additional natural gas supply is coming from import sources.
 The effect of declaring a peak reserve factor on the total capacity in DemoS_004a,
compared with DemoS_004: there is additional capacity required that is coming from oil-
fired power plants as new power plants are available from 2005. The total capacity in
DemoS_004a is increasing from 507 GW in 2005 to 659 GW in 2020 (compared with
466 GW to 542 GW without the peak reserve requirement).
 There is no effect on the generating capacity in DemoS_004b, compared with
DemoS_004a.

The electricity price varies across years and time slices (Figure 77).

63
 Figure 76. Results – electricity generation capacity in DemoS_004

Figure 77. Results – electricity price by time slice in DemoS_004

Other interesting results to show are related to the peak contribution specifically (Figure 78).
The peak equation expresses that the available capacity must exceed demand for the electricity
(ELC) commodity in any time slice by a certain margin, so the dual value of the peak equation
describes the premium consumers have to pay in addition to the commodity price (dual value of
EQ_COMBAL) during the peak time slice (SD in this case) to ensure adequate system capacity.
The peak marginal is similar, though not identical, when using COM_PKRSV and
COM_PKFLX, owing to the differences in how they are applied in the TIMES equations.

64
 Figure 78. Results – Dual values of the peak equations in DemoS_004

Objective-Function = 3,187,361 M euros (see the _SysCost table in VEDA-BE). This cost is
only slightly higher with the peak reserve requirement and the additional investments in
generating capacity: 3,211,296 M euros.

3.5 DemoS_005 - 2-region model with endogenous trade: compact approach

Description. At the fifth step, the model evolves from being a single region model to become
a compact multi-regional model (2 or more regions in the same set of B-Y Templates). This
approach is relevant when all the model regions are under the control of a single individual.
Objective. The objective is to create the multi-regional model framework typical to larger or
more complex models, namely the trade matrix that allows the modelling of energy trade
movements (uni-directional or bi-directional trade between two regions). Another objective is to
demonstrate how to limit emissions from a sector in a particular region or from the entire energy
system of all regions through emission bounds or user constraints. Scenario variants illustrate the
impact of a cap on CO2 emissions from the electricity sector only and of a cross-region user
constraint on the total CO2 emissions from the transport and electricity sectors.

Attributes introduced: Files updated

COM_BNDNET SysSettings
UC_RHSRTS VT_REG_PRI_v05
UC_COMNET Files created
Scen_TRADE_PARAM
Scen_ELC_CO2_BOUND
Scen_UC_CO2BND
Files removed
Scen_Peak_RSV-FLX

Files. The fifth step model is built:

1. by modifying the SysSettings file to add one region;
2. by modifying the B-Y Template (VT_REG_PRI_V05) to disaggregate the energy balance
between two regions and to regionalize some process attributes;

65
 3. by creating trade files to capture the trade movements between the two regions;
4. by creating more scenario files to limit GHG emissions (Figure 79).

Figure 79. The files included in DemoS_005

3.5.1 SysSettings file

3.5.1.1 Region-Time Slices
The ~BookRegions_Map table is used to create one additional region: REG2 (Figure 80) in
the same workbook (REG).

Figure 80. New region definition in the SysSettings file

3.5.2 B-Y Templates

3.5.2.1 EnergyBalance, EB1, EB2
The energy balance is disaggregated between two regions (Figure 81) using shares on
production, conversion, and final consumption of various energy commodities: REG1 becomes
producer and consumer of solid fuels (100%), crude oil (30%) and renewable energies (100%),
while REG2 becomes producer and consumer of natural gas (100%), crude oil (70%), and
nuclear energy (100%). The same portion of the energy balance as in the fourth step is used in
this fifth step model.

66
 Figure 81. Energy balance at start year 2005 for REG1 & REG 2–Covered in DemoS_005

3.5.2.2 Pri_COA/GAS/OIL
These sheets are updated to include two regions and to regionalize some process attributes.
There are several ways of accounting for the regionalization of some attributes. For instance, it is
possible to insert a Region column on the left side of any ~FI_T table and to indicate in which
region(s) the process is available (Figure 82). A process can be available in only one region (e.g.
MINGAS* and IMPGAS1) or in several regions (EXPGAS1). In this later case, different rows
can be inserted to declare different values for some of the attributes (ACT_BND of EXPGAS1);

67
the values that remain on the initial row will apply to all regions (COST of EXPGAS1). The
additional rows approach is mainly used when all attributes of a process vary across regions.
In the process table (~FI_ Process), the region where each process is available can be
specified (Figure 83): MINGAS* and IMPGAS1 processes exist only in REG2, while the
EXPGAS1 process exists in both regions (by default, when the Region column is empty, it
applies to all regions). Comma-separated entries are also allowed, for instance, when a process
exists in more than one region but not in all regions.

Figure 82. Regionalization of process attributes using additional rows

Figure 83. Region specification in the default process table

3.5.2.3 Con_ELC
This sheet is also updated to include two regions and to regionalize some process attributes.
However, a different approach is used (Figure 84): columns are inserted (duplicated) only for
those attributes that vary across regions: the STOCK attribute in this example. As for the year,
the regions are identified using the " ~ " command after the attribute. The additional columns
approach is mainly used when only few attributes of a process vary across regions.
The column approach is also used in the following sheets, namely for the STOCK attribute:
Sector_Fuels, DemTechs_TPS, DemTechs_ELC, DemTechs_RSD and DemTechs_TRA. The
row approach is used in the Demand sheet.

3.5.3 Trade files

Two trade files are created to model the energy trade movements between the two regions.

68
 Figure 84. Regionalization of process attributes using additional columns

3.5.3.1 Scen_Trade_Links
The ~ TradeLinks tables are used to declare the traded commodities and their links between
regions (Figure 85): either bilateral links between regions (e.g. ELC trade between REG 1
(importer/exporter) and REG2 (importer/exporter) or unilateral links between regions (e.g. GAS
trade between REG 1 (importer) and REG2 (exporter). For each link declared (1=active links),
VEDA-FE will automatically create an IRE (inter-regional trade) process to which attributes may
then be associated (e.g., bounds, investment costs, etc.). The naming convention for IRE
processes is:

 Bilateral trade: TB_<fuel name>_<exporter region>_<importer region>_<01> (e.g.

TB_ELC_REG1_REG2_01)
 Unilateral trade: TU_<fuel name>_<exporter region>_<importer region>_<01> (e.g.
TU_GAS_REG2_REG1_01)

Figure 85. Examples of trade matrix for bilateral and unilateral links

3.5.3.2 Scen_Trade_Param
In this file, a transformation table ~TFM_INS is used to insert new attributes for trade
processes (Figure 86), for example: an investment cost (INVCOST) for all unilateral trade
processes (TU_*). Trade processes are created automatically after the user declares unilateral or
bilateral links between regions in the _Trade_Links file.

Figure 86. Declaration of attributes for IRE processes

69
3.5.4 Scenario files
Two more scenario files are created to insert new information in the RES that can be retained
or not in the configuration of the model at the time of solving the model. Of the previous
scenario files, only the Scen_Peak_RSV file is retained for further analysis.

3.5.4.1 Scen_ELC_CO2_Bound
This file is used to introduce a bound (limit) on the CO2 emissions from the power sector in
REG1. A transformation table ~TFM_INS is used (Figure 87) to declare an upper bound on
annual emissions (Attribute = COM_BNDNET; LimType = UP), on the CO2 emissions from the
electricity sector only (ELCCO2) in REG1. In this example the upper bound is calculated as a
percentage reduction target from the power sector CO2 emissions in a reference scenario for
2010 (10% = 993,548 kt) and 2020 (20% = 1,017,340 kt). It is necessary to run the step model
without any limit on emissions first to get the reference emission trajectory (run DemoS_005)
and to calculate the bounds as a reduction target from the reference emissions. An interpolation
rule is used with the "0" flag in the Year column and the interpolation/extrapolation option in the
region column where the bounds are declared. The code 5 means full interpolation and forward
extrapolation.

Figure 87. Declaration of emission bounds for the power sector

3.5.4.2 Scen_UCCO2_BND – user constraint

This file shows another way used to introduce bounds (limits) on the CO2 emissions from
both the power and the transportation sectors in each region (REG1 and REG2). The idea is to
build a user constraint (Figure 88) that specifies the maximum amount of emissions in a specific
year for the sum of TRACO2 and ELCCO2 emission commodities.
These upper bounds (or limits) are again calculated as a percentage reduction target from the
CO2 emissions (sum in kt) of the power and the transportation sector in a reference scenario for
2010 (10%) and 2020 (20%). It is necessary to run the step model without any limit on emissions
first to get the reference emission trajectory (run DemoS_005) and to calculate the bounds as a
reduction target from the reference emissions.

Figure 88. Declaration of emission bounds using a user constraint

The UC scenario template is set up as described in Section 2.3.8. The sets declarations above
the table indicate:

70
 ~UC_Sets: R_E: AllRegions: The constraints are to be applied to all regions in the model,
individually (E=each). That is, the bounds imposed for REG1 and REG2 are separate, and
there is no emissions trading between regions.
 ~UC_Sets: T_E: The constraints are imposed to each time period individually. There is no
banking or borrowing between periods.

The table level declaration following the table tag (~UC_T:UC_RHSRTS) indicates that any
column without an index will be interpreted as the right hand side of the constraint, in this case,
the indicated bounds in REG1 and REG2 in the given years. This right hand side bounds 1 times
the net production (UC_COMNET) of the sum of TRACO2 and ELCCO2. The
interpolation/extrapolation option 5 indicates full interpolation and forward extrapolation.

3.5.5 Results
Three cases are solved with this step model, with a different selection of scenario files: the
DemoS_005 case is solved without any limit on CO2 emissions and using only the three main
components (BASE, TRADE_PARAM, SysSettings), while the DemoS_005a case is solved
adding one scenario file (ELC_CO2_BOUND) to put a limit on CO2 emissions from the REG1
power sector, and the DemoS_005b case is solved adding the other scenario file
(UC_CO2_BND) to put a limit on both the power and the transportation sectors in both regions.
A first sample of results shows the different configuration of the energy supply systems in the
two regions (Figure 89). As mentioned earlier, the REG1 becomes the main provider of solid
fuels, renewable energies and some crude oil (from both domestic production and imports).
REG1 is also getting electricity from REG2. REG2 becomes the main provider of natural gas,
nuclear energy and some crude oil (from both domestic production and imports).

Figure 89. Results – fuel supply options for both regions in DemoS_005

A second sample of results shows the evolution of the emissions in the different sectors of the
two regions (Figure 90):

71
  Emissions from the power and the transportation sectors as projected in the DemoS_005
case were used to compute the emissions limits in the other two cases.
 A limit on the CO2 from the power sector in REG1 (DemoS_005a) leads to a lower
electricity production from solid fuels, and an emission increase in REG2, which
produces more electricity from natural gas to supply REG1 (Figure 91).
 With a limit on the CO2 from both the power and the transportation sector in REG1 and
in REG2 (DemoS_005b), all the emission reductions are coming from the power sector in
both regions. Emissions from the transportation sector are not affected compared with the
reference case (DemoS_005) meaning that the power sector of both regions could provide
enough reduction options at a lower cost to meet the target. Because there is no trading in
emissions between regions, REG2 must cut back on its electricity generation from natural
gas, and it begins importing natural gas-fired electricity from REG1, which in turn
imports natural gas from REG2 (Figure 91).

Figure 90. Results – emissions by sector and by region in DemoS_005

Finally, the marginal price of CO2 (i.e. the price to pay in euros to reduce the last ton of CO2
to meet the reduction targets) in both scenarios with limits on emissions is particularly relevant
and represents the level of tax that would be necessary to achieve the reduction targets that are
prescribed in the scenario files (Figure 92).

72
 Figure 91. Results – endogenous trades in DemoS_005

Figure 92. Results – emissions by sector and by region in DemoS_005

Objective-Function = 3,204,949 M euros (see the _SysCost table in VEDA-BE) with

1,225,688 M euros for REG1 and 1,979,261 M euros for REG2. This cost is less than 0.1%
higher with the emission limits for the power sector (3,206,161 M euros) and 1.4% higher with
the emission limits for the power and the transportation sectors (3,250,281 M euros). More
details about the impacts of the emission limits on the different cost components of the system in
each region are shown below (Figure 93).

73
 Figure 93. Results – emissions by sector and by region in DemoS_005

3.6 DemoS_006 - Multi-region with separate regional templates

Description. At the sixth step, the configuration of the multi-regional model developed
previously shifts from a single set of B-Y Templates for all regions to a separate sets of B-Y
Templates for each region. This approach is relevant when the model regions are under the
control of more than one individual.
Objective. The objective is again to create the multi-regional model framework typical to
larger or more complex models, with the trade matrix and limits on emissions of all regions, but
additionally to introduce the concept of technology repositories (i.e., SubRES) that include a
number of new processes (in competition) that are available in the database to replace the
existing ones at the end of their lifetime or to meet an increasing demand.
The motivation behind these repositories is mainly to avoid repeating the new process
specifications for each region; all attributes specifications apply to all regions unless a
transformation file is used to regionalize some values when necessary.
Simultaneously, the role of the vintage feature is illustrated to handle processes for which
characteristics change over time (other than investment cost) when new capacity is built. As in
step 5, the scenario variants illustrate the impact of a cap on CO2 emissions from the electricity
sector only and of a cross-region user constraint on the total CO2 emissions from the transport
and electricity sectors.

Attributes introduced: Files updated

N.A. SysSettings

74
 Files created
SubRES_NewTechs
VT_REG1_PRI_v06
VT_REG2_PRI_v06
Files replaced
VT_REG1_PRI_v05

Files. The sixth step model is built 1) by modifying the SysSettings file to add one B-Y
Template, 2) by replacing the B-Y Template (VT_REG_PRI_V05) by two B-Y Template
(VT_REG1_PRI_v06, VT_REG2_PRI_v06) to disaggregate the energy balance between two
regions in two separate files, and 3) by creating a SubRES file to add new processes to the model
(Figure 94).

Figure 94. The files included in DemoS_006

3.6.1 SysSettings file

3.6.1.1 Region-Time Slices
The ~BookRegions_Map table is used to create one additional workbook: one for each region
REG1 and REG2 (Figure 95).

75
 Figure 95. New workbook name definitions in the SysSettings file

3.6.2 B-Y Templates

The structure of the two B-Y Templates (VT_REG1_PRI_v06 and VT_REG2_PRI_v06) is
identical to the structure of the B-Y Template of the fourth step model and uses the same energy
balances defined in the fifth step model for REG1 and REG2 respectively. There is no change to
report, except that new power plants are moved from the B-Y Template to the new process
repository.

3.6.3 SubRES_NewTechs
Two files are created to add new processes in the model, the SubRES and SubRES_Trans
files. The SubRES file is a repository of new processes available for all regions. In the SubRES,
by default, all attribute specifications apply to all regions. This approach is convenient for
models with multiple regions because a single set of declarations can be made for all regions.
The SubRES file includes one sheet for each sector: PRI_ELC, PRI_RSD, PRI_TRA,
PRI_FuelSec. (Due to the way SubRES are processed in VEDA-FE, it is required that the name
of each sheet start with a valid name of one of the model sectors, as defined in the names of the
B-Y templates. In this case, PRI is the only such model sector, and so all sheets in the SubRES
template begin with PRI_.)
With this approach, the B-Y Templates now include only processes with existing capacity in
the base year 2005, and all new processes are defined in the SubRES. Duplicate definition should
be avoided. The new power plants are now declared in this file without any regional specification
(Figure 96). Other new processes are created in the other sheets following the same rules: new
processes do not have an existing installed capacity, but they are characterized with an
investment cost (INVCOST) as well as the year where they become available (START).
The role of the vintage feature is illustrated to handle processes for which characteristics
other than investment cost change over time when new capacity is built., In this example, the
new gas-fired power plant (ELCTNGAS00) has its efficiency and emission coefficient evolving
between 2006 and 2020. The process ELCTNGAS00 is vintaged (Vintage=Yes) in the
~FI_Process table (Figure 97).

Figure 96. Example of new processes in the SubRES file

76
 Figure 97. Example of a new process with vintage tracking in the SubRES file

3.6.3.1 SubRES_NewTechs_Trans
For each SubRES_<user-name> file, there is an associated SubRES_<user-name>_Trans file.
The transformation files contain the mapping and transformation operations that control the
inheritance (or not) of new processes into the various regions of the model, as well as to change
any process characteristics, such as investment costs, by region. In this example, the file is
empty, so all new processes in the SubRES are available in both regions with identical
characteristics.

3.6.4 Results
The results are very similar to those obtained with the previous step model since most of the
changes occurred in the way the information is structured in different files rather than in the
energy system itself. However, the impact of the vintage feature for the new gas-fired power
plants is illustrated (Figure 98).

Figure 98. Results – fuel supply options for both regions in DemoS_005

Objective-Function = 3,205,281 M euros (see the _SysCost table in VEDA-BE) with

1,293,017 M euros for REG1 and 1,912,264 M euros for REG2. These costs are similar to those
computed with the previous step model DemoS_005.

3.7 DemoS_007 – Adding complexity

Description. The seventh step model is enhanced to capture more components of the energy
balance, leading to a more comprehensive representation of the RES with more complex
processes.
Objectives. The objective is to show how to model a more comprehensive RES covering
more details of the energy balance with more complex processes along its two dimensions:
number of commodities and the number of transformation steps in the whole supply-demand

77
chain. In this step refined petroleum products are broken out into different commodities (e.g.,
gasoline, diesel, heavy fuel, etc.) to better describe the transport sector, where different types of
vehicles are introduced. This enhancement of the RES requires the modelling of additional and
more complex processes (e.g., refineries and dual demand cars) and the need to introduce the
primary commodity group (PCG) concept.
Several more techniques are also introduced in this step:

 We present an easier way to account for combustion-based emissions, by directly linking

emission coefficients with each unit of fuel burnt.
 We illustrate how to build end-use demand projections starting from base year values and
different growth rates. This is done using the fill table feature to grab base year
information from the initial files (e.g. B-Y Templates).
 We show how to build a user constraint that specific the minimum (or maximum) annual
growth rate for a set of processes using the CAP, GROWTH attribute.
 Finally, we demonstrate how to use the elastic demand feature of TIMES, including how
to generate the file containing the demand prices for base scenarios and how to use these
prices for the constrained scenarios.

Attributes introduced: Files updated

Share SysSettings
ACTFLO VT_REG1_PRI_v07
COM_VOC VT_REG2_PRI_v07
COM_STEP SubRES_NewTechs
COM_ELAST Files created
UC_CAP Scen_DemProj_DTCAR
Scen_Refinery
Scen_ElasticDem
Scen_TRA_CO2_BOUND
Scen_UC Growth

Files. The seventh step model is built:

1. by modifying the SysSettings file to add interpolation rules;
2. by modifying the two B-Y Template (VT_REG1_PRI_v07, VT_REG2_PRI_v07) and the
SubRES file (SubRES_NewTechs) to add more commodities, more complex processes,
and emission coefficients, and to introduce the PCG concept;
3. by creating a scenario file to project demand from base year values;
4. by creating a scenario file to update refinery attributes;
5. by creating a scenario file to include price-elasticities for demands;
6. by creating a scenario file with a limit on emissions from the transportation sector;
7. by creating a scenario file with a user constraint on growth rates of new cars (Figure 99).

78
 Figure 99. The files included in DemoS_007

3.7.1 SysSettings file

3.7.1.1 Interpol_Extrapol_Defaults
More interpolation/extrapolation rules are added to the transformation table (Figure 100). The
same interpolation/extrapolation rule (number 5) is also used for the maximum input shares
(Share-I) and the maximum output shares (Share-O) of all processes at once. These new
attributes are defined in the next section.

Figure 100. Updated table for interpolation/extrapolation rules in the SysSettings file

3.7.2 B-Y Templates

3.7.2.1 EnergyBalance
At this step, the energy balance is disaggregated and includes a larger number of
commodities. The crude oil category is disaggregated to track all refined products independently
(Figure 101) to better describe the transport sector where different types of cars are introduced. A
larger portion of the energy balance is covered in terms of the number of commodities and also

79
of the number of transformation steps in the whole supply-demand chain, with the addition of the
refining step.

Figure 101. Disaggregated energy balance at start year 2005 for REG2 – Covered in
DemoS_007

3.7.2.2 Con_REF – primary commodity group definition

A flexible refinery (REFEOIL00) is introduced in this sheet (Figure 102) to convert crude oil
(OIL) into refined products (DSL, KER, LPG, GSL, etc.) that will be used in the transportation
sector.

 The existing refinery is characterized with an efficiency (EFF) and an annual activity
bound (ACT_BND) equivalent to the sum of the refined products produced at base year
2005 as given in the energy balance. In this example the efficiency is represented by the
ratio of the crude oil in input to the refinery on the sum of the petroleum products in
output. For this reason we get an efficiency greater than 1. This behaviour depends on the
definition of the commodity group of a technology (see below for more details).
 This more complex process with multiple outputs commodities is also characterized with
a new attribute: the maximum share for each commodity output in the total production
(Share-O~UP). In this example, the maximum shares for all outputs sum to 100%,
meaning that they are equivalent to fixed shares. It would be possible to have a sum of
maximum shares greater than 100%, leaving some flexibility to the model to optimize the
output mix.

The same approach is used to declare the new commodities and processes in their definition
tables, where the refinery is declared as a PRE process, and the concept of Primary Commodity
Group (PCG) is introduced (Figure 103). The activity of a standard process is equal to the sum of
the commodity flow(s) on either the input side or the output side of a process, as defined by the
PCG. The activity of a process is limited by the available capacity, so that the activity variable
establishes a link between the installed capacity of a process and the maximum possible
commodity flows entering or leaving the process during a year or a subdivision of a year.

80
 Figure 102. Refinery

In a simple process, one consuming a single commodity and producing a single commodity,
the modeler simply chooses one of these two flows to define the activity, and thereby the process
normalization (input or output). In complex processes, with several commodities (perhaps of
different types) as inputs and/or outputs, the definition of the activity variable requires
designation of the PCG to serve as the activity-defining group. The PCG is defined as a subset of
the commodities of the same nature entering or leaving a process. For instance, the PCG may be
the group of energy carriers, or the group of materials of a given type, on either the input or
output side of the process. More about PCGs and their use can be found in Section 2.2.1 of Part
II of the TIMES documentation.
VEDA-FE establishes default PCGs for any process involving multiple inputs and/or outputs,
based upon the assumption first that all processes are output normalized and then according to
the commodities’ nature. In case of different commodity types on the output (or input) side, the
default PCG is based on the following order:

 DEM
 MAT
 NRG
 ENV
 FIN

However, in some cases it is desirable/necessary to override these defaults, for instance to

normalize a process with energy commodities inputs (NRGI) as for the refinery in this example.
Indeed, the activity of a refinery is usually characterized based on the barrels of crude oil
consumed.

Figure 103. Overwrite default PCG for the refinery

81
3.7.2.3 Pri_PP
Import and export options for all refined petroleum products were added in this sheet; they
are characterized with the COST and ACT_BND attributes as for any other primary fuels (solid
fuels, natural gas, crude oil) (Figure 104). Note that by convention, the export prices are
generally be slightly less than import prices, to avoid the model importing just to export.

3.7.2.4 Sector_Fuels
Additional sector fuel processes (FTE-*) are defined and characterized in this sheet (Figure
105), namely to produce the transportation sector fuels from primary refined products (e.g. GSL
to TRAGSL). It is not always relevant to keep track of all primary fuels in a sector; multiple
primary fuels can be aggregated into a single sector fuel in this case. In this example, several
refined products are aggregated into a single electricity sector fuel (via FTE-ELCOIL). When
more than one primary fuel are used to create one sector fuel, the shares of input fuels (Share-
I~UP) need to be provided. As with Share-O, the maximum input shares may sum to greater than
100%, if desired, to provide some process flexibility.

Figure 104. Imports and exports of refined petroleum products

Figure 105. Additional sector fuel processes with multiple inputs

82
3.7.2.5 DemTechs_TRA
The single demand process consuming an energy commodity (TRAOIL) and producing
directly the transport demand commodity (DTD1) is replaced with more sophisticated processes
representing cars and characterized with non-energy units (Figure 106). The declaration of these
processes is shown below (Figure 107): their activity units are in billions passengers-kilometres
(BpK) rather than PJ, and their capacity units are in thousands of units (000_units) rather than
PJa.

 The existing processes are characterized with their existing installed capacity (STOCK)
in thousands of car units (000_units) as indicated above. The stock values correspond to
the amount of fuel consumption (e.g. TRADSL) required to produce the transportation
demand (DTCAR) as given by the energy balance and taking into account the efficiency
(EFF), the annual availability factor (AFA) and the conversion between capacity unit and
activity unit (CAP2ACT).
 The efficiency (EFF) is specified in terms of billions of vehicle-kilometres per petajoule
(BVkm/PJ), and can be interpreted as the number of kilometres a vehicle can travel with
1 PJ of energy.
 The annual availability factor (AFA) represents the average thousand kilometres ('000
km) a car is traveling each year.
 A new attribute is introduced to capture the relation between the process activity and the
commodity flow (ACTFLO), the commodity being the output demand, in terms of
passengers per car unit (Passenger/Car). This TIMES parameter requires an additional
index that is the specification of the commodity group: DEMO (demand out) in this
example.
 The life time (LIFE) is specified in number of years as for the other processes.
 The conversion factor between capacity unit and activity unit (CAP2ACT) is not equal to
1 because the units are different: the activity is in billion vehicle-kilometres, the stock is
in thousands of units (000_units or vehicles) and the utilization factor (AFA) is in
thousand kilometres per vehicle. The CAP2ACT is translating mvkm into bvkm.

Figure 106. More complex processes in the transportation sector

Figure 107. Declaration of more processes in the transportation sector

83
3.7.2.6 Demands
The demand for transportation by cars is updated and declared in the right units and
correspond to the sum of billion passengers-kilometres (Bpass*km) for all types of cars (Figure
108):

 Demand (Bpass*km) = STOCK (000_units) * AFA (000_vehiclekm/unit) *

ACTFLO~DEMO (Passengers/vehicle)* CAP2ACT(0.001bvkm/mvkm)

Figure 108. Demand for transportation by car in physical units

3.7.2.7 Emi
A new sheet is added to introduce a comprehensive and convenient approach to account for
combustion emissions by sector. Indeed, the easiest way to account for combustion emissions is
to directly associate the fuel-based emission coefficients with fuel consumption throughout the
whole energy system.
A new ~COMEMI table is added (Figure 109) to define fuel-based emission coefficients
instead of defining emission coefficients for each process in all ~FI_T tables. The special tag
~COMEMI is used to link emissions to commodity consumption through special processing in
the VEDA-FE SYNC process. (The VEDA-TIMES parameters VDA-EMCB and FLO-EMIS
provide alternative ways to declare consumption-linked emissions. See Part II of the TIMES
documentation for more on the use of these parameters.)
In this example, emissions of TRACO2 are associated with six fuels (LPG, gasoline,
kerosene, diesel, heavy fuel oil, natural gas,) for which a coefficient (kt/PJ) is provided. These
coefficients are applied to all the fuel consumption by all the individual processes in the
transportation sector.

Figure 109. Combustion emissions from the transportation sector

3.7.3 SubRES_NewTechs
3.7.3.1 PRI_TRA
This sheet is updated to model the new cars using the same approach as described above for
the existing cars.

84
3.7.4 Scenario files
Several scenario files are created at this seventh step.

3.7.4.1 Scen_DemProj_DTCAR
This scenario file is created to project transport demand using a fill table to grab base year
values from B-Y templates (Figure 110). The ~TFM_FILL table (see section 2.3.3 for more
information) is a feature allowing a template to collect information from other templates. In this
example, the table is collecting the base year values (YEAR=2005) from the B-Y templates
(Scenario = BASE) for the transportation demand (Attribute=Demand) by cars (commodity =
DTCAR). VEDA-FE fills in the REG1 and REG2 values in the blue highlighted cells each time
the template is SYNCed.

Figure 110. Grab base year demand values from B-Y templates

The DTCAR demand is then projected to 2020 in the ~TFM_INS table using the base year
values and some multipliers (2% for REG1 and 3% for REG2) defined by the user (Figure 111).

Figure 111. Using base year values to project end-use demands

3.7.4.2 Scen_Refinery
This scenario file is created to update refinery attributes, again using a fill table to grab
information from B-Y templates (Figure 112). In this example, the table is collecting the base
year values (YEAR=2005) from the B-Y templates (Scenario = BASE) for the activity
production bound (Attribute=ACT_BND) of the refinery (process = REFEOIL00).

Figure 112. Grab base year attribute values from B-Y templates

The activity production is then projected to 2020 in the ~TFM_INS table using the base year
values and some relaxation factors (25% for REG1 and 30% for REG2) defined by the user
(Figure 113). In addition, the maximum (UP) shares of the refinery outputs (Attribute=SHARE-
O) are all updated to 50%, creating flexibility for the model to optimize the mix of refined
products (DSL, KER, LPG, etc.).

85
 Figure 113. Using base year values to update refinery attributes

3.7.4.3 Scen_TRA_CO2_BOUND
This file is used to introduce bounds (limits) on the CO2 emissions from the transportation
sector in REG1 and REG2. A transformation table ~TFM_INS is used (Figure 114) to declare
upper bounds on annual emissions (Attribute = COM_BNDNET; LimType = UP), on the CO2
emissions from the transportation sector only (TRACO2) in REG1 and REG2. These upper
bounds are calculated as percentage reduction targets from the transportation sector CO2
emissions in a reference scenario for 2010 (10%) and 2020 (20%). It is necessary to run the step
model without any limit on emissions first to get the reference emission trajectory (run
DemoS_007) and then calculate the bounds as a reduction targets from the reference emissions.
An interpolation rule is used with the "0" flag in the Year column and the
interpolation/extrapolation option in the region column where the bounds are declared; the code
5 means full interpolation and forward extrapolation.

Figure 114. Declaration of emission bounds for the transportation sector

3.7.4.4 Scen_UC Growth

This file shows another type of user constraint that specifies the maximum (or minimum)
annual growth rate for a set of processes using the CAP, GROWTH attribute (Figure 115). (See
Section 2.3.8 for more on user constraints.)
This user constraint imposes a maximum capacity (defined by UC_CAP) growth rate
(CAP,GROWTH) of 1% per year (value in the column UC_CAP) for cars consuming TRADSL
(these cars are identified using the two columns PSET_CO and PSET_CI). This constraint also
provides a seed value of 1 (column UC_RHSRTS) to enable the capacity growth to start in case
the existing capacity of diesel cars is zero.

Figure 115. Specifying growth rates with a user constraint

86
3.7.4.5 Scen_ElasticDem
This file is used to introduce price-elasticities for end-use demands (Figure 116), so that
demands can react to changes in their prices under a constrained energy system (e.g., under
limits or tax on emissions, etc.). (See Section 4.2 of Part I of the TIMES documentation for more
on the elastic demand formulation.)
In this example, price-elasticities are declared for the transportation demand by cars
(DTCAR). Three attributes need to be declared:

 COM_ELAST: Elasticity of demand indicating how much the demand rises/falls in

response to a unit change in the marginal cost of meeting a demand that is elastic.
 COM_VOC: Maximum possible variation of demand in both directions when using the
elastic demand formulation (15% in this example).
 COM_STEP: Number of steps for the linear approximation of the demand curve (10
steps in this example).

Figure 116. Declaring price-elasticities for end-use demands

In order to activate the elastic demand feature, there are few steps to follow:

 Generate a file with demand prices from a reference case, i.e. without any constraint or
tax on emissions: in the Control Panel of the FE Case Manager, make sure the option
“Write B Price for Elast Dem" is selected (Figure 117). This option is already selected in
the DemoS_007.
 Solve a constrained case with price-elasticity:
o Select the constrained scenarios you want to include in the model run (emission
limits or taxes) as well as the elastic demand scenario.
o In the FE Case Manager, click on No Elast DEM below Base Price and select the
reference case that was run to get the demand base prices (see right side of Figure
118 where DemoS_007b is a constrained case run with elastic demands, while
DemoS_007a on the left side is a constrained case run without elastic demands).

87
 Figure 117. Write base prices for elastic demands

Figure 118. Activate the elastic demand in constrained runs

88
3.7.5 Results
The effect of price elasticities on the new projected demand for car transportation in thousand
passengers-kilometres (kpass*km) to the 2020 horizon is visible (Figure 119) in the scenarios
where it was activated (DemoS_007b and DemoS_007c). Demands are decreasing by about 9%
in both regions, less than the maximum decrease of 15%, meaning than more cost-effective
emission reduction options exist elsewhere in the system beyond that level.
The impacts of the emissions constraints and the growth rate constraint on the optimal
process mix selected to meet the car transportation demand (kpass*km) is shown (Figure 120)
for both regions together:

Figure 119. Results - Effect of price elasticities for the car transportation demand in
DemoS_007

Figure 120. Results – Car transport process mix in DemoS_007

89
  In the reference case (DemoS_007), new diesel cars satisfy the entire demand for car
transportation from 2015 and beyond. The output mix of the refinery is shown below
(Figure 121).
 The limits on the transportation sector emissions (DemoS_007a) lead to a switch toward
less polluting options such as electric, natural gas and LPG cars.
 The activation of elastic demand (DemoS_007b) leads to a reduction in the use of the
most expensive option to meet demand – electric cars .
 The addition of a growth rate constraint on diesel cars (DemoS_007c) leads to a switch
toward natural gas cars.

Figure 121. Results - Flexible refinery output in DemoS_007

Objective-Function = 5,484,966 M euros (see the _SysCost table in VEDA-BE) with

2,859,389 M euros for REG1 and 2,625,577 M euros for REG2. These costs are higher than
those computed with the previous step model DemoS_006 because of the many components
added to the RES. The total cost is 12% higher when emissions limits are imposed on the
transportation sector (6,145,863 M euros), but only 7% higher with the activation of elastic
demand as the model has more flexibility to reach the emissions targets (5,891,267 M euros).
The addition of the growth rate constraint on diesel cars brings the system cost increase back up
to 10% (6,025,956 M euros).

3.8 DemoS_008 - Split Base-Year (B-Y) templates by sector: demands by

sector
Description. At the eighth step, the level of detail in the representation of the RES is
expanded further, the base-year information is disaggregated into different B-Y Templates for

90
each sector, and demands are projected through 2050. Each of these B-Y Templates utilizes only
the relevant portion of the energy balance for its region and is linked to an additional single file
containing the complete regional energy balances. This approach is convenient when different
individuals work in parallel on different sectors. In addition, it encourages grouping of related
commodities and processes, and as the size of a model grows it improves (and speeds up) the
process of managing the model.
Objective. The objective is to give more examples on how to further expand the detail of the
representation of the RES, in terms of the number of end-use demand segments and end-use
devices as well as commodities. On the demand side, the idea is to cover the energy consumption
by end-use in all sectors rather than by type of energy: agriculture (one end-use demand),
commercial (three end-use demands), residential (three end-use demands), industrial (one end-
use demands), and transport (two end-use demands). On the supply side, the idea is to break the
renewables into more detail for wind, solar, hydro and biomass power. This enhancement of the
RES requires the modelling of additional processes as well as the addition of emission
coefficients for all sectors.
Another objective is to show how to impose a limit on power generation capacity: nuclear,
for example. The scenario variants with nuclear maximum capacity, with different types of limits
on emissions, and with and without the elastic demand feature, illustrate the impacts on the
respective contribution of each sector to the target as well as on the electricity generation mix.

Attributes introduced: Files updated

N.A. SysSettings
Scen_TRA_CO2_Bound
Scen_ELC_CO2_Bound
Scen_UC_CO2BND
SubRES_NewTechs
Files created
VT_REG1_PRI_v08
VT_REG1_ELC_v08
VT_REG1_RCA_v08
VT_REG1_TRA_v08
VT_REG1_IND_v08
VT_REG2_PRI_v08
VT_REG2_RCA_v08
VT_REG2_ELC_v08
VT_REG2_TRA_v08
VT_REG2_IND_v08
Scen_UC_NUC_MaxCAP
Files replaced
VT_REG1_PRI_v07
VT_REG2_PRI_v07

Files. The eighth step model is built:

1. by modifying the SysSettings file to add more time periods;

91
 2. by replacing the two B-Y Templates (VT_REG1_PRI_v07, VT_REG2_PRI_v07) by five
B-Y Templates – one for each sector – in each region (VT_REG1_*_v08,
VT_REG2_*_v08), and to add more energy commodities, energy processes, and
emissions;
3. by completing the SubRES file;
4. by updating scenario files with limits on emissions;
5. by creating a scenario file with a user constraint on the maximum nuclear power capacity
(Figure 122).

Figure 122. The files included in DemoS_008

3.8.1 SysSettings file

3.8.1.1 TimePeriods
The ~TimePeriods table is used to extend the time horizon of the model by adding six active
periods of five years (Figure 123). These specifications are saved under a new time period
definition (Pdef-11). The time horizon is extended to 2050 with the milestones years being 2005,
2006, 2010, 2015, 2020, 2025, 2030, 2035, 2040, 2045 and 2050. This can be seen in VEDA-FE,
Advanced Functions menu, MileStone Years tab.

92
 Figure 123. New time periods definition in the SysSettings file

3.8.1.2 Defaults
The ~DefUnits table is used to specify the different default activity, capacity and commodity
units for each sector in the model (Figure 124).

Figure 124. Default declarations in the SysSettings file

3.8.2 B-Y Template VT_REG*_PRI_V08

3.8.2.1 EnergyBalance
The energy balance is disaggregated further and includes a larger number of commodities.
The renewable category is disaggregated to track several sources independently: biomass as well
as hydro, wind, and solar energy (Figure 125). Moreover, the energy balances of both regions are
now moved into a separate file (called EnergyBalance) and all B-Y Templates are linked to this
file to grab the relevant sector data.

93
 * For purposes of clarity the energy balance is not presented totally and some columns are missing (for refined
products).
Figure 125. Disaggregated energy balance at start year 2005 for REG1 – Covered in
DemoS_008

3.8.2.2 Pri_COA, Pri_GAS, Pri_OIL, Pri_PP, Con_REF

The structure of these sheets have not changed, but the data is updated following a different
commodity split between REG1 and REG2 in the energy balance.

3.8.2.3 Pri_RNW and Pri_NUC

Mining processes for the uranium resources and the new renewable potentials are
characterized with a cost (Figure 126).

Figure 126. Description of new supply options for renewables

3.8.2.4 Pri_ELC
This sheet is created to capture the imports and exports of electricity (Figure 127). In the
default process table, the operational level of these processes are declared as DAYNITE in the
Tslvl column. Note that the ELC commodity is not declared in the default commodity table as it
is already declared in the ELC B-Y Templates. Commodities need to be declared only once and
then are available for all files (not only B-Y Templates).

Figure 127. Imports and exports options for electricity

3.8.3 B-Y Template VT_REG*_ELC_V08

3.8.3.1 Con_ELC
New power plants are added for each type of renewable energy (Figure 128) using the same
approach as before. Their contribution to peak varies depending on the resources: 50% for hydro,

94
30% for wind, and 20% for solar. However, there is no emission coefficient associated with
process anymore (in ~FI_T tables). All combustion emissions are tracked in a uniform manner at
the sector level in a ~COMEMI table.

Figure 128. New power plants for renewable electricity generation

3.8.3.2 Emi
A similar sheet is added in all sectors with a ~COMEMI table used to define fuel-based
emission coefficients associated with fuel consumption in each sector (Figure 129).

Figure 129. Combustion emissions from the electricity sector

3.8.4 BY Template VT_REG*_IND_V08

3.8.4.1 DemTechs_IND
The energy consumed in the industrial sector is captured through a single generic process
(Figure 130) consuming the mix of industrial fuels as given in the energy balance and producing
one end-use demand (DIDM1). A relaxation factor is used for the maximum input shares in 2050
to give more flexibility to the model over time to optimize the fuel mix. However, the value of
the relaxation factor should remain realistic since most fuel switches involve process switches as
well.

Figure 130. Multiple input shares process in the industrial sector

95
3.8.4.2 Emi
An emission commodity is created (Figure 131) and a ~COMEMI table is added in the Emi
sheet to track all fuel-based emissions from the sector.

Figure 131. New environmental commodity for industrial emissions

3.8.5 BY Template VT_REG*_RCA_V08

This B-Y Template includes the information related to three sectors: agriculture, commercial
and residential.

3.8.5.1 DemTechs_AGR
The energy consumed in the agriculture sector is captured through a single generic process
(as for the industrial sector) consuming the mix of agriculture fuels as given in the energy
balance and producing one end-use demand (DAOT). A relaxation factor is also used for the
maximum input shares in 2050 to give more flexibility to the model over time to optimize the
fuel mix. However, the value of the relaxation factor should remain realistic since most fuel
switches involve process switches as well.

3.8.5.2 DemTechs_RSD and DemTechs_COM

The energy consumed in the commercial and the residential sectors is modelled through
specific processes (Figure 132). Multiple processes are in competition to satisfy each end-use
demand (e.g., RSHE* to satisfy the DRSH demand). The existing processes are characterized
with their existing installed capacity (STOCK) corresponding in this case to the energy
consumption required to produce these energy services as given by the energy balance and the
additional fuel split assumptions. The calculation of the existing stocks also takes into account
availability factors (AFA) and are converted into GW using a capacity to activity factor
(PRC_CAPACT equivalent to CAP2ACT). They also have an efficiency (EFF) and a life time
(LIFE).

Figure 132. Existing processes in the residential sector

96
3.8.5.3 Demands
The demand table includes all end-use demands for energy services from the three sectors
(Figure 133). The values come from the process sheets where the values are already computed in
the pink column (Figure 132): STOCK*AFA*PRC_CAPACT. This sheet also includes the
fractional shares of each end-use demand by time slice (Figure 134). These shares are relevant to
capture the annual variation in the electricity (ELC) consumption levels and prices, the only
commodity tracked at the time slice level. In this example, the annual variations are significant
for those end-use demands affected by seasonal changes (e.g. space heating).

Figure 133. Demand for energy services in the RCA sectors

Figure 134. Fractional shares for RCA energy service demands

97
3.8.5.4 Emi
An emission commodity is created in all three sectors and three ~COMEMI tables are added
in the Emi sheet to track all fuel-based emissions from each of the three sectors.

3.8.6 BY Template VT_REG*_TRA_V08

3.8.6.1 DemTechs_TRA
The energy consumed in the transportation sector is disaggregated into two end-use demands:
transportation by cars and public transport. Consequently, more existing processes are included
to satisfy the demand for the new public transport demand, and they are modelled using the same
approach as for cars (Figure 135).

Figure 135. Existing processes in the transportation sector

3.8.6.2 Demands
The demand table includes both end-use demands (in Bpass-km) and the fractional shares of
each end-use demand by time slice.

3.8.6.3 Emi
An emission commodity is created and a ~COMEMI table is added in the Emi sheet to track
all fuel-based emissions from the sector.

3.8.7 SubRES_NewTechs
The structure of this file has not changed; this is a repository of new processes available for
all the regions. The file includes one sheet for each sector: ELC, PRI, IND, RCA, TRA. (The
sheet's names have changed and reflect each new sector's name).
The new process repository is completed with more new processes similarly as for the
existing processes in the B-Y Templates, namely more processes for renewable power
generation, public transport, and more energy services in the residential and commercial sectors
(Figure 136).

3.8.7.1 IEA-ETSAP_ETechDS
This sheet contains a reference to the technology briefs (E-TechDS – Energy Technology
Data Source) coordinated by the ETSAP-IEA. They are classified into two main categories:

98
energy supply technologies and energy demand technologies. They provide relevant data on the
most important technical and economic attributes of numerous types of technologies.3

Figure 136. New processes in the residential and commercial sectors

3.8.8 Scenario files

3.8.8.1 Scen_UC_CO2BND
This user constraint is updated to introduce bounds (limits) on the CO2 emissions from all
sectors in each region (REG1 and REG2). These upper bound are calculated as a percentage
reduction target from the CO2 emissions (sum in kt) from all the sectors in a reference scenario
for 2010 (10%) and 2020 (20%). It is necessary to run the step model without any limit on
emissions first to get the reference emission trajectory (run DemoS_008) and to calculate the
bounds as a reduction target from the reference emissions.

3.8.8.2 Scen_UC_NUC_MaxCAP
To build this scenario, a ~TFM_FILL table first collects information from the B-Y Templates
for REG1 and REG2 (Figure 137): the installed capacity (STOCK) of the nuclear power plant
(ELCNENUC00). These data are refreshed each time this file is synchronized (SYNC). Second,
a user constraint is built to define an absolute upper limit on the total nuclear capacity by region
(Figure 138). In 2015, the maximum capacity is fixed to the 2005 base year levels in both
regions. Afterwards the capacity is kept constant for REG1 (using the interpolation rule

3
http://www.iea-etsap.org/Energy_Technologies/Energy_Technology.asp

99
15=interpolation migrated at start, forward extrapolation), and in REG2 is limited to an
additional 10% of the 2005 base year capacity in 2030 and an additional 50% in 2050.

Figure 137. Grab base information on nuclear power capacity

Figure 138. Declare a maximum capacity for nuclear power plants with a user constraint

3.8.9 Results
The results for the electricity generation capacity (Figure 139) show the respective role of the
new types of renewable power (biomass, hydro, wind and solar), the 2050 horizon, as well as the
effects of the user constraint on nuclear capacity. Nuclear capacity remains constant for REG1
while it grows in REG2 up to the maximum bound in 2030, but not in 2050.

Figure 139. Results - Power generation capacity by fuel type in DemoS_008

The emissions by sector (in Mt) are presented (Figure 140) for both regions, where it is
possible to see the contribution of each sector to reaching the reduction targets. In DemoS_008c,
with a limit on the total emissions, the additional reductions are coming from the electricity
sector (replacing coal-fired with gas-fired power plants), as well as from the residential and the
commercial sectors (replacing solid fuels with renewable energies).

100
 Figure 140. Results – Emissions by sector in DemoS_008

Objective-Function = 19,119,653 M euros (see the _SysCost table in VEDA-BE) with

9,068,703 M euros for REG1 and 10,050,950 M euros for REG2. These costs are again much
higher to those computed in the previous step model DemoS_007 because of the expansion of
the RES. The total cost is 4% higher with the emission limits for the electricity and the
transportation sectors (19,358,261 M euros), and is only slightly reduced by the activation of the
elastic demands (19,352,675 M euros). The additional user constraint on nuclear power increases
the system cost by 11% (19,699,008 M euros).

3.9 DemoS_009 - SubRES sophistication (CHP, district heating) and Trans

files
Description. At the ninth step, the model database is developed further by adding more
SubRES with more complex processes. Because SubRES are used to add new processes in
different sectors they can be considered as separate modules that can be included in model runs
as part of the reference energy system or not. This approach is convenient when different
individuals work in parallel on different sectors.
Objective. The objective is to give more examples of possible SubRES including more
complex processes: one that introduces iron and steel production in the industrial sector, and one
that introduces combined heat and power (CHP) processes, centralised heating plants, and heat
exchanger + district heating network. Additional objectives include:

101
  To show how to use the BY Trans file to move or add data and reduce the size of tables in
the B-Y Templates. Here we specify the availability factor by time slice for existing wind
and solar processes and add an interpolation rule for new hydro capacity (NCAP_BND).
 To show how to use the transformation file associated with each SubRES to declare the
availability or non-availability of each process in each region: new hydro power plants in
this example.
 To give an example of a scenario used to insert/update information in the B-Y Templates
and SubRES: the demands and the retirement profile for the iron and steel processes.
 To illustrate how to build a user constraint to limit the penetration of some processes,
such as the district heating system between 2020 and 2050.

Attributes introduced: Files updated

PASTI VT_REG1_ELC_V09
CEH VT_REG2_ELC_V09
CHPR BY_Trans
UC_CAP SubRES_NewTechs_Trans
UC_COMPRD Files created
UC_FLO SubRES_New-IND
SubRES_New-CHP-DH
Scen_IND_NewRes
Scen_UC_DH_MinProd

Files. The ninth step model is built:

1. by modifying two B-Y Templates (VT_REG1_ELC_v09, VT_REG2_ELC_v09) to
introduce past investment information;
2. by using the BY Transformation file (BY_Trans) to insert base year information
(availability factor by time slice for existing wind and solar plants and interpolation
rules);
3. by using a SubRES Transformation file (SubRES_NewTechs_Trans) to insert
information for new processes (availability factor by time slice for new wind and solar
plants) and to declare the availability or non-availability of each process in each region;
4. by building two new SubRES (one with an iron & steel sector; one with CHP processes
and district heating);
5. by creating a scenario file to update information in the industrial sector;
6. by creating a scenario file with a user constraint on the minimum penetration of district
heating in the residential sector (Figure 141).

102
 Figure 141. The files included in DemoS_009

3.9.1 B-Y Template VT_REG*_ELC_V09

The only B-Y Templates that are modified are the electricity ones (VT_REG1_ELC_V09 and
VT_REG2_ELC_V09).

3.9.1.1 Con_ELC
The STOCK attribute for existing capacity can be replaced by another attribute (PASTI =
past investments) to describe capacity installations that took place before the beginning of the
model horizon (2005) and still exist during the modelling horizon. For any process, an arbitrary
number of past investments may be specified to reflect the age structure in the existing capacity
stock: the hydro power plants in this example (Figure 142). Each vintage of PASTI capacity will
be constant until the end of its technical life, after which the capacity becomes zero in a single
step. This allows a vintage-based retirement profile for the existing stock to be introduced into
the model without the need to calculate and specify a STOCK in each future year.

103
 Figure 142. Declare past investments that took place before 2005

3.9.1.2 BY_Trans
The BY_Trans file works like a scenario file, except that the rule-based filters and the
update/insert changes apply only to those process and commodities already existing in the B-Y
templates. In this example (Figure 143), the file is used to insert new information: the availability
factor (AF) by time slice (SD, SN, etc.) for existing wind and solar plants (ELCREWIN00 and
ELCRESOL00).

Figure 143. Using the transformation file to insert new attributes for existing processes

The transformation file is also used to insert a new interpolation rule (2 = interpolation, but
extrapolation with EPS (epsilon, or effectively zero), which inserts EPS in every year if no
bound value is declared in any year) to avoid the installation of new capacity (NCAP_BND)
after the base year for the existing hydro power plants (ELCREHYD00). VEDA-FE creates this
entry by default for all technologies for which STOCK is declared. Since we have switched to
using PASTI we need to declare it manually (Figure 144).

Figure 144. Using the transformation file to insert a new interpolation rule

104
3.9.2 SubRES_NewTechs_Trans
Similarly to the BY_Trans file, a transformation file exists for each of the SubRES created.
They are used to update/insert information for new processes and commodities declared in the
corresponding SubRES and to declare the availability or non-availability of each process in each
region. In this example, the transformation file of the SubRES_NewTechs is used to insert the
availability factor for new wind and solar plants (ELCRNWIN01 and ELCRNSOL01) exactly as
for the existing ones.
To assign the availability of processes to regions, a new ~TFM_AVA table is created (Figure
145). The first line says that all processes (Pset_PN=*) are available in all regions. The second
line modifies this to say that the new hydro power plant is not available in REG1 (1=available;
0=non-available).

Figure 145. Using the SubRES transformation file to declare process availability

3.9.3 SubRES_New-IND
In the new SubRES_New-IND file, a simplified iron & steel sector is added to the model
(Figure 146). This file includes two sheets (IND and PRI); sheet names need to start with the
name of one of the model sectors.

Figure 146. Examples of processes in the iron & steel sector

For policy analysis, it is useful to develop the most energy-intensive industrial sectors, such
as iron & steel, in more detail, using a process-oriented approach rather than using generic
processes capturing the energy mix. Here the demand is expressed in millions tons (Mt) of
finished steel production, and a series of processes are modelled to represent the main steps of
the transformation chain, from raw material extraction to the production of finished products
(with capacity and activity units in Mt). The last process (IDMIIS) is described like a demand
process, while the others are described as (upstream) processes in the chain. This means that they
consume energy commodities and/or materials to produce new materials useful for the iron &

105
steel chain production. The last process, which is a demand technology, finally consumes energy
commodities and materials produced in the chain to satisfy the iron and steel demand (DIIS).
These processes use a mix of energy inputs and material inputs. These materials are declared
as MAT commodities and tracked in Mt (Figure 147).

Figure 147. Energy and material input commodities for the iron & steel sector

3.9.4 SubRES_New-CHP-DH
This file includes two sheets (ELC_CHP and RCA), recalling that SubRES sheet names need
to start with the name of one of the model sectors. The first sheet is used to add the combined
heat and power (CHP) sector to the model (Figure 148). Cogeneration power plants, or combined
heat and power plants (CHP), are plants that consume one or more commodities and produce two
commodities, electricity (ELC) and heat (HET). The new CHP processes are characterized with
additional attributes compared with conventional power plants.

 The new processes do not have an existing installed capacity, but they are available in the
database to be invested in. They are characterized with an efficiency (EFF), an annual
availability factor (AFA), fixed and variable O&M costs (FIXOM, VAROM), a life time
(LIFE), a capacity to activity factor (CAP2ACT in PJ/GW), and an investment cost
(INVCOST), as well as the year in which they become available (START). Maximum
input shares (Share-I~UP) are also specified for the dual input process ELCBNGAB01
consuming a maximum of 60% of biomass.
 Two new attributes are introduced: the ratio of electricity lost to heat gained (CEH) as
well as the ratio of heat produced to electricity produced (CHPR).

Two main types of cogeneration power plants can be distinguished according to the
flexibility of the outputs: a back pressure process (ELCBNGAB01) and a condensing process
(ELCCNGAS01).

 Back pressure turbines are systems in which the ratio of the production of electricity and
heat is fixed, so that the electricity generation is directly proportional to the steam
produced. In a real system, a back pressure turbine is defined using the electrical
efficiency, the thermal efficiency, and the load utilization. The CHPR attribute is then
fixed (FX), so the production of electricity and heat is in a fixed proportion, but one could
also use a (LO) CHPR for defining the back-pressure point, if so desired (to allow by-
passing the turbine to produce more heat). CEH can be either 0 (or missing) or 1:
o If it is 0 (or missing) as in this example, the activity represents the electricity
generation and the capacity represents the electrical capacity;

106
 o If it is 1, the activity represents the total energy output and the capacity represents
the total capacity (electricity + heat).
 The condensing pass-out or extraction turbines do not have to produce heat, permitting
electricity only to be generated, and permitting the amount of heat generated to be
directly adjusted to the heat demand, while the electricity generation is reciprocally
proportional to heat generation (electricity losses because of heat extraction). They are
thus described differently:
o 1. Coefficient of electricity to heat, via attribute CEH such that: a) <= 1:
electricity loss per unit of heat gained (moving from condensing to backpressure
mode), indicating that activity is measured in terms of electricity, or b) >= 1: heat
loss per unit of electricity gained (moving from backpressure to condensing
mode), indicating that activity is measured in terms of total output (electricity plus
heat).
o 2. Efficiencies, according to 1: a) are specified for the condensing point, or b) are
specified for backpressure point.
o 3. Costs, according to 1: a) are specified based according to condensing mode, or
b) are specified based on total electricity and heat output at backpressure point.
o 4. Ratio of heat produced to electricity produced (CHPR): Ratio of heat to power
at backpressure point; at least a maximum value is required, but in addition also a
minimum value may be specified.
 See Section 4.1 of Part II of the TIMES documentation for more on CHP processes and
their attributes.

The CHP processes are declared as CHP processes in the process declaration table with a
time slice level of activity (DAYNITE). The heat (HET) is also declared as a new energy
commodity in the commodity declaration table.

Figure 148. Examples of combined heat and power processes

The RCA sheet is used to add a district heating option to the model (Figure 149): a process is
created as the district heating option (RSHNHET1) and a sector fuel process (FTE-RSDHET) is
created to produce sector heat (RSDHET) from primary heat (HET).

 They are characterized with an efficiency (EFF), an annual availability factor (AFA),
fixed O&M costs (FIXOM), a life time (LIFE), a capacity to activity factor (CAP2ACT
in PJ/GW), and an investment cost (INVCOST), as well as the year in which they
become available (START).

107
 Figure 149. Demand for heat and district heating options

3.9.5 Scenario files

3.9.5.1 Scen_IND_NewRES
A transformation table is used to update the base year industrial demand (DIDM1): the base
year valued defined in the B-Y Templates are multiplied by 0.9 (Figure 150). This essentially
reduces the DIDM1 demand that was used to model all industrial sector energy consumption by
an amount roughly corresponding to that consumed by the new iron and steel sector. (Although
note that we are not trying to replicate calibration to the energy balance precisely in this simple
example.)
Another transformation table is used to define the demand value for the new iron and steel
demand (DIIS), activating this sector when the SubRES is included in a model run, and to
specify the retirement profile for the iron and steel processes (STOCK in 2050). (In this case the
STOCK has been introduced in a SubRES template so VEDA-FE will not create any
interpolation rule to prohibit new investments.)

Figure 150. Update existing information and insert new information in the industrial sector

3.9.5.2 Scen_UC_DH_MinProd
A user constraint is built to specify the minimum district heating penetration requirement in
specific years (2020 and 2050) with an interpolation/extrapolation rules between those years
(rule 15=interpolation migrated at start, forward extrapolation) (Figure 151). The constraint says
that the production of DRSH by processes that consume RSDHET (Pset_CI) must be the
minimum (LimType=LO) percentage specified in each region/year combination of all
production (table level declaration UC_COMPRD) of DRSH.

Figure 151. Minimum district heating penetration using a user constraint

108
3.9.6 Results
The model variant DemoS_009d is solved with the new iron & steel sector. Figure 152 shows
the demand production (DIIS in Mt) from the finished steel production process (IDMIIS),
consuming industrial steel (IISRST in Mt) and a mix of energy in PJ.
The model variant DemoS_009e is solved with the new district heating option. Figure 153
shows the contribution of district heat in meeting the demand for residential space heating in
both regions together.

Figure 152. Results – Finished steel production in DemoS_009

Figure 153. Results – Fuel used for residential space heating in DemoS_009

Objective-Function = 19,183,729 M euros (see the _SysCost table in VEDA-BE) with

9,084,193 M euros for REG1 and 10,099,536 M euros for REG2. These costs are similar to those
computed with the previous step model DemoS_008. The total cost is 3% higher with the
emission limits, growth rates, elastic demands, and the new iron and steel sector (19,721,879 M
euros) and 5% with the new district heating option (20,187,883 M euros) and the new investment
required to satisfy the minimum constraint on district heating penetration.

109
3.10 DemoS_010 - Demand projections and elastic demand
Description. At the tenth step, the model structure and database remain the same but energy
service demands are projected using an internal VEDA-FE routine.
Objective. The objective is to show how to prepare the files required to automatically project
end-use demands for energy services using demand drivers along with sensitivity and calibration
series.

Attributes introduced: Files updated

N.A. Scen_ElasticDem
Files created
Dem_Alloc+Series
ScenDem_DEM_Ref

Files. The tenth step model is built:

1. by creating one file that allocates a demand driver to each end-use demand
(Dem_Alloc+Series) and defines sensitivity and calibration series, and one file
(ScenDem_DEM_Ref) that defines demand drivers;
2. by modifying the elastic demand scenarios to cover all end-use demands for energy
services (Figure 154).

Figure 154. The files included in DemoS_010

3.10.1 Demand files

3.10.1.1 ScenDem_DEM_Ref
The ~DRVR_Table table is used to declare a coherent set of driver growth rates (or indexes,
with 2005=1) to drive all end-use demands in all regions (Figure 155). These drivers can be more

110
general, such as macroeconomic indicators, as in this example (Gross Domestic Product (GDP),
population (POP), industrial output demand (INDD)), or more specific, like vehicle-kilometres
for energy service demands in the transportation sector, for instance. It is possible to build
multiple files called ScenDem_<file name> with different drivers to generate, for example, a
reference case along with low and high growth cases.

Figure 155. Demand drivers for end-use demand projections

3.10.1.2 Dem_Alloc+Series
The ~Series table is used to define sensitivity and calibration series (Figure 156). The
sensitivity series represents the sensitivity of each end-use demand to one unit change in its
driver. The calibration series can optionally be used to provide additional control over the
resulting demand levels.
The growth rates of the various drivers are applied to the 2005 base year demands using the
following formula:

The ~DRVR_Allocation table is used to allocate a particular driver to each end-use demand
in each region (Figure 157). Only one such allocation file, always named Dem_Alloc+Series,
may be built. That is, it is envisioned that in different scenarios, the projection of the driver for
each demand may change (higher or lower population growth, for example), but the association
of each demand with a particular driver will not change. (For example, DRSH is always driven
by population growth with the same sensitivity.) Only one driver series may be associated with
each demand. However, one may easily create a composite series if combining two drivers is
desired. In this example, the demand DAOT will be projected using the driver GDP, adjusted
with calibration and sensitivity series (Constant; =1 over the whole model horizon).

Figure 156. Sensitivity and calibration series for end-use demand projections

111
 Figure 157. Allocation of demand drivers and series for end-use demand projections

All the demands projected with the internal VEDA-FE module can also be managed from the
menu: Advanced Functions/Demand Master. Changes made within the Demand Master will be
reflected in the templates. For more information on the Demand Master function, see
http://support.kanors-emr.org/.

3.10.2 Results
The resulting demand projections in the reference case (DemoS_010) using the driver and
series allocation presented above are shown (Figure 158), as well as the demand reactions when
including all additional constraints (limits on emissions, growth rates of cars, minimum
penetration of district heating, etc.).

Figure 158. Results – Demand projections in DemoS_010

112
 Objective-Function = 24,831,217 M euros (see the _SysCost table in VEDA-BE) with
10,869,234 M euros for REG1 and 13,961,983 M euros for REG2. The total cost is 7% higher
with all model variants (26,475,198 M euros).

3.11 DemoS_011 - Linking input templates and VEDA-BE sets

Description. At the eleventh step, the model structure and database still remain the same but
process and commodity sets defined in VEDA-BE are linked with the VEDA-FE model.
Objective. The objective is to show how to link VEDA-BE sets with VEDA-FE models. It is
possible to create sets of commodities and processes in VEDA-BE using filters and rules. These
sets are generally used to build tables to view results in VEDA-BE, but it is also possible to link
the VEDA-BE database with a VEDA-FE model to use these sets in VEDA templates. We also
provide an example in which VEDA-BE sets are used in the VEDA-FE database: a user
constraint on the minimum penetration of renewable power plants is built using a user defined
set of renewable processes. (See Part V of the TIMES documentation for more on creating
VEDA-BE sets and using them to view results within VEDA-BE.)

Attributes introduced: Files created

N.A. Scen_BOUNDS-UC_WSETS

Files. The eleventh step model is built:

1. by creating one scenario file that explains VEDA Sets specification and includes a user
constraint using a VEDA-BE table.

3.11.1 Scen_Bounds-UC-wSets
The new scenario file contains two sheets: one that explains how to access VEDA-BE sets
within VEDA-FE, and one that includes a user constraint using a VEDA-BE table (UC_Set). The
steps to link the VEDA-BE database with a VEDA-FE database are:

 Click on Veda_SnT.MDB in the main menu bar of VEDA-FE.

 In the Options window, File Locations tab, click Veda-BE Database button (Figure
159), and locate the path where the VEDA-BE database is stored (e.g.
C:\VEDA\Veda_BE\Databases\DemoS_VBE), and click OK.
o The selected Veda_SnT.MDB path will now appear in the main menu bar of
VEDA-FE (e.g. C:\VEDA\Veda_BE\Databases\DemoS_VBE\Veda_SnT.MDB).
 VEDA-BE sets will now appear in the VEDA-FE browser (See Section 2.4.1). The sets
of commodities and processes can be viewed in the dropdown menus below the main
Process and Commodity boxes. Selecting one of the sets will change the Process or
Commodity list to show only the processes or the commodities included in this set: the
PP_RENEW set that includes all renewable power plants in this example (Figure 160).
Any of these sets can now be used directly in VEDA-FE files to insert or update
information for a group of processes or commodities.

113
 Figure 159. Create the link to VEDA-BE databases in VEDA-FE

Figure 160. VEDA-BE sets in the VEDA-FE browser

As an example, a user constraint is built using the process set PP_RENEW (column
PSet_SET) that includes all renewable power plants: it specifies a minimum renewable
penetration share of 10% in 2020 and 15%-20% in 2050, depending on the region, along with an
interpolation/extrapolation rule (Figure 161).

Figure 161. User constraint on renewable power using a VEDA-BE set

3.11.2 Results
Figure 162 shows the impact of the new user constraint on the renewable share of total
power generation. While the share of renewables is going to 0 without the user constraint in the
previous reference case (DemoS_010), it reaches 18% across both regions in 2050 in the new

114
reference case (DemoS_011), and 20% when including all additional constraints (limits on
emissions, growth rates of cars, minimum penetration of district heating, etc.).

Figure 162. Results – Demand projections in DemoS_011

Objective-Function = 24,867,969 M euros (see the _SysCost table in VEDA-BE) with

10,886,683 M euros for REG1 and 13,981,286 M euros for REG2. The total cost is 6% higher
with all model variants (26,483,468 M euros).

3.12 DemoS_012 – More modelling techniques

Description. At the twelfth step, taxes and subsidies are added to the model database and a
new modelling technique is introduced, namely the lumpy investment concept.
Objective. The objective is to show how to add taxes and subsidies for processes or
commodities, such as a tax on diesel and total CO2 for all sectors and regions, as well as a
subsidy on solar power plants in this example. Another objective is to show how to use the
lumpy investment feature of TIMES through discrete capacity for the new nuclear power plants.

Attributes introduced: Files updated

N.A. VT_REG1_PRI_v12
VT_REG2_PRI_v12
SubRES_NewTechs
Files created
Scen_TRADSL_Tax
Scen_CO2_Tax
Scen_Solar_Subsidies
Scen_UC_CO2_Regions
Scen_NUC_DiscInv

115
 Files. The twelfth step model is built:
1. by updating two B-Y Templates (VT_REG1_PRI_v12, VT_REG2_PRI_v12) to create an
aggregated CO2 emission commodity;
2. by updating the SubRES_NewTechs file to specify discrete investment options;
3. by creating scenario files for introducing taxes, subsidies, and an emission constraint for
all sectors and regions, as well as for discrete investments for nuclear power plants.

3.12.1 B-Y Template VT_REG*_Pri_V12

The only B-Y Templates that are modified are the primary energy ones
(VT_REG1_PRI_V12 and VT_REG2_PRI_V12).

3.12.1.1 TOTCO2
A sheet is added with a ~COMAGG table is that is used to define an aggregated commodity
(TOTCO2), including all sectoral CO2 emissions using multipliers of 1. This is equivalent to
making TOTCO2 the sum of all sectoral CO2 emissions (Figure 163). It is possible to add more
aggregated commodities and change multipliers. For instance, when there are different types of
GHG emissions (CH4, N2O, etc.), an aggregated commodity can be created in CO2-equivalent
to account for their respective global warming potential (CH4=36; N2O=298).

Figure 163. Aggregation of emission commodities

3.12.2 SubRES_NewTechs (ELC sheet)

The first step necessary to enable lumpy investments is to specify discrete investment options
in the default process table, for new nuclear power plants in this example (ELCNNUC01), by
changing the process set from ELC to ELC, DSCINV (Figure 164).

Figure 164. Discrete investment option for nuclear power plants

116
3.12.3 Scenario files
3.12.3.1 Scen_NUC_DiscInv – lumpy investments
The second step necessary to enable lumpy investments is to specify allowable discrete
capacity investments (NCAP_DISC) in specific years for new nuclear power plants
(ELCNNUC01). In this example (Figure 165) the capacity installed for this process can be a
module of 1 GW in 2015, while in 2033 the model can install 2 GW or 3 or 4 or 5 GW.

Figure 165. Discrete capacity at specific years for nuclear power plants

In summary, the TIMES lumpy investment variant can be enabled following four steps:

1. Specify the SET DSCINV for the process for which lumpy investment is to be enabled
(here new power plants (ELCNNUC01) in the ELC sheet of the SubRES_NewTechs
file).
2. Build a scenario file with the discrete capacity modules to be allowed: capacities for the
new power plants (ELCNNUC01) in the NUC_DSCINV sheet of the
Scen_NUC_DiscInv scenario.
3. Before solving the model, it is necessary to enable the variant discrete investment in
VEDA-FE. From the FE Case Manager, select the Control Panel button, check the box
for Discrete Investment at the top right in the TIMES Extensions section (Figure 166),
and click the OK button. Back in the FE Case Manager, the inscription DSC YES in the
yellow section at the bottom of the window shows that the option is enabled.
4. In the Control Panel, set OPTCR (optimization criterion, or tolerance) to 0, in order to get
a truly optimal solution. For example, if you leave OPTCR at its default value 0.1, in
most models this will leave room for very different MIP solutions that would satisfy the
optimality tolerance, and thus you could see lots of flip-flopping between model runs
(even when using exactly the same scenario data).

117
 Figure 166. Enable the variant discrete investment in VEDA-FE

3.12.3.2 Scen_TRADSL_Tax
This file is used to introduce a flow tax (FLO_TAX) on processes and commodities
(input/output) (Figure 167). This is a new attribute that allows imposing an incremental cost of
using/producing a commodity by a process (cost in Currency per unit of commodity produced or
consumed). Here it is used to impose a flow tax on all the transportation processes (T*)
consuming the diesel commodity (TRADSL) at specific years in each region.

Figure 167. Flow tax on commodities

3.12.3.3 Scen_CO2_Tax
This file is used to introduce a tax on a net quantity of commodity (COM_TAXNET). Here
we impose a tax on the new emission aggregated commodity (TOTCO2) created in B-Y
Templates (VT_REG*_PRI_V12) at specific years (Figure 168).

118
 Figure 168. Tax on net quantity of commodities

3.12.3.4 Scen_Solar_Subsidies
This file is used to introduce a flow subsidy (FLO_SUB) on commodities (Figure 169). This
is a new attribute that allows creating a credit for using/producing a commodity by a process
(cost in Currency per unit of commodity produced or consumed). Here a flow subsidy on the
electricity (ELC) commodity produced by all processes consuming the solar energy commodity
(ELCSOL) is created with various values at specific years in each region.

Figure 169. Flow subsidy on commodities

3.12.3.5 Scen_UC_CO2_Regions
This file introduces a new user constraint that imposes limits on all CO2 emissions, summed
over all regions and sector emissions. These upper bounds (or limits) are calculated as a
percentage reduction target from the total CO2 emissions (TOTCO2 in kt) in a reference scenario
for 2020 (10%) and 2050 (15%). It is necessary to run the step model without any limit on
emissions first to get the reference emission trajectory (run DemoS_012) and to calculate the
bounds as reduction from the reference emissions.
Comparing this scenario with Scen_UC_BND, the differences are the ~UC_Sets (using R_S:
AllRegions rather than R_E: AllRegions) and the declaration (UC_RHSTS rather than
UC_RHSRTS).

Figure 170. User constraint on the aggregation of emission commodities

3.12.4 Results
This model is mainly run to show the impacts of the different taxes and subsidies, as well as
the effects of the lumpy investment feature of TIMES through the discrete capacity requirement
for the new nuclear power plants. Regarding fuel consumption in transportation (Figure 171):

119
 The tax on diesel consumption in the transportation sector (DemoS_012a) leads to a rapid
decrease in refined products, reaching zero by 2025, to the benefit of renewable energies,
which meet most of the demand by 2050.
 The tax on total CO2 emissions (DemoS_012b) leads to an even more drastic decrease of
refined products, reaching zero by 2010, to the benefit of renewable energies.
 The limit on total CO2 emissions (DemoS_012d) does not have an impact on the
transportation fuel mix but affects other parts of the whole energy system. The tax puts
much higher pressure on the energy system than the limit.

Regarding the electricity generation capacity (Figure 172):

 The tax on total CO2 emissions (DemoS_012b) has important impacts on the electricity
sector as well, where most of the thermal generation capacity is replaced with wind
power.
 The subsidy on solar power (DemoS_012c) leads to a more diversified mix, as part of the
wind power is replaced with solar power.
 The declaration of discrete capacity for nuclear power plants (DemoS_012e) limits the
nuclear growth, with only 1 GW of new capacity addition in 2020, 2025, 2030 and 10
GW in 2035 compared with 121 GW in the reference case (Figure 173).

Figure 171. Results – Fuel consumption for transportation in DemoS_012

120
 Figure 172. Results – Electricity generation capacity in DemoS_012

Figure 173. Results – New capacity investments for electricity generation in DemoS_012

121