Demand Response Optimization for Battery Energy Storage (Stage 2) by abhineet-gupta · Pull Request #808 · NatLabRockies/H2Integrate

abhineet-gupta · 2026-07-21T13:55:33Z

Demand Response Optimization for Battery Energy Storage (Stage 2)

This PR is a continuation of PR 679.
It adds a Pyomo optimization based controller for the BESS system.
The controller optimizes the battery dispatch to minimize the Co-Op's expenditure while allowing demand response capabilities based on G&T requirements during peak window.

Section 1: Type of Contribution

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:

Type of Reviewer Feedback Requested (on Draft PR)

Structural feedback:
Do you agree with the terminology used in describing this approach in documentation.

Implementation feedback:
Is this the correct way to add highs solver for pyomo to github workflow. It has already been added to environment.yml.
Other feedback:

Section 3: General PR Checklist

Section 4: Related Issues

Section 5: Impacted Areas of the Software

Section 5.1: New Files

Section 5.2: Modified Files

h2integrate/control/control_strategies/storage/plm_optimized_storage_controller.py
- Modified implementation under PeakLoadManagementOptimizedStorageController

Section 6: Additional Supporting Information

Section 7: Test Results, if applicable

Section 8 (Optional): New Model Checklist

multi-objective BESS

johnjasa

This is great, thanks for the follow-on PR, @abhineet-gupta! I love how you updated the code, examples, tests, and docs. Really slick stuff with some good solver generalizations as well.

I've left some questions and suggestions, nothing huge but I do think some of the clarifications will be useful for users approaching this code.

vijay092

Thank you for working on this! I had some minor comments.

vijay092 · 2026-07-27T22:15:38Z


 **Given:**
- $\lambda_t$ := `supervisory_signal`: price, demand, or price $\times$ demand time series at timestep $t$
+- $\lambda_t$ := `lmp_signal`: electricity price time series at timestep $t$


I'd call this a supervisory signal, since it could be either LMP or demand- essentially any external signal that the battery needs to respond to.

This controller needs both LMP and demand signals as inputs at the same time, hence the distinction.

Is there just one demand signal? If the LMP could also be an upstream demand signal (as in the heuristic control work), then it may make sense to adjust the name as @vijay092 suggested. I see a supervisory signal file, but I only see one demand and lmp in the docs formulation.

vijay092 · 2026-07-27T22:43:59Z


 $$
-\max_{u_t, v_t,p_{d,t}, p_{c,t}} \quad \gamma \cdot \Delta t \sum_{t \in \mathcal{T}} p_{d,t}
+\min_{u_{gt,t},u_{coop,t},v_t,p^d_{gt,t},p^d_{coop,t},pc_t,\text{SOC}_t,p_{gt2coop,t}} \quad


Could you confirm if the units are uniform in the first and second term? Incentive is $ / kwh and LMP is $/MWh?

The optimization setup expects $/kWh for both. I will double check the input data in example to ensure that they follow the convention.

vijay092 · 2026-07-27T23:15:05Z


