Skip to content

Properties #1474

@FabianHofmann

Description

@FabianHofmann

Problem Statement

PyPSA currently treats non-physical entities (carriers, shapes, line types, etc.) as regular components alongside physical ones (generators, lines, buses). This mixing makes it difficult to:

  • Distinguish between physical and metadata components == propertys programmatically
  • Establish hierarchical relationships between metadata layers
  • Perform efficient grouped operations in statistics and plotting
  • Validate cross-component references

Idea

propertys in PyPSA are data components representing non-physical entities and abstract attributes in dense format such as n.carrier, n.country, n.shapes.
They are mostly used in internal functionalities for statistics, plotting and wherever mapping to meta data is needed.

Propertys are layers for dense information which can be referenced by (physical) components (Generator, Line, etc) or other properties through columns in the static dataframe. The latter is referred to as a nested API approach. To define and use it the user typically would

  1. initialize the meta component n.property.add("x", attr1="a")
  2. reference the property in a column of a component, n.generators["x"]
  3. refer to it in statistics (or similar modules) n.stats.optimal_capacity(groupby="x") or n.stats.optimal_capacity(groupby=("x", "attr1")) (we still have to decide on the API here!)

Proposed Solution

1. Property Class

Create a distinct Property base class that:

  • Inherits from the existing Components base class
  • Adds metadata-specific functionality (hierarchical relationships, validation)
  • Clearly identifies non-physical entities

2. Nested API & Hierarchical Relationships

Enable parent-child relationships between components:

# Define property hierarchy
n.properties.countries.add("DE", name="Germany")
n.properties.bidding_zones.add("DE_50Hz", country="DE", name="Germany 50Hz")
n.properties.nodes.add("node_1", bidding_zone="DE_50Hz")

# Reference in physical components
n.generators["node"] = "node_1"  # Automatically inherits bidding_zone and country

# Use in statistics with automatic hierarchy traversal
n.statistics.capacity(groupby="country")  # Aggregates through bidding_zone → country
n.statistics.capacity(groupby="bidding_zone.tso")  # Access nested attributes

Example Use Case - Geographical Maps with different resolution

With a nested API approach, the flexibility on plotting different geographical layers may increase significantly. Imagine you have a pypsa network in high spatial resolution, with property for bidding_zone and country defined (initialized and referenced). Additionally, the geopandas dataframe in n.shapes contains shapes for all bidding zones and countries. n.explore would now be able to create statistics and full automatically plot them on nodal, bidding zone and country level.

Example Use Case - Grouping by sectors

The user defines an additional column in n.carriers sector which can directly be used in statistics (see Idea 3. above)

Preconditions

  • Optional attributes: Attributes which are not assigned if not needed
  • Data validation

Existing “Properties”

  • Carrier
  • Line Types
  • Transformer Types
  • Shapes
  • Global Constraints

Extentions / Future Work / Related topics

We can think about how to distinguish between pre-loaded properties and user-defined properties. for example line types and in future other things like technology-data access point, could serve as templates or input data. there should be a clear separation between these kinds.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    Status

    Todo

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions