Demand Response Optimization for Battery Energy Storage by vijay092 · Pull Request #679 · NatLabRockies/H2Integrate

vijay092 · 2026-04-15T18:38:51Z

Demand Response Optimization for Battery Energy Storage (Stage 1)

This PR introduces a Pyomo-based formulation for demand response, which will be implemented in two stages.

As the first stage, this work implements a rolling horizon optimization for battery operations. The battery dispatch logic is based on a pre-defined signal, such as LMP, load, or a combination of both. This is the G&T level dispatch signal for demand response. The next stage will implement the peak load management logic.

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:

Add unit tests
Add documentation

Type of Reviewer Feedback Requested (on Draft PR)

Structural feedback: Is this in the right place?

Implementation feedback: I used the same style as Gen's pyomo implementation. Appreciate feedback here.

Other feedback:

Section 3: General PR Checklist

Section 3: Related Issues

Section 4: Impacted Areas of the Software

Section 4.1: New Files

Main Implementation: h2integrate/control/control_strategies/storage/plm_optimized_storage_controller.py
Usage Example: examples/34_plm_optimized_dispatch

Section 4.2: Modified Files

h2integrate/core/supported_models.py
- Added the new model

Section 5: Additional Supporting Information

Section 6: Test Results, if applicable

Section 7 (Optional): New Model Checklist

elenya-grant

Hi Sanjana! Just putting a few high-level comments now - but I will do a deeper dive shortly! I love the thorough testing of PLMOptimizedControllerConfig and PLMOptimizedStorageController! The docstrings also look awesome! Besides the comments and questions that I left, other high-level things I'd like to see included before this is merged in are:

