Skip to content

Add units-aware getters/setters for power system components#1617

Draft
luke-kiernan wants to merge 5 commits intomainfrom
lk/units-prototype
Draft

Add units-aware getters/setters for power system components#1617
luke-kiernan wants to merge 5 commits intomainfrom
lk/units-prototype

Conversation

@luke-kiernan
Copy link
Copy Markdown
Contributor

Prototype of units-aware getters and setters. Core functionality works: some tests fail, but I believe it's due to inter-package friction (e.g. PSB's systems aren't quite compatible).

  • Add conversion methods in components.jl for get_value/set_value
    • MW conversion: device_base * base_power → MW
    • Mvar conversion: device_base * base_power → Mvar
    • DU conversion: returns RelativeQuantity with device base
    • SU conversion: converts to system base per-unit
  • Handle compound types (MinMax, UpDown) with recursive conversion
  • Regenerate all struct files with new accessor signatures
  • Update exports to include MW, Mvar, MVA, kV, OHMS, SIEMENS, DU, SU
  • Update test dependencies and add explicit units API tests
  • Dev InfrastructureSystems.jl dependency to local version

Example usage:
get_active_power(gen) # → 30.0 MW (default)
get_active_power(gen, DU) # → 0.6 DU (device base)
get_reactive_power(gen) # → 20.0 Mvar

- Add conversion methods in components.jl for get_value/set_value
  - MW conversion: device_base * base_power → MW
  - Mvar conversion: device_base * base_power → Mvar
  - DU conversion: returns RelativeQuantity with device base
  - SU conversion: converts to system base per-unit
- Handle compound types (MinMax, UpDown) with recursive conversion
- Regenerate all struct files with new accessor signatures
- Update exports to include MW, Mvar, MVA, kV, OHMS, SIEMENS, DU, SU
- Update test dependencies and add explicit units API tests
- Dev InfrastructureSystems.jl dependency to local version

Example usage:
  get_active_power(gen)       # → 30.0 MW (default)
  get_active_power(gen, DU)   # → 0.6 DU (device base)
  get_reactive_power(gen)     # → 20.0 Mvar

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
@luke-kiernan
Copy link
Copy Markdown
Contributor Author

luke-kiernan commented Jan 21, 2026

Where things currently stand:

  • set_value(comp, val::Quantity) calls the new Unitful conversion system
  • set_value(comp, val::Float64) calls the multiplier system and uses the system's units setting
  • get_value(comp, units) for fields marked as "needs_conversion" (e.g. active, reactive power) returns Unitful results; if units is omitted, you get natural units.

Main problems I've noticed:

  1. Manual conversions: extra * base_power.
  2. Implicitly using system base: since we're defaulting to natural units, need to change get_value to get_value(comp, "SU") in a couple spots. [We could change the default to system base, but then that gets weird when components aren't attached to a system.]
  3. Constants: setting total_power = 0.0 then adding each power individually doesn't work any more, because you get unitless + unitful.

In PSY, the major places that use the old units system and will need overhaul are the ones we expected: parsing from PowerSystemTableData [planned for depreciation], time series, cost curves, and the public stateful API [set_units_base_system!, with_units_base].

edit: oh....an unfortunate side effect is that the getters now ignore the system's unit setting. That's not come up here in PSY--we don't manipulate units a whole lot here--but it will definitely cause issues in downstream packages.

edit^2: the above "unfortunate side effect" is fixable. Make the single-argument get_value(comp) return MWA, SU, or DU, depending on whether the system's unit setting is NATURAL_UNITS, SYSTEM_BASE, or DEVICE_BASE. However, that's immediate type instability.

luke-kiernan and others added 2 commits March 17, 2026 14:01
Default getters now use _get_system_units() instead of hardcoded
unit types, respecting the system's unit setting.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant