Standardize performance model outputs

[elenya-grant]

Standardize performance model outputs

Introducing a baseclass for performance models to standardize outputs. The standardized outputs are:

• commodity_out in units of commodity_rate_units: commodity output profile of length n_timesteps
• total_commodity_produced in units of commodity_amount_units: sum of commodity produced over simulation (adjusted for timestep if necessary)
• annual_commodity_produced in units of commodity_amount_units/yr: annual commodity production adjusted for a year-long simulation, shape is equal to plant_life.
• replacement_schedule in units of unitless: the percent of the capacity that is replaced per year. Defaults to an array of zeros of length plant_life.
• capacity_factor in units of unitless: the capacity factor of a system as a fraction. Has a shape equal to plant_life.
• rated_commodity_production in units of commodity_rate_units: rated production capacity of the converter. Used to calculate capacity_factor
• operational_life in units of yr: operational life of the technology, defaults to plant life. Tentatively planning on adding it in.

The attributes that each performance model needs to define prior to calling the setup() method in the PerformanceModelBaseClass are: commodity, commodity_rate_units and commodity_amount_units. For example, the wind performance models in the setup method would do:

class WindPerformanceBaseClass(PerformanceModelBaseClass):
    def setup(self):
        self.commodity = "electricity"
        self.commodity_rate_units = "kW"
        self.commodity_amount_units = "kW*h"
        super().setup()

An electrolyzer performance model would do:

class ElectrolyzerPerformanceBaseClass(PerformanceModelBaseClass):
    def setup(self):
        self.commodity = "hydrogen"
        self.commodity_rate_units = "kg/h"
        self.commodity_amount_units = "kg"
        super().setup()

This would resolve some issues around hard-coded tech-specific logic in H2IntegrateModel and the profast finance models, and issues relating to unit convention for varying simulation lengths or timesteps. Changes to the wind, solar, water power, and electrolyzer converters have already been done and can be reviewed now for reviewers to provide high-level feedback.

Benefits of this PR are:

• standardized output naming can reduce tech-specific hard-coded logic in H2IntegrateModel, finance models, etc
• standardized output naming may also reduce the number of places in the code that a new commodity type has to be added when a tech with a new commodity type is added
• standardized usage of rate units vs amount units

Section 1: Type of Contribution

• Feature Enhancement
  • Framework
  • New Model
  • Updated Model
  • Tools/Utilities
  • Other (please describe):
• Bug Fix
• Documentation Update
• CI Changes
• Other (please describe):

Section 2: Draft PR Checklist

• Open draft PR
• Describe the feature that will be added
• Fill out TODO list steps
• Describe requested feedback from reviewers on draft PR
• Complete Section 7: New Model Checklist (if applicable)

TODO:

• Update/add outputs to converter models

  • wind (elenya)
  • solar (elenya)
  • water_power (elenya)
  • ammonia
  • co2
  • grid
  • hopp (elenya)
  • hydrogen (electrolyzer) (elenya)
  • hydrogen (geologic) (Kaitlin)
  • iron (elenya)
  • methanol (Kaitlin)
  • natural gas (elenya)
  • steel (Kaitlin)
  • water?
  • paper mill in Example 6

• Update/add outputs to storage models

  • hydrogen
  • battery

• Update/add outputs to feedstock model and fix units (elenya)

• Update combiners and splitters (as necessary)

• Update ProFAST finance models to use capacity factor as utilization and rated_commodity_production as capacity

• Update AdjustedCapexOpexComp if needed.

• Update/fix tests as needed

• Update post-processing functions as necessary (elenya)

• Update documentation on adding a new technology

Type of Reviewer Feedback Requested (on Draft PR)

Structural feedback:

• thoughts on standardized output naming convention?

Implementation feedback:

• Changes to the wind, solar, water power, and electrolyzer converters have already been done and can be reviewed now for reviewers to provide high-level feedback.

Other feedback:

• do we want to assume a year is 8760 hours or use what OpenMDAO assumes is a year (8765.812776 hours/year)?

Section 3: General PR Checklist

• PR description thoroughly describes the new feature, bug fix, etc.
• Added tests for new functionality or bug fixes
• Tests pass (If not, and this is expected, please elaborate in the Section 6: Test Results)
• 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)
• CHANGELOG.md has been updated to describe the changes made in this PR

Section 3: Related Issues

Units for varying timesteps and simulation lengths: Issue #244, #204, and #387 (may be partially resolved with this PR)
Standardized naming conventions: Issue #223 (this would be partially resolved with this PR)
Remove dependence on name of the technologies in H2I: Issue #374 (would be partially/fully resolved in this PR)
Issue about converter baseclass (somewhat related): Issue #231

Section 4: Impacted Areas of the Software

Section 4.1: New Files

• path/to/file.extension
  • method1: What and why something was changed in one sentence or less.

Section 4.2: Modified Files

• path/to/file.extension
  • method1: What and why something was changed in one sentence or less.

Section 5: Additional Supporting Information

Future development (in other PRs) that could build on this framework are:

• standardize outputs for techs that produce multiple commodities
• standardize inputs and outputs for techs that require/use feedstocks

Section 6: Test Results, if applicable

[RHammond2]

I like the idea of enforcing that some of these parameters need to exist to simplify setup and later usage, but there should be an actual enforcement method that requires the commodity, commodity_rate_units, commodity_amount_units, and the later to-be-determined attribues to be defined. Without an actual enforcement it will let the error crop up in a likely confusing place once it's been long enough since this feature has been implemented.

Something along these lines would likely work to avoid getting too fancy with Python's abstract base classes. i would definitely make the error message a bit more descriptive during implementation, but this keeps it to a single line for this example.

class PerformanceModelBaseClass():  # will need om.ExplicitComponent, but am skipping for the sake of a replicable example
    def __new__(cls, *args, **kwargs):
        required = ("commodity", "commodity_rate_units", "commodity_amount_units")
        missing = [el for el in required if not hasattr(cls, el)]
        if missing:
            missing = ", ".join(missing)
            raise NotImplementedError(f"{cls.__name__} missing the following attributes: {missing}")
        return super().__new__(cls)

In this case, we could define the following two sample subclasses.

class WindPerformanceBaseClass(PerformanceModelBaseClass):
    commodity = "electricity"

class OtherPerformanceBaseClass(PerformanceModelBaseClass):
    commodity = "electricity"
    commodity_rate_units = "kwh"
    commodity_amount_units = "kw"

When called, OtherPerformaceBaseClass() will successfully initialize, but when attempting to create an instance of WindPerformanceBaseClass, you'll be met with the error.

NotImplementedError: WindPerformanceBaseClass missing the following attributes: commodity_rate_units, commodity_amount_units

The only catch is that if base classes themselves aren't tested for basic setup, then this will cascade to the class being instantiated.

class Wind(WindPerformanceBaseClass):
    def __init__():
        pass

>>> Wind()
NotImplementedError: Wind missing the following attributes: commodity_rate_units, commodity_amount_units