integration tests of the controller with the StoragePerformanceModel - similar to the tests in h2integrate/control/control_strategies/storage/test/test_optimal_controllers.py
a test for the example you added in examples/test/test_all_examples.py (this can be a pretty basic test, but it'll be good to ensure that the example you added is updated and runs without error as H2I is further developed)

Truly awesome work! Please message or call me if you want to discuss any of the comments I left! I will do another review that focuses on the logic within the controller - but wanted to get these initial questions and comments to you early on!

elenya-grant · 2026-04-21T22:38:59Z

+    performance_incentive (float)
+        Incentive revenue ($/kW per dispatch hour).
+    n_max_events (int)
+        Maximum discharge events per control window. Default 10.


great doc-strings! These are so helpful!

elenya-grant · 2026-04-21T22:40:31Z

+    peak_window (dict)
+        Hours eligible for dispatch. 'start' and 'end' as HH:MM:SS strings.
+    performance_incentive (float)
+        Incentive revenue ($/kW per dispatch hour).


Suggested change

Incentive revenue ($/kW per dispatch hour).

Incentive revenue ($/commodity_rate_units per dispatch hour).

I've only thought about this PR as a battery use case. We should chat about what this would mean.

I agree that it makes sense to make this general for storage since there is not anything that is really battery specific.

elenya-grant · 2026-04-21T22:49:13Z

+        m = pyomo.ConcreteModel(name="plm_dr")
+
+        # Parameters
+        P_max = self.config.max_charge_rate


In order for the controller to be compatible with a case where we want to optimize the storage charge rate or capacity, then any method called in compute() should use inputs["max_charge_rate"] instead of self.config.max_charge_rate and inputs["storage_capacity"] instead of self.config.max_capacity.

An example of how to test this is somewhat shown in h2integrate/storage/test/test_storage_performance_model.py::test_generic_storage_with_simple_control_charge_rate_lessthan_demand, using the prob.set_val function (happy to chat about it if you want)

I changed the code to use inputs. Could you check if that's what you had in mind?

yes! It looks great to me now!

jaredthomas68

This is great Sanjana! I'm excited about where this is going. I gave a lot of comments, but some of them may be irrelevant due to my experience with pyomo. The doc page details were very helpful, thank you.

jaredthomas68 · 2026-04-23T19:17:04Z

+- $\overline{\text{SoC}}$ := `max_soc_fraction`, $\quad \underline{\text{SoC}}$ := `min_soc_fraction`
+- `n_control_window` := Horizon length for optimization
+- $\mathcal{T} := \{0, 1, \ldots, T\}$: hourly time steps over `n_control_window`
+- $\mathcal{M}_m$ := set of hours in month $m$, for $m = 1, \ldots, 12$


Same as above, does this have to be hours?

It can handle any timestep now.

jaredthomas68 · 2026-04-23T19:19:43Z

+Maximize total annual incentive revenue:
+
+$$
+\max_{u_t,\, v_t} \quad \gamma \cdot \bar{P} \sum_{t \in \mathcal{T}} u_t


should the objective be based on max charge/discharge rate, or on actual discharge rate at each time step?

I was assuming that the battery always charges and discharges at max discharge rate. If we want to solve for the actual discharge rate as well as when (the binary var) we want to discharge, the math becomes a little harder. I can work on that tomorrow.

For now, I've assumed the battery charges and discharges at its maximum rate. I'll submit another PR to implement your version. When the state of charge approaches its limits, the optimizer handles edge cases as follows:

-If the SOC is too close to the minimum, discharging is disabled.
-If the SOC is too close to the maximum, charging is disabled.

Does this mean that a one hour battery with a 0.1 min soc and 0.9 max soc will never charge or discharge because it will be too close to the limits? If so, then I think we should adjust this PR. If the battery can still reach the max and min allowable SOC then I am happy with where this is at.

Hi @jaredthomas68, I'm now solving for the optimal power (not assuming it charges/discharges at rated) . Check out the new formulation.

jaredthomas68 · 2026-04-23T22:46:16Z

+        )
+
+        m.objective = pyomo.Objective(
+            expr=-incentive * P_max * sum(m.discharge[t] for t in m.T),


is there a good way to use possible discharge instead of rating (see my similar comment in docs)

Totally fair point, I am working on it.

See my previous comments.

jaredthomas68 · 2026-04-23T22:48:23Z

+                + eta_c * mdl.charge[t] * P_max / E_max
+                - mdl.discharge[t] * P_max / (eta_d * E_max)


see my comments in docs

jaredthomas68 · 2026-04-23T23:02:54Z

+            list[float]: ``(u_t - v_t) * P_max`` for each timestep in
+            the solved window. Positive = discharge, negative = charge.
+        """
+        P_max = self.config.max_charge_rate


I think P_max should be adjusted to not overcharge the battery, but still allow it to go to max charge. Maybe you have the handled somehow and I missed it.

I will submit another PR to solve for the optimal charge rate, and this comment will be addressed then.
SOC will never go out of bounds because we have constraints on it.

Made changes to solve for the optimal charge rate.

brookeslawski · 2026-04-27T18:34:17Z

I've reviewed this PR from a high level (without running the code), mostly focusing on the documentation and overall functionality. The documentation explains the added features compared to existing models clearly, which is very helpful. Nice job!

abhineet-gupta · 2026-05-04T16:11:32Z

+        n_max_events: 10  # maximum discharge events per month
+        signal_threshold_percentile: 95.0  # only dispatch when LMP >= this percentile
+        n_control_window_hours: 24  # hours; converted to timesteps using simulation dt
+        event_duration:  # omit or set to null to use static peak_window


Do we need to add another constraint (event_duration==null) or (min_peak_window == null) or (event_duration <= min_peak_separation)?

genevievestarke

Looks good to me! Thank you @vijay092 for adding in this capability!
I had a few suggestions for making the solver references more general.

…torage_controller.py Co-authored-by: genevievestarke <103534902+genevievestarke@users.noreply.github.com>

jaredthomas68

This is looking really good! Thank you for addressing the feedback. I think there are a few more changes that need to be made before merging, mostly some minor adjustments to the tests.

jaredthomas68 · 2026-04-30T22:10:20Z

+- SoC bounds:
+
+$$
+\underline{\text{SoC}} \leq \text{SoC}_t \leq \overline{\text{SoC}} \qquad \forall\, t \in \mathcal{T}


I'm not sure why, but the under and over bars are not rendering in the docs, at least in the tests.

jaredthomas68 · 2026-04-30T22:11:08Z


 $$
-u_t \in \{0, 1\}, \quad v_t \in \{0, 1\}, \quad \text{SoC}_t \in [0, 1] \qquad \forall\, t, m
+u_t \in \{0, 1\}, \quad v_t \in \{0, 1\}, \quad \text{SoC}_t \in [\underline{\text{SoC}},\, \overline{\text{SoC}}] \qquad \forall\, t


the underline and overline are not rendering in the test docs build

How are you seeing the preview? It looks fine to me. Is the overbar problem only on SOC, or on P too?
I went ahead and changed the notation to SOC_min and SOC_max.

jaredthomas68 · 2026-04-30T22:25:38Z

+]
+event_dur_cfg = control_params.get("event_duration")
+
+half_td = None


did you mean to name this "half_dt"?

td is short for timedelta. Half the event duration as pd.Timedelta.

jaredthomas68 · 2026-04-30T22:34:33Z

+            self.steps_per_event: int = max(
+                1,
+                int(
+                    round(


would it make sense to enforce rounding up here to make sure the full event duration is included?

Currently, a 3.5-timestep event rounds to 4 steps and a 3.4-timestep event rounds to 3 steps. For our use case, ceil makes more sense- I'd rather dispatch one extra step than miss revenue. Good catch, changed it to ceil.

jaredthomas68 · 2026-05-05T20:49:52Z

+@pytest.mark.parametrize(
+    "example_folder,resource_example_folder", [("34_plm_optimized_dispatch", None)]
+)
+def test_plm_optimized_dispatch_example(subtests, temp_copy_of_example):


Thanks for the added tests

jaredthomas68 · 2026-05-05T20:51:45Z

+        p_discharge = pyomo.value(model.p_discharge[t])  # type: ignore[index]
+        if t > 0:
+            soc += eta_c * p_charge * dt_hours / E_max - p_discharge * dt_hours / (eta_d * E_max)
+        assert soc >= base_config.min_soc_fraction - 1e-6


It is best to use subtests if you have multiple assert statements in a single test. There are many examples of subtests in our test suite. Can you make sure that all your tests with multiple asserts are protected with subtests?

jaredthomas68 · 2026-05-05T20:52:01Z

+    controller.dt_seconds = 3600
+    signal = np.array([1.0, 1.0, 1.0, 1.0, 1.0, 10.0, 1.0, 8.0, 1.0, 1.0])
+    mask = controller._compute_eligible_mask(signal)
+    print(mask)


Please remove print statements

Co-authored-by: Jared Thomas <jaredthomas68@users.noreply.github.com>

…tegrate into peakload-optimized

abhineet-gupta · 2026-05-06T20:01:26Z

+
+plt.tight_layout()
+plt.savefig(
+    "examples/34_plm_optimized_dispatch/plm_optimized_dispatch.png", dpi=150, bbox_inches="tight"


This line prevents the running the example from inside the example 34 directory. Using the EXAMPLE_DIR variable here should solve this.

abhineet-gupta

The rest of the PR looks good to me.

jaredthomas68

I think is looking good. I left a few suggestions, but no blocking comments.

jaredthomas68 · 2026-05-07T18:33:24Z

                self.solve_dispatch_model(
                    start_time=window_start,
-                    n_days=self.n_timesteps // 24,
+                    n_days=int(round(self.n_timesteps * self.dt_seconds / 86400)),


I think ceiling would be more appropriate here so we don't have 0 days. I'm not positive though, so this is a non-blocking comment.

jaredthomas68 · 2026-05-07T18:38:24Z

+    with subtests.test("start time"):
+        assert start.hour == 8
+        assert start.minute == 0
+        assert start.second == 0
+    with subtests.test("end time"):
+        assert end.hour == 18
+        assert end.minute == 40
+        assert end.second == 20


Technically I think these asserts should separated, but they are close enough I could let it go. Non-blocking.

jaredthomas68 · 2026-05-07T18:39:16Z

+        with subtests.test(f"SOC in bounds at t={t}"):
+            assert soc >= base_config.min_soc_fraction - 1e-6
+            assert soc <= base_config.max_soc_fraction + 1e-6



Two asserts in one subtest should be separated. Non-blocking.

aditiegarg9 · 2026-05-07T19:25:35Z

+
+## Optimization Problem
+
+This optimization is executed for each rolling window. At each window boundary the terminal SoC is carried forward as the initial condition for the next window.


It might be good to highlight the variable used for rolling window. I believe you are incorporating MPC here?

…torage_controller.py Co-authored-by: Jared Thomas <jaredthomas68@users.noreply.github.com>

vijay092 requested review from abhineet-gupta, elenya-grant, genevievestarke and jaredthomas68 April 15, 2026 18:42

elenya-grant reviewed Apr 21, 2026

View reviewed changes

Add PLM optimized dispatch controller, example 34, and tests

410e488

vijay092 force-pushed the peakload-optimized branch from b82857b to 410e488 Compare April 22, 2026 21:44

vijay092 added 3 commits April 22, 2026 16:05

Make sure the example runs

cf46abe

Add docs

e32b730

Update docs and add figure

561a6da

johnjasa self-requested a review April 23, 2026 19:45

vijay092 added 2 commits April 23, 2026 16:12

Edit docs page

7afb43a

Edit docstrings to include raises

9b9ac9b

jaredthomas68 requested changes Apr 23, 2026

View reviewed changes

vijay092 added 8 commits April 25, 2026 13:29

Add integartion tests

3d4735f

Add PLM optimized dispatch controller, example 34, and tests

42b63c3

Make sure the example runs

b0a030c

Add docs

125b48f

Add docs

7903e39

Update docs and add figure

eb9b449

Edit docs page

053e586

Edit docstrings to include raises

2f0a325

vijay092 force-pushed the peakload-optimized branch from 3d4735f to 2f0a325 Compare April 26, 2026 02:43

vijay092 added 4 commits April 27, 2026 12:09

Correct formatting

86c6fc4

FIX formatting in supported modesl

a7fc28c

Fix formatting in test_all_ex

057d8fa

Fix formatting in supported_models

0810a9a

vijay092 added 2 commits April 27, 2026 12:35

More formatting fixes

ac0c0a0

Change code to handle varibale timesteps

fa9a4a7

Edit config comments

c127b15

abhineet-gupta reviewed May 4, 2026

View reviewed changes

vijay092 added 4 commits May 4, 2026 11:53

Minor edits to configs

10aee14

Add tests for storageperformancemodel

dec2b05

Raise Valueerror if min peak separation < event dur

d2c8ac1

Remove Valueerror if min peak separation < event dur

4d8656a

genevievestarke approved these changes May 5, 2026

View reviewed changes

vijay092 and others added 5 commits May 5, 2026 09:34

Merge remote-tracking branch 'upstream/develop' into peakload-optimized

e024fc8

Update h2integrate/control/control_strategies/storage/plm_optimized_s…

9e359a3

…torage_controller.py Co-authored-by: genevievestarke <103534902+genevievestarke@users.noreply.github.com>

Update h2integrate/control/control_strategies/storage/plm_optimized_s…

eda288a

…torage_controller.py Co-authored-by: genevievestarke <103534902+genevievestarke@users.noreply.github.com>

Update h2integrate/control/control_strategies/storage/plm_optimized_s…

ae7eb89

…torage_controller.py Co-authored-by: genevievestarke <103534902+genevievestarke@users.noreply.github.com>

Apply pre-commit formatting

d4511d2

jaredthomas68 requested changes May 5, 2026

View reviewed changes

vijay092 and others added 5 commits May 5, 2026 15:51

Update docs/control/pyomo_controllers.md

a290876

Co-authored-by: Jared Thomas <jaredthomas68@users.noreply.github.com>

Fix SOC min max notation

9bd1834

Merge branch 'peakload-optimized' of https://github.com/vijay092/H2In…

cad9201

…tegrate into peakload-optimized

Change round to ceil in steps_per_event calc

b8d8182

Add subtests

05ba4c6

abhineet-gupta reviewed May 6, 2026

View reviewed changes

abhineet-gupta approved these changes May 6, 2026

View reviewed changes

Merge branch 'develop' into peakload-optimized

6f9417e

jaredthomas68 approved these changes May 7, 2026

View reviewed changes

Minor changes to comments and subtests

060a22a

aditiegarg9 approved these changes May 7, 2026

View reviewed changes

Change round to ceil when computing n_days

a340622

jaredthomas68 reviewed May 7, 2026

View reviewed changes

Comment thread h2integrate/control/control_strategies/storage/plm_optimized_storage_controller.py

vijay092 and others added 2 commits May 7, 2026 14:28

Update h2integrate/control/control_strategies/storage/plm_optimized_s…

0831c29

…torage_controller.py Co-authored-by: Jared Thomas <jaredthomas68@users.noreply.github.com>

Add _time_step_bound and make sure init_sc is within bounds

7a63466

johnjasa enabled auto-merge May 7, 2026 21:12

johnjasa merged commit f626984 into NatLabRockies:develop May 8, 2026
12 checks passed

	Incentive revenue ($/kW per dispatch hour).
	Incentive revenue ($/commodity_rate_units per dispatch hour).

		+ eta_c * mdl.charge[t] * P_max / E_max
		- mdl.discharge[t] * P_max / (eta_d * E_max)


		## Optimization Problem

		This optimization is executed for each rolling window. At each window boundary the terminal SoC is carried forward as the initial condition for the next window.

Conversation

vijay092 commented Apr 15, 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 1)

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

Section 4: Impacted Areas of the Software

Section 4.1: New Files

Section 4.2: Modified Files

Section 5: Additional Supporting Information

Section 6: Test Results, if applicable

Section 7 (Optional): New Model Checklist

Uh oh!

elenya-grant left a comment

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!

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!

jaredthomas68 left a comment

Choose a reason for hiding this comment

Uh oh!

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!

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!

brookeslawski commented Apr 27, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

genevievestarke left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

vijay092 commented Apr 15, 2026 •

edited

Loading