Enhancement: Convert `supported_models` to enforce actual class names #468

johnjasa · 2026-01-30T03:48:50Z

Nice, thanks!

johnjasa · 2026-01-30T03:48:04Z

Could you please modify the docs around this section to make it clear that the string name just maps directly to the class name here? And say this is the name used in the input yaml files?

-Original file line number
+Diff line change
@@ Expand Up / @@ -124,15 +124,20 @@ tests/h2integrate/test_hydrogen/data/* @@
     tests/h2integrate/test_hydrogen/output.txt
     *speed_dir_data.csv
     examples/h2integrate/*/data
+    examples/**/*data/
     examples/h2integrate/*/figures
+    examples/*/*_output_dir/
+    examples/*/*.sqlite
     examples/*/*_new.*
     examples/*/*[0-9].*
     *wind_electrolyzer/
     tests/h2integrate/reports/
     tests/h2integrate/test_hydrogen/output/
     **/run_*_out/
+    **/*_run/
     *_out/
     **/test_*_out/
+    **/wind_electrolyzer/*
     docs/misc_resources/wind_electrolyzer/
     docs/_autosummary
@@ Expand Down @@

-Original file line number
+Diff line change
@@ Expand Up / @@ -29,7 +29,10 @@ @@
       - Remove unused dependencies.
       - Fixes typos for skipped folders.
       - Fixes missing dependencies for `gis` modifier used in new iron mapping tests.
-      - Remove `pytest-subtests` as it's incorporated into pytest as of v9, and is an archived project.
+    - Updates all models in `supported_models` to map between a string version of the class name and
+      the class itself. As such, all examples and documentation have been updated to properly instruct
+      users to the change in model configuration naming conventions.
+    - Remove `pytest-subtests` as it's incorporated into pytest as of v9, and is an archived project.
     ## 0.5.1 [December 18, 2025]
@@ Expand Down @@

-Original file line number
+Diff line change
@@ Expand Up @@
     The first approach, [open-loop control](#open-loop-control), assumes no feedback of any kind to the controller. The open-loop framework does not require a detailed technology performance model and can essentially act as the performance model. The open-loop framework establishes a control component that runs the control and passes out information about `<commodity>_unmet_demand`, `unused_<commodity>`, `<commodity>_out`, and `total_<commodity>_unmet_demand`.
     Supported controllers:
-    - [`pass_through_controller`](#pass-through-controller)
-    - [`demand_open_loop_storage_controller`](#demand-open-loop-storage-controller)
-    - [`demand_open_loop_converter_controller`](#demand-open-loop-converter-controller)
-    - [`flexible_demand_open_loop_converter_controller`](#flexible-demand-open-loop-converter-controller)
+    - [`PassThroughOpenLoopController`](#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)=
@@ Expand All @@
     In the pyomo control framework in H2Integrate, each technology can have control rules associated with them that are in turn passed to the pyomo control component, which is owned by the storage technology. The pyomo control component combines the technology rules into a single pyomo model, which is then passed to the storage technology performance model inside a callable dispatch function. The dispatch function also accepts a simulation method from the performance model and iterates between the pyomo model for dispatch commands and the performance simulation function to simulated performance with the specified commands. The dispatch function runs in specified time windows for dispatch and performance until the whole simulation time has been run.
     Supported controllers:
-    - [`heuristic_load_following_controller`](#heuristic-load-following-controller)
+    - [`HeuristicLoadFollowingController`](#heuristic-load-following-controller)

-Original file line number
+Diff line change
@@ Expand Up @@
     (pass-through-controller)=
     ### Pass-Through Controller
-    The `pass_through_controller` simply directly passes the input commodity flow to the output without any modifications. It is useful for testing, as a placeholder for more complex controllers, and for maintaining consistency between controlled and uncontrolled frameworks as this 'controller' does not alter the system output in any way.
+    The `PassThroughOpenLoopController` simply directly passes the input commodity flow to the output without any modifications. It is useful for testing, as a placeholder for more complex controllers, and for maintaining consistency between controlled and uncontrolled frameworks as this 'controller' does not alter the system output in any way.
-    For examples of how to use the `pass_through_controller` open-loop control framework, see the following:
+    For examples of how to use the `PassThroughOpenLoopController` open-loop control framework, see the following:
     - `examples/01_onshore_steel_mn`
     - `examples/02_texas_ammonia`
     - `examples/12_ammonia_synloop`
     (demand-open-loop-storage-controller)=
     ### Demand Open-Loop Storage Controller
-    The `demand_open_loop_storage_controller` uses simple logic to dispatch the storage technology when demand is higher than commodity generation and charges the storage technology when the commodity generation exceeds demand, both cases depending on the storage technology's state of charge. For the `demand_open_loop_storage_controller`, the storage state of charge is an estimate in the control logic and is not informed in any way by the storage technology performance model.
+    The `DemandOpenLoopStorageController` uses simple logic to dispatch the storage technology when demand is higher than commodity generation and charges the storage technology when the commodity generation exceeds demand, both cases depending on the storage technology's state of charge. For the `DemandOpenLoopStorageController`, the storage state of charge is an estimate in the control logic and is not informed in any way by the storage technology performance model.
     An example of an N2 diagram for a system using the open-loop control framework for hydrogen storage and dispatch is shown below ([click here for an interactive version](./figures/open-loop-n2.html)). Note that the hydrogen out going into the finance model is coming from the control component.
     ![](./figures/open-loop-n2.png)
-    For examples of how to use the `demand_open_loop_storage_controller` open-loop control framework, see the following:
+    For examples of how to use the `DemandOpenLoopStorageController` open-loop control framework, see the following:
     - `examples/14_wind_hydrogen_dispatch/`
     - `examples/19_simple_dispatch/`
@@ Expand All / @@ -37,7 +37,7 @@ This page documents two core controller types: @@
     (demand-open-loop-converter-controller)=
     ### Demand Open-Loop Converter Controller
-    The `demand_open_loop_converter_controller` allocates commodity input to meet a defined demand profile. It does not contain energy storage logic, only **instantaneous** matching of supply and demand.
+    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.)
@@ Expand All @@
     ```yaml
     control_strategy:
-        model: demand_open_loop_converter_controller
+        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 `demand_open_loop_converter_controller` open-loop control framework, see the following:
+    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 `flexible_demand_open_loop_converter_controller` 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:
+    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
@@ Expand All / @@ -81,7 +81,7 @@ The controller computes: @@
     Everything remains open-loop no storage, no intertemporal coupling.
-    For an example of how to use the `flexible_demand_open_loop_converter_controller` open-loop control framework, see the following:
+    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.
@@ Expand Down @@

-Original file line number
+Diff line change
@@ Expand Up @@
     (heuristic-load-following-controller)=
     ## Heuristic Load Following Controller
-    The pyomo control framework currently supports only a simple heuristic method, `heuristic_load_following_controller`, but we plan to extend the framework to be able to run a full dispatch optimization using a pyomo solver. When using the pyomo framework, a `dispatch_rule_set` for each technology connected to the storage technology must also be specified. These will typically be `pyomo_dispatch_generic_converter` for generating technologies, and `pyomo_dispatch_generic_storage` for storage technologies. More complex rule sets may be developed as needed.
+    The pyomo control framework currently supports only a simple heuristic method, `HeuristicLoadFollowingController`, but we plan to extend the framework to be able to run a full dispatch optimization using a pyomo solver. When using the pyomo framework, a `dispatch_rule_set` for each technology connected to the storage technology must also be specified. These will typically be `PyomoDispatchGenericConverter` for generating technologies, and `PyomoRuleStorageBaseclass` for storage technologies. More complex rule sets may be developed as needed.
-    For an example of how to use the pyomo control framework with the `heuristic_load_following_controller`, see
+    For an example of how to use the pyomo control framework with the `HeuristicLoadFollowingController`, see
     - `examples/18_pyomo_heuristic_wind_battery_dispatch`

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Enhancement: Convert `supported_models` to enforce actual class names #468

Uh oh!

Diff view

Diff view

There are no files selected for viewing

johnjasa Jan 30, 2026

Uh oh!

johnjasa Jan 30, 2026

Uh oh!

Uh oh!

-Original file line number
+Diff line change
@@ Expand Up @@
     from h2integrate.converters.solar.solar_pysam import PYSAMSolarPlantPerformanceComponent
     supported_models = {
-        "pysam_solar_plant_performance" : PYSAMSolarPlantPerformanceComponent,
+        "PYSAMSolarPlantPerformanceModel" : PYSAMSolarPlantPerformanceComponent,
-        "run_of_river_hydro_performance": RunOfRiverHydroPerformanceModel,
-        "run_of_river_hydro_cost": RunOfRiverHydroCostModel,
-        "eco_pem_electrolyzer_performance": ECOElectrolyzerPerformanceModel,
-        "singlitico_electrolyzer_cost": SingliticoCostModel,
-        "basic_electrolyzer_cost": BasicElectrolyzerCostModel,
-        "custom_electrolyzer_cost": CustomElectrolyzerCostModel,
+        "RunOfRiverHydroPerformanceModel": RunOfRiverHydroPerformanceModel,
+        "RunOfRiverHydroCostModel": RunOfRiverHydroCostModel,
+        "ECOElectrolyzerPerformanceModel": ECOElectrolyzerPerformanceModel,
+        "SingliticoCostModel": SingliticoCostModel,
+        "BasicElectrolyzerCostModel": BasicElectrolyzerCostModel,
+        "CustomElectrolyzerCostModel": CustomElectrolyzerCostModel,
         ...
     }
@@ Expand Down Expand Up @@
     For now, modify a single  the `create_technology_models.py` file to include your new technology as such:
     ```python
-    combined_performance_and_cost_model_technologies = ['hopp', 'h2_storage', '<your_tech_here>']
+    combined_performance_and_cost_model_technologies = ['HOPPComponent', 'h2_storage', '<your_tech_here>']
     # Create a technology group for each technology
     for tech_name, individual_tech_config in self.technology_config['technologies'].items():
@@ Expand Down @@

-Original file line number
+Diff line change
@@ Expand Up / @@ -3,7 +3,7 @@ @@
     The Production Financial Analysis Scenario Tool or (ProFAST)[https://www.nrel.gov/hydrogen/profast-access] is a financial modeling tool developed at the NREL based on General Accepted Accounting Principles (GAAP) methodology. The model provides a quick and convenient way to conduct in-depth financial analysis for production system and services.
     Currently there are two ProFAST models that can be used:
-    - [``ProFastComp``](profastcomp:profastcompmodel): A price-taker model that calculates levelized cost of commodity (or breakeven price) using [ProFAST](https://github.com/NREL/ProFAST).
+    - [``ProFastLCO``](profastcomp:profastcompmodel): A price-taker model that calculates levelized cost of commodity (or breakeven price) using [ProFAST](https://github.com/NREL/ProFAST).
     - [``ProFastNPV``](profastnpv:profastnpvmodel): A price-setter model that calculates the net present value of a commodity using [ProFAST](https://github.com/NREL/ProFAST).
     (profast:overview)=
@@ Expand All @@
     ```yaml
     finance_parameters:
-      finance_model: "ProFastComp" #finance model
+      finance_model: "ProFastLCO" #finance model
         model_inputs: #inputs for finance_model
           params: #Financing parameters
             analysis_start_year: 2032 #year that financial analysis starts
@@ Expand Down Expand Up @@
     ```yaml
     finance_parameters:
-      finance_model: "ProFastComp"
+      finance_model: "ProFastLCO"
       model_inputs:
         params: !include  "profast_params.yaml" #Finance information
         capital_items: #default parameters for capital items unless specified in tech_config
@@ Expand Down @@

-Original file line number
+Diff line change
@@ -1,14 +1,14 @@
     (profastcomp:profastcompmodel)=
     # ProFastComp
-    The `ProFastComp` finance model calculates levelized cost of a commodity using [ProFAST](https://github.com/NREL/ProFAST).
+    The `ProFastLCO` finance model calculates levelized cost of a commodity using [ProFAST](https://github.com/NREL/ProFAST).
-    The inputs, outputs, and naming convention for the `ProFastComp` model are outlined in this doc page.
+    The inputs, outputs, and naming convention for the `ProFastLCO` model are outlined in this doc page.
     (profastcomp:overview)=
     ## Finance parameters overview
-    The main inputs for `ProFastComp` model include:
+    The main inputs for `ProFastLCO` model include:
     - required: financial parameters (`params` section). These can be input in the `ProFastBase` format or the `ProFAST` format. These two formats are described in the following sections:
       - [ProFastBase format](profast:direct_opt)
       - [ProFAST format](profast:pf_params_opt)
@@ Expand All / @@ -17,7 +17,7 @@ The main inputs for `ProFastComp` model include: @@
     ```yaml
     finance_parameters:
-      finance_model: "ProFastComp"
+      finance_model: "ProFastLCO"
       model_inputs: #inputs for the finance_model
         save_profast_results: True #optional, will save ProFAST results to .yaml file in the folder specified in the driver_config (`driver_config["general"]["folder_output"]`)
         save_profast_config: True #optional, will save ProFAST the profast config to .yaml file in the folder specified in the driver_config (`driver_config["general"]["folder_output"]`)
@@ Expand All @@
     (profastcomp:outputs)=
     ## Output values and naming convention
-    ``ProFastComp`` outputs the following data following the naming convention detailed below:
+    ``ProFastLCO`` outputs the following data following the naming convention detailed below:
     - `LCO<x_and_descriptor>`: levelized cost of commodity in USD/commodity unit, e.g. `LCOH_produced` for hydrogen produced.
     - `wacc_<commodity_and_descriptor>`: weighted average cost of capital as a fraction.
     - `crf_<commodity_and_descriptor>`: capital recovery factor as a fraction.
@@ Expand Down @@

-Original file line number
+Diff line change
@@ Expand Up @@
     (finance:supportedmodels)=
     ## Currently supported general finance models
-    - [``ProFastComp``](profastcomp:profastcompmodel): calculates levelized cost of commodity using [ProFAST](https://github.com/NREL/ProFAST).
+    - [``ProFastLCO``](profastcomp:profastcompmodel): calculates levelized cost of commodity using [ProFAST](https://github.com/NREL/ProFAST).
     - [``ProFastNPV``](profastnpv:profastnpvmodel): calculates the net present value of a commodity using [ProFAST](https://github.com/NREL/ProFAST).
     - [``NumpyFinancialNPV``](numpyfinancialnpvfinance:numpyfinancialnpvmodel): calculates the net present value of a commodity using the [NumPy Financial npv](https://numpy.org/numpy-financial/latest/npv.html#numpy_financial.npv) method.
@@ Expand Down @@

-Original file line number
+Diff line change
@@ Expand Up / @@ -2,20 +2,20 @@ @@
     # Solar Resource: GOES PSM v4
     There are four datasets that use the [NSRDB GOES PSM v4 API](https://developer.nrel.gov/docs/solar/nsrdb/nsrdb-GOES-full-disc-v4-0-0-download/) calls:
-    - "goes_aggregated_solar_v4_api"
-    - "goes_conus_solar_v4_api"
-    - "goes_fulldisc_solar_v4_api"
-    - "goes_tmy_solar_v4_api"
+    - "GOESAggregatedSolarAPI"
+    - "GOESConusSolarAPI"
+    - "GOESFullDiscSolarAPI"
+    - "GOESTMYSolarAPI"
         - supports solar resource data for typical meteorological year (TMY), typical global horizontal irradiance year (TGY), and typical direct normal irradiance year (TDY)
     These datasets allow for resource data to be downloaded for **locations** within the continental United States.
     | Model      | Temporal resolution | Spatial resolution | Years covered | Regions | Website |
     | :--------- | :---------------: | :---------------: | :---------------: | :---------------: | :---------------: |
-    | `goes_aggregated_solar_v4_api`  | 30, 60 min  | 4 km | 1998-2024  | North America, South America | [GOES Aggregated](https://developer.nrel.gov/docs/solar/nsrdb/nsrdb-GOES-aggregated-v4-0-0-download/) |
-    | `goes_conus_solar_v4_api`  | 5, 15, 30, 60 min  | 2 km | 2018-2024  | Continental United States | [GOES Conus](https://developer.nrel.gov/docs/solar/nsrdb/nsrdb-GOES-conus-v4-0-0-download/) |
-    | `goes_fulldisc_solar_v4_api`  | 10, 30, 60 min  | 2 km | 2018-2024  | North America, South America |  [GOES Full disc](https://developer.nrel.gov/docs/solar/nsrdb/nsrdb-GOES-full-disc-v4-0-0-download/) |
-    | `goes_tmy_solar_v4_api`  | 60 min  | 4 km | 2022-2024, for tmy, tdy and tgy  | North America, South America |  [GOES TMY](https://developer.nrel.gov/docs/solar/nsrdb/nsrdb-GOES-tmy-v4-0-0-download/) |
+    | `GOESAggregatedSolarAPI`  | 30, 60 min  | 4 km | 1998-2024  | North America, South America | [GOES Aggregated](https://developer.nrel.gov/docs/solar/nsrdb/nsrdb-GOES-aggregated-v4-0-0-download/) |
+    | `GOESConusSolarAPI`  | 5, 15, 30, 60 min  | 2 km | 2018-2024  | Continental United States | [GOES Conus](https://developer.nrel.gov/docs/solar/nsrdb/nsrdb-GOES-conus-v4-0-0-download/) |
+    | `GOESFullDiscSolarAPI`  | 10, 30, 60 min  | 2 km | 2018-2024  | North America, South America |  [GOES Full disc](https://developer.nrel.gov/docs/solar/nsrdb/nsrdb-GOES-full-disc-v4-0-0-download/) |
+    | `GOESTMYSolarAPI`  | 60 min  | 4 km | 2022-2024, for tmy, tdy and tgy  | North America, South America |  [GOES TMY](https://developer.nrel.gov/docs/solar/nsrdb/nsrdb-GOES-tmy-v4-0-0-download/) |
     ```{note}
@@ Expand Down @@

Enhancement: Convert supported_models to enforce actual class names #468

Are you sure you want to change the base?

Uh oh!

Enhancement: Convert supported_models to enforce actual class names #468

Uh oh!

Uh oh!

Diff view

Diff view

There are no files selected for viewing

johnjasa Jan 30, 2026

Choose a reason for hiding this comment

Uh oh!

johnjasa Jan 30, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Enhancement: Convert `supported_models` to enforce actual class names #468

Enhancement: Convert `supported_models` to enforce actual class names #468