90.1 PRM: G3.1.1 Single Zone system type exception based on Internal Load AND EFLR

[eringold]

@dmaddoxwhite @lymereJ @weilixu

In model_differentiate_primary_secondary_thermal_zones, it appears that both the maximum internal load check AND the equivalent full-load hours check are used to determine whether a zone is removed from the primary system type:

openstudio-standards/lib/openstudio-standards/standards/ashrae_90_1_prm/ashrae_90_1_prm.Model.rb

Lines 2892 to 2912 in d332605

	# Eliminate all zones for which both max load and EFLH exceed limits
	zones.each do |zone|
	zone_name = zone.name.get.to_s
	max_load = zone_max_load[zone_name]
	avg_max_load = get_wtd_avg_of_other_zones(zone_max_load, zone_area, zone_name)
	max_load_diff = (max_load - avg_max_load).abs
	avg_eflh = get_avg_of_other_zones(zone_eflh, zone_name)
	eflh_diff = (avg_eflh - zone_eflh[zone_name]).abs
	if max_load_diff >= load_limit && eflh_diff > eflh_limit
	# Add zone to secondary list, and remove from hashes
	OpenStudio.logFree(OpenStudio::Warn, 'openstudio.standards.Model', "Zone moved to PSZ due to load AND eflh: #{zone_name}; load limit = #{load_limit}, eflh_limit = #{eflh_limit}")
	OpenStudio.logFree(OpenStudio::Warn, 'openstudio.standards.Model', "load diff = #{max_load_diff}, this zone load = #{max_load}, avg zone load = #{avg_max_load}")
	OpenStudio.logFree(OpenStudio::Warn, 'openstudio.standards.Model', "eflh diff = #{eflh_diff}, this zone load = #{zone_eflh[zone_name]}, avg zone eflh = #{avg_eflh}")
	sec_zones << zone
	sec_zone_names << zone_name
	zone_eflh.delete(zone_name)
	zone_max_load.delete(zone_name)
	end
	end

if max_load_diff >= load_limit && eflh_diff > eflh_limit

This seems to differ from the language of both 90.1-2016 Appendix G:

as well as the Standard 90.1-2016 Performance Rating Method Reference Manual:

Should Line 2901 be if max_load_diff >= load_limit || eflh_diff > eflh_limit, or has there been a new interpretation of this part of Appendix G?

[dmaddoxwhite]

The tests are done in three steps, since each time we eliminate a zone, it affects the "average of other spaces". In the first step we eliminate zones that meet both criteria (hence the "&&"). In the second step we check EFLH, and in the third step we check load. This logic was added to the draft 90.1-2019 PRM reference manual, but it looks like that hasn't been published yet.

[eringold]

Hm, I see that now as I read farther in the code.

This is ultimately causing me to hit #1523, because for a building which operates 24/7, I have data/electric rooms with high internal loads that area already served by FCUs in the proposed model being included with the primary system type in the baseline model. The EFLH check isn't capturing them, but I was expecting the internal load check would.

I'll have to do more digging. Thank you for clarifying!