ApacheHVAC Appendices A-J

ApacheHVAC User Guide
Appendices A–J
IES Virtual Environment
Copyright © 2016 Integrated Environmental Solutions Limited. All rights reserved.
No part of the manual is to be copied or reproduced in any form without the express agreement of
Integrated Environmental Solutions Limited.
VE 2016 ApacheHVAC User Guide – Appendices A-J i

Contents
Appendix A: Rules for Air Flow Specification ...................................................................................4

Appendix B: System Parameter Dialog Data Mapping ......................................................................6
Appendix C: ApacheHVAC Component and Controller Limits ...........................................................7
Appendix D: HVAC Systems Modeling Guidance for the ASHRAE Standard 90.1-2007 Performance
Rating Method (PRM) ................................................................................................................... 10
1.1.1 Fan power for PRM Baseline systems ........................................................................................................ 10
1.1.2 DX Cooling EER and COP for PRM Baseline systems .................................................................................. 11
1.1.3 Baseline systems 2 and 4 ........................................................................................................................... 12
Appendix E: Ground-Source Heat Pump Modeling using ApacheHVAC and Gaia Geothermal Ground-
Loop Design (GLD)......................................................................................................................... 22
Appendix F: Modeling VRF systems ............................................................................................... 24
Appendix G: Hydronic Radiant Heating and Cooling Systems ......................................................... 33
1.2 Modeling hydronic heated and/or cooled slabs using radiant panels (method 1) .................................... 35
1.3 Modeling heated or cooled slabs using slab zones and hydronic loops (method 2) ................................. 36
1.3.1 Hydronic Radiant Slab Zones ..................................................................................................................... 36
1.3.2 ApacheHVAC Hydronic Loops and Controls for Radiant Slabs ................................................................... 40
1.3.3 Illustrative results indicating appropriate modeling of radiant cooling slab ............................................. 42
Appendix H: Modeling UFAD and DV in ApacheHVAC .................................................................... 43
Appendix I: Solar Hot Water Applications in ApacheHVAC ............................................................. 56
Appendix J: Pre-ISM Zone Loads, Ventilation, and Autosizing using the Loads Data Spreadsheet and
original System Schedules interface (VE2015 and earlier versions)................................................. 57
1 Zone Loads, Ventilation, and Autosizing using the Loads Data Spreadsheet ........................ 57
1.1 Overview .................................................................................................................................................... 57
1.2 Zone-level loads and sizing ........................................................................................................................ 58
1.2.1 Zone-level system set up and autosizing steps .......................................................................................... 59
1.3 System-level loads and sizing .................................................................................................................... 65
1.3.1 Unmet Load Hours tests ............................................................................................................................ 67
1.3.2 Understanding loads for ApacheHVAC components in Vista Results ........................................................ 71
2 HVAC controller profiles relative to setpoints entered in the System Schedules dialog........ 72
2.1.1 An example and further explanation for CP7 and HP6 profiles ................................................................. 73
2.1.2 Coordination with changes made to setpoints via the System Schedules and Setpoints dialog ............... 73
3 Manual Adjustment of Control Throttling Range for Tighter Control of Space Temperature
and Humidity ............................................................................................................................ 75
3.1.1 Reducing control bandwidths for tighter control or to avoid overlapping control bands ......................... 77
3.1.2 Manual editing of HVAC profiles to alter the midband offsets from setpoint and thus modify this aspect
of the throttling range ............................................................................................................................................. 78
3.1.3 Humidity control — dehumidification, sub-cooling, and reheat to SAT .................................................... 80
References .................................................................................................................................... 82
VE 2016 ApacheHVAC User Guide – Appendices A-J ii

ApacheHVAC User Guide Appendices
The ApacheHVAC User Guide is divided into five parts—five separate documents—each of which covers a
set of related topics. Ten ApacheHVAC User Guide Appendices provide additional information.
A: Overview and Fundamentals

Part A describes general functions, toolbars, tree, canvas, drawing tools, overlays and
annotations, HVAC prototypes library, constructing systems, multiplexing basics, types of
components and controllers, essential rules, Integrated System Management (ISM) basics,
overview of the System Parameters UI, typical workflow, and results view.
Many of these topics are appear again in parts B–E where they are covered in greater detail.
B: Equipment, Loops, Components, and Controls

Plant Equipment and Water Loops
Airside Components and Controllers
Room Unit Components and Controllers
C: Working with Prototype HVAC Networks

Prototype HVAC Systems Library
Rooms, Zones, Layers, and Multiplexing
Integrated System Management (ISM), emphasizing broader VE context as in ISM phases
1b and 2, and productivity tools in phase 3; will cover phases 1-3 as they are released.
System Setup, System Parameters, Zones Tabular Edit, Loads, Ventilation, Autosizing,
Loads Reports, and Results Analysis workflow and essential steps.
D: System Parameters Interface for HVAC Networks

Description of each individual parameter and control in the System Parameters dialog.
See also Appendix B: System Parameter Dialog Data Mapping.
E: Prototype Systems
System types and common features of Prototype Systems in the HVAC Systems Library
Appendix A: Rules for Air Flow Specification

Appendix B: System Parameter Dialog Data Mapping
Appendix C: ApacheHVAC Component and Controller Limits
Appendix D: HVAC Systems Modeling Guidance for the ASHRAE 90.1 Performance Rating Method
Appendix E: Ground-Source Heat Pump Modeling with ApacheHVAC and Gaia Geothermal GLD
Appendix F: VRF systems in ApacheHVAC
Appendix G: Hydronic Radiant Heating and Cooling Systems in ApacheHVAC
Appendix H: UFAD and Displacement Ventilation in ApacheHVAC
Appendix I: Solar Hot Water Applications in ApacheHVAC
Appendix J: Pre-ISM Zone Loads, Ventilation, and Autosizing using the Loads Data Spreadsheet and
original System Schedules interface (VE2015 and earlier versions)
Zone Loads, Ventilation, and Autosizing using the Loads Data Spreadsheet
System Schedules dialog and HVAC controller profiles relative to setpoints
Manual Adjustment of Throttling Range for Space Temp & Humidity
VE 2016 ApacheHVAC User Guide – Appendices A–J 3

Appendix A: Rules for Air Flow Specification
It is important to specify airflows in the system completely and consistently. The rules for airflow
specification are set out below.
Airflows may be specified by the following mechanisms:

• With a flow rate controller. Airflow is specified at any point in the system where a controller with
its controlled variable set to flow rate is attached to the ductwork.
• With a percentage flow control controller. Airflow may be specified by a controller with its
controlled variable set to percentage flow control. Such a controller may only be attached to the
outlet of a damper set component. In this case, the flow entering the left branch of the damper set
(often the outside air intake) will be set as a percentage of the flow leaving to the right.
• By the assumption of continuity across air handling components. The program will deduce the
airflow at all points along a chain of air handling components given the flow at any point in the
chain, on the assumption of flow continuity. This rule is subject to a qualification in the case of
room components, as explained below.
• By addition or subtraction at a junction. At a junction where all but one of the flows are known,
the program will deduce the unknown flow by addition or subtraction. You must ensure that,
where a flow is to be deduced by subtraction, the result is never negative. If this situation arises,
the negative flow is set to zero.
• For the current iteration scheme, every closed loop that can be traced in the HVAC airside network
must pass through at least one assigned room component. To satisfy this requirement, the room
component must have an actual space in the model assigned to it—i.e., it cannot satisfy this rule if
it remains set as an adiabatic duct.
Important note: Airflow is not set by the fans or by any other type of component.
You should check before simulating a system that all flows in the system can be determined by applying
these rules. Over-specification of flows is tolerated, but there should be no inconsistencies in the
numerical values of flows.
In the case of rooms, the assumption of flow continuity is qualified by additional rules introduced to allow
ApacheHVAC to interact with MacroFlo.
If MacroFlo is running in tandem with ApacheHVAC, it will detect any imbalance between the system
flows entering and leaving each room, and make up the surplus or deficit with air flowing through the
building through openings in the fabric (provided that suitable openings exist). In order to allow such
imbalances to be set up, the following additional rules are applied relating to the assumption of flow
continuity across rooms:
In a first pass, ApacheHVAC makes no assumption about flow continuity across rooms. Within this
constraint, all possible flow deductions are made.
If some system airflows remain undetermined at this stage, a second pass is made in which the program
allows room outflow to be set equal to room inflow. All possible flow deductions are then made under
this assumption.

If some system airflows still remain undetermined, a third pass is made in which the program allows room
inflow to be set equal to room outflow, or room outflow to be set equal to room inflow. All possible flow
deductions are again made.
After this process, all airflows should be determined for a well-specified system. If this is not the case, an
error message is displayed.
By delaying the application of the room flow continuity assumption, these rules allow flow imbalances to
be set up to simulate a variety of mechanical ventilation and mixed-mode regimes.
When using ApacheHVAC and MacroFlo in tandem, it is important to note that ApacheHVAC can set flows
in MacroFlo, but not vice versa. All ApacheHVAC flows must be set within ApacheHVAC.
There are instances when room flow imbalances may meaningfully be set up without invoking MacroFlo.
If the supply rate for a room is greater than the extract rate, the deficit will tacitly be assumed to be lost
to outside. Note, however, that if the extract rate is greater than the supply, the deficit will not be
assumed to be made up with air from elsewhere unless MacroFlo is running and suitable openings are
present.

Appendix B: System Parameter Dialog Data Mapping
This appendix, which covers the mapping of dependencies and links for all parameters and controls within
the ApacheHVAC System Parameters dialog, is a separate document (approximately 250 pages).

Appendix C: ApacheHVAC Component and Controller Limits
The limits on the number of component and controllers permitted in a single ApacheHVAC file support
HVAC networks of approximately the numbers of zones indicated below. The actual number of zones will
range from these values to approximately a dozen fewer than stated, depending upon the number of
components and controllers outside of the multiplexed portion of the network.
4,000* zones in prototype single-zone systems, such as most 01–04 configurations, with each multiplex
layer including the following:
• Principal room
• Non-principal room – separately exhausted space drawing air from the principal room
(optional)*
• Return air plenum “room” component
• Active duct
• Heating coil
• Cooling coil
• Room unit (baseboard heater or similar)
• Junctions (1 to 4, depending on configuration)
• Proportional controllers (2 to 8, depending on configuration)
• On-off controllers (2 to 4, depending on configuration)
6,000 zones in prototype multi-zone systems, such as most 05–09 configurations, with each multiplex
layer including the following:
• Principal room
• Active duct (2 per zone in dual-duct systems)
• Heating coil (2 per zone in stepped 2-stage electric reheat)
• Cooling coil (FCU and Chilled beam systems)
• Room units (1 to 2, depending whether for just heating or heating and cooling)
4,000* on multi-zone DV systems, such as 09g, with each multiplex layer including:
• Principal room – occupied zone
• Stratified zone “room” component
• Return air plenum “room” component*
• Room units (1 to 2, depending whether for just heating or heating and cooling)
3,000 on multi-zone UFAD systems, such as 07f, with each multiplex layer including:

• UFAD supply air plenum “room” component
• Principal room – occupied zone
• Stratified zone “room” component
• Cooling coil (fan-powered boxes and underfloor “chilled beams”)
• Heating coil (2 per zone in stepped 2-stage electric reheat)
• Junctions (5 per zone on UFAD systems)
*The maximum number of single-zone systems in one ApacheHVAC file can be increased to approximately
6,000 by deleting the optional separately exhausted non-principal room component from all multiplex
layers when this component is not needed. Similarly, the maximum number of zones within one ApHVAC
file with all systems of configuration 09g could be increased to approximately 6,000 if the project had no
return air plenums and these components were deleted from the systems.
The limits on numbers of specific component and controllers are as listed in the table below.

Appendix D: HVAC Systems Modeling Guidance for the
ASHRAE Standard 90.1-2007 Performance Rating Method (PRM)
This section provides only supplemental information where added guidance was deemed necessary for
modeling particular HVAC systems in the context of the ASHRAE Standard 90.1 Appendix G Performance
Rating Method (PRM). Information regarding systems modeling that is not specific to the PRM is provided
in previous sections of this document.
(Section under construction)

PLEASE NOTE: This section of the ApacheHVAC User Guide is presently still under construction. Please be
sure to check for updates.
1.1.1 Fan power for PRM Baseline systems

ASHRAE 90.1-2007 section G3.1.2.8 states that if return and relief fans are in the proposed, they must be
"modeled" (i.e., they must be accounted for) in the baseline. However, G3.1.2.9 very clearly states that
"System fan electrical power [the combined total for each System] for supply, return, exhaust, and relief
(excluding power to fan-powered VAV boxes) shall be calculated using the following formulas..." And the
term CFMs ("s" subscript is for "supply") is defined as the "the baseline system maximum design supply
fan airflow rate in cfm" for both the Sys 1-2 formula and the TABLE G3.1.2.9 formulas used for Sys 3-8.
Therefore, because a fan component in ApacheHVAC is essentially an airflow meter that determines fan
energy consumption associated with a particular flow rate according to corresponding curves for total
static pressure and efficiency, it makes sense that for the Baseline system (and the Baseline ONLY... not
the Proposed) the energy consumption for all non-FP-box fans on a baseline system is most accurately
accounted for by applying the appropriate combination of static pressure and efficiency values to just the
Supply Fan. Doing this will provide exactly the baseline fan power required in the baseline system, per
90.1 PRM, at any particular system supply airflow rate. And, because the entire allotted baseline fan
energy is thus determined according to the Supply fan flow rate (just as it is in the PRM formulas), the
Baseline system should most definitely NOT have additional fan power modeled for exhaust and relief
fans.

1.1.2 DX Cooling EER and COP for PRM Baseline systems
The pre-defined DX Cooling types provided in ApacheHVAC are set up to meet 90.1-2007 PRM
requirements for Baseline systems. There are 11 pre-defined systems available:
• 5 for Packaged Single-Zone systems (PSZ) for different size ranges and associated COPs
• 3 for Packaged Terminal Ari-Conditioning (PTAC) for different size ranges and associated COPs
• 3 for Packaged Terminal Heat Pumps (PTHP) for different size ranges and associated COPs
The COP values in the pre-defined DX Cooling types match ASHRAE 90.1-2007 requirements (according to
the tables at the end of Chapter 6), as adjusted per CA Title-24 ACM Manual methods to remove the
supply fan power from the EER that was determined for a packaged unit at ARI conditions. This is the
same as what is done for older 90.1 EER numbers (with fan) provided as pre-defined options in the eQuest
Wizard and subsequent conversion of these to EIR without fan in the detailed interface. The difference in
ApacheHVAC is that, rather than presenting an EER with SA fan and converting it to an EIR without SA fan,
the DX Cooling Type dialog provides the EER with SA fan from 90.1 chapter 6 tables only in the reference
name of the DX Cooling Type. The actual number used in the input field for that dialog is the COP without
the fan—i.e., after applying the Title-24 ACM method for removing the supply fan power.

1.1.3 Baseline systems 2 and 4
Packaged Terminal Heat Pump (PTHP) and Packaged Single-Zone Heat Pump (PSZ-HP)
Default autosizing for pre-defined Heat Pumps in ApacheHVAC sets the heating capacity at ARI rating
condition of 47 °F equal to the full heating load assigned to the HP in the Heating Design Sizing run. Using
the default performance curves, the capacity actually available from the HP alone at the design heating
outdoor condition will be significantly less (on the order of 30 to 60% of the rated capacity, depending on
climate, etc.). The remaining load will be met by the backup heat source, which, by default, is electric
resistance heating with infinite capacity.
For ASHRAE 90.1 PRM Baseline Systems, check that the default autosized capacity does not significantly
conflict with the following considerations:
Generally, the ASHP heating capacity should be within about +/- 10 to 20% of the cooling capacity to
mimic the behavior of actual equipment. Heating capacity for actual equipment is often, but not always,
on the order of 15% less than cooling capacity. Using this as a guideline, rather than exactly matching the
sizes or sizing the heating capacity larger to meet more of the winter heating load without backup (as
such equipment can be selected), will cause the electric resistance heat to begin sharing the load at a
temperature closer to the 40°F outdoor maximum permitted for electric backup operation.
For ASHRAE 90.1 PRM Baseline Systems, the ASHP heating capacity should must be sufficient to maintain
the space heating setpoint without solar or internal gains when the outdoor temperature is 40°F, such
that the backup electric heat never supplements the heat pump when the outdoor temperature is 40°F or
higher.
If the required heating capacity to maintain the 40°F upper limit for backup heat source operation is
significantly greater than the cooling capacity (e.g., ), the cooling capacity should be increased so that the
heating and cooling capacities are more fairly representative of actual equipment. This will cause the
simulated DX cooling mode to operate at a lower part-load fraction and may require revision of the
cooling mode COP if the cooling capacity is shifted to a higher range with respect to ASHRAE 90.1-2007
tables 6.8.1B and 6.8.1D.
For actual applications, this will typically be a function of the equipment selection and sizing—often, but
not always, prioritized for Design Cooling Loads—with the heating and cooling capacity both determined
by sizing at 100 to 125% of the cooling load. However, for heating, the NRCAN recommended outdoor
temperature balance point (OA temp at which capacity equals space-conditioning load) should be in the
range of 23 to 32°F (-5 to 0°C).
To maintain dehumidification capability in humid climates, and thus consistency with industry best
practice, heat pump cooling capacity should be oversized no more than 125%.

As noted in the more general section describing these pre-defined ApacheHVAC systems, the 90.1 PRM
requirements for sizing and operation of air-source heat pumps (ASHPs) are based in part upon DOE-2
parameters and default inputs to eQuest rather than standard industry practice for sizing and operation
of ASHPs. These defaults and the sizing approach that they imply can lead to unrealistic simulation results,
regardless of what simulation tool is being used. The following considerations are therefore essential to
using these pre-defined systems in the context of the PRM baseline requirements.
This discussion addresses the following section G3.1.3.1 text from ASHRAE 90.1:
Heat Pumps (Systems 2 and 4). Electric air-source heat pumps shall be modeled with electric auxiliary
heat. The systems shall be controlled with multistage space thermostats and an outdoor air thermostat
wired to energize auxiliary heat only on the last thermostat stage and when outdoor air temperature is
less than 40°F.
IES has provided a new set of default values for the Air-Source Heat Pump (ASHP) component as of VE 6.3
(default values are shown in the figure below); however, in light of the complications with ASHRAE
requirements vs. both real-world and simulation-based sizing considerations detailed below, fully
automating the sizing and performance curve inputs to meet the ASHRAE-90.1 PRM requirements for
ASHPs in PRM baseline systems 2 and 4 will come in future versions. The current method therefore
combines autosizing with manual inputs to size baseline ASHPs within the current version of the VE.

The sizing process for the ASHP should be as follows (if needed, see further explanation below):
• For these systems, the ASHP component and DX cooling provide the heating and cooling modes of
the reversible heat pump. The electric resistance backup heat source has unlimited capacity.
• Complete the standard design sizing runs for spaces and then for the system(s) with the oversizing
factors set to their default values of 1.15 for cooling equipment and 1.25 for heating equipment,
as required by the 90.1 PRM. This will autosize the capacity ASHP and DX cooling to meet the full
extent of the oversized loads at the respective design conditions.
• For each zone with an ASHP, compare the autosized capacity for the ASHP component in the
range of typical balance point temperatures (e.g., 25 to 40 °F, depending on the climate) with the
sized capacity of the corresponding DX cooling coil. These capacities are shown in the Heat Pump
component dialog or, for many zones at once, in tabular edit view thereof, and in the Cooling Coil
dialog or tabular edit view thereof. Note that the connected DX Cooling type covers a range of
possible baseline sizes having a common COP, and therefore the capacity indicated in the type
dialog may be overridden by autosizing for each instance of that type (if permitted).
• If the ASHP capacity within the range of typical balance points does not and DX cooling coil
capacities do not differ significantly* (e.g., by 20% or more), adjust as indicated below.

• If the ASHP component and DX cooling coil capacities differ significantly* (e.g., by 20% or more),
adjust as indicated below.
o If the autosized cooling coil capacity is significantly greater than the ASHP capacity, adjust
the ASHP capacity upward to match the cooling capacity. If the ASHP is within 20% of the
DX cooling, it is probably not worth making an adjustment, as this serves only to scale the
ASHP performance curve with respect to efficiency.
• If the heating design day outdoor temperature is 40°F or higher, check the simulation results to
ensure that the backup electric
System heating Capacity from sizing runs, modified as required to accommodate the following
considerations:
For actual applications, this will typically be a function of the equipment sizing as prioritized for Design
Cooling Loads, with the heating and cooling capacity both determined by sizing at 100 to 125% of the
cooling load. However, for heating, the NRCAN recommended outdoor temperature balance point (OA
temp at which capacity equals space-conditioning load) should be in the range of 23 to 32°F (-5 to 0 C).
For ASHRAE 90.1 PRM Baseline Systems, in order to have the electric resistance heat share the load at
a temperature closer to the 40°F outdoor maximum for electric backup operation, the ASHP heating
capacity should be thr great of:
A) the sized cooling capacity
B) sufficient to maintain the space heating setpoint without solar or internal gains when the
outdoor temperature is 40°F.
If the heating design day OA temp is significantly below 30°F, and additional design sizing run with OA
temperature between 30 and 40°F may be justified to determine an ASHP capacity and balance point
that will engage the electric backup below the design temperature when internal and solar gains are
not present.
If the required heating capacity to satisfy B is greater than the cooling capacity, A, the cooling capacity
should be increased up
To maintain consistency with industry best practice, the cooling capacity should be oversized no more
than 125%, unless this is required to match sizing of heating capacity in a PRM baseline system to
avoid operation of the backup electric heat when the OA temperature is above 40°F.
The sizing process for ASHPs tends to differ significantly from that of other HVAC equipment. The ASHRAE
PRM specification is unfortunately unclear with respect to the sizing this type of equipment for baseline
systems (more on this below). Thus there is a degree of interpretation required here, and you are free to
re-interpret this as you see fit. The numbers you are seeing in the ASHP component dialog are simply a
starting point, and will require modification.
If the ASHP were sized for typical design heating indoor conditions (zero solar and internal gains) and an
outdoor temperature between 23 and 40°F, this would be consistent with both. However, if the outdoor
condition for the heating design day is significantly below 32°F, heating this is inconsistent with the way in
which equipment is normally sized in a simulation environment—i.e., it’s a departure from the standard
procedure of sizing of heating equipment to meet heating loads at the standard design heating
conditions.
The 90.1 PRM requires adequately sizing the ASHP plus backup heat source to avoid excessive unmet load
hours, and does not permit any electric backup heat when the outdoor temperature is 40°F or higher.
Thus the “balance point” (the outdoor temperature at which the full output of the ASHP just meets the

space heating load) needs to be below 40°F under all circumstances of varying internal gains, solar gains,
etc. The PRM goes on to specify that the electric backup should be the last resort with respect to
maintaining the desired room temperature when the air-source heat pump can’t fully meet the load. The
specified incrementally lower thermostat setpoint for engaging the backup heat is but one means of
accomplishing this. Addressing these together requires a bit of a sizing balancing act. And, the 40°F
ASHRAE is referring to is very different than the Minimum source temperature in the ASHP dialog. Both of
these are explained below.
It is important not to be misled by the PRM reference to 40°F as the maximum outdoor temperature for
operation of the backup electric resistance heating. The PRM is not saying that the ASHP should be off
below this temperature, only that the electric resistance heat should be off at above it. Assuming the
former, which may be implied by the combination of the PRM language regarding the and the eQuest
default for “Minimum HP Heat Temp” in the eQuest Supplemental Heat dialog (see below), can
significantly skew results for the model.
The following bar graph shows annual energy consumption by end use for autosized heating and cooling
as predicted by eQuest version 3.63 with location set to Minneapolis, MN and HVAC system type set to
PTAC and heat source set to heat pump (i.e., system type is PTHP). All other inputs, including the building
geometry, remained at pre-set version 3.63 default values.

In this particular illustration of how the default eQuest version 3.63 ASHP input values can lead to
unrealistic results for a baseline system, the default building in Minneapolis, MN used 75 times as much
energy (390 MBTU vs. 5.2 MBTU) for “supplemental” electric resistance space heating as it did for heating
via the specified PTHP systems.
The screen captures above show how the default Minimum HP Heat Temp has been reduced to 10 °F to
avoid this particular problem. Because we have found no justification for cutting the heat pump off at
even 10 °F when the backup heat source is electric resistance, the default value in ApacheHVAC as of VE
6.3 is 0 °F.

For one particular zone (the top floor core zone of the default 2-story office building), the default ASHP
inputs and sizing beget particularly skewed results, as indicated by the annual load served by the
Supplemental heat source vs. that served by the total load on the Heat pump unit in the SS-Q report
above.
Minimum source temperature setting for the ASHP component

The minimum source temperature is the temperature below which the ASHP will switch off completely
and allow the backup heat source to take over completely, rather than just supplement the ASHP output.
When the backup heat source is electric resistance heating and both the ASHP heat and backup heat are
delivered by a common fan, etc. (i.e., when there is no significant difference between these with respect
to heating system or parasitic loads), it makes sense to switch the ASHP off completely only when low
outdoor temperatures drive the COP to a value of less than 1.0. This is because both run on electricity and
the electric resistance heating has an effective COP of 1.0. In such cases, the thermal and economic
balance points for this hand-off should be essentially the same.
Because the PRM Baseline systems with ASHPs are required to use electric resistance as the backup
heating source, we must assume this has an effective COP of 1.0. As the default ASHP curve has a COP of
better than 1.0 down to 0°F, we have used 2°F as the default minimum source temperature as of VE 6.3.
This is also consistent with industry best practice, which might set this between 0 and 10°F for a system
with electric resistance backup, depending upon the equipment, climate, and so forth. Some recently
offer ASHP technologies, however, have been developed with a greater emphasis on heating performance
and are capable of operating efficiently well below 0°F.
When the backup heat source uses a different energy source, has relatively high efficiency, or has lesser
associated system/parasitic loads, the economic balance point may be higher with respect to the heat
pump COP. The economic balance point is the outdoor temperature below which it is cheaper to heat
with the supplementary heat source rather than the heat pump. In such cases, it often makes sense to
restrict ASHP operation, operating only the backup heat source below a specified outdoor temperature.

An outdoor temperature sensor is used to shut off the heat pump when the temperature falls below the
preset limit. Only the supplementary heat source operates below this temperature. This is the Minimum
source temperature setting for the ASHP component in ApacheHVAC.
Note: While real-world ASHP applications do sometimes, as noted above, restrict operation of the ASHP
below a specified temperature, it is very unusual to restrict the backup heat source operation in building
for which the ASHRAE 90.1 PRM is applicable. While an individual homeowner may be given the option to
prevent the use of the backup heat above a set outdoor temperature, the occupants of heated spaces in
larger buildings generally expect the heating setpoint to be met by whatever means is available to do so,
regardless of the particular outdoor temperature at the time.
ASHP sizing
For actual applications, ASHP sizing and selection is a combined function of design cooling Loads and
heating balance point. The cooling loads are usually the priority in a climate with significant cooling load,
especially if it is a humid climate. On the other hand, the preferred heating balance point (the lowest
outdoor temperature at which the ASHP meets the entire heating load) is typically in the 22 to 32 °F
range. If driven purely by cooling requirements, both heating and cooling capacity would be sized at about
100 to 110% of the cooling load. This approach is meant to provide efficient cooling operation and
effective dehumidification. In climates with mild winters, this may provide ample capacity to meet all
heating loads. In colder climates, however, this approach to sizing will tend to address some significant
fraction of the heating load, but not all of it. The rest will be addressed by a backup heat source. To
minimize dependence on the backup heat source, a somewhat larger unit may be selected in order to
provide a lower heating balance point with respect to outdoor temperature. However, where the climate
is not all that cold, oversizing with respect to heating to achieve a low balance point temperature may
reduce seasonal heating efficiency if it leads to a majority of operating hours at low part-load fractions,
which is significantly less efficient than operating the heat pump at or near full load. Furthermore, part-
load operation at low outdoor temperatures is doubly inefficient: at an outdoor temperature of 37°F, the
COP for a typical heat pump can drop below 1.0 if the load is less than about 30%. Finally, if
dehumidification is anticipated when in cooling mode (i.e., in all but notably dry climates), best practice,
even when seeking a lower heating balance point, is to avoid sizing the unit greater than 125% of the
cooling load. Getting this right requires a somewhat sophisticate bit of logic.

