You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/readthedocs/dev/concept.md
+51-17Lines changed: 51 additions & 17 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,9 +3,27 @@
3
3
... of OSMoGrid and it's implementation.
4
4
Here, we want to focus on the overall structure of the tool and which part does serve which purpose.
5
5
6
+
The computational heaviest part is connecting households / loads to the street graph as well as clustering the loads based on the distances following the street graph.
7
+
This is why we want to shift those parts to the smallest regions possible.
8
+
To achieve this, a given region of interest is partitioned heuristically as much as possible.
9
+
The concept is as follows:
10
+
11
+

12
+
13
+
The region of interest is broken down according to the administrative boundaries until the level of municipality boundaries is reached.
14
+
Moreover, these municipal boundaries are further broken down to districts.
15
+
They are defined as local dense groups of houses, that do form disjoint groups.
16
+
However, if those dense groups are very big, computational complexity still can be too big.
17
+
So, if need be, the districts are further broken down into smaller sub-districts.
18
+
Based on those (sub-)districts, cluster of loads are build, that later form the regions of secondary substations.
19
+
Those clusters respect the distance between them according to the street graph, they are connected to.
20
+
Lastly, the street graph is converted into a grid model.
21
+
22
+
Following this concept, the following actor hierarchy is implemented:
23
+
6
24
## Actors
7
25
### OsmoGridGuardian
8
-
- Coordination of voltage level spanning routine
26
+
- Coordination of multi voltage level spanning routine
9
27
- Error handling
10
28
- Collection of lv grids received from `LvCoordinator` and assigning subnet numbers
11
29
@@ -18,26 +36,42 @@ Here, we want to focus on the overall structure of the tool and which part does
18
36
19
37
### LvCoordinator
20
38
- Coordinates the generation of the whole low voltage level
21
-
- Partitions the OSM data by municipal boundaries
22
-
- Settlements only rarely cross municipality boundaries
23
-
- The concept of concessional agreements on serving a municipality incentive to not let grids cross boundaries
24
-
- Spawns a pool of `LvGridGenerator`s
25
-
- Spawns a pool of `LvRegionCoordinator`s (needs to know the `LvGridGenerator` worker pool)
26
-
- Hand over regions (here: municipalities) to `LvRegionCoordinator`s
27
-
- Collect results from `LvRegionCoordinator`s and check completeness
39
+
- Determines the highest available administrative boundary within the region of interest
40
+
- Spawns an `LvRegionCoordinator` to split up the region of interest according to this administrative level
41
+
- Collects results and checks completeness
42
+
-*Outcome*: Complete region of interest + the highest available administrative boundary
28
43
29
44
### LvRegionCoordinator
30
-
- Responsible for generation of lv grids within a defined region (might be a municipality)
31
-
- Generate loads in that region
32
-
- Cluster them to secondary-substation regions
33
-
- Build sub-graphs according to secondary-substation regions and hands them over to `LvGridGenerator`s
34
-
- Collect results from `LvGridGenerator`s, check completeness and forward them to `LvCoordinator`
45
+
- Splits up the region of interest according to a given administrative boundary
46
+
- If the level of a municipality is **NOT** reached:
47
+
- Spawns new `LvRegionCoordinator`s per new subregion to split up for the next lower administrative boundary
48
+
-*Outcome*: Subregions on administrative level `n` + the next lowest administrative level `n-1`
49
+
- If the level of a municipality is reached:
50
+
- Hand over the "municipalities" to `MunicipalityCoordinator`s
51
+
-*Outcome*: Subregions on administrative level "municipality"
52
+
53
+
### MunicipalityCoordinator
54
+
- Coordinates the region partitioning within the administrative boundary of a municipality
55
+
- Determines dense and disjoint groups of houses as local "districts"
56
+
-*Outcome*: Districts within the given municipality
57
+
58
+
### DistrictCoordinator
59
+
- Breaks down districts even further, if still too big w.r.t. computational measures (to be defined)
60
+
-*Outcome*: (Sub)districts with suitable size
61
+
62
+
### SubDistrictCoordinator
63
+
- Responsible for handling a sub-district
64
+
- A sub-district can also be a district, if that isn't too big
65
+
- Derives loads from houses
66
+
- Connects loads to street graph
67
+
- Clusters loads while respecting the distance on the street graph
68
+
- Those clusters are the regions of secondary substations
69
+
- Hands over the graph to `GridGenerator`s
70
+
-*Outcome*: Street subgraphs per secondary substation region
35
71
36
72
### LvGridGenerator
37
-
- Generates a distinct, galvanically closed lv sub grid model
38
-
- Building the distance matrix
39
-
- Determining perpendiculars and connect loads to the street graph
40
-
- Transform into electrical grid model
73
+
- Generates a distinct, galvanically closed lv sub grid model from street graph
74
+
-*Outcome*: Grid model per secondary substation region
0 commit comments