First time here? Check out the Help page!
1 | initial version |
No, the "NR SBD Performance" module does not use CBECC-Com. It used the standard EnergyPro DOE-2 engine. If you uncheck "delete temporary files after simulation is complete" in the calculations section, you can access the .bdl and .sim files to dive a bit deeper.
From my understanding, the "NR SBD Performance" module was created to follow the CPUC ruling that the SBD model must represent the actual performance of the proposed building. Therefore, this mode allows the user to specify schedules and plug loads and model system types not currently supported by CBECC-Com or the ACM.
The "standard" building is still created using Title 24 rulesets as in CBECC-Com, but follows the proposed building schedule and plug load inputs. The results are also still presented in TDV. I have not used this module extensively, or done a comparison between the two, but that amount of disparity sounds much too large. I would check any potential missing inputs, and review the .sim files (and add more reporting capability if necessary) to figure out what is wrong.
2 | No.2 Revision |
No, the "NR SBD Performance" module does not use CBECC-Com. It used the standard EnergyPro DOE-2 engine. If you uncheck "delete temporary files after simulation is complete" in the calculations section, you can access the .bdl and .sim files to dive a bit deeper.
From my understanding, the "NR SBD Performance" module was created to follow the CPUC ruling that the SBD model must represent the actual performance of the proposed building. Therefore, this mode allows the user to specify schedules and plug loads and model system types not currently supported by CBECC-Com or the ACM.
The "standard" building is still created using Title 24 rulesets as in CBECC-Com, but follows the proposed building schedule and plug load inputs. inputs (and uses the DOE-2 engine, not EnergyPlus). The results are also still presented in TDV. I have not used this module extensively, or done a comparison between the two, but that amount of disparity sounds much too large. I would check any potential missing inputs, and review the .sim files (and add more reporting capability if necessary) to figure out what is wrong.