Add NFP for ScheduleRuleset#11612
Conversation
|
A key comment from team discussion was around how date/time is expressed in the input. @joseph-robertson please review and facilitate discussion and possible revisions to the design. |
|
I believe one of the comments/suggestions was to consider revising the Date Specification Type (currently either DateRange or SpecificDates). Specifically, to offer one date specification type along the lines of extensible date ranges. Something like: |
JasonGlazer
left a comment
JasonGlazer
left a comment
There was a problem hiding this comment.
Overall, I have no objection to the concept of adding another method of accepting schedules directly in EnergyPlus since there is a good use case for them but there are some specifics that should addressed.
| For support of OpenStudio SDK <-> EnergyPlus Alignment. | ||
| `OS:Schedule:Ruleset` is widely used; breaking API here would have too much impact. | ||
|
|
||
| EnergyPlus currently requires users to decompose a yearly schedule into a hierarchy of objects: `Schedule:Day:*` → `Schedule:Week:*` → `Schedule:Year`. |
There was a problem hiding this comment.
You should probably list all the existing Schedule types including Schedule:Compact, Schedule:Constant, Schedule:File:*
| `OS:Schedule:Ruleset` is widely used; breaking API here would have too much impact. | ||
|
|
||
| EnergyPlus currently requires users to decompose a yearly schedule into a hierarchy of objects: `Schedule:Day:*` → `Schedule:Week:*` → `Schedule:Year`. | ||
| This is expressive but verbose and non-intuitive: a typical weekday/weekend/holiday schedule that a user might describe in a few sentences requires many objects and careful date-range bookkeeping. |
There was a problem hiding this comment.
Having multiple approaches to enter schedules is to allow for different peoples needs. Whether any are "non-intuitive" seems very subjective.
| @@ -0,0 +1,317 @@ | |||
| Schedule Ruleset | |||
There was a problem hiding this comment.
I brought up on the call the "Ruleset" is a loaded term usually associated with Appendix G or ECB or CBECC. How about "Schedule:MultipleRules" or something that doesn't use that term?
|
|
||
| The OpenStudio SDK has long offered `OS:Schedule:Ruleset` as a higher-level, rule-based abstraction: the user defines a default day schedule and a prioritized list of override rules, each specifying which days of the week and which date range (or specific dates) the rule applies to. | ||
| Special design day schedules (summer, winter, holiday, custom) are also first-class fields. | ||
| This model is far closer to how schedules are actually specified in building standards, energy codes, and operator manuals. |
There was a problem hiding this comment.
I'm not sure about the "far closer" part, certainly this is a different approach that OpenStudio users are likely to prefer due to their familiarity to it.
| \note If blank, the Default Day Schedule is used for Holidays. | ||
| \type object-list | ||
| \object-list DayScheduleNames | ||
| A7 , \field Custom Day 1 Schedule Name |
There was a problem hiding this comment.
How are Custom Day 1 and Custom Day 2 used in this rule approach?
| \minimum 1 | ||
| \maximum 31 | ||
| \default 31 | ||
| N6 , \field Specific Month |
There was a problem hiding this comment.
See my last comment. We don't really need the specific month and day if we already can specify the start and end month and day.
| \type object-list | ||
| \object-list DayScheduleNames | ||
|
|
||
| Schedule:Rule, |
There was a problem hiding this comment.
This should probably be called Schedule:Week:Rule since it is setting weeks values based on a dayschedule
| IDD: | ||
|
|
||
| ``` | ||
| Schedule:Ruleset, |
There was a problem hiding this comment.
This should probably be called "Schedule:Year:MultipleRule" but this comment really is about making it clear that this object is at the "year" level. The "MultipleRule" reflects an earlier suggestion
| Update `doc/input-output-reference/src/overview/group-schedules.tex` with new `Schedule:Ruleset` and `Schedule:Rule` subsections placed directly following `Schedule:Year` and `Schedule:Compact`. | ||
| Key points to document: | ||
|
|
||
| - The priority model: rules are evaluated in ascending `Rule Order`; the first matching rule wins. |
There was a problem hiding this comment.
As said in another comment "Rule Order" is probably the trickiest concept. Maybe provide some example of rules with conflicts.
| \type object-list | ||
| \object-list ScheduleRulesetNames | ||
| N1 , \field Rule Order | ||
| \note Lower values have higher priority. Must be unique within a Schedule:Ruleset. |
There was a problem hiding this comment.
What if instead of Rule Order we allow the Start/End Day/Month to be used to set priorities. The one with the fewest days always takes priority. So the default is a 365 day year, and if another rule applied to 90 days it would go over that, and if another rule applied to 2 days it would take priority over the 90 day rule.
|
Just adding my comment in here: I don't have any specific for or against comments here. As long as current existing schedule definitions will still be valid, I don't have a problem with adding another schedule type. It seems like we have a lot of approaches, but I guess by doing this we are giving users more options for whatever they prefer. Given that I use OpenStudio in my graduate seminar, anything that improves the link between E+ and OS is fine with me. |
6 participants
Pull request overview
This PR adds the NFP design document for native
Schedule:Rulesetsupport in EnergyPlus.