<%#= README.md.erb is used to auto-generate README.md. %> <%#= To manually maintain README.md throw away README.md.erb and manually edit README.md %> ###### (Automatically generated documentation) # <%= name %> ## Description <%= description %> ## Modeler Description <%= modelerDescription %> ## Measure Type <%= measureType %> ## Taxonomy <%= taxonomy %> ___ ## Table of Contents - [Measure Overview](#measure-overview)
- [Other Examples](#other-examples)
- [Automatically Generated Argument List](#arguments)
## Measure Overview The intent of this measure is to give the user the ability to shift schedules, thereby giving some control over the timing of energy use. A daily peak period is defined using a start and end hour of the day. This represents a peak demand window for which customers, e.g., might be penalized for running home appliances. Schedule values falling within the peak period are then shifted back in time, to start at the end of the peak period. An optional delay value can be specified to control how many hours after the peak period final hour the load shift should begin. By default, only schedule values occuring during weekdays can be shifted. However, an optional argument can be supplied to additionally enable schedule shifts for weekend days. Users also have the ability to disallow overlapping of shifted schedules onto any existing events. By default, however, schedules are shifted to periods that already have non-zero schedule values. In terms of specifying which schedules may be shifted, the user may provide comma-separated lists of schedule names for both ScheduleRuleset and ScheduleFile object types. Any schedule whose name is not listed is not available to receive any schedule shifts. The following illustrates a simple shift that has been applied to a refrigerator schedule. The first 5 weekdays of the year show the appliance load shifted back to start at the end of the peak period. The peak period does not apply to weekends, and so the final 2 weekend days does not show any shifted schedules.  It's important to note that although this measure has been written generically to support any schedules of either the ScheduleRuleset of ScheduleFile type, it has only been tested in the context of residential workflows (i.e, ResStock). Users applying this measure in other (untested) workflows should use caution. ## Other Examples Below are additional examples illustrating various scenarios for changing values supplied to measure arguments. ### Shorter peak period *Peak Period*: 5pm - 7pm | *Delay*: None | *Weekdays Only*: Yes  ### Non-zero delay value *Peak Period*: 3pm - 7pm | *Delay*: 1hr | *Weekdays Only*: Yes  ### Applied to weekends *Peak Period*: 3pm - 7pm | *Delay*: None | *Weekdays Only*: No  ___ *(Automatically generated argument information follows)* ## Arguments <% arguments.each do |argument| %> ### <%= argument[:display_name] %> <%= argument[:description] %> **Name:** <%= argument[:name] %>, **Type:** <%= argument[:type] %>, **Units:** <%= argument[:units] %>, **Required:** <%= argument[:required] %>, **Model Dependent:** <%= argument[:model_dependent] %> <% if argument[:type] == "Choice" && !argument[:model_dependent]%> **Choice Display Names** <%= argument[:choice_display_names] %> <% end %> <% end %> <% if arguments.size == 0 %> <%= "This measure does not have any user arguments" %> <% end %> <% if outputs.size > 0 %> ## Outputs <% output_names = [] %> <% outputs.each do |output| %> <% output_names << output[:display_name] %> <% end %> <%= output_names.join(", ") %> <% end %>