Provide power_class to Fluctuating Generators

[boltbeard]

From model_draft.ego_renewable_feedin the time series for wind_onshore has been divided into 7 power classes and a time series for each power class is created. This is assigned to every generator with every wind_onshore entry in model_draft.ego_supply_pf_generator_single being one from 1-7 and the rest of the technologies having a power_class of 0. More info about this on openego/data_processing#231

This means along with solving issue #254 the power_class also has to be included in GeneratorFluctuating Objects to make sure the correct time series is assigned to them.

Currently in the absence of the power_class, all wind_onshore are assigned a feedin time series corresponding to the power_class 4 until one is available

[boltbeard]

Information needed and Decisions to make

1. How are power classes dealt with in eTraGo? It would be good to handle them similarly in eDisGo for consistency.
2. Is there a generalization if the power_class attribute is absent in the generator?
3. How wrong/right would any analysis be by assuming a power_class of 4 for all wind generators as handled in eDisGo (issue #121)?

Tasks if power_class needs to be introduced

• The materialized views need to include power_class of every renewable generator in

  • model_draft.ego_supply_res_powerplant_sq_mview
  • model_draft.ego_supply_res_powerplant_nep2035_mview
  • model_draft.ego_supply_res_powerplant_ego100_mview
  • supply.ego_dp_supply_res_powerplant_sq_mview
  • supply.ego_dp_supply_res_powerplant_nep2035_mview
  • supply.ego_dp_supply_res_powerplant_ego100_mview
    @IlkaCu, @wolfbunke, @ulfmueller Could you please tell me how much effort would this take?

• A power_class attribute needs to be included in the GeneratorFluctuatingDing0 Class

• Document the availability of this attribute

[wolfbunke]

Hey @boltbeard, sorry I lost the issue almost due to filtering. I will have a look how we can add the power_classto the mviews now.

[boltbeard]

Hi @wolfbunke, Before looking too deeply into the issue, I'm really interested in the answer to:

1. How are power classes dealt with in eTraGo? It would be good to handle them similarly in eDisGo for consistency.

Once I have some knowledge about this, it may be easier to see its criticality

The rest of the question are already to an extent answered by @MarlonSchlemminger in openego/eDisGo#121

[wolfbunke]

I see two option to map the power_class to the mViews.

1. Adding the column to the Mview by a join with tablemodel_draft.ego_renewable_feedin

SELECT a.power_class, b.*
    FROM model_draft.ego_renewable_feedin a INNER JOIN (SELECT * FROM model_draft.ego_dp_supply_res_powerplant b WHERE b.scenario::text = 'Status Quo'::text 
	AND b.electrical_capacity > 0::numeric 
	AND b.preversion = 'v0.3.0'::text ) b ON (a.w_id = b.w_id) 

2. Using model_draft.ego_supply_aggr_weather and adding power_class into the query
   see here: https://github.com/openego/data_processing/blob/dev/dataprocessing/sql_snippets/ego_dp_powerflow_assignment_generator.sql#L416-L433 and using it.

At the moment I was trying to run 1.) but I got few problems.

[wolfbunke]

1. How are power classes dealt with in eTraGo? It would be good to handle them similarly in eDisGo for consistency.

All calculation are done in the Dataprocessing and eTraGo is getting only the prepared time series. See here: https://github.com/openego/data_processing/blob/d0c2da7464e02af63edcab627dad934f757038c3/dataprocessing/sql_snippets/ego_dp_powerflow_timeseries_generator.sql#L179-L206

[boltbeard]

An update to this issue has been discussed, the minutes are documented in eDisGo issue #121, and its current state is summarized below:

After having a closer look at the power_class implementations in eTraGo and its working within eGo in combination with eDisGo, the following conclusions were made:

1. The major use case of eDisGo is to be used in conjunction with eTraGo as part of the entire eGo tool suite, where active power timeseries in eTraGo would be calculated by considering the power classes in the aggregated generators, and provide an averaged time series curve per technology per weather cell to eDisGo for each technology for each weather cell. (This is the current state of the implementation)

2. The current state of the implementation does induce inacurracies due to the averaging of all the time series of all the generators at an mv grid. It is currently assumed that this induced inaccuracy is acceptable until quantifiable evidence proves it to be otherwise. Although this has not been quantified yet, there are methods that this can be done

Further information can be obtained by the issue directly

[mltja]

Obsolete with new data.