Bugfix on storage so storage can't charge with unavailable input commodity

[elenya-grant]

Bugfix on storage so storage can't charge with unavailable input commodity

Storage performance models were not constrained to only charge with the available input commodity. If a controller were to tell the storage performance model to charge more than the available input commodity, then the storage would charge more than the available input commodity. This shouldn't be allowed to happen, storage performance models should only be able limited to only be able to charge with the commodity_in. This PR fixes that.

This PR also fixes some of the logic in the storage model baseclass to decide whether it's using feedback control. The previous logic was:

if any(intended_dispatch_tech in name for name in self.tech_group_name):

and was updated to:

if any(intended_dispatch_tech == name for name in self.tech_group_name):

Previously, if you had a technology named "battery" that uses a pyomo controller and another technology named "battery_1" that uses an open-loop controller. Then the logic in "battery_1" would have said it's using feedback control (when it isn't). Using == instead of in makes it so that the logic in battery_1 will run as expected.

Both of these changes have new tests!

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:

• Step 1
• Step 2

Type of Reviewer Feedback Requested (on Draft PR)

Structural feedback:

Implementation feedback:

Other feedback:

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
  • At least one complete sentence has been provided to describe the changes made in this PR
  • After the above, a hyperlink has been provided to the PR using the following format:
    "A complete thought. [PR XYZ]((https://github.com/NatLabRockies/H2Integrate/pull/XYZ)", where
    XYZ should be replaced with the actual number.

Section 3: Related Issues

Section 4: Impacted Areas of the Software

Section 4.1: New Files

Section 4.2: Modified Files

• examples/34_plm_optimized_dispatch/: tech config and plant config were updated to use an electricity feedstock instead of the grid. This change was made based on input from @vijay092 and the planned future work thats captured in Issue SLC: sync up peak load management capabilities #749.
• h2integrate/storage/battery/pysam_battery.py: modified PySAMBatteryPerformanceModel
  • simulate(): updated to take commodity_available as an input and constrain charge based on the available commodity.
• h2integrate/storage/storage_baseclass.py: modified StoragePerformanceBase
  • run_storage(): updated calls to simulate() and added commodity_available as a key in the kwargs dictionary to pass to feedback controllers.
  • simulate(): updated to take commodity_available as an input and constrain charge based on the available commodity.
  • setup(): minor change in logic for deciding whether using feedback control or not

New tests

• h2integrate/control/test/test_multistorage_pyomo_openloop_control.py::test_battery_pyomo_battery_openloop: test that would've failed before this PR that tests the naming logic for deciding whether a technology has a feedback control strategy or not.
• h2integrate/storage/test/test_storage_performance_model.py::test_generic_storage_charge_more_than_available: test that would've failed before this PR. Tests when the commodity_set_point tells the storage to charge more than what's available.

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

[jaredthomas68]

The storage base class changes to make all controllers take in the available commodity makes sense on the surface, but could ultimately limit the ability to charge storage from the grid because storage would never charge. I went and checked on the PLM optimized control and found it has not been correctly connected to the grid yet and so I would like to get that figured out first so we can appropriately address it in this PR. I made a draft PR with my ideas in #745 that I think should help clarify my concerns.

That said, I really the ideas in this PR and expect them to come in once we have a clear path forward (probably this week I think). I just want to make sure we are all on the same page and don't negatively impact existing capabilities.

[jaredthomas68]

I think I'm ok with where this is at now. Thank you for iterating. The run time is increased by about 7x to get convergence instead of doing a direct calculation, but it is still fast enough. I hope we can improve the run time in the future.

[vijay092]

I looked at Example 34 and it looks good to me! Thanks, Elenya!