Based on the previous inputs, stochastic schedule values falling within the peak window are shifted to after (offset by delay) the end of the peak window.
Other details/questions:
If shift would cause any stacking of events, do not shift (shouldn't happen often).
Applies to appliances consuming any fuel type.
Should we support defining a different delay value for each appliance?
Approach 2
Perhaps we follow the approach for vacancy and power outage periods. For example, create a new schedules_peak_period argument in BuildResidentialHPXML (along with weekday/weekend and delay arguments?) that populate the HPXML like so:
Then we could support (1) multiple peak periods per day, (2) application to all schedule types (not just stochastically generated), and (3) defining a different delay value for each appliance.
To be able to model load shifting of appliances.
Approach 1
Add the following arguments to the
BuildResidentialScheduleFile
measure:schedules_peak_period
(optional; str). Must be between 1 and 12 hours. Default '15 - 18'.schedules_peak_period_delay
(optional; int). Default 0.schedules_peak_period_xxx
(optional; bool). Default false. Choices forxxx
are:cooking_range
,dishwasher
,clothes_washer
,clothes_dryer
. Others?Based on the previous inputs, stochastic schedule values falling within the peak window are shifted to after (offset by delay) the end of the peak window.
Other details/questions:
Approach 2
Perhaps we follow the approach for vacancy and power outage periods. For example, create a new
schedules_peak_period
argument inBuildResidentialHPXML
(along with weekday/weekend and delay arguments?) that populate the HPXML like so:Then we could support (1) multiple peak periods per day, (2) application to all schedule types (not just stochastically generated), and (3) defining a different delay value for each appliance.