Data

The description of the methods, input data and results of the eGon-data pipeline is given in the following section. References to datasets and functions are integrated if more detailed information is required.

Main input data and their processing

All methods in the eGon-data workflow rely on public and freely available data from different external sources. The most important data sources and their processing within the eGon-data pipeline are described here.

Data bundle

The data bundle is published on zenodo. It contains several data sets, which serve as a basis for egon-data:

• Climate zones in Germany
• Data on eMobility individual trips of electric vehicles
• Spatial distribution of deep geothermal potentials in Germany
• Annual profiles in hourly resolution of electricity demand of private households
• Sample heat time series including hot water and space heating for single- and multi-familiy houses
• Hydrogen storage potentials in salt structures
• Information about industrial sites with DSM-potential in Germany
• Data extracted from the German grid development plan - power
• Parameters for the classification of gas pipelines
• Preliminary results from scenario generator pypsa-eur-sec
• German regions suitable to model dynamic line rating
• Eligible areas for wind turbines and ground-mounted PV systems
• Definitions of industrial and commercial branches
• Zensus data on households
• Geocoding of all unique combinations of ZIP code and municipality within the Marktstammdatenregister

For further description of the data including licenses and references please refer to the Zenodo repository.

Marktstammdatenregister

The Marktstammdatenregister (MaStR) is the register for the German electricity and gas market holding, among others, data on electricity and gas generation plants. In eGon-data it is used for status quo data on PV plants, wind turbines, biomass, hydro power plants, combustion power plants, nuclear power plants, geo- and solarthermal power plants, and storage units. The data are obtained from zenodo, where raw MaStR data, downloaded with the tool open-MaStR using the MaStR webservice, is provided. It contains all data from the MaStR, including possible duplicates. Currently, two versions are used:

• 2021-05-03
• 2022-11-17

The download is implemented in MastrData.

OpenStreetMap

OpenStreetMap (OSM) is a free, editable map of the whole world that is being built by volunteers and released with an open-content license. In eGon-data it is, among others, used to obtain information on land use as well as locations of buildings and amenities to spatially dissolve energy demand. The OSM data is downloaded from the Geofabrik download server, which holds extracts from the OpenStreetMap. Afterwards, they are imported to the database using osm2pgsql with a custom style file. The implementation of this can be found in OpenStreetMap.

In the OpenStreetMap dataset, the OSM data is filtered, processed and enriched with other data. This is described in the following subsections.

Amenity data

The data on amenities is used to disaggregate CTS demand data. It is filtered from the raw OSM data using tags listed in script osm_amenities_shops_preprocessing.sql, e.g. shops and restaurants. The filtered data is written to database table openstreetmap.osm_amenities_shops_filtered.

Building data

The data on buildings is required by several tasks in the pipeline, such as the disaggregation of household demand profiles or PV home systems to buildings, as well as the DIstribution Network Generat0r ding0 (see also Medium and low-voltage grids).

The data processing steps are:

• Extract buildings and filter using relevant tags, e.g. residential and commercial, see script osm_buildings_filter.sql for the full list of tags. Resulting tables:
  • All buildings: openstreetmap.osm_buildings
  • Filtered buildings: openstreetmap.osm_buildings_filtered
  • Residential buildings: openstreetmap.osm_buildings_residential
• Create a mapping table for building’s OSM IDs to the Zensus cells the building’s centroid is located in. Resulting tables:
  • boundaries.egon_map_zensus_buildings_filtered (filtered)
  • boundaries.egon_map_zensus_buildings_residential (residential only)
• Enrich each building by number of apartments from Zensus table society.egon_destatis_zensus_apartment_building_population_per_ha by splitting up the cell’s sum equally to the buildings. In some cases, a Zensus cell does not contain buildings but there is a building nearby which the no. of apartments is to be allocated to. To make sure apartments are allocated to at least one building, a radius of 77m is used to catch building geometries.
• Split filtered buildings into 3 datasets using the amenities’ locations: temporary tables are created in script osm_buildings_temp_tables.sql, the final tables in osm_buildings_amentities_results.sql. Resulting tables:
  • Buildings w/ amenities: openstreetmap.osm_buildings_with_amenities
  • Buildings w/o amenities: openstreetmap.osm_buildings_without_amenities
  • Amenities not allocated to buildings: openstreetmap.osm_amenities_not_in_buildings

