Skip to content

make battery charge positive and add demand component to plm opt exam…#745

Closed
jaredthomas68 wants to merge 1 commit into
NatLabRockies:developfrom
jaredthomas68:plm_opt_patch
Closed

make battery charge positive and add demand component to plm opt exam…#745
jaredthomas68 wants to merge 1 commit into
NatLabRockies:developfrom
jaredthomas68:plm_opt_patch

Conversation

@jaredthomas68

Copy link
Copy Markdown
Collaborator

…ple 34

Add demand component to PLM opt and consider making storage charge positive

PR #664 is making it so charging can't happen without grid, so we need to make sure that the opt plm works with grid charging prior to that PR so the new changes in #664 can be tested against known results. I did some work on this and the solution I found was to make charge positive so that battery charge can be passed to the demand component.

I have not made all the sign changes that would be needed for this PR to be complete, but I would like to generate discussion around this to facilitate proper preparation for merging PR #664.

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:

  • come to a consensus on the proper handling of demand when using the PLM opt control
  • make appropriate changes based on above decision

Type of Reviewer Feedback Requested (on Draft PR)

Structural feedback:

Implementation feedback:

  • thoughts on how to handle battery charge as demand to the grid (and other similar scenarios). I made storage charge positive (the negative version is still in commodity_out) so it could be used as demand.

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 4: Related Issues

Section 5: Impacted Areas of the Software

Section 5.1: New Files

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

Section 5.2: Modified Files

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

Section 6: Additional Supporting Information

Section 7: Test Results, if applicable

Section 8 (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
    • Run generate_class_hierarchy.py to update the class hierarchy diagram in docs/developer_guide/class_structure.md

@elenya-grant elenya-grant left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for adding this fix, Jared! I think it makes a lot of sense.

I think that we should be careful to change the charge output profile to be positive (a lot of tests are going to fail). I suppose my only reason to keep it negative is that I could imagine it being useful in some future use-case, and that having it negative makes it more clear that negative values mean charging and positive values mean discharging when looking at the storage_{commodity}_out, {commodity}_set_point or storage_dispatch_commands.

Responding to your requested feedback from reviewers: I think we should perhaps add a new output, such as "storage_{commodity}_charge_positive", instead. I'd be curious to hear what others think.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

storage_commodity_out is negative when charging and positive when discharging. The charge output profile is defined as always being negative - this change will cause a lot of tests to fail. I think we could instead add another output called storage_commodity_charge_positive or something.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a feeling this will break things in Gen's tests as well.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for adding more subtests! This will definitely help with any future debugging of this example if it fails!

timezone: -6 # MDT (UTC-6)
start_time: 2025/01/01 00:00:00
technology_interconnections:
- [battery, electrical_load_demand, [storage_electricity_charge, electricity_demand]]

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this solution but I still think we should think about adding a new storage output rather than changing the existing one.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How is this different from - [battery, electrical_load_demand, [electricity_out, electricity_in]]
?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

electricity_out from storage is negative when charging and positive when discharging. Meaning that electricity_in to the demand component (which should be the electricity supplied to the demand component) would be positive and negative, which would increase the unmet_electricity_demand_out would be greater than the total demand when the battery is charging. So, actually I do think that [battery, electrical_load_demand, [electricity_out, electricity_in]] would be a feasible solution!

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ohhh what I have in PR #664 based on @vijay092 suggestion.

@vijay092 vijay092 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, Jared! This all makes sense. Just flagging that we may want additional tests to confirm the wiring is working as expected.

timezone: -6 # MDT (UTC-6)
start_time: 2025/01/01 00:00:00
technology_interconnections:
- [battery, electrical_load_demand, [storage_electricity_charge, electricity_demand]]

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How is this different from - [battery, electrical_load_demand, [electricity_out, electricity_in]]
?

assert pytest.approx(total_energy_charged, rel=1e-3) == -2663.0
assert pytest.approx(total_energy_charged, rel=1e-3) == 2663.0

with subtests.test("Check energy balance with battery and grid"):

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need more tests to make sure the wiring and energy balance is correct? Maybe this could be a follow on PR but this is good for #664.

Examples I can think of: i) No grid purchase during discharge timesteps. ii) Grid purchase equals unmet demand

@johnjasa

Copy link
Copy Markdown
Collaborator

@jaredthomas68, thanks again for chatting about #664 today. Given that it's in develop now, where does that leave this PR? Are you planning other changes, should it be closed, or something else?

@jaredthomas68

Copy link
Copy Markdown
Collaborator Author

@jaredthomas68, thanks again for chatting about #664 today. Given that it's in develop now, where does that leave this PR? Are you planning other changes, should it be closed, or something else?

I'm closing this PR for now, but I think we may want to come back to it later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ready for review This PR is ready for input from folks

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants