New PeakPeriodSchedulesShift measure

[joseph-robertson]

Closes #58.

This PR creates a new model measure called PeakPeriodSchedulesShift. Its purpose is to shift schedules based on a defined weekday (or weekday/weekend) peak period. Both ScheduleRuleset and ScheduleFile schedules are supported (i.e., they are subject to modifications).

Arguments:

• schedules_peak_period (str)
  • A weekday (or weekday/weekend) "peak" time period.
• schedules_peak_period_delay (int)
  • The number of hours after the end of the peak period to start the shift. Defaults to 0.
• schedules_peak_period_allow_stacking (bool)
  • Whether schedules can stack events. Defaults to true.
• schedules_peak_period_weekdays_only (bool)
  • Whether shift applies to weekdays only or all days. Defaults to true.
• schedules_peak_period_schedule_rulesets_names (str; comma-separated)
  • A comma-separated list of ScheduleRuleset names for which the peak period shift applies.
• schedules_peak_period_schedule_files_column_names (str; comma-separated)
  • A comma-separated list of ScheduleFile names for which the peak period shift applies.

Constraints:

• All schedule shifts must occur within one calendar day (i.e., no shifting into the next day)

Some notes/suggestions after 6/27 meeting:

• Update measure description(s) to describe intent/testing for the measure.
• Should we allow negative schedules_peak_period_delay values? I.e., shift to before the peak period?
• Should schedule names match argument values exactly? Or perhaps just be contained in actual schedule names? (Think units of a whole building where the schedule names are slightly different, e.g., have suffixes appended.)
• Update README.md with a graphic. Here is an example.

Other notes:

• Let's ignore the unchecked items above, for now.
• Joe to talk to Scott about testing this measure in BEopt. Maybe schedule meeting between Joe/Jeff/Scott.
  • Can this measure be called multiple times so as to apply different peak periods to different schedules?
  • We should propose which categories this applies to, along with example inputs (perhaps different inputs for different appliances?) Target: Jeff will create github issue around this by Fri Jul 21. (Next BEopt release is Aug 14.)
  • Should we consider any sort of penetration of events that are affected? E.g., only 40% of the time (i.e., days) schedules actually get shifted.

[DavidGoldwasser]

@joseph-robertson do you still intend for this to be draft, or do we want to get this in upcoming measure release?

[joseph-robertson]

@DavidGoldwasser I believe this should remain draft. We will likely be including this measure in future analyses, and so would assist in additional testing of the measure.