NatLabRockies · elenya-grant · Apr 11, 2026 · Mar 26, 2026 · Mar 26, 2026 · Mar 27, 2026
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -45,6 +45,9 @@
   data between functions in a module. [PR 590](https://github.com/NatLabRockies/H2Integrate/pull/590)
 - Adds `H2IntegrateModel.state` as an `IntEnum` to handle setup and run status checks.
   [PR 590](https://github.com/NatLabRockies/H2Integrate/pull/590)
+- Reclassified open-loop converter control strategies as demand components and updated output naming convention to align with output naming convention in storage performance models [PR 631](https://github.com/NatLabRockies/H2Integrate/pull/631).
+  - The `FlexibleDemandOpenLoopConverterController` has been renamed to `FlexibleDemandComponent`
+  - The `DemandOpenLoopConverterController` has been renamed to `GenericDemandComponent`
 - Modified CI setup so Windows is temporarily disabled and also so unit, regression, and integration tests are run in separate jobs to speed up testing and provide more information on test failures. [PR 668](https://github.com/NatLabRockies/H2Integrate/pull/668)
 
 ## 0.7.2 [April 9, 2026]

diff --git a/docs/_toc.yml b/docs/_toc.yml
@@ -69,6 +69,9 @@ parts:
       - file: control/open-loop_controllers
       - file: control/pyomo_controllers
       - file: control/controller_demonstrations
+  - caption: Demand
+    chapters:
+      - file: demand/demand_components
   - caption: Finance Models
     chapters:
       - file: finance_models/financial_analyses

diff --git a/docs/control/control_overview.md b/docs/control/control_overview.md
@@ -9,8 +9,7 @@ The first approach, [open-loop control](#open-loop-control), assumes no feedback
 Supported controllers:
 - [`SimpleStorageOpenLoopController`](#pass-through-controller)
 - [`DemandOpenLoopStorageController`](#demand-open-loop-storage-controller)
-- [`DemandOpenLoopConverterController`](#demand-open-loop-converter-controller)
-- [`FlexibleDemandOpenLoopConverterController`](#flexible-demand-open-loop-converter-controller)
+
 
 
 (pyomo-control-framework)=

diff --git a/docs/control/open-loop_controllers.md b/docs/control/open-loop_controllers.md
@@ -26,93 +26,3 @@ An example of an N2 diagram for a system using the open-loop control framework f
 For examples of how to use the `DemandOpenLoopStorageController` open-loop control framework, see the following:
 - `examples/14_wind_hydrogen_dispatch/`
 - `examples/19_simple_dispatch/`
-
-## Open-Loop Converter Controllers
-
-Open-loop converter controllers define rule-based logic for meeting commodity demand profiles without using dynamic system feedback. These controllers operate independently at each timestep.
-
-This page documents two core controller types:
-1. Demand Open-Loop Converter Controller — meets a fixed demand profile.
-2. Flexible Demand Open-Loop Converter Controller — adjusts demand up or down within flexible bounds.
-
-(demand-open-loop-converter-controller)=
-### Demand Open-Loop Converter Controller
-The `DemandOpenLoopConverterController` allocates commodity input to meet a defined demand profile. It does not contain energy storage logic, only **instantaneous** matching of supply and demand.
-
-The controller computes each value per timestep:
-- Unmet demand (non-zero when supply < demand, otherwise 0.)
-- Unused commodity (non-zero when supply > demand, otherwise 0.)
-- Delivered output (commodity supplied to demand sink)
-
-This provides a simple baseline for understanding supply–demand balance before adding complex controls.
-
-#### Configuration
-The controller is defined within the `tech_config` and requires these inputs.
-
-| Field             | Type           | Description                           |
-| ----------------- | -------------- | ------------------------------------- |
-| `commodity_name`  | `str`          | Commodity name (e.g., `"hydrogen"`).  |
-| `commodity_units` | `str`          | Units (e.g., `"kg/h"`).               |
-| `demand_profile`  | scalar or list | Timeseries demand or constant demand. |
-
-```yaml
-control_strategy:
-    model: DemandOpenLoopConverterController
-model_inputs:
-  control_parameters:
-    commodity_name: hydrogen
-    commodity_units: kg/h
-    demand_profile: [10, 10, 12, 15, 14]
-```
-For an example of how to use the `DemandOpenLoopConverterController` open-loop control framework, see the following:
-- `examples/23_solar_wind_ng_demand`
-
-(flexible-demand-open-loop-converter-controller)=
-### Flexible Demand Open-Loop Converter Controller
-The `FlexibleDemandOpenLoopConverterController` extends the fixed-demand controller by allowing the actual demand to flex up or down within defined bounds. This is useful for demand-side management scenarios where:
-- Processes can defer demand (e.g., flexible industrial loads)
-- The system requires demand elasticity without dynamic optimization
-
-The controller computes:
-- Flexible demand (clamped within allowable ranges)
-- Unmet flexible demand
-- Unused commodity
-- Delivered output
-
-Everything remains open-loop no storage, no intertemporal coupling.
-
-For an example of how to use the `FlexibleDemandOpenLoopConverterController` open-loop control framework, see the following:
-- `examples/23_solar_wind_ng_demand`
-
-The flexible demand component takes an input commodity production profile, the maximum demand profile, and various constraints (listed below), and creates a "flexible demand profile" that follows the original input commodity production profile while satisfying varying constraint.
-Please see the figure below for an example of how the flexible demand profile can vary from the original demand profile based on the input commodity production profile and the ramp rates.
-The axes are unlabeled to allow for generalization to any commodity and unit type.
-
-| ![Flexible Demand Example](figures/flex_demand_fig.png) |
-|-|
-
-
-#### Configuration
-The flexible demand controller is defined within the `tech_config` with the following parameters:
-
-| Field               | Type           | Description                                  |
-| ------------------- | -------------- | -------------------------------------------- |
-| `commodity_name`          | `str`          | Commodity name.                              |
-| `commodity_units`         | `str`          | Units for all values.                        |
-| `demand_profile`          | scalar or list | Default (nominal) demand profile.            |
-| `turndown_ratio`          | float          | Minimum fraction of baseline demand allowed. |
-| `ramp_down_rate_fraction` | float          | Maximum ramp-down rate per timestep expressed as a fraction of baseline demand. |
-| `ramp_up_rate_fraction` | float          | Maximum ramp-up rate per timestep expressed as a fraction of baseline demand. |
-| `min_utilization` | float          | Minimum total fraction of baseline demand that must be met over the entire simulation. |
-
-```yaml
-model_inputs:
-  control_parameters:
-    commodity_name: hydrogen
-    commodity_units: kg/h
-    demand_profile: [10, 12, 10, 8]
-    turndown_ratio: 0.1
-    ramp_down_rate_fraction: 0.5
-    ramp_up_rate_fraction: 0.5
-    min_utilization: 0
-```
diff --git a/docs/demand/demand_components.md b/docs/demand/demand_components.md
@@ -0,0 +1,90 @@
+# Demand components
+
+- [`GenericDemandComponent`](#generic-demand-component)
+- [`FlexibleDemandComponent`](#flexible-demand-component)
+
+Demand components define rule-based logic for meeting commodity demand profiles without using dynamic system feedback. These components operate independently at each timestep.
+
+This page documents two core demand types:
+1. Generic Demand Component — meets a fixed demand profile.
+2. Flexible Demand Component — adjusts demand up or down within flexible bounds.
+
+(generic-demand-component)=
+### Generic Demand Component
+The `GenericDemandComponent` allocates commodity input to meet a defined demand profile. It does not contain energy storage logic, only **instantaneous** matching of supply and demand.
+
+The demand component computes each value per timestep:
+- Unmet demand (non-zero when supply < demand, otherwise 0.)
+- Unused commodity (non-zero when supply > demand, otherwise 0.)
+- Delivered output (commodity supplied to demand sink)
+
+This provides a simple baseline for understanding supply–demand balance.
+
+#### Configuration
+The demand is defined within the `tech_config` and requires these inputs.
+
+| Field             | Type           | Description                           |
+| ----------------- | -------------- | ------------------------------------- |
+| `commodity_name`  | `str`          | Commodity name (e.g., `"hydrogen"`).  |
+| `commodity_units` | `str`          | Units (e.g., `"kg/h"`).               |
+| `demand_profile`  | scalar or list | Timeseries demand or constant demand. |
+
+```yaml
+performance_model:
+    model: GenericDemandComponent
+model_inputs:
+  performance_parameters:
+    commodity_name: hydrogen
+    commodity_units: kg/h
+    demand_profile: [10, 10, 12, 15, 14]
+```
+For an example of how to use the `GenericDemandComponent` framework, see the following:
+- `examples/23_solar_wind_ng_demand`
+
+(flexible-demand-component)=
+### Flexible Demand Component
+The `FlexibleDemandComponent` extends the generic demand component by allowing the actual demand to flex up or down within defined bounds. This is useful for demand-side management scenarios where:
+- Processes can defer demand (e.g., flexible industrial loads)
+- The system requires demand elasticity without dynamic optimization
+
+The component computes:
+- Flexible demand (clamped within allowable ranges)
+- Unmet flexible demand
+- Unused commodity
+- Delivered output
+
+For an example of how to use the `FlexibleDemandComponent` demand component, see the following:
+- `examples/23_solar_wind_ng_demand`
+
+The flexible demand component takes an input commodity production profile, the maximum demand profile, and various constraints (listed below), and creates a "flexible demand profile" that follows the original input commodity production profile while satisfying varying constraint.
+Please see the figure below for an example of how the flexible demand profile can vary from the original demand profile based on the input commodity production profile and the ramp rates.
+The axes are unlabeled to allow for generalization to any commodity and unit type.
+
+| ![Flexible Demand Example](figures/flex_demand_fig.png) |
+|-|
+
+
+#### Configuration
+The flexible demand component is defined within the `tech_config` with the following parameters:
+
+| Field               | Type           | Description                                  |
+| ------------------- | -------------- | -------------------------------------------- |
+| `commodity_name`          | `str`          | Commodity name.                              |
+| `commodity_units`         | `str`          | Units for all values.                        |
+| `demand_profile`          | scalar or list | Default (nominal) demand profile.            |
+| `turndown_ratio`          | float          | Minimum fraction of baseline demand allowed. |
+| `ramp_down_rate_fraction` | float          | Maximum ramp-down rate per timestep expressed as a fraction of baseline demand. |
+| `ramp_up_rate_fraction` | float          | Maximum ramp-up rate per timestep expressed as a fraction of baseline demand. |
+| `min_utilization` | float          | Minimum total fraction of baseline demand that must be met over the entire simulation. |
+
+```yaml
+model_inputs:
+  performance_parameters:
+    commodity_name: hydrogen
+    commodity_units: kg/h
+    demand_profile: [10, 12, 10, 8]
+    turndown_ratio: 0.1
+    ramp_down_rate_fraction: 0.5
+    ramp_up_rate_fraction: 0.5
+    min_utilization: 0
+```
diff --git a/docs/user_guide/model_overview.md b/docs/user_guide/model_overview.md
@@ -67,6 +67,7 @@ Below summarizes the available performance, cost, and financial models for each
   - [Storage Models](#storage-models)
   - [Basic Operations](#basic-operations)
   - [Control Models](#control-models)
+  - [DemandModels](#demand-models)
 
 (resource-models)=
 ## Resource models
@@ -284,8 +285,10 @@ Below summarizes the available performance, cost, and financial models for each
     - `'SimpleStorageOpenLoopController'`: open-loop control; manages resource flow based on demand and input commodity
     - `'DemandOpenLoopStorageController'`: open-loop control; manages resource flow based on demand and storage constraints
     - `'HeuristicLoadFollowingController'`: open-loop control that works on a time window basis to set dispatch commands; uses Pyomo
-- Converter Controllers:
-    - `'DemandOpenLoopConverterController'`: open-loop control; manages resource flow based on demand constraints
-    - `'FlexibleDemandOpenLoopConverterController'`: open-loop control; manages resource flow based on demand and flexibility constraints
 - Optimized Dispatch:
     - `'OptimizedDispatchController'`: optimization-based dispatch using Pyomo
+
+(demand-models)=
+## Demand Models
+- `'GenericDemandComponent'`: manages resource flow based on demand constraints
+- `'FlexibleDemandComponent'`: manages resource flow based on demand and flexibility constraints
diff --git a/examples/19_simple_dispatch/run_wind_battery.py b/examples/19_simple_dispatch/run_wind_battery.py
@@ -42,14 +42,14 @@
 )
 ax[1].plot(
     range(start_hour, end_hour),
-    model.prob.get_val("battery.electricity_unused_commodity", units="MW")[start_hour:end_hour],
+    model.prob.get_val("battery.unused_electricity_out", units="MW")[start_hour:end_hour],
     linestyle=":",
     label="Unused Electricity commodity (MW)",
     linewidth=2,
 )
 ax[1].plot(
     range(start_hour, end_hour),
-    model.prob.get_val("battery.electricity_unmet_demand", units="MW")[start_hour:end_hour],
+    model.prob.get_val("battery.unmet_electricity_demand_out", units="MW")[start_hour:end_hour],
     linestyle=":",
     label="Electricity Unmet Demand (MW)",
     linewidth=2,

diff --git a/examples/23_solar_wind_ng_demand/flexible_demand_tech_config.yaml b/examples/23_solar_wind_ng_demand/flexible_demand_tech_config.yaml
@@ -91,10 +91,10 @@ technologies:
         variable_opex_per_mwh: 0.0  # $/MWh
         cost_year: 2023
   electrical_load_demand:
-    control_strategy:
-      model: FlexibleDemandOpenLoopConverterController
+    performance_model:
+      model: FlexibleDemandComponent
     model_inputs:
-      control_parameters:
+      performance_parameters:
         commodity: electricity
         commodity_rate_units: kW
         rated_demand: 100000

diff --git a/examples/23_solar_wind_ng_demand/plant_config.yaml b/examples/23_solar_wind_ng_demand/plant_config.yaml
@@ -27,7 +27,7 @@ technology_interconnections:
                                                                 # connect NG feedstock to NG plant
   - [combiner, electrical_load_demand, [electricity_out, electricity_in]]
                                                                                  # subtract wind and solar from demand
-  - [electrical_load_demand, natural_gas_plant, [electricity_unmet_demand, electricity_demand]]
+  - [electrical_load_demand, natural_gas_plant, [unmet_electricity_demand_out, electricity_demand]]
                                                                                                        # give remaining load demand to natural gas plant
   - [combiner, fin_combiner, electricity, cable]
   - [natural_gas_plant, fin_combiner, electricity, cable]

diff --git a/examples/23_solar_wind_ng_demand/tech_config.yaml b/examples/23_solar_wind_ng_demand/tech_config.yaml
@@ -91,10 +91,10 @@ technologies:
         variable_opex_per_mwh: 0.0  # $/MWh
         cost_year: 2023
   electrical_load_demand:
-    control_strategy:
-      model: DemandOpenLoopConverterController
+    performance_model:
+      model: GenericDemandComponent
     model_inputs:
-      control_parameters:
+      performance_parameters:
         commodity: electricity
         commodity_rate_units: kW
         demand_profile: 100000  # 100 MW

diff --git a/examples/24_solar_battery_grid/README.md b/examples/24_solar_battery_grid/README.md
@@ -53,8 +53,8 @@ The grid performance model handles:
 - `electricity_in`: Power flowing INTO the grid (selling to grid) - limited by interconnection size
 - `electricity_out`: Power flowing OUT OF the grid (buying from grid) - limited by interconnection size
 - `electricity_sold`: Actual electricity sold (up to interconnection limit)
-- `electricity_unmet_demand`: Demand that couldn't be met due to interconnection limit
-- `electricity_excess`: Electricity that couldn't be sold due to interconnection limit
+- `unmet_electricity_demand_out`: Demand that couldn't be met due to interconnection limit
+- `unused_electricity_out`: Electricity that couldn't be sold due to interconnection limit
 
 **Cost Model:**
 - CapEx: Based on interconnection size ($/kW) plus fixed costs
@@ -72,16 +72,16 @@ Solar → Battery → [Grid Buy (purchases) | Grid Sell (sales)]
 
 - Solar generates electricity
 - Battery stores excess and follows 100 MW demand profile
-- Grid Buy purchases electricity when battery cannot meet demand (via `electricity_unmet_demand` → `electricity_demand` connection)
-- Grid Sell accepts excess electricity when battery has surplus (via `electricity_unused_commodity` → `electricity_in` connection)
+- Grid Buy purchases electricity when battery cannot meet demand (via `unmet_electricity_demand_out` → `electricity_demand` connection)
+- Grid Sell accepts excess electricity when battery has surplus (via `unused_electricity_out` → `electricity_in` connection)
 
 ### Technology Interconnections
 
 ```yaml
 technology_interconnections: [
   ["solar", "battery", "electricity", "cable"],
-  ["battery", "grid_buy", ["electricity_unmet_demand", "electricity_demand"]],
-  ["battery", "grid_sell", ["electricity_unused_commodity", "electricity_in"]]
+  ["battery", "grid_buy", ["unmet_electricity_demand_out", "electricity_demand"]],
+  ["battery", "grid_sell", ["unused_electricity_out", "electricity_in"]]
 ]
 ```