Heat HP
load Cap
Design 25 to 47 F
temp 35 F ?
Maybe best to simply size ASHP capacity at 47°F OA source temp to equal required heating capacity at
design heating condition. Until we build some or all of this logic into the software, user intervention will
be required to determine appropriate sizing of the ASHP component in ApacheHVAC. As of VE 6.4, the
ASHP capacity at 47°F outdoor temperature will, for systems 2 & 4 when used in an ASHRAE 90.1 PRM
Baseline model or when requested by the user, be set equal to the DX cooling capacity. However, in the
rare case of spaces with both moderate cooling loads and substantial heating loads occurring when
outdoor temperatures are above 40°F, it will be incumbent upon the user to check that these heating
loads are not exceeding the ASHP capacity and causing use of backup heat when outdoor temperatures
are greater than 40°F. The reason for this is that the backup heating for ASHPs in ApacheHVAC does not
include an arbitrary high limit input for the backup heat source. Rather, the backup supplements the ASHP
when the latter cannot fully meet the load.
A further refinement will extend this logic as follows, using an additional special-purpose heating design
sizing run with the outdoor temperature forced to 40°F.
For true PRM Baseline systems (i.e., only when such system are used in PRM Baseline models), in order
to have the electric resistance heat share the load at a temperature closer to the 40°F outdoor
maximum for back operation, the ASHP heating capacity should be the greater of the following:
1) the associated cooling capacity
2) heating capacity sufficient to maintain the space heating setpoint without solar or internal
gains when the outdoor temperature is 40°F
When the heating capacity must greater than the desired cooling capacity such that the backup source
will never be required when the outdoor temperature is above 40°F (#2 above), the associated DX
cooling capacity will need to be increased to match the heating capacity. This scales the performance
curves in the DX cooling dialog so that the part-load efficiencies are correct.
The ASHRAE PRM specification includes the very clear statement regarding controls to prevent backup
electric heat operation above outdoor temperatures of 40°F; however, this applies only to software that is
incapable of modeling a true back heat source that is used only when the primary (ASHP) heat source is
unable to meet the load as a function of outdoor conditions and/or indoor heating loads.

The PRM is also unclear with respect to the actual sizing of heat pump equipment for baseline systems. If,
for example, ASHP is required by ASHRAE to be 25% oversized beyond that required just to meet the
space conditioning load at the design condition
Backup electric resistance heat

Let’s say the design condition is a 10°F outdoor temperature just before sunrise (no sun) with no internal
gains in the space, and maintaining the room at say a 70-F setpoint under these conditions results in a
quasi-static load of 464 kBtu/h. Multiply this by 1.25 and we get 580 kBtu/h.
If sized according to ASHRAE requirements for baseline building equipment, the ASHP has to have a
capacity of 580 kBtu/h, and we assume this should be at the “rated” condition (this is where ASHRAE is
more than just a bit unclear). If we then go and look at the rating conditions for an ASHP in a baseline
system (EER tables at the end of 90.1 chapter 6), we see that the ARI rating condition is an outdoor
temperature of 17°F. Thus, following this logic, our baseline ASHP should be capable of providing 580
kBtu/h at 17°F outdoor temperature. If the load is greater or the outdoor temperature is lower, it may not
actually meet the load. However, as the design load was determined at 10°F outdoor temperature and the
equipment must be 25% oversized, this probably will never by a limiting factor for a baseline ASHP
system. There will, however, be another very significant limiting factor: The ASHP probably will have a
lower limit, such as 17°F, below which it will provide no useful heat…

Appendix E: Ground-Source Heat Pump Modeling using
ApacheHVAC and Gaia Geothermal Ground-Loop Design (GLD)
Capability for transferring hourly equipment loads and final results between the IES Virtual Environment
and Gaia Geothermal’s Ground Loop Design (GLD) provides for comprehensive and detailed modeling and
design of ground-source heat pump HVAC systems. For more information on GLD software, go to:
www.gaiageo.com If you are interested in using this coupling of Gaia Geothermal and the IES VE, be sure
to check with the distributor of Gaia GLD, Thermal Dynamics Inc., at [email protected] for
discounts that have been and may still be available to licensed IES-VE users.
Modeling Ground-Source Heat Pump HVAC Systems

There is not yet an explicit ground-source heat pump model within ApacheHVAC; however, loads results
can be read into Gaia Geothermal’s Ground-Loop Design tool. This provides detailed modeling of heat
pump equipment and bore fields.
Begin by modeling the building as you would otherwise in the VE and the appropriate HVAC system in
ApacheHVAC, including all controls, air-side components, coils, terminal units, hydronics, water loops, etc.
and a boiler and chiller to provide the hot and cold supply water with suitable water loop flow rates and
temperatures. Include any loop temperature rest schemes that will be used with the ground-source heat
pump (GSHP) system. The ApacheHVAC boiler and chiller components are a placeholder that will simply
record loads for the GSHP, ground-source loops and pumps, geo-exchange bore fields, backup heating and
cooling equipment (boiler and cooling tower), and time-of-use (TOU) demand-based heat pump controls
that can be modelled in GLD 2010.
Prior to running the simulation, set the ApacheSim reporting interval to 60 minutes. Having completed up
to a full year of simulation in the IES Virtual Environment, instructions from Gaia Geothermal are as
follows:
Import the .aps results file from the VE into GD via either of the GLD Loads modules (Average Block or
Zone Manager). Clicking the Import button (arrow that goes down to the left) opens a dialog that allows
import of .aps or .csv files into the Loads module. The .csv option allows for manipulation of loads
between the VE and GLD using a spreadsheet to account for an uncommon heating or cooling source or
scheme that is not yet available in either the VE or GLD, and thus which would reduce the load passed on
to the GSHP.
Do not use the Loads > Import Loads Menu item in GLD to import .aps files, as Gaia Geothermal have
not set this up yet to work with .aps files. The .asp file import for boiler and chiller loads from the VE
must be done through one of the Loads modules (Average Block or Zone Manager).
Create a Borehole Design project and make sure it is properly linked to the correct Loads project—i.e., it is
populated from the .aps or .csv file that contains the loads from the VE.
From this point forward, use GLD as you would otherwise to model the complete GSHP system, including
detailed bore field design and manufacturer heat pump performance data.
Once the analysis in GLD is complete, you can export from GLD to an .aps file that IES VE can then read for
display and further analysis of results. The steps for that are as follows:
1. Completed the Hourly simulation in GLD
2. Go to the main File menu > Export File > Export APS and save the data generated by GLD as an .aps
file that can be read by IES VE.

The following requirements must be adhered to for exporting APS files from GLD for use with the IES VE:
A. Make sure you run the GLD program as an Administrator on Windows Vista or Windows 7
B. Must run an Hourly Simulation in the BoreHole Designer
C. Do not exceed a 1-year modelling period (Prediction Time)
D. Make sure that the "APS FIles" Folder exists in the GLD2010 directory.
Note: A quick way to test the Hourly simulation and the ability to export the .aps files is to use a very
short prediction time in GLD, such as 0.1 years, so that you don’t have to wait a long time for the full year
analysis.
GLD results exported to the IES VE .aps file should appear in Vista Results as in the screen capture above.
If you have followed the steps above without success, first check that the .aps file from the VE does in fact
include boiler and/or chiller loads to be addressed by the heat pump system. If you have confirmed these
loads are present in the file, but are still having difficulty, Gaia Geothermal has expressed willingness to
provide technical assistance to GLD users to address any import/export issues.

Appendix F: Modeling VRF systems
While work has begun on this, the VE does not yet include an explicit model for Variable Refrigerant Flow
(VRF) systems, also referred to as Variable Refrigerant Volume (VRV). The condenser heat recovery facility
in ApacheHVAC, however, can be used to reasonably approximate the thermodynamic performance of
such systems. This assumes that the system is configured and controlled the move heat, via a common
refrigerant loop, from zones in cooling mode to those in heating mode when these modes overlap.
1. Start with a multiplexed prototype system that best represents the configuration for the actual
project—e.g., PTAC, packaged single-zone, or DOAS with Fan-coil units.
2. Use a part-load-curve chiller component for the cooling mode.
The part-load-curve chiller component is used to represent the cooling mode for six reasons:
a. It has a condenser heat recovery function with which up to 100% of condenser heat can be
made available for meeting heating loads.
b. It accepts connections from multiple coils (the more sophisticated DX Cooling model has
one-to-one relationships between the compressor, condenser, and evaporator coil).
c. The data matrix format for part-load COP values is completely generic; this relies more on
user data input, but doesn’t force the performance curve to look like a typical DX unit.
d. COP can be a single number (e.g., for a very rough model), part-load dependent, or both
part-load and outdoor-temperature dependent.
e. The outdoor-temperature dependence can be DBT (it does not assume WBT as would be
used for a water-cooled chiller), and irrelevant parameters for chilled water pumps,
condenser water pumps, and cooling tower fans can simply be set to zero.
f. If data is available to separately account for the condenser fan peak power and power
fraction associated with load on the compressor and condenser section, this can readily be
included using the “Cooling tower fans” input and par-load fan-power % inputs.
Superseded by Generic Cooling Source: Note that as of version 6.3, the part-load-curve “chiller” will
need to be on a “chilled water loop”; however, the water loop is readily made irrelevant by setting the
W/gpm values to zero for both primary and secondary loop pumps and using the Simple cooling coil
model (selected in the cooling coil dialog), which conveys load but is not sensitive to water flow and
temperature. The Heat rejection tab should be left with no cooling tower. In the Chiller set, simply Add
a Part-load curve chiller model.
3. Use a Generic heat source component for the heating mode.
Depending upon whether heating mode performance varies more significantly with load fraction or
outdoor temperature, the part-load-curve Heating equipment inputs or Air-source heat pump (both
accessed from within the Generic heat source dialog) can be used to model the heating mode
(addressing heating loads when rejected heat from cooling-mode operation is not available).
In a warm climate where the variation of outdoor source temperature does not significantly influence
capacity and COP, the ability to model COP variation with part-load fraction may be most valuable.
Efficiency values (which can be in excess of 100%—e.g., 350% to represent a COP of 3.5) in the Part
load curve heating plant dialog are used to indicate up to 10 part-load COP values. If there is backup
electric resistance heating, this can be represented by a 100% efficiency value in the last (bottom) row,
with the 9th data point representing the heat pump function a maximum output. There should be very

small increment for the load range between the 9th and 10th data points so that the model makes a
very steep transition rather than smooth ramp of the COP value between these point.
When outdoor temperature is the primary driver for heating mode performance (after using recovered
heat when there is simultaneous heating and cooling), the Air-source heat pump (ASHP) may be the
preferable option when outdoor temperature is the primary driver for heating mode performance
(after using recovered heat when there is simultaneous heating and cooling). The reasons for this are
that the ASHP model varies according to outdoor temperature (and thus thermal lift) and also has a
setting for the Minimum source temperature below which the unit will cease to operate and will
depend fully upon the backup heat source.
The ASHP model can still account in some respect for variation of COP with load fraction; however, this
must be entered as data points on a single composite curve that indicates both the COP and heat
output available for each outdoor temperature. The curve is once again represented by up to 10 data
points. For each point, users need to indicate the outside-air source temperature, COP, and heat
output available at that temperature. While there are benefits in accounting for variation of
performance with outdoor temperature, some analysis may be required to determine appropriate
part-load adjustments to the otherwise full-load COP with relatively higher outdoor source
temperatures. In other words, the user must first determine how much, assuming otherwise typical
operation of the building, the heating load will be reduced from the full-load condition as outdoor
temperatures rise. This can then be used to adjust COP according to load fraction for data points
associated warmer outdoor temperatures.
When using the ASHP, the Part load curve heating plant (see Heating equipment Edit button) within
the Generic heat source dialog can be used to represent just the backup heat source. Typically this will
be electric resistance heat (efficiency = 100%).
4. Distribution losses associated with refrigerant lines can be accounted for in the Heat source dialog.
Airside distribution losses are better accounted for by using the Ductwork heat pickup (heat gain/loss)
component on the HVAC network.
5. In the cooling source (part-load curve chiller model), you can specify COP values dependent upon both
load and OA dry-bulb conditions. Set the pump and tower fan power to zero.
6. The Condenser Heat Recovery percentage in the part-load curve chiller dialog should be 100%
(indicating that all of the heat extracted from zones in cooling can be rejected to zones in heating) and
the CHR recipient should point to the Generic heat source you have set up for the heating mode.
7. In the Part-load curve heating plant dialog for the Generic heat source (when using this rather than the
ASHP to model heating mode) COP values will be expressed as efficiency values—e.g., 350% to indicate
a COP of 3.5).
8. In the Generic heat source dialog, leave the tick box for “Use water source heat pump?” unticked, as
you will already have determined the electrical energy needed to extract this recovered heat on the
cooling side. Set the Heating plant type to “Other heating plant” to keep energy consumption results
separate from boilers or DHW heat sources, if any, in the project. The heat load will be apportioned in
the following sequence:
a. Recovered heat from the part-load cooling source, to the extent it is available
b. ASHP, if used rather than a Part-load heat source
c. Part-load heat source or backup ER heat-source for ASHP, if the ASHP is used

This method can account for the benefits of moving heat from one zone to another and variation of COP
with both load and outdoor temperature (it will account for the degradation of COP and heating capacity
with low outdoor temperatures only if the ASHP is used for the heating mode).
• While the COP for cooling operation will, when outdoor temperature dependence is included,
always be a function of both outdoor conditions and load, rather than strictly indoor conditions,
as would be the case when transferring heat from one location to another in common-loop
VRF/VRV system operation, this method should provide a reasonable approximation of the
system performance.
• Although the CHR facility does allow for modeling energy consumption according to a COP
associated with upgrading heat from a condenser loop to a heating loop (e.g., as in a WSHP), this
is not necessary in this case, as the heating coils will effectively operate as the condenser for the
DX cooling when heat is being transferred via CHR. There is also an input within the part-load-
curve chiller dialog for the percentage of condenser heat available for recovery. When there is no
heat exchanger required in the refrigerant system, and thus no exchanger effectiveness to model,
and no alternate means of rejecting condenser heat when it is being routed to condenser coils
that are directly heating spaces, the available CHR percentage ought to be approaching 100%. The
compressor COP should account for losses associated with compressor heat rejection directly to
the surrounding air. As a small amount of heat will be lost in the distribution of refrigerant to coils
in heat rejection (heating) mode, an appropriate value for available CHR percentage might be on
the order of 95%, depending on the system components, configuration, and installation.
The graph below shows results for a modest 25-zone office building on a day where heating and cooling
loads overlap. There is one air-source heat pump (ASHP) acting as the heating mode of the VRV system
and one part-load-curve “chiller” as the cooling mode of the VRV. These components within ApacheHVAC
are permitted to serve multiple heating and cooling coils, as would be the case in a VRV system.
In the illustrated example, the ASHP and part-load cooling sources are coupled to heating and cooling
coils in a multiplexed stack of 25 packaged single-zone systems for the individual zones. These are created
from either the prototype Packaged single-zone system 04 or prototype Packaged terminal heat pump
system 02, as provided in pre-defined configuration. With just two exceptions, the pre-defined
configurations remain unchanged:
• Switch the cooling coil from the dedicated DX cooling model to the part-load curve chiller model
of similar characteristics set up to represent the VRV cooling mode and that includes the
condenser heat recovery (CHR) capability. Set pump power in both the chiller model dialog and
chilled water loop dialog to zero. This provides the capability for having many cooling coils
connected to one cooling source.
o The dedicated DX Cooling model using performance curves and accounting for the
entering air WBT at the DX evaporator coils provided as of VE 6.1.1 is thus far set up to
run only with one DX evaporator coil per DX cooling source (compressor & condenser)
and without any form of CHR to be passed to an ASHP. Therefore, the default assignment
of DX coils to this model in a pre-defined system needs to be changed.
• Change the System type for the heating coils to Generic heat source and select the generic source
that you have set up to represent the VRV heating mode.
o Note that as of VE 6.4.1 the ASHP is no longer placed on the airside network and has been
replaced by two separate dedicated components: an air-to-air heat pump (AAHP) and air-
to-water heat pump (AWHP). The former, like the DX Cooling Types, has a one-to-one
relationship between the heat pump and heating coils. Therefore—until a dedicated VRV

model is provided—the connection to multiple coils for a VRV model requires using the
Air-source heat pump (ASHP) accessed from within the Generic heat source dialog.
The condenser heat recovery (CHR) acts as the common refrigerant loop to pass heat from the zones in
cooling mode to those requiring heat. The CHR points to a Generic heat source representing the VRV
heating mode (via options described above) and electric-resistance backup heat.
The ER backup is third in line to meet heating loads after the CHR and VRV heating mode (part-load-curve
or ASHP) capacity are fully used. Because the backup heat source will always have an infinitely expandable
capacity, any limitation of heating capacity needs to be specified in terms of the capacity of the each
heating coils. Maximum cooling capacity is similarly limited by the capacity specified for each “simple”
cooling coil (advanced coils, water loops, and detailed chiller models must be used to model the cooling
performance of under-served coils in the case of intentionally constrained plant equipment capacity).
The graphs below for two different VRV examples show the recovered heat from the cooling mode (green
line) taking precedence over the ASHP (VRV heating mode) to meet heating load. When energy values for
the “chillers” and “heat pumps” variables are added in the second graph, these result also show that the
cooling system is accounting for the energy required to extract this heat via an evaporator coil in zones
where cooling is taking place and then pumping it to the heating side. Thus the electrical energy
consumption for this extraction of heat from zones in cooling mode does not need to be counted
separately on the heating side.

In working out the these methods, our observation is that for many building types and configurations, if
the systems are suitably controlled, there should be very little temporal overlap of heating and cooling
modes in a building effectively served by a large number of single-zone systems sharing a common
outdoor component. It would therefore appear that, in many applications, much of the efficiency (or
perhaps better referred to as efficacy) of VRV/VRF systems stems from their avoidance of the “one-size-
fits-all” plus re-heat outcome typical of a multi-zone packaged VAV system. In other words, the common-
loop aspect of the configuration often seems to be secondary, in terms of providing reduced energy
consumption, to other aspects of VRV, such as obviating the need for re-heat.
The table of results below shows another means of confirming the transfer of recovered heat from zones
in cooling mode to zones in heating mode: When there is a cooling load present and the cooling load
(total for all zones presently in cooling mode) times the cooling COP—i.e., the amount of heat that needs
to be rejected by the VRV system in cooling mode—is equal to or greater than the heating coils load (total
for all zones presently in heating mode), then the part-load heat source or heat pump load should go to
zero, as should the backup heat source if using the ASHP with backup electric heat.

The two graphs on the next page show additional examples of results variables that can be examined to
analyze the performance of VRV performance for particular project. Results such as these can be used as
a quick reality check to see that the system is behaving as expects. They can also be used to provide more
detailed analysis of what sort of performance might be expected under various conditions.

Appendix G: Hydronic Radiant Heating and Cooling Systems
There are two methods for modeling radiant cooling and heating systems in the VE. Which of the two
methods is most appropriate in any given project depends on a number of factors, ranging from design
phase and desired level of accuracy to system type, configuration, and parameters to be investigated.
While there are even quicker and further simplified methods provided by the ApacheSystems module,
these are primarily intended for UK compliance tools and early schematic design studies. The following,
on the other hand, describes methods appropriate to supporting design decisions, exploration of control
strategies, modeling specific opportunities for integrated operation of building systems and passive
thermal strategies, and detailed documentation of potential system energy savings.
• The first method models the radiant systems as hydronic heating and/or cooling panels or radiators in
the occupied space. This amounts to the straightforward use of the ApacheHVAC Radiator and/or
Chilled Ceiling components as described in the User Guide. Examples of radiant cooling panels
modeling are provided in the following pre-defined ApacheHVAC Prototype Systems:
o 09e Radiant Heat-Cool panels - DCV [EWC chlr - HW blr] .asp
o 09f Rad Heat-Cool - DCV - Heat pipe [EWC chlr - HW blr] .asp
o 09g Rad Heat-Cool - DV - DCV - Ht pipe [EWC chlr - HW blr] .asp
Please note that water flow rates are not yet autosized for hydronic room units; however, they can
be relatively easily calculated using the standard formulas [gpm = Btu/h / (500 x delta-T)] and
results of the ASHRE Loads analysis (either from the VE directly or in the Loads Data spreadsheet
generated for a custom version an otherwise pre-defined prototype ApacheHVAC system).
Note also that only the last of these three pre-defined systems includes a stratified zone for
modeling thermal displacement ventilation (DV) or similar environments.
• The second method models the radiant systems as hydronic heating and/or cooling within a separate
slab zone above or below the occupied space. Because ApacheHVAC does not yet, however, have
dedicated zone loops for this purpose, heating and/or cooling panels or radiators are placed within
the slab zone and some adjustments made to the type definitions to remove characteristics of those
devices that are not relevant when modeling hydronic loops in a concrete slab.
All chilled ceiling panel systems, all four-pipe heating/cooling panel systems, all radiator/panel and fin-
tube convector heating, and most heating-only slabs can use the first and simpler one of these two
options. In the case of heating-only slabs, the panel-based method is often adequate given that the
thermal and energy performance for most heating-only systems does not depend significantly on taking
advantage of thermal mass and off-peak operation of equipment. However, there are cases, such as a
space with a heated floor slab that also receives significant direct solar gain, for which is will be important
to use the second method to accurately model the thermodynamics of the floor slab. In other words, if
the slab is likely to become thermally saturated by direct solar gain, this will both provide buffering of
peak solar gain and alter the delta-T between the hydronic loops and the slab material, thus affecting the
load profile for the heating source.
Modeling radiant cooling systems requires further considerations, and thus drives the need for using the
second method in all cases where there are cooled elements of the building fabric (e.g., a floor or ceiling
slab) rather than a cooled metal ceiling panel. Furthermore, it is common for cooled slabs to have surface
temperature sensors, and these can be modeled only with the second method. Combined heating/cooling
systems are subject to the same considerations as cooling-only systems, plus additional care with respect
to sensors signals and controls to avoid inefficient consecutive operation of heating and cooling modes.

There are seven essential considerations in selecting the appropriate method. The last three of these are
significant mainly with respect to actively cooled concrete slabs or similar elements of the building fabric:
1. Type of hydronic radiant system: lightweight panels vs. thermally massive slabs?
2. Design phase: in conceptual or schematic design, simpler panel models may more often be sufficient
3. Location of cooled surfaces or building elements relative to the occupied space
a. Location of panels relative to the occupied space: horizontal (overhead) or vertical panels
b. Location of slabs relative to occupied space, ground, and outdoors: ceiling, floor, and/or walls
4. Operating modes: heating-only, cooling-only, or both?
5. Interaction of chilled slabs with solar loads: will active slabs frequently receive direct solar gain?
6. Level of accuracy: model the slab cooling capacity or use pre-determined value per delta-T?
7. Significance of slab material thickness: e.g., is there intent to assess potential for pre-cooling?
8. Physical coupling with other systems and building elements; for example: Is there an underfloor air
distribution (UFAD) plenum on top of the radiant slab through which the supply air will exchange heat
with the slab? Is there a warm return air plenum under a chilled floor slab? Is the use of thermal
displacement ventilation (DV) or a UFAD system likely to increase the delta-T, and thus the convective
heat transfer, at the surface of a chilled ceiling?
Modeling of radiant cooling, with and/or without heating, should facilitate or account for the following:
• Radiant and convective heat transfer to and from cooled panels and/or slabs
• Orientation of panels (horizontal or vertical) and physical location and orientation of active slabs
• Differing characteristics (capacity at delta-T, radiant/convective split) of various panel options
• Thermal mass and absorption of direct solar gain for actively cooled slabs
• Rate of heat transfer resulting from hydronic tube spacing and depth in radiant slabs
• Slab surface and occupied zone temperatures
• Control of water temperatures and flow rates in zone-level hydronic loops according to slab core or
surface temperature, occupied space temperature, and/or outdoor temperature resets
• Modeling of chilled and hot-water sources, loops, and pumps, including heating and cooling sources
• Potential effectiveness of low-energy heating and cooling water sources that take advantage of the
moderate water temperature usable (and often required) in radiant systems—e.g. indirect
evaporative cooling, waterside economizers, condenser heat recovery, condensing boilers, and solar
hot water.
• Potential for nighttime and early morning pre-cooling of chilled slabs
• Assessment of occupant thermal comfort, including dry-resultant or operative temperature both
during peak cooling demand and in early morning occupied hours where pre-cooling is included
• Integrated operation and control of hydronic and airside systems, including dedicated outside air
systems (DOAS) for ventilation, latent loads/condensation control, and energy recovery
• Controls for mixed-mode systems (natural ventilation plus radiant), where applicable
• Capability for modeling stratified thermal environments, with or without displacement ventilation,
where appropriate to space type and or system design
• Controls for automated shading devices and/or of modeling user-operated shading, daylight-based
dimming of electric lights, and other active load-control strategies
All of the above are supported within the IES <Virtual Environment>.

To the extent they are present in the system, all heated or chilled ceiling and wall panels, four-pipe
heating/cooling panels, radiators, fin-tube convector heating, and most heating-only radiant slabs can be
appropriately modeled using the first (panel-component-based) method. With this method, only radiant
slabs require special considerations to mimic the performance of the massive slab and to appropriately
constrain output when the active slab is a floor or similar surface that occupants will be in contact with.
These considerations are described in the next section below. All of the other hydronic terminal unit
devices mentioned above can be modeled without any special considerations.
1.2 Modeling hydronic heated and/or cooled slabs using radiant panels (method 1)
This method approximates the performance of a hydronic radiant slab using radiant heating and cooling
panels within the conditioned space. There are no slab zones and nothing inside of any floor or ceiling
construction. Panel performance parameters are treated much as they would with actual heating and
cooling panels, with two very important exceptions: the panels representing the slab will be massive and,
if the slab is a floor, the surface of the panels must be treated as a floor with people walking on it and
sitting immediately above it.
Radiator and Chilled ceiling Types dialogs:
• Orientation should be horizontal if this is to mimic a ceiling or floor; vertical if an active wall element.
• Radiant fraction should be set according to the split of convective vs. radiant effect. The faction will
tend to be higher for a cooled floor or heated ceiling than for a cooled ceiling or heated floor, given
the convective heat transfer characteristics of floor and ceiling surfaces.
• When using a model of radiant panels to mimic a heated and/or cooled slab the reference surface-to-
air delta-T and associated heating or cooling capacity must be constrained by the need to maintain
slab surface temperatures within the range desired for human thermal comfort—typically 64°F (18°C)
minimum in cooling mode and 75°F (24°C) in heating mode. Given room air temperature of around
75°F (24°C) when in cooling mode and 68°F (20°C) when in heating mode, the reference delta-T values
would be just 11°F (6 K) and 7°F (4 K) for cooling and heating modes, respectively.
• The heat or cooling output at the reference temperature should then be set at a reasonable value for
this modest delta-T. In the case of a heated floor, the convective heat transfer coefficient will be
higher, and thus capacity will be better than a heated ceiling slab. In the case of a cooled floor, unless
there is direct-beam sun striking the floor to present the load very directly, the cooled floor will have
less cooling effect than a cooled ceiling, given convective heat transfer will be very limited in the
downward direction. Sensible cooling capacity for typical slab-to-space temperature differentials is on
the order of 24 Btu/hr-ft2 (~7 W/ft2 or 77 W/m2) of active surface, not including associated
ventilation systems or strategies. When even a relatively low-cooling-capacity ventilation system,
such as DV, is also accounted for, cooling capacities begin to approach those of conventional all-air
VAV systems.
• Water capacity should be the volume in each radiant loop/zone, within reason, as the effect of this
will be dwarfed by the effect of the massive floor.
• The weight should reflect the approximate mass of the heated/cooled floor construction. Again, very
rough numbers can be used at this stage just to approximate the thermal inertia of the slab.
• Additional general technical information such as that provided above, along with many references for
further reading, is available in a paper authored by ApacheHVAC Product Manager, Timothy Moore,
prior to his joining IES. This paper is available from the UC Berkeley Center for the Built Environment
at www.cbe.berkeley.edu/research/pdf_files/IR_RadCoolScoping_2006.pdf

1.3 Modeling heated or cooled slabs using slab zones and hydronic loops (method 2)
For the second method—detailed modeling of heated and or/cooled hydronic radiant slabs—there are a
number of specialized steps that must be taken. The following provides guidelines for these within the VE.
1.3.1 Hydronic Radiant Slab Zones

Proper modeling of the slab and hydronic tubing is essential, as this is the heat transfer path to and from
the water. This is particularly important in the case of a chilled slab, given that this heat transfer will
ultimately determine the cooling capacity and resulting thermal comfort under peak conditions. Using a
standard slab construction will tend to overestimate heat transfer to and from the hydronic loops.
Conversely, the model should be constrained only by slab properties, controlled temperature and flow
rate of the water, and the capacity of the heating and/or cooling water sources.
• The radiant slab zone should be represented in the model with a minimal non-zero interior volume.
While it must have some volume in order to be simulated as a thermal space in the model, the air
volume inside the slab zone should be minimized so that it is effectively removed from the heat
transfer modeling.
o When inner volume representation is not applied in ModelIT, this can be accomplished by
simply drawing a very thin zone—e.g., 0.01 inch or 0.1 mm, or similar height. The construction
thickness for the slab material will still me modeled, but will not be visually represented and will
not contribute to the height of the exterior walls or overall building.
o If inner volume representation is used in ModelIT, then the slab zone should be drawn as
representing just the slab thickness that is above the centerline of the hydronic tubing. The
total thickness of slab zone top construction (the “ceiling” of the slab zone) should then be very
slightly less than the actual thickness from the tubing centerline to the finished floor or
equivalent surface above. The bottom portion of the slab—below the tubing center line—
should then be set by the top layer in the construction for the ceiling of the space below (e.g., a
return plenum or occupied space under the radiant slab).
For example, in IP units, a 6” thick radiant floor slab with hydronic tubing 2” from the top
surface and a room below would have the following dimensions and constructions:
Slab zone height = 2”
Slab zone “ceiling” overall construction thickness = 1.99”
The top layer (outermost) of the construction for the “ceiling” of the space below
should be concrete of appropriate thermal characteristics with layer thickness = 4”
If the slab construction, including any insulating layers, is in direct contact with the
earth:
- The innermost layer (bottom layer in the list of construction layers) of the
ground-contact floor construction should be concrete of appropriate thermal
characteristics with layer thickness = 4”
- The second from the outermost layer (top layer in the list of construction
layers) of the ground-contact floor construction should be approximately 36”
of soil to represent the thermal mass with which the hydronic slab—whether
insulated or not—will interact.
- The outermost layer (top layer in the list of construction layers) of the ground-
contact floor construction should be a U-value adjustment layer (created with

the U-value adjustment tool) to appropriately represent the sum of all
potential heat transfer paths through the ground to the outside air (see
below).
• If the conditioned slab is in contact with the ground, user the Ground-contact U-value adjustment facility within the
Ground-contact/Exposed Floors section of the constructions database (ApCdb) to add an appropriate U-value
adjustment layer. Both EN-ISO and F-Factor methods are provided. Whether there is to be perimeter or under-slab
insulation in the project, this facility will add an additional layer of insulation in the construction to represent the
resistance of the average path from the average underside of your building to the outside air. This layer is best added
beyond the 30” (0.75 m) of earth normally included in ground-contact constructions. For hydronic slabs—especially if
uninsulated below—the thermal mass of this soil is important with to include adjacent to the floor.
• The inside surface for both the slab top and bottom (ceiling and floor, which will be the ceiling of the room below for
non-ground-floor stories of the building) need to have internal air-film resistance set to 0.0001 ft2-hr-F/Btu (or
2
0.0001 m K/W, effectively zero, but not zero). This facilitates modeling the water in direct contact with the
construction.
• Conductivity for the concrete material in slab top and bottom constructions should be reduced (adjusted to an
appropriate lower value) to account for the spacing and depth of the tubes within the slab, plus the resistance of the
PEX tubing wall. This is best done with a 2D finite-element model of just two tubes in a cross-section of the slab top
and slab bottom using LBNL’s free THERM tool. This tool provides a quick and accurate means of determining an
overall U-value for the combination of all heat-transfer paths between the slab surface and the water in the tubes.
Typically, depending upon hydronic tube material, depth, and spacing, the conductivity value for the concrete
material will need to be reduced about 20 to 60%---i.e., to about 40 to 80% of its initial value. Whereas the
unadjusted value would over-predict heat transfer, too small a value will under-predict it.

The THERM model and spreadsheet calculations above are used to determine the correct adjusted
conductivity for the concrete slab or other material in which the hydronic tubing is embedded. The
THERM model is relatively simple and the spreadsheet calculations are simply used to convert U-value to
resistance, then subtract the resistance of the water film in the tube and air film on the exposed surface,
convert resistance to conductance, and finally use this to calculate the adjusted conductivity value for the
concrete material. This final number will be entered into the concrete layer of the construction in the VE
and will account for the tube material, diameter, depth from the surface, and spacing within the slab.
The following excerpt from SIMULATION OF RADIANT COOLING PERFORMANCE WITH EVAPORATIVE COOLING SOURCES
(T. Moore, May 2008; Center for the Built Environment) provides further explanation of the simple slab
and hydronic tube model preparation in THERM. Following that within this appendix is a section (12.2.2)
on setting up hydronic loops and controls for radiant slabs in ApacheHVAC. Additional information on
both of these topics can be found in SIMULATION OF RADIANT COOLING PERFORMANCE WITH EVAPORATIVE COOLING
SOURCES, available from the UC Berkeley Center for the Built Environment at:
www.cbe.berkeley.edu/research/pdf_files/Moore2008-RadCoolSimulations.pdf

Adiabatic
boundary
conditions
PEX tubing
material and
boundary Close-up of finite-element mesh at section
condition through bisected hydronic tubing
Lower half of cast concrete ceiling/floor slab material:

The upper half mirrors the dimensions and heat transfer Chilled ceiling surface
pathways from the embedded hydronic tubing to the boundary condition
cooling surface; adjacent portions of the slab to each with adjacent air at
side repeat this cell in keeping with the tube spacing. 25°C (77.4°F)
Radiation enclosure
with facing surfaces
at 24°C (75°F)
Figure 1a: A cross-section of the concrete slab with embedded hydronic tubing is described in THERM as
a repeatable segment bounded by the chilled surface (bottom), center of the tubing (top), and midpoint
between tubes (either side). Boundaries other than the tube interior and chilled surface are adiabatic.
Figure 13b: Isothermal contours indicate the distribution of temperatures resulting from the finite-element
model of two-dimensional heat transfer between boundary conditions.
Figure 13c: Isothermal contours as graduated colored/grayscale fills provide a visualization of continuous
temperature gradients throughout a cross-section of the chilled slab material.

1.3.2 ApacheHVAC Hydronic Loops and Controls for Radiant Slabs
• Radiator Types and Chilled Ceiling Types are, for the time being, used to model hydronic loops
that will be placed within a slab zone. This is accomplished by effectively eliminating a number
of irrelevant inputs normally used for modeling radiant panels. Guidelines for settings in the
Radiator and Chilled Ceiling Types dialogs for hydronic heating and cooling loops placed within
a slab zone are as follows:
o Orientation (horizontal or vertical) is relatively unimportant, but should be set to
match the orientation of the slab in which the zone loop will be placed.
o Radiant fraction should be set to zero, as the loop should have only a convective
(really conductive) coupling with the core of the slab.
o The reference temperature should be set to 1 K (1.8°F), the smallest value permitted.
The reason for this is that this delta-T will, in this type of application, be referencing
the difference between the controlled average water temperature in the zone
hydronic loop and the negligible volume that must remain within the 3D slab zone in
order for it to be included in the model. Setting a larger value as would be done for a
panel in the occupied space will unnecessarily constrain the heating and/or cooling
capacity of the zone loop.
o The rate at which the room loads add or remove heat to/from the slab will determine
how close the core temperature of the slab is to the water temperature. In some
cases, the delta-T may be a fraction of the minimum 1 K input value.
o The influence of the heating and cooling Output at Reference Temperature Difference
should be effectively eliminated as a limit on heating/cooling capacity. It should
therefore be set to a greater value than the maximum from boiler/chiller or the peak
zone load from the loads analysis. However, because extreme values may introduce
instability in the model, an appropriate value would be two to four times the
anticipated peak zone load, thus allowing capacity equal to the peak zone load to be
available from the loop when the water-to-slab core delta-T is ½ to ¼ of the reference
temperature (above). The idea here is to let the modeling of the slab and controls on
water temperature and flow rate in the loop determine the actual capacity at any
given time step.
o Maximum Cooling from Chiller and Maximum Heating from Boiler values can be used
as limiting factors for zone loops, but this is in addition to setting the water
temperature and flow rate at the unit controller. As the latter are typically a more
appropriate means of limiting the zone loop heating or cooling capacity, the value for
Maximum Cooling from Chiller and Heating from Boiler can be set to a value that will
be notably higher than any zone for which the particular Type is to be used.
o The weight should be that of just the water, and the water capacity should be
consistent with the loop or loops for which the type will be used. As the loop mass and
water volume are likely to be very small relative to the concrete slab, exact values are
not important here.
• To facilitate multiplexing and copying of room components representing slab zones and
containing zone loop controllers (Room Unit Controllers for “Radiators” and “Chilled Ceilings”),
“Room with Air Supply” components should be placed on a side branch of the airside HVAC
network. From a setup and editing perspective, this is preferable to using the “Room without
air supply” component (this component is, for this reason, to be removed until a multiplex
compatible version is made available).

• The airside network branch that couples the slab zones must have a time switch controller
with Flow Rate set to zero.
• Temperature sensor locations for hydronic slab heating and cooling loop controllers
(“Radiators” and “Chilled Ceilings”) should be determined by design. These locations can
include any combination of slab core (local or within the slab zone), slab surface, the adjacent
occupied space conditioned by the slab, any other space in the building where the thermostat
would be located, and/or external to the building (for modeling water temperature reset
based upon outdoor temperature).
• Water temperatures for heating and cooling should be set appropriate to radiant slab design
parameters—i.e., to avoid thermal discomfort or condensation issues—and in keeping with
any limitations imposed by low-energy heating and cooling sources used in the project.
• When using room temperature sensors rather than a surface temperature sensor assigned to
the surface of the slab itself, the radiant fraction in the controllers should normally be set to a
small fraction of 1, or about 0.1–0.2 for a typical wall-mounted thermostat. However, if the
project will use a specialized thermostat that approximates operative temperature, a more
appropriate value for the sensor radiant fraction may be in the range of 0.4–0.5.
• Flow rates for hydronic loop controls are, as of VE 6.4, not yet autosized; however, they can be
relatively easily calculated using the standard formulas [gpm = Btu/h / (500 x delta-T)] and
results of the ASHRE Loads analysis (either from the VE directly or in the Loads Data
spreadsheet generated for a custom version an otherwise pre-defined prototype ApacheHVAC
system).

1.3.3 Illustrative results indicating appropriate modeling of radiant cooling slab

Appendix H: Modeling UFAD and DV in ApacheHVAC
The HVAC systems library includes two pre-defined UFAD system prototypes. One is intended for more
humid climates for which dehumidification will be required, and thus includes an optional heat
pipe/wheel/runaround coil in the AHU. The other simply excludes this feature. The labeled image of the
prototype UFAD system below is as it appears in version 6.5 (VE 2012).
• There’s little value in modeling UFAD without stratified thermal zones, as this is the primary means of
obtaining energy savings with such systems, so treat this as a given in the proposed model. Including
the UFAD plenum geometry is also important for understanding actual supply temperatures after gain
in the plenum.
• It is essential, especially in larger models, to ensure that loads in the stratifies zone normally specified
in terms of W/ft2 (or m2) are entered and converted via the Room Data Tabular Edit view to absolute
values (btu/h or W) before replacing the “floor” surface of the stratified zone with a “hole” to the
occupied zone below. Changing the input mode for all stratified zones in the building can be done
simultaneously via a single selection change of this parameter in Room Data Tabular Edit view with all
stratified zones selected and ticked in that view.
• How to split loads depends upon building type/use. For offices and similar spaces, it is generally
advisable to place loads as follows:
o Lighting gains: 100% in the stratified zone if pendant or surface-mount fixtures; split between
stratified zone and the RA plenum zone if the fixtures are flush mounted in a drop ceiling that
defines a return plenum. The surfaces in occupied zone below will, along with those in the

stratified zone, “see” the radiant fraction of the lighting gain. Set the radiant fraction according
to the general type of light fixtures or data for actual fixtures.
o Occupants gains: 100% in the occupied zone, as this simplifies ventilation calculations and
introduces some conservatism with respect to not relying upon thermal plumes from
occupants that may be moving about enough to re-mix the stratification as much as they add
to it. (Note: If the space is a theater or similar with stationery occupants being the dominant
load, however, it then makes sense to split the occupant load partly to the stratified zone.)
o Equipment gains: Split these gains between occupied and stratified zones according to
anticipated distribution of actual convective gains. Determine the split via CFD studies for the
project, physical measurements in a mock-up, research literature, or other means appropriate
to the project scale, scope, resources, and level of detail required.
As a default until better data can be obtained, and assuming the occupant gain is placed 100%
in the occupied zone, an even 50/50% split between the occupied and stratified zones is a
reasonable starting point for most UFAD systems, and a 30/70% split between occupied and
stratified zones is a reasonable starting point for true thermal displacement ventilation (DV)
systems that gently “pour” a pool of cool air onto the floor (i.e., not using swirl diffusers).
• The pre-defined UFAD systems in ApacheHVAC include a “re-mixing” path and control for use in zones
that include a fan-powered box for heating (typically perimeter zones). This feature partially mixes the
space, reducing thermal stratification consistent with the flow rate from each particular zone fan-
powered box. It does so in a particular zone only when its fan runs. It is important to understand how
your particular system is designed, as this remixing behavior will not be present for all applications.
• In the case of the ASHRAE 90.1 PRM for LEED and similar performance rating systems, the re-mixing
path and control can also be used in a baseline (non-stratified) version of the same system to destroy
the stratification at all times and to more completely mix the space, rather than partially mixing the
space consistent with the flow rate from a particular fan-powered box only when heating is engaged.

• When autosizing a UFAD system and corresponding baseline VAV system for comparison, as is typical,
it is important to make some adjustments to the autosizing process to calculate the correct zone-level
airflow rates for both the proposed and baseline models. There is one simple customization of the
Loads Data spreadsheet that needs to be made for each of these two system models, as follows.
1. UFAD System: Adjust the supply temperatures in the Room Design Airflows tab of the Loads Data
spreadsheet for the Proposed UFAD HVAC system so that heat gain in the UFAD plenum will be
accounted in the airflow calculation. In other words, the airflow calc needs to account for both the
loads in the occupied zone and the load picked up by the supply air in the UFAD plenum. This is
represented as an adjusted supply air temperature, and therefore a reduced delta-T, which will
increase the design supply flow rate accordingly. The following example shows this adjustment as
made by inserting a new column for UFAD supply plenum heat gain within the Room Design Airflows
tab of the Loads Data spreadsheet for the UFAD system. The values for gain in degrees°F in the new
column are simply added to the supply air temperature normally reported in the next column.
The plenum gain numbers can be set to typical values to begin with (e.g., 2–5 °F), and then later
adjusted according to results of an initial system-level sizing run.
This adjustment of the supply air temperature for UFAD airflow should be done independent of the
SAT and reset values for the AHU cooling coil entered in the System Parameters dialog. This dialog
edits the system tabs of the corresponding Loads Data spreadsheet, and these values set the LAT at
the AHU cooling coil, which will differ from the SAT at the diffusers. Because the coil LAT must be
lower to address the heat gain in the UFAD plenum, and may need to be colder still for
dehumidification, the AHU input parameters must be set independent of the zone SAT that is used for
airflow calculations. Therefore, use the System Parameters dialog or direct editing of system design
parameters on the relevant system tab, as shown below, to set the leaving temperatures for the AHU
coils. Use the added column described above to adjust the SAT values for design airflow calculations.

The graph of HVAC node results for the sample UFAD model design sizing run below shows what you
should look for upon completion of the system-level design sizing run (system-level design sizing for
cooling will be the .cln results file, and in this case in Brisbane Australia January is the hottest month).
Any simulation of the few hottest days year can be used for this test. The graph shows the significant
difference between the SAT from the AHU at node 79 (dark blue line) and at the UFAD diffusers (node
59, light blue). The example spreadsheet above reflects the differences between the SAT at the AHU
and diffusers for specific zones. These gains are somewhat greater than typical, given the hot sunny
climate, significant direct-beam solar gain striking the raised floor top surface of the UFAD plenum,
and the nature of the two-story test model (described in subsequent pages); however, not unrealistic.
The graph below is for the second system-level design sizing run—i.e., after adjusting the plenum gain
values in the spreadsheet and re-applying the resulting zone airflow values to the controllers in the
HVAC system. Node 60 (green) is the occupied zone temperature, which is the essential determinant
of whether or not the airflow is adequately sized to address the zone loads with the actual supply
temperature exiting the diffusers. Node 64 (red) is the stratified zone and node 78 (pink) is the RA
plenum. It’s worth noting that the temperature in the first-floor RA plenum is actually lower than the
temperature of the first-floor stratified zone, as the RA plenum air is being actively cooled by the
second-floor UFAD supply plenum sitting on top of the metal and concrete floor deck that separates
these two plenums.

2. Baseline system: Use either the same system model running the remixing path at all times or a
dedicated system model, such as a standard VAV system, with the stratified zone and remixing path
added. Thus the baseline system or any alternative version of the proposed that is not meant to be
stratified can be modeled without removing the partitioning for thermal stratification from the
thermal zones in the model. The multiplex region within the Baseline VAV system will exclude the
UFAD supply plenum but will include the stratified zones in series with the occupied zones, with the re-
mixing path “stirring” these back together as a single “well-mixed” zone. You must do two things:
a. Either, add the stratified zone, remixing path, and controller for this from the UFAD network to
the Baseline or non-stratified alternate version, as shown below, or, to run the UFAD system
model as a fully-mixed system for comparison, remove the AND connection from the controller
on the re-mixing path in the UFAD version so it will run continuously during the simulation.
b. Zone-level loads for the occupied and stratified zones need to be combined for the autosizing
of airflow controllers by adding a cell reference for this within the Loads Data spreadsheet for
the system. This must be done for each Baseline or alternate non-stratified system in order to
have the zone airflows properly sized to address the entire load with the space fully mixed.
This is actually quite simple. The example below shows the Loads Data spreadsheet for the
Baseline VAV system in a model where the stratified zones where present at the time of zone-
level autosizing. The formula in cells K8 through K11 have been modified to add the loads from
cells J16 to 19, respectively. This will then size the design cooling airflow to the occupied zones
according to the total load in occupied plus stratified zones. The same is done for the heating
loads and airflow calculations. The controller airflow settings need to be updated (Assign
System Parameters and Room Sizing Data in the workflow navigator) after combining the loads
in the spreadsheet airflow calculation.

To get the stratified zones to show up in the spreadsheet in a list following the corresponding occupied
zones, the stratified zones must first be organized in the model browser (normally by name) so that the
sorted list of stratified zones will be exactly parallel to the corresponding occupied zones (same number of
zone sin the exact same order). The stratified zones should be assigned to a group that matches the room
group used to assign occupied zones to a particular AHU. Having done so, you must temporarily assign the
appropriate group of stratified zones to the same ApacheHVAC system multiplex as the corresponding set
of occupied zones (i.e., on additional rows below the occupied zones within the same multiplex edit
dialog). Be sure not to rep[lace or delete multiplex rows for any occupied zones. Then run the zone-level
sizing, which will generate a spreadsheet as shown above with the stratified zones listed below the
occupied zones. If you already have baseline system spreadsheets that you want to keep, move them for
the time being to a folder with a new (custom) name before running the zone-level sizing so that this will
generate a new spreadsheet for each system. Then modify formula in the spreadsheet columns K and P
on the Room Design Airflows tab so that the loads from occupied and stratified zones are added in these
columns as described above. Once you have done all this, you will need to delete the added (stratified
zone) layers from the HVAC system multiplex(es); however, be sure to leave the added rows in the
spreadsheet. Thus, once having assigned to spreadsheet values to controls in ApacheHVAC, the airflow
controllers on each occupied zone multiplex layer will have flow rates based upon the combined load,
including the corresponding stratified zone for each.
The image below illustrates an appropriate test model for a very large building with numerous identical
spaces served by a UFAD system. The divisions on the side of the model show occupied and stratified core
and perimeter zones, common UFAD and RA plenums, and non-UFAD services zones at the back of the
core zone. Apart from the one exterior façade, this small piece of the larger building is surrounded on all
sides other zones. Whether they exist in the model or are represented by simplified dummy zones, these
adjacent spaces are placed on a separate layer in ModelIt, and this layer is de-activated (status = off) in
the Layer Properties dialog, thus making all the adjacencies effectively adiabatic (the thermal mass of the
constructions is still present, but the net heat transfer across any adjacency is zero) without exposure to
outdoor conditions. This allows much faster testing and experimentation for these representative zones.

The following are examples of the sort of results from a single hot day in an initial simulation run that
should be checked to ensure that loads are being met and thermal stratification is being modeled as
intended. This also illustrates how the modeling results can be used to explore and communicate the
thermal effects associated with the assumed plume factors for internal gains.
80.5
80.0
79.5
79.0
78.5
Temperature (°F)
78.0
77.5
77.0
76.5
76.0
75.5
75.0
74.5
74.0
00:00 06:00 12:00 18:00 00:00
Date: Tue 02/Feb
Air temperature: 01 Perim Occupied (ufad example 2.aps) Cooling set point: 01 Perim Occupied (ufad example 2.aps)

86
84
82
80
Temperature (°F)
78
76
74
72
70
68
66
00:00 06:00 12:00 18:00 00:00
Date: Tue 02/Feb
Air temperature: 01 UFAD Plenum (ufad example 2.aps) Air temperature: 01 RA plenum (ufad example 2.aps)
Air temperature: 01 Perim Occupied (ufad example 2.aps) Air temperature: 01 Perim Stratified (ufad example 2.aps)
Similar results can also be queried for nodes in the HVAC system to confirm system operation and to
analyze the influence of both primary SA duct and UFAD plenum gains.

• As for whether or not to include the UFAD plenum in the model, there are a number of advantages in
terms of modeling how UFAD systems actually work. It is valuable and perhaps essential to explicitly
model the UFAD supply plenum whenever one or more of the following is true:
c. The raised floor top surface of the UFAD plenum sees direct-beam solar gain.
d. The UFAD plenum is sitting on a floor deck that has a warm return plenum below it, as in many
multi-story projects.
In either of these two cases, there will be significant gain to the plenum, and thus the supply air
temperature to the zone will not be the same as the leaving temperature from the AHU (regardless of
whether you’re including duct heat gain). As the plenum area is generally large, gain to the plenum can
be substantial. A study by the UC Berkeley Center for the Built Environment (CBE) showed that, even
for a core zone, as much as 40% of cooling load for a typical multi-story office space with RA plenum
below the floor deck can accrue to the supply air in the UFAD plenum before it reaches the diffusers.
When direct beam solar is striking the raised floor, heat gain in the UFAD supply plenum can be much
greater.
• Apart from its use as described above for re-mixing the occupied and stratified zones to model a non-
stratified system for comparison, the re-mixing path and control is used to de-stratify the model in
spaces that are served by a UFAD system and have a fan-powered box for reheat (such as perimeter
zones or private offices), and where this fan-powered box is able to stir the space. This might extract
room air as an induced secondary airflow into the fan-powered box (how the ApacheHVAC prototype
UFAD system is set up by default) or simply couple the fan-powered box to a diffuser that blows air up
the glazed perimeter wall. In any case, if the UFAD system is design and implemented properly, there

will be good stratification in cooling mode and little to no stratification in heating mode. This captures
the benefits of thermal stratification for cooling mode and avoids wasting that warm air when the
occupants need it. The modeling of this is intended to de-stratify the space when and only when the
fan-powered box is operating, and this is the reason for the logical AND connection from the remixing
controller to the airflow control on the fan-power-box secondary/re-circulated airflow path.
The remixing path is highlighted in yellow below. The controller for this is in red, including the logical
AND connection to the fan-powered box controller, and the controller dialog is at right. The controller
uses a simple proportional relationship to ramp up the re-mixing flow directly in proportion to the flow
from the UFAD diffusers to the occupied zone.
• Distribution of radiant exchange in thermally spaces modeled as an occupied plus stratified zone:
The radiant fraction of an internal gain is seen by all “surfaces” in the space to which the gain is assigned.
The term “surfaces” is in quotes here, as this includes the hole that connects the occupied and stratified

zones in each room. As such, if, for example, the ceiling above and hole at the base of the stratified zone
in a particular room were to account for 80% of the total “surface” area of that stratified zone, then 40%
of the radiative energy would initially strike the ceiling and 40% would strike the hole as a “surface”. The
remaining 20% would be distributed among the walls of the stratified zone in proportion to their surface
area. In other words, as a proxy for actual view factors, which can get very computationally weighty, the
radiant energy is distributed to surfaces as an area-weighted proportion of the total.
Once the radiative energy from the internal gain has been distributed, along with other radiative inputs,
surface temperatures and the differences thereof are used to calculate radiant exchange between
surfaces. When the hole as a pseudo “surface” between occupied and stratified zones receives radiation
from the lights, it has no capacity to store thermal energy, and thus does not heat up and convectively
heat the adjacent air as normal surfaces would; however, it does immediately communicate the radiation
it receives to all of the surfaces that it can “see”. This re-distribution is done in proportion to surface area
and temperature of receiving surfaces, as with other radiant exchanges. As such, the hole acts somewhat
like a diffusing lens that scatters the radiation passing through it according the area and relative
temperature of the surfaces it can see.
• Because the hole connecting the occupied and stratified zones has no surface area as a “floor” for that
space in the 3D model, if the lighting gain in the stratified is to set in terms of W/m^2, this needs to be
done prior to creating the 100% hole in the partition separating the occupied and stratified zones. Once
these gains have been specified in W/m^2, select all stratified zones and use the Tabular Room Data tool
in the Apache Thermal view with all rows selected in that window to simultaneously change the Input
Mode for all lighting gains in the stratified zones from W/m^2 to W. You’ll need to do the same for the
stratified fraction of equipment and task-light loads (see below) prior to adding the holes between zones,
otherwise these gains will be set to zero when you replace the “floor” partition for the stratified zone
with a hole of the same area.
• If you have a return plenum at the ceiling AND the light fixtures are mounted within the drop ceiling such
that a fraction of the radiant and convective go directly to the RA plenum, defined a separate lighting gain
for the plenum. If, for example, you had 10 W/m^2 total lighting gain with 20% overall going to the
plenum and 40% overall radiative, you would have two lighting gains defined: Stratified zone = 8 W/m^2
and 40% radiative and Plenum zone = 2 W/m^2 and 40% radiative. This assumes that the top surface of
the fixture is white painted metal or plastic, etc., such that is has typical emissivity and thus the portion of
gain directed up into the plenum as radiant energy will be similar to that directed down into the room.
• For a UFAD system (as with DV or radiant cooling) including the radiant fractions for these gains is
important, as the top and bottom constructions (raised floor and floor deck below) will be cooled by the
supply air—much like a radiant cooling slab. The same is true for DV systems that gently “pour” cool air to
form a more or less continuous shallow pool of cool air on the floor. The floor gets cool. As the raised
floor of a UFAD plenum is cooler than the ceiling it can see above, which is surrounded by the stratified
zone and RA plenum, it will received radiant heat from the ceiling. As long as there is thermal
stratification, this will be true for the model and in the real world. Similarly, in a multi-story building,
because the floor deck under the UFAD plenum will be cooled by the supply air—like an air-cooled
version of a hydronic radiant slab—it will receive both radiative and convective gain from the much
warmer RA plenum below. The result of gain at the top and bottom of the UFAD plenum is gain in the
supply air, just as in the real-world plenum. Even when there is no direct-beam sun striking the raised
floor surface, gain to the supply air in the plenum can account for as much as about 14% of the gain
removed from the space. When there is direct-beam solar striking the raised floor, this can be much
greater.
• In keeping with the logic above for lighting in a commercial office space, gains for both equipment/task
lights and people will need to be appropriately distributed. Because equipment and task lights tend to be

stationary, these will have stronger and more consistent thermal plumes. Therefore, depending upon the
mix of actual devices, the plume factor for these might be on the order of 70%—i.e., 70% of their gain
should be directly assigned to the stratified zone. As for radiant fraction, however, only the portion of the
gain assigned to the occupied zone (the actual location of the equipment
• As noted above, if equipment/task-light gains are to be specified in W/m^2, the fraction of the gain that
will be assigned to the stratified zone needs to be placed there and converted to an absolute gain
(expressed in Watts) prior to replacing the partition surface with a hole.
• As people are much less consistent with respect to thermal plumes (they tend to fidget, move about, and
sometime breath with some force, thus making for inconsistent thermal plumes), the above approach to
lighting, equipment, and task lights will account for much of the dependable thermal stratification from
internal gains. What to do with the occupant gains then becomes a bit of a judgment call with respect to
providing a fair approximation of real-world thermodynamics for the particular type of space, use, and
occupancy. If the space is relatively lightly occupied, as with mainly office spaces, simply placing all
occupant gains in the occupied zone introduces a modest conservatism, but simplifies inputs for occupant
gains as well as occupancy-based ventilation calculations and inputs. The contribution of CO2 from
occupants, which is calculated in proportion to combined sensible and latent gains for the occupants in a
space at any given simulation time step, will also accrue 100% to the occupied space when all people
gains are placed there. On the other hand, if the space is densely occupied and occupants will be mainly
sedentary, it may be worth splitting the loads such that 30–60% of occupant gains are assigned to the
stratified zone, along with lighting and/or equipment. This may be particularly important for a theater or
similar space conditioned by a thermal displacement ventilation (DV) system.
• If a separate people gain is used to assign a portion of heat from occupants to the stratified zone, the split
between the occupied zone and stratified zone gains should be done as follows: Let’s use the example of
a relatively densely occupied call center with each occupant given 4 m^2 of space (about 40 sf/person).
Let’s assume that, given available research or CFD modeling, it was judged that an average of 50% of the
sensible thermal gains from occupants would accrue to the stratified zone in the form of thermal plumes,
thus bypassing the occupied air volume and thermostat. Let’s also assume that, given the slightly tense
and stressful nature of the call center work, the sensible gain per occupant was estimated to average 120
W/person and the 75 W/person latent gain will be omitted from consideration with respect to thermal
plumes (although this is a bit of a simplification, all latent gain will be assumed to be mixed with the
occupied air volume by occupant breathing and movement, rather than some of it being transferred
immediately to the stratified zone).
• Begin, before replacing the partition between occupied and stratified zones with a hole, by creating
separate people gains for the occupied and stratified zones. Both should use the full occupant density of 4
m^2 per person, which will aid in other occupant-dependent inputs and calculations for the occupied
zone; however, both will use only 50% of the sensible gain (60 W/person for each). While full 75
W/person latent gain will be used for the occupied zone people gain, the latent gain will be set to zero
W/person for the stratified zone (the latent gain, as with CO2 added to the occupied zone, will eventually
pass through the stratified zone, but only after being fully mixed with the occupied zone air and then
diluted and displaced by introduction of supply air).
• Where the space is densely occupied and de-humidification will be controlled according to the relative
humidity in the occupied zone, it will be important to also split the latent gains so that they accrue to
both occupied and stratified zones. In the example above, it may be appropriate to include roughly 40
W/person latent gain in the occupied zone people gain and 35 W/person latent gain in the stratified zone
people gain.
• Where CO2-based demand-controlled ventilation controls are to be modeled to reflect CO2 sensors that
will actually be placed in the occupied zone of the built spaces, it will be important to maintain the

“people” gain type in the stratified zone in order to have CO2 accrue to both occupied and stratified
zones in proportion to the combined.
• Note that whenever the “people” gain type is used for internal gains directly assigned to the stratified
zone, care should be taken to zero out any occupancy-based calculation of fresh air for stratified zones.
The fresh air should be calculated for and introduced into only the occupied zones. The proper calculation
of fresh air ventilation rates for the occupied zone is the primary reason for placing the full occupant
density (number of occupants) in both occupied and corresponding stratified zones, and then adjusting
the sensible and latent gains per person to reflect the thermal plume factors—i.e., reducing each to split
the gains appropriately.

Appendix I: Solar Hot Water Applications in ApacheHVAC
Solar Hot Water in Apache HVAC
Solar Hot Water in ApacheHVAC can be used for space heating and/or DHW, but is always located on the
HW loop return. This does not, however, negate the use of the separate Solar HW module in Apache
Thermal view to first meet DHW load, and thus take advantage of the greater delta-T between main water
supply and the solar HW loop for improved solar HW efficiency.
While the DHW-coupled configuration in the ApacheThermal view is the most common for residential
applications, commercial applications often have very little DHW demand, and thus tend more often to
use the solar hot water for space heating.
Typical configurations
The initial configuration for Solar Hot Water in ApacheHVAC (as of VE 6.4.1) will most often be used in
low-temperature heating systems, such as hydronic radiant floors, for which the return water
temperature is quite low. This solar HW application is normally paired with a condensing boiler as the
backup heat source, so as to maximize the opportunity for actual condensing operation, which also
required a moderate return temperature.
Solar hot water panels as a pre-heating system on the HW loop return is also a configuration sometimes
used for natatoriums. However, a heat pump or “heat-recovery chiller” may more sense in such cases as
means of handling latent loads from pool evaporation on the evaporator side, with condenser heat being
rejected to the pool. This is because the majority of heat loss from swimming pools is typically in the form
of latent heat and the air then needs to be dried to avoid condensation on windows and other
components of the building fabric.
Advanced configurations
Then there are more complex strategies, such as that implemented for a regional hospital project in BC
Canada, that use hot, cold, and temperate water loops with two water-to-water heat pumps to facilitate
recovery of heat from low-temperature sources, such as the exhaust air stream, to heat both DHW and
occupied spaces. A strategy such as this presents an opportunity for solar heating of both DHW (heating
cold water from the mains) and for putting heat into the heat recovery loop that is then a resource for
water-source heat pumps.
The range of applications for the solar HW in ApacheHVAC will further expand as IES adds water-to-water
heat pumps and additional configuration options. Presently, however, users can model heat-recovery
chillers and can upgrade the temperature of condenser heat from a chiller set via a single-COP heat pump
option on the HW loop.

Appendix J: Pre-ISM Zone Loads, Ventilation, and Autosizing using
the Loads Data Spreadsheet and original System Schedules
interface (VE2015 and earlier versions)
1 Zone Loads, Ventilation, and Autosizing using the Loads Data
Spreadsheet
1.1 Overview
Pre-defined prototype ApacheHVAC systems can be imported and autosized at both the zone and system
levels. These two levels of loads analysis and autosizing can also be applied successfully to a broad range
of user-modified variants of the pre-defined prototype systems. All systems, including any user-defined
configuration, can be autosized with respect to system coils, fans, water loops, and plant equipment.
For pre-defined systems and variants thereof, the autosizing process sizes a broad range of system
elements in two stages—first at the room/zone level, then at the system/plant level—with opportunity
for user intervention between the two. ASHRAE Loads calculations are linked to target ApacheHVAC
systems for both stages of the sizing process:
• Zone-level loads and sizing must be completed either manually or through the autosizing
procedure described below. The resulting values for airflows and other controller settings
must be assigned to the HVAC system in order for the spaces to be adequately conditioned.
• System-level loads and sizing, which applies to coils, fans, water loops, chillers, DX cooling,
boilers, heat pumps, and other heat sources, must be completed in order to appropriately
scale equipment capacities and performance data to obtain appropriate performance and
energy consumption (unless the equipment sizing/capacities are otherwise manually set).
While any pre-defined prototype system can be modified without losing autosizing capabilities, retaining
the zone-level autosizing capability requires maintaining pre-defined controller applications, controller
reference name prefix with colon (e.g., “MC4: ….” ), and relationships to the Loads Data spreadsheet for
each system. The use of the Loads Data spreadsheet is further described below.
System-level autosizing for coils, fan components, DX Cooling, HW and CHW loops, Heat transfer loops,
boilers, chillers, heat pumps, and most other heating and cooling sources that “see” a load during the
sizing run, applies to all ApacheHVAC systems, regardless of how and when they were created.
Figure 1-1: Systems setup and sizing toolbar in ApacheHVAC.
From left to right, the toolbar buttons in Figure Figure 1-1 provide the following functions.

1.2 Zone-level loads and sizing
The zone-level autosizing process sets zone-level and airside control inputs in the context of basic system-
level parameters. Depending upon the specific system type, these include the following parameters:
• zone-level heating and cooling load oversizing factors
• zone-level airflow for VAV boxes, fan-coil units, fan-powered boxes, active chilled beams, etc.
• outside-air ventilation rates as well as CO2 sensor control thresholds, where DCV is employed
• exhaust airflow and inter-zonal transfer airflows (typically as make-up air for exhausted air)
• reheat coil leaving air temperatures and flow rates
• radiator and chilled ceiling panel water flow rates (as of version 6.5)
• outside-air economizer damper minimum flow rates (incl. optional ASHRAE 62.1 calculations)
• outside-air economizer dry-bulb temperature high limits*
• energy recovery engagement, sensible and latent effectiveness, and device power*
• coil leaving air temperatures, temperature resets, and zone humidity control*
For prototype systems, the zone-level autosizing process provides means of engaging or disengaging
system features, such as outside air economizers and airside energy recovery, from within the System
Parameters dialog, in a addition to manually changing these within the Loads Data spreadsheet for each
system or within the ApacheHVAC airside network itself. The controllers in pre-defined systems also use
pre-defined control profiles (which you may also use as you see fit). This allows system-operating schemes
for unoccupied hours—e.g., temperature setback only, setback with fan cycling, or setback with fan
cycling but no outside air—to be selected along with system schedules and setpoints. While these
parameters and operating schemes can be manually changed, the dialogs provide basic inputs and
automation for pre-defined systems.
The System Schedules dialog (see additional description below) sets room heating and cooling set points,
operating schedules, including start-up and after-hours operation, and the control scheme to be used
during unoccupied hours. It does so via automated editing of a pre-defined set of profiles that are
referenced within the prototype systems and also applied to Room Data in the Apache Thermal view. The
application of heating and cooling set points from the System Schedules dialog to Room Data for each
conditioned space provides the fundamental basis for autosizing.
The System Parameters dialog (see additional description below) provides initial inputs for many of the
zone- and system-level parameters in the list above, such as zone load oversizing factors and both air-
handler and zone coil leaving air temperatures, as inputs to the autosizing of zone-level airflows, etc. It
should be noted that oversizing factors are separately set with coils, water loops, and other heating and
cooling equipment that is autosized only in the system-level stage of the process.
While otherwise accessible to any ApacheHVAC user, the ASHRAE 90.1 Performance Rating Method (PRM)
Navigator in the VE provides additional interface dialogs and tools for ASHRAE 62.1 ventilation rates,
exhaust airflow settings, and application of PRM Baseline fan curve inputs. The PRM Navigator interface is
described in a separate user guide. The more manual approach to these parameters is described below.
IMPORTANT: Through version 6.4 and variants thereof, the automated zone-level sizing procedure
requires that the target ApacheHVAC system file is named “proposed.asp”. This file name must be in
place prior to using either System Parameters or Room Load Calculations in the System Prototypes &
Sizing navigator. If not, the parameter changes and/or sizing process will not populate the Loads Data
spreadsheet according to the rooms or zones assigned to the correct target system. The target system
name of “proposed.asp” must also remain in place (or be reinstated) for the Assign system parameters

and room sizing data action in the sizing navigator. The ApacheHVAC file name can be subsequently
changed without consequence. For version 6.5 an onward, this naming convention will not be required,
nor is it required for the System-level loads and sizing process described below.
1.2.1 Zone-level system set up and autosizing steps

Unless the model has exceptionally small number of thermal zones, conditioned spaces or thermal zones
in model should first be according to system or air-handler assignment. If using the System Prototypes &
Sizing navigator, prepare for the sizing process by loading the blank (default) Loads Data spreadsheet into
the project folder via the Acquire prototype data action in the navigator. As of version 6.5, this will be
automatically loaded when using the system parameters and sizing toolbar buttons within ApacheHVAC.
Having completed these preparations, the main steps in system setup and autosizing are as follows:
Figure 1-2: Open ApacheHVAC, load selected systems from the HVAC Prototype Systems Library as
needed, and save the file. When using workflow navigators for either the ASHRAE 90.1 PRM or System
Prototypes & Sizing, creation and naming of a blank file called “proposed.asp” is automatically executed

by the Prototype System action in the navigator; however, outside the context of the ASHRAE 90.1 PRM
Navigator, this naming is not required when working directly from the ApacheHVAC toolbar.
Additional systems can be loaded at any time and additional sizing runs performed as needed. Prototype
systems can be modified or used as resources from which to copy elements for customizing or extending
the capabilities of a particular system. For all but advanced users, however, it is recommended that initial
system sizing and brief test simulations are completed prior to modifying the system configuration,
components, or controls (substantial experience with ApacheHVAC is also recommended).
As noted above, when using the workflow navigators, the automated zone-level sizing procedure requires
that the target ApacheHVAC system file is named “proposed.asp”. This file name must be in place prior to
using either System Parameters or Room Load Calculations in either the System Prototypes & Sizing
navigator or the ASHRAE 90.1 PRM navigator. The target system name “proposed.asp” must also remain
in place (or be reinstated) for the Assign system parameters and room sizing data action in the sizing
navigator. The ApacheHVAC file name can be subsequently changed without consequence. This naming
convention is not required for the System-level loads and sizing process described below or when working
directly from the Systems setup and sizing toolbar in ApacheHVAC.
Figure 1-3: Use Edit Multiplex to assign groups of rooms or zones to the prototype system.

Figure 1-4: System Schedules dialog edits coordinated profiles used in system controllers and Room Data.

Figure 1-5: Opening the System Parameters dialog generates a Loads Data spreadsheet for each system
(one per multi-zone system or set of single-zone systems) and provides access to setting essential
parameters for system sizing and operation via the spreadsheets.* Edited parameters are recorded in the
respective Loads Data spreadsheet for use in subsequent steps of the process—i.e., edits to these
parameters are not immediately reflected in the ApacheHVAC system components and controllers.
*Note: In 2013 detailed system parameter dialogs with tabular edit views will be attached to each system
and the Loads Data spreadsheet will no longer be used.

Figure 1-6: The Room Load Calculations step in the System Prototypes & Sizing navigator runs ASHRAE
Loads and populates the Loads Data spreadsheet for each network with loads results and other relevant
data, such as room volumes. Calculations for zone airflows and similar parameters use the loads data and
previously recorded settings from the System Parameters dialog. There are optional features in the
spreadsheet for zone-specific airflow configurations and calculation of ASHRAE 62.1 ventilation rates.

Figure 1-7: The Assign System Parameters and Room Sizing Data step assigns values to system
components and controllers. This is the essential final step in the zone-level autosizing. Viewing the zone
heating or cooling airflow rates for all multiplex layers confirms that this stage of autosizing is complete.

1.3 System-level loads and sizing
System autosizing—the second sizing stage—runs the selected ApacheHVAC system to determine design
sizing for system and plant equipment. Sizing at this level is thus the combined result of the zone loads for
the design-day conditions, setpoints (including setback in the case of cooling), system configuration, and
controller settings for the selected ApacheHVAC system.
This stage of the sizing process can be applied to system-level equipment for any (pre-defined or user-
defined) functional ApacheHVAC system, and no Loads Data spreadsheets are required. Furthermore,
except in the context of the Workflow Navigator for ASHRAE 90.1 PRM, system sizing does not require a
specific ApacheHVAC target file name. Rather, the target HVAC system file is simply selected when the
system level sizing is performed (when system sizing is launched form the ApacheHVAC toolbar, the
system sizing target defaults to the currently open ApacheHVAC file).
System-level autosizing applies to the following components within ApacheHVAC:

• heating coils
• cooling coils
• fans
• boilers
• chillers
• hot water loops
• chilled water loops
• heat transfer loops
• DX cooling
• air-source heat pumps
• water loop heat pumps
• furnaces
• water-source heat exchangers
• other heating & cooling sources
A coil, for example, is sized according to the maximum load it “sees” during the design sizing run, given
the settings within controls for leaving air temperature, dehumidification, air flow rates, and so forth.
System-level autosizing does not use or require the Loads Data spreadsheet for each system. Loads Data
spreadsheets are required only for zone-level autosizing and for expediting setup of common component
parameters, such leaving air temperature setting for coils, via the System Parameters dialog. Regardless of
where they exist in the system (AHU or zone level) all coils and fans are autosized along with plant
equipment during the system-level sizing run, which does not depend on the spreadsheets.
Figure 1-8: System-level sizing and System Loads report buttons on the Systems setup and sizing toolbar.
System load calculations and autosizing can be run from the System-level sizing button on the
ApacheHVAC toolbar (Error! Reference source not found. above), directly from within the ASHRAE Loads
dialog (Figure 1-9 below), or from the System load calculations action item in the System Prototypes &

Sizing navigator. This third option is further described under in the System Prototypes & Sizing workflow
navigator section below.
Figure 1-9: ApacheHVAC system loads analysis type in ASHRAE Loads dialog
In addition to the System Loads Calculation reports, there are also a number of tools available for
checking the number of “unmet load hours” according to various criteria. This is explained in the next
subsection immediately below.

1.3.1 Unmet Load Hours tests
Unmet load hours are any hours of operation when conditioned spaces are outside the throttling range
for heating or cooling controls. While this test is performed automatically in the 90.1 Performance Rating
Method (PRM) Navigator for the associated reports, this can readily be done as a manual check within
Vista Results. To do so, complete all of the following steps (an example is provided below):
1. In Vista Results, select the conditioned spaces in the model from the Room Browser tree at left.
2. Select the Air temperature results variable.
3. Open the Range Test tool.
4. Date/Time: check the tick box below the list of week days and select When conditioned (incl.
setback) from the drop-down menu next to this tick box.
5. Test: Between room setpoints (+/- differential tolerances)
6. Under Test temperatures in controlled band, tolerances in °F (or, for metric users, … in °C ), enter 2
for both heating and cooling if working in IP units and 1.11 for both if working in metric units
(these settings will apply for most user most of the time; see further notes below).
7. Check the tick box for Averaged, shared hours (for ‘unmet hours’ test).
8. Click Apply.
The range test below shows results for a system autosized perfectly to meet all loads for the simulation
period of eight days in January (this test was aimed at confirming heating performance). This outcome
may actually be less than ideal if meeting all loads under the most extreme conditions causes the system
to be significantly oversized relative to more typical conditions. And, over a full year, even autosized
systems will normally have some unmet heating or cooling hours as a result of varying conditions and
related system dynamics or differences between the design sizing conditions vs. the simulation weather
file. The results of an unmet loads hours test should, however, generally appear as in this example.

Figure 1-10: Unmet Load Hours test performed using the Range Test tool in Vista Results

Figure 1-11: Heating setpoint profile (purple), Cooling setpoint profile (blue), zone air temperature
(green), and plant profile (red) for a selected space in the model.
As can be seen in Figure 1-11: Heating setpoint profile (purple), Cooling setpoint profile (blue), zone air
temperature (green), and plant profile (red) for a selected space in the model. above, the profiles set in
the Room Data dialog for a particular space (either via a Thermal Template, via System Schedules dialog,
or manually) for heating and cooling setpoints are recorded at the time of simulation and can readily be
placed on graph along with the zone/room air temperature. The profiles show the setpoints for occupied
hours and setback for unoccupied hours.
The right-hand graph shows the heating setpoint and room temperature once again with the Plant profile
(red). The plant profile toggles between 0 and 1 to indicate the times during which the normal daytime
setpoint should be fully met (future versions of the VE may use this profile to provide more detailed
information regarding system status relative to setpoints, night-cycle operation, and so forth).
It is important to keep in mind that the heating and cooling profiles show the setpoint for occupied hours
as a target for the morning start-up and after-hours operating periods. Thus you may see the room
temperature lagging behind the setpoint profile, particularly in the early morning hours. The definitions
below describe how unmet load hour tests use nighttime setback values while the modeled spaces are
transitioning between nighttime setback and daytime setpoint. This avoids over-counting unmet hours.
Note that in the illustrative example on the preceding page there are some spaces in the model for which
the hours in all three columns are zero. These spaces are plenums and an unconditioned vestibule. While
they still have profiles assigned to them in Room Data (via System Schedules or manually) for timed
heating and cooling setpoints and setback, they have their heating and cooling on/off profiles (on/off
schedules) in Room Data set either individually or via thermal templates to “off continuously.” This is the
essential means of indicating that a space in unconditioned with respect to unmet load hours tests.
When the VE detects heating and cooling on/off profiles set to “off continuously” and thus determines
that a particular room is fully unconditioned, a nominal unconditioned values range of 20°C +/-80°C (68°F
+/-144°F) is applied. This equates to an unconditioned heating value of -76°F (-60°C) just shy of the -80°F
lowest external temperature ever recorded in the US, and an unconditioned cooling value of 212°F
(100°C)—the boiling point of water. These values are recorded at the time of simulation as continuous
setpoints for any fully unconditioned space.

1.3.1.1 Definitions of terms used in the Unmet Load Hours range test
The terminology used in the range test tools for unmet load hours is somewhat specialized. The following
definitions may therefore be helpful in using the Range Test dialog for unmet load hour tests:
• When Occupied: All times for any particular room when occupancy is greater than zero.
• When room heated or cooled: Tests for hours out of range relative to the setpoint profiles at all
times for each particular room, so long as the value for the on/off profile for either heating or
cooling = on. If there are warm-up and after-hours operating periods over which the daytime
setpoints are extended, this test will use daytime setpoints during these time periods. This test
does not allow for room temperature transition from setback to setpoint.
• When plant profile on full: All times for a particular room during which the normal daytime
setpoint should be fully met—i.e., fully excluding unoccupied/nighttime operation (outside of
“opening hours”) and both morning start-up and after-hours operation.
• When conditioned (incl. setback): Tests for hours out of range relative to setpoints, applying
the unoccupied/nighttime setback values to any morning start-up and after-hours operating
periods during all times for a particular room when the on/off heating or cooling profile = ON.
This test assumes, for example, that the full morning warm-up period will be needed to raise a
particular zone from the setback temperature to the daytime setpoint, and therefore does
allow for room temperature transition from setback to setpoint.
• Between room setpoints (+/- differential tolerances): Test to count hours in three categories:
o Below the heating setpoint minus the heating control band tolerances
o Between room setpoints, +/- the set control band tolerances
o Above the cooling setpoint plus the heating control band tolerances
• Test temperatures in controlled band, tolerances in °F: These values set the added tolerance
above and below the setpoints that should be applied to determine when a temperature is
“out of range.” The tolerances allow for the throttling or control of HVAC parameters such as
variable water and air flow rates in coils and ducts to address loads. The pre-defined systems
all reference profiles that have names beginning with “HVAC,” and so long as they are changed
only via the System Schedules dialog, these profiles are maintained with standard throttling
ranges relative to the heating and cooling setpoints. Unless you’ve set up your own HVAC
controller profiles or have revised values in the pre-defined “HVAC” profiles within ApPro, the
standard 2°F for both heating and cooling when working in IP units (1.11°C when in metric)
should be used here. If you have set up custom control profiles, you will need to set these
tolerance values to allow for the throttling range in the custom profiles.
• Averaged, shared hours (for ‘unmet hours’ test): This looks at average temperature over the
full one-hour period in each room for each hour and then adds any particular out-of-range
hour to the total “shared hours” tally only once, regardless of how many rooms or zones were
out of range during that hour. The “shared hours” total of each column is displayed in the
bottom row of the table.
With all conditioned spaces selected, the total of shared hours reported in the bottom row as
outside the control ranges for both heating and cooling are collectively the Unmet Load Hours.
A space temperature is considered out of range (under-heated or under-cooled) for any hour
when the average temperature for that hour is below the heating setpoint less the control
band tolerance or above the cooling setpoint plus the control band tolerance. The “shared
hours” might be thought of as a logical ‘OR’ test, with each hour counted only once when any
one or more rooms in the currently selected set of rooms is/are out of range.

1.3.2 Understanding loads for ApacheHVAC components in Vista Results
It’s important to understand what you’re looking at when viewing loads for ApacheHVAC components
within Vista Results view. The following is meant to touch on just a few points that may be less obvious in
terms of how the numbers you see in the results relate to the capacity of the components and the loads
that they convey to heating and cooling plant equipment.
Coils are relatively more straightforward in that their capacity or loading is a function of design inputs:
• For simple coils, the capacity set in the coil dialog will be the capacity, regardless of conditions on
either the air or water side of the coil. This load will be passed to the connected water loop or
directly to the heating or cooling source if no water loop is present.
• For advanced coils, the capacity of the coil is a function of the relationship between the design
conditions and the actual conditions at any given time step as well as the temperature and flow
rate of the connected water loop.
Water loops will contribute to the load seen by a boiler or chiller: heat rejected to the water loop by
pumps will add to or subtract from the load placed upon the loop by coils and other devices.
Room units, unlike coils, have heating and cooling effects associated with the presence of their mass
within the conditioned space: Regardless of whether it is OFF (i.e., not active or presently engaged) or ON,
the thermal mass of any room unit will play a role in adding heat to or removing heat from the space. All
room units will thus have a load profile differing at least somewhat from the load profile seen by the
heating or cooling source to which they are coupled.
For example, a radiator will heat a room less as its mass is warming up and will continue to heat the room
after the flow of hot water to it is turned off. And, even if it never turns on, a radiator will absorb a minor
cooling load while sitting idle in a space as the space grows warmer. Thus at the end of a hot summer day
when the air conditioning runs just to closing time, a radiator will contribute ApHVAC Room Unit Cooling
Load (via stored “coolth”) when the airside AC system shuts down and the room begins to grow warmer.

2 HVAC controller profiles relative to setpoints entered in the
System Schedules dialog
SYS Cooling Setpoint = Timed cooling setpoint (during occ. + start-up & after hours) and setback (unoccupied hours)
SYS Heating Setpoint = Timed heating setpoint (during occ. + start-up & after hours) and setback (unoccupied hours)
SYS Plant Profile = On-off modulating profile denoting times—e.g., occupied or “opening hours”—for which the
normal daytime setpoints should be fully met. This excludes morning start-up and after-hours
operation when the set-points for occupied hours are in play, but may not yet be achieved.
CP1 = Cooling SP (150 F = “off”) HP1 = Heating SP -1°F EP1 = Occupied hrs; PP1, PP2, and PP3 =
or all hours when Occ. hrs. only if OA min
CP2 = Cooling SP (150 F = “off”) HP2 = Heating SP (40 F = “off”) set Off in unocc. hrs.;
setback strategy set
CP3 = Cooling SP +1°F HP3 = Heating SP (40 F = “off”) to any not labeled Occ. + start-up & after
“OA off”. hrs. if OA min On, but
CP4 = Cooling SP -1°F HP4 = Heating SP +1°F
fans cycling in unocc.
CP5 = Cooling SP -1°F (150 F = “off”) HP5 = Heating SP +1°F (40 F = “off”) hrs.; All hrs. if OA min is
On 24-hours, per EP1.
CP6 = Cooling SP +1°F HP6 PP4 = Same as PP1,
Occupied hours except when garage fan
CP7
(all hrs. when Fan not off or cycling) strategy set to “Setback
Occupied hours
= Midpoint between Heating & during unocc. Times"
(all hrs. when Fan not off or cycling)
Cooling setpoints wherein % is applied to
= Midpoint between Cooling &
Unoccupied hours PP4 for all unoccupied
Heating setpoints
= Heating SP +2°F hours (regardless of
Unoccupied hours
(40 F = “off” in unoccupied hours) setback vs. 24-hr cond.
= Cooling SP -1°F
to occ. setpoints setting
(150 F = “off” in unoccupied hours) HP7 = Heating SP -2°F for all other profiles).
CP8 Notes:
Occupied hours • For Cooling and Heating control profiles (CP1–8 and HP1–7 ), the timing of the shift
(all hrs. when Fan not off or cycling) between occupied and un-occupied setpoints for each of the four day types (Mon-Fri, Sat,
= 0.00 Sun, Hol) includes morning start-up and after-hours operation at the occupied/daytime
Unoccupied hours setpoints. The “setback strategy” determines whether a thermostat setback is used in
= Cooling SP -1°F unoccupied hours and whether HVAC fans stay on, cycle, or shut off.
• CP7 and HP6 control airflow on/off in unoccupied hours and “hand-off” in occupied hours.
(150 F = “off” in unoccupied hours)
• CP8 is a specialized primary airflow profile for systems with fan-powered boxes or similar.
• The economizer profile (EP1) and plant equipment profiles (PP1–4) are fully on during
only occupied hours. Because these are modulating profiles, the degree to which they are
“on” during occupied and/or unoccupied hours can be less than 100%. The parking garage
fan profile (PP4), for example, can maintain 20% airflow in unoccupied hours.
Among the HVAC profiles, CP7, CP8, and HP6 have unique behavior that warrants further explanation:
These three profiles are used in the on-off control of VAV airflow to schedule the min VAV flow rate ON
whenever the building is occupied (i.e., during the opening hours set in System Schedules dialog). CP7 and HP6
provide a “hand-off” of the maintenance of minimum airflow for all opening hours between the cooling and
heating airflow controllers. The CP8 profile, which is used in system with fan-powered boxes for heating, does
not have a corresponding heating airflow control to hand off to, so it forces the cooling airflow control ON for
all opening hours via a midband value of 0°F. These profiles also force the airflow ON at the min flow (at least)
during the closed hours if the system setback strategy is not “HVAC off” and does not include fan cycling.
• When the setback strategy includes fan cycling (either “Temp setback w/ HVAC fan cycling” or Temp
setback, HVAC cycling w/OA off”), all three of these profiles provide setback values during the closed

hours, such that the airflow is ON during closed hours only if zone the temperature is either below the
heating setback or above the cooling set-up value (with midband offsets; see example below).
• When the strategy is either “Temp setback” or “Temp setback w/OA off,” CP7 and HP6 profiles provide
a value midway between heating and cooling setpoints during all hours such that one of the two
controllers is maintaining at least the minimum VAV airflow at all times. For these strategies, the value
of CP8 is zero during all hours such that the minimum VAV airflow is maintained at all times (assuming
the zone temperature is never below zero).
• When the setback strategy is “HVAC off” during the closed hours, these profiles have extreme values
(150°F threshold for cooling airflow operation and 40°F threshold for heating airflow operation) that
prevent the fans from running so long as the spaces are within this very large temperature range.
2.1.1 An example and further explanation for CP7 and HP6 profiles
As we have separate controllers for VAV heating and cooling airflow, the value in these controllers during
occupied hours is always the midpoint between heating and cooling setpoints. If the setpoints are 69°F and
75°F, respectively, then the daytime profile values will be 72°F for both CP7 and HP6.
During night/unoccupied hours/days, these on-off setpoint control profiles operate the VAV airflow ON only
when the temperature in at least one zone is either below the Heating SP +2°F or greater than the Cooling SP -
1°F. Thus during the "closed" hours, if there are setpoints as above and heating and cooling setback values of
60°F and 80°F, respectively, the actual deadband in which there will be zero VAV airflow would be 17°F—i.e.,
the difference between (60+2) and (80-1).
When there is fan cycling, there is effectively a large deadband of no fan operation between the setback values
for HP6 and CP7. The alternative to fan cycling in the closed hours is that the fans are on continuously. This is
the case for the "Temp setback w OA/off" setback strategy.
When fan cycling is not part of the strategy, the HP6 and CP7 profiles for VAV systems are used to force the VAV
boxes to operate and demand at least their minimum flow rate at all times. Thus the value in the profile goes
flat at the midpoint between heating and cooling setpoints. The two controllers still hand off control as room
temperature passes this mark, but both are giving an ON signal, so the effect is a continuous flow at least equal
to the min VAV flow rate.
2.1.2 Coordination with changes made to setpoints via the System Schedules and Setpoints dialog
The values in these profiles are presently (in VE 2012) coordinated with night/weekend/holiday set-back/set-up
schedules for zone temperature setpoints via hard-wired temperature offsets in IP units, such as setpoint +1°F
and setpoint -1°F. The offset are the fundamental driver of airside controls sequencing.
The exact profile names are critical to this function, as they are used both by the System Schedules and
Setpoints dialog to keep track of alternate profile sets and by the profile import procedure to determine which
are present already.
Some HVAC profile application references within the controllers have been revised over time to improve control
sequencing (e.g., some have been switched from CP3 to CP4 or similar). There are also a few new applications
of these profiles to specific controls and systems subsequently added. For example, the profile named “HVAC
CP4 - Cooling (Midband: Sys 3–8 VAV airflow; Sys 9 FCU Clg Coil SAT)” is now also used as to provide a timed
midband for the zone-temperature based reset of the target mixed-air temperature at the outside air
economizer damper set. The name of the profile does not suggest this. Unfortunately, within the current
scheme, the names of the HVAC profiles cannot be changed without breaking their functionality. The current
HVAC profile names are therefore occasionally a bit confusing.

In a future release, the HVAC and SYS profile names will be simplified in keeping with the table above to clarify
relationships to setpoints and other specific functions, such as how a particular profile is used to determine the
operation of a particular component for a selected setback strategy in the unoccupied hours. Until then, that
table is a handy reference. It also shows which HVAC profiles are redundant: CP1/2, CP3/6, HP2/3, and PP1/2/3.
These HVAC profiles will, in a subsequent release, be replaced altogether with a more transparent and flexible
scheme that supports both Metric and IP units and provides user-friendly adjustment of the control “throttling
range” without need for manually editing control bandwidths and HVAC profiles. Until that functionality is in
place, the Appendix following this one describes manual edits for applications wherein a narrower throttling
range is required.
The spreadsheet below—best viewed at zoom of about 250%—describes the main applications of the HVAC
control profiles (CP1, HP4, and so forth) in controllers for each of the principal nine categories or types of pre-
defined HVAC systems in somewhat greater detail.

3 Manual Adjustment of Control Throttling Range for Tighter
Control of Space Temperature and Humidity
Whereas space temperature controls for maintaining human thermal comfort typically have a deadband
of several degrees between heating and cooling setpoints, plus an allowance for control of airflow, water,
coils, etc. as the space temperature strays outside of the band defined by the setpoints, projects such as
museum archives and laboratories may require considerably tighter controls.
• While there are exceptions for buildings where tight control is critical (labs, museums, certain
health-care applications, etc.) ASHRAE standard 90.1 requires at least 5°F between the heating and
cooling setpoints to allow for a deadband and to avoid wasting energy on overly tight control
(assuming this is simply for human thermal comfort). It is also important to maintain some control
bandwidth so that there is a range of temperature over which controls can modulate thermal inputs
to the space. In publication DA28 Building Management and Control Systems from AIRAH, the
Australian equivalent of ASHRAE, the recommendation for VAV applications is a minimum of 1K
actual (truly neutral) deadband between any control actions, plus control ramp bandwidths of at
least 1K each for both heating and cooling controls. With setpoints occurring in the middle of the
two control bands, this translates to heating and cooling setpoints separated by at least 2K.
• Among the four most common errors listed for VAV system control in actual building, AIRAH
includes “Small or non-existent deadbands lead to excessive instability.” The one case where AIRAH
suggests there might be less difference between heating and cooling set points is with PID
controllers, which can provide tighter control without excessive energy consumption but are
expensive to set up and thus less common outside of process applications. PID controls can only be
approximated by proportional controls modeling, and even with PID controls and high-quality
sensors, the actual control system will need some bandwidth over which to control dampers, coils,
etc. Furthermore, this tendency toward instability for very tight controls is exaggerated in
simulation, as reality has an unlimited number of time steps over which to make tiny corrections
whereas a whole-building simulation will use time steps somewhere between 1 minute and 60
minutes (typically 6 to 10 minutes for the VE).
The pre-defined controls and HVAC profiles require a minimum of 4°F (2.22 K) between the heating and
cooling setpoints to avoid overlap of controls, and using this minimum value would provide zero actual
deadband (one or the other control would always be active).

The graphic above from the ApacheHVAC user guide section 8.3.15 VAV airflow controls shows the
relationship of the standard pre-defined control midbands and bandwidth relative to zone heating and
cooling setpoints. In this example, the heating and cooling setpoints are separated by 6°F, and it can be
seen that the ramps for cooling airflow and heating coil control will overlap if this difference is reduced by
more than 2°F.
If you require tighter control than is allowed by the pre-defined controls, you must either 1) modify the
HVAC control bandwidths and/or 2) modify the HVAC control profiles to move the control midband values
closer to the setpoint, depending on the intended outcome. Appropriate controls sequencing—i.e.,
without overlap of controls such as airflow modulation and coil LAT modulation—usually requires that the
bandwidth are reduced whenever the midband offset reduced. These operations are described below.

