fenix.tecnico.ulisboa.pt · web viewthe initial code was developed specifically for the corvo case...
TRANSCRIPT
Manual
IN+ energy modeling and microgrid operation toolbox
André Rita
Student of Master Degree in Mechanical Engineering
Universidade de Lisboa, Instituto Superior Técnico
October 2017
TABLE OF CONTENTS
TABLE OF CONTENTS............................................................................................................................... I
LIST OF FIGURES.................................................................................................................................... III
1 INTRODUCTION..............................................................................................................................1
1.1 The Toolbox...............................................................................................................................1
1.2 The Economic Dispatch Model...................................................................................................2
1.3 Objectives..................................................................................................................................2
1.4 Structure of the Manual.............................................................................................................3
2 BASIC CONCEPTS............................................................................................................................4
2.1 Microgrids..................................................................................................................................4
2.2 Generation and Storage units....................................................................................................5
3 CREATING THE MICROGRID SYSTEM..............................................................................................6
3.1 Starting the Toolbox..................................................................................................................6
3.2 GUI_Initial_Window...................................................................................................................6
3.2.1 General Definitions.............................................................................................................12
3.3 GUI_Add_Entry_Generation/Storage......................................................................................15
3.3.1 GUI_Add_Entry_Generation...............................................................................................15
20
3.3.2 GUI_Add_Entry_Storage.....................................................................................................22
3.3.3 GUI_Delete_Entry...............................................................................................................26
3.4 GUI_Save/Load_Data_Sets......................................................................................................27
3.4.1 GUI_Save_Data_Sets..........................................................................................................27
3.4.2 GUI_Load_Data_Sets..........................................................................................................28
4 CHOOSING A SIMULATION TYPE...................................................................................................30
4.1 GUI_Simulation_Type_Selection..............................................................................................30
5 SIMULATION TYPE 1: TYPICAL DAY SIMULATION.........................................................................31
5.1 GUI_Demand_Configuration....................................................................................................31
5.1.1 GUI_Add_Entry_Demand_Increase....................................................................................35
5.1.2 GUI_Demand_Response.....................................................................................................37
5.2 GUI_Ren_En_Avail...................................................................................................................40
6 SIMULATION TYPE 2: CUSTOM LENGTH SIMULATION..................................................................45
6.1 GUI_Multi_Day_Sim_Definitions.............................................................................................45
7 RESULTS & OUTPUTS....................................................................................................................49
I
7.1.1 MatLab® Command Window..............................................................................................49
7.1.2 Figures................................................................................................................................50
7.1.3 Relevant Outputted Variables.............................................................................................52
8 SUGGESTIONS FOR FUTURE WORK/IMPROVEMENTS..................................................................54
8.1 Code/Programming related improvements.............................................................................54
8.1.1 General tweaks/improvements/corrections.......................................................................54
8.1.2 Computational speed.........................................................................................................56
8.2 Toolbox/Model related improvements....................................................................................57
8.2.1 Inserting priority definition.................................................................................................57
8.2.2 Reinstating removed features............................................................................................57
8.2.3 Adding new features...........................................................................................................58
8.2.4 Revising some features.......................................................................................................60
9 AFTERWORD.................................................................................................................................61
REFERENCES.........................................................................................................................................62
II
LIST OF FIGURES
Figure 1: Representation of a typical microgrid (Adapted from [5]).......................................................5
Figure 2: Initial Window of the toolbox..................................................................................................7
Figure 3: Initial Window with created system........................................................................................8
Figure 4: Initial Window with main components numbered..................................................................8
Figure 5: Add Entry Generation Window of the toolbox.......................................................................15
Figure 6: Current selectable types of Generation entries.....................................................................16
Figure 7: Available Fuel types...............................................................................................................18
Figure 8: Fuel Characteristics Window..................................................................................................21
Figure 9: Current selectable types of Storage entries...........................................................................22
Figure 10: Add Entry Storage Window..................................................................................................23
Figure 11: Delete Entry Window...........................................................................................................26
Figure 12: Save Data Set Window.........................................................................................................27
Figure 13: Load Data Set Window (example).......................................................................................28
Figure 14: Simulation Type Selection Window......................................................................................30
Figure 15: Demand Configuration Window..........................................................................................31
Figure 16: Demand Configuration Window with a plotted Base Demand profile.................................32
Figure 17: Demand Configuration Window with Demand Increase entries..........................................33
Figure 18: Modified column in the Demand Profile Table (empty - left; with entries - right)...............34
Figure 19: Add Entry Demand Increase Window..................................................................................35
Figure 20: Current selectable Demand Increase entries types.............................................................36
Figure 21: Profiles for the “Electric Vehicles” type...............................................................................36
Figure 22: Demand Response Window (example)................................................................................38
Figure 23: Demand Response Window with modified “Fixed Demand” (example)..............................39
Figure 24: Renewable Availability Window..........................................................................................41
Figure 25: Example of a filled Renewable Availability Window............................................................42
Figure 26: Daily Capacity Factors Configuration Windows...................................................................43
Figure 27: Custom Length Simulation Window.....................................................................................45
Figure 28: Selectable types of renewable data that can be inserted....................................................46
Figure 29: Instructions for filling the excel spreadsheet.......................................................................46
Figure 30: Example of a filled excel spreadsheet..................................................................................47
Figure 31: Example of Command Window text during the simulation.................................................50
Figure 32: Example of data printed in the Command Window at the end of the simulation...............50
Figure 33: “Figure 1” Window..............................................................................................................51
III
Figure 34: “Figure 2” Window..............................................................................................................51
IV
1 INTRODUCTION
1.1 The Toolbox
Welcome to the IN+ toolbox manual. This energy microgrid simulation and operation optimization
tool has been developed at the IN+ Center for Innovation, Technology and Policy Research at
Instituto Superior Técnico in Lisbon, Portugal, in order to aid the development of energy
management projects there.
The first version of the toolbox, to my knowledge, was developed by Abeysekera, M. [1], a Master
student from the Universidad Politècnica de Catalunya, during his Master Thesis in conjunction with
the Vulcano project being developed in the island of Corvo, in the Azores archipelago, Portugal. It
was developed using the MatLab® software programming language. Since then, the code has been
worked on by other master and doctorate students as well as researchers. Please accept my
apologies and feel free to correct this information should it be incorrect.
The initial code was developed specifically for the Corvo case and the subsequent “ tamperers”
merely modified it to suit their intended usage, although the core of the algorithm (the economic
dispatch model discussed in §1.2) remained the same (at least from the Abeysekera version forward).
However, the lack of a structured document describing how to use the code, combined with the
different styles and approaches to programming (lack of commentaries, heterogeneous algorithm
logic, removal and addition of functions, etc.) has forced every new user/developer to undergo a
rather extended learning period, reading and understanding the code as well as requiring some
degree of experience with MatLab® in order to adapt the code to your situation, even for the
purpose of running a few simple simulations.
One of the objectives of my master thesis [2] was to generalize the code and develop a graphical
interface in order to make it transition from a chunk of MatLab® code to a functional toolbox,
applicable to any case the user might intend. During my attempt to fulfil this goal, I’ve also tried to
“clean up” (removing unnecessary or redundant variables or chunks of code, attempting to increase
its computational speed, etc.) and comment the code. Nevertheless, I recognize that there is still
some work to be done in that area, and that wasn’t the main focus of my thesis, therefore the code
might still be a little confuse/messy. Taking that into account as well as the complexity added by the
introduction of the GUI, I found it necessary to write this document to explain how to use and
continue working on this toolbox in the future.
1
1.2 The Economic Dispatch Model
At the core of the toolbox is the economic dispatch algorithm. This algorithm determines the
dispatch priority of the entries of the system (generation/storage) based solely on a production cost
calculated taking into account fuel consumptions and costs. Therefore, entries that do not have any
fuel cost introduced in the toolbox have the highest priority, followed by the ones that have a
predicted lower production cost, considering their fuel consumption rates and costs to dispatch a
certain power. This means that, although the tool calculates other parameters such as emissions,
specific costs, fuel consumption, etc. the only currently implemented dispatch method is the one
based on the production costs. I will not go into detail regarding the economic dispatch model, in
order to understand it, I believe it should suffice to read the corresponding chapters in the
Abeysekera, M. and Guzzi, F. theses [1, 3].
Since the Abeysekera version was the first one that I’m aware of to be developed, some of its original
functions and calculations were removed subsequently, but his thesis should be read to understand
the core Economic Dispatch algorithm. On the Guzzi, F. thesis [3], chapter 2 and 3 also concern
economic dispatch model, but the main interest is in the addition of the Energy Storage Systems
(ESS) to the model, that were not present previously. Although the storage algorithm was found to
be flawed and is being corrected (by Lorenzi, G., a researcher at IN+), since the version developed by
Guzzi, F. was the one used as a basis for the current toolbox, reading his thesis is also highly
recommended if you wish to understand the core algorithm and model used by the toolbox. Both
theses also contain their respective test cases’ (Corvo and Terceira islands) results and discussion,
which may provide some insight about the main advantages and limitations of the model.
1.3 Objectives
This document has two objectives:
The first one is to explain how to use the toolbox working mainly with the developed
Graphical User Interface (GUI) without the need of understanding the code behind it or using
too many MatLab® commands to complement its usage. The beginning of each section of this
document will have this goal, like a manual for a user who intends to run the tool as it is
programmed (they shall also be labelled as “Manual” sections);
On the other hand, this document also intends to “pass the torch”, displaying more technical
data for the people interested in further modifying the toolbox itself. In each chapter, after
the initial explanation on how to use the toolbox, I will dive into deeper technical and
2
programming information, regarding the inner working of the toolbox and connections
between its MatLab® functions (this section break is signalled by “Technical Data”). These
sections are aimed mainly at future developers, or more in-depth users;
1.4 Structure of the Manual
During this document, I will attempt to clearly separate the two objectives discussed in § 1.3 in their
corresponding sections. Therefore every chapter concerning the working procedures of the toolbox
will consist of an initial “Manual” section followed by a “Technical Data” section. Nevertheless,
should anything regarding a basic usage of the toolbox not be clear on the “Manual” sections, be
sure to read the “Technical Data” ones, or part of them, as they should shed some light on your
questions, since some overlap between them is sure to happen.
As for the order of the chapters in the Manual, it starts by naming and explaining some basic
concepts of the toolbox in an introductory chapter, followed by chapters organized in a step-by-step
usage of the toolbox.
3
2 BASIC CONCEPTS
2.1 Microgrids
Since the toolbox is designed for use by microgrid managers and operators, it’s expected that the
user already has some knowledge on the concepts related to them. Nevertheless, while not
extensively covering the subject, some basic topics will still be addressed here.
“There is no clear definition of a microgrid, and the concept varies in different countries and regions.
Based on the European Technology Platform of Smart Grids [4], a microgrid is a platform that
facilitates the integration of distributed generators (DG), energy storage systems (ESS) and loads to
ensure that the power grid can supply sustainable, price-competitive and reliable electricity.”
(Adapted from [5]). The U.S. Department of Energy Microgrid Exchange Group [6] defines a microgrid
as “a group of interconnected loads and distributed energy resources within clearly defined electrical
boundaries that acts as a single controllable entity with respect to the grid. A microgrid can connect
and disconnect from the grid to enable it to operate in both grid-connected or island-mode”. This
definition is not entirely correct as some microgrids in remote systems have no connection to a main
grid.
From these definitions, it can be seen that, such as a larger grid, a microgrid is consisted by a set of
Generators (the term “Generators” here meaning any unit that can dispatch power to the grid, not
just thermal generators), and may have some Storage devices. Some microgrids are able to operate
in an islanded mode from a main grid, connecting to it when such need arises to satisfy the demand,
while others have no connection whatsoever to any larger grid.
Figure 1 represents a typical microgrid and some of its usual components, a Distributed Energy
Storage (DES) facility and a Distributed Generation (DG) one, and the connections to a main grid and
the loads.
4
Figure 1: Representation of a typical microgrid (Adapted from [5])
2.2 Generation and Storage units
For the purpose of using the toolbox, it should suffice to understand this basic division of the
components of microgrids into Generation and Storage units (the latter ones being optional but very
common), since the first step in using the toolbox consists of creating a virtual microgrid, defining the
technical characteristics of each of these entries in the Add Generation/Storage Entry Windows (see
§3.3.1 and §3.3.2). For further development of the code, I sincerely recommend a more in-depth
study of microgrids, especially energy storage in microgrids. Gao [5] has some initial chapters
explaining the basic concepts of microgrids and smartgrids, and his book addresses energy storage in
smart grids.
There are many types of both Generation and Storage units possible, and the types used vary from
microgrid to microgrid. The current version of the toolbox is somewhat limited in the types of entries
that it can model (in Figure 6 and Figure 9 the Generation and Storage unit types, respectively,
modelled by the toolbox are shown), especially regarding Storage units (since as it was said before,
the storage module was only inserted recently and due to the difficulties involved in modelling
energy storage). It should be possible, however, to model types of generation and storage not
inserted into the toolbox, should they be similar to the ones present in it, through the use of
assumptions and some tuning of the technical parameters.
5
3 CREATING THE MICROGRID SYSTEM
3.1 Starting the Toolbox
Manual
In order to initiate the Toolbox, having an installed version of the software MatLab® is required (one
of the suggestions for a future improvement is the creation of an executable file. That may require
some tuning of the code, since some results are displayed in MatLab® figures and in written text in
the MatLab® command window, see §7). To run the program just open the Main.m script located in
the main folder of the Toolbox and hit “Run” in the “Editor” tab of the MatLab® window (shortcut
F5).
NOTE: Although the directory change commands were generalized (not using specific directories as
commands as in previous versions), the names of some folders still have to be used in the code to
direct the directory change during its usage. Therefore, if you change the name of some of the
folders inside the Toolbox folder, the program may not run properly. Feel free to change the name of
the main folder, changing it shouldn’t cause any problems (Awesome_Toolbox is one suggestion,
remember that MatLab® is not too queen on folder and file names with spaces in them).
3.2 GUI_Initial_Window
Manual
As was previously mentioned, the first step in using the toolbox consists of creating the energy
system to be modelled. The created system is displayed in the two tables on the Initial Window of
the toolbox. In this section, the components of the Initial Window will be explained and subsequent
sections will address the addition of Generation and Storage entries. Figure 2 and Figure 3 show what
the Initial Window looks like when running the program for the first time and with a created energy
system, respectively. Figure 4 displays the numeration of the main components of the window that
will be used when describing each of them.
NOTE: Some windows such as the case of the Initial Window have some notes in italic small letter. At
other windows, some suggestion boxes may pop up when you put the mouse over some fields. You
are advised to read all of these suggestions carefully when using the toolbox. These may save you the
effort/cost of replacing the computer screen you punched due to the frustration that this program
may cause if you attempt to explore alternative ways to use it.
6
Figure 2: Initial Window of the toolbox
NOTE: Due to the ongoing work being done on the toolbox (bug correction, adding functions, etc.),
even as this Manuel is being written, it is possible that the pictures presented in this manual are
different from the actual windows. Most of the time these differences won’t affect using the toolbox
(changes in the italic notes, for example), but apologies in advance for any confusion it may cause.
1. See NOTE: at the start of §3.1;
2. Generation Table - This table contains the Generation entries that were added to the system.
The hidden fields are shown when discussing the addition of Generation entries (§3.3.1);
3. Storage Table - This table contains the Storage entries that were added to the system. The
hidden fields are shown when discussing the addition of Storage entries (§3.3.2);
7
Figure 3: Initial Window with created system
Figure 4: Initial Window with main components numbered
8
4. General Definitions Panel - Fields explained in more detail in §3.2.1. When changing values in
this panel please be aware that clicking in Next Step uploads the current definitions and
opens new windows while keeping Initial Window open. This means that, after clicking Next
Step, the only way to change a definition in this panel is to close all the subsequent windows,
change the intended value and click Next Step again;
5. Bottom Buttons:
a. Add and Delete entries: Add will open the Add Entry Generation Window (§3.3.1).
Delete will open the Delete Entry Window (§3.3.3);
b. Next Step: opens Simulation Type Selection Window (§4.1)
c. Quit & Clean: exits the toolbox cleaning the currently created system. If you exit
using the red cross button in the upper right section of the window, the current
system will be saved. As long as you don’t exit MatLab®, it will be available when you
restart the toolbox;
6. Save and Load Buttons - Can be used to save/load created energy system, through the
Save/Load Data Set Windows (§3.4.1 and §3.4.2). This is the best and only way (without
command window controls) of maintaining a created energy system after shutting down
MatLab®;
Technical Data
GUI’s in MatLab® in the Toolbox run mainly based on “Callback” functions. These are different from
usual MatLab® functions in the sense that they only run when a certain action is performed (clicking a
button, sliding a slider, etc.). There are also some “Creation” and “Deletion” functions that dictate
what happens when an item is first created or deleted (the “Creation” functions are used to ensure
that items such as check buttons and radio buttons have the value that you want when the window is
first opened, whereas “Deletion” functions can be used to change some variables when closing the
window itself, for example) During the usage of a certain window, the functions work as usual
MatLab® functions, in the sense that variables created inside them are not shared with the other
functions. However, when running a GUI window, a structure called handles is created and it can be
accessed by any function of that window’s code. Adding fields to this structure enables the passage
of variables from function to function. Working with its fields (the handles structures has fields with
9
all the characteristics of all the elements of the GUI, that can be changed at will), and the “set” and
“get” functions allows connection between items (a button that updates a table) or getting values
given by each item (exporting the value entered by the user in an edit field to a variable).
NOTE: the author of this Manual still has not figured out how to transport variables from the GUI to
the command window at the end of the window usage, without using “global” variables (variables
defined in every workspace). The usage of global variables is unadvised due to the fact that they may
consume a lot of memory and cost computation power, so they were kept them to a minimum and
only used them to transport the necessary values to outside of the GUI. It is recommended that
anyone seeking to improve the computation speed of the Toolbox would start by cleaning the global
variables (the solution should be in the “varargout” function, but I never quite figured out how to use
it and the need to focus in other aspects have led me to leave this frozen, since the global variables
work).
The Initial Window is commanded by the files GUI_Initial_Window.m and GUI_Initial_Window.fig. It
was created using the GUIDE interface to create GUI’s in MatLab®. The .m file is the one with the
hard code, it contains the functions that run when using the window depicted in the .fig file, all the
“Callback”, “Creation” and “Deletion” functions previously mentioned. the code should be well
commented and “Tags” that accurately depict what each item does were used (“Tags” are the
name/identification that each item has in the GUI: each function in the .m file has a name that
contains the “Tag” used on the item it refers to). Therefore it shouldn’t be very hard to understand
the window’s code just by reading, provided you actually understand something about MatLab® and
its functions used in this GUI (the ones mentioned above, “Callback”, “get”, “set”, etc.; remember
that the help browser in MatLab® is your greatest friend and can be found by pressing F1 when the
mouse is over some difficult words). Nevertheless, below it is what is believed to be the most
important aspects of each element of the Initial Window, numbered in Figure 4.
1. Nothing to see here;
2. The Generation Table displays the information stored in the global variable called
Data_Generation. Both Data_Generation and Data_Storage are cell arrays that are created
empty in a first usage of the toolbox. If the user does not exit the toolbox using the Quit &
Clean button, they are not erased and are imported to be displayed in the tables when
running the toolbox again. Cell arrays were used due to some fields being strings while
others are numeric values, as well as the fact that GUI tables use cell arrays as the variables
from which they import the data to display. Adding values to these arrays will be discussed in
10
the sections concerning the addition of Generation and Storage entries (§3.3.1 and §3.3.2).
Both tables also allow the user to edit most of the fields of an entry already added, which
means that you can add several entries without filling each of the technical characteristics
and then edit them in the table directly. However, some notes must be made regarding this:
a. Some fields can’t be changed at all, such as Type and Fuel. Since there only a finite
number of Types and Fuel types modelled in the toolbox, as well as other functions
being dependent on reading this field, the user is not allowed to change them by
hand;
b. The restrictions regarding the technical values while editing them as much more lax
(that is to say there are none) than when filling them individually in the Entry
Addition Windows. While these were placed there to avoid non-physically possible
values being defined, while editing fields directly in the table such can happen,
leading to the toolbox spitting out weird values or not being able to run at all. For
unexperienced or distracted users it is recommended to avoid editing fields in the
tables;
3. The Storage Table works in a similar fashion to what was discussed in point 2, concerning
the Generation Table, Data_Storage is the cell array that governs this table;
4. The General Definitions panel contains a set of check and radio buttons and edit fields. A new
field is added to the handles structure of the Initial Window at its creation called Flags. Flags
is a structure as well and contains several fields that will have logical (for the check and radio
buttons) and double (edit fields) variables. The logical fields have the default values
corresponding to the initial position of the check and radio buttons and are updated when
the user changes their position. When clicking the button Next Step, the current
handles.Flags structure is uploaded to a global variable called Flags. This variable may suffer
some additions to its fields in subsequent windows. The fact that the upload is made when
clicking Next Step, while the Initial Window itself is not closed when doing so, means that any
change to the General Definitions panel after the new windows are opened only takes effect
if you close them and click Next Step again. The meaning of each of them is discussed in
§3.2.1.
5. This set of check buttons, with the exception of Quit & Clean open new windows that are
discussed in the next sections. Be aware that while running the GUI windows, MatLab® is
11
using the GUI folder as its main directory (although some windows do a quick change of
directory that will be explained later on), so changing this folder’s name, or the functions
therein will result in the GUI not being able to run properly. Quit & Clean deletes the
Data_Generation and Data_Storage variables, so they are created as empty when running
the toolbox again
6. These buttons also prompt the appearance of new windows that are discussed and shown in
detail in their respective sections (§3.4.1 and §3.4.2);
3.2.1 General Definitions
Manual
The General Definitions panel displayed in Figure 4 contains every item with its respective default
value, that is, the value that they have when first opening the Initial Window without changing
anything. Here the effect of each of these fields will be addressed:
Detailed Results - Pretty self-explanatory, determines whether the user gets more or less
detailed result at the end of the simulation. This refers only to the results presented in the
command window, as the ones that are presented in Figures are independent;
Min Up/Down Times - Determines whether the model will use the Min. Up and Down Times
inserted for each entry. If not selected, the Min. Up/Down times are defined as 0 for every
entry, regardless of the values inserted, and the simulation will be run disregarding the
values inserted;
Ramp Up/Down Rates – In a similar logic to the previous point, if unselected, the Ramp
Up/Down Rates are defined as infinite (shortened to Inf, as per MatLab® notation, from now
on) for every entry and the simulation is run disregarding the inserted values (NOTE: The
Muditha version of the toolbox contained an algorithm that used Ramp values different from
Inf, however this was removed in the Guzzi version, most likely due to problems running it
for his case, and because the ramp rates of his case were high enough that he could regard
them as infinite. I’ve attempted to reinsert the algorithm, since I believe the simulation of
Ramp Rates to be an important aspect of the toolbox, however it has not been extensively
tested, since for my test case the rates were also high enough as to use Inf, use at your own
risk);
12
Long Term Calcs. - Decides whether the toolbox performs Long Term Calculations after
running the simulation or not;
Complete Enumeration / Priority List - Only one of these may be selected, and it determines
the way the model defines the priority list of the entries. Complete Enumeration, as the
name indicates lists all possible combination of states of the entries (turned on or off), which
is unfeasible for large systems (2N states, resulting in an [N X 2N] matrix, N being the number
of entries, quickly overloading MatLab® memory), so Priority List is the default one. Complete
Enumeration has also not been exhaustively tested after the toolbox generalization, due to
its usage restriction to small systems;
Up/Down Spinning Reserve - Definition of the upper and lower spinning reserve (also
referred to as operational reserve) as a percentage of the demand profile. I would
recommend some research into the concept of spinning reserve, but you can understand it
as a margin that the system has to have to be able to respond to unexpected spikes in the
demand requirements. For example an upper operational reserve of 10% means that the
Generators (generation entries) are able to increase their power to respond to an increase of
up to 10% in the expected demand requirement for a given hour;
Number of Predecessors - This definition concerns the algorithm that optimizes the best
“path”, regarding the possible states of the generation entries. Although it’s difficult to
explain without going into much detail about how the optimization, for each hour, the
algorithm takes the current state of the entries (which ones are turned on and off) and, from
the list of feasible states for the next hour (the states that satisfy the predicted demand
while respecting the operational reserve constraints) selects the cheapest one. The
connection of the feasible state selected for each hour, through all the hours shall be
referred to as a “path”. With one predecessor, only one final path is obtained, since for each
hour he only tests the cheapest next feasible state for one of the previous feasible states.
With more predecessors, for each hour he will test next feasible states for more previous
feasible states, therefore obtaining more “paths” at the end of the optimization. These
“paths” are finally compared to see which one is the cheapest and that one is selected as the
solution. (NOTE: This whole explanation is somewhat theoretical, derived from the
understanding of the algorithm code rather than actual experimentation, since I’ve not used
any value different from 1 for Number of Predecessors during my time with the tool. I didn’t
see anything in the code that would prevent the program from working for different values
13
of it, and the explanation above appears to correctly explain how it enters in the algorithm.
However take it with a grain of salt and run it with different values at your own risk);
Ren. Energy Allowed - This field gives the user the chance to define the amount of
Intermittent Renewable Energy that is allowed in the system, as a percentage of the demand
for each hour. (NOTE: Be aware that, at the moment, intermittent renewable only concerns
Solar PV and Wind type entries. The curtailment of energy is made indiscriminately into both,
without any priority, unless you edit the Generation Table in the fields regarding Fuel Cost, to
give the Wind and Solar PV entries a cost different from 0, therefore changing their priority
definition. This might, however, result in a distortion of the costs calculated at the end of the
simulation);
Technical Data
Like it was already mentioned in point 4, on the Technical Data section of §3.2, all information
regarding this panel is stored in the handles.Flags structure and imported to a global variable Flags,
also a struct, when clicking the Next Step button. Below are some notes important for each field:
Detailed Results - Logical variable, its corresponding field in the global Flags struct will be
used inside the Main script;
Min Up/Down Times - Logical variable, used in the Main script;
Ramp Up/Down Rates - Logical variable, used in the Main script;
Long Term Calcs. - Logical variable, used in the Main script, decides whether it runs the
long_term_calcs.m function;
Complete Enumeration / Priority List - Logical variable called CompleteEnu, “true” runs
complete_enumeration.m and “false” runs priority_list.m, both called in the Main script;
Up/Down Spinning Reserve - Double variables, edition of the field is limited to values
between 0 and 100, and they are stored as decimal values (0.21, for example);
Number of Predecessors - Double variable, edition of the field limited to round numbers,
higher than 1, and different from Inf;
Ren. Energy Allowed - Double variable, edition of the field limited to values between 0 and
100, stored as percentage value (21, for example);
14
In the handles.Flags struct of Initial Window, two fields called DemRes and GoAhead are also created,
with the default values of “false”. The first one decides the usage of a Demand Response algorithm
that is currently still being worked on (see §5.1.2 for details), and the second makes the connection
with the Main script, giving it the order to advance to the simulation, after running the GUI Windows,
when they close, or not run it in case they are closed without wanting to run a simulation.
3.3 GUI_Add_Entry_Generation/Storage
3.3.1 GUI_Add_Entry_Generation
Manual
When clicking the Add Entry button in the Initial Window, the Add Entry Generation Window,
depicted in Figure 5, will appear. For this window, the numeration of its components will be
unnecessary, since they are properly identified and grouped in titled panels.
Figure 5: Add Entry Generation Window of the toolbox
Filling the fields and selecting options on the popup menus on this window allows you to customize a
generation entry to be added to the system. In case you don’t fill any of the fields, the values shown
in Figure 5 represent the default values that will be used for the entry added, with the exception of
15
the Name field, as discussed below. Below are some important details regarding each set of
parameters:
Type - Defines the type of the entry that will be added. Since this affects how the ED model
handles the entry, it is a non-customizable field in the Generation Table and therefore
cannot be changed once the Generation entry is added. Figure 6 shows the selectable types
in the current version of the toolbox;
Figure 6: Current selectable types of Generation entries
Name - This determines the Name the entry will have when presenting results and outputs
of the simulations. Entries for which you don’t fill out this field will be known as “John Doe”.
Adding several unnamed entries will result in difficulty in distinguishing them, especially for
large systems, so it is recommended you don’t do it. This field is editable in the Generation
Table;
Power - Parameters in this panel concern power and ramp rates of the entry. All fields can
be edited in the Generation Table:
o P Max [kW]: The maximum dispatch able power of the entry (in kilowatts);
o P Min[kW]: The minimum power at which the entry can operate (in kilowatts);
o Ramp up [kW/h]: Ramp up rate of the entry, when increasing power (in kilowatts per
hour);
o Ramp down [kW/h]: Ramp down rate of the entry, when decreasing power (in
kilowatts per hour);
Constraints - Working time constraints and initial definitions:
16
o Min up time [h]: The minimum time that the entry has to be working for, once
turned on, before it can be shut off again (in hours);
o Min down time [h]: The minimum time that the entry has to be down for, once it was
turned off, before it can be turned on again (in hours);
o Initial State [h]: Determines the initial state of the entry in the simulation, that is, the
value that the entry has for the 1st hour simulated. Use negative values to describe
being shut down (-3 means the entry has been off for 3 hours) and positive values
for entries that you want to have been on (3 means the entry has been on for 3
hours). NOTE: There is a restriction in place to prevent this field being filled as 0, but
none in place when editing the value directly in the Generation Table. Using 0 as the
Initial State of an entry usually causes errors when running the dispatch algorithm;
when in doubt, leave it with the default value;
Direct Costs - Variables concerning direct costs associated with the entry:
o Cold Start [€]: Cost of turning on the entry when it is off (in Euros). When calculating
the hourly costs, the Cold Start Cost (for the hour in which the entry is turned on) is
summed to the Fuel Consumption Cost (if they exist), resulting in the Production
Costs;
o Hot Start [€]: (NOTE: This value is currently not being used in the toolbox) Cost of
starting the entry when it was turned off without having time to cool down (in
Euros). See Technical Data section and §8.2.2 for more details;
o Shut Down [€]: Cost of turning the entry off when it is dispatching power (in Euros);
Fuel - This panel allows you to change the Fuel Type used by the entry and customize its fuel
consumption curve through the Characteristics button:
o Fuel Type: The popup menu here allows you to select the Fuel Type for the entry
being created. You can only change the Fuel Type for some other than None for
Thermal entries. Cannot be edited in the Generation Table. Figure 7 shows the
currently available Fuel types that can be selected;
17
Figure 7: Available Fuel types
o Characteristics: Clicking this button will prompt the appearance of the Fuel
Characteristics Window, only if the Type currently selected is Thermal. In this
window (discussed in §Error: Reference source not found and shown in Figure 8) you
can edit the fuel consumption curve of the entry;
Project Analysis - This panel concerns definitions for Long Term Calculations:
o Annual Costs [€]: Cost of acquiring the equipment, considered yearly during its
lifetime (in Euros);
o Fixed Op. Costs [€/kW/year]: Fixed yearly operational and maintenance costs of the
equipment (in Euros per power per year);
o Var. Op. Costs [€/kWh]:Variable operation and maintenance related costs (in Euros
per energy produced);
o DR [%]: Discount Rate, in a percentage value (21, for example) (figure shows IRR, but
that was corrected);
o Lifetime [y]: Lifetime of the equipment, in years (number of years the equipment is
predicted to last in operation);
Bottom Push Buttons:
o Storage Unit: Closes the Add Entry Generation Window and opens the Add Entry
Storage Window (discussed in §3.3.2);
o Add: Adds an entry to the system with the characteristics inserted. Pressing this
button does not close the Add Entry Generation Window or resets any of its fields to
default values. Therefore, you can add more entries to the system by changing the
fields and pressing Add again, after adding a first one;
18
o Done: Closes Add Entry Generation Window. Does not save currently inserted values
in any field;
Technical Data
With the exception of the Type, Name and Fuel Type (strings), all variables defined in this window are
defined as double. The default values are the ones shown in their respective fields when first opening
the Add Entry Generation Window. Some fields are subjected to editing restrictions to avoid the
insertion of non-feasible values and strings inserted in numeric fields. In case a value is edited to
something outside of the allowed scope of values, that field is reset to its default value. The
restrictions are:
Power:
o P Max and P Min cannot be defined as values lower than 0, or as Inf;
o Ramp Up/Down Rate cannot be defined as lower than or equal to 0;
Constraints:
o Min up/down time cannot be lower than 0;
o Initial State cannot be defined as 0 or Inf;
Direct Costs:
o Cold Start, Hot Start and Shut Down - Values below 0 and Inf are not accepted;
Project Analysis:
o Annual Costs, Fixed Op. Costs, and Var. Op. Costs cannot be lower than 0 or Inf;
o DR cannot be defined higher than 100 or lower than 0 (figure shows IRR, but that
was corrected);
o Lifetime has to be higher than 0 (minimum 1 year) and cannot be Inf;
A struct is created as a field on the handles struct to store all the changes to the fields done by the
user. When pressing Add, the function “Add_Entry_Generation.m” converts the struct into a cell
array vector and concatenates it with the Data_Generation cell array matrix. In practice this is just
like adding a new line to a matrix, with the exception that it is a cell array (the Data_Generation cell
array is treated like a matrix with entries of both the string and double type).
19
3.3.1.1 GUI_Fuel_Characteristics
Manual
In the Fuel Characteristics Window (shown in Figure 8), you can define the parametres of the thermal
generators’ fuel consumption curves. These curves will determin the priority order between entries
labelled Thermal, for the ED Model will try to minimize the fuel consumptions costs for these entries.
In the current version, fuel consumption curves are assumed to be linear, and these are the only type
of curves that can be defined. Therefore, the figure in the Fuel Characteristics Window shows a
straight line with indications as to the nomenclature of the values that need to be filled to define the
curve. For the fuel consumption curve the following need to be defined:
NOTE: Although the figure uses the unit Litre for the Fuel Unit, the way the toolbox is configured
allows you to define the curves for other units, and the calculations will just be made in that unit.
This is because some generators might not be comparable when converted to Litres (for example
Natural Gas generators’ curves would probably be better off defined in terms of m3, making m3 the
Fuel Unit considered for this case). The results presented in the outputs should make sense as long as
you are consistent in the definitions, for each generator.
No-load Cost (NLC) [FU/h]: The fuel consumption (in Fuel Units per hour) when the generator
is working at 0 power. This value is obtained by linearly extrapolating the fuel consumption
curve to see where it would cross the vertical axis (according to the notation of Figure 8).
Since most thermal generators have a minimum working power and a non-linear fuel
consumption curve this is usually a purely theoretical value, however it can be understood as
the fuel consumption that the generator needs to beat internal friction and work without
dispatching power;
Inc. Heat Rate (IHR) [FU/kWh]:The Incremental Heat Rate of the generator is the slope of the
curve when it is linear. It defines the increase in consumption of fuel required to go from one
working power to another;
20
Figure 8: Fuel Characteristics Window
There are 2 more parameters that are defined in this window, not directly related with the fuel
consumption curve. These are:
Fuel Cost [€/FU]: The cost of purchasing one unit of the fuel used by this generator. This
value is important for the model as it will help define the priority of the thermal generators.
Thermal generators with lower fuel consumption costs (Fuel Consumption Cost = Fuel Cost *
Fuel Consumed) will be used more frequently by the model, in order to minimize the
production costs;
Emissions [kgCO2eq / FU]: The value of emitted kilograms of CO2eq per each unit of fuel
consumed in the considered generator. Although this value is not used as a decision value by
the model as of yet, the resulting emissions are calculated for all generators and presented
in the outputs of the toolbox.
When pressing Confirm the values filled in will be updated and the window will close. Clicking Cancel
will close the window without updating changes or saving any edited values.
Technical Data
All variables stored in this window are of the type double.
21
When the Add Entry Generation Window is opened, a struct is created in the handles struct of that
window inside of which there is a field called “Fuel”. Inside the handles struct of the Fuel
Characteristics Window a struct called “Fuel” is created and altered when the user edits the fields in
this window. When clicking Confirm this “Fuel” struct is used to update the values in the “Fuel” struct
created in the previous window, through the magic of Global variables.
3.3.2 GUI_Add_Entry_Storage
Manual
If you click the Storage button in the Add Entry Generation Window, that window will close and the
Add Entry Storage Window will pop into existence (shown in Figure 10). Similarly to the Generation
one, in this window you can edit the fields respective to a Storage entry you wish to add to the
system. Just like before, let us go field by field, explaining their meaning:
Type - Defines the type of the entry that will be added. Since this affects how the ED model
handles the entry, it is a non-customizable field in the Storage Table and therefore cannot be
changed once the entry is added. Figure 9 shows the selectable types in the current version
of the toolbox;
Figure 9: Current selectable types of Storage entries
Name - This determines the Name the entry will have when presenting results and outputs
of the simulations. Entries for which you don’t fill out this field will be known as “Jane Doe”
Adding several unnamed entries will result in difficulty in distinguishing them, especially for
large systems, so it is recommended you don’t do it. This field is editable in the Storage
Table;
22
Figure 10: Add Entry Storage Window
Characteristics - Parameters in this panel technical definitions of the entry. All fields can be
edited in the Storage Table:
o Capacity [kWh]: The energy storage capacity of the entry(in kilowatt-hour);
o Charge Rate[kW]: The maximum charging rate of the storage system (in kilowatts);
o Initial SoC [%]:The initial State of Charge, in the first hour simulated, of the storage
system (as a percentage of its Capacity);
o Eq. Fuel Cost [€ / FU]: The Equivalent Fuel Cost of the storage entry (in € per Fuel
Unit). This allows you to define a cost of dispatching storage energy, therefore
allowing you to change the priority of the storage system in the dispatch order;
Efficiencies – Definitions related with efficiency:
o Charging Efficiency [%]: Energetic efficiency of the charging process of the storage
entry;
23
o Discharging Efficiency [%]: Energetic efficiency of the discharging process of the
storage entry;
o Customize (N.I.): N.I. stands for Not implemented. Reserved for future
implementation. The idea was to insert a dependence of the charging and
discharging efficiency on the State of Charge of the storage system, through some
curves. See §8.2.3 for more details;
Project Analysis - This panel concerns definitions for Long Term Calculations:
o Annual Costs [€]: Cost of acquiring the equipment, considered yearly during its
lifetime (in Euros);
o Fixed Op. Costs [€/kW/year]: Fixed yearly operational and maintenance costs of the
equipment (in Euros per power per year);
o Var. Op. Costs [€/kWh]:Variable operation and maintenance related costs (in Euros
per energy produced);
o DR [%]: Discount Rate, in a percentage value (21, for example) (figure shows IRR but
that was corrected);
o Lifetime [y]: Lifetime of the equipment, in years (number of years the equipment is
predicted to last in operation);
Bottom Push Buttons:
o Generation Unit: Closes the Add Entry Storage Window and opens the Add Entry
Generation Window (discussed in §3.3.1);
o Add: Adds an entry to the system with the characteristics inserted. Pressing this
button does not close the Add Entry Storage Window or resets any of its fields to
default values. Therefore, you can add more entries to the system by changing the
fields and pressing Add again, after adding a first one;
o Done: Closes Add Entry Storage Window. Does not save currently inserted values in
any field;
24
Technical Data
With the exception of the Type and Name (strings), all variables defined in this window are defined as
double. The default values are the ones shown in their respective fields when first opening the Add
Entry Storage Window. Some fields are subjected to editing restrictions to avoid the insertion of non-
feasible values and strings inserted in numeric fields. In case a value is edited to something outside of
the allowed scope of values, that field is reset to its default value. The restrictions are:
Characteristics:
o Capacity cannot be lower or equal to 0 or equal to Inf;
o Charge/Discharge Rate cannot be lower than 0;
o Initial SoC has to be between 0 and 100;
o Eq. Fuel Cost [€ / FU] cannot be lower than 0 or Inf;
Efficiencies:
o Charging/Discharging Efficiency have to be between 0 and 100;
Project Analysis:
o Annual Costs, Fixed Op. Costs, and Var. Op. Costs cannot be lower than 0 or Inf;
o DR cannot be defined higher than 100 or lower than 0 (figure shows IRR, but that
was corrected);
o Lifetime has to be higher than 0 (minimum 1 year) and cannot be Inf;
Similarly to the Generation case, a struct is created as a field on the handles struct of this window to
store all the changes to the fields, done by the user. When pressing Add, the function
“Add_Entry_Storage.m” converts the struct into a cell array vector and concatenates it with the
Data_Storage cell array matrix, like adding a new line to a matrix.
25
3.3.3 GUI_Delete_Entry
Manual
After adding entries to either the Generation or the Storage Tables, you can delete entries, by
pressing the Delete Entry button. Doing so will prompt the appearance of the Delete Entry Window
(Figure 11).
Figure 11: Delete Entry Window
In this window, you can insert the number of the entry you wish to delete from either of the tables
and click Delete to do so. The radio button lets you select which type of entry you wish to delete
(Generation or Storage). If there are no entries of the selected type or the inserted entry doesn’t
exist, it doesn’t do anything, without warnings.
The respective table will only be updated when you close this window and right click on it. When
deleting multiple entries, especially if the one you delete is between others, the numbers will change
(if you delete entry 4 in a system that has 5 entries, the old 5 will now be number 4). To avoid
mistakes when deleting multiple entries, it is recommended to close this window and update the
tables after each entry you delete.
Technical Data
This code correspondent to this window only has some restrictions to avoid attempts to clear
nonexistent entries. When you press Delete it simply clears the line correspondent to the entry
number inserted by the user, in either the Data_Generation or Data_Storage array matrix.
26
3.4 GUI_Save/Load_Data_Sets
Manual
To avoid having to create the microgrid system all over again when you wish to run simulations for
another one, or when shutting down MatLab®, there is the possibility of saving and loading created
systems. In this section the windows that appear when pressing the Save and Load buttons in the
Initial Window will be looked at and their functionality will be discussed.
3.4.1 GUI_Save_Data_Sets
Manual
Pressing the Save button in the Initial Window will prompt the appearance of the Save Data Set
Window (Figure 12). In this simple window, all you need to do is insert the name under which you
wish to save the currently created system. The system will be saved under the inserted name in the
folder "Saved_Data_Sets” (inside the “Toolbox” folder) and will be available for loading through the
Load Data Set Window (§3.4.2).
Figure 12: Save Data Set Window
Two important notes must be made regarding the saving function:
Saving under the same name as an already existent system will simply override the previous
one, without any warning;
Altering the name of the folder “Saved_Data_Sets” may result in errors in this function, so
please abstain from doing it. Should it happen simply create a new one in the “Toolbox”
folder with the exact name “Saved_Data_Sets” or undo the modifications;
27
Technical Data
The code in the “GUI_Save_Data_Sets.m” function is quite simple. A new field in its handles struct is
created with the name Name to store the string inserted by the user in the editable field. When
clicking save, the code simply changes directory to the “Saved_Data_Sets” folder and saves the
variables Data_Generation and Data_Storage there under the name stored in the Name field.
3.4.2 GUI_Load_Data_Sets
Manual
After saving created systems, you can load them in future uses of the toolbox using the Load button.
Clicking it will open the Load Data Set Window (Figure 13 shows an example of said window). If there
are no saved systems a warning message will instead pop up. In the Load Data Set Window, by
selecting the entry you wish to load (clicking it until a blue outline is seen over that entry) and clicking
Load you can recover the saved system in order to further modify it or run simulations with it. The
window also shows the creation date of each of the saved systems.
Figure 13: Load Data Set Window (example)
NOTE: The Load Data Set Window only lists the saved systems inside the “Saved_Data_Sets” folder,
not inside any of its subfolders. Therefore, if you only have subfolders inside, the warning message
claiming there are no saved systems may appear when you click Load in the Initial Window. The
saved data that you wish to load must be inside the “Saved_Data_Sets”, and not inside any
subfolder.
28
NOTE: If you press Load in the Load Data Set Window without selecting an entry the first one listed
will be loaded by default. Apologies but this was done to prevent errors when pressing the Load
button without a selected entry.
Technical Data
The code in the “GUI_Load_Data_Sets.m” is also not very complicated or long. The “dir” command is
used to store the list of names and dates of the variables stored inside the “Saved_Data_Sets” folder.
This list is then presented on the table in the Load Data Set Window. When the user clicks on an
entry in the table, the line selected is saved in the handles struct, in a field called Selected_Entry
(default value is 1, when the window is created to prevent errors). Clicking the Load button loads the
variable with the same name as the one selected in the table from the “Saved_Data_Sets” folder.
This was not tested extensively for the case of entries saved with names too long to be presented
completely in the table; there may be some errors there. Just avoid long names and all this should
work just fine.
29
4 CHOOSING A SIMULATION TYPE
Manual
After creating your energy microgrid it is time to select which type of simulation you wish to run for
it. When pressing the Next Step button it the Initial Window, a new window will appear, asking you to
select which simulation you wish to run at that time. Currently only 2 types of simulation are
available, and they are shown and discussed in the following sections of this Manual.
4.1 GUI_Simulation_Type_Selection
Manual
Figure 14 shows the Simulation Type Selection Window. Here you can select the type of simulation
you wish to run. Currently, two types of simulations can be performed, and the windows that appear
after pressing Confirm depend on the type selected. The choice is between a “Typical Day
Simulation” (you manually fill out the data for a time period of 24 hours) and a “Custom Length
Simulation” (the data is imported from an excel file you can fill with the data you have, making it
possible to simulate any time length desired).
Figure 14: Simulation Type Selection Window
Technical Data
The selection performed in this window is stored in the Flags variable, in the field “Typical_day” (true
for typical day simulation, false for custom length simulation). The value of the flag will affect which
windows appear next and decide between running some code blocks in the “Main” script.
30
5 SIMULATION TYPE 1: TYPICAL DAY SIMULATION
Manual
In this section, the first type of simulations that can be performed in the toolbox will be analyzed.
When selecting a Typical Day Simulation, the user can customize the demand profile and renewables
availability for a period of 24 hours manually.
5.1 GUI_Demand_Configuration
Manual
After selecting this type of simulation in the Simulation Type Selection Window, the Demand
Configuration Window will appear (shown in Figure 15).
Figure 15: Demand Configuration Window
This window is divided into three areas: the Demand Profile Table, the Demand Increase Table and
the Demand Graph. Since that last one is simply a plot of the Base/Modified Demand profiles
obtained by messing around with the other two, it will not be explained in much detail.
31
In the first table, the Demand Profile Table you can define what will be called the Base Demand
profile. This is done by filling the Base column with the values of the hourly demand (in kilowatts) for
the day you wish to model. After filling the table, pressing the Update button will show a plot of the
inserted values in the graph area (an example is shown in Figure 16).
If you wish to run the simulation for the demand profile inserted, simply press Next Step to open the
next window (Renewable Availability Window, discussed in §5.2). Otherwise, should you wish to
modify further the demand profile inserted, namely increasing it by adding specific types of units
(electrical vehicles, certain types of buildings, etc.), you can use the second table to do so
Figure 16: Demand Configuration Window with a plotted Base Demand profile
Interacting with the Demand Increase Table is done through the Add Entry and Delete Entry buttons,
below it. Following the same logic as the creation of a microgrid system in the Initial Window,
pressing the Add Entry button lets you access the Add Entry Demand Increase Window (in §5.1.1 that
window and the hidden columns of the Demand Increase Table are shown and discussed) where you
can select the type of entry you wish to add to the system. These entries all concern the demand side
(as opposed to the supply side considered in the Initial Window) of the microgrid, and cause different
kinds of increase to the Base Demand profile inserted. After adding entries, right clicking the table
will display the new entries added. Pressing Update will cause the plot to display both the Base and
the Modified profiles (as seen on Figure 17), if the table is not empty. Deleting entries from the
32
Demand Increase table is easier than for the tables on the Initial Window. Simply one of the fields of
the entry you wish to delete to select it (blue outline on the cell clicked) and press Delete Entry.
Save and Load buttons at the bottom of the window let you save and load demand profiles that you
wish to keep after finishing a MatLab® session. Both the Base and Modified profiles, as well as the
Demand increase entries will be saved and can be loaded at a posterior session to run simulations
with.
The slider at the bottom of the Demand Profile Table lets you access another column (seen in Figure
18) called Modified. This column is not editable; it is used merely for displaying the values of the
Modified Demand profile, since they may not be easy to consult on the plot.
Figure 17: Demand Configuration Window with Demand Increase entries
Pressing Next Step with a Modified Demand profile defined will use the Modified profile as the
demand profile for running the simulation.
Technical Data
The workings of this window have a lot of similarities with the Initial Window’s. When the window
first opens, the variables Base_Demand (vector) and Demand_Increase (cell array matrix) are
33
declared as global. If they are empty (due to no previous usage of the toolbox in this session),
Base_Demand is defined as a 24 entry vector of zeros and displayed as such in the Demand_Profile.
Otherwise, the values of the previous Base_Demand vector are imported from the variable to the
table. The same happens with the Demand_Increase variable. The function “Modify_Demand.m”
modifies the Base_Demand vector accounting for the Demand_Increase entries if it is not empty and
creates the Modified_Demand vector. This last one is displayed in the Modified column of the
Demand Profile Table and in the graph’s plot. Since it is not a global variable, the function
“Modify_Demand.m” will run again in the main script, in case the user gives the order to run a
simulation with Demand_Increase entries.
Figure 18: Modified column in the Demand Profile Table (empty - left; with entries - right)
Pressing Update will do one of two things, depending on whether there are Demand Increase entries
or not:
If there are no Demand Increase entries, the Update button will simply plot the Base Demand
values inserted in the Demand Configuration Table;
If there are Demand Increase entries, pressing Update will run the “Modify_Demand.m”
function, which consists of a simple application of Equation (1 (§5.1.1) to create the Modified
Demand profile. Information regarding the “Profiles” variable used in this function can be
found in §5.1.1. Afterwards both the Base and the Modified Demand profiles will be plotted
in the graph area.
34
NOTE: the variable that defines the number of time steps for the simulation in the “Main.m” script is
the DEMAND vector, most specifically, its “length” (NT = length (DEMAND) ) For typical day
simulations, DEMAND will be obtained from either the Base_Demand by itself, or the Base_Demand
affected by the Demand_Increase entries, and will always have a length of 24 entries (24 hours),
that’s why they are defined with a specific length in the functions related with this type of
simulations, without any concerns for generalization.
5.1.1 GUI_Add_Entry_Demand_Increase
Manual
Adding Demand Increase entries to the Demand Increase Table in the Demand Configuration Window
is done through the Add Entry Demand Increase Window (Figure 19), which appears after you press
the Add Entry button. In this window you can select from certain types of Demand Increase entries,
and between several profiles for each type, as well as customizing some basic parameters. Figure 20
shows the current selectable entry types and Figure 21 depicts the four profiles currently selectable
in the “Electric Vehicles” type, as an example.
Figure 19: Add Entry Demand Increase Window
35
Figure 20: Current selectable Demand Increase entries types
Figure 21: Profiles for the “Electric Vehicles” type
36
Pressing the Next and Previous buttons lets you browse through the profiles for each type. The Add
button works similarly to the Add Entry Generation/Storage Windows, adding you entry per click,
thus allowing you to add several entries per use of the window. Clicking the Done button will close
the window.
At the top of the window there are three customizable fields: Number, Unit Power [kW] and Peak
Hour. The last one is currently unavailable for all entry types (see §8.2.3 for more details). The first
two will allow you to customize how many entries (Number) and the power of each unit (Unit Power)
(in kilowatts) are added to the demand profile. As you can see the graphs are all displayed in terms of
% Unit Power, there fore the final addition to the Base Demand profile, for each hour is given by
Equation (1.
AdditionHour h=Nº entries×Unit Power×%Unit PowerHour h (1)
Technical Data
The main initial definition in this window is the creation of the Profiles cell array. The entries of this
variable correspond to the vectors and titles that are displayed in the graph of the Add Entry Demand
Increase Entry Window. In order to add a new profile, add its vector and title to the Profiles variable
(respecting the order of numeration of entries). The code automatically calculates the number of
profiles in the struct, so there shouldn’t be any need to alter anything else (unless, of course, you
spot a bug). The existing profiles inserted should all be properly identified in the code comments.
The addition of a Demand Increase entry works in the same fashion as the Generation and Storage
entries, with the concatenation of a cell array vector to a cell array matrix named
“Demand_Increase”. This concatenation is performed in the “Add_Entry_Demand_Increase.m”
function.
5.1.2 GUI_Demand_Response
Manual
Pressing the Demand Response button will prompt the appearance of the Demand Response Window
(example shown in Figure 22).
37
Here, the user can modify the “Fixed Demand” profile plotted (in kilowatts), which is defined as equal
to the “Base Demand” profile (Base of Modified demand profile) when first opening the window.
Only the “Flexible” column of the Demand Response Table is editable. Pressing the Update Plot
button displays the alterations made in the graph.
Figure 22: Demand Response Window (example)
The “Fixed Demand” can be understood as the lower boundary for the new profile that will be
created by the DR algorithm. It is calculated by subtracting each entry of the “Flexible Demand” to
the “Base Demand” profile. Therefore, its values cannot, for any hour, be higher than the ones in the
“Flexible Demand” profile. Attempting to edit a cell on the “Flexible” column with a higher value than
the corresponding one in the “Base” column will reset that cell’s value to the default one.
The algorithm only shifts loads, ensuring the sum of the new “DR profile” is equal to the one of the
old “Base Demand” profile. Therefore, should the “Flexible Demand” be all zeros (as shown in the
example on Figure 22), when pressing Confirm the Demand Response algorithm will not run, since
this would not result in any alteration to the demand profile inserted in the algorithm.
Should you modify the Flexible column (similarly to the example in Figure 23), the ED Model will run
twice (once for the initial Demand profile and another for the DR profile). At the end of both
simulations, a warning message will inform you whether the Total Production Costs for the “DR
38
Profile” were higher (in which case the results presented will concern the original demand profile) or
lower (results will concern the “DR Profile”).
Be aware that running two simulations means twice the simulation time. If the simulation time for
the base demand profile is high, the one for the “DR Profile” will not be very different, thus resulting
in two simulations ran for the results of one.
For an explanation and results concerning the DR algorithm, consult §4 and §6.2, respectively, of [2].
Understanding the algorithm and its implementation in the ED Model should help you assess
whether the increase in simulation time is worth the savings in production costs. Be aware that the
results are dependent of the definition of the “Fixed Demand Profile”.
This function was not extensively tested after implementation, so take caution with bugs that may
appear when running the program in imaginative ways (switching windows mid use, running it
several times in a row without cleaning variables, etc.).
Figure 23: Demand Response Window with modified “Fixed Demand” (example)
Technical Data
During the initialization of the window, fields called “Flex_Demand” and “Base_Demand” are created
in the handles struct. For the first time the window is opened in a session, “Base_Demand” is equal
39
to the global “Base_Demand” variable (24 entries vector), and “Flex_Demand” is a vector of zeroes.
Afterwards, if the user did not exit the window pressing Quit & Clean, the values previously inserted
are imported during the current MatLab® session.
A cell array called “Demand_Display” controls the Demand Response Table. Its 3 columns correspond
to 3 fields of the handles struct:
1. The “Hour” vector (simply 1:24);
2. “Flex_Demand”;
3. “Base_Demand”.
Some logical restrictions are placed in the editable callback function of the Demand Response Table.
These will cause the cells’ values to revert to their default if the user attempts to insert a value higher
than the one on the corresponding “Base” column.
A vector called “Fixed_Demand” is also created in the handles struct for display in the plot. Its entries
are the difference between the Base and Flex vector’s entries.
When Confirm is pressed, if the “Flex_Demand” field’s maximum is different from 0, it is exported to
a global variable called “Flex_Demand”. This will be used in the “Main.m” script, when calling the
“demand_response.m” function.
5.2 GUI_Ren_En_Avail
Manual
The final window when performing a Typical Day Simulation is called the Renewable Availability
Window. In this window (accessed by pressing Next Step in the Demand Configuration Window) you
can configure the availability of certain renewable resources, namely hydro, solar and wind. Figure
24 and Figure 25 showcase an example of an empty and filled Renewable Availability Windows,
respectively.
40
Figure 24: Renewable Availability Window
Currently two ways of inserting renewable availability are available to choose from:
You can either fill the Renewable Availability Table manually with the hourly available power
for each hydro, solar or wind entry in your system. The table is automatically configured
when you open the window so there will be one column for each of the entries. After filling
the table, pressing Update Plot will display the inserted values in the graph;
Using capacity factors, through the Daily Capacity Factor panel at the bottom of the window.
For the wind and solar entries the hourly capacity factors can be inserted on the Daily
Capacity Factors Configuration Windows (Figure 26), which appear when you press the Conf.
Wind/Solar button. This hourly capacity factors will be applied to all wolar/wind entries in
the system and the calculated power will be displayed in the Renewable Availability Table
and plotted when you press Confirm. In the hydro case, you can fill the edit field to define a
constant capacity factor for all hydro entries. Once again, pressing Calculate will
automatically calculate and display in the table and the graph the resulting power availability
for the hydro entries. In all these cases, the capacity factors should be inserted as
percentages (21, for example).
41
Figure 25: Example of a filled Renewable Availability Window
Similarly to previous windows, this one also has the Save/Load buttons to save and load inserted
renewable availability for future uses in simulations.
Pressing Previous Step will close the window, without saving any changes made. Pressing Run
Simulation will close all open windows (Initial, Demand Configuration and Renewable Availability
Windows) and run the ED Model for the inserted data.
NOTE: Since the Renewable Availability Table is automatically configured when you open the
window, for the created energy system in the Initial Window, should you wish to modify the system
at this point, be sure to close this window first. Otherwise errors may occur when you try to run the
simulation. For safety, the rule of thumb should be: when going back to a window to modify
something, make sure any subsequent windows are currently closed.
42
Figure 26: Daily Capacity Factors Configuration Windows
Technical Data
The initialization of the Renewable Availability Window contains the creation of structs called Indexes
and Names that contain how many entries of each type (hydro, wind and solar) are in the energy
system and their respective names. That information is then used to customize the Renewable
Availability Table, determining its number of columns accordingly and configuring the columns
headers as the names of the entries.
The save and load functions are exactly alike the ones already used in the previous windows, refer to
them should you have any questions or find any problem with its usage.
The code that creates and updates the plot is somewhat more complicated due to the creation of the
legend of the graph, where it features the names of the entries rather than generic names. It should
however be well commentated enough, that it shouldn’t be too hard to follow.
Calculations using the capacity factors are also extremely simple. The code imports the maximum
powers of the renewable entries from the “Data_Generation” cell array and multiplies these powers
by the inserted capacity factors.
43
When pressing Run Simulation the renewables availabilities are exported to a global variable called
“Ren_En_Avail”, a struct containing the number of entries of each type and their respective power
availability. This is the struct that is called upon in the “Main.m” script to define the available power
of hydro, wind and solar entries.
44
6 SIMULATION TYPE 2: CUSTOM LENGTH SIMULATION
Manual
In this section, the second type of simulations that can be performed in the toolbox will be analyzed.
In this type, the user selects the amount of data he wishes to import from an excel spreadsheet
previously filled with whatever available data he has. All this customization happens in one window,
the Custom Length Simulation Window. Therefore, there is only one window after the Initial Window,
when selecting this type of simulations.
6.1 GUI_Multi_Day_Sim_Definitions
Manual
Figure 27 shows the Custom Length Simulation Window. In it you can customize the time length of
the data you want to import from the excel spreadsheet and the way in which the renewables data is
imported from it.
Figure 27: Custom Length Simulation Window
The three panels in the upper half of the window (Start analysis at, Length of Data… and Resulting
Span) allow you to customize the amount of data to be imported from the excel spreadsheet. For
example, if the excel contained data for one year of operation and you wanted to do a simulation
correspondent to the second month, you needed only to insert in the first panel 1 Month and in the
second panel 1 Month and 28/29 Days (depending on if it is a leap year or not). The notes under the
panel let you know how many days (first line) and hours (second line) are added by each field, since it
the spreadsheet must be filled with hourly data. Lastly, the third panel helps you check the first and
45
last lines that will be imported from the spreadsheet, to help confirm the data length you inserted.
The checkbox is used to run the Demand Response algorithm (see §5.1.2 for more details).
The bottom panel (Renewables Data) lets you specify how the renewables data was inserted in the
excel, and how it should be handled by the toolbox. Currently you can insert the renewables data for
hydro, solar and wind energy in the ways shown in Figure 28. The fields labeled N.I. are not currently
implemented (see §8.2.3 for more details), therefore you can insert renewables availability as either
direct power or hourly capacity factors.
Figure 28: Selectable types of renewable data that can be inserted
Pressing the Instructions button displays a warning window containing some instructions to help fill
the excel spreadsheet. These can be seen in Figure 29, and should be understood and followed to
prevent any errors while attempting to run the simulation or in the results obtained.
Figure 29: Instructions for filling the excel spreadsheet
In Figure 30 an example of an excel spreadsheet used for running this type of simulation is
presented. The values shown are purely hypothetical.
46
Figure 30: Example of a filled excel spreadsheet
This example contains data for 1 day (24 hours) of operation, for a system that has no hydro plants
(empty hydro column), two solar plants with the solar availability inserted as “Power” (two columns
filled with solar availability, in kW) and one wind plant, with the wind resource being inserted as
hourly capacity factors (one wind column with decimal capacity factors).
Please note that empty or non-numeric cells in columns of existent renewable types will be
converted to 0 when importing the data from the excel.
Technical Data
The code in the ”GUI_Multi_Day_Sim_Definitions.m” function is rather long, due to the great number
of Edit Fields present in the window. Each of the Edit Fields should be properly identified with
comments and tagged, so use the search function (Ctrl + F) to find specific ones. The Edit Fields in the
Resulting Span panel are non-editable. They work merely as a display, conveying to the user which
lines will be imported from the excel. These are in a different section of the function than the other
Edit Fields.
When opening the window, an Indexes struct is created and stored as a field in the handles. The
Indexes struct uses the Data_Generation cell array matrix to read how many entries of each
47
renewable type (hydro, solar and wind) are present in the system, and their positions (entry
number). This information is then used when pressing Run Simulation to import the data from the
columns of the excel to the global struct named Ren_En_Avail. If either of the resources is defined as
Capacity Factor, the code simply performs the calculations for each renewable, multiplying its
maximum power by the capacity factor imported, and then stores the resulting power in the
Ren_en_Avail struct.
When importing the excel data to the Ren_En_Avail struct, the code has to change between letter
and numerical notation, since the columns in the excel file have to be accessed by their designation
letter. Afterwards, it simply creates a MatLab® matrix containing all the data “cut” from the
spreadsheet and works with the matrix itself. This is also part of what makes the code so long and
rather complicated to understand at first sight. Some patience is required to fully understand the
function related to this window, although it shouldn’t be necessary if it’s importing the data
correctly.
48
7 RESULTS & OUTPUTS
In this chapter, the results and outputs presented/given by the toolbox at the end of a simulation will
be analyzed. Regardless of the type of simulation performed, the results are always presented in the
same way, and the outputs are always of the same type. The only difference concerns the size of the
data: when a Typical Day simulation is performed, the data will concern the 24 hours simulated,
while a Custom Length simulation will present the data for the number of hours selected. Results and
outputs will only be presented if the simulation is able to finish, that is if the model completes its
optimization without any problems (failing to find feasible states for an hour and inability to respect
operational reserve constraints are the two main impediments for finishing a simulation, and each
has a correspondent warning window that will warn you of the occurrence).
NOTE: A bug has also been noticed where the toolbox will finish running the simulation without any
of the problems mentioned above but will then be unable to perform the final calculations. This is
signaled by a typical error message in the MatLab® command window, presenting the calculation that
failed. After looking into it, it was seen that the optimization was letting an hour for which there were
no feasible states bypass the simulation interruption, and was therefore defined as all the generators
with Inf energy production, resulting in an inability to compute further calculations that required a
finite production value. To this date, I’ve not discovered why this happens, but it had a low incidence
in the scope of all the simulations run (about 2 times in over 500 simulations).
Here, the distinction between Manual and Technical Data will be abandoned, and the relevant
results and outputs of the toolbox will be presented and discussed.
7.1.1 MatLab® Command Window
Part of the results will be presented in the form of text printed in the MatLab® Command Window.
While running the simulation, the window will be filled with the current hour the model is currently
optimizing (example in Figure 31), followed by data regarding some parameters for each of the
simulated hours (example seen in Figure 32).
49
Figure 31: Example of Command Window text during the simulation
Figure 32: Example of data printed in the Command Window at the end of the simulation
7.1.2 Figures
When the simulation finishes, two windows (called “Figure 1” and “Figure 2”) will appear. These
provide different types of information and are show below in Figure 33 and Figure 34. “Figure 1”
contains dispatch information, for both the Generation and Storage entries, as well as presenting the
50
demand profile simulated, for comparison. “Figure 2” relays the production shares by technology
type, as well as the specific parameters of thermal generators (Costs, Emissions and Fuel
Consumption).
Figure 33: “Figure 1” Window
Figure 34: “Figure 2” Window
51
If you selected the Long Term Calculations option, a third window will appear, displaying the values
of LCOE (Levelized Cost of Electricity) and NPC (Next Present Cost) calculated for each entry.
7.1.3 Relevant Outputted Variables
While a great number of variables are created during the working of the toolbox, the most relevant
ones are here listed. In these structs, the user can consult important calculated values that may be
difficult to obtain from the figures or not presented in either the figures or the Command Window.
All the variables mentioned below are stored at the end of the simulation, in the “Results” folder, as
a MatLab® variable file, under the name “Last_Run_Results.m”. However only the data for the last
run is stored and it is overridden every time you run a new simulation.
“Last_Run_Results.m” will contain the following variables:
“DEMAND” ([NT x 1] vector): demand profile vector (NT is the number of time steps, equal to
24 for the Typical Day Simulation);
“Costs” (struct): a struct containing the costs calculated for the simulation. Contains the
following fields (these fields are the same used in the other saved strucs, unless stated
otherwise):
o Hourly_Gen ([NG x NT] matrix): hourly costs for each entry (NG is the number of
entries of the system);
o Hourly_Total ([NT x 1] vector): hourly total costs;
o Gen_Total ([NG x 1] vector): total costs for each entry;
o Total (double): the value of the total costs for the simulation;
o Fuel_Type (struct): costs for each fuel type for the thermal generators. Its fields are
the fuel types available for selection for the thermal generators.
“Specific_Costs” (struct): contains the normalized costs considering the produced power.
Divided in the same fields as “Costs”;
Emissions (struct): contains the CO2eq emissions calculated for the simulation. Same fields as
the previous structs;
52
Specific_Emissions (struct): normalized CO2eq emissions considering power production. Same
fields as the previous structs;
Production (struct): values of energy production. In addition to the same fields as the structs
exposed above, it has two additional ones:
o Hourly_Technology (struct): power produced hourly by each technology type;
o Production.Technology (struct): total power production divided by technology type:
Fuel_Consumption (struct): contains the calculated fuel consumption for each entry. Only
has three fields (Hourly_Gen, Gen_Total and Fuel_Type);
Specific_Fuel_Consumption (struct): contains the calculated fuel consumption, normalized
considering the energy production. Only has three fields (Hourly_Gen, Gen_Total and
Fuel_Type);
Shares (struct): struct containing the energy production shares of each entry. Its fields are
the names of the entries of the system;
Long_Term (struct): If the Long Term Calculations option was selected, this struct will also be
an output variable saved. It contains the NPC and LCOE fields, containing its calculated values
for each entry of the system. NOTE: An “Inf” LCOE value means that the unit in question had
a null energy production during the simulated time, resulting in infinity (Costs/Energy)
53
8 SUGGESTIONS FOR FUTURE WORK/IMPROVEMENTS
In this section, the notation for Manual and Technical Data will be abandoned. The reason for that is
that this whole section is directed to anyone that wishes to continue working in the development of
this toolbox.
Here some suggestions for future improvements or modifications of the toolbox will be enumerated.
Some were already mentioned in other chapters, while others are more general and don’t concern
any specific window or function. A few of these ideas arrived during my work and were not
implemented due to lack of time, or decisions to focus on other functions. Some may concern
problems regarding functions of the toolbox that again, due to lack of time were not corrected. All of
them are merely suggestions for improving the toolbox, since it seems to be operating in a rather
satisfactory way.
My thesis [2] should also have a chapter devoted to suggestions for future improvements.
Nevertheless, they should be easier to explain here, after all the explanation regarding the inner
workings of the toolbox, which I could not put on the thesis without going way above its page limit.
Therefore, I reckon that reading the suggestions chapter of the thesis will not add anything new to
what is said in this chapter, but feel free to take a look and confirm by yourself.
8.1 Code/Programming related improvements
The following are related to technical improvements at a programming level, related to the
computational code itself
8.1.1 General tweaks/improvements/corrections
In case I haven’t already mentioned, I’m a mechanical engineering student. This means that my
studies were not focused in programming. My knowledge of programming is limited to a basic
degree of general theory of programming and I’ve only ever practiced it on MatLab®, which is a
programming language so simple, I’m not even sure it can be called that (I usually use the term “tool”
when referring to it, but what do I know?).
All this, combined with the fact that the code has already gone through several other people,
culminates in:
54
There will most likely be bugs that escaped my tests;
There will be redundancies/useless blocks in the code;
Surely there are some functions that can be performed in more efficient ways (saving
computational time, which I discuss below);
Therefore, given my limited knowledge of programming related issues, instead of boring you with a
point-by-point analysis of what should be improved in the code, I’ll leave it to the better judgment of
future developers, and ask for some patience when handling this code. That’s why most of the
suggestions in this section will not be regarding programming matters (excluding this and the next
one, which I believe is actually important enough to be mentioned).
One bug that was noticed but unable to correct due to lack of time is described in the NOTE in §7,
and will probably pop up if enough different simulations are run. It would be a good place to start
when attempting to correct bugs and programming related issues.
Other important aspect that should be corrected is the fact that errors aroused when simulations
were run with systems that contained no thermal generators. To avoid these errors, conditions in the
code were set in place to prevent simulations from being run with systems that would result in these
errors. However, this discards the possibility of modelling systems that are 100% renewable, when
the model should theoretically do so without any problems. It would be interesting to have the
toolbox able to model 100% renewable systems, especially if the priority definition discussed in
Section §8.2.1 is implemented. The errors probably came from the core of the ED Model searching
for fuel consumption curves of thermal generators at some point and not being able to find them.
Which means that some tweaking of the core model should be done for it to work properly when
there are no thermal entries, which shouldn’t be very hard, once the code is understood
So, I’ll finish this by saying that if you are working on this toolbox and you have enough patience to
try to improve it from a programming point of view, please do so. I’ve tried to “clean” the existing
code of useless definitions, redundancies, etc. and comment it, but there should be much to be done.
I’ve also tried to do my parts of the code as clean as possible, but again, if you know a better way of
doing it, implement and modify it so future developers and users can benefit from it.
55
8.1.2 Computational speed
The only reason why cleaning the code might actually be relevant at some point in the development
of the toolbox is related with the computation speed of the simulation. To clarify, in this section, the
“simulation time” referred to is the one that appears referred to as “Elapsed time: “ in the command
window, after running a simulation. This time concerns only what it took to run the ED Model itself,
after the insertion of data in the GUI is completed and the GUI is closed.
After generalizing the code, an increase in the time that it took to perform simulations was noticed.
This is obviously expected, as the generalization of the code involved addition of blocks of code,
mainly several “if” conditions, which are, to my knowledge, the dread of MatLab®’s speed. The only
reference I have for such a declaration is the Terceira island simulations, since the code last worked
on by Guzzi, F. [3] was adapted for that case, and the files I received contained the Terceira data.
After testing the toolbox for the Terceira case before and after generalizing, I found that the
simulation time went from about 30 seconds to about 1/2 minute. This time varies according to the
day selected within the data available. In order to discard the possibility that my somewhat outdated
computer might have something to do with the increase in the simulation time, some were run and
compared in other computers, with better processors, and no discernible difference was noticed.
Although this increase still left the simulation time within acceptable values for the Terceira case,
when running for more complicated systems, it was found that the simulation time would increase
almost exponentially. The Terceira system consisted of 18 Generation and Storage entries. When
running simulations for the Madeira system (33 generation and storage entries), the simulations took
about 7 minutes, going as high as 10 for some days. 10 minutes for a simulation as simple as this is
not really acceptable. To my knowledge, nothing can be done to combat the influence of the system
size in the simulation time, as well as the variability associated with running different days. However,
taking a closer look at the code and “cleaning” it may hopefully improve computational time. This
makes the previous suggestion relevant, for if the toolbox continues to be increased and developed
without concerns for programming efficiency, simulation times will only increase, and may reach
absolutely unacceptable values.
56
8.2 Toolbox/Model related improvements
Although this manual overlooked the explanation of the ED Model itself, since it is the core of the
toolbox, here lie some suggestions for improving it, as well as some suggestions regarding the
toolbox as a whole.
8.2.1 Inserting priority definition
Currently, the only way to modify the priority of the energy system’s entries is through their cost.
The Allowed Ren. Energy field acts on both solar and wind entries indiscriminately, which allows no
control of the curtailment. That is why the cells related to the fuel characteristics were left as
editable in the Generation Table, and why there is an Equivalent Fuel Cost field for Storage entries, in
the Initial Window. These allow the user to define costs even for renewable entries and storage
entries. This remains, however, a rather crude way of controlling priority definitions, as well as
causing possible errors in the Total Costs calculations, during the simulations.
One suggestion would be to allow the user to define the priority of entries (or at least the renewable
ones), while maintaining their cost as null. This user imputed definition would then bypass the
priority defined in either the “priority_list.m” or “complete_enumeration.m” functions. This can be
done by running the function only for the entries without user defined priority and then
concatenating the user defined priority with the outputs of these functions, to obtain the desired
result.
8.2.2 Reinstating removed features
Comparing the simpler initial (at least to my knowledge) code developed by Abeysekera, M. (annexed
in [1]), with the one provided by Guzzi, F., one of the things that I noticed was that some features
had been removed. This is probably due to the fact that, since the code was specific for each case,
these weren’t working properly for his case, and he decided to remove them altogether instead of
adapting them, since he didn’t really need them. Some examples of these features are:
Using the Ramp Up/Down Rates in the ED Model. I’ve attempted to reinstate this one, since
such an important technical constraint of the generators shouldn’t be left out of the
modelling of a system. However, since for the case I’ve worked on the ramp rates were high
57
enough to be modelled as Inf, no extensive testing was done to check if the reintegration was
working properly;
Using Hot Start Cost. As of right now, the toolbox only uses the Cold Start Cost, however the
Hot Start Cost was still an input in some functions so, when developing the GUI, it was left as
a customizable field when adding an entry. The original code had three options:
1. Using only the Cold Start Cost (similarly to what the toolbox is currently doing);
2. Using the Hot Start Cost (there would only be a start cost if the generator had been
working previously and was shut down for a short period;
3. A cost curve between the two values (that started in the Cold Start Cost and would
tend to the Hot Start Cost), depending on the previous usage of the generator when
it was started. This represented the best modelling option and reinstating it would
probably improve modelling accuracy.
Other types of fuel consumption curves, namely, a second degree polynomial or an
exponential curve. The slots correspondents to these values are still available in the gen_data
matrix. Implementing these (and more types of curves if necessary) would also probably
improve modelling accuracy and the range of thermal generators that can be modelled. It
would, however, require severe modifications to the Fuel Characteristics Window, as well as
to the ED Model optimization (currently done using “fmincon”, inside the “production_ED.m”
and “production.m” functions);
8.2.3 Adding new features
As mentioned, over the course of my work on this toolbox, there were ideas for implementing some
features that were eventually left aside. This is obvious looking at some fields that are not used in the
model, or buttons that do nothing at all (the dreaded N.I.). Here I will attempt to convey the ideas
that were originally going to be put in practice in those places, in the hope that someday they are.
There are also some suggestions that not got past the “idea” phase.
The charging and discharging efficiencies of ESS (Energy Storage Systems) are usually
dependent of their SoC. Currently both the charging and discharging efficiency are inserted
and used as fixed values. The idea behind the Customize button in the Add Entry Storage
Window was to give the user the chance to customize a curve that would dictate how these
58
efficiencies would vary according to the SoC. In order to do so, my suggestion would be to
assess the typical shape of said curves (which would require some research regarding the
subject of ESS), and present the user with something similar to the Fuel Characteristics
Window, to define the curves parameters;
In the Demand Increase entries, one of the type of entry that can be added refers to
domestic appliances (called Appliances). Although for the other type of entries, the profiles
used made sense (average daily normalized profiles), since they mostly concern units that
have a working/charging period of many hours, using normalized daily profiles for household
appliances might not be the most correct choice, in terms of modelling. The profiles currently
inserted for these entries are, in fact, normalized and averaged daily, but are specific for the
Madeira Island case. Ideally, what should be inserted, if an average normalized working cycle
of the appliance (which usually only takes some hours), with the possibility of dislocating the
working cycle along the hours of the day, according to the system considered. It was with
that logic in mind that the Peak Hour field was inserted in the Add Entry Demand Increase
Window, so that the user could select a typical working cycle normalized profile and then
select the hour of the day in which the peak of the cycle would occur. This would require
configuring the Peak Hour field to make it editable when the selected type is Appliances.
Profiles for household appliances are not hard to come by, but implementing and testing this
feature would require some time and patience;
Adding the possibility of using wind and solar intensity forecasts as an input for the
Renewable Availability, in both types of simulations. The intention is to give the user the way
to define the wind and solar production systems’ characteristics (number of units, type of
units, etc.), possibly choosing between several types of wind turbines and solar panels, and
their respective power curves. This would allow the toolbox to automatically calculate the
produced energy by the solar and wind entries, when the wind speed/solar radiation
intensity forecasts are inserted. The main reason behind this concerns the usual
unavailability of detailed data regarding the actual available power for wind and solar PV
production. Even forecasts for the wind speed and solar radiation intensity are usually hard
to obtain with an acceptable accuracy, but they are more commonly available than direct
power available, which leads to the necessity of implementing these calculations in order to
allow the toolbox to deal with predictions rather than just validation of data.
59
Implementing integration with main-grids. It would be interesting for a microgrid tool to be
able to simulate interactions between microgrids and main grids, for cases when such is a
possibility. Since most of the test cases so far concerned islanded systems (islands in
Portuguese archipelagos), developing and implementing such interaction was not a priority
in the development of the toolbox. However, in order to augment the scope of possibilities
that can be modelled by the program, it would be very interesting to see such a feature
available in it;
Including the possibility of optimizing other parameters, instead of just production costs.
Using other factors, such as emissions or fuel consumption as decision variables would be
interesting. If it doesn’t add much simulation time, additional analyses could be performed
using these as the decision variables for the optimization, and the results could be presented
to the user, for comparison purposes. Other way of implementing it is giving the user the
choice of which parameter to optimize during the simulation.
8.2.4 Revising some features
The DR algorithm and its integration with the model, as well as the Long Term Calculations were the
latest features to be added to the toolbox during my work on it. Therefore, they are the least tested
and more prone to contain mistakes, even down to their core formulation and algorithms [Check the
math (“The numbers Mason, what do they mean?”]). Be aware of that when using them and feel free
to develop them and test them further. Results and discussion of these functions can be found in [2],
be sure to read their respective chapters to understand the functions’ limitations and errors, as well
as suggestions on where to start improving them.
60
9 AFTERWORD
Congratulations, you made it to the end. I would like to personally thank you for the patience it took
to read this manual. I completely understand that reading something technical is never fun; I know
this to be true from personal experience.
I felt it was necessary to write this manual so some poor sod wouldn’t have to go reading the whole
code again when picking up the toolbox to work on. It was already hard enough for me to do it; after
the whole amount of GUI functions added during my work, it would have been nearly impossible.
First, I would like to ask for your understanding regarding the lacking information this paper has,
especially about the inner workings of the ED Model itself, which is obviously the most interesting
aspect of the Toolbox. Since I wasn’t the one to develop it, but rather just generalized its
computational application while developing the GUI, I felt rather uncomfortable going into much
detail about it (since I am not entirely sure I understand it at 100%). The bibliography recommended,
and a bit of dedication and patience should help you cover that plot hole rather easily.
Second, I will leave here my contact. Should any further questions arise, feel free to try to contact me
though the email address below. I can’t assure you I will be able to answer your question in a
satisfying manner, and I apologize in advance for any delays I might have answering you. Rest
assured that if I don’t answer immediately, it is because I’m extremely busy, as I usually check my
email inbox once a day. Another question is that, after some time, my memory of my work here
might start to rust, so there are no guaranties I will remember enough to help you, especially if you
contact me a long time after this has been written. Nevertheless, it doesn’t hurt to try and I shall try
my best to help you.
Email address: [email protected]
Lastly, just would like to wish you well. The reason why I chose to work on this toolbox as my master
thesis was because I saw some potential in it. There is still has a lot of work to be done to make it a
toolbox capable of competing with the ones currently used, but the versatility of programming in
MatLab® presents a great scope of possibilities. The concept of a self-sustainable microgrid can also
be applied to buildings with renewable production, for example, which may start to be more
common in the near future. Tools like this one should help in their implementation and operation.
Hopefully that was part of the reason you chose to use this tool and/or work on developing it.
Best Regards: The author
61
REFERENCES
[1] M. Abeysekera, "Development of an energy system operation planning tool considering transmission system effects and operational constraints," Universitat Polytècnica de Catalunya, Barcelona, 2012.
[2] A. Rita, "Development of an energy modeling and microgrid operation toolbox in MatLab®," Thesis to obtain the Master of Science Degree in Mechanical Engineering, U. Lisbon - IST, October 2017.
[3] F. Guzzi, "Development of a modelling and planning tool for renewable microgrids: The case study of Terceira Island," Thesis to obtain the Master of Science Degree in Energy Engineering & Management, IST, 2016.
[4] Smart grids, "European Technology Platform on Vision and Strategy for Europe’s Electricity," 2006.
[5] D. W. Gao, Energy Storage for Sustainable Microgrid, University of Denver, U.S.A.: Academic Press, Elsevier, 2015.
[6] "Building Microgrids: Microgrid definitions," Microgrids at Berkeley Lab, [Online]. Available: https://building-microgrid.lbl.gov/microgrid-definitions. [Accessed 15 August 2017].
62