-
Notifications
You must be signed in to change notification settings - Fork 3
Topologies
In order to create a LES from a local energy scenario as created with the ETM, the scenario has to be coupled to a network topology. You can choose an existing topology or create a new one. All existing topologies can be found under the Show all
option of the Topologies
menu. This page describes the topologies and their attributes, which is particularly relevant when you create a new topology. At the end of this page it is described how you can review the parameters of the topology if you have chosen to use an existing one.
On the level of a typical LES, the network consists of one or several medium-voltage (MV) networks which support several low-voltage (LV) networks (see figure below for an example of a network topology).
The high-voltage (HV) net is assumed to lie outside of the testing ground and serves as a source/sink for demand/supply of electricity for the LES as a whole.
Topologies in ETMoses are defined in a simple nested textfile (YML format). Within this textfile it is possible to define:
- the number of MV networks in the testing ground
- the number of LV networks connected to the MV networks
- the number of direct connections to the MV net
- the capacities of the network components
- investment costs and technical lifetimes for network components
- the stakeholder that owns the network component
An example of a simple network in YML format is given below:
---
name: HV Network
stakeholder: producer
children:
- name: HV-MV Trafo
capacity: 16000
technical_lifetime: 30
investment_cost: 150000
stakeholder: system operator
children:
- name: 'MV-LV Trafo #1'
capacity: 2000
technical_lifetime: 30
investment_cost: 50000
stakeholder: system operator
children:
- name: Households 1
capacity: 17.25
units: 33
stakeholder: customer
- name: 'MV-LV Trafo #2'
capacity: 2000
technical_lifetime: 30
investment_cost: 50000
stakeholder: system operator
children:
- name: Households 2
capacity: 17.25
units: 33
stakeholder: customer
- name: 'MV-LV Trafo #3'
capacity: 2000
technical_lifetime: 30
investment_cost: 50000
stakeholder: system operator
children:
- name: Households 3
capacity: 17.25
units: 33
stakeholder: customer
The above YML file can be translated into a visual network as seen below:
The properties of network components, e.g. their capacity, can be specified by changing their attributes in the network YML. The user can change both technical properties as well as financial properties which are needed in order to calculate the business case. In this subsection, we will describe the syntax of the topology YAML in detail.
The topology YAML starts with three dashes. This is part of the YAML format and signifies the start of a new document (see section 2.2 of the YAML documentation).
Every topology starts with a single link to the high voltage (HV) network. This represents the connection to the 'rest of the world'. The HV net is the first 'node' of the hierarchical network and can branch into other connections as we will see below. Starting from this node, we can define its children, see e.g. the example above.
Any component (node) of the network can have the following attributes:
-
name
: a string which is enclosed in quotation marks (""). The 'name' attribute is the first one that needs to be specified and is preceded by a single dash. -
capacity
: the capacity of the network in kW -
investment_cost
: the cost of investment in EUR -
yearly_o_and_m_costs
: the yearly operational and management cost for a certain node in EUR. -
technical_lifetime
: the technical lifetime in years; it is assumed that the economic lifetime is the same as the technical lifetime -
units
: the number of units of the component -
children
: one or more connections to the rest of the network. The 'children' attribute is the last to be specified as it must be followed by the definitions of child nodes. -
stakeholder
: the 'owner' of the node.
Each attribute has a keyword (listed above) and a value which are seperated by a colon (':')
Underneath the 'children' keyword (and the colon), the names of the children can be specified. Preceding the 'name' keyword, the YAML expects a two-space indentation and a single dash followed by a space. The indentation makes it possible to nest multiple layers of children (and grandchildren etc.)
Keywords following the 'name' keyword need to have the same indentation. This ensures that they are interpreted as part of the same component (node).
The 'units' keyword has a special function: it multiplies the capacity and investment cost of the component. This can be used to group many components of the same type. No other attributes of the component are multiplied by the 'units'. The user is responsible for keeping things consistent: e.g. if you increase the capacity of a node, the capacities of its children will not be increased. If you would like these capacities to increase as well, you need to update them manually.
Consider e.g. the following excerpt from the example above. If you would change the capacity of HV-MV Trafo
(at arrow 1), this not change the capacity of its children. In case you also want to change the capacity of its child MV-LV Trafo #1
, you need to do this by updating the capacity at arrow 2.
- name: HV-MV Trafo
capacity: 16000 <--- 1
technical_lifetime: 30
investment_cost: 150000
stakeholder: system operator
children:
- name: 'MV-LV Trafo #1'
capacity: 2000 <--- 2
technical_lifetime: 30
investment_cost: 50000
stakeholder: system operator
children:
Consider the second excerpt from the same example above. The capacity of the node Households 1
is 33 * 17.25 kW
(i.e. the value of units
(arrow 3) times the value of capacity
(arrow). Changing the number of units or the capacity will result in a different capacity for this node; it will however not affect the capacity of the node MV-LV Trafo #1
(arrow 5).
- name: 'MV-LV Trafo #1'
capacity: 2000 <--- 5
technical_lifetime: 30
investment_cost: 50000
stakeholder: system operator
children:
- name: Households 1
capacity: 17.25 <--- 4
units: 33 <--- 3
stakeholder: customer
Examples of stakeholders are listed below. In principle, you can give the stakeholder any name you want. However, only those stakeholders pre-defined in the market models can be used within these market models.
- customer
- cooperation
- system operator
- producer
- supplier (usually not associated with a network component)
- aggregator (usually not associated with a network component)
- government (usually not associated with a network component)
Note that only when you assign a stakeholder to a specific node, you can apply a measure to this node as the measures are applied to the stakeholder and not to the node. If no stakeholder is assigned for a node, this node cannot be used in the market model.
In order to take the depreciation costs of a node into account in the business case, you need to define at least the investment_cost
and the technical_lifetime
, and preferably also the yearly_o_and_m_costs
. Failing to provide one of the first two attributes, will result in the fact that the depreciation costs are not taken into account in the business case.
This is especially relevant when you create a LES with an existing topology. You can review and modify the properties of the topology by going to the Topology
tab under the Edit LES
button. The syntax described above can be applied here as well. Also note that the LES only will give meaningful results about congestion when the capacities (and units) in the topology are related to the number of residences.