unmet load hours

[weilixu]

Rule 19-5 and 19-6 checks unmet load hours.

The output schema sets the unmet load hours as required data.

In that case, do you agree that unmet_load_hours_heating, unmet_load_hours_cooling and coincident_unmet_load_hours cannot be Null since these three parameters are required data and their types are number?

[KarenWGard]

I'm including Jason on this thread because I'm not sure that I know enough about the schema to answer this question. Weili - your logic about these inputs always having a number because they're required makes sense, I can't say with authority. Thanks, Karen

…

On Mon, Mar 20, 2023 at 7:35 PM Weili Xu ***@***.***> wrote: Assigned #995 <#995> to @KarenWGard <https://github.com/KarenWGard>. — Reply to this email directly, view it on GitHub <#995 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A3G3CLFLHH6MTDKHAORBGUDW5CPPRANCNFSM6AAAAAAWBO3TZU> . You are receiving this because you were assigned.Message ID: ***@***.***>

[JacksonJ-KC]

I would like to revive this conversation and add some of my own concerns revolving around the schema's use of the word "coincident" and potential confusion around the note and the 90.1-2019 ruleset interpretation.

I would think that an unmet hour occurs when there is either a cooling unmet hour or a heating unmet hour.

• Worst case scenario: all unmet heating hours occur at a different time than the unmet cooling hours.
  Unmet hours == (Unmet heating + Unmet cooling)
• Best case scenario: all unmet heating hours occur at the same time as the unmet cooling hours.
  Unmet hours == Unmet heating == Unmet cooling

However in rules 19-5 and 19-6, we allow projects to pass if EITHER unmet_hours OR (unmet_heating + unmet_cooling) are less than 300. Going by the definition above, it should be impossible for (unmet_heating + unmet_cooling) to be less than unmet_hours and should trigger a failure for being invalid. However, our test cases 19-5-b and 19-6-b test this scenario and result in a PASS.

[mkarpman]

It seems that the intent is to allow populating either unmet_hours OR (unmet_heating AND unmet_cooling).

• If unmet_hours are specified, than we can readily check whether the project meets the min. 300 hrs requirement.
• If this field is blank, then we can be sure that the project passes ONLY of unmet_heating + unment_cooling <=300 (i.e., your best case scenario occurs). In all other cases, project may fail the limit.

[JacksonJ-KC]

That sounds fine to me. The logic needs to be adjusted to prioritize unmet_hours and only fall back to unmet_heating + unmet_cooling when unmet_hours is not defined. Agreed?

[mkarpman]

I agree, but I wonder if othres have different recollection on how these data elements are related. In either case, notes to the schema should be updated to make this clear. E.g., I think it would be sufficient to provide either one or the other, and not both.