Overlying-grid requirements

In plain terms

A distribution grid does not exist in isolation: it hangs off the high-voltage (transmission) grid above it. When the whole system is planned together — for example eDisGo coupled with eTraGo via eGo — the upper grid level may require the distribution grid to dispatch its flexibilities in a certain way (e.g. a given curtailment, a storage or DSM profile). eDisGo stores these requirements and can pass them to the optimisation as additional constraints.

Data

The OverlyingGrid container (edisgo.overlying_grid) holds the requirements handed down from the overlying grid, such as:

• renewables_curtailment — required curtailment of renewable feed-in,

• storage_units_active_power / storage_units_soc — required aggregate storage-unit dispatch and state of charge,

• dsm_active_power — required DSM utilisation,

• electromobility_active_power — required aggregate EV charging,

• heat_pump_decentral_active_power / thermal_storage_units_decentral_soc — required decentral heat-pump operation,

• heat_pump_central_active_power / thermal_storage_units_central_soc / feedin_district_heating — the corresponding central power-to-heat / district-heating requirements.

The helper distribute_overlying_grid_requirements() returns a new EDisGo object in which these aggregate requirements are distributed onto the individual components, with a distribution key that differs per flexibility (EV by flexibility-band power, storage by installed capacity p_nom, power-to-heat by p_set, DSM by its potential bands, and curtailment proportional to current feed-in).

Use in the optimisation

The high-voltage requirements are honoured by the OPF versions that add HV constraints — opf_version 3 and 4 of pm_optimize() (see Multi-period optimal power flow). This keeps the local, distribution-level flexibility schedule consistent with what the transmission-level planning expects, so the two levels can be optimised coherently.