Include more schedules in csv file

[joseph-robertson]

Examples:

• heating/cooling seasons (more detailed than the current simple ones)
• bath/kitchen fans
• heating/cooling setpoints
• water heating (e.g., Jeff had included something like this for WH-GEB)

For vacancy, are we zeroing out everything we want to (i.e., all schedules that are currently in the schedules csv file)?

For power outage, would this work?

We could move away from rulesets altogether, but there'd be a runtime penalty associated with that.

[joseph-robertson]

On setpoints:

Option A

• Have ResStockArguments create the setpoint schedule that we want
• Update BuildResidentialScheduleFile (similar to wh-geb), and pass in the created setpoint schedule Pass in the created setpoint schedule path to BuildResidentialHPXML

Option B

• Incorporate setpoint arguments into BuildResidentialScheduleFile (they may be simple enough)

Option C

• Option B but not formally adopted into OS-HPXML (just a ResStock branch)

Option D

• New measure that comes after BuildResidentialScheduleFile, that uses output of the measure as its input (e.g., sleep column). Requires changes to meta measures. See New ResStockArgumentsPostHPXML measure #927.

[joseph-robertson]

@shorowit Seems like we could pursue Option A above if we separated out pieces of the stochastic generator into their own methods. ResStockArguments could call these method(s) and gather relevant information for creating the setpoint schedule csv. The rest of the workflow downstream (in terms of measure calls), therefore, would be untouched. What do you think?

[shorowit]

Yes, that is a definite possibility. Though option B may be easier to implement and has some appeal if indeed there are some simple, high-level inputs to construct the 8760 setpoint schedules. @ejhw can you list the inputs that are being proposed?

[ejhw]

@shorowit

• Cooling Setpoint Has Offset Nighttime

• Cooling Setpoint Has Offset Daytime Unoccupied

• Cooling Setpoint Offset Magnitude (e.g., 0, 3, 6, 12 ºF)

• Heating Setpoint Has Offset Nighttime

• Heating Setpoint Has Offset Daytime Unoccupied

• Heating Setpoint Offset Magnitude (e.g., 0, 3, 6, 12 ºF)

It is possible that we could refactor to make it simpler by using 0ºF offset to represent Has Offset = False:

• Cooling Setpoint Offset Nighttime (e.g., 0, 3, 6, 12 ºF)

• Cooling Setpoint Offset Daytime Unoccupied (e.g., 0, 3, 6, 12 ºF)

• Heating Setpoint Offset Nighttime (e.g., 0, 3, 6, 12 ºF)

• Heating Setpoint Offset Daytime Unoccupied (e.g., 0, 3, 6, 12 ºF)

cc @ekpresent

[joseph-robertson]

I'm trying to minimally prove this approach out here: NREL/OpenStudio-HPXML#994.

@shorowit @ejhw @ekpresent

[afontani]

• heating/cooling seasons: Being built out via the Power Outage PR
• bath/kitchen fans: Being built out via the Power Outage PR
• heating/cooling setpoints: Have open PRs to create the 8760s but hasn't been merged.
• water heating (e.g., Jeff had included something like this for WH-GEB): Has not begun.

[joseph-robertson]

@ejhw What was the original motivation for wanting to use ResStock to generate detailed HVAC setpoints? I'm trying to get some traction on #931, which uses (1) occupants/sleeping schedules and (2) new daytime unoccupied / nighttime offset arguments to create the detailed HVAC setpoints.

@afontani @shorowit

[ejhw]

@joseph-robertson I think it was

1. to make HVAC setpoints consistent with occupancy schedules, and
2. to facilitate GEB setpoint schedule measures that work with the new setpoint diversity added via EULP.

I think the motivation was for one of @ekpresent 's projects.

[afontani]

Related to #931