Optimisation models¶

Generally, this library should allow the optimisation of district heating grids with various configurations settings and different approaches. The optimisation methods of this library are tools to assist the planning process of DHS projects and to analyze the economic feasibility of DHS for a given district, community or city - either by focusing on the DHS itself, or by also considering the overall energy system of a district, which could not just be the heating sector, but also the electricity, mobility sector or the gas infrastructure.

At the moment, there is one approach using oemof-solph as linear optimisation library implemented. This approach is explained in the following sections. It totally makes sense to have some experiences with oemof-solph to understand this toolbox more easily.

Scope¶

The following questions can be addressed using the optimize_investment method of the ThermalNetwork:

What is the cost-optimal topology and dimensioning of a DHS piping system, given the locations of potential central heat supply plants, the potential locations for the DHS piping system (e.g. street network), and the position of consumers?
In addition to the first question, what is the cost-optimal expansion of a given DHS system?
Is it cost-efficient to build a DHS at all, if there a consumer-wise heat supply alternatives? (Comparison of central and de-central supply strategies)
What is the optimal dispatch of the heat producers? (In case there are no expansion options, but just existing DHS pipes)
Planned: Streets-wise aggregation option

To answer these questions, at the moment, the LP and MILP optimisation library oemof.solph is used. Other approaches, e.g. heuristic approaches, might follow.

The following sections will give an overview about the general usage/workflow, (the necessary input data, the different optimisation settings and options, the results), and second, the underlying mathematical description.

Usage¶

Links to the subsections:

Overview
Input Data
Label systematic
Results

Overview¶

The optimisation of a given ThermalNetwork is executed by:

import dhnx

tnw = dhnx.network.ThermalNetwork()

tnw = network.from_csv_folder('path/to/thermal_network')

invest_opt = dhnx.input_output.load_invest_options('path/to/invest_options')

tnw.optimize_investment(invest_options=invest_opt)

For executing an optimisation, you must provide investment options additional to the previous data, which defines a ThermalNetwork. Both are explained in the following section.

Input Data¶

In this section, it is firstly revised, what input data is exactly necessary from the ThemalNetwork class, and then explained, what data needs to be provided as investment options, and what optimisation settings you can apply.

The following figure provides an overview of the input data:

The structure of the input data might look a bit confusing at the beginning, but provides a lot of options for building up complex district heating models. There are two groups of data: Firstly, data that describes the components and the connectivity of the network, required by the ThermalNetwork class. Secondly, data that is necessary for the investment optimization. For now, all data needs to be provided in csv files. This means that you do not need to provide a geo-reference for applying an district heating network optimisation model at all. Probably, in many cases, it is the export of four geo-referenced layers (e.g. geopandasdataframe, shp-file, or any other), which are a line layer representing the potential places for the DHS-trenches, and three point layers for the producers, the consumers, and the potential forks of the DHS system. All geometry information of the network system is passed by an id for each element. Thus, the line layer connects all points and provides the spatial relation with the attributes from_node, to_node, and length. If you prepare the data, be careful that every consumer is connected to an pipe, and every piping network system is connected to at least one producer.

ThermalNetwork¶

The data for the ThermalNetwork must be provided in the structure as defined for the .csv reader. The following data is required for applying an optimisation:

tree
├── pipes.csv                       # (required)
├── consumers.csv                   # (required)
├── forks.csv                       # (required)
├── producers.csv                   # (required)
└── sequences                       # (optional)
    └── consumers-heat_flow.csv

The attributes, which are required, and which are optional with respect to the optimisation, are presented in detail in the following:

Pipes¶

The basis for the district heating system optimisation is a table of potential pipes. The following attributes of the ThermalNetwork must be given:

id: see Thermal Network
from_node: see Thermal Network
to_node: see Thermal Network
length: see Thermal Network

The following attributes are additional attributes of the optimisation module. These attributes are optional for the optimisation:

attribute	type	unit	default	description	status	requirement
existing	bool	n/a	0	Binary indicating and existing pipe	Input	optional
capacity	float	kW	0	Capacity for existing pipe	Input	optional
hp_type	object	n/a	‘nan’	Type_label of existing pipe	Input	optional
active	bool	n/a	1	Binary indicating that edge is available	Input	optional
add_fix_costs	float	Eur/m	0	Additional fix investment costs	Input	optional

existing: Binary indicating an existing pipe. If there is no column existing given, all Pipes are free for optimisation.
capacity: Capacity of existing pipes. If existing is True, a capacity must be given.
hp_type: Label of the type of pipe. The hp_type refers to a set of parameters of a pipeline component. The parameters for the hp_type must be given in the following table (see network/pipes.csv). If existing is True, a hp_type must be given.
active: Binary indicating that this pipe is considered. If no column active is given, all pipe-options are active. With this attribute, single pipes can be switched on and off. This can be very useful, if different scenarios should be analyzed, e.g. you might like to make a given street/pipes unavailable.

Consumers¶

The following attributes of the ThermalNetwork must be given:

id: see Thermal Network

The following attributes are additional attributes of the optimisation module, and optional:

attribute	type	unit	default	description	status	requirement
active	bool	n/a	1	Binary indicating that consumer is active	Input	optional
P_heat_max	float	kW	n/a	Maximum heat load of consumer	Input	optional

active: Binary indicating that consumer-xy is considered. If no column active is given, all consumers are active. With this attribute, single consumers can be switched on and off (e.g. for scenario analysis with different connection quotes).
P_heat_max: Maximum heat load of consumer. If no column P_heat_max is given, the maximum heat load is calculated from the heat demand series (see consumers-heat_flow.csv). Depending on the optimisation setting, P_heat_max or the demand series is used for the optimisation (see Optimisation settings for further information).

Producers¶

The following attributes of the ThermalNetwork must be given:

id: see Thermal Network

The following attributes are additional attributes of the optimisation module, and optional:

attribute	type	unit	default	description	status	requirement
active	bool	n/a	1	Binary indicating that producer is active	Input	optional

