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
- initialize the meta component
n.property.add("x", attr1="a")
- reference the property in a column of a component,
n.generators["x"]
- 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.
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:
propertys programmaticallyIdea
propertys in PyPSA are data components representing non-physical entities and abstract attributes in dense format such asn.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 wouldn.property.add("x", attr1="a")n.generators["x"]statistics(or similar modules)n.stats.optimal_capacity(groupby="x")orn.stats.optimal_capacity(groupby=("x", "attr1"))(we still have to decide on the API here!)Proposed Solution
1. Property Class
Create a distinct
Propertybase class that:Componentsbase class2. Nested API & Hierarchical Relationships
Enable parent-child relationships between components:
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_zoneandcountrydefined (initialized and referenced). Additionally, the geopandas dataframe inn.shapescontains shapes for all bidding zones and countries.n.explorewould 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.carrierssectorwhich can directly be used instatistics(see Idea 3. above)Preconditions
Existing “Properties”
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-dataaccess point, could serve as templates or input data. there should be a clear separation between these kinds.