import and connect generators

[nesnoj]

Implement import of generator, weather and timeseries datasets.
Tasks:

• Genos
  • Import
    Don't forget to remove version-workaround in model draft import
    (Move pre-data_processing of RES and Conv Power plants to DP? data_processing#180) (including col preversion) !
  • Handle genos without geoms
  • Use new structure of agg. genos Distinguish aggr. generation by type not by subtype #51
    • Add la_id to geno id, solution see Distinguish aggr. generation by type not by subtype #51 (comment)
  • Disconnect decommisioned
    (to be solved first: decommissioning of conv. PP data_processing#178 and changing ids of conv generators in different scenarios data_processing#175)
  • Change repowered
    • CAUTION: The voltage level of some existing genos may change due to changes in capacities! If so, disconnect old geno and create new one with updated voltage level! (see RES and CONV PP related issues (dp v0.3) data_processing#181 (comment))
  • Connect new (with standard equipment)
    • MV
    • LV
    • LV: random relocation as in dingo if geom or LVGD id is missing
    • Store costs (cf. Calculate grid expansion costs #45 (comment))
    • ~[ ] Solve problem with changing IDs of conv. PP - dis- and reconnect! grid expansion costs for conv. PP #59 ~
  • Modeling of dispatchable generators Define generator modeling #16
  • Validation (several MVGDs)
    • Include conv. genos (commented out due to dp bug Move pre-data_processing of RES and Conv Power plants to DP? data_processing#180).
  • Use version filter (remove temp. model draft solution)
  • Remove genos used for testing
  • [ ] make functions more generic (for use with data from pyPSA), esp. _update_grids
• [ ] Weather data
  • [ ] Import
  • [ ] ...
• Timeseries (see Timeseries for generators #5)
  • Import
  • ...
• Link genos, weather data, timeseries
• [ ] Log what happened

[nesnoj]

New geno mviews are considered in dingo by now, see openego/ding0#225.

[nesnoj]

Note: conv. genos are disregarded now, due to a bug in conv pp tables, see openego/data_processing#175

[nesnoj]

Notes:

• new LV genos which are member of former agg. LA are added as 1 new agg. geno (unline the dingo importer, there're no type- or subtype-specific agg. genos)

[gplssm]

When there is one aggr. Generation, neglecting its type, I don't know how to assign the according time series... Any suggestions for this?

[nesnoj]

Ok I will change this..

[nesnoj]

A question concerning cable selection procedure @birgits @gplssm :

To connect new genos I have to choose a cable type for line. Approach: Use the smallest possible cable available which is able to carry the max. apparent power (taking the load factor into account). If the power exceeds the max. available value, use the quantity attribute (same procedure here -> quantity * rated_power * load_factor > apparent power). Right?

In your parts, you have to select cables too - is there a generic function to do this? If not, I'll move mine to e.g. tools...

[birgits]

For grid expansion there are only two possibilities. Either a parallel cable of the same kind is installed or if this isn't sufficient as many parallel standard cables as needed are installed. So to answer your question there is no function that chooses the smallest possible cable yet, but you did the same in dingo, right? Your equation is correct, though for lines we use current instead of power. Otherwise you'd have to know the line voltage to calculate S.

[nesnoj]

Your equation is correct, though for lines we use current instead of power. Otherwise you'd have to know the line voltage to calculate S.

Thanks for the hint!
The problem is: I do not have either (except the rated values), since I connect the genos prior to PF.
But I only need approximate values during the connection to select an sufficient cable. Sure, in the borderline case (decision on cable 1 or 2?) it may happen that I'd select a cable which is either somewhat too small or oversized, but I would not bother too much here (I've no idea how to obtain exact values here except doing an extra PF which is definitely no option..).

EDIT: Solved, new method. Cf. #45 (comment)

[birgits]

@nesnoj should we keep this issue open as a reminder what's left to do here or are just conventional generators missing, in which case I would just make a new issue out of it? Is the ToDo list at the top up to date?

[nesnoj]

Is this one still current?
The to-do-list should be up to date from my end, but maybe some parts were fixed meanwhile (not by me).
If we wait a couple of months, most parts will get obsolete as the MaStR could be used.

[birgits]

It is still relevant, mostly because conventional generators are not yet imported.
Time series from oedb can be assigned, so I crossed that off the list. Weather data is not yet imported but might be helpful, wherefore we can leave it as a possible ToDo.
About the operation strategy for conventional generators - in #16 we decided to not implement an operation strategy for conventional generators in edisgo, as it is implemented in etrago and time series for conventional generators will be handed over to edisgo. However, when edisgo is used stand-alone, it might be useful to provide something to have reasonable time series for dispatchable generators. @gplssm what do you think, should we leave this issue on the list?
I am not sure what's meant by "Remove genos used for testing". @nesnoj?

[gplssm]

If we wait a couple of months, most parts will get obsolete as the MaStR could be used.

Exactly my favorite kind of humor 😁
But, maybe, data quality of MaStR isn't too bad

About the operation strategy for conventional generators - in #16 we decided to not implement an operation strategy for conventional generators in edisgo, as it is implemented in etrago and time series for conventional generators will be handed over to edisgo. However, when edisgo is used stand-alone, it might be useful to provide something to have reasonable time series for dispatchable generators.

The feature of determining dispatch of flexible power plants is planned to be included when OPF is implemented in eDisGo. But, we can remove it from the list respectively mark it as resolved as we have the option to provide data that determines the dispatch.

CAUTION: The voltage level of some existing genos may change due to changes in capacities! If so, disconnect old geno and create new one with updated voltage level! (see openego/data_processing#181 (comment))

This seems to me still important. I would propose to create a new issue for that.

Solve problem with changing IDs of conv. PP - dis- and reconnect! #59

Important. Still open. Issue exits. I deleted it.

Some of the tasks that are described above in the issue's description, I didn't understand. @nesnoj are this task still relevant and open?

• Remove genos used for testing
• Link genos, weather data, timeseries

I suggest to create new issues.

@birgits said that some flexible power plant technologies (i.e. biomass, CHP,...) aren't imported at the moment. If this is true, let's created an issue.

Info: Some other points were removed due to risk of pending forever.

[birgits]

@birgits said that some flexible power plant technologies (i.e. biomass, CHP,...) aren't imported at the moment. If this is true, let's created an issue.

I am not totally sure as I don't fully understand what is done but in those lines a filter for renewable generators is set so that only solar and wind generators are retrieved and the import of conventional generators is commented. The reason why this is done is not mentioned. I guess the problem with conventional generators could be the changing IDs that are addressed in issue #59. But I can't think of a reason why e.g. biomass powerplants can't be imported.

[birgits]

Filters are now removed and all types of generators imported. The issue can now be closed.