Medium-voltage grid statistics

[gplssm]

Current structure for statistical analysis of grid data created with dingo and its methods are explained in the docs. The examples give an idea how to use it. Based on the existing code the statistics for MV grids are extended first.

Extend calculate_mvgd_stats() (and maybe also nd.to_dataframe() such that folllowing items are contained

• Cable/ line lengths
  • Length of longest path in MV and LV (see code of Mohamed from line 68)
  • Kilometers and percentage of each cable/line type
  • Length of rings (main branch) and length of branching stubs
  • Number of outgoing lines (rings)
  • Min/max/mean length of rings
• Substation/ Transformers
  • Number of HV-MV transformers
  • Cumulative capacity of HV-MV transformers
  • Number of LV stations
  • Cumulative nominal power of LV stations
• Load and generation
  • Load and generation density: not calculated but district's area is included as a field.
  • Nominal capacity of each generation technology
  • Nominal cumulative generation capacity and peak load in MV and LV level
  • Cumulative generation capacity per voltage level [4..7]
  • Cumulative generation capacity per connection type (only MV): (a) connected to ring, (b) connected to branch
  • Generation capacity directly connected at bus bar of (a) HV-MV substation and (b) MV-LV substation
  • Number of load areas (LA) per type
    1. Normal LA
    2. Aggregated LA
    3. Satellite LA
  • Cumulative load within aggregated load areas (these are LV loads)
  • Cumulative generation capacity within aggregated load areas (MV and LV level)
  • Peak load of each sector (retail, residential, industrial, agricultural)
• Regions and spatiality
  • Number of LV grid districts
  • Number of LA
  • Peak load and population in aggregated LAs
  • Number of satellite LA groups (@nesnoj knows the details)
• Grid issues
  • Max. and average voltage deviation
  • Max. and average line overloading
• Add description of each figure that is returned by calculate_mvgd_stats() in the docs

[gplssm]

Following types and subtypes of generation technologies are available in Dingo

Type	Subtype
biomass	biofuel
biomass	biogas
biomass	waste_wood
biomass	biogas_from_grid
biomass	biomass
biomass	biogas_dry_fermentation
biomass	wood
gas	gas
gas	gas_sewage
gas	gas_landfill
gas	gas_mine
geothermal	geothermal
run_of_river	hydro
solar	solar_roof_mounted
solar
solar	solar_ground_mounted
wind	wind_onshore
wind	wind_offshore

Please consider as well the case that a subtype is undefined (see solar)

[miguelparadacontzen]

I have some questions for @gplssm or @nesnoj :

1. N°of MV/LV trafos < LV Districts = N° LV Stations. Is that possible?

2. N°of circuit breakers \neq N°of Rings. Is that possible?

3. N°of Load Areas \neq N°of LV Stations. Is that possible?

4. In the grids I have tested, it seems that, N°of branches in MVdistrict.mv_grid = N°of branches in all rings. ie. all branches are associated to a ring. However, there are satellite LA. is that OK? shouldn't they not be associated to aring?

5. the attribute branch['branch'].ring tells me the ring where the branch is connected or the ring of which the branch is part of?
   eg.

station
|
|
cable_distr ------- node 1 ------ close ring BACK to station
|
|
node 2

the vertical branch from cable_distr to node2, is not part of the ring but its connected to it. what does the .ring attribute says?

[gplssm]

Answers to questions above

1. Yep, is possible. A MV-LV substation in an aggr. LA has no transformer.
   EDIT: Here is where it happens.
2. Should not! Already tacked in Number of rings does not match number of circuit breakers #218
   EDIT: Yes it is. See answer in Number of rings does not match number of circuit breakers #218
3. Yes. A LA contains one or more LV grid districts
4. You are right! If there are satellite LAs those should be connected via branching lines. One exception exists: if the satellite LA is within 100m distant from the ring, than the ring line is slightly moved in order to include the satellite LA (applies the same for generators). @nesnoj could you please extend or edit my answer?
   EDIT: I admit that the attribute's name "ring" seems to indicate that only branches IN the ring refer to the ring object (inconsistently, this is how we refer to the term "ring" in our docstrings). However, the ring object is needed for (internal) operations on satellites too, this is why it was introduced. Hence, it's not a good idea to use it outside the core of dingo.. Sorry for the confusion!
5. @nesnoj ?
   EDIT: As described in 4., it returns the ring where the branch is connected to (or the ring the branch is part of, if the branch lies within the ring).
   In your example, it returns the obj of the ring station ----- cable_distr ----- node 1 ----- ....
   To make it clearer: A branch connecting node 2 and another node 3 would point to the same ring. Hope that helps...

[nesnoj]

Sorry for late reply, see edited answer above.

[miguelparadacontzen]

I edited the function calculate_mvgd_stats to fix the issues with the rings by creating the method rings_full_data() See here.

it calculates the "true rings" (the cycles in a graph) as the method rings_nodes() does, and the (half-)rings from MV stations to aggregated LAs. For each ring it yields the ring object, a list of edges and a list of nodes.

It only works if the network, nw, created by dingo was already "initialized" by applying the line nw.control_circuit_breakers(mode='close'). I don't know why is that... It seems that if this command was not used over a network, then the circuit breakers do not have the attribute that says if they are open or close. or maybe it is empty. does that make sense?

[miguelparadacontzen]

function is implemented here.

[nesnoj]

The CB's attribute state stores if it's open or closed but something else happens here: when opening a CB, the lines from the CB to the 2 adjacent nodes are deleted. When closing, they're inserted again. Hence, to get the full topology, CBs must be closed.

This implementation is quite odd and a better solution was to just use the attribute when doing something with the graph! Since it affects many places in the code, I'd prefer to leave it as it is, even if the solution is not very intuitive, though. We gonna implement this in a better way in eDisGo (cf. openego/eDisGo#23).

On rings_full_data(): Thanks for your effort! But I prefer not to count the lines of agg. LAs as rings, although they are treated as rings internally. Beside the ring count which represents the number of "real" rings, I rather like to have information on how many agg. LAs are inside the MVGD.

[miguelparadacontzen]

OK, I can comment out that part of the code so only "true" rings are treated as rings. The Number of agg LAs is already calculated in the stats.

[nesnoj]

Cheers!