Demonstrating different sizing modes with H2 electrolyzer

[jmartin4u]

Utilizing Sizing Modes with Resizeable Converters

When the size of one converter is changed, it may be desirable to have other converters in the plant resized to match.
This can be done manually by setting the sizes of each converter in the tech_config, but it can also be done automatically with resizeable converters.
Resizeable converters can execute their own built-in sizing methods based on how much of a feedstock can be produced upstream, or how much of a commodity can be offtaken downstream by other converters.
By connecting the capacities of converters to other converters, one can build a logical re-sizing scheme for a multi-technology plant that will resize all converters by changing just one config parameter.

Setting up a resizeable converter

To set up a resizeable converter, take advantage of the ResizeablePerformanceModelBaseConfig and ResizeablePerformanceModelBaseClass.
The ResizeablePerformanceModelBaseConfig will declare a sizing performance parameter within the the tech_config, which is a dict that specifies the sizing mode.
The ResizeablePerformanceModelBaseClass will automatically parse this dict into the inputs and discrete_inputs that the performance model will need for resizing.
Here is the start of an example tech_config for such a converter:

tech_config = {
    "model_inputs": {
        "shared_parameters": {
            "production_capacity": 1000.0,
        },
        "performance_parameters": {
            "sizing": {
                "size_mode": "normal",  # Always required
                "flow_used_for_sizing": "electricity",  # Not required in "normal" mode
                "max_feedstock_ratio": 1.6,  # Only used in "resize_by_max_feedstock"
                "max_commodity_ratio": 0.7,  # Only used in "resize_by_max_commodity"
            },
        },
    }
}

Currently, there are three different modes defined for size_mode:

• normal: In this mode, converters function as they always have previously:
  • The size of the asset is fixed within compute().
• resize_by_max_feedstock: In this mode, the size of the converter is adjusted to be able to utilize all of the available feedstock:
  • The size of the asset should be calculated within compute() as a function of the maximum value of <feedstock>_in - with the <feedstock> specified by the flow_used_for_sizing parameter.
  • This function will utilizes the "max_feedstock_ratio" parameter - e.g., if "max_feedstock_ratio" is 1.6, the converter will be resized so that its input capacity is 1.6 times the max of <feedstock>_in.
  • The set_val method will over-write any previous sizing varaibles to reflect the adjusted size of the converter.
• resize_by_max_commodity: In this mode, the size of the asset is adjusted to be able to supply its product to the full capacity of another downstream converter:
  • The size of the asset should be calculated within compute() as a function of the max_<commodity>_capacity input - with the <feedstock> specified by the resize by flow parameter.
  • This function will utilizes the "max_commodity_ratio" parameter - e.g., if "max_commodity_ratio" is 0.7, the converter will be resized so that its output capacity is 0.7 times a connected "max_<commodity>_capacity" input.
  • The set_val method will over-write any previous sizing varaibles to reflect the adjusted size of the converter.

To construct a resizeable converter from an existing converter, very few changes must be made, and only to the performance model.
ResizeablePerformanceModelBaseConfig can replace BaseConfig and ResizeablePerformanceModelBaseClass can replace om.ExplicitComponent.
The setup function must be modified to include any "max_<feedstock>_capacity" outputs or "max_<commodity>_capacity" inputs that can be connected to do the resizing.
Then, any feedstock_sizing_function or feedstock_sizing_function that the converter needs to resize itself should be defined, if not already.
Finally, the compute method should be modified (near the start, before any size-based calculations occur) to modify the size with these functions:

import numpy as np
from h2integrate.core.utilities import ResizeablePerformanceModelBaseConfig, merge_shared_inputs
from h2integrate.core.model_baseclasses import ResizeablePerformanceModelBaseClass


class TechPerformanceModelConfig(ResizeablePerformanceModelBaseConfig):
    # Declare tech-specific config parameters
    size: float = 1.0


