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.

johnjasa · 2026-07-27T15:53:00Z

Could you please add definitions or explanations for the shaded gold regions in the figure or legends?

johnjasa · 2026-07-27T15:55:29Z

 dependencies:
  - python=3.11
  - glpk
+  - highspy


Thanks for adding the highspy req here! Could you please add it to the conda install command within the install.md doc page too please?

johnjasa · 2026-07-27T15:56:55Z

    )

-    PeakLoadManagementOptimizedStorageController.glpk_solve_call(model)
+    PeakLoadManagementOptimizedStorageController.pyomosolver_solve_call(model)


I like this generalization away from glpk to the pyomosolver! Thanks

johnjasa · 2026-07-27T15:59:57Z

+        """Compute the cost a G$T charges to a CoOp based on the current grid price.
+
+        Args:
+            lmp (float): Current grid price (locational marginal price), e.g., in $/MWh.
+
+        Returns:
+            float: Cost charged by the G$T in the same units as `lmp`.


Should this be G&T instead of G$T? Maybe I'm just not familiar with the initialism

johnjasa · 2026-07-27T16:00:33Z

+        Returns:
+            float: Cost charged by the G$T in the same units as `lmp`.
+        """
+        return 1.05 * lmp + 20


Should these multiplicative and offset coefficients be input or settable in some way? Or is it okay that they're hardcoded here? Will they always be these values?

johnjasa · 2026-07-27T16:01:43Z


    @staticmethod
-    def glpk_solve_call(
+    def pyomosolver_solve_call(


My own curiosity: why move away from GLPK here to use highs? Is it more robust, faster, better for this problem, or something else? Should we avoid using GLPK in other contexts within H2I?

johnjasa · 2026-07-27T16:06:29Z

 ```

-# Optimized Demand Response Controller
+## Optimized Demand Response Controller


Suggestion: the actual class file has PeakLoadManagement in the name; I'd suggest keeping the same naming convention here in the docs, and maybe even referencing or linking to the class itself so users can dig deeper.

johnjasa · 2026-07-27T16:09:26Z

-            object.__setattr__(self.config, "max_charge_rate", float(inputs["max_charge_rate"][0]))
-        if "storage_capacity" in inputs:
-            object.__setattr__(self.config, "max_capacity", float(inputs["storage_capacity"][0]))
-


Is this just no longer necessary? Can we still optimize the max_charge_rate and storage_capacity values at the OM level and they'll get updated? It looks like yes as they're used on line 250, but I'm asking to double-check!

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.

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?

vijay092 · 2026-07-27T22:58:04Z

+        Returns:
+            float: Cost charged by the G$T in the same units as `lmp`.
+        """
+        return 1.05 * lmp + 20


vijay092 · 2026-07-27T23:01:59Z

+        discharge_gt = pyomo.value(model.discharge_gt[t])  # type: ignore[index]
+        discharge_coop = pyomo.value(model.discharge_coop[t])  # type: ignore[index]
+        with subtests.test(f"No simultaneous charge, discharge_gt or discharge_coop at t={t}"):
+            assert not (charge > 0.5 and discharge_gt > 0.5 and discharge_coop > 0.5)


This allows two conditions to be > 0.5 which should not happen, right?

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.

vijay092 · 2026-07-27T23:24:30Z

+u_dicharge_coop = controller.discharge_coop_bin_history
+v_charge = controller.charge_bin_history
+p_dicharge_gt = controller.p_discharge_gt_history
+p_dicharge_coop = controller.p_discharge_coop_history


vijay092 · 2026-07-27T23:24:54Z

-            length ``n_control_window_hours`` per solve.
+        lmp_signal (list[float]): Locational Marginal Pricing (LMP)
+            forecast time series.
+        demand_signal (list[float]): Consumer demand forcast time series


vijay092 · 2026-07-27T23:25:09Z

+        )
+
+        # Objective is maximizing incentive revenue is earned for every kWh discharged and
+        # minimzing the cost of energy for the CoOp.


vijay092 · 2026-07-27T23:25:24Z

@@ -304,13 +306,34 @@ def pyomo_dispatch_solver(
                # Solve the optimzation problem


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?

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

		@@ -304,13 +306,34 @@ def pyomo_dispatch_solver(
		# Solve the optimzation problem

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!

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!

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!

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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

abhineet-gupta commented Jul 21, 2026 •

edited

Loading