-        # Incentive revenue is earned for every kWh discharged.
+        # Power transmitted to CoOp
+        m.p_tocoop = pyomo.Var(


p_tocoop is unbounded above which might cause issues later on. Good to add an upper bound.

That's a good point. There would be a practical upper bound (based on interconnections etc). However, there is no theoretical upper bound (we can potentially model as large a G&T and CoOp under this framework as we like). Not sure how to pick a reasonable upper bound here.

I think the upper bound could be exposed as a user input to the control in the tech_config. I think it would appropriate to have a default value of None but allow the user to set it as well. It may also work to pull it from the performance model rating information, perhaps with a buffer.

vijay092 · 2026-07-27T23:29:17Z

    with subtests.test("Discharge never above max_charge_rate"):
        assert np.all(discharge <= 1.0 + 1e-4)

-    with subtests.test("SOC at t=0 equal to init_soc_fraction"):


Why is this removed?

SOC at t = 0 is calculated after the first iteration is complete. So this test is only valid if battery doesn't discharge at the first step. Previously, that wasn't possible because the battery could only discharge during peak window but now it can also discharge at the first step.

…imizedStorageController

…ients

abhineet-gupta · 2026-07-30T17:38:23Z

@johnjasa,
Thanks for the review, I have addressed your comments with and tagged them with specific commit hashes.

jaredthomas68

Nice work, this is looking really good! Most of my comments are related to generality and needs of other projects hoping to use this work. If you have any questions or concerns I'm happy to clarify and discuss potential solutions.

jaredthomas68 · 2026-08-06T22:17:52Z


 **Given:**
- $\lambda_t$ := `supervisory_signal`: price, demand, or price $\times$ demand time series at timestep $t$
+- $\lambda_t$ := `lmp_signal`: electricity price time series at timestep $t$


Is there just one demand signal? If the LMP could also be an upstream demand signal (as in the heuristic control work), then it may make sense to adjust the name as @vijay092 suggested. I see a supervisory signal file, but I only see one demand and lmp in the docs formulation.

jaredthomas68 · 2026-08-06T22:50:10Z


 $$
-\sum_{t \in \mathcal{M}_m \cap \mathcal{T}} u_t \leq B_m \cdot \tau \qquad \forall\, m
+\sum_{t \in \mathcal{M}_m \cap \mathcal{T}} u_{gt,t} \leq B_m \cdot \tau \qquad \forall\, m


It appears that only the number of hours (or timesteps?) are constrained per month, rather than the number of events, which I think is intended to be a full battery cycle per event. From the plot, it looks like multiple discharge events happen per day, while we need to be able limit the number of events per day as well as the number of events per month. I may be misunderstanding, but I think it would be worth revisiting this formulation against the requirements. My understanding of what is needed:

constrain the number of events in a month

constrain the number of events in a day

specify whether an event should be a full battery cycle or use some other definition of what an "event" is.

To be clear, I like what you have here and I think we should keep it. I also think it is not sufficient for the current project needs.

jaredthomas68 · 2026-08-06T22:53:02Z

It may be worth moving these demand and lmp profiles to the library/demand_profiles as I did in #773, but probably less important here since they are only used in one example so far.

jaredthomas68 · 2026-08-06T22:54:19Z

Can you add descriptions at the top of each lmp/demand/other signal with information about the data, where it came from, units, etc?

jaredthomas68 · 2026-08-06T23:19:05Z

            storage_out = np.zeros(self.n_timesteps)
            soc_out = np.zeros(self.n_timesteps)

+            # Per-timestep history of the MILP decision variables, accumulated


I think this is a fine way of storing if you just need them for use from the object immediately after a run. If you want them saved in the openmdao recorder database for later analysis from a saved file then we should consider making them outputs of the component.

jaredthomas68 · 2026-08-06T23:35:58Z

            domain=pyomo.NonNegativeReals,
            bounds=(0, P_max),
-            doc="Discharge power (kW) at timestep t",
+            doc="Discharge power to Co-Op (kW) at timestep t",


as determined by the local/coop

jaredthomas68 · 2026-08-07T18:17:08Z

        m.soc_evolution = pyomo.Constraint(m.T, rule=soc_evolution_rule)

-        # Can't charge and discharge at the same time.
+        # Can't charge to both G&T and CoOp or discharge at the same time.


The discharge only ever impacts the coop directly, the impact on the G&T is secondary.

Suggested change

# Can't charge to both G&T and CoOp or discharge at the same time.

# Can't simultaneously discharge according to both G&T and COOP, or charge and discharge at the same time.

jaredthomas68 · 2026-08-07T18:19:27Z

            ),
        )

+        # Can't discharge to CoOp in the dispatch window.


Suggested change

# Can't discharge to CoOp in the dispatch window.

