How to specify zones / geographic granularity

[m-mirz]

• could be geographical points describing a zone

[grgmiller]

There are multiple levels of geographic granularity that could be considered:

1. Interconnection - a group of balancing regions that are physically interconnected and can exchange electricity with each other
2. Balancing authority (in US) / country (in Europe) - generally defined by a region for which there is a single operator that is responsible for balancing supply and demand
3. Transmission congested zones within each BA
4. Transmission-level nodes (generally corresponding to LMP nodes in a wholesale market)
5. Distribution-level nodes (generally corresponding to distribution-level substation/feeder)

One question is how this data should be made available. Several options:

1. Mapping table that identifies the relationship between each of the 5 levels of geographies identified above. Ideally, if you start with the most granular (5) and work your way up to 1 (interconnect), each of the more granular geographies should map to a single larger geography.
2. GIS files (e.g. shapefiles). One challenge of GIS data is that some of these regions overlap with each other, so sometimes it is not possible to map each generator to a specific region based on its location alone

Part of how this data is provided might depend on what type of emissions/generation data we are starting with. If we're starting with emissions data that is provided already aggregated at a regional level, or whether we are starting with data for individual generators or demand nodes.

[grgmiller]

Each level of geographic granularity that we include might also depend on whether or not we can also find data that identifies the edges/connections between each level. For example, at the balancing authority level, we would need to be able to identify all of the BA-to-BA interties between each region, whereas for distribution-level nodes, we might need to have a map of the distribution network itself. (If you think about this problem in terms of a network graph, each region would be a "node" but we would also need data about each "edge").

The type of information that we might want about each edge is not only whether they exist, but things like the volume of interchange / line ratings, etc. This discussion might be better suited for an issue about interchange / consumption-based emissions data.

Not sure if this is related to #14 ?

[gwpicard]

Some good points!

Our model should allow for the abstraction of all common elements to every level of spatial granularity. We ideally should not add any new "properties" when increasing spatial granularity (or vice-versa).

Perhaps, the best abstraction for all levels could just some kind of network graph where node = spatial level of granularity, and edge = connection between spatial levels. Then we work within this constraint to allow for the description of data regardless of the level.

Does that make sense?

I see #14 as specifying the "edge" parts of the graph in the data model.

---

I'm also wondering about how we distinguish between consuming nodes and producing nodes?

The substation / feeder level would typically be for step-down to end users, correct? How would we fit going from individual power unit --> aggregated production?

[grgmiller]

Notes/thoughts from conversation on this topic at 4/28/2022

Ideally, we would be getting data at the unit level, which could be then agggregated up to whichever level we need. For each unit, we would want a static table that maps each unit to each level of geographic granularity (node, zone, BA, interconnect, etc).

However, the raw data might not always be available at the unit level, but we still would want to be able to map the data up and down the different levels of geographic granularity. For example, say an ISO is only able to provide the data at the zone level (e..g. "MISO South"). We would still want them to provide a static mapping table that identifies all of the nodes that are located in that region, and then all of the units that are located at each node.

I think having consistent mapping of where all the units are located (within the power network topology, rather than just their lat/long or location within geopolitical boundaries) will be the most helpful.

[grgmiller]

Other questions from the call:

• Do we want a geojson or shapefile of each zone so that we can more easily map demand (for example)
  • Thoughts: if we have both demand and generation nodes specified, and we have a network graph / topology of how all these nodes are connected, we might not need to have maps of the boundaries

[grgmiller]