class TechPerformanceModel(ResizeablePerformanceModelBaseClass):
    def setup(self):
        self.config = TechPerformanceModelConfig.from_dict(
            merge_shared_inputs(self.options["tech_config"]["model_inputs"], "performance"),
            strict=False,
        )
        super().setup()

        # Declare tech-specific inputs and outputs
        self.add_input("size", val=self.config.size, units="unitless")
        # Declare any commodities produced that need to be connected to downstream converters
        # if this converter is in `resize_by_max_commodity` mode
        self.add_input("max_<commodity>_capacity", val=1000.0, units="kg/h")
        # Any feedstocks consumed that need to be connected to upstream converters
        # if those converters are in `resize_by_max_commodity` mode
        self.add_output("max_<feedstock>_capacity", val=1000.0, units="kg/h")

    def feedstock_sizing_function(max_feedstock):
        max_feedstock * 0.1231289  # random number for example

    def commodity_sizing_function(max_commodity):
        max_commodity * 0.4651  # random number for example

    def compute(self, inputs, outputs, discrete_inputs, discrete_outputs):
        size_mode = discrete_inputs["size_mode"]

        # Make changes to computation based on sizing_mode:
        if size_mode != "normal":
            size = inputs["size"]
            if size_mode == "resize_by_max_feedstock":
                if inputs["flow_used_for_sizing"] == "<feedstock>":
                    feed_ratio = inputs["max_feedstock_ratio"]
                    size_for_max_feed = self.feedstock_sizing_function(
                        np.max(inputs["<feedstock>_in"])
                    )
                    size = size_for_max_feed * feed_ratio
            elif size_mode == "resize_by_max_commodity":
                if inputs["flow_used_for_sizing"] == "<commodity>":
                    comm_ratio = inputs["max_commodity_ratio"]
                    size_for_max_comm = self.commodity_sizing_function(
                        np.max(inputs["max_<commodity>_capacity"])
                    )
                    size = size_for_max_comm * comm_ratio
            self.set_val("size", size)

Example plant setup

An example plant with resizeable technologies is set up in examples/22_sizing_modes/.
Follow the examples in run_size_modes.ipynb to see how they work.
Here, there are three technologies in the the tech_config.yaml:

1. A hopp plant producing electricity,
2. An electrolyzer producing hydrogen from that electricity, and
3. An ammonia plant producting ammonia from that hydrogen.

The electrolyzer and ammonia technologies are resizeable.
They are set up in "normal" mode in the tech_config.

technologies:
  hopp:
    model_inputs:
      performance_parameters:
        sizing:
          size_mode: "normal"
  electrolyzer:
    model_inputs:
      performance_parameters:
        sizing:
          size_mode: "normal"
  ammonia:
    model_inputs:
      performance_parameters:
        sizing:
          size_mode: "normal"

The technology_interconnections in the plant_config is set up to send electricity from the wind plant to the electrolyzer, then hydrogen from the electrolyzer to the ammonia plant.
There is also an entry to send the max_hydrogen_capacity from the ammonia plant to the electrolyzer, which will be required only in the resize_by_max_commodity mode.
Note: this creates a feedback loop within the OpenMDAO problem, which requires an iterative solver.

technology_interconnections: [
    ['hopp', 'electrolyzer', 'electricity', 'cable']
    ['electrolyzer', 'ammonia', 'hydrogen', 'pipe']
    ['ammonia', 'electrolyzer', 'max_hydrogen_capacity']
]

resize_by_max_feedstock mode

In this case, the electrolyzer will be sized to match the maximum electricity_in coming from HOPP.
This increases the electrolyzer size to 1080 MW, the closest multiple of 40 MW (the cluster size) matching the max HOPP power output of 1048 MW.

technologies:
  hopp:
    model_inputs:
      performance_parameters:
        sizing:
          size_mode: "normal"
  electrolyzer:
    model_inputs:
      performance_parameters:
        sizing:
          size_mode: "size_by_max_feedstock"
          flow_used_for_sizing: "electricity"
          max_feedstock_ratio: 1.0
  ammonia:
    model_inputs:
      performance_parameters:
        sizing:
          size_mode: "normal"

resize_by_max_product mode

In this case, the electrolyzer will be sized to match the maximum hydrogen capacity of the ammonia plant.
This requires the technology_interconnections entry to send the max_hydrogen_capacity from the ammonia plant to the electrolyzer.
This decreases the electrolyzer size to 560 MW, the closest multiple of 40 MW (the cluster size) that will ensure an h2 produciton capacity that matches the ammonia plant's h2 intake at its max ammonia produciton capacity.

technologies:
  hopp:
    model_inputs:
      performance_parameters:
        sizing:
          size_mode: "normal"
  electrolyzer:
    model_inputs:
      performance_parameters:
        sizing:
          size_mode: "size_by_max_commodity"
          flow_used_for_sizing: "hydrogen"
          max_commodity_ratio: 1.0
  ammonia:
    model_inputs:
      performance_parameters:
        sizing:
          size_mode: "normal"

Using optimizer with multiple connections

With both electrolyzer and ammonia in size_by_max_feedstock mode, the COBYLA optimizer can co-optimize their max_feedstock_ratio variables to minimize the LCOA. This is achieved at a capacity factor of approximately 55% in both the electrolyzer and the ammonia plant.

In the tech_config:

technologies:
  hopp:
    model_inputs:
      performance_parameters:
        sizing:
          size_mode: "normal"
  electrolyzer:
    model_inputs:
      performance_parameters:
        sizing:
          size_mode: "size_by_max_feedstock"
          flow_used_for_sizing: "electricity"
          max_feedstock_ratio: 1.0
  ammonia:
    model_inputs:
      performance_parameters:
        sizing:
          size_mode: "size_by_max_feedstock"
          flow_used_for_sizing: "hydrogen"
          max_feedstock_ratio: 1.0

And in the driver_config:

driver:
  optimization:
    flag: True
    solver: COBYLA
    tol: 0.01
    catol: 15000
    max_iter: 100
    rhobeg: 0.1
    debug_print: True

design_variables:
  electrolyzer:
    max_feedstock_ratio:
      flag: True
      lower: 0.1
      upper: 10.
      units: unitless
  ammonia:
    max_feedstock_ratio:
      flag: True
      lower: 0.1
      upper: 10.
      units: unitless

objective:
  name: finance_subgroup_nh3.LCOA

End output from COBYLA:

Driver debug print for iter coord: rank0:ScipyOptimize_COBYLA|15
----------------------------------------------------------------
Design Vars
{'ammonia.max_feedstock_ratio': array([1.00961083]),
 'electrolyzer.max_feedstock_ratio': array([0.79723742])}

Nonlinear constraints
None

Linear constraints
None

Objectives
{'finance_subgroup_nh3.LCOA': array([1.19535981])}

Optimization Complete
-----------------------------------

Type of Contribution

• Feature Enhancement
  • New Technology Model
• Bug Fix
• Documentation Update
• CI Changes
• Other (please describe):

General PR Checklist

• CHANGELOG.md has been updated to describe the changes made in this PR
• Documentation
  • Docstrings are up-to-date
  • Related docs/ files are up-to-date, or added when necessary
  • Documentation has been rebuilt successfully
  • Examples have been updated (if applicable)
• Tests pass (If not, and this is expected, please elaborate in the tests section)
• Added tests for new functionality or bug fixes
• PR description thoroughly describes the new feature, bug fix, etc.

Related issues

#183

Impacted areas of the software

Key changes:

• examples/24_sizing_modes/: This is an example folder containing a notebook run_size_modes.ipynb that runs through all the different modes
  • This notebook has also been connected as a docs page in the `_toc.yml'
• h2integrate/core/h2integrate_model.py: Added check for loops and assignment of linear/nonlinear solvers
• h2integrate/core/utilities.py: Added the ResizeablePerformanceModelBaseConfig class
• h2integrate/core/model_baseclasses.py: Added the ResizeablePerformanceModelBaseClass class
• h2integrate/converters/hydrogen/electrolyzer_baseclass.py: Updated to use the 3 sizing modes
• h2integrate/converters/hydrogen/eco_tools_pem_electrolyzer.py: Updated to use the 3 sizing modes

Necessary changes made elsewhere:

• h2integrate/converters/hydrogen/wombat_model.py: Updated to have discrete_inputs and discrete_outputs in super().compute()
• `h2integrate/converters/hydrogen/test/': Added tests for electrolyzer size modes
• h2integrate/converters/ammonia/ammonia_synloop.py: Updated to use the first 2 sizing modes
• `h2integrate/converters/ammonia/test/': Added test for ammonia size modes
• All examples using the eco_tools_pem_electrolyzer and ammonia_synloop: Updated performance parameters to have size_mode: "normal" (No effect on performance)
• Changed some default values from 0 to -1 to prevent linear algebra errors when iterative solver is active:
  • h2integrate/storage/hydrogen/pem_electrolyzer.py
  • h2integrate/transporters/cable.py
  • h2integrate/transporters/pipe.py
  • h2integrate/finances/profast_base.py
    • Previously, there was a check for capacity being equal to 0.0 that was used to unsure that total production was connected, so a require_connection = True was added in its place
    • As a result, corrective changes were made to tests that did not connect total production:
      • `h2integrate/finances/test/test_finances.py
      • `h2integrate/finances/test/test_profast_finance.py
      • `h2integrate/finances/test/test_profast_npv.py