As there are discrepancies between the Census data [Census] and OSM building data when both datasets are used to generate electricity demand profiles of households, synthetic buildings are added in Census cells with households but without buildings. This is done as part of the Demand_Building_Assignment dataset in function generate_synthetic_buildings. The synthetic building data are written to table openstreetmap.osm_buildings_synthetic. The same is done in case of CTS electricity demand profiles. Here, electricity demand is disaggregated to Census cells according to heat demand information from the Pan European Thermal Atlas [Peta]. In case there are Census cells with electricity demand assigned but no building or amenity data, synthetic buildings are added. This is done as part of the CtsDemandBuildings dataset in function create_synthetic_buildings. The synthetic building data are again written to table openstreetmap.osm_buildings_synthetic.

Street data

The data on streets is used in the DIstribution Network Generat0r ding0, e.g. for the routing of the grid. It is filtered from the raw OSM data using tags listed in script osm_ways_preprocessing.sql, e.g. highway=secondary. Additionally, each way is split into its line segments and their lengths is retained. The filtered streets data is written to database table openstreetmap.osm_ways_preprocessed and the filtered streets with segments to table openstreetmap.osm_ways_with_segments.

Grid models

Power grid models of different voltage levels form a central part of the eGon data model, which is required for cross-grid-level optimization. In addition, sector coupling necessitates the representation of the gas grid infrastructure, which is also described in this section.

Electricity grid

High and extra-high voltage grids

The model of the German extra-high (eHV) and high voltage (HV) grid is based on data retrieved from OpenStreetMap (status January 2021) [OSM] and additional parameters for standard transmission lines from [Brakelmann2004]. To gather all required information, such as line topology, voltage level, substation locations, and electrical parameters, to create a calculable power system model, the osmTGmod tool was used. The corresponding dataset Osmtgmod executes osmTGmod and writes the resulting data to the database.

The resulting grid model includes the voltage levels 380, 220 and 110 kV and all substations interconnecting these grid levels. For further information on the generation of the grid topology please refer to [Mueller2018].

Medium and low-voltage grids

Medium (MV) and low (LV) voltage grid topologies for entire Germany are generated using the python tool ding0 ding0. ding0 generates synthetic grid topologies based on high-resolution geodata and routing algorithms as well as typical network planning principles. The generation of the grid topologies is not part of eGon_data, but ding0 solely uses data generated with eGon_data, such as locations of HV/MV stations (see High and extra-high voltage grids), locations and peak demands of buildings in the grid (see Building data respectively Electricity), as well as locations of generators from MaStR (see Marktstammdatenregister). A full list of tables used in ding0 can be found in its config. An exemplary MV grid with one underlying LV grid is shown in figure Exemplary synthetic medium-voltage grid with underlying low-voltage grid generated with ding0. The grid data of all over 3.800 MV grids is published on zenodo.

Exemplary synthetic medium-voltage grid with underlying low-voltage grid generated with ding0

Besides data on buildings and generators, ding0 requires data on the supplied areas by each grid. This is as well done in eGon_data and described in the following.

MV grid districts

Medium-voltage (MV) grid districts describe the area supplied by one MV grid. They are defined by one polygon that represents the supply area. Each MV grid district is connected to the HV grid via a single substation. An exemplary MV grid district is shown in figure Exemplary synthetic medium-voltage grid with underlying low-voltage grid generated with ding0 (orange line).

The MV grid districts are generated in the dataset MvGridDistricts. The methods used for identifying the MV grid districts are heavily inspired by Hülk et al. (2017) [Huelk2017] (section 2.3), but the implementation differs in detail. The main difference is that direct adjacency is preferred over proximity. For polygons of municipalities without a substation inside, it is iteratively checked for direct adjacent other polygons that have a substation inside. Speaking visually, a MV grid district grows around a polygon with a substation inside.

The grid districts are identified using three data sources

1. Polygons of municipalities (Vg250GemClean)
2. Locations of HV-MV substations (EgonHvmvSubstation)
3. HV-MV substation voronoi polygons (EgonHvmvSubstationVoronoi)

Fundamentally, it is assumed that grid districts (supply areas) often go along borders of administrative units, in particular along the borders of municipalities due to the concession levy. Furthermore, it is assumed that one grid district is supplied via a single substation and that locations of substations and grid districts are designed for aiming least lengths of grid line and cables.

With these assumptions, the three data sources from above are processed as follows:

• Find the number of substations inside each municipality
• Split municipalities with more than one substation inside
  • Cut polygons of municipalities with voronoi polygons of respective substations
  • Assign resulting municipality polygon fragments to nearest substation
• Assign municipalities without a single substation to nearest substation in the neighborhood
• Merge all municipality polygons and parts of municipality polygons to a single polygon grouped by the assigned substation

For finding the nearest substation, as already said, direct adjacency is preferred over closest distance. This means, the nearest substation does not necessarily have to be the closest substation in the sense of beeline distance. But it is the substation definitely located in a neighboring polygon. This prevents the algorithm to find solutions where a MV grid districts consists of multi-polygons with some space in between. Nevertheless, beeline distance still plays an important role, as the algorithm acts in two steps

1. Iteratively look for neighboring polygons until there are no further polygons
2. Find a polygon to assign to by minimum beeline distance

The second step is required in order to cover edge cases, such as islands.

For understanding how this is implemented into separate functions, please see define_mv_grid_districts.

Load areas

Load areas (LAs) are defined as geographic clusters where electricity is consumed. They are used in ding0 to determine the extent and number of LV grids. Thus, within each LA there are one or multiple MV-LV substations, each supplying one LV grid. Exemplary load areas are shown in figure Exemplary synthetic medium-voltage grid with underlying low-voltage grid generated with ding0 (grey and orange areas).

The load areas are set up in the LoadArea dataset. The methods used for identifying the load areas are heavily inspired by Hülk et al. (2017) [Huelk2017] (section 2.4).

Gas grid

Information about the gas grids and how they were created

Methane grid

Hydrogen grid

Demand

Electricity, heat and gas demands from different consumption sectors are taken into account in eGon-data. The related methods to distribute and process the demand data are described in the following chapters for the different consumption sectors separately.

Electricity

Information about electricity demands and their spatial and temporal aggregation

Heat

Heat demands comprise space heating and dirinking hot water demands from residential and comertial trade and service (CTS) buildings. Process heat demands from the industry are, depending on the required temperature level, modelled as electrcity, hydrogen or methane demand.

The spatial distribution of annual heat demands is taken from the Pan-European Thermal Altlas version 5.0.1 [Peta]. This source provides data on annual european residential and CTS heat demands per hectar cell for the year 2015. In order to model future demands, the demand distribution extracted by Peta is then scaled to meet a national annual demand from external sources. The following national demands are taken for the selected scenarios:

Heat demands per sector and scenario

	Residential sector	CTS sector	Sources
eGon2035	379 TWh	122 TWh	[Energiereferenzprognose]
eGon100RE	284 TWh	89 TWh	[Energiereferenzprognose]

The resulting data is stored in the database table demand.egon_peta_heat. The implementation of these dataprocessing steps can be found in HeatDemandImport.

Figure Spatial distribution of residential heat demand in scenario eGon2035 shows the distribution of residential heat demands for scenario eGon2035, categorized for different levels of annual demands.

Spatial distribution of residential heat demand in scenario eGon2035

Afterwards, the annual heat demands are used to create hourly heat demand profiles. For residential heat demand profiles a pool of synthetical created bottom-up demand profiles is used. Depending on the mean temperature per day, these profiles are randomly assigned to each residential building. The methodology is described in detail in [Buettner2022].

Data on residential heat demand profiles is stored in the database within the tables demand.egon_heat_timeseries_selected_profiles, demand.egon_daily_heat_demand_per_climate_zone, boundaries.egon_map_zensus_climate_zones. To create the profiles for a selected buidling, these tables have to be combined, e.g. like this:

SELECT (b.demand/f.count * UNNEST(e.idp) * d.daily_demand_share)*1000 AS demand_profile
FROM (SELECT * FROM demand.egon_heat_timeseries_selected_profiles,
UNNEST(selected_idp_profiles) WITH ORDINALITY as selected_idp) a
JOIN demand.egon_peta_heat b
ON b.zensus_population_id = a.zensus_population_id
JOIN boundaries.egon_map_zensus_climate_zones c
ON c.zensus_population_id = a.zensus_population_id
JOIN demand.egon_daily_heat_demand_per_climate_zone d
ON (c.climate_zone = d.climate_zone AND d.day_of_year = ordinality)
JOIN demand.egon_heat_idp_pool e
ON selected_idp = e.index
JOIN (SELECT zensus_population_id, COUNT(building_id)
FROM demand.egon_heat_timeseries_selected_profiles
GROUP BY zensus_population_id
) f
ON f.zensus_population_id = a.zensus_population_id
WHERE a.building_id = SELECTED_BUILDING_ID
AND b.scenario = 'eGon2035'
AND b.sector = 'residential';

Exemplary resulting residential heat demand time series for a selected day in winter and summer considering different aggregation levels are visualized in figures Temporal distribution of residential heat demand for a selected day in winter and Temporal distribution of residential heat demand for a selected day in summer.

Temporal distribution of residential heat demand for a selected day in winter

Temporal distribution of residential heat demand for a selected day in summer

The temporal disaggregation of CTS heat demand is done using Standard Load Profiles Gas from demandregio [demandregio] considering different profiles per CTS branch.

The heat demand time series for both sectors creation is done in the Dataset HeatTimeSeries.

Gas

Information about gas demands and their spatial and temporal aggregation, including hydrogen and methane demands

Mobility

Motorized individual travel

The electricity demand data of motorized individual travel (MIT) for both the eGon2035 and eGon100RE scenario is set up in the MotorizedIndividualTravel dataset.

The profiles are generated using a modified version of SimBEV v0.1.3. SimBEV generates driving profiles for battery electric vehicles (BEVs) and plug-in hybrid electric vehicles (PHEVs) based on MID survey data [MiD2017] per RegioStaR7 region type [RegioStaR7_2020]. These profiles include driving, parking and (user-oriented) charging times. Different vehicle classes are taken into account whose assumed technical data is given in table EV types. Moreover, charging probabilities for multiple types of charging infrastructure are presumed based on [NOW2020] and [Helfenbein2021]. Given these assumptions, a pool of 33.000 EVs-types is pre-generated and provided through the data bundle (see Data bundle) as well as written to table EgonEvTrip. The complete tech data and assumptions of the run can be found in the metadata_simbev_run.json file, that is provided along with the trip data.

EV types

Tecnnology	Size	Max. charging capacity slow in kW	Max. charging capacity fast in kW	Battery capacity in kWh	Energy consumption in kWh/km
BEV	mini	11	120	60	0.1397
BEV	medium	22	350	90	0.1746
BEV	luxury	50	350	110	0.2096
PHEV	mini	3.7	40	14	0.1425
PHEV	medium	11	40	20	0.1782
PHEV	luxury	11	120	30	0.2138

Heavy-duty transport

In the context of the eGon project, it is assumed that all e-trucks will be completely hydrogen-powered. The hydrogen demand data of all e-trucks is set up in the HeavyDutyTransport dataset for both the eGon2035 and eGon100RE scenario.

In both scenarios the hydrogen consumption is assumed to be 6.68 kgH2 per 100 km with an additional supply chain leakage rate of 0.5 % (see here).

For the eGon2035 scenario the ramp-up figures are taken from the network development plan (version 2021) (Scenario C 2035). According to this, 100,000 e-trucks are expected in Germany in 2035, each covering an average of 100,000 km per year. In total this means 10 Billion km.

For the eGon100RE scenario it is assumed that the heavy-duty transport is completely hydrogen-powered. The total freight traffic with 40 Billion km is taken from the BMWK Langfristszenarien for heavy-duty vehicles larger 12 t allowed total weight (SNF > 12 t zGG).

The total hydrogen demand is spatially distributed on the basis of traffic volume data from [BASt]. For this purpose, first a voronoi partition of Germany using the traffic measuring points is created. Afterwards, the spatial shares of the Voronoi regions in each NUTS3 area are used to allocate hydrogen demand to the NUTS3 regions and are then aggregated per NUTS3 region. The refuelling is assumed to take place at a constant rate. Finally, to determine the hydrogen bus where the hydrogen demand is allocated to, the centroid of each NUTS3 region is used to determine the respective hydrogen Voronoi cell (see GasAreaseGon2035 and GasAreaseGon100RE) it is located in.

Supply

The distribution and assignment of supply capacities or potentials are carried out technology-specific. The different methods are described in the following chapters.

Electricity

The electrical power plants park, including data on geolocations, installed capacities, etc. for the different scenarios is set up in the dataset PowerPlants.

Main inputs into the dataset are target capacities per technology and federal state in each scenario (see Modeling concept and scenarios) as well as the MaStR (see Marktstammdatenregister), OpenStreetMap (see OpenStreetMap) and potential areas (provided through the data bundle, see Data bundle) to distribute the generator capacities within each federal state region. The approach taken to distribute the target capacities within each federal state differs for the different technologies and is described in the following. The final distribution in the eGon2035 scenario is shown in figure Generator park in the eGon2035 scenario.

Generator park in the eGon2035 scenario

Onshore wind

Offshore wind

PV ground mounted

PV rooftop

In a first step, the target capacity in the eGon2035 and eGon100RE scenarios is distributed to all MV grid districts linear to the residential and CTS electricity demands in the grid district (done in function pv_rooftop_per_mv_grid).

Afterwards, the PV rooftop capacity per MV grid district is disaggregated to individual buildings inside the grid district (done in function pv_rooftop_to_buildings). The basis for this is data from the MaStR, which is first cleaned and missing information inferred, and then allocated to specific buildings. New PV plants are in a last step added based on the capacity distribution from MaStR. These steps are in more detail described in the following.

MaStR data cleaning and inference:

• Drop duplicates and entries with missing critical data.
• Determine most plausible capacity from multiple values given in MaStR data.
• Drop generators that don’t have a plausible capacity (23.5 MW > P > 0.1 kW).
• Randomly and weighted add a start-up date if it is missing.
• Extract zip and municipality from ‘site’ given in MaStR data.
• Geocode unique zip and municipality combinations with Nominatim (1 sec delay). Drop generators for which geocoding failed or which are located outside the municipalities of Germany.
• Add some visual sanity checks for cleaned data.

Allocation of MaStR plants to buildings:

• Allocate each generator to an existing building from OSM or a synthetic building (see Building data).
• Determine the quantile each generator and building is in depending on the capacity of the generator and the area of the polygon of the building.
• Randomly distribute generators within each municipality preferably within the same building area quantile as the generators are capacity wise.
• If not enough buildings exist within a municipality and quantile additional buildings from other quantiles are chosen randomly.

Disaggregation of PV rooftop scenario capacities:

• The scenario data per federal state is linearly distributed to the MV grid districts according to the PV rooftop potential per MV grid district.
• The rooftop potential is estimated from the building area given from the OSM buildings.
• Grid districts, which are located in several federal states, are allocated PV capacity according to their respective roof potential in the individual federal states.
• The disaggregation of PV plants within a grid district respects existing plants from MaStR, which did not reach their end of life.
• New PV plants are randomly and weighted generated using the capacity distribution of PV rooftop plants from MaStR.
• Plant metadata (e.g. plant orientation) is also added randomly and weighted using MaStR data as basis.

Hydro

Heat

Heat demand of residential as well as commercial, trade and service (CTS) buildings can be supplied by different technologies and carriers. Within the data model creation, capacities of supply technologies are assigned to specific locations and their demands. The hourly dispatch of heat supply is not part of the data model, but a result of the grid optimization tools.

In general, heat supply can be divided into three categories which include specific technologies: residential and CTS buildings in a district heating area, buildings supplied by individual heat pumps, and buildings supplied by conventional gas boilers. The shares of these categories are taken from external sources for each scenario.

Heat demands of different supply categories

	District heating	Individual heat pumps	Individual gas boilers
eGon2035	69 TWh	27.24 TWh	390.78 TWh
eGon100RE	61.5 TWh	311.5 TWh	0 TWh

The following subsections describe the heat supply methodology for each category.

