pnnl / ruleset-checking-tool

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

6-2 logic

weilixu opened this issue · comments

Rule 6-2 seems have repeated logic
Applicability check: Building has Hotel/Model Guestroom or Dormitory Living Quarters, Dwelling Units space types

IF-ELSE statement: if ( space_p.lighting_space_type == "Guest Room" ) OR ( space_p.lighting_space_type == "Dormitory Living Quarters" ) OR ( space_p.lighting_space_type == "Dwelling Units" ):

The applicability check seems doing the same thing by looping through spaces to check space_p.lighting_space_type = [GEUST ROOM, DORMITORY LIVING QUARTERS, DWELLING UNITS].

Could we condense the repeated logic into one?

I agree. I think we can remove applicability check and just make it one of the outcomes, so that the RCT outcomes are "Pass", "Fail", "Manual Review" or "Not Applicable". Does it make sense?

I agree. I think we can remove applicability check and just make it one of the outcomes, so that the RCT outcomes are "Pass", "Fail", "Manual Review" or "Not Applicable". Does it make sense?

Thanks Maria. I think that make sense.
I do have a follow up question:
What should we do with data group that is not meeting the selection criteria. It is happening in some places in the rules and I think there will be more coming up.
We can use 6-2 as an example:

for space in zone.spaces:
    if space.lighting_space_type in [GEUST ROOM, DORMITORY LIVING QUARTERS, DWELLING UNITS]:
        do rulecheck and return PASS, FAIL and UNDETERMINED for the space.


for space in zone.spaces:
    if space.lighting_space_type in [GEUST ROOM, DORMITORY LIVING QUARTERS, DWELLING UNITS]:
        do rulecheck and return PASS, FAIL and UNDETERMINED for the space.
    else:
          return Not_Applicable

What about the spaces that do not fall into the selection criteria?

  1. We can set them to Not Applicable in the outcome.
  2. We just ignore them and skip the rule checking.

Issue with Option 1: is when we summarized the component-level rule assertions to calculate the rule-level assertion, it would require customized logic for each rule, which the RCT currently do not have such implementation (e.g. in 6-2 we could ignore all NOT_APPLICABLE at component-level results). and This is difficult to implement.

Issue with Option 2: we may end up with no checking in a rule at all (assume an RMD has no space fall into the three space types). We can add a rule-level logic that if there nothing checked then rule-level outcome is "Not Applicable" - this is much easier to implement.

Weily, I think Option 2 with the rule-level "Not Applicable" outcome makes sense. Perhaps you can bring it up at the RDS call today.

Weily, I think Option 2 with the rule-level "Not Applicable" outcome makes sense. Perhaps you can bring it up at the RDS call today.

That is great. Thanks!

The discussion agreed that we will use not applicable to label the spaces.