NatLabRockies · RHammond2 · Jan 21, 2026 · Jan 22, 2026 · Jan 22, 2026 · Jan 22, 2026
diff --git a/.gitignore b/.gitignore
@@ -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
 

diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -29,6 +29,9 @@
   - Remove unused dependencies.
   - Fixes typos for skipped folders.
   - Fixes missing dependencies for `gis` modifier used in new iron mapping tests.
+- 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.
 
 ## 0.5.1 [December 18, 2025]
 

diff --git a/docs/control/control_overview.md b/docs/control/control_overview.md
@@ -7,10 +7,10 @@ There are two different systematic approaches, or frameworks, in H2Integrate for
 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)=
@@ -20,4 +20,4 @@ The second systematic control approach, [pyomo control](#pyomo-control), allows
 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)
diff --git a/docs/control/open-loop_controllers.md b/docs/control/open-loop_controllers.md
@@ -8,22 +8,22 @@ The open-loop storage controllers can be attached as the control strategy in the
 
 (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/`
 
@@ -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.)
@@ -57,19 +57,19 @@ The controller is defined within the `tech_config` and requires these inputs.
 
 ```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
 
@@ -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.

diff --git a/docs/control/pyomo_controllers.md b/docs/control/pyomo_controllers.md
@@ -10,7 +10,7 @@ An example of an N2 diagram for a system using the pyomo control framework for h
 
 (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`
diff --git a/docs/developer_guide/adding_a_new_technology.md b/docs/developer_guide/adding_a_new_technology.md
@@ -165,14 +165,14 @@ Here's what the updated `supported_models.py` file looks like with our new solar
 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,
 
     ...
 }
@@ -228,7 +228,7 @@ If you're adding a technology where this makes sense, you can follow the same st
 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():

diff --git a/docs/finance_models/ProFastBase.md b/docs/finance_models/ProFastBase.md
@@ -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)=
@@ -22,7 +22,7 @@ Below is an example inputting financial parameters directly in the `finance_para
 
 ```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
@@ -77,7 +77,7 @@ Below is an example of the `finance_parameters` section of `plant_config` if usi
 
 ```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

diff --git a/docs/finance_models/ProFastComp.md b/docs/finance_models/ProFastComp.md
@@ -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)
@@ -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"]`)
@@ -40,7 +40,7 @@ If you are setting `save_profast_results` to `True` and are using multiple finan
 
 (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.

diff --git a/docs/finance_models/finance_index.md b/docs/finance_models/finance_index.md
@@ -18,7 +18,7 @@ The `commodity_type` and `description` are used in the finance model naming conv
 (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.
 

diff --git a/docs/resource/goes_solar_v4_api.md b/docs/resource/goes_solar_v4_api.md
@@ -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}