Additional supporting information

Test results, if applicable

Tests passing

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[johnjasa]

Overall, I really like this PR. The amount of effort and planning you put into this is palpable, thank you @jmartin4nrel! I generally like the approach you've suggested here and would support it in H2I. I have some pretty in-the-weeds questions or suggestions, but nothing roadblocking at all.

Understanding the different implementations of sizing technologies is a potentially difficult task for users, so I want to take special consideration for the naming scheme. I have a few questions here that I'd love your take on:

• My biggest question or point I want to discuss is the naming introduced here, specifically on compute_mode, normal, feedstock_size, and product_size. Because these would be very user-facing and repeated throughout the code, I want to make sure they're abundantly clear.
  • First, would sizing_mode be more descriptive than compute_mode? I want to find something a bit more clear.
  • What about size_by_feedstock and size_by_product instead of what's there? Should normal be size_by_capacity or size_by_config or something else then?
• Should there a default compute_mode? Should this vary model to model? With one of the modes being called normal it intuitively feels like it should be the default
• I do like having both buy and sell price in the config, it took me a sec to reason out if we need both of them but I think the explicitness is good
• Nitpick: On the slides, like on slide 4, and we have "ignored" inputs and outputs, what does this mean in the code? Will those parameters appear in the n2 in OpenMDAO or are they not instantiated at all? Looking at the code, it looks like they don't get initialized at all. If so, I'd suggest a different word than "ignored", more like "not initialized" or similar. I'm probably overthinking this.
• How do we enforce that connected upstream converters must also be in product_size mode? I guess we could add pretty reasonable checking at the h2integrate_model.py level
• Does it make sense, with this amount of potential boilerplate, to have performance base classes and cost base classes? Would it simplify the flow of creating converters that operate in these different modes?

[johnjasa]

I like this approach. At first I was going to advocate for having the file existing be optional so the profile could also be passed in as an OpenMDAO array instead of reading from a file, but that seems unnecessarily complex at this stage. No changes needed!

[elenya-grant]

I think this could be kinda important for the ammonia/ASU interaction or ammonia/electrolyzer interaction. I think it'd be hard to figure out exactly but I think that I'd more often expect the product demand profile to come from another technology as an output rather than being read from a file. I might be missing something though.

[johnjasa]

naming: sell_price up here and buy_price in the compute

[johnjasa]

I'm not sure what you mean by "The product_profile will simply act as an "end cap"" -- could you maybe rephrase or clarify? Is it essentially a "sink" for an outputted commodity? I bet as I dig more into the code this will be more clear.

Reply via ReviewNB

[jaredthomas68]

Comment on naming:

• general: more explicit names to avoid confusion

• mode: I think names like "technology_sizing_mode" would be more clear

• mode name suggestions:

  • size_technology_by_feedstock
  • size_technology_by_output_demand
  • size_technology_by_config_inputs

[elenya-grant]

I think profile should be able to be input as any of the following options:

• str: filepath to timeseries profile (may be useful for users to specify the column name to use)
• pathlib.Path: filepath to timeseries profile (may be useful for users to specify the column name to use)
• list or array: time series profile
• int or float: constant demand value at each timestep that can be converted into a timeseries
• input from other technology

[elenya-grant]

this should be outputs["electricity_consume"] = power_to_electrolyzer_kw or
outputs["electricity_consume"] = h2_ts["Power Consumed [kWh]"]

[johnjasa]

Thanks for this, Jonathan! I pushed up some changes directly, we talked about the PR we brought in, and I feel great about this work.

I asked Elenya if I could merge this in and she said "oh yes sure thing"