Window U-factors and BPI-2400 compliance

[GamalielL]

BPI-2400 lists maximum U-factors for "Single-pane window, wood frame"=0.714 and "Single-pane window, metal frame"=0.833. These are significantly lower than conventional estimates. It's my understanding traditional estimates were driven by the NFRC rating conditions or design load conditions and that under real-world average use conditions the conductive performance is better and hence better represented by a lower U-factor. This issue was researched during the development of BESTEST-EX and I believe that research informed the BPI-2400 limits. However contractors and auditors are most familiar with NFRC ratings, so this causes a discrepancy between the expectation of software end users and modeling best practices.

To avoid confusion with OptiMiser users I assume that the U-factor input in our interface is for NFRC conditions and make an internal adjustment in the model for real-world conditions. Also to avoid confusion, I report the user interface value in the HPXML. However this is causing a problem as some programs are starting to validate for BPI-2400 compliance. I believe our model complies with the BPI-2400 limits, but I can't communicate that in the HPXML without reporting a different value for window U-factor than is shown in the interface. I can't figure out good way to deal with this issue.

[nmerket]

This drives at the heart of the measured vs defaulted debate that has been raging for years with HPXML. I'm not really sure what the best answer is either.

[GamalielL]

This is actually more about nominal vs actual. We handle this in envelope components by having separate elements for insulation layer NominalRValue and AssemblyEffectiveRValue for the entire insulation group.

[shorowit]

I would argue that this is really a distinction between rated performance and annual performance. In my opinion, the simplest solution here is to document that the UFactor and SHGC elements should be NFRC values. If a software tool internally calculates some other annual-adjusted value, they can use an extension element.

A decent analogy can be made for heat pumps. The AHRI rated heating capacity is calculated under specific rated conditions -- an outdoor temperature of 47F and an indoor temperature of 70F. Software tools that do seasonal calculations probably use that capacity directly. One could easily do research showing that if you use the rated capacities directly for modeling in cold climates, you are overestimating a heat pump's capacity, and therefore the capacities should be reduced downward using some kind of hard limit. But if you have a software tool that does hourly calculations and adjusts the capacity for the indoor/outdoor temperatures of the given hour, then you wouldn't want to impose a limit like that because you'd be double-counting.

In the same way, the BPI-2400 window U-factor limits should absolutely not apply to EnergyPlus-based (or DOE2-based or ...) software tools. EnergyPlus performs detailed hourly window heat transfer that takes into account off-rated conditions. Applying the BPI-2400 limits when using EnergyPlus would result in a worse estimate, not better.

At a minimum, the BPI-2400 window U-factor limits really need to be caveated/explained better. Possibly they should be removed altogether. Note that ASHRAE 140 defines a window with a U-factor higher than the BPI-2400 limits:

[GamalielL]

I agree that the existing HPXML elements should be NFRC values, but unless and until BPI amends the limits or adds some explanation/exception, I will be stuck enforcing that limit on the nominal NFRC value to ensure HPXML verification of BPI-2400 passes. Using an extension element isn't helpful unless we agree on a convention and the validation tool can translate it.