IOM should be component-neutral, as much as possible. Eliminate PSY types where possible. Looking through, common oppotunities:
Category 1: types we can broaden.
PSY.Component -> IS.InfrastructureSystemsComponentPSY.System -> IS.InfrastructureSystemsContainer
Category 2: present in IS, but we're using the PSY prefix here and there.
UnitSystem and its subtypes- function data types:
PiecewiseLinearData
- value curve types:
TimeSeriesData
The worst offenders are in /src/utils/powersystems_utils.jl.
Seemingly unavoidable:
- Components:
ACBus (network model), HVDC, Service, Contingency, ThermalGen (must run checks)
- Cost related: MBC/IEC cost structs,
OperationalCost (only supertype: DeviceParameter)
IOM should be component-neutral, as much as possible. Eliminate PSY types where possible. Looking through, common oppotunities:
Category 1: types we can broaden.
PSY.Component->IS.InfrastructureSystemsComponentPSY.System->IS.InfrastructureSystemsContainerCategory 2: present in
IS, but we're using thePSYprefix here and there.UnitSystemand its subtypesPiecewiseLinearDataTimeSeriesDataThe worst offenders are in
/src/utils/powersystems_utils.jl.Seemingly unavoidable:
ACBus(network model),HVDC,Service,Contingency,ThermalGen(must run checks)OperationalCost(only supertype:DeviceParameter)