diff --git a/docs/about.rst b/docs/about.rst index 5dcdee32a..28f7d3525 100644 --- a/docs/about.rst +++ b/docs/about.rst @@ -44,6 +44,7 @@ The figure below visualizes the interdependencies between the different tools. :width: 800 :alt: eGon-data tool chain +.. _concept-and-scenarios-ref: Modeling concept and scenarios =============================== diff --git a/docs/data.rst b/docs/data.rst index f6646b176..4dfb21a0a 100644 --- a/docs/data.rst +++ b/docs/data.rst @@ -1,10 +1,23 @@ **** 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. + +.. include:: data/input_data.rst 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 ---------------- @@ -18,6 +31,11 @@ Gas 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-demand-ref: + Electricity ----------- @@ -42,6 +60,9 @@ Mobility 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 ----------- @@ -60,6 +81,10 @@ Gas 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 ---------------------- @@ -94,14 +119,4 @@ Heat stores Published data ============== -Data bundle ------------ -The data bundle is published on -`zenodo `_. It contains several data -sets, which serve as a basis for egon-data. One such data set is the geocoding -for the `MaStR data set `_ which is -used for eGon-data as well. Whenever the MaStR data set is updated it is -necessary to redo the geocoding with the new data set and update the data -bundle accordingly. The geocoding can be done based on the -`mastr-geocoding repository `_. diff --git a/docs/data/DLR.rst b/docs/data/DLR.rst index 4c0b030c5..5414db22a 100644 --- a/docs/data/DLR.rst +++ b/docs/data/DLR.rst @@ -1 +1,47 @@ -Methods to include dynamic line rating in our model. +==================================================== +Methods to include dynamic line rating in our model +==================================================== + +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. + +.. image:: images/regions_DLR.png + :width: 400 + :alt: regions DLR + +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. + +.. image:: images/table_max_capacity_DLR.png + :width: 400 + :alt: table_max_capacity_DLR + +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/ \ No newline at end of file diff --git a/docs/data/batteries.rst b/docs/data/batteries.rst index d023f8d1f..2fcb79d46 100644 --- a/docs/data/batteries.rst +++ b/docs/data/batteries.rst @@ -1 +1,37 @@ -Information about batteries in our system. +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 + +.. list-table:: Parameters of batteries for scenario eGon2035 + :widths: 40 30 30 + :header-rows: 1 + + * - + - 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 :py:class:`StorageEtrago `, the data for batteries in the transmission grid is stored in the database table :py:class:`grid.egon_etrago_storage `. diff --git a/docs/data/electricity_grids.rst b/docs/data/electricity_grids.rst index 9717ab671..0d288e836 100644 --- a/docs/data/electricity_grids.rst +++ b/docs/data/electricity_grids.rst @@ -1,7 +1,125 @@ -Information about our electricity grids and how they were created +.. _ehv-hv-grids: -High and extra-high voltage grids -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +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 +:py:class:`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]_. + +.. _ding0-grids: 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 :ref:`ehv-hv-grids`), locations and peak demands +of buildings in the grid (see :ref:`building-data-ref` respectively :ref:`electricity-demand-ref`), +as well as locations of generators from MaStR (see :ref:`mastr-ref`). 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 :ref:`ding0-mv-grid`. +The grid data of all over 3.800 MV grids is published on `zenodo `_. + +.. figure:: /images/ding0_mv_lv_grid.png + :name: ding0-mv-grid + :width: 600 + + 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: + +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 :ref:`ding0-mv-grid` (orange line). + +The MV grid districts are generated in the dataset +:class:`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 (:class:`Vg250GemClean`) +2. Locations of HV-MV substations (:class:`EgonHvmvSubstation`) +3. HV-MV substation voronoi polygons (:class:`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 :func:`define_mv_grid_districts`. + +.. _load-areas-ref: + +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 :ref:`ding0-mv-grid` (grey and orange areas). + +The load areas are set up in the +:class:`LoadArea` dataset. +The methods used for identifying the load areas are heavily inspired +by Hülk et al. (2017) [Huelk2017]_ (section 2.4). diff --git a/docs/data/electricity_supply.rst b/docs/data/electricity_supply.rst index 97e555507..418bd886b 100644 --- a/docs/data/electricity_supply.rst +++ b/docs/data/electricity_supply.rst @@ -1 +1,86 @@ -Information on electricity supply by carrier etc. +The electrical power plants park, including data on geolocations, installed capacities, etc. +for the different scenarios is set up in the dataset +:class:`PowerPlants`. + +Main inputs into the dataset are target capacities per technology and federal state +in each scenario (see :ref:`concept-and-scenarios-ref`) as well as the MaStR (see :ref:`mastr-ref`), +OpenStreetMap (see :ref:`osm-ref`) and potential areas (provided through the data bundle, +see :ref:`data-bundle-ref`) 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 :ref:`generator-park-egon-2035`. + +.. figure:: /images/Erzeugerpark.png + :name: generator-park-egon-2035 + :width: 400 + + 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 +:func:`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 +:func:`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 :ref:`building-data-ref`). +* 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 +++++++ + + diff --git a/docs/data/gas_grids.rst b/docs/data/gas_grids.rst index ee113f03d..f3df18ea2 100644 --- a/docs/data/gas_grids.rst +++ b/docs/data/gas_grids.rst @@ -1,7 +1,7 @@ Information about the gas grids and how they were created -Methane grid -~~~~~~~~~~~~ +Methane grid +++++++++++++++ Hydrogen grid -~~~~~~~~~~~~~ +++++++++++++++ diff --git a/docs/data/heat_demand.rst b/docs/data/heat_demand.rst index 9874a435f..6e004ae28 100644 --- a/docs/data/heat_demand.rst +++ b/docs/data/heat_demand.rst @@ -1 +1,100 @@ -Information about heat demands and their spatial and temporal aggregation +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: + +.. list-table:: Heat demands per sector and scenario + :widths: 25 25 25 25 + :header-rows: 1 + + * - + - 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 :py:class:`demand.egon_peta_heat `. +The implementation of these dataprocessing steps can be found in :py:class:`HeatDemandImport `. + +Figure :ref:`residential-heat-demand-annual` shows the distribution of residential heat demands for scenario ``eGon2035``, +categorized for different levels of annual demands. + +.. figure:: /images/residential_heat_demand.png + :name: residential-heat-demand-annual + :width: 400 + + 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 :py:class:`demand.egon_heat_timeseries_selected_profiles `, :py:class:`demand.egon_daily_heat_demand_per_climate_zone `, :py:class:`boundaries.egon_map_zensus_climate_zones `. To create the profiles for a selected buidling, these tables +have to be combined, e.g. like this: + +.. code-block:: none + + 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 :ref:`residential-heat-demand-timeseries-winter` and :ref:`residential-heat-demand-timeseries-summer`. + +.. figure:: /images/residential_heat_demand_profile_winter.png + :name: residential-heat-demand-timeseries-winter + :width: 400 + + Temporal distribution of residential heat demand for a selected day in winter + +.. figure:: /images/residential_heat_demand_profile_summer.png + :name: residential-heat-demand-timeseries-summer + :width: 400 + + 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 +:py:class:`HeatTimeSeries `. diff --git a/docs/data/heat_stores.rst b/docs/data/heat_stores.rst index a5aca786f..59a10c172 100644 --- a/docs/data/heat_stores.rst +++ b/docs/data/heat_stores.rst @@ -1 +1,35 @@ -Information on 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 :ref:`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``. + +.. list-table:: Parameters of heat stores + :widths: 16 16 16 16 16 16 + :header-rows: 1 + + * - + - 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 :py:class:`HeatEtrago `, the data is written into the tables :py:class:`grid.egon_etrago_bus `, :py:class:`grid.egon_etrago_link ` and :py:class:`grid.egon_etrago_store `. + diff --git a/docs/data/heat_supply.rst b/docs/data/heat_supply.rst index 503425b07..f0c633edb 100644 --- a/docs/data/heat_supply.rst +++ b/docs/data/heat_supply.rst @@ -1 +1,80 @@ -Description of methods to include heat supply in the data model etc. +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. + +.. list-table:: Heat demands of different supply categories + :widths: 20 20 20 20 + :header-rows: 1 + + * - + - 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. + +.. _district-heating: + +District heating +~~~~~~~~~~~~~~~~ + +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 :py:class:`DistrictHeatingAreas `, the resulting data is stored in the tables :py:class:`demand.egon_map_zensus_district_heating_areas ` and :py:class:`demand.egon_district_heating_areas `. +The resulting district heating grids for the scenario eGon2035 are visualized in figure :ref:`district-heating-areas`, which also includes a zoom on the district heating grid in Berlin. + +.. figure:: /images/district_heating_areas.png + :name: district-heating-areas + :width: 800 + + 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. + +#. 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. + +#. 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. + +#. 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. + +#. 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 :ref:`chp-plants`. + +.. figure:: /images/combined_heat_and_power_plants.png + :name: chp-plants + :width: 400 + + Spatial distribution of CHP plants in scenario ``eGon2035`` + + +Individual heat pumps +~~~~~~~~~~~~~~~~~~~~~ + +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 + +Individual gas boilers +~~~~~~~~~~~~~~~~~~~~~~ + +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 :py:class:`HeatSupply `. The data is stored in the tables :py:class:`demand.egon_district_heating ` and :py:class:`demand.egon_individual_heating `. diff --git a/docs/data/input_data.rst b/docs/data/input_data.rst new file mode 100644 index 000000000..b1dd53cb6 --- /dev/null +++ b/docs/data/input_data.rst @@ -0,0 +1,143 @@ +.. _data-bundle-ref: + +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. + +.. _mastr-ref: + +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 :class:`MastrData`. + +.. _osm-ref: + +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 :class:`OpenStreetMap`. + +In the :class:`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-ref: + +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 :ref:`ding0-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 :class:`Demand_Building_Assignment` +dataset in function :func:`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 :class:`CtsDemandBuildings` +dataset in function :func:`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`. diff --git a/docs/data/mobility_demand.rst b/docs/data/mobility_demand.rst index 8a2dced96..5beb00f5b 100644 --- a/docs/data/mobility_demand.rst +++ b/docs/data/mobility_demand.rst @@ -1 +1,71 @@ -Information about demands in the mobility sector. +Motorized individual travel +++++++++++++++++++++++++++++ + +The electricity demand data of motorized individual travel (MIT) for both the eGon2035 +and eGon100RE scenario is set up +in the :py:class:`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 :ref:`ev-types-data`. +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 :ref:`data-bundle-ref`) as well as written +to table :py:class:`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. + +.. csv-table:: EV types + :header: "Tecnnology", "Size", "Max. charging capacity slow in kW", "Max. charging capacity fast in kW", "Battery capacity in kWh", "Energy consumption in kWh/km" + :widths: 10, 10, 30, 30, 25, 10 + :name: ev-types-data + + "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 :py:class:`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 +:py:class:`GasAreaseGon2035` and +:py:class:`GasAreaseGon100RE`) it is +located in. diff --git a/docs/images/Erzeugerpark.png b/docs/images/Erzeugerpark.png new file mode 100644 index 000000000..3d67b2af2 Binary files /dev/null and b/docs/images/Erzeugerpark.png differ diff --git a/docs/images/combined_heat_and_power_plants.png b/docs/images/combined_heat_and_power_plants.png new file mode 100644 index 000000000..3120b08a4 Binary files /dev/null and b/docs/images/combined_heat_and_power_plants.png differ diff --git a/docs/images/ding0_mv_lv_grid.png b/docs/images/ding0_mv_lv_grid.png new file mode 100644 index 000000000..0ed848db7 Binary files /dev/null and b/docs/images/ding0_mv_lv_grid.png differ diff --git a/docs/images/district_heating_areas.png b/docs/images/district_heating_areas.png new file mode 100644 index 000000000..226a3d8a4 Binary files /dev/null and b/docs/images/district_heating_areas.png differ diff --git a/docs/images/regions_DLR.png b/docs/images/regions_DLR.png new file mode 100644 index 000000000..b4a7aedfd Binary files /dev/null and b/docs/images/regions_DLR.png differ diff --git a/docs/images/residential_heat_demand.png b/docs/images/residential_heat_demand.png new file mode 100644 index 000000000..974c9c604 Binary files /dev/null and b/docs/images/residential_heat_demand.png differ diff --git a/docs/images/residential_heat_demand_profile_summer.png b/docs/images/residential_heat_demand_profile_summer.png new file mode 100644 index 000000000..3c41641d3 Binary files /dev/null and b/docs/images/residential_heat_demand_profile_summer.png differ diff --git a/docs/images/residential_heat_demand_profile_winter.png b/docs/images/residential_heat_demand_profile_winter.png new file mode 100644 index 000000000..e661fd289 Binary files /dev/null and b/docs/images/residential_heat_demand_profile_winter.png differ diff --git a/docs/images/table_max_capacity_DLR.png b/docs/images/table_max_capacity_DLR.png new file mode 100644 index 000000000..016b7db3f Binary files /dev/null and b/docs/images/table_max_capacity_DLR.png differ diff --git a/docs/literature.rst b/docs/literature.rst index d725279b4..e44a0dc0f 100644 --- a/docs/literature.rst +++ b/docs/literature.rst @@ -1,3 +1,45 @@ ********** Literature ********** + +.. [BASt] Bundesanstalt für Straßenwesen, Automatische Zählstellen 2020 (2020). URL https://www.bast.de/DE/Verkehrstechnik/Fachthemen/v2-verkehrszaehlung/Daten/2020_1/Jawe2020.cs + +.. [Brakelmann2004] H. Brakelmann, Netzverstärkungs-Trassen zur Übertragung von Windenergie: Freileitung oder Kabel? (2004). URL http://www.ets.uni-duisburg-essen.de/download/public/Freileitung_Kabel.pdf + +.. [Buettner2022] C. Büttner, J. Amme, J. Endres, A. Malla, B. Schachler, I. Cußmann, Open modeling of electricity and heat demand curves for all residential buildings in Germany, Energy Informatics 5 (1) (2022) 21. doi:10.1186/s42162-022-00201-y. URL https://doi.org/10.1186/s42162-022-00201-y + +.. [Census] S. B. (Destatis), Datensatzbeschreibung ”Haushalte im 100 Meter-Gitter” (2018). URL https://www.zensus2011.de/SharedDocs/Downloads/DE/Pressemitteilung/DemografischeGrunddaten/Datensatzbeschreibung_Haushalt_100m_Gitter.html + +.. [DAE_store] Danish Energy Agency, Technology Data – Energy storage, First published 2018 by the Danish Energy Agency and Energinet, URL https://ens.dk/en/our-services/projections-and-models/technology-data/technology-data-energy-storage + +.. [demandregio] F. Gotzens, B. Gillessen, S. Burges, W. Hennings, J. Müller-Kirchenbauer, S. Seim, P. Verwiebe, S. Tobias, F. Jetter, T. Limmer, DemandRegio - Harmonisierung und Entwicklung von Verfahren zur regionalen und zeitlichen Auflösung von Energienachfragen (2020). URL https://openaccess.ffe.de/10.34805/ffe-119-20 + +.. [Energiereferenzprognose] Prognos AG, Energiewirtschaftliches Institut an der Universität zu Köln, Gesellschaft für Wirtschaftliche Strukturforschung mbH: Entwicklung der Energiemärkte – Energiereferenzprognose (2014) + +.. [eXtremOS] A. Guminski, C. Fiedler, S. Kigle, C. Pellinger, P. Dossow, K. Ganz, F. Jetter, T. Kern, T. Limmer, A. Murmann, J. Reinhard, T. Schmid, T. Schmidt-Achert, S. von Roon, eXtremOS Summary Report (2021). doi:https://doi.org/10.34805/ffe-24-21. + +.. [FfE2017] Flexibilisierung der Kraft-Wärme-Kopplung; 2017; Forschungsstelle für Energiewirtschaft e.V. (FfE) + +.. [Helfenbein2021] K. Helfenbein, Analyse des Einflusses netzdienlicher Ladestrategien auf Verteilnetze aufgrund der zunehmenden Netzintegration von Elektrofahrzeugen, Master’s thesis, Hochschule für Technik und Wirtschaft Berlin, URL https://reiner-lemoine-institut.de/analyse-einflussesnetzdienlicher-ladestrategien-verteilnetze-zunehmender-netzintegration-elektrofahrzeugen-helfenbein-2021/ + +.. [Hotmaps] S. Pezzutto, S. Zambotti, S. Croce, P. Zambelli, G. Garegnani, C. Scaramuzzino, R. P. Pascuas, A. Zubaryeva, F. Haas, D. Exner, A. Mueller, M. Hartner, T. Fleiter, A.-L. Klingler, M. Kuehnbach, P. Manz, S. Marwitz, M. Rehfeldt, J. Steinbach, E. Popovski, Hotmaps project, d2.3 wp2 report – open data set for the eu28 (2018). URL www.hotmaps-project.eu + +.. [Huelk2017] L. Hülk, L. Wienholt, I. Cußmann, U.P. Müller, C. Matke, E. Kötter, Allocation of annual electricity consumption and power generation capacities across multiple voltage levels in a high spatial resolution, International Journal of Sustainable Energy Planning and Management Vol. 13 2017 79–92. URL https://journals.aau.dk/index.php/sepm/article/view/1833 + +.. [MiD2017] Bundesministerium für Digitales und Verkehr, Mobilität in Deutschland 2017 (2017). URL https://daten.clearingstelle-verkehr.de/279/ + +.. [Mueller2018] U. Mueller, L. Wienholt, D. Kleinhans, I. Cussmann, W.-D. Bunke, G. Pleßmann, J. Wendiggensen 2018 J. Phys.: Conf. Ser. 977 012003, DOI 10.1088/1742-6596/977/1/012003 + +.. [NEP2021] Übertragungsnetzbetreiber Deutschland (2021): *Netzentwicklungsplan Strom 2035*, Version 2021, 1. Entwurf. 2021. + +.. [NOW2020] Nationale Leitstelle Ladeinfrastruktur, Ladeinfrastruktur nach 2025/2030: Szenarien für den Markthochlauf (2020). URL https://www.now-gmbh.de/wp-content/uploads/2020/11/Studie_Ladeinfrastruktur-nach-2025-2.pdf + +.. [OSM] Geofabrik GmbH and OpenStreetMap-Contributors, OpenStreetMap Data Extracts, Stand 01.01.2022 (2022). URL https://download.geofabrik.de/europe/germany-220101.osm.pbf + +.. [Peta] Europa-Universität Flensburg, Halmstad University and Aalborg University, Pan-European Thermal Atlas - Residential heat demand (2021). URL https://s-eenergies-open-data-euf.hub.arcgis.com/maps/d7d18b63250240a49eb81db972aa573e/about + +.. [RegioStaR7_2020] Bundesministerium für Digitales und Verkehr, Regionalstatistische Raumtypologie (RegioStaR7), Gebietsstand 2020 (2020). URL https://mcloud.de/web/guest/suche/-/results/detail/536149D1-2902-4975-9F7D-253191C0AD07 + +.. [Schmidt2018] D. Schmidt, Supplementary material to the masters thesis: NUTS-3 Regionalization of Industrial Load Shifting Potential in Germany using a Time-Resolved Model (Nov. 2019). doi:10.5281/zenodo.3613767. URL https://doi.org/10.5281/zenodo.3613767 + +.. [sEEnergies] T. Fleiter, P. Manz, N. Neuwirth, F. Mildner, K. Persson, U.AND Kermeli, W. Crijns-Graus, C. Rutten, seenergies d5.1 dataset web-app.seenergies arcgis online web-apps hosted by europa-universität flensburg (2020). URL https://tinyurl.com/sEEnergies-D5-1 diff --git a/src/egon/data/datasets/calculate_dlr.py b/src/egon/data/datasets/calculate_dlr.py index 95f1fac85..3680f9abb 100644 --- a/src/egon/data/datasets/calculate_dlr.py +++ b/src/egon/data/datasets/calculate_dlr.py @@ -21,10 +21,32 @@ class Calculate_dlr(Dataset): + """Calculate DLR and assign values to each line in the db + + Parameters + ---------- + *No parameters required + + *Dependencies* + * :py:class:`DataBundle ` + * :py:class:`Osmtgmod ` + * :py:class:`WeatherData ` + * :py:class:`FixEhvSubnetworks ` + + *Resulting tables* + * :py:class:`grid.egon_etrago_line_timeseries + ` is filled + """ + + #: + name: str = "dlr" + #: + version: str = "0.0.1" + def __init__(self, dependencies): super().__init__( - name="dlr", - version="0.0.1", + name=self.name, + version=self.version, dependencies=dependencies, tasks=(dlr,), ) diff --git a/src/egon/data/datasets/emobility/heavy_duty_transport/h2_demand_distribution.py b/src/egon/data/datasets/emobility/heavy_duty_transport/h2_demand_distribution.py index e3a94a1a3..b2511dd74 100644 --- a/src/egon/data/datasets/emobility/heavy_duty_transport/h2_demand_distribution.py +++ b/src/egon/data/datasets/emobility/heavy_duty_transport/h2_demand_distribution.py @@ -1,6 +1,6 @@ """ -Calculation of hydrogen demand based on a Voronoi distribution of counted truck traffic -among NUTS 3 regions. +Calculation of hydrogen demand based on a Voronoi partition of counted truck traffic +used to allocate it to NUTS3 regions and finally aggregate it on NUTS3 level. """ from geovoronoi import points_to_coords, voronoi_regions_from_coords from loguru import logger diff --git a/src/egon/data/datasets/emobility/motorized_individual_travel/ev_allocation.py b/src/egon/data/datasets/emobility/motorized_individual_travel/ev_allocation.py index a64ed1c50..a65a69e99 100644 --- a/src/egon/data/datasets/emobility/motorized_individual_travel/ev_allocation.py +++ b/src/egon/data/datasets/emobility/motorized_individual_travel/ev_allocation.py @@ -47,9 +47,9 @@ def fix_missing_ags_municipality_regiostar(muns, rs7_data): """Check if all AGS of municipality dataset are included in RegioStaR7 dataset and vice versa. - As of Dec 2021, some municipalities are not included int he RegioStaR7 + As of Dec 2021, some municipalities are not included int the RegioStaR7 dataset. This is mostly caused by incorporations of a municipality by - another municipality. This is fixed by assining a RS7 id from another + another municipality. This is fixed by assigning a RS7 id from another municipality with similar AGS (most likely a neighboured one). Missing entries in the municipality dataset is printed but not fixed diff --git a/src/egon/data/datasets/fill_etrago_gen.py b/src/egon/data/datasets/fill_etrago_gen.py index c9d8ea68b..cae8fff4f 100644 --- a/src/egon/data/datasets/fill_etrago_gen.py +++ b/src/egon/data/datasets/fill_etrago_gen.py @@ -9,10 +9,32 @@ class Egon_etrago_gen(Dataset): + """ + Group generators based on Scenario, carrier and bus. Marginal costs are + assigned to generators without this data. Grouped generators + are sent to the egon_etrago_generator table and a timeseries is assigned + to the weather dependent ones. + + *Dependencies* + * :py:class:`PowerPlants ` + * :py:class:`WeatherData ` + + *Resulting tables* + * :py:class:`grid.egon_etrago_generator + ` is extended + * :py:class:`grid.egon_etrago_generator_timeseries + ` is filled + + """ + #: + name: str = "etrago_generators" + #: + version: str = "0.0.8" + def __init__(self, dependencies): super().__init__( - name="etrago_generators", - version="0.0.8", + name=self.name, + version=self.version, dependencies=dependencies, tasks=(fill_etrago_generators,), ) @@ -65,7 +87,6 @@ def fill_etrago_generators(): def group_power_plants(power_plants, renew_feedin, etrago_gen_orig, cfg): - # group power plants by bus and carrier agg_func = { @@ -89,7 +110,6 @@ def group_power_plants(power_plants, renew_feedin, etrago_gen_orig, cfg): def add_marginal_costs(power_plants): - scenarios = power_plants.scenario.unique() pp = pd.DataFrame() @@ -124,7 +144,6 @@ def add_marginal_costs(power_plants): def fill_etrago_gen_table(etrago_pp2, etrago_gen_orig, cfg, con): - etrago_pp = etrago_pp2[ ["carrier", "el_capacity", "bus_id", "scenario", "marginal_cost"] ] @@ -243,7 +262,6 @@ def power_timeser(weather_data): def adjust_renew_feedin_table(renew_feedin, cfg): - # Define carrier 'pv' as 'solar' carrier_pv_mask = renew_feedin["carrier"] == "pv" renew_feedin.loc[carrier_pv_mask, "carrier"] = "solar" diff --git a/src/egon/data/datasets/heat_etrago/__init__.py b/src/egon/data/datasets/heat_etrago/__init__.py index 23241fdcb..2ff427f5c 100644 --- a/src/egon/data/datasets/heat_etrago/__init__.py +++ b/src/egon/data/datasets/heat_etrago/__init__.py @@ -102,6 +102,7 @@ def insert_buses(carrier, scenario): def insert_store(scenario, carrier): + sources = config.datasets()["etrago_heat"]["sources"] targets = config.datasets()["etrago_heat"]["targets"] diff --git a/src/egon/data/datasets/heat_etrago/hts_etrago.py b/src/egon/data/datasets/heat_etrago/hts_etrago.py index 1cd91dbba..112919457 100644 --- a/src/egon/data/datasets/heat_etrago/hts_etrago.py +++ b/src/egon/data/datasets/heat_etrago/hts_etrago.py @@ -11,6 +11,7 @@ def hts_to_etrago(): + sources = config.datasets()["etrago_heat"]["sources"] targets = config.datasets()["etrago_heat"]["targets"] scenario = "eGon2035" @@ -18,6 +19,7 @@ def hts_to_etrago(): for carrier in carriers: if carrier == "central_heat": + # Map heat buses to district heating id and area_id # interlinking bus_id and area_id bus_area = db.select_dataframe( diff --git a/src/egon/data/datasets/power_plants/__init__.py b/src/egon/data/datasets/power_plants/__init__.py index 71213e66f..39f68ad40 100755 --- a/src/egon/data/datasets/power_plants/__init__.py +++ b/src/egon/data/datasets/power_plants/__init__.py @@ -56,10 +56,50 @@ class EgonPowerPlants(Base): class PowerPlants(Dataset): + """ + This module creates all electrical generators for different scenarios. It + also calculates the weather area for each weather dependent generator. + + *Dependencies* + * :py:class:`Chp ` + * :py:class:`CtsElectricityDemand + ` + * :py:class:`HouseholdElectricityDemand + ` + * :py:class:`mastr_data ` + * :py:func:`define_mv_grid_districts + ` + * :py:class:`RePotentialAreas + ` + * :py:class:`ZensusVg250 + ` + * :py:class:`ScenarioCapacities + ` + * :py:class:`ScenarioParameters + ` + * :py:func:`Setup ` + * :py:class:`substation_extraction + ` + * :py:class:`Vg250MvGridDistricts + ` + * :py:class:`ZensusMvGridDistricts + ` + + *Resulting tables* + * :py:class:`supply.egon_power_plants + ` is filled + + """ + + #: + name: str = "PowerPlants" + #: + version: str = "0.0.18" + def __init__(self, dependencies): super().__init__( - name="PowerPlants", - version="0.0.18", + name=self.name, + version=self.version, dependencies=dependencies, tasks=( create_tables, @@ -347,7 +387,6 @@ def insert_hydro_plants(scenario): } for carrier in map_carrier.keys(): - # import target values target = select_target(carrier, scenario) @@ -500,9 +539,7 @@ def assign_voltage_level(mastr_loc, cfg, mastr_working_dir): def assign_voltage_level_by_capacity(mastr_loc): - for i, row in mastr_loc[mastr_loc.voltage_level.isnull()].iterrows(): - if row.Nettonennleistung > 120: level = 1 elif row.Nettonennleistung > 20: @@ -610,7 +647,6 @@ def insert_hydro_biomass(): def allocate_conventional_non_chp_power_plants(): - carrier = ["oil", "gas"] cfg = egon.data.config.datasets()["power_plants"] @@ -625,14 +661,12 @@ def allocate_conventional_non_chp_power_plants(): ) for carrier in carrier: - nep = select_nep_power_plants(carrier) if nep.empty: print(f"DataFrame from NEP for carrier {carrier} is empty!") else: - mastr = select_no_chp_combustion_mastr(carrier) # Assign voltage level to MaStR @@ -771,7 +805,6 @@ def allocate_conventional_non_chp_power_plants(): def allocate_other_power_plants(): - # Get configuration cfg = egon.data.config.datasets()["power_plants"] boundary = egon.data.config.settings()["egon-data"]["--dataset-boundary"]