Expose appliance design level as a measure parameter in options_lookup

[lixiliu]

For the electrical panels project, we want to be able to model the power draw profile of appliances realistically, specifically schedule-based appliances which have their unique challenges. As a short-term solution to achieve this, it would be helpful to expose the end use design level as a parameter that can be set to "auto" or specified in options_lookup, as end use timeseries renormalization is computationally expensive. We are planning to kick off a run for the panels project some time in FY23 Q4 - FY24 Q1, so I am looking for help to get this done soon, if that's a possible feature to be implemented.

In the long run, we want to be able to model these end uses as real operation cycles, which requires some more thinking.

Status Quo Currently, these end uses in OS-HPXML are modeled using time series schedules of fractional values representing level of power draw, with 1 = max power. Separately, the annual consumption of these end uses are calculated using Resnet 301 standard, while taking into account usage multipliers to add diversity to loads. The fractional value schedules are normalized to the annual loads to get end use load profiles. An output of this calculation is the "design level" of the end use, which represents the peak power draw, as described in the HPXML measure shown below: https://github.com/NREL/resstock/blob/e65c23ef7f834573e54c1e2ff37e28b5f504dd68/resources/hpxml-measures/HPXMLtoOpenStudio/resources/schedules.rb#L1548-L1563 and illustrated by the diagram below:

Problem The problem with this approach is that the assumptions behind the schedules and the annual load calculations are not coordinated, thereby could lead to unrealistic design levels in either direction of estimation. Below is a comparison @yingli-NREL did of the design level of appliances found in TX from EUSS round 1 run FY2018 vs. nameplate power rating of appliances from Pecan St. As seen in the plot, the resultant design level for dryers in ResStock varies significantly with outliers over 10 kW. For full comparison, see: comparison_of_peak_power_and_nameplate.docx

[joseph-robertson]

So you're proposing to have optional, e.g., xxx_design_level (W) arguments, added to the BuildResidentialHPXML measure for each of the end uses whose schedules can be stochastically generated? When supplied, they would override the calculated design_level = annual_kwh * 1000.0 / ann_equiv_full_load_hrs (i.e., both annual_kwh and ann_equiv_full_load_hrs would be ignored). Would schedule values need to then be re-scaled to achieve the correct annual_kwh?

[afontani]

The next step is to have @shorowit and @jmaguire1 take a look and think about OS-HPXML implementation.

[shorowit]

Related to https://github.com/NREL/OpenStudio-HPXML/issues/1024

[lixiliu]

So you're proposing to have optional, e.g., xxx_design_level (W) arguments, added to the BuildResidentialHPXML measure for each of the end uses whose schedules can be stochastically generated? When supplied, they would override the calculated design_level = annual_kwh * 1000.0 / ann_equiv_full_load_hrs (i.e., both annual_kwh and ann_equiv_full_load_hrs would be ignored). Would schedule values need to then be re-scaled to achieve the correct annual_kwh?

@joseph-robertson - yeah, for now, can we reverse the equation to annual_kwh = design_level * Ann_equiv_full_load_hrs / 1000 and ignore Resnet calculation? We really want to understand how far off the numbers end up being from Resnet if they are calculated from the bottom-up. Alternatively, can we allow the stochastic power draw schedules from BuildResidentialScheduleFile to be generated without renormalization from the resources/* files since those files capture real survey data? Again, to start, we are trying to understand how far off the calculations end up being from the bottom-up before coming up with a reforming strategy for the schedule generation.

[shorowit]

After reading https://github.com/NREL/OpenStudio-HPXML/issues/1024, it seems like one issue is that the appliance usage multipliers (e.g., clothes dryer usage level.tsv) is defined independent of the stochastic occupancy schedule. So the stochastic occupancy schedule might say that a home's occupants don't use the dryer much while the usage level could be 200%. That will result in unrealistic power levels. Perhaps the stochastic schedule generator should be defining usage multipliers instead of using tsvs.

I don't know if that would completely solve the issue, but it feels like a step in the right direction.

[lixiliu]

After reading NREL/OpenStudio-HPXML#1024, it seems like one issue is that the appliance usage multipliers (e.g., clothes dryer usage level.tsv) is defined independent of the stochastic occupancy schedule. So the stochastic occupancy schedule might say that a home's occupants don't use the dryer much while the usage level could be 200%. That will result in unrealistic power levels. Perhaps the stochastic schedule generator should be defining usage multipliers instead of using tsvs.

I don't know if that would completely solve the issue, but it feels like a step in the right direction.

This makes sense except we need to first understand what's typical in the Resent calculations. My understanding is the Resnet calculations are not functions of operating hours but something more arbitrary. Is there a way to back out assumed "hours of use" from Resnet?

[shorowit]

I am pretty sure the RESNET equations calculate the number of operating cycles/year for a given appliance; I have a spreadsheet from them if you are interested.

[lixiliu]

@shorowit - yes please, that would be EXTREMELY helpful.