Supplemental attributes
SupplementalAttribute types hold contextual data linked to Components — information that sits outside each component's electrical definition. Geographic location, outage schedules, plant groupings, emissions profiles, and PSS/e impedance correction tables are typical examples. Keeping this metadata separate from component structs reflects how power system datasets are actually organized: the same contextual fact often applies to many devices, and it changes on a different schedule than network equipment data.
Why separate contextual data from components?
Power system components exist in multiple contexts. A generator is not only defined by its electrical properties — it also has a location, may belong to a plant, and may share infrastructure with other units. Traditional approaches stored this extra information in generic dictionary fields, which led to inconsistent data across large systems, difficult maintenance, and no validation of what was stored.
Supplemental attributes address this by using structured types instead of loose dictionaries. Electrical behavior stays in component definitions; contextual information lives in attributes that can be attached, queried, and shared explicitly. This lets you build models in layers (electrical first, context later), reuse contextual data across systems, and update outage schedules or emissions profiles without touching electrical models — while keeping the speed of in-memory data rather than relying on heavyweight component objects or an external relationship database.
How relationships work
Supplemental attributes use many-to-many relationships. One attribute can connect to multiple components, and one component can have multiple attributes.
For example:
- Multiple generators at the same plant can share geographic coordinates
- One weather pattern can affect several plants in a region
- Each generator might have its own maintenance schedule
This flexibility matches how power systems actually work, where components share resources and are affected by common factors.
What kinds of contextual data are available?
PowerSystems.jl provides supplemental attribute types for common modeling needs. Each topic has a dedicated explanation page and a matching how-to guide; field-level API details live in the Public API Reference docstrings.
| Modeling need | Explanation | How-to |
|---|---|---|
| Group units into plants (shafts, penstocks, PCCs, combined cycle) | Grouping generators into plants | Group generators into plants |
| Emissions rates and start-up adders | Emissions metadata | Add emissions to generators |
| Planned and forced outages | Outage and contingency data | Model Outages |
| Geographic location (GeoJSON) | (this page) | Parse MATPOWER or PSS/e files — auto-loaded from PSS/e v35 substations |
| PSS/e transformer impedance correction tables | (this page) | Migrate from version 4.0 to 5.0 |
GeographicInfo stores GeoJSON location metadata and can be shared across buses. When parsing PSS/e v35 files with a substation section, coordinates are automatically attached as GeographicInfo attributes. See Parsing MATPOWER or PSS/e Files.
ImpedanceCorrectionData links a PSS/e Transformer Impedance Correction Table row to a transformer. It is typically populated during PSS/e import rather than built by hand.
Attributes can include time series data — for example, planned outage schedules and stochastic forced-outage probabilities.
Learn more
- Attach supplemental data to components — attach any supplemental attribute to a component
- Query contextual data on a system — retrieve attributes and their associations
- Hydro reservoir topology — linking reservoirs to turbines (component relationships, not supplemental attributes)
- Type Structure — where supplemental attributes sit in the type hierarchy