Rule Dependencies

[JacksonJ-KC]

We are currently using BPF as it is specified in the RMDs in the calculation of the expected value of performance cost index target. However, if a project fails Rule 1-1 by incorrectly calculating an area-weighted BPF or using the incorrect BPF value, our expected value of performance cost index will also be incorrect.

Do we want to continue to give a PASS outcome on Rule 1-3 if the specified PCI_t equals the expected value, but the expected value is calculated using the incorrect BPF?

Alternately, should we borrow the pieces of logic from Rule 1-1 that calculate the expected area-weighted BPF and also use that in Rule 1-3 for the calculation of expected PCI_t? This would make it so that if a project fails Rule 1-1 they would also very likely fail Rule 1-3.

[JacksonJ-KC]

This same situation appears frequently throughout the RCT, specifically sections 1, 10, 19, 21 & 22.

Some of my ideas for solutions:

• Include a fail message in critical rules to inform a reviewer of the other rules that depend on the value that failed
• Have rule applicability be based on expected values / expected system types rather than the modeled values / modeled system types.
• Void evaluation of rules that are dependent on a rule that received a FAIL outcome

[JacksonJ-KC]

The same situation also applies to rules 18-1 and 18-2 which test the baseline system types & zones served. Applicability of many rules depends on the baseline system type modeled.

Per suggestions above, applicability for rules that involve baseline system type could instead be based on the expected baseline system type determined in rule 18-1, or we could come up with a way to indicate the critical rules that other rules heavily depend on so that if a FAIL outcome is received on a critical rule it will be obvious that certain other rule evaluations are effectively voided.

Example:
If baseline system type 9 is modeled, but the RCT is able to determine that it should have been a baseline system type 7: Rules 18-1 & 18-2 fail, but every other rule has the perspective that rule applicability is based on baseline system type 9. The correction for Rules 18-1 & 18-2 need to be made first, then the correct rule applicability will kick in the next time the RCT is ran, and potentially new errors will need to be resolved because applicability has changed. This does not seem like the best way for this to work.

[JacksonJ-KC]

Another example:

Rule 19-9: Air economizers shall not be included in baseline HVAC Systems 1, 2, 9, and 10.
Rule 19-10: Air economizers shall be included in baseline HVAC Systems 3 through 8, and 11, 12, and 13 based on climate as specified in Section G3.1.2.6 with exceptions.

The RCT determines in Rule 18-1 that the system is supposed to be baseline system type 4 and it is supposed to have an air economizer.
However, baseline system type 2 is mistakenly modeled, with the air economizer that it is supposed to have. The project receives a FAIL on Rule 19-1 for modeling the incorrect baseline system type. The project receives a FAIL outcome on Rule 19-9 for correctly modeling an air economizer on the incorrect baseline system type. The project receives NOT APPLICABLE outcome on Rule 19-10 because the incorrect baseline system type was modeled.

I am worried that the initial FAIL on Rule 19-1 will cause someone to think that they are not supposed to have the air economizer. They correct the baseline system type to system 4, and they remove the air economizer. They run the RCT for the 2nd time and they are now failing Rule 19-10 which tells them they need the air economizer back.

[KarenWGard]

I think this is an important topic, and I'm of two minds - one is that if someone doesn't know that they need to correct the HVAC system type before the zone assignments and other HVAC details... they are not prepared to do this level of energy modeling. The other opinion is that we should give the modeler as much information as possible so that they can create good model(s) with as few iterations as possible.

As far as evaluating Rule 18-2 on the expected system type instead of the modeled system type... There are a couple cases where we can't be 100% sure of the expected system type (vestibules), and I think it makes sense to evaluate each rule based on the modeled system.

However, giving the modeler / reviewer information about rule interactions is a very good idea. I support the idea of creating a list of other rules upon which each rule is dependent. We could simply provide the list of rule interactions with the rule evaluation, or there are tons of options to go a little deeper. For example, if we create these a list of interactions for each rule, we can then generate a hierarchy / diagram of which rules to resolve first.