h2integrate.core.h2integrate_model#

Classes

H2IntegrateModel(config_input)

class h2integrate.core.h2integrate_model.H2IntegrateModel(config_input)#
_load_component_config(config_key, config_value, config_path, validator_func)#

Helper method to load and validate a component configuration.

Parameters:
  • config_key (str) -- Key name for the configuration (e.g., "driver_config")

  • config_value (dict | str) -- Configuration value from main config

  • config_path (Path | None) -- Path to main config file (None if dict)

  • validator_func (callable) -- Validation function to apply

Returns:

tuple --

(validated_config, config_file_path, parent_path)
  • validated_config: Validated configuration dictionary

  • config_file_path: Path to config file (None if dict)

  • parent_path: Parent directory of config file (None if dict)

load_config(config_input)#

Load and validate configuration files for the H2I model.

This method loads the main configuration and the three component configuration files (driver, technology, and plant configurations). Each configuration can be provided either as a dictionary object or as a filepath. When filepaths are provided, the method resolves them using multiple search strategies.

Parameters:

config_input (dict | str | Path) -- Main configuration containing references to driver, technology, and plant configurations. Can be: - A dictionary containing the configuration data directly - A string or Path object pointing to a YAML file containing the configuration

Behavior:
  • If config_input is a dict: Uses it directly as the main configuration

  • If config_input is a path: Uses get_path() to resolve and load the YAML file from multiple search locations (absolute path, relative to CWD, relative to H2Integrate package)

For each component config (driver_config, technology_config, plant_config): - If the config value is a dict: Validates it directly using the appropriate

validation function (load_driver_yaml, load_tech_yaml, load_plant_yaml)

  • If the config value is a path string:
    • When main config was loaded from file: Uses find_file() to search relative to the main config file's directory first, then falls back to other search locations (CWD, H2Integrate package, glob patterns)

    • When main config was provided as dict: Uses get_path() with standard search strategy (absolute, relative to CWD, relative to H2Integrate package)

Sets:

self.name (str): Name of the system from main config self.system_summary (str): Summary description from main config self.driver_config (dict): Validated driver configuration self.technology_config (dict): Validated technology configuration self.plant_config (dict): Validated plant configuration self.driver_config_path (Path | None): Path to driver config file (None if dict) self.tech_config_path (Path | None): Path to technology config file (None if dict) self.plant_config_path (Path | None): Path to plant config file (None if dict) self.tech_parent_path (Path | None): Parent directory of technology config file self.plant_parent_path (Path | None): Parent directory of plant config file

Note

The parent path attributes (tech_parent_path, plant_parent_path) are used later for resolving relative paths to custom models and other referenced files within the technology and plant configurations.

Example

>>> # Using filepaths
>>> model = H2IntegrateModel("main_config.yaml")
>>> # Using mixed dict and filepaths
>>> config = {
...     "name": "my_system",
...     "driver_config": "driver.yaml",
...     "technology_config": {"technologies": {...}},
...     "plant_config": "plant.yaml",
... }
>>> model = H2IntegrateModel(config)
create_custom_models(model_config, config_parent_path, model_types, prefix='')#

This method loads custom models from the specified directory and adds them to the supported models dictionary.

Parameters:
  • model_config (dict) -- dictionary containing models, such as technology_config["technologies"]

  • config_parent_path (Path) -- parent path of the input file that model_config comes from. Should either be plant_config_path.parent or tech_config_path.parent

  • model_types (list[str]) -- list of keynames to search for in model_config.values(). Should be ["performance_model", "cost_model", "financial_model"] if model_config is technology_config["technologies"].

  • prefix (str, optional) -- Prefix of "model_class_name", "model_location" and "model". Defaults to "". Should be "finance_" if looking for custom general finance models.

collect_custom_models()#

Collect custom models from the technology configuration and general finance models found in the plant configuration.

create_site_model()#
create_plant_model()#

Create the plant-level model.

This method creates an OpenMDAO group that contains all the technologies. It uses the plant configuration but not the driver or technology configuration.

Information at this level might be used by any technology and info stored here is the same for each technology. This includes site information, project parameters, control strategy, and finance parameters.

create_technology_models()#
_process_model(model_type, individual_tech_config, tech_group)#
create_finance_model()#

Create and configure the finance model(s) for the plant.

This method initializes finance subsystems for the plant based on the configuration provided in self.plant_config["finance_parameters"]. It supports both default (single-model) setups and multiple/distinct (subgroup-specific) finance models.

Within this framework, a finance subgroup serves as a flexible grouping mechanism for calculating finance metrics across different subsets of technologies. These groupings can draw on varying finance inputs or models within the same simulation. To support a wide range of use cases, such as evaluating metrics for only part of a larger system, finance subgroups may reference multiple finance_groups and may overlap partially or fully with the technologies included in other finance subgroups.

Behavior:
  • If finance_parameters is not defined in the plant configuration,

no finance model is created. * If no subgroups are defined, all technologies are grouped together under a default finance group. commodity and finance_model are required in this case. * If subgroups are provided, each subgroup defines its own set of technologies, associated commodity, and finance model(s). Each subgroup is nested under a unique name of your choice under ["finance_parameters"]["subgroups"] in the plant configuration. * Subsystems such as ElectricitySumComp, AdjustedCapexOpexComp, GenericProductionSummerPerformanceModel, and the selected finance models are added to each subgroup's finance group. * If commodity_stream is provided for a subgroup, the output of the technology specified as the commodity_stream must be the same as the specified commodity for that subgroup. * Supports both global finance models and technology-specific finance models. Technology-specific finance models are defined in the technology configuration.

Raises:
  • ValueError -- If ["finance_parameters"]["finance_group"] is incomplete (e.g., missing commodity or finance_model) when no subgroups are defined.

  • ValueError -- If a subgroup has an invalid technology.

  • ValueError -- If a specified finance model is not found in self.supported_models.

Side Effects:
  • Updates ``self.plant_config["finance_parameters"]["finance_group"] if only a single

finance model is provided (wraps it in a default finance subgroup). * Constructs and attaches OpenMDAO finance subsystem groups to the plant model under names finance_subgroup_<subgroup_name>. * Stores processed subgroup configurations in self.finance_subgroups.

Example

Suppose plant_config["finance_parameters"]["finance_group"] defines a single finance model without subgroups:

>>> self.plant_config["finance_parameters"]["finance_group"] = {
...     "commodity": "hydrogen",
...     "finance_model": "ProFastComp",
...     "model_inputs": {"discount_rate": 0.08},
... }
>>> self.create_finance_model()
# Creates a default subgroup containing all technologies and
# attaches a ProFAST finance model component to the plant.
connect_technologies()#
create_driver_model()#

Add the driver to the OpenMDAO model and add recorder.

setup()#

Extremely light wrapper to setup the OpenMDAO problem and track setup status.

run()#
post_process(summarize_sql=False, show_plots=False)#

Post-process the results of the OpenMDAO model.

Right now, this means printing the inputs and outputs to all systems in the model. We currently exclude any variables with "resource_data" in the name, since those are large dictionary variables that are not correctly formatted when printing.

If summarize_sql is set to True and a recorder file was written, the results in the recorder file will be summarized and saved as a .csv file.

Also, if show_plots is set to True, then any performance models with post-processing plots available will be run and shown.