Add Load Flexibility measure

[rajeee]

Pull Request Description

Load Flexibility measure for the buildings standard scenario project.

Related PRs

• New ResStockArgumentsPostHPXML measure #929 is the approach we decided to use.

Checklist

Not all may apply:

• Tests (and test files) have been updated
• Documentation has been updated
  • If related to resstock-estimation, checklist includes data dictionary, source report, options saturation, options_lookup.
• Add to the changelog_dev.rst file
• openstudio tasks.rb update_measures has been run
• No unexpected regression test changes on CI (checked comparison artifacts)

[rajeee]

@yingli-NREL Please implement this function.

[jmaguire1]

Glad this came up in the ResStock development meeting! A couple thoughts:

• If you're changing HVAC setpoints, you might want that to only happen on weekdays, not weekends, since most TOU rates don't have peaks on weekends. Or have an input for whether this applies to weekends or not?
• Some of the metrics I know utilities are most interested in with DR events is how much load was shed during the event period, and how much it increased after the event ended. The snapback at the end of the event can make new peaks if you have enough homes enrolled. This might be complicated to do, but some useful outputs if you had runs with both a baseline and DR: How much load was shed during the event (difference in HVAC energy use), and how much additional load there was in the hour after the event ends. If you have preheating/cooling that increase in load might also be interesting/useful.
• If and when you look at shifting WHs, I'd suggest you just allow one level of setpoint change (a drop of ~10F) to mimic sending CTA-2045 load shed commands, rather than full flexibility on the setpoint schedule. I know some newer HPWHs (and maybe ERWHs too?) allow you to actually send setpoints through the API, but I've yet to see a program take advantage of that. Also, if you want to consider preheating know that's only possible on a few very new products and they have to have an integrated tempering valve (we currently don't model tempering valves).
• You might also want to look at this measure Joe wrote for shifting other loads. He can get you a link to it, but there's a measure that allows you to shift any electricequipment object (like say, a dishwasher) out of peak. I think that's very unlikely to be an automated thing that makes sense to do, and is more likely to reflect behavioral changes like someone purposefully waiting to do laundry after the peak period ends.

[shorowit]

This is the measure Jeff is referring to: NREL/openstudio-load-flexibility-measures-gem#57

[rajeee]

Thank you both for the comments. I looked at Joe's measure, and the measure seemed more tuned to things like dishwasher. The measure will zero out the schedule during the peak period, whereas for HVAC setpoint, we want to add offsets. There was another measure which seems more fit for setpiont: https://github.com/NREL/openstudio-load-flexibility-measures-gem/tree/develop/lib/measures/ShiftScheduleByType.
We could have probably tried to repurpose either of those for our use case, but there were enough difference in the approach that we thought writing a new measure was better. Large part of the setpoint shifting work was already done in python, so writing a python measure that used those code was a natural step.

• If you're changing HVAC setpoints, you might want that to only happen on weekdays, not weekends, since most TOU rates don't have peaks on weekends. Or have an input for whether this applies to weekends or not?
• Some of the metrics I know utilities are most interested in with DR events is how much load was shed during the event period, and how much it increased after the event ended. The snapback at the end of the event can make new peaks if you have enough homes enrolled. This might be complicated to do, but some useful outputs if you had runs with both a baseline and DR: How much load was shed during the event (difference in HVAC energy use), and how much additional load there was in the hour after the event ends. If you have preheating/cooling that increase in load might also be interesting/useful.
• If and when you look at shifting WHs, I'd suggest you just allow one level of setpoint change (a drop of ~10F) to mimic sending CTA-2045 load shed commands, rather than full flexibility on the setpoint schedule. I know some newer HPWHs (and maybe ERWHs too?) allow you to actually send setpoints through the API, but I've yet to see a program take advantage of that. Also, if you want to consider preheating know that's only possible on a few very new products and they have to have an integrated tempering valve (we currently don't model tempering valves).
• You might also want to look at this measure Joe wrote for shifting other loads. He can get you a link to it, but there's a measure that allows you to shift any electricequipment object (like say, a dishwasher) out of peak. I think that's very unlikely to be an automated thing that makes sense to do, and is more likely to reflect behavioral changes like someone purposefully waiting to do laundry after the peak period ends.

Good point about not shifting on weekends - we can definitely expose an argument to make this optional.

For the metrics, yes this is important. The result of this work will feed into DR-Path that LBNL is working on and based on the information provided to me by @trynthink, they are interested in:

• Instantaneous shed fraction (Fractional end-use load reduction the tech could achieve momentarily (~5 min), while maintaining acceptable service)
• 1-hour shed fraction (Fractional end-use load reduction the tech could achieve for one hour, while maintaining acceptable service)
• 2-hour shed fraction (Fractional end-use load reduction the tech could achieve for two hours, while maintaining acceptable service)
• 4-hour shed fraction (Fractional end-use load reduction the tech could achieve for four hours, while maintaining acceptable service)
• Shift duration (Maximum duration, in hours, of a load shift that this tech could execute while maintaining acceptable service (e.g., from start of load increase to end of load decrease). One of 0, 2, 4, 8, or 12 hours (zero means that the technology cannot shift load).

I think the snapback issue you mention can factor into the "maintaining acceptable service" above.

Thanks for the comment on WH flexibility - this is quite timely since we will soon start designing its input.

[jmaguire1]

Yeah I should have been more clear: Joe's measure is in fact for adjusting clothes washer, dishwasher, etc. I know that's beyond what you're currently considering, and I'm skeptical that there'll be a ton of potential in appliances that you can schedule like this, but behavioral changes are more likely and potentially something you'd ultimately want to consider for a load flexibility measure. I just wanted to point out it exists, up to you if you want to integrate it here.

Thanks @shorowit for providing the link to the measure! I should have included that, and been more clear about what I was referring to.

[jmaguire1]

And then on the metrics @rajeee: does having some metrics be 5 minute imply you'll be running with shorter timesteps, and if so how short? Some of our HVAC-GEB changes require 1 minute timesteps, because cycling losses happen on a pretty short basis. It can take 2-3 minutes to get to full capacity for example. Obviously this comes with a big increase in run time, so it really depends on what your use case is, and how long a period you want to calculate these metrics for. I haven't seen many utilities trying to shift loads for periods less than a few hours, but maybe there is interest in 5 minute intervals.

I might disagree that snapback is covered by the duration that service can be provided. It's more about what the power is the first few timesteps after the event ends and things go back to normal operation. As an example, if you have a 4 hour HVAC shift and the HVAC can't stay off for the full 4 hours and maintain setpoint, you'd still have a snapback at the end of the event when the setpoint goes back to normal. In my mind these metrics aren't all that directly related?

When you get to WH lets definitely talk for a few minutes about what the inputs ought to be, and what kind of events you want to send. There's functionality for changing the WH operating mode for HPWHs (like making sure the elements never turn on during a shed event) that you may want to include along with setpoint changes.

[rajeee]

And then on the metrics @rajeee: does having some metrics be 5 minute imply you'll be running with shorter timesteps, and if so how short? Some of our HVAC-GEB changes require 1 minute timesteps, because cycling losses happen on a pretty short basis. It can take 2-3 minutes to get to full capacity for example. Obviously this comes with a big increase in run time, so it really depends on what your use case is, and how long a period you want to calculate these metrics for. I haven't seen many utilities trying to shift loads for periods less than a few hours, but maybe there is interest in 5 minute intervals.

I might disagree that snapback is covered by the duration that service can be provided. It's more about what the power is the first few timesteps after the event ends and things go back to normal operation. As an example, if you have a 4 hour HVAC shift and the HVAC can't stay off for the full 4 hours and maintain setpoint, you'd still have a snapback at the end of the event when the setpoint goes back to normal. In my mind these metrics aren't all that directly related?

When you get to WH lets definitely talk for a few minutes about what the inputs ought to be, and what kind of events you want to send. There's functionality for changing the WH operating mode for HPWHs (like making sure the elements never turn on during a shed event) that you may want to include along with setpoint changes.

Sorry, I wasn't clear on my comment about snapback. I meant to say that there is a clause saying "while maintaining acceptable service", and I was saying we can push for "the load shifting shouldn't produce snapback" to be included as a part of that criteria.

We haven't really considered 5 minutes load flexibility for now, and currently don't have plan on going below 15-minute timestamps. My initial thought on providing that metrics is that whatever the HVAC power happen to be in the peak period is available for 5 minute flexibility (this is with assumption that most HVAC can be safely turned off for 5 minutes). If the assumption is not correct, or we need to better account for snapback this might cause, we will need better plan. I am open to suggestion!

[jmaguire1]

Hmmm, I'm still a bit confused with respect to snapback. You'd expect that happen whenever you go back to the normal setpoints, I don't think there's an easy way around it. In heating, I suppose you could gradually increase the setpoint to avoid triggering the backup ER heat for an ASHP, but you'll still have to have some amount of increased load when you increase the setpoint, there's no real way to avoid that. What were you thinking when you were thinking of the criteria "the load shifting shouldn't produce snapback"?

I think your 5 minute plan is pretty reasonable actually. Physically yes, you can turn the equipment off for 5 minutes, and in just 5 minutes you're safe from the space temperature changing so quickly that you'd get uncomfortable. Whether utilities/program administrators would actually send signals at 5 minute intervals I'm not sure, I've never seen that but I don't think that needs to change our approach from what you were thinking at all.

[rajeee]

Hmmm, I'm still a bit confused with respect to snapback. You'd expect that happen whenever you go back to the normal setpoints, I don't think there's an easy way around it. In heating, I suppose you could gradually increase the setpoint to avoid triggering the backup ER heat for an ASHP, but you'll still have to have some amount of increased load when you increase the setpoint, there's no real way to avoid that. What were you thinking when you were thinking of the criteria "the load shifting shouldn't produce snapback"?

Okay, let's go back a little bit.

Set point offset based demand response can lead to snapback. And we need to try to prevent it as much as possible and also quantify it. I think we both are in agreement and on the same page regarding this.

Currently, the metrics we are targeting to collect (the bullet points I listed in the beginning) doesn't explicitly talk about snapback. And I agree we should add metrics related to snapback. My point was that the listed bullet points (coming from LBNL) have a room in it for us to insert snapback metrics. That room is granted by the "while maintaining acceptable service" clause. We can argue that keeping snapback below a certain threshold is part of "maintaining acceptable service".

Now onto how exactly can we limit snapback? Our initial thought is to do a random horizontal shifting of peak period window. So, some houses will start half-hour early and end half-hour early. Both the shifting length, and peak period window length is user input to the flexibility measure - though we wish to define good defaults. We are open to suggestion on quantifying the snapback effect. Maybe percent increase beyond the baseline for those hours?

I think your 5 minute plan is pretty reasonable actually. Physically yes, you can turn the equipment off for 5 minutes, and in just 5 minutes you're safe from the space temperature changing so quickly that you'd get uncomfortable. Whether utilities/program administrators would actually send signals at 5 minute intervals I'm not sure, I've never seen that but I don't think that needs to change our approach from what you were thinking at all.

Thanks for the confirmation. The other concern here is also the snapback. For the actual flexibility scenario we will simulate, we can calculate some metrics related to snapback. But for this ad hoc 5 minute flexibility, if we don't actually do the 5 minute simulation, how do we quantify the snapback, and how do we justify/promise that it won't be bad?

[jmaguire1]

@rajeee: Ahhh, I see what you mean with some amount of randomizing the end period as a way to reduce snapback. That's definitely something that can be done, and I'm definitely interested in looking into how much that helps. There's always going to be some amount of load increase as the event ends, but sure, you can smooth out the timing of when that increase happens. Now I feel like we're on the same page here.

For the 5 minute peak, that's an interesting question. If we stick with 15 minute timesteps, during the timestep where the setpoint changes, you're likely at max power for the full timestep (especially now with a higher TCM), so it wouldn't be unreasonable to assume that the power during that 15 minute period is the same as it would be in a 5 minute period (because the equipment is running at 100% for the 15 minutes anyways). If we see cases where the setpoint returns to normal and the space temperature reaches the new setpoint in a single timestep, then we'd have to think about doing something more complicated here, but let's cross that bridge if and when we come to it.

This is probably beyond the scope of what you're considering and what could be covered by the language from LBNL, but: want to give any thought to people opting out of events? I have evidence (from just a couple of utilities, not something that conclusive) that ~10% of people opt out of events, and that the longer the event is the more people opt out. I think I already showed you that but:

This is from PLMA last year, PGE (Portland) showed this. I've heard anecdotes from APS and Duke that also put this at ~90% participation in any given event. Modeling opt out seems like a nice to have, but may well be beyond scope here.

[rajeee]

This is probably beyond the scope of what you're considering and what could be covered by the language from LBNL, but: want to give any thought to people opting out of events? I have evidence (from just a couple of utilities, not something that conclusive) that ~10% of people opt out of events, and that the longer the event is the more people opt out.

For some of this, we may not need to do anything - we are generating the maximum potential for a given scenario, so, one can always account for opt-out rate in post-processing by using a simple multiplier. This doesn't take into account the reduced snapback with opt-out nor can it handle people progressively opting out as the event progresses as shown in your picture. It would be fun to model that - but probably way out of scope like you said!