Enable load following optimization dispatch with Pyomo

[genevievestarke]

Bring Pyomo load following dispatch capabilities into H2I

This feature would enable dispatch optimization using one storage technology and multiple generation technologies (using the combiner) to determine optimal storage operation to follow a load while minimizing costs. This feature adds the optimization problem formulation, framework, and solver for the optimization in Pyomo. To do this, a hybrid_rule.py file was added to aggregate the storage and production variables to create one problem for the optimizer. The added files are

• OptimizedDispatchController class in pyomo_controllers.py
• The hybrid_rule.py file: Aggregates optimization pieces from the various components and formulates the model for the optimization. This file collects the objective function, initializes model parameters, and updates time series parameters.
• The generic_converter_opt.py file: Houses the variables, parameters, constraints, and objective function for the generator technology in the optimization model.
• The pyomo_storage_rule_min_operating_cost.py file: houses the storage and system variables, parameters, constraints, and objective function. Ideally the system parameters would be in a separate file, perhaps, but have been combined for efficiency in the first implementation.
• The controller_opt_problem_state.py file: Formulates the optimization model for the solver

The below is an example of how and where the dispatch is run using a battery for electricity storage:

What's changed?

For the optimized dispatch, the control and dispatch functions are no longer separate (see figure above). This also means that the controller needs access to the dispatch parameters. Now all dispatch and controller classes have access to the shared_parameters section in the input yaml, meaning that parameters like commodity_name that were defined in multiple places before should now be defined once in the shared_parameters section. This affects the pyomo heuristic dispatch, as well. Most control parameters are then defined in the shared_parameters, as well, because there is a large overlap with the performance variables. Control/dispatch specific variables can be defined in the control_parameters section. This include:

• cost_per_charge: in $/kW, cost to charge the storage (note that charging is incentivized)
• cost_per_discharge: in $/kW, cost to discharge the storage
• commodity_met_value: in $/kW, penalty for not meeting the desired load demand
• cost_per_production: in $/kW, cost to use the incoming produced commodity (i.e. electricity from wind)
• time_weighting_factor: This parameter discounts each subsequent time step incrementally in the future in the horizon window by the defined amount (defaults to 0.995)
• tech_name: Name that the technology will be defined as in the dispatch

Note that the tech_name variable must match with the names given in the tech_to_dispatch_connections in the plant_config file. TODO: should we eliminate the tech_name variable and make it the same as the defined technology name? Why is it different?

We have exposed the cost values to the user in this implementation, which was not the case for HOPP. This is good for visibility, but the weights are fussy. If your dispatch is taking an abnormally long time (or even longer than a minute), you should check to make sure your weights make sense, or change them to see if that makes a difference. Some rules of thumb and thoughts:

• You always want your commodity_met_value to be the largest because this is what drives meeting the load for load following
• You should not set cost_per_charge equal to cost_per_discharge. This will confuse the optimizer. In the objective function, charging the battery is incentivized and discharging is disincentivized, meaning that if they are the same value, they can cause the optimizer to oscillate the battery because they "cancel each other out" in value in the objective function. I usually set cost_per_charge a little bit less than cost_per_discharge to not discourage charging the battery instead of meeting the load by discharging.
• I view cost_per_production as not that important if the energy is already produced (i.e. from wind for example). I tend to set this to 0 to not discourage charging the battery
• I have been setting cost_per_charge and cost_per_discharge two orders of magnitude lower than commodity_met_value so that the charging the discharging of the battery don't interfere with the load very much. You can put them closer together, but it will increase the time that the optimization takes.
• These weights are defined as "$/kW", which is a weird unit. I defined them this way because pyomo is based on dollars and inputs to H2I are in kilowatts. I think it may be better to choose either $/MW or cents/kW and then convert internally, as these are more established cost measures and people have better intuition about what these number mean.

This pull request does not enable the optimal dispatch of a storage technology that can charge from the grid. This implementation currently only involves incoming electricity from upstream (that could be bought using grid component). It also only allows one incoming electricity stream and does not apply optimal dispatch of that stream back through the upstream technologies (no feedback). The dispatch can handle more than one generation technology, but the incoming electricity must be combined using an H2I combiner before going to the storage component, and the cost_per_production, which is defined in the storage technology section, needs to include the cost of production for all production technologies. This could be done using the following:

technology_interconnections: [
  ["wind", "combiner", "electricity", "cable"],
  ["solar", "combiner", "electricity", "cable"],
  ["combiner", "battery", "electricity", "cable"],
]

tech_to_dispatch_connections: [
  ["combiner", "battery"],
  ["battery", "battery"],

The demand is also still set externally after the setup step. Ideally, the dispatch will be integrated with the load demand framework that already exists in H2I, and the demand can be defined that way.

# Define demand signal
demand_profile = np.ones(8760) * 100.0

# Model setup
model.setup()
# Set demand signal directly on the battery technology
model.prob.set_val("battery.electricity_demand", demand_profile, units="MW")

# Run the model
model.run()

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:

• Get general feedback on framework of added pyomo pieces
• Apply any framework feedback and update code so that heuristic dispatch works as expected
• Update example to accurately describe run
• Update doc strings in methods
• Write tests for new pyomo optimization
• Make docs page?
• Maybe: address where dispatch inputs should live for generator technologies
• Maybe: make an example with multiple generation technologies, using the combiner to connect to dispatch

Type of Reviewer Feedback Requested (on Draft PR)

Structural feedback:
This dispatch model differs significantly from the heuristic block formulation in H2I. The dispatch for the generation + storage system is aggregated in hybrid_rule.py, which pulls from generic_converter_opt.py and pyomo_storage_rule_min_operating_cost.py, all three of which are classes, and thus outside of the OpenMDAO input/output framework. This was implemented because the previous dispatch_rule framework was difficult to aggregate in the way that was needed to formulate the optimization problem. I would like feedback on this structure, and whether we could make it more OpenMDAO-friendly.

Implementation feedback:

Other feedback:
The inputs to the dispatch are all defined in the storage technology config, including the cost_per_production term, which describes the cost of the production technologies. I think this should be defined under the production technologies in the config, so any feedback on how to pull this into the battery dispatch would be appreciated!

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

This resolves #386

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

Section 6: Test Results, if applicable

Section 7 (Optional): New Model Checklist

• Model Structure:
  • Follows established naming conventions outlined in docs/developer_guide/coding_guidelines.md
  • Used attrs class to define the Config to load in attributes for the model
    • If applicable: inherit from BaseConfig or CostModelBaseConfig
  • Added: initialize() method, setup() method, compute() method
    • If applicable: inherit from CostModelBaseClass
• Integration: Model has been properly integrated into H2Integrate
  • Added to supported_models.py
  • If a new commodity_type is added, update create_financial_model in h2integrate_model.py
• Tests: Unit tests have been added for the new model
  • Pytest-style unit tests
  • Unit tests are in a "test" folder within the folder a new model was added to
  • If applicable add integration tests
• Example: If applicable, a working example demonstrating the new model has been created
  • Input file comments
  • Run file comments
  • Example has been tested and runs successfully in test_all_examples.py
• Documentation:
  • Write docstrings using the Google style
  • Model added to the main models list in docs/user_guide/model_overview.md
    • Model documentation page added to the appropriate docs/ section
    • <model_name>.md is added to the _toc.yml

[genevievestarke]

This pull request is ready for an overall framework review!