First, district heating areas are defined for each scenario based on existing district heating areas and an overall district heating share per scenario. To reduce the model complexity, district heating areas are defined per Census cell, either all buildings within a cell are supplied by district heat or none. The first step of the extraction of district heating areas is the identification of Census cells with buildings that are currently supplied by district heating using the building dataset of Census. All Census cells where more than 30% of the buildings are currently supplied by district heat are defined as cells inside a district heating area. The identified cells are then summarized by combining cells that have a maximum distance of 500m.

Second, additional Census cells are assigned to district heating areas considering the heat demand density. Assuming that new district heating grids are more likely in cells with high demand, the remaining Census cells outside of a district heating grid are sorted by their demands. Until the pre-defined national district heating demand is met, cells from that list are assigned to district heating areas. This can also result in new district heating grids which cover only a few Census cells.

To avoid unrealistic large district heating grids in areas with many cities close to each other (e.g. the Ruhr Area), district heating areas with an annual demand > 4 TWh are split by NUTS3 boundaries.

The implementation of the district heating area demarcation is done in DistrictHeatingAreas, the resulting data is stored in the tables demand.egon_map_zensus_district_heating_areas and demand.egon_district_heating_areas. The resulting district heating grids for the scenario eGon2035 are visualized in figure Defined district heating grids in scenario eGon2035, which also includes a zoom on the district heating grid in Berlin.

Defined district heating grids in scenario eGon2035

The national capacities for each supply technology are taken from the Grid Development Plan (GDP) for the scenario eGon2035, in the eGon100RE scenario they are the result of the pypsa-eur-sec run. The distribution of the capacities to district heating grids is done similarly based on [FfE2017], which is also used in the GDP. The basic idea of this method is to use a cascade of heat supply technologies until the heat demand can be covered.

1. Combined heat and power (CHP) plants are assigned to nearby district heating grids first. Their location and thermal capacities are from Marktstammdatenregister [MaStR]. To identify district heating grids that need additional suppliers, the remaining annual heat demand is calculated using the thermal capacities of the CHP plants and assumed full load hours.
2. Large district heating grids with an annual demand that is higher than 96GWh can be supplied by geothermal plants, in case of an intersection of geothermal potential areas and the district heating grid. Smaller district heating grids can be supplied by solar thermal power plants. The national capacities are distributed proportionally to the remaining heat demands. After assigning these plants, the remaining heat demands are reduced by the thermal output and assumed full load hours.
3. Next, the national capacities for central heat pumps and resistive heaters are distributed to all district heating areas proportionally to their remaining demands. Heat pumps are modeled with a time-dependent coefficient of performance depending on the temperature data.
4. In the last step, gas boilers are assigned to every district heating grid regardless of the remaining demand. In the optimization, this can be used as a fall-back option to not run into infeasibilities.

The distribution of CHP plants for different carriers is shown in figure Spatial distribution of CHP plants in scenario eGon2035.

Spatial distribution of CHP plants in scenario eGon2035

Heat pumps supplying individual buildings are first distributed to each medium-voltage grid district, these capacities are later on further disaggregated to single buildings. Similar to central heat pumps they are modeled with a time-dependent coefficient of performance depending on the temperature data.

The distribution of the national capacities to each medium-voltage grid district is proportional to the heat demand outside of district heating grids.

@RLI: Distribution on building level

All residential and CTS buildings that are neither supplied by a district heating grid nor an individual heat pump are supplied by gas boilers. The demand time series of these buildings are multiplied by the efficiency of gas boilers and aggregated per methane grid node.

All heat supply categories are implemented in the dataset HeatSupply. The data is stored in the tables demand.egon_district_heating and demand.egon_individual_heating.

Gas

Information on gas supply - hydrogen and methane.

Flexibility options

Different flexibility options are part of the model and can be utilized in the optimization of the energy system. Therefore detailed information about flexibility potentials and their distribution are needed. The considered technologies described in the following chapters range from different storage units, through dynamic line rating to Demand-Side-Management measures.

Demand-Side-Management

How did we implement DSM? Results etc.

Dynamic line rating

To calculate the transmission capacity of each transmission line in the model, the procedure suggested in the Principles for the Expansion Planning of the German Transmission Network [NEP2021] where used:

1. Import the temperature and wind temporal raster layers from ERA-5. Hourly resolution data from the year 2011 was used. Raster resolution latitude-longitude grids at 0.25° x 0.25°.

2. Import shape file for the 9 regions proposed by the Principles for the Expansion Planning. See Figure 1.

Figure 1: Representative regions in Germany for DLR analysis [NEP2021]

3. Find the lowest wind speed in each region. To perform this, for each independent region, the wind speed of every cell in the raster layer should be extracted and compared. This procedure is repeated for each hour in the year 2011. The results are the 8760 lowest wind speed per region.

4. Find the highest temperature in each region. To perform this, for each independent region, the temperature of every cell in the raster layer should be extracted and compared. This procedure is repeated for each hour in the year 2011. The results are the 8760 maximum temperature per region.

5. Calculate the maximum capacity for each region using the parameters shown in Figure 2.

Figure 2: transmission capacity based on max temperature and min wind speed [NEP2021]

6. Assign the maximum capacity of the corresponding region to each transmission line inside each one of them. Crossborder lines and underground lines receive no values. It means that their capacities are static and equal to their nominal values. Lines that cross borders between regions receive the lowest capacity per hour of the regions containing the line.

[NEP2021]

Principles for the Expansion Planning of the German Transmission Network https://www.netzentwicklungsplan.de/

E-Mobility

What flexibilities does e-mobility provide to the system. How did we implement it?

Battery stores

Battery storage units comprise home batteries and larger, grid-supportive batteries. National capacities for home batteries arise from external sources, e.g. the Grid Development Plan for the scenario eGon2035, whereas the capacities of large-scale batteries are a result of the grid optimization tool eTraGo.

Home battery capacities are first distributed to medium-voltage grid districts (MVGD) and based on that further disaggregated to single buildings. The distribution on MVGD level is done proportional to the installed capacities of solar rooftop power plants, assuming that they are used as solar home storage.

Potential large-scale batteries are included in the data model at every substation. The data model includes technical and economic parameters, such as efficiencies and investment costs. The energy-to-power ratio is set to a fixed value of 6 hours. Other central parameters are given in the following table

Parameters of batteries for scenario eGon2035

	Value	Sources
Efficiency store	98 %	[DAE_store]
Efficiency dispatch	98 %	[DAE_store]
Standing loss	0 %	[DAE_store]
Investment costs	838 €/kW	[DAE_store]
Home storage units	16.8 GW	[NEP2021]

On transmission grid level, distinguishing between home batteries and large-scale batteries was not possible. Therefore, the capacities of home batteries were set as a lower boundary of the large-scale battery capacities. This is implemented in the dataset StorageEtrago, the data for batteries in the transmission grid is stored in the database table grid.egon_etrago_storage.

Gas stores

Description of methods and assumptions to include potential h2 stores in the system

Hydrogen stores

Methane stores

Heat stores

The heat sector can provide flexibility through stores that allow shifting energy in time. The data model includes hot water tanks as heat stores in individual buildings and pit thermal energy storage for district heating grids (further described in District heating).

Within the data model, potential locations as well as technical and economic parameters of these stores are defined. The installed store and (dis-)charging capacities are part of the grid optimization methods that can be performed by eTraGo. The power-to-energy ratio is not predefined but a result of the optimization, which allows to build heat stores with various time horizons.

Individual heat stores can be built in every building with an individual heat pump. Central heat stores can be built next to district heating grids. There are no maximum limits for the energy output as well as (dis-)charging capacities implemented yet.

Central cost assumptions for central and decentral heat stores are listed in the table below. The parameters can differ for each scenario in order to include technology updates and learning curves. The table focuses on the scenario eGon2035.

Parameters of heat stores

	Technology	Costs for store capacity	Costs for (dis-)charging capacity	Round-trip efficiency	Sources
District heating	Pit thermal energy storage	0.51 EUR / kWh	0 EUR / kW	70 %	[DAE_store]
Buildings with heat pump	Water tank	1.84 EUR / kWh	0 EUR / kW	70 %	[DAE_store]

The heat stores are implemented as a part of the dataset HeatEtrago, the data is written into the tables grid.egon_etrago_bus, grid.egon_etrago_link and grid.egon_etrago_store.

Published data