Apply pre-commit hooks to entire codebase

.github/ISSUE_TEMPLATE/bug_report.md

@@ -7,12 +7,12 @@ assignees: ''
 
 ---
 
-**Describe the bug**  
+**Describe the bug**
 A clear and concise description of what the bug is.
 
 ---
 
-**To Reproduce**  
+**To Reproduce**
 Steps to reproduce the behavior:
 1. Go to '...'
 2. Click on '...'
@@ -21,12 +21,12 @@ Steps to reproduce the behavior:
 
 ---
 
-**Expected behavior**  
+**Expected behavior**
 A clear and concise description of what you expected to happen.
 
 ---
 
-**Screenshots**  
+**Screenshots**
 If applicable, add screenshots to help explain your problem.
 
 ---
@@ -39,10 +39,10 @@ If applicable, add screenshots to help explain your problem.
 
 ---
 
-**Proposed solution (optional)**  
+**Proposed solution (optional)**
 If you have an idea of how this issue could be fixed, describe it here.
 
 ---
 
-**Additional context**  
+**Additional context**
 Add any other context about the problem here.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -8,7 +8,7 @@ assignees: ''
 ---
 
 **Is your feature request related to a problem? Please describe.**
-A clear and concise description of what the problem is.  
+A clear and concise description of what the problem is.
 E.g. *I'm always frustrated when [...]*
 
 ---

ci/bootstrap.py

@@ -38,10 +38,12 @@ def exec_in_env():
             except subprocess.CalledProcessError:
                 check_call(["virtualenv", env_path])
         print("Installing `jinja2` into bootstrap environment...")
-        check_call([join(bin_path, "pip"), "install", "jinja2", "tox", "matrix"])
+        check_call(
+            [join(bin_path, "pip"), "install", "jinja2", "tox", "matrix"]
+        )
     python_executable = join(bin_path, "python")
     if not os.path.exists(python_executable):
-        python_executable += '.exe'
+        python_executable += ".exe"
 
     print("Re-executing with: {0}".format(python_executable))
     print("+ exec", python_executable, __file__, "--no-env")
@@ -58,25 +60,33 @@ def main():
         loader=jinja2.FileSystemLoader(join(base_path, "ci", "templates")),
         trim_blocks=True,
         lstrip_blocks=True,
-        keep_trailing_newline=True
+        keep_trailing_newline=True,
     )
 
     tox_environments = {}
-    for (alias, conf) in matrix.from_file(join(base_path, "setup.cfg")).items():
+    for (alias, conf) in matrix.from_file(
+        join(base_path, "setup.cfg")
+    ).items():
         deps = conf["dependencies"]
         tox_environments[alias] = {
             "deps": deps.split(),
         }
         if "coverage_flags" in conf:
-            cover = {"false": False, "true": True}[conf["coverage_flags"].lower()]
+            cover = {"false": False, "true": True}[
+                conf["coverage_flags"].lower()
+            ]
             tox_environments[alias].update(cover=cover)
         if "environment_variables" in conf:
             env_vars = conf["environment_variables"]
             tox_environments[alias].update(env_vars=env_vars.split())
 
     for name in os.listdir(join("ci", "templates")):
         with open(join(base_path, name), "w") as fh:
-            fh.write(jinja.get_template(name).render(tox_environments=tox_environments))
+            fh.write(
+                jinja.get_template(name).render(
+                    tox_environments=tox_environments
+                )
+            )
         print("Wrote {}".format(name))
     print("DONE.")
 

docs/_templates/module.rst_t

@@ -6,4 +6,3 @@
 {%- for option in automodule_options %}
    :{{ option }}:
 {%- endfor %}
-

docs/about.rst

@@ -6,25 +6,25 @@ Project background
 ==================
 
 egon-data provides a transparent and reproducible open data-based data processing pipeline for generating data models suitable for energy system modeling. The data is customized for the requirements of the research project eGo_n. The research project aims to develop tools for open and cross-sectoral planning of transmission and distribution grids. For further information please visit the `eGo_n project website <https://ego-n.org/>`_.
