ETraGoSpecs (eTraGo-eDisGo-Interface)

[maltesc]

In addition to #2, the interface function get_etragospecs is implemented in:
eGo/ego/tools/specs.py (see: specs.py)

However, I need help with extending the function and verifying a few parameters (I don't necessarily need the exact answer - also a hint to the corresponding code section might help)

1. Information is needed on how to merge Ding0 grids with eTraGo buses. Is there a table that associates Ding0 grid IDs with transmission grid bus IDs?

2. What exactly is the column e_annual in table model_draft.ego_grid_pf_hv_result_load? What is the unit?

3. Is there a definition of 'extendable storage'? In my point of view this is the extendable short term storage (batteries) and thus there should be only one per TG bus. However, e.g. at bus 27334 there are 6. For eDisGo the installed capacities and active power series of the batteries are of particular interest.

4. eDisGo needs the Curtailment for wind and solar. In the eTraGo results I find the installed capacity and the corresponding dispatch. Where can I find the hourly potential in order to calculate the curtailment?

5. Zählpfeilsystem in eTraGo results in my point of view: storage charged = negative P and discharged = positive P. Is this correct (I have only seen dummy results yet)?

[gplssm]

Today I'll review implementation by @maltesc and report back here.

I cannot answer the above question. Could you @ulfmueller @IlkaCu @wolfbunke @mariusves or @BartelsJ help out here?

[ulfmueller]

1. @IlkaCu knows better how the grid district ids evolve in the hv-mv bus ids of the powerflow data. @gplssm and @nesnoj should know where ding0 gets the grid districts ids. But it should be consistent :)

2. e_annual is the overall load per bus per year. It is not used by eTraGo. More details from @IlkaCu

3. extendable storages could be also for longterm storage. If a bus has a potential for both. Two storage units should be possible. 6 seems awkward. @lukasoldi knows about this stuff in detail.

4. the p_max_pu * p_nom defines the potential for each snapshot and power plant

5. eTraGo uses the pypsa convention on the "Zählpfeilsystem" ;), which is a Generator-Zählpfeilsystem. So yes, generation is positive and load is negative.

[gplssm]

1. Indeed, we know where we take this information from: the column "subst_id" from grid.ego_dp_mv_griddistrict. But this wasn't actually the question. The question is: how to join this subst_id (ranging from 1..3608) with the bus_id (by far higher range) for example found in "model_draft.ego_grid_pf_hv_result_bus".

[ulfmueller]

I think I understood the question. I would say what you explained is one side of the medal. The other side can be answered by @IlkaCu . She knows in which table(s) the subst_id gets translated to 'our' final id.

[ulfmueller]

it has to do with the data which comes from osmTGmod, which has 'otg_ids'. But I think it is easier if @IlkaCu explains this.

[IlkaCu]

Table model_draft.ego_grid_hvmv_substation contains the otg_id (which is the id from osmTGmod) as well as the subst_id. We use this table in the DP to link both IDs.

[lukasoldi]

extendable storages could be also for longterm storage. If a bus has a potential for both. Two storage units should be possible. 6 seems awkward. @lukasoldi knows about this stuff in detail.

that is correct. 6 seems not correct. Are you sure this is for one scenario? Could you share the 6 items so we can check for doubling?

[maltesc]

Thank you for the numerous and informative feedback.

@lukas and @ulfmueller The mentioned case occurred in the current model_draft results version (result ID = 1, no clustering). Not sure if this is for one scenario, however, the result_id is supposed to be unique. There are many similar cases among the table, however here is the example:

table: model_draft.ego_grid_pf_hv_result_storage

At bus 27334, there are 6 extendable storages:
Storage IDs: 50886, 10967, 40990, 39318, 1071, 29422