active: Binary indicating that producer is active. If no column active is given, all producers are active. With this attribute, single producers can be switched on and off (e.g. for scenario analysis for different supply plant positions.

Forks¶

The following attributes of the ThermalNetwork must be given:

id: see Thermal Network

For Forks, no additional required or optional attributes are needed by the optimisation module.

Consumers-heat_flow¶

Providing consumers heat flow time series is optional, but either the consumers demand must be given in form of P_heat_max as attribute of the consumers, or in form of a heat_flow time series with the minimum length of 1.

The following table shows an example of a consumers-heat_flow:

timestep	0	1
0	8	12
1	10	10
2	9	7

The column index must be the consumers id (And be careful that the dtype also matches the id of the consumers!).

Investment and additional options¶

If you want to do an investment or an simple unit commitment optimisation using the optimize_investment() method of the ThermalNetwork, you need to provide some additional data providing the investment parameter. The following sheme illustrates the structure of the investment input data:

tree
├── network
|   └── pipes.csv           # (required)
|
├── consumers
|   ├── bus.csv             # (required)
|   ├── demand.csv          # (required)
|   ├── source.csv          # (optional)
|   ├── storages.csv        # (optional)
|   └── transformer.csv     # (optional)
|
└── producers
    ├── bus.csv             # (required)
    ├── demand.csv          # (optional)
    ├── source.csv          # (required)
    ├── storages.csv        # (optional)
    └── transformer.csv     # (optional)

The investment input data provides mainly all remaining parameters of the oemof solph components, which are not specific for a single pipe, producer or consumer.

The minimum of required data is a specification of the pipe parameters (costs, and losses), a (heat) bus and a heat demand at the consumers, and a (heat) bus and a heat source at the producers. The detailed attributes are described in the following sections.

network/pipes.csv¶

You need to provide data on the investment options for the piping system. The following table shows the minimal required data you need to provide:

label_3	active	nonconvex	l_factor	l_factor_fix	cap_max	cap_min	capex_pipes	fix_costs
pipe-typ-A	1	0	0	0	100000	0	0.5	0

Each row represents an investment option. Note this investment option creates an oemof-solph Heatpipeline component for each active pipe. The units are given es examples. There are no units implemented, everybody needs to care about consistent units in his own model. At the same time, everybody is free to choose his own units (energy, mass flow, etc.).

label_3: Label of the third tag. See Label system.
active: (0/1). If active is 0, this heatpipeline component is not considered. This attribute helps for easy selecting and deselecting different investment options.
nonconvex: (0/1). Choose whether a convex or a nonconvex investment should be performed. With nonconvex set to 1, fix losses and fix costs independent of the dimension of the pipelines capacity can be considered. It is recommended to set nonconvex to 1, as the construction of DHS pipelines is usually characterized by a high share of fixed costs. If nonconvex is 0, the costs-curve is a line through origin.
l_factor: Relative thermal loss per length unit (e.g. [kW_loss/(m*kW_installed)]. Defines the loss factor depending on the installed heat transport capacity of the pipe. The l_factor is multiplied by the invested capacity in investment case, and by the given capacity for a specific pipe in case of existing DHS pipes.
l_factor_fix: Absolute thermal loss per length unit (e.g. [kW/m]). In case of nonconvex is 1, the l_factor_fix is zero if no investement in a specific pipe element is done. Be careful, if nonconvex is 0, this creates a fixed thermal loss. Recommended to use with nonconvex is True.
cap_max: Maximum installable capacity (e.g. [kW]).
cap_min: Minimum installable capacity (e.g. [kW]). Note that there is a difference if a nonconvex investment is applied (see oemof-solph documentation for further information).
capex_pipes: Variable investment costs depending on the installed heat transport capacity (e.g. [€/kW]).
fix_costs: Fix investment costs independent of the installed capacity (e.g. [€]) This attribute requires nonconvex is set to True.

See the Heatpipeline API for further details about the attributes.

The module dhnx.optimization.precalc_hydraulic provides helpful functions for the calculation of the pipeline parameters (see dhnx.optimization.precalc_hydraulic). See also the precalulation example in the example folder of the optimisation examples.

consumers/.¶

All data for initialising oemof-solph components at the consumers are provided by the .csv files of the consumers folder. For a principal understanding, check out the excel reader example of oemof-solph, which works the same way: oemof-solph excel reader example.

The minimum requirement for doing an DHS optimisation is to provide an demand at the consumers. Therefore, you need the following two .csv files: bus.csv specifies the oemof-solph Bus components, and demand.csv defines the oemof.solph.Sink.

Example for table of Buses¶

label_2

active

excess

shortage

shortage costs

excess costs

heat

1

0

0

99999

99999

You must provide at least one bus, which has a label (label_2, see Label system), and needs to be active. Optionally, you can add an excess or a shortage with shortage costs or excess costs respectively. This might help to get an feasible optimisation problem, in case your solver says, ‘infeasible’, for finding the error.

demand.csv¶
label_2	active	nominal_value
heat	1	1

The demand also needs to have a label (label_2, see Label system), has the option for deactivating certain demands by using the attribute active, and needs to have a specification for the nominal_value. The nominal_value scales your demand.

producers/.¶

The producers look quite similar as the consumers. The consumers are taking energy from the DHS system. That means, the energy need to be supplied somewhere, which makes some kind of source necessary. To connect a source in the oemof logic, there needs to be a oemof.solph.Bus to which the source is connected. The two files bus.csv and source.csv need to be provided:

Example for table of Buses¶

label_2

active

excess

shortage

shortage costs

excess costs

heat

1

0

0

99999

99999

The bus.csv table works analog to the consumers (see consumers/.).

source.csv¶
label_2	active
heat	1

You need to provide at least one source at the source.csv table. Additionally, there are already a couple of options for adding additional attributes of the oemof.solph.FLow to the source, e.g. variable_costs, fix feed-in series, and min and max restrictions.

Generally, with this structure at every producer and consumer multiple oemof components, like transformer and storages can be already added.

Optimisation settings¶

The following table shows all options for the optimisation settings (See also setup_optimise_investment()):

attribute	type	default	description
heat_demand	str	‘scalar’	‘scalar’ or ‘series’. ‘scalar’: Peak heat load. ‘series’: time-series is used as heat demand.
simultaneity	float	1	Simultaneity or concurrency factor
num_ts	int	1	Number of time steps of optimisation
time_res	float	1	Time resolution
start_date	str	‘1/1/2018’	Startdate for oemof optimisation
frequence	str	‘H’	Lenght of period
solver	str	‘cbc’	Name of solver
solve_kw	dict	{‘tee’: True}	Solver kwargs
bidirectional_pipes	bool	False	Bidirectional pipes leads to bi-directional flow attributes at the heatpipeline components {‘min’: -1, bidirectional: True}
dump_path	str	None	If a dump path is provided, the oemof dump file is stored.
dump_name	str	dump.oemof	Name of dump file
print_logging_info	bool	False	There are still some helpful print statements.
write_lp_file	bool	False	Option of writing lp-file. The lp-file is stored in ‘User/.oemof/lp_files/DHNx.lp’

Some more explanation:

heat_demand: If you set heat_demand to ‘scalar’, num_ts is automatically 1, and the peak heat load is used as heat demand for the consumers. If you want to use a time series as heat demand, apply ‘series’.

Label systematic¶

In order to access the oemof-solph optimisation results, a label systematic containing a tuple with 4 items is used. Please check the basic example of oemof-solph for using tuple as label (oemof-solph example tuple as label).

The following table illustrates the systematic:

Labelling system (bold: obligatory; italic: examples)¶
tag1: general classification	tag2: commodity	tag3: specification / oemof object	tag4: Specific id
consumers	heat	source	forks-34
producers	electricity	demand	consumers-15
infrastructure	gas	excess	prdocuers-4
	hydrogen	shortage	forks-14-forks-27
		pipe-typ-A	forks-24-consumers-122
		storage_xy
		boiler_typ_xy

The labels are partly given automatically by the oemof-solph model builder:

tag1: general classification: This tag is given automatically depending on the spatial belonging. Tag1 can be either consumers (consumer point layer), producers (producer point layer) or infrastructure (pipes and forks layer). See Thermal Network.
tag2: commodity: This tag specifies the commodity, e.g. all buses and transformer (heatpipelines) of the DHS pipeline system have automatically the heat as tag2. For a transformer of the consumers or the producers the tag2 is None, because a transformer usually connects two commodities, e.g. gas –> heat.
tag3: specification / oemof object: The third tag indicates either the oemof object and is generated automatically (this is the case for demand.csv, source.csv and bus.csv), or is the specific label_3 of the pipes.csv, transformer.csv or storages.csv.
tag4: id: The last tag shows the specific spatial position and is generated automatically.

Results¶

For checking and analysing the results you can either select to write the investment results of the heatpipeline components in the Thermalnetwork. You will find the results there:

# pipe-specific investment results
results = network.results.optimization['components']['pipes']

The following tables provides an overview of the results table:

attribute	type	unit	description	status
id	object	n/a	Unique id (see pipes of network)	Input
from_node	object	n/a	Node where Edge begins (see pipes of network)	Input
to_node	object	n/a	Node where Edge ends (see pipes of network)	Input
length	float	m	Length of pipe (see pipes of network)	Input
hp_type	object	n/a	Label of pipe which got selected from network/pipes.csv	Result
capacity	float	kW	Installed pipe capacity	Result
direction	float	-1/0/1	Flow direction of pipe: 1 if direction corresponds to the from_node/to_node notation. -1: opposite direction. 0: no investment. This works only if the setting option bidirectional_pipes is set False.	Result
costs	float	Eur	Total cost of pipe element.	Result
losses	float	kW	Total losses of pipe element.	Result

You can also check out the detailed results of the oemof model, which are stored at:

# oemof-solph results "main"
r_oemof_main = network.results.optimization['oemof']

# oemof-solph results "meta"
r_oemof_meta = network.results.optimization['oemof_meta']

Or you can also dump the oemof results and analyze the results as described in oemof-solph handling results. The labelling systematic will help you to easily get want you want, check Label system.

Introducing example¶

The following sections illustrates some features of the DHNx investment optimisation library.

You can execute and reproduce the example with all figures, check the introduction_example.

import matplotlib.pyplot as plt
import dhnx


# Initialize thermal network
network = dhnx.network.ThermalNetwork()
network = network.from_csv_folder('twn_data')

# Load investment parameter
invest_opt = dhnx.input_output.load_invest_options('invest_data')

# plot network
static_map = dhnx.plotting.StaticMap(network)
static_map.draw(background_map=False)
plt.title('Given network')
plt.scatter(network.components.consumers['lon'], network.components.consumers['lat'],
            color='tab:green', label='consumers', zorder=2.5, s=50)
plt.scatter(network.components.producers['lon'], network.components.producers['lat'],
            color='tab:red', label='producers', zorder=2.5, s=50)
plt.scatter(network.components.forks['lon'], network.components.forks['lat'],
            color='tab:grey', label='forks', zorder=2.5, s=50)
plt.text(-2, 32, 'P0', fontsize=14)
plt.text(82, 0, 'P1', fontsize=14)
plt.legend()
plt.show()

The following figure shows the initial status of an (thermal) network, which is examined in the following sections:

The network of Fig. 2 consists of two options for the heat producers (“P0” and “P1”), eight consumers, and 11 forks. Before running the whole script, we will have a brief look at some input data. Let’s start with the consumers.csv (“twn_data/consumers.csv”):

consumers.csv¶
id	lat	lon	P_heat_max
0	30	40	15
1	10	40	18
2	10	60	25
3	30	70	36
4	50	60	25
5	90	40	12
6	60	10	50
7	60	30	20

A peak heating load P_heat_max is given for every consumer within the thermal network input data (see Thermal Network Input). The heat load needs to be pre-calculated, or assumed. The geographical attributes lat and lon are optional, but needed for plotting purpose. The next table shows the input data of the heat pipeline elements (“invest_data/network/pipes.csv”):

pipes.csv¶
label_3	active	nonconvex	l_factor	l_factor_fix	cap_max	cap_min	capex_pipes	fix_costs
pipe-typ-A	1	0	0.00001	0	100000	0	2	0

In the simplest (and most approximate) case, a linear correlation between the thermal capacity and the investment costs can be used. In this example, we assume costs of 2 € per kilowatt installed thermal capacity and meter trench length. As maximum capacity cap_max, we take a very high value to make sure that the total heat load of all consumers (including losses) can be supplied. Additionally, we assume a heat loss of 0.00001 kW/m. The parameters of the district heating pipes need to be pre-calculated depending on the piping system and technical data sheet of the manufacturer. (In future, some pre-calculation function might be added.) The length of each pipe, the costs and the losses are related to, must be given in the pipes.csv table of the Thermal Network Input). Next, we optimise the network and get the results:

network.optimize_investment(invest_options=invest_opt)

# get results
results_pipes = network.results.optimization['components']['pipes']
print(results_pipes[['from_node', 'to_node', 'hp_type', 'capacity', 'heat_loss[kW]',
                     'invest_costs[€]']])

Since we do not have any other costs than investment costs, we can check if our results have been correctly processed by comparing the objective of the optimisation problem with the sum of the investment costs of the single pipes, which should be the same:

# sum of the investment costs of all pipes
print(results_pipes[['invest_costs[€]']].sum())

# objective value of optimisation problem
print(network.results.optimization['oemof_meta']['objective'])

Next, we can transfer the results to a ThermalNetwork, which contains only the pipes with an investment (to avoid possible numerical inaccuracy, the criterion is > 0.001):

# assign new ThermalNetwork with invested pipes
twn_results = network
twn_results.components['pipes'] = results_pipes[results_pipes['capacity'] > 0.001]

Now, lets have a look at the optimisation results, and plot the pipes:

# plot invested pipes
static_map_2 = dhnx.plotting.StaticMap(twn_results)
static_map_2.draw(background_map=False)
plt.title('Given network')
plt.scatter(network.components.consumers['lon'], network.components.consumers['lat'],
            color='tab:green', label='consumers', zorder=2.5, s=50)
plt.scatter(network.components.producers['lon'], network.components.producers['lat'],
            color='tab:red', label='producers', zorder=2.5, s=50)
plt.scatter(network.components.forks['lon'], network.components.forks['lat'],
            color='tab:grey', label='forks', zorder=2.5, s=50)
plt.text(-2, 32, 'P0', fontsize=14)
plt.text(82, 0, 'P1', fontsize=14)
plt.legend()
plt.show()

… which should give:

The next thing is to deactivate one heat producer by setting the attribute active of producer P1 to 0 (compare Thermal Network Input):

producers.csv¶
id	lat	lon	active
0	30	0	1
1	0	80	0

Now, the plot of pipes with a positive investment should look like this:

Fig. 4: Pipes with investment (only P0)¶

There are many other options already implemented. For example:

Using time series as heat demand

Doing redundancy analysis by setting min and max attributes to the producers’ sources

Adding other oemof-solph objects like Transformer, Storages, further Buses, Sinks and Sources to each producer and consumer

Using discrete pipe data by using the nonconvex investment options

Have fun!

Optimisation models¶

Scope¶

Usage¶

Overview¶

Input Data¶

ThermalNetwork¶

Pipes¶

Consumers¶

Producers¶

Forks¶

Consumers-heat_flow¶

Investment and additional options¶

network/pipes.csv¶

consumers/.¶

producers/.¶

Optimisation settings¶

Label systematic¶

Results¶

Introducing example¶

Table of Contents

This Page