-egon-data is a further development of the `Data processing <https://github.com/openego/data_processing>`_ developed in the former research project `open_eGo <https://openegoproject.wordpress.com/>`_. It aims to extend the data models as well as improve the replicability and manageability of the data preparation and processing. 
-The resulting data set serves as an input for the optimization tools `eTraGo <https://github.com/openego/eTraGo>`_, `ding0 <https://github.com/openego/ding0>`_ and `eDisGo <https://github.com/openego/eDisGo>`_ and delivers, for example, data on grid topologies, demands/demand curves and generation capacities in a high spatial resolution. The outputs of egon-data are published under open-source and open-data licenses.  
+egon-data is a further development of the `Data processing <https://github.com/openego/data_processing>`_ developed in the former research project `open_eGo <https://openegoproject.wordpress.com/>`_. It aims to extend the data models as well as improve the replicability and manageability of the data preparation and processing.
+The resulting data set serves as an input for the optimization tools `eTraGo <https://github.com/openego/eTraGo>`_, `ding0 <https://github.com/openego/ding0>`_ and `eDisGo <https://github.com/openego/eDisGo>`_ and delivers, for example, data on grid topologies, demands/demand curves and generation capacities in a high spatial resolution. The outputs of egon-data are published under open-source and open-data licenses.
 
 
 Objectives of the project
 =========================
 
-Driven by the expansion of renewable generation capacity and the progressing electrification of other energy sectors, the electrical grid increasingly faces new challenges: fluctuating supply of renewable energy and simultaneously a changing demand pattern caused by sector coupling. However, the integration of non-electric sectors such as gas, heat, and e-mobility enables more flexibility options. The eGo_n project aims to investigate the effects of sector coupling on the electrical grid and the benefits of new flexibility options. This requires the creation of a spatially and temporally highly resolved database for all sectors considered. 
+Driven by the expansion of renewable generation capacity and the progressing electrification of other energy sectors, the electrical grid increasingly faces new challenges: fluctuating supply of renewable energy and simultaneously a changing demand pattern caused by sector coupling. However, the integration of non-electric sectors such as gas, heat, and e-mobility enables more flexibility options. The eGo_n project aims to investigate the effects of sector coupling on the electrical grid and the benefits of new flexibility options. This requires the creation of a spatially and temporally highly resolved database for all sectors considered.
 
 Project consortium and funding
 ==================================
 
-The following universities and research institutes were involved in the creation of eGon-data: 
+The following universities and research institutes were involved in the creation of eGon-data:
 
 * University of Applied Sciences Flensburg
 * Reiner Lemoine Institut
 * Otto von Guericke University Magdeburg
 * DLR Institute of Networked Energy Systems
-* Europa-Universität Flensburg 
+* Europa-Universität Flensburg
 
 The eGo_n project (FKZ: 03EI1002) is supported by the Federal Ministry for Economic Affairs and Climate Action (BMWK) on the basis of a decision by the German Bundestag.
 
@@ -36,9 +36,9 @@ The eGo_n project (FKZ: 03EI1002) is supported by the Federal Ministry for Econo
 eGon-data as one element of the eGo-Toolchain
 =============================================
 
-In the eGo_n project different tools were developed, which are in exchange with each other and have to serve the respective requirements on data scope, resolution, and format. The results of the data model creation have to be especially adapted to the requirements of the tools eTraGo and eDisGo for power grid optimization on different grid levels. 
+In the eGo_n project different tools were developed, which are in exchange with each other and have to serve the respective requirements on data scope, resolution, and format. The results of the data model creation have to be especially adapted to the requirements of the tools eTraGo and eDisGo for power grid optimization on different grid levels.
 A PostgreSQL database serves as an interface between the data model creation and the optimization tools.
-The figure below visualizes the interdependencies between the different tools. 
+The figure below visualizes the interdependencies between the different tools.
 
 .. image:: images/Toolchain_web_desktop.svg
   :width: 800
@@ -58,7 +58,7 @@ System boundaries and general assumptions
 
 * Sectors
 * Focus on Germany
-* Neighbouring countries (which ones and why) 
+* Neighbouring countries (which ones and why)
 * Spatial resolution / aggregartion levels
 * Temporal resolution incl. assumptions on weather year
 
@@ -67,11 +67,11 @@ The following image visualizes the different components considered in scenario `
 .. image:: images/egon-modell-szenario-egon2035.png
   :width: 800
   :alt: Components of the data models
-  
+
 Scenarios
 ---------
-  
-eGon-data aims to create different scenarios, which differ in terms of RE penetration or the availability of flexibility options. Currently, the following scenarios are available or in progress. 
+
+eGon-data aims to create different scenarios, which differ in terms of RE penetration or the availability of flexibility options. Currently, the following scenarios are available or in progress.
 
 * ``eGon2035`` Mid-termin scenario based on assumptions from the German network expansion plan 'scenario C2035', version 2021 and TYNDP
 * ``eGon2035_lowflex`` Mid-termin scenario similar to 'eGon2035', but with a limited availability of flexibility options
@@ -121,6 +121,3 @@ eGon-data aims to create different scenarios, which differ in terms of RE penetr
      - 16.1 TWh :subscript:`H2`
    * - Hydrogen transport
      - 26.5 TWh :subscript:`H2`
-
-
-

docs/conf.py

@@ -47,7 +47,7 @@ def read_authors(**kwargs):
 # on_rtd is whether we are on readthedocs.org
 # on_rtd = os.environ.get("READTHEDOCS", None) == "True"
 
-#if not on_rtd:  # only set the theme if we're building docs locally
+# if not on_rtd:  # only set the theme if we're building docs locally
 html_theme = "sphinx_rtd_theme"
 
 html_use_smartypants = True
@@ -65,5 +65,5 @@ def read_authors(**kwargs):
 
 autodoc_type_aliases = {
     "Dependencies": "egon.data.datasets.Dependencies",
-    "Tasks": "egon.data.datasets.Tasks"
+    "Tasks": "egon.data.datasets.Tasks",
 }

docs/data.rst

@@ -124,5 +124,3 @@ Heat stores
 
 Published data
 ==============
-
-

docs/data/DSM.rst

@@ -1,29 +1,29 @@
-Demand-side management (DSM) potentials are calculated in function :func:`dsm_cts_ind_processing<egon.data.datasets.DSM_cts_ind.dsm_cts_ind_processing>`. 
-Potentials relevant for the high and extra-high voltage grid are identified in the function :func:`dsm_cts_ind<egon.data.datasets.DSM_cts_ind.dsm_cts_ind>`, 
-potentials within the medium- and low-voltage grids are determined within the function :func:`dsm_cts_ind_individual<egon.data.datasets.DSM_cts_ind.dsm_cts_ind_individual>` 
-in a higher spatial resolution. All this is part of the dataset :py:class:`DsmPotential <egon.data.datasets.DsmPotential>`. 
+Demand-side management (DSM) potentials are calculated in function :func:`dsm_cts_ind_processing<egon.data.datasets.DSM_cts_ind.dsm_cts_ind_processing>`.
+Potentials relevant for the high and extra-high voltage grid are identified in the function :func:`dsm_cts_ind<egon.data.datasets.DSM_cts_ind.dsm_cts_ind>`,
+potentials within the medium- and low-voltage grids are determined within the function :func:`dsm_cts_ind_individual<egon.data.datasets.DSM_cts_ind.dsm_cts_ind_individual>`
+in a higher spatial resolution. All this is part of the dataset :py:class:`DsmPotential <egon.data.datasets.DsmPotential>`.
 The implementation is documented in detail within the following student work (in German): [EsterlDentzien]_.
 
-Loads eligible to be shifted are assumed within industrial loads and loads from Commercial, Trade and Service (CTS). 
+Loads eligible to be shifted are assumed within industrial loads and loads from Commercial, Trade and Service (CTS).
 Therefore, load time series from these sectors are used as input data (see section ref:`elec_demand-ref`).
-Shiftable shares of loads mainly derive from heating and cooling processes and selected energy-intensive 
-industrial processes (cement production, wood pulp, paper production, recycling paper). Technical and sociotechnical 
-constraints are considered using the parametrization elaborated in [Heitkoetter]_. An overview over the 
-resulting potentials for scenario ``eGon2035`` can be seen in figure :ref:`dsm_potential`. The table below summarizes the 
-aggregated potential for Germany per scenario. As the annual conventional electrical loads are assumed to be lower in the 
+Shiftable shares of loads mainly derive from heating and cooling processes and selected energy-intensive
+industrial processes (cement production, wood pulp, paper production, recycling paper). Technical and sociotechnical
+constraints are considered using the parametrization elaborated in [Heitkoetter]_. An overview over the
+resulting potentials for scenario ``eGon2035`` can be seen in figure :ref:`dsm_potential`. The table below summarizes the
+aggregated potential for Germany per scenario. As the annual conventional electrical loads are assumed to be lower in the
 scenario ``eGon100RE``, also the DSM potential decreases compared to the scenario ``eGon2035``.
 
 .. figure:: /images/DSM_potential.png
   :name: dsm_potential
-  :width: 600 
-  
+  :width: 600
+
   Aggregated DSM potential in Germany for scenario ``eGon2035``
-  
+
 .. list-table:: Aggregated DSM Potential for Germany
    :widths: 20 20 20
    :header-rows: 1
 
-   * - 
+   * -
      - CTS
      - Industry
 
@@ -35,16 +35,14 @@ scenario ``eGon100RE``, also the DSM potential decreases compared to the scenari
      - 900 MW
      - 150 MW
 
-DSM is modelled following the approach of [Kleinhans]_. DSM components are created wherever 
-respective loads are seen. Minimum and maximum shiftable power per time step depict time-dependent 
-charging and discharging power of a storage-equivalent buffers. Time-dependent capacities 
-of those buffers account for the time frame of management bounding the period within which 
+DSM is modelled following the approach of [Kleinhans]_. DSM components are created wherever
+respective loads are seen. Minimum and maximum shiftable power per time step depict time-dependent
+charging and discharging power of a storage-equivalent buffers. Time-dependent capacities
+of those buffers account for the time frame of management bounding the period within which
 the shifting can be conducted. Figure :ref:`dsm_shifted_p-example` shows the resulting potential at one exemplary bus.
 
 .. figure:: /images/shifted_dsm-example.png
   :name: dsm_shifted_p-example
-  :width: 600 
-
-  Time-dependent DSM potential at one exemplary bus
+  :width: 600
 
-
+  Time-dependent DSM potential at one exemplary bus

docs/data/batteries.rst

@@ -1,29 +1,29 @@
 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 <https://github.com/openego/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. 
+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 % 
+     - 98 %
      - [DAE_store]_
 
    * - Efficiency dispatch
      - 98 %
      - [DAE_store]_
-     
+
    * - Standing loss
      - 0 %
      - [DAE_store]_
-     
+
    * - Investment costs
      - 838 €/kW
      - [DAE_store]_
@@ -33,5 +33,5 @@ Potential large-scale batteries are included in the data model at every substati
      - [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. 
+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 <egon.data.datasets.storages_etrago.StorageEtrago>`, the data for batteries in the transmission grid is stored in the database table :py:class:`grid.egon_etrago_storage <egon.data.datasets.etrago_setup.EgonPfHvStorage>`.

docs/data/electricity_grids.rst

@@ -3,30 +3,30 @@
 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 (OSM) (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, 
+The model of the German extra-high (eHV) and high voltage (HV) grid is based
+on data retrieved from OpenStreetMap (OSM) (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 <https://github.com/openego/osmTGmod>`_ was used. The corresponding dataset 
-:py:class:`Osmtgmod <egon.data.datasets.osmtgmod.Osmtgmod>` executes osmTGmod 
+tool <https://github.com/openego/osmTGmod>`_ was used. The corresponding dataset
+:py:class:`Osmtgmod <egon.data.datasets.osmtgmod.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 the different grid levels. Information about
 border crossing lines are as well extracted from *OSM* data by *osmTGmod*.
 For further information on the generation of the grid topology please refer to [Mueller2018]_.
-The neighbouring countries are included in the model in a significantly lower 
-spatial resolution with one or two nodes per country. The border crossing lines 
+The neighbouring countries are included in the model in a significantly lower
+spatial resolution with one or two nodes per country. The border crossing lines
 extracted by *osmTGmod* are extended to representative nodes of the respective
-country in dataset 
-:py:class:`ElectricalNeighbours <egon.data.datasets.ElectricalNeighbours>`. The 
+country in dataset
+:py:class:`ElectricalNeighbours <egon.data.datasets.ElectricalNeighbours>`. The
 resulting grid topology is shown in the following figure.
 
 .. figure:: /images/grid_topology_ehv_hv.png
   :name: gridtopology_ehv_hv
   :width: 400
-  
+
 
 
 .. _ding0-grids:

docs/data/electricity_supply.rst

@@ -239,4 +239,4 @@ an upper limit of 1 MW.
 
 The implementation of fuel cells in the data model is detailed in the
 :py:mod:`power_to_h2 <egon.data.datasets.hydrogen_etrago.power_to_h2>`
-page of our documentation.
+page of our documentation.