power-openapi-models 0.2.0__tar.gz → 0.3.0__tar.gz

{power_openapi_models-0.2.0/src/power_openapi_models.egg-info → power_openapi_models-0.3.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: power-openapi-models
-Version: 0.2.0
+Version: 0.3.0
 Summary: Typed Python models for the Sienna power system data format
 Author: Sienna Platform
 License-Expression: BSD-3-Clause

{power_openapi_models-0.2.0 → power_openapi_models-0.3.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "power-openapi-models"
-version = "0.2.0"
+version = "0.3.0"
 description = "Typed Python models for the Sienna power system data format"
 readme = "README.md"
 license = "BSD-3-Clause"

power_openapi_models-0.3.0/src/power_openapi_models/_schema_version.txt

@@ -0,0 +1 @@
+v0.3.0

{power_openapi_models-0.2.0/src/power_openapi_models/bundles/0.2.0 → power_openapi_models-0.3.0/src/power_openapi_models/bundles/0.3.0}/PortfolioDocument.json

@@ -1,5 +1,5 @@
 {
-  "$comment": "Strict validation bundle for schema release 0.2.0.",
+  "$comment": "Strict validation bundle for schema release 0.3.0.",
   "$schema": "http://json-schema.org/draft-07/schema#",
   "additionalProperties": false,
   "definitions": {
@@ -180,6 +180,15 @@
           "description": "Name of the component. Components of the same type (e.g., `PowerLoad`) must have unique names, but components of different types (e.g., `PowerLoad` and `ACBus`) can have the same name.",
           "type": "string"
         },
+        "out_of_area_load_ids": {
+          "default": [],
+          "description": "IDs of the loads that belong to this area but connect to a bus in another area (PSS/E off-area loads). When area interchange control includes these loads (PSS/E AREAIN=2), their demand counts in the net interchange of this area, not of the area of their bus.",
+          "items": {
+            "type": "integer"
+          },
+          "type": "array",
+          "uniqueItems": true
+        },
         "peak_active_power": {
           "default": 0.0,
           "description": "Peak active power in the area. Units: per power_units \u2014 NATURAL_UNITS: MW, COMPONENT_BASE: pu .",
@@ -193,6 +202,13 @@
         "power_units": {
           "$ref": "#/definitions/UnitSystem",
           "description": "Unit basis for this component's power-family fields (active/reactive/apparent power, ratings, limits, ramp rates). COMPONENT_BASE: per unit on this component's own base_power. NATURAL_UNITS: the field's physical unit."
+        },
+        "scheduled_net_interchange": {
+          "description": "Scheduled net active power interchange of the area (PSS/E PDES): the area's total export minus its total import that area interchange control holds. Positive means the area exports power. `null` when the area has no scheduled interchange; `0.0` is a valid schedule. Units: per power_units \u2014 NATURAL_UNITS: MW, COMPONENT_BASE: pu .",
+          "type": [
+            "number",
+            "null"
+          ]
         }
       },
       "required": [
@@ -206,7 +222,7 @@
     },
     "AverageRateCurve": {
       "additionalProperties": false,
-      "description": "A curve whose y values are the average rate `f(x)/x` at production level `x` \u2014 total cost or fuel divided by output, the form heat rate tables use when they report MBTU/MWh against MW. `initial_input` records the total input at the minimum production point and is what makes conversion to an `InputOutputCurve` possible. Use `IncrementalCurve` when the data gives marginal rather than average rates.",
+      "description": "A curve whose y values are the average rate `f(x)/x` at production level `x` \u2014 total cost or fuel divided by output, the form heat rate tables use when they report MMBtu/MWh against MW. `initial_input` records the total input at the minimum production point and is what makes conversion to an `InputOutputCurve` possible. Use `IncrementalCurve` when the data gives marginal rather than average rates.",
       "properties": {
         "curve_type": {
           "const": "AVERAGE_RATE",
@@ -572,6 +588,10 @@
         "id": {
           "type": "integer"
         },
+        "license": {
+          "description": "License of the source data, if known: an SPDX identifier such as 'CC-BY-4.0', or a license name or URL.",
+          "type": "string"
+        },
         "organization": {
           "description": "Publishing organization, e.g. 'U.S. Energy Information Administration'.",
           "type": "string"
@@ -822,6 +842,11 @@
           "$ref": "#/definitions/Period",
           "description": "Step between the start of consecutive forecast windows. Part of the series' identity: two forecasts of one variable at the same resolution but different intervals \u2014 a day-ahead and a real-time forecast \u2014 are distinct series. `PT0S` is the canonical interval of a single-window forecast, which has no second window to step to."
         },
+        "interval_alignment": {
+          "$ref": "#/definitions/IntervalAlignment",
+          "default": "PERIOD_ENDING",
+          "description": "Position of each timestamp in the period it represents."
+        },
         "name": {
           "description": "Time series name (e.g. max_active_power). Part of the series' identity, and often carrying a disambiguating suffix; `component_field` records what the values are for.",
           "type": "string"
@@ -953,6 +978,11 @@
           "$ref": "#/definitions/Period",
           "description": "Step between the start of consecutive forecast windows. Part of the series' identity: two forecasts of one variable at the same resolution but different intervals \u2014 a day-ahead and a real-time forecast \u2014 are distinct series. `PT0S` is the canonical interval of a single-window forecast, which has no second window to step to."
         },
+        "interval_alignment": {
+          "$ref": "#/definitions/IntervalAlignment",
+          "default": "PERIOD_ENDING",
+          "description": "Position of each timestamp in the period it represents."
+        },
         "name": {
           "description": "Time series name (e.g. max_active_power). Part of the series' identity, and often carrying a disambiguating suffix; `component_field` records what the values are for.",
           "type": "string"
@@ -1204,10 +1234,10 @@
     },
     "FuelCurve": {
       "additionalProperties": false,
-      "description": "Variable operation cost of a device expressed in fuel consumed \u2014 MBTU, liters, m^3 \u2014 together with the price that converts fuel to currency. Wraps a `ValueCurve` in input-output, incremental, or average-rate form; exactly one of `fuel_cost` and `fuel_cost_time_series` supplies the price.",
+      "description": "Variable operation cost of a device expressed in fuel consumed, in the fuel quantity `fuel_units` names, together with the price that converts fuel to currency. Wraps a `ValueCurve` in input-output, incremental, or average-rate form, whose y axis is fuel per hour; exactly one of `fuel_cost` and `fuel_cost_time_series` supplies the price.",
       "properties": {
         "fuel_cost": {
-          "description": "Fixed fuel cost per unit of fuel, or null when fuel_cost_time_series names a time-varying one. Exactly one of the two is set; producers and consumers enforce it.",
+          "description": "Fixed fuel cost in USD per one `fuel_units` of fuel, or null when fuel_cost_time_series names a time-varying one. Exactly one of the two is set; producers and consumers enforce it.",
           "type": [
             "number",
             "null"
@@ -1220,12 +1250,16 @@
             "null"
           ]
         },
+        "fuel_units": {
+          "$ref": "#/definitions/FuelUnit",
+          "description": "The fuel quantity the curve's y axis counts (per hour) and `fuel_cost` is priced per. No default: an unstated fuel unit is ambiguous."
+        },
         "power_units": {
           "$ref": "#/definitions/UnitSystem"
         },
         "startup_fuel_offtake": {
           "$ref": "#/definitions/InputOutputCurve",
-          "description": "Fuel consumed during startup, as a curve in the unit's fuel units."
+          "description": "Fuel consumed during startup, as a curve in `fuel_units`."
         },
         "value_curve": {
           "$ref": "#/definitions/ValueCurve"
@@ -1242,12 +1276,22 @@
       "required": [
         "value_curve",
         "power_units",
+        "fuel_units",
         "vom_cost",
         "variable_cost_type"
       ],
       "title": "FuelCurve",
       "type": "object"
     },
+    "FuelUnit": {
+      "description": "Fuel quantity a `FuelCurve` is expressed in: `MMBTU` (million British thermal units) or `GJ` (gigajoules) of heat content.",
+      "enum": [
+        "MMBTU",
+        "GJ"
+      ],
+      "title": "FuelUnit",
+      "type": "string"
+    },
     "FunctionData": {
       "description": "Raw mathematical data defining a function `f(x)` \u2014 coefficients or point tables with no units or interpretation attached. `function_type` selects the shape: linear, quadratic, piecewise linear through (x, y) points, or piecewise constant between x endpoints. What `x` and `y` stand for is supplied by whatever wraps this, and the `TIME_SERIES_*` variants hold a reference to a stored series in place of the numbers.",
       "oneOf": [
@@ -1453,6 +1497,16 @@
       "title": "InputOutputCurve",
       "type": "object"
     },
+    "IntervalAlignment": {
+      "description": "Position of a timestamp in the period of length `resolution` that its value represents. At a one-hour resolution, the value at 01:00 covers 01:00 to 02:00 for `PERIOD_BEGINNING`, 00:30 to 01:30 for `PERIOD_MIDPOINT`, and 00:00 to 01:00 for `PERIOD_ENDING`. Descriptive: the store records it and does not realign a series.",
+      "enum": [
+        "PERIOD_BEGINNING",
+        "PERIOD_MIDPOINT",
+        "PERIOD_ENDING"
+      ],
+      "title": "IntervalAlignment",
+      "type": "string"
+    },
     "LinearFunctionData": {
       "additionalProperties": false,
       "description": "Data for a linear function `f(x) = proportional_term * x + constant_term`.",
@@ -1909,7 +1963,7 @@
         },
         "points": {
           "items": {
-            "$ref": "#/definitions/XY_Coords"
+            "$ref": "#/definitions/TwoDimensionalFunctionPoint"
           },
           "type": "array"
         }
@@ -2105,6 +2159,11 @@
           "$ref": "#/definitions/Period",
           "description": "Step between the start of consecutive forecast windows. Part of the series' identity: two forecasts of one variable at the same resolution but different intervals \u2014 a day-ahead and a real-time forecast \u2014 are distinct series. `PT0S` is the canonical interval of a single-window forecast, which has no second window to step to."
         },
+        "interval_alignment": {
+          "$ref": "#/definitions/IntervalAlignment",
+          "default": "PERIOD_ENDING",
+          "description": "Position of each timestamp in the period it represents."
+        },
         "name": {
           "description": "Time series name (e.g. max_active_power). Part of the series' identity, and often carrying a disambiguating suffix; `component_field` records what the values are for.",
           "type": "string"
@@ -2429,6 +2488,11 @@
           "$ref": "#/definitions/Period",
           "description": "Step between the start of consecutive forecast windows. Part of the series' identity: two forecasts of one variable at the same resolution but different intervals \u2014 a day-ahead and a real-time forecast \u2014 are distinct series. `PT0S` is the canonical interval of a single-window forecast, which has no second window to step to."
         },
+        "interval_alignment": {
+          "$ref": "#/definitions/IntervalAlignment",
+          "default": "PERIOD_ENDING",
+          "description": "Position of each timestamp in the period it represents."
+        },
         "name": {
           "description": "Time series name (e.g. max_active_power). Part of the series' identity, and often carrying a disambiguating suffix; `component_field` records what the values are for.",
           "type": "string"
@@ -2553,6 +2617,11 @@
           "format": "date-time",
           "type": "string"
         },
+        "interval_alignment": {
+          "$ref": "#/definitions/IntervalAlignment",
+          "default": "PERIOD_ENDING",
+          "description": "Position of each timestamp in the period it represents."
+        },
         "length": {
           "description": "Number of timesteps.",
           "minimum": 0,
@@ -3253,6 +3322,7 @@
             "id",
             "initial_timestamp",
             "interval",
+            "interval_alignment",
             "length",
             "name",
             "owner_category",
@@ -3422,6 +3492,26 @@
       "title": "TimeSeriesQuadraticFunctionData",
       "type": "object"
     },
+    "TwoDimensionalFunctionPoint": {
+      "additionalProperties": false,
+      "description": "A single point, given as its `x` and `y` coordinates.",
+      "properties": {
+        "x": {
+          "description": "Units: the wrapped function's input unit.",
+          "type": "number"
+        },
+        "y": {
+          "description": "Units: the wrapped function's output unit.",
+          "type": "number"
+        }
+      },
+      "required": [
+        "x",
+        "y"
+      ],
+      "title": "TwoDimensionalFunctionPoint",
+      "type": "object"
+    },
     "UnitSystem": {
       "description": "Unit basis a stored value is expressed in. COMPONENT_BASE: per-unit against a base the component records itself. NATURAL_UNITS: the quantity's own physical unit. No system-wide option: a value per-unitized against a shared base records that base on the component and rides as COMPONENT_BASE. Used in three scopes, each read against its own record rather than a document-wide table: a component's own `power_units` (against that component's `base_power`), a cost payload's own `power_units` (e.g. `CostCurve`, against the owning component's `base_power`), and a time series association's own `unit_system` (governing only that one series).",
       "enum": [
@@ -3475,26 +3565,6 @@
       ],
       "title": "ValueCurve",
       "type": "object"
-    },
-    "XY_Coords": {
-      "additionalProperties": false,
-      "description": "A single point, given as its `x` and `y` coordinates.",
-      "properties": {
-        "x": {
-          "description": "Units: the wrapped function's input unit.",
-          "type": "number"
-        },
-        "y": {
-          "description": "Units: the wrapped function's output unit.",
-          "type": "number"
-        }
-      },
-      "required": [
-        "x",
-        "y"
-      ],
-      "title": "XY_Coords",
-      "type": "object"
     }
   },
   "description": "The serialized form of a whole investment portfolio: the candidate technologies, regional aggregations, and policy requirements that make up an expansion problem, the supplemental attributes that describe them, the association tables that link them, and the names of the sidecar files holding the base power system and the time series values. This is the interchange format between producers of portfolio data and the consumers that expand or solve it, so the shape is defined here rather than by convention in each producer.\n\nThere is no document-level unit system or base power. A portfolio records every value in natural units and, unlike a power system, carries no per-unit basis of its own: there is no `power_units`/`base_power` resolution to perform at the document level. The only unit marker that ever appears is an embedded cost payload's own `power_units` (on a CostCurve or FuelCurve), which is intrinsic to that curve and interpreted from the curve alone.\n\nDeliberately excluded from openapi-generator: `components` is a map from type name to an array of heterogeneous component objects, which the generated client cannot express as typed buckets. The hand-written container in the generated investments model package (`src/openapi/document.jl`) is the single representation of that type ordering, and its fields are checked against this file. This schema remains authoritative for every other language binding.\n\nThe base power system the portfolio expands is not embedded: `base_system_file` names a sidecar holding it as its own system document, so a portfolio and its base system can be written, moved, and read together. Time series *values* likewise never appear here \u2014 `time_series_associations` carries the metadata rows and `time_series_storage_file` names the sidecar; reading or writing that file is the consumer's job.",