# Can't follow discharge commands from the COOP in the dispatch window.

jaredthomas68 · 2026-08-07T18:24:07Z


    @staticmethod
-    def glpk_solve_call(
+    def pyomosolver_solve_call(


I like the move away from having a method call in the control to call a specific solver by name, but I think we should use that general method (pyomosolver_solve_call) to run the solver of choice (GLPK, HIGHs, etc). could we either add some logic or methods for each solver that can be called by pyomosolver_solve_call so the user can choose the solver to use?

jaredthomas68 · 2026-08-07T18:30:22Z

+            float: Cost charged by the G$T in the same units as `lmp`.
+        """
+        return (
+            self.config.GnT_pricingfunction_coeffs[0] * lmp


I think the COOP price needs to be independent of LMP in some cases. Maybe that just means setting the first coeff to 0? I'm also wondering how we may be able to build in other electricity pricing approaches than what is represented here. We should probably discuss offline about other project needs and make sure we make the pricing and objective functions here work for what is needed.

abhineet-gupta changed the base branch from main to develop July 21, 2026 13:56

abhineet-gupta force-pushed the PLM_DR branch from 5ccc795 to a948d23 Compare July 21, 2026 13:56

abhineet-gupta requested a review from vijay092 July 21, 2026 13:58

abhineet-gupta force-pushed the PLM_DR branch 3 times, most recently from 96a279f to bb33d74 Compare July 21, 2026 14:20

abhineet-gupta requested review from elenya-grant, genevievestarke and jaredthomas68 July 21, 2026 14:53

Abhineet Gupta added 5 commits July 23, 2026 09:28

Improve PeakLoadManagementOptimizedStorageController to allow for

6019fa3

multi-objective BESS

Add CHANGELOG.md for PR 808

ea6064c

Format plm_optimized_storage_controller using ruff

b830c63

Fix ruff formatting

e030805

Add highspy to github workflow

fda3c74

abhineet-gupta force-pushed the PLM_DR branch from bd1701a to fda3c74 Compare July 23, 2026 15:29

johnjasa requested changes Jul 27, 2026

View reviewed changes

vijay092 reviewed Jul 27, 2026

View reviewed changes

abhineet-gupta added 6 commits July 30, 2026 07:01

Address domments on doucmentation on PR 808

63786a7

Fix test in test_plm_optimized_storage_controller.py

9cb5738

Address more comments on PR 808

021e803

Add G&T cost function coefficient as inputs for PeakLoadManagementOpt…

938b395

…imizedStorageController

Fix test_plm_optimized_storage_controller.py with cost function coeff…

95a9153

…ients

Merge remote-tracking branch 'upstream/develop' into PLM_DR

a088c3d

abhineet-gupta marked this pull request as ready for review July 30, 2026 17:38

jaredthomas68 requested changes Aug 7, 2026

View reviewed changes

	# Can't charge to both G&T and CoOp or discharge at the same time.
	# Can't simultaneously discharge according to both G&T and COOP, or charge and discharge at the same time.

	# Can't discharge to CoOp in the dispatch window.
	# Can't follow discharge commands from the COOP in the dispatch window.

Uh oh!

Conversation

abhineet-gupta commented Jul 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Demand Response Optimization for Battery Energy Storage (Stage 2)

Section 1: Type of Contribution

Section 2: Draft PR Checklist

TODO:

Type of Reviewer Feedback Requested (on Draft PR)

Section 3: General PR Checklist

Section 4: Related Issues

Section 5: Impacted Areas of the Software

Section 5.1: New Files

Section 5.2: Modified Files

Section 6: Additional Supporting Information

Section 7: Test Results, if applicable

Section 8 (Optional): New Model Checklist

Uh oh!

johnjasa left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

vijay092 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

abhineet-gupta commented Jul 30, 2026

Uh oh!

jaredthomas68 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

abhineet-gupta commented Jul 21, 2026 •

edited

Loading