Adjust eDisGo to new Specs

[maltesc]

I just finished the new version of the Specs function (see https://github.com/openego/eGo/blob/features/specs/ego/tools/specs.py). I tried to stay as close as possible to the old version. However, since some things have changed, the eDisGo class "ETraGoSpecs" needs to be adjusted. The new class description should look something like this (see explanation below):

"""Defines an eTraGo object used in project open_eGo

Contains specifications which are to be fulfilled at transition point
(superiorHV-MV substation) for a specific scenario.

Attributes
----------

_battery_capacity: :obj:`float`
    Capacity of virtual battery at Transition Point
_battery_active_power : :pandas:`pandas.Series<series>`
    Time series of active power the (virtual) battery (at Transition Point)
    is charged (negative) or discharged (positive) with
_conv_dispatch : :pandas:`pandas.DataFrame<dataframe>`
    Time series of active power for each (aggregated) type of flexible 
generators normalized with corresponding capacity. 
    Columns represent generator type:
     * 'gas'
     * 'coal'
     * 'biomass'
     * ...
_renewables : :pandas:`pandas.DataFrame<dataframe>`
Dataframe of fluctuating renewables ('wind','solar'), aggregated 
by weather ID (w_id). 
Columns specify each aggregate:
 * 'name' (e.g. 'solar')
 * 'w_id'
 * 'ren_id' (ID used to allocate the aggregates to their time series)

_ren_dispatch : :pandas:`pandas.DataFrame<dataframe>`
Time series of active power of wind and solar aggregates, 
normalized with corresponding capacity. 
    Columns represent ren_id (see _renewables):
     * '0'
 * '1'
 * ...
_curtailment : :pandas:`pandas.DataFrame<dataframe>`
    Time series of curtailed power for wind and solar aggregates,
    normalized with corresponding capacity.
    Columns represent ren_id (see _renewables):
     * '0'
 * '1'
 * ...	
"""

Explanation:

We unfortunately had to drop a few attributes. Since generators in eTraGo are aggregated by size, but not by voltage level, it would be necessary to query every single generator from the DP in order to identify those that are connected to the HV side. Since this query is pretty time consuming, it is not recommendable to desaggregate generators. For this reason, no absolute values (but only normalized values) are calculated for the MV side of the TG bus transformer. Therefore, the former attributes "_active_power", "_reactive_power" and "_capacity", have been excluded from the Specs.

Furthermore, since load is aggregated by eTraGo and can alternatively be queried directly from the DP, load and annual load have also been excluded from the Specs.

The attribute _dispatch contains the normalized dispatch of all flexible generators. This behavior is similar to before. However, flexible renewables (solar and wind) have been excluded from this attribute.

Since wind and solar are not only aggregated by size, but also by weather ID (where the weather ID is comparable simple to query), we decided to not waste this information at the interface level. The attribute _renewables now contains all aggregates (unique by name (e.g. 'solar') and w_id) with their corresponding ren_id to allocate them to the dispatch dataframes. _ren_dispatch and _curtailment contain the normalized time series, while the columns represent the ren_id from the _renewables attribute.

In case this new solution is difficult to implement in eDisGo, it would easy to switch back to the old version, where also wind and solar are completely aggregated by type. Furthermore, runtime of the now included weather ID might be an issue. While the old function processed all data in milliseconds, only the query of a few weather ID's takes around 5 seconds. Since this is done for almost every TG bus, this might extend the total runtime considerably.

We had considered to keep all storage types at interface level. However, it can be assumed that no storage facilities but extendable storages are connected to the MV. For this reason (as in the old version) only extendable storages are included. However, the code for including all storage types has been implemented and can easily be recovered.

As an example, use:

from ego.tools.specs import get_etragospecs_from_db
    
from oemof import db
conn = db.connection(section='oedb')
Session = sessionmaker(bind=conn)
session = Session() 

bus_id = 23971 # One random, interesting bus.
result_id = 9 # model_draft scenario with 2 hours of minimal residual load
scn_name = 'NEP 2035' 

specs = get_etragospecs_from_db(session, 
				bus_id, 
				result_id, 
				scn_name)

[gplssm]

Thx a lot for the detailed issue description. @birgits will take care about as soon as possible.

[birgits]

See also: openego/eGo#11

[gplssm]

In openego/eGo#11 (comment) we agreed on not having any check-ups in the eTraGo-eDisGo interface

[birgits]

Thank you very much @maltesc for your input! I am implementing the needed changes at the moment and have a small question concerning the renewables dataframe - will the weather ID be a string or an integer?

[maltesc]

The weather ID is an integer and comes from the model_draft table 'EgoSupplyPfGeneratorSingle'. The datatype in the specs is the same as in this table.

However, this is easy to change and we can easily adjust the datatype in the specs in case you need it differently.

[birgits]

Thank you @maltesc. The interface is almost done. I have another small question though just to be sure - are the ren_dispatch timeseries the possible feed-in minus the curtailment or do we need to subtract the curtailment?

[maltesc]

@birgits:
ren_dispatch is the effective dispatch, optimized by eTraGo.
The potential (possible dispatch) takes part of the internal calculation, however, it is not an interface attribute.
In other words: You don't need to subtract the curtailment from ren_dispatch

[birgits]

The specs are implemented now. I didn't merge yet and would like to wait for your feedback @wolfbunke @maltesc. You'll find the changes on the branch features/#90-etrago-specs. You can use the provided example in eDisGo/edisgo/examples/ to run edisgo with etrago specs. Make sure to provide the correct scenario name (in line 24) and MV grid IDs (in line 19 in list 'grids', grid IDs must be integer) for the specs you want to run edisgo with.
At the project meeting we will further discuss if the example will be part of ego or implemented as an edisgo run in edisgo itself. This will probably also decide if scenario name and MV grid ID will be part of the etrago specs or provided separately.

[birgits]

@wolfbunke reported that it works for him so I'll close this issue.