We might be able to utilize existing specifications from IEC 61970 Common Information Model (https://www.epri.com/research/products/000000003002021840)

Related to #24

Without having seen CIM before, I was envisioning that for each of the five spatial granularity levels introduced above, each level would contain "nodes" and edges that describe the connection between each node at that level, and there would also be edges that describe the relationship to nodes at the spatial granularity level above and below.

There are multiple levels of geographic granularity that could be considered:

1. Interconnection - a group of balancing regions that are physically interconnected and can exchange electricity with each other

2. Balancing authority (in US) / country (in Europe) - generally defined by a region for which there is a single operator that is responsible for balancing supply and demand

3. Transmission congested zones within each BA

4. Transmission-level nodes (generally corresponding to LMP nodes in a wholesale market)

5. Distribution-level nodes (generally corresponding to distribution-level substation/feeder)

For example, if we were looking at level 2 (balancing authority), the nodes would be things like CAISO, BPAT, AZPS, and edges that describe how each of these nodes are interconnected to each other at the same level. Each of these BA nodes would also be connected to a node at the level above (interconnection), and the level below (transmission congested zone). Generally, as you move up the spatial granularity mapping (from most granular to least granular), there should be a m:1 relationship (many distribution nodes would map to a single transmission node, many transmission nodes would map to a single subregion, many subregions would map to a single balancing area, etc..).

Then when we have unit-level data, each of these units would have a static attribute that assigns it to a specific node at a specific level of geographic granularity.

[grgmiller]

Related to #3 maybe the lat/long or local timezone database name is a static attribute of the node, so that any end data can be converted from UTC to local time through how it is mapped to the node.

[grgmiller]

Another question is whether or not we want to represent the generation topology below the nodal level. For example, a specific power plant would be mapped to a single distribution or transmission node, But if we are getting source data for individual boilers, units, or generators at a power plant, we would also want a topological mapping of how all boilers, generators, and units are associated with each other at a single power plant. These relationships can be simple (1:1) or complex (m:m).

[gwpicard]

@grgmiller That's exactly what I was thinking as well — specifying topologies for each level and how the levels map onto each other. Some thoughts below:

Shared (and non-shared) attributes across levels Like you said, we should also define the shared node attributes across levels i.e. whether you are at the BA level or plant-level, each will have a shared timestamp dynamic property. However, timezone is more complicated at the BA where they can span multiple timestamps. It would be nice here to figure out what attributes are and aren't shared across levels

Topological mapping schematic It would also be good to agree on the levels of spatial — would you be able to illustrate using some along the lines of below (simplified quick sketch)?:

This is oversimplified and doesn't include any consuming nodes or transmission, but it would be nice to see a simplified version of your thoughts schematically using something along the lines of the above diagram.

Sub-unit-level properties In terms of the properties below the nodal level, I'm not sure if it's overkill at the moment. Getting unit-level production would already be amazing. I hope that our model is flexible enough to append later down the line.

[grgmiller]

Here's what I was thinking. Boxes represent nodes, lines represent edges. Solid lines represent physical connections (eg transmission line) which would each have their own static and dynamic attributes (e.g. line capacity, interchange over line in each timestamp), while dashed lines represent relational edges that only describe how one level maps to another. The round circle represents a dynamic endpoint that would be assigned a single node in the topology - thus, you could aggregate the endpoint to any level above because you know the mapping. This is just a rough sketch of the idea.

Again related to #24 - not sure how we would actually store this network graph and distinguish between the different types of edges.

[gwpicard]

@grgmiller I like this model. I think what would be useful is to map properties to each node in each level. And we can discuss what we like/don't like about and challenge it.

As for how to store it, I think there are things we can get inspiration from. I think the best thing is to have separate modules for nodes and edges. The node module includes an ID + properties. The edge module would contain two node IDs that represent an edge. You could then reconstruct the entire network graph + levels with something like that.

[gwpicard]

One way we could build on this specification would be:

Each node has a mix of static/dynamic data, and in essence becomes directed graph. Each specification would represent the system state at any point in time.

[grgmiller]

Notes from CDSC PSWG meeting 5/26:

• Are ISOs going to follow our data specification, or are they going to give us the data how they want? We might want to make sure that we specify the data in a way that also makes it easy for ISOs
• We might not want to strictly define specific named levels in the hierarchy, since each grid might be structured slightly differently. We might want to label these level 1, 2, 3, etc, and there can be a different number of levels for each region. As long as we know how each level maps to each other across regions, we should be okay. Maybe we define a set of level types that can be assigned to each level for each region that lives as part of the metadata so that we know what level number each node is and what level that node represents
• An endpoint can be attached to any node/edge at any level, based on what the data provider is willing/able to provide
• Each node/edge should maybe include some sort of metadata that specifies what data fields are relevant to a given level (like these https://github.com/carbon-data-specification/Power-Systems-Data/issues/7#issuecomment-1109695041)
• Maybe in addition to metadata being specified for each node and edge, we also need metadata for the levels?
• How does this model map into the CIM / CGMES that is already used by ISOs - maybe we should ensure that these two are compatible.

[m-mirz]

The nodes and edges could be mapped to CIM TopologicalNodes and ACLineSegments

• https://cim.fein-aachen.org/libcimpp/doc/IEC61970_16v29a/classIEC61970_1_1Base_1_1Topology_1_1TopologicalNode.html
• https://cim.fein-aachen.org/libcimpp/doc/IEC61970_16v29a/classIEC61970_1_1Base_1_1Wires_1_1ACLineSegment.html

I think it could be very valuable to reuse the name and mRID defined for these components. You find these attributes if you unfold the "Public Attributes inherited from ... IdentifiedObject" section. Sharing the same unique ID with CIM will make the mapping much easier.

This is one example. I am going to work on a more comprehensive list.

@grgmiller do we also want to keep track of grid reconfigurations by adding switches and breakers?

[grgmiller]

Notes from 7/7 meeting:

• While we are working on this, think about how we are defining each level - i.e. if we say that a transmission node is one level, what does that mean? Why is it important that we are using these levels?
• As we make design decisions we should document: 1) what we mean by terms when we are using them, and 2) why we are making the design decision we are making.

[grgmiller]

Thanks for sharing the CIMS specification @m-mirz . I think one important question that we need to answer about this is what level of specificity we need to define, based on how specifically we want our data to inform models. There are four general types of grid models (copper plate, transshipment, DC power flow, AC power flow; see this for some definitions).

It sounds like we are interested in at least specifying data that could inform a DC power flow model which considers Kirchoffs laws and factors like resistance and max line capacity. However, not sure if we are trying to get to the level of specificity of an AC power flow model that takes into account active and reactive power.

You mentioned switches and breakers - is that too specific, or do we want to just represent the system as nodes and edges? My understanding that representation of switches/breakers would perhaps be useful for reliability/network modeling, but not necessarily DC power flow modeling.

[grgmiller]

Notes from conversation with grid operators 8/23:

• The topology needs to be flexible because not every region has the same structure. For example, within MISO there are regions, zones, and control areas, which don't align with the structure of, say, CAISO.
• Although the specific name of each level should remain abstract, we should have a description for each level that indicates the type of element that should belong to that level. This is to ensure that we can compare elements across different regions. For example, level 0 is called "interconnect" in the US and "Synchronous Area" in ENTSO-E, but the similar element is that it describes a region in which all generators are synchronized at the same AC frequency.
• Next steps might include surveying the structure of different grid regions across the world and trying to map them to a common set of levels