3.1.1 Reducing control bandwidths for tighter control or to avoid overlapping control bands
To reduce the control bandwidths, simply modify the values for Proportional Bandwidth. As with any
controller parameter within the zone-level multiplex region of the system, this can be executed as a global
edit, a local edit, or via tabular edit by clicking the parameter label when in global edit mode.
o Reducing the cooling airflow control band from the default 2°F to 1°F without adjusting the
midband profile would allow the heating and cooling setpoints to be moved 0.5°F closer without
overlap (i.e., to a minimum separation of 3.5°F
o If the same change from the default 2°F to just 1°F was made in the zone re-heat coil controller,
this will shave another 0.5°F from the required separation, allowing the setpoints to be just 3.0°F
apart without overlap.
o The reduced minimum required separation of setpoints noted in the examples above assumes that
it is acceptable to have no actual deadband at all. This will tend to lead to control instability,
particularly if using relatively large simulation time steps, and potentially forcing simulation with
very small time steps (1 or 2 minutes) to avoid modeling excessive energy consumption as a result
of unstable zone temperatures and the absence of an actual deadband.
o While it will not change the required separation of setpoints, similarly reducing the bandwidths for
Cooling SAT reset and Heating airflow controls will reduce the overall throttling range, and thus
apply the full potential of system heating and cooling over a narrower range of zone temperatures.
Again, there is some risk of added instability, but not nearly so much or with such energy-intensive
implications as eliminating the deadband between heating and cooling controls.

3.1.2 Manual editing of HVAC profiles to alter the midband offsets from setpoint and thus modify
this aspect of the throttling range
To adjust the control midbands closer to the heating and cooling setpoints, you will need to manually edit
the HVAC profiles in the ApPro database.
IMPORTANT NOTE: The System Schedules dialog, which can be a valuable tool prior to manual
edits, should not be used to edit or assign edited profiles after manually editing, as this will
overwrite manual edits.
As of VE 2012 Feature Pack 1, the System Schedules & Setpoints dialog includes a facility for
assigning any alternate set of set-point and HVAC profiles to selected zone groups and/or HVAC
systems. To avoid overwriting manual edits, it is essential that you create and assign an alternate
profile set before manually editing them to adjust the throttling range, and thereafter ensure that
you do not click OK or Apply in the System Schedules dialog when the modified set of profiles is
selected. The dialog is not (yet) capable of editing the profiles for any throttling range expect the
default, and it will overwrite your manual edits with defaults for this aspect of the profiles if you
click either OK or Apply.
For the same reasons, it will also be valuable to use the System Schedules dialog to edit HVAC
operating hours, morning start-up, after-hours operation, and control strategy for night/unoccupied
operation before manually editing the profiles to reduce throttling range, etc.
The tables in ApacheHVAC User Guide Appendix B: HVAC zone controller profile values relative to
setpoints entered in the System Schedules dialog (above) are helpful in identifying which profiles need to
be modified for a particular system type (listed in the first column). The associated profiles are indicated
as “HP2, HP5, CP1, CP7” corresponding to the profile names in the ApPro database view. For each system
type category (07, 09, etc.), the table indicates in a column for each relevant control the midbands value
relative to setpoint, which profiles is used, and whether the value is the middle of a deadband for on/off
controls with hysteresis or the midpoint of a proportional control band. The following VAV reheat system
rows from the table illustrate this:
For Cooling airflow, for example, the table indicates that…

• The on/off control schedule and setpoint are governed by HVAC profile CP7, which forces the airflow
ON during all occupied hours and, depending upon the night/unoccupied control strategy selected by
the user in System Schedules, cycles the airflow ON/OFF according to an elevated setpoint value that
is 1°F below the Unoccupied Cooling Setpoint. Given the default Unoccupied Cooling Setpoint of 80°F

and the selection of Temp setback with HVAC fan cycling as the Setback Strategy, the cooling airflow
will be on at no less than the minimum fan flow rate when any one or more zones exceeds 79°F.
• The midband value and setback schedule for this value for proportional cooling airflow control at the
VAV box is governed by HVAC profile CP4. This profile has a value 1°F below the Cooling Setpoint for
both Occupied and Unoccupied hours. Thus, when the daytime or Occupied Cooling Setpoint is
defaulted to 75°F, the proportional control of the zone airflow will use a midband of 74°F.
To reduce the offset of the daytime cooling airflow control with respect to the cooling setpoint, and thus
reduce the standard throttling range so that the setpoints can be closer together without overlapping
controls, the daytime value in profile CP4 needs to be closer to or even equal to the cooling setpoint.
• If you were to raise the daytime value in profile CP4 in the example above from 74°F to 75°F (equal to
the cooling setpoint) without altering the default proportional control bandwidth of 2°F, this would
also raise the lower end of the proportional control band by 1°F, thus allowing the heating and
cooling setpoints to be 1°F closer together without overlapping controls.
• If you were to raise daytime value in profile CP4 by the same 1°F and also reduce the proportional
control bandwidth from the default of 2°F to just 1°F, this would allow the heating and cooling
setpoints to be 1.5°F closer together without overlapping controls.
• If you then do the same for the Heating coil LAT control—moving the midband 1°F closer to the
setpoint and contracting the proportional band from the default 2°F to just 1°F—you would gain the
same 1.5°F of added leeway on the heating end of the control range. With both heating and cooling
control bands moved and retracted by this same amount, you would free up 3°F of actual deadband
(no control operation other than min airflow) between the setpoints.
• If you then chose to have no actual deadband whatsoever, the modifications described above would
permit heating and cooling setpoints separated by just 1°F without overlapping controls. Note,
however, that this will tend toward instability as small variations in room temperature will very easily
trigger alternating addition of cooing airflow and zone-level reheat. This will drive the model toward
shorted simulation time steps, such as 1 to 6 minutes, to avoid modeling excessive energy
consumption associated with oscillation between heating and cooling. And, very small simulation
time steps will at significantly to the time required to perform an annual simulation. It is therefore
highly recommended that for such models, if the project is anything much more than a very small
building with very few zones, the majority of diagnostic simulation and testing of hypotheses, etc.
should be performed using very short periods of 1 to 3 days in each relevant season—e.g., three very
cold winter days, three very hot summer days, and three shoulder-season days.

The user inputs for system setpoints and translation to controller inputs are presently being revised and
will eventually include separate heating and cooling user input parameters for Control Throttling Range.
This will facilitate modeling unusually tight control of space temperatures without having to manually
customize the HVAC profiles as described above.
3.1.3 Humidity control — dehumidification, sub-cooling, and reheat to SAT
When working with a humid climate, it’s important to understand that the pre-defined systems are set up
so that any zone with excessive RH can vote for a cooler off-coil temperature (down to the user input for
Cooling coil min LAT) to dry the air at the AHU. If the System AHU Heating coil LAT value is set lower than
the Cooling coil min LAT, this will for immediate reheat at the AHU when, and only when, the cooling coil
LAT is driven below the heating coil LAT by demand for dryer air.
• The controller MC2: Cooling SAT reset per zone dehumidification demand for each zone votes
on the system AHU cooling coil LAT with respect to zone humidity, and the default setting is a
55% RH midband with 10% bandwidth, such that this controller will vote for the min cooling
coil LAT if RH in the zone it is attached to gets up to 60% or higher. The Max. Percent
Saturation (%), which is the top end of the zone RH control band, assuming a 10% bandwidth,
is set in the Room Data or Thermal Template for each zone in the model (within Apache
Thermal view) and this value is picked up by the Loads Data spreadsheet at the time of zone-
level sizing. You can also adjust the RH midband value in the Loads data spreadsheet for the
system or within the controller itself (if you do the latter, you might want to remove the
“MC2:” from the controller reference name to avoid overwriting manual changes with
subsequent updates from the spreadsheet.
• For cooling and dehumidification controls, it’s helpful to understand how the System
Parameters inputs are used in the controls for cooling temperature reset and dehumidification
at the AHU.
Example
In the following example from the System side of the System Parameters dialog, the inputs are set so that:
• AHU cooling coil LAT can be as low as 50°F for dehumidification purposes; however, the
cooling coil LAT will be constrained to not less than the AHU Heating coil LAT when not driven
to a lower value specifically for the purpose of dehumidification.
• AHU heating coil LAT will be 54°F. Because this determines the minimum supply air
temperature leaving the AHU, this sets the lower bound for the AHU cooling coil LAT, except
when overridden for dehumidification, thus forcing immediate reheat at the AHU only when
justified by need to dry the air. (This parameters should really come before the Cooling SAT
reset in the dialog.)
• Design cooling SAT for calculating zone airflows will be 55°F, and this independent of setting
for coil LAT values, which can be lower if desired for dehumidification and/or cooling supply
temperature allowing for heat pickup in the ductwork. In this example, setting this value at
55°F and the AHU Heating coil LAT to 54°F suggests that you anticipate at least 1°F
temperature rise in the ducts when the AHU is at its minimum SAT. For this, ductwork heat
pickup should be enabled by indicating (within the Ductwork Heat Pickup component on the
system) an approximate duct U-value, surface area, and location (e.g., a return plenum zone)
for the supply ducts. When duct heat gain/loss is not modeled, the Design Cooling SAT is
normally set the same at the AHU Heating coil LAT, assuming this is the coldest air
temperature that will ever be supplied to the zones.

• The cooling SAT reset of 10°F will allow the SAT at the AHU to be raised up to 10°F above the
Design value when all zones on the system are at or below the zone Cooling setpoint. In this
example, this value would allow an SAT up to 64°F leaving the AHU. If the assumed minimum
heat gain is present in ductwork, this would result in an SAT of 55 to 65°F at the zone terminal
unit. (This parameters should really come last among these four in the dialog.)
These four parameters will be more logically arranged in a future version. A display-only field will also be
added to indicate the Min Cooling SAT from the AHU (uneditable) as the Min Cooling Coil LAT for zone
cooling purposes that is coordinated with and thus determined by the AHU heating coil LAT.
A subsequent release will introduce revised means of translating system setpoints to controller inputs,
and this will include user input parameters for control throttling range. This will facilitate modeling
unusually tight control of space temperatures without having to manually customize the HVAC profiles.

References
ASHRAE Handbook of Fundamentals, Heat Balance Method
ASHRAE 140-2004 and 2007 Standard Method of Test for the Evaluation of Building Energy Analysis
Computer Programs. ASHRAE 2004 and 2007. ISSN 1041-2336.
ASHRAE 90.1-2007, 2010, and 2013 Energy Standard for Buildings Except Low-Rise Residential Buildings.
ASHRAE 2007. 2010, and 2013. ISSN 1041-2336

ApacheHVAC Appendices A-J

Uploaded by

Copyright:

Available Formats

ApacheHVAC Appendices A-J

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ApacheHVAC Appendices A-J

Uploaded by

Copyright:

Available Formats

ApacheHVAC User Guide

Copyright © 2016 Integrated Environmental Solutions Limited. All rights reserved.

VE 2016 ApacheHVAC User Guide – Appendices A-J i

Appendix A: Rules for Air Flow Specification ...................................................................................4

VE 2016 ApacheHVAC User Guide – Appendices A-J ii

A: Overview and Fundamentals

B: Equipment, Loops, Components, and Controls

C: Working with Prototype HVAC Networks

D: System Parameters Interface for HVAC Networks

Appendix A: Rules for Air Flow Specification

VE 2016 ApacheHVAC User Guide – Appendices A–J 3

Airflows may be specified by the following mechanisms:

VE 2016 ApacheHVAC User Guide – Appendices A–J 4

VE 2016 ApacheHVAC User Guide – Appendices A–J 5

VE 2016 ApacheHVAC User Guide – Appendices A–J 6

VE 2016 ApacheHVAC User Guide – Appendices A–J 7

VE 2016 ApacheHVAC User Guide – Appendices A–J 8

(Section under construction)

1.1.1 Fan power for PRM Baseline systems

VE 2016 ApacheHVAC User Guide – Appendices A–J 10

VE 2016 ApacheHVAC User Guide – Appendices A–J 11

VE 2016 ApacheHVAC User Guide – Appendices A–J 12

VE 2016 ApacheHVAC User Guide – Appendices A–J 13

VE 2016 ApacheHVAC User Guide – Appendices A–J 14

VE 2016 ApacheHVAC User Guide – Appendices A–J 15

VE 2016 ApacheHVAC User Guide – Appendices A–J 16

VE 2016 ApacheHVAC User Guide – Appendices A–J 17

Minimum source temperature setting for the ASHP component

VE 2016 ApacheHVAC User Guide – Appendices A–J 18

VE 2016 ApacheHVAC User Guide – Appendices A–J 19

VE 2016 ApacheHVAC User Guide – Appendices A–J 20

Backup electric resistance heat

VE 2016 ApacheHVAC User Guide – Appendices A–J 21

Modeling Ground-Source Heat Pump HVAC Systems

VE 2016 ApacheHVAC User Guide – Appendices A–J 22

VE 2016 ApacheHVAC User Guide – Appendices A–J 23

VE 2016 ApacheHVAC User Guide – Appendices A–J 24

VE 2016 ApacheHVAC User Guide – Appendices A–J 25

VE 2016 ApacheHVAC User Guide – Appendices A–J 26

VE 2016 ApacheHVAC User Guide – Appendices A–J 27

VE 2016 ApacheHVAC User Guide – Appendices A–J 30

VE 2016 ApacheHVAC User Guide – Appendices A–J 31

VE 2016 ApacheHVAC User Guide – Appendices A–J 33

VE 2016 ApacheHVAC User Guide – Appendices A–J 34

VE 2016 ApacheHVAC User Guide – Appendices A–J 35

1.3.1 Hydronic Radiant Slab Zones

VE 2016 ApacheHVAC User Guide – Appendices A–J 36

VE 2016 ApacheHVAC User Guide – Appendices A–J 37

VE 2016 ApacheHVAC User Guide – Appendices A–J 38

Lower half of cast concrete ceiling/floor slab material:

VE 2016 ApacheHVAC User Guide – Appendices A–J 39

VE 2016 ApacheHVAC User Guide – Appendices A–J 40

VE 2016 ApacheHVAC User Guide – Appendices A–J 41

VE 2016 ApacheHVAC User Guide – Appendices A–J 42

VE 2016 ApacheHVAC User Guide – Appendices A–J 43

VE 2016 ApacheHVAC User Guide – Appendices A–J 44

VE 2016 ApacheHVAC User Guide – Appendices A–J 45

VE 2016 ApacheHVAC User Guide – Appendices A–J 46

VE 2016 ApacheHVAC User Guide – Appendices A–J 47

VE 2016 ApacheHVAC User Guide